Perché git continua a mostrare le mie modifiche quando cambio rami (file modificati, aggiunti, cancellati), indipendentemente dal fatto che esegua git add o no?

115

Sono davvero nuovo di git e ho cercato di capire perché git continua a mostrare tutto ciò che ho modificato in un ramo in un altro ramo quando eseguo git checkout per passare da un ramo all'altro. Prima ho provato a non usare git add e non ha funzionato. Tuttavia, ho provato a utilizzare git add, ma non ho risolto il problema. Non sto ancora usando git commit.

Questo è fondamentalmente quello che sto facendo:

$ git clone <a_repository>  
$ git branch  
* master  
$ git branch testing  
$ git checkout testing  
...edit a file, add a new one, delete...  
$ git status  
    # On branch testing  
    # Changed but not updated:  
    #   (use "git add/rm <file>..." to update what will be committed)  
    #   (use "git checkout -- <file>..." to discard changes in working directory)  
    #  
    #       deleted:    file1.txt  
    #  
    # Untracked files:  
    #   (use "git add <file>..." to include in what will be committed)  
    #  
    #       file2.txt  
no changes added to commit (use "git add" and/or "git commit -a")  
$ git branch  
  master  
* testing  
$ git checkout master  
D       file1.txt  
Switched to branch 'master'  
$ git status  
    # On branch master  
    # Changed but not updated:  
    #   (use "git add/rm <file>..." to update what will be committed)  
    #   (use "git checkout -- <file>..." to discard changes in working directory)  
    #  
    #       deleted:    file1.txt  
    #  
    # Untracked files:  
    #   (use "git add <file>..." to include in what will be committed)  
    #  
    #       file2.txt  
no changes added to commit (use "git add" and/or "git commit -a")

Ho pensato che, mentre usi i rami, qualunque cosa tu faccia in un ramo, è invisibile a tutti gli altri rami. Non è questo il motivo per creare rami?

Ho provato a usare "git add" ma le modifiche sono visibili in entrambi i rami. Devo eseguire "git commit" prima di passare da un ramo all'altro per evitare questo?

git

— JPZ
fonte

Risposte:

142

Il cambio di ramo porta con te modifiche non vincolate. O eseguire prima il commit, eseguire git checkout .per annullarli o eseguire git stashprima di cambiare. (Puoi ripristinare le modifiche con git stash apply)

— Sean Clark Hess
fonte

git stash pop è migliore a meno che tu non voglia creare un enorme stack di stash.

— siride

@JPZ: git stash si occupa solo di file tracciati; i nuovi file non vengono tracciati, quindi non verranno nascosti.

— siride

@JPZ: Se vuoi mettere da parte i file non tracciati, la cosa da fare è git addloro prima di metterli da parte. Detto questo, non sono sicuro che tu voglia effettivamente nasconderti qui - se intendi che tali modifiche facciano parte del ramo da cui ti allontani, eseguine il commit. (Se intendi tornare a quel ramo e lavorare di più sulle modifiche prima di stashconfermarle , allora potrebbe essere lo strumento giusto per il lavoro.)

— Cascabel

"Il cambio di ramo porta con te modifiche non vincolanti" - Questo ha senso e forse è la peggiore idea di design. Che senso ha avere rami se non puoi lavorare in modo isolato? !!!

— nehem

Nel mio caso, ho un ramo di funzionalità da un ramo di sviluppo. Ho eseguito il commit nel feature branch ma mostra i cambiamenti anche quando eseguo il checkout nel ramo di sviluppo.

— Hitesh Garg

Risposta breve: sì, devi impegnarti. Assicurati di farlo sul ramo giusto, però!

Un ramo è un puntatore a un commit. Quando si esegue il commit con un ramo estratto, il ramo avanza per puntare a quel nuovo commit. Quando estrai un ramo, stai controllando il commit a cui punta. (Puoi pensare ai commit come istantanee del tuo albero di lavoro.)

Quindi, se hai modifiche che non hai commesso, non saranno influenzate dal cambio di ramo. Ovviamente, se cambiare ramo è incompatibile con le tue modifiche, git checkoutsi rifiuterà semplicemente di farlo.

git addè un comando per la gestione temporanea delle modifiche, che verrà poi eseguito il commit. Non registra tali modifiche nella cronologia del repository. Li colloca semplicemente in un'area di staging (l'indice); git commitquindi utilizza i contenuti di quell'area di staging per creare commit.

— Cascabel
fonte