Come gestirlo quando un commit in-progress sembra improvvisamente dipendere da un altro che non esiste ancora?

Question

Come gestirlo quando un commit in-progress sembra improvvisamente dipendere da un altro che non esiste ancora?

#1 da (17 voti)
#2 da (5 voti)

13

Non ho esperienza con Git, ma faccio del mio meglio per abituarmi, e finora lo sto usando solo per progetti su cui lavoro da solo.

Quando eseguo il codice, c'è un approccio top-down in modo naturale (poiché non posso conoscere il futuro), e c'è un tema ricorrente:

Faccio un po 'di lavoro.
Scopro che per trasformare il mio lavoro in qualcosa di "impegnativo" ho bisogno di fare altro lavoro.
L'altro lavoro merita il proprio commit.

Per qualcosa di commettibile intendo qualcosa che compila o qualcosa che non è un casino totale.
E per qualcosa che merita il proprio impegno mi riferisco a quello che ho imparato che i commit dovrebbero fare solo una cosa.

Il modo in cui lo risolvo è complicato. Se l'altro lavoro si trova in un altro file, creo un nuovo ramo, eseguo il commit e unisco. Se il lavoro si trova nello stesso file .. ugh .. Realizzo una copia locale e reimposta il file nel suo stato in HEAD, apporta il commit necessario e quindi inizia a ripristinare il mio lavoro dalla copia. Come dovrei effettivamente gestirlo? Non immagino che sia così, vero? Non lo presumo, perché deve venire un po 'spesso a tutti (anche quelli che non conoscono il futuro). O forse sembra che il mio flusso di lavoro sia probabilmente difettoso?

git

posta MasterMastic 14.11.2015 - 13:59

fonte

2 risposte

5

Se usi una GUI per Git, come SourceTree di Atlassian, o git gui , puoi commettere parti di file e lasciare le altre parti senza commit. In effetti, puoi impegnare singole righe di codice.

Lo faccio spesso quando cado nelle fosse dei conigli come descrivi tu. Questo è un ottimo modo per rendere quel commit o commit sensibile come precursore del commit principale.

Puoi farlo dalla riga di comando, ma è un po 'maldestro.

Quando puoi impegnarti a livello di patch Git e linee individuali, non devi creare nuovi rami, stash, commit, stash e unisci. Continua a lavorare e non interrompere il flusso. Hai una buona idea.

risposta data 15.11.2015 - 02:20

fonte

Leggi altre domande sui tag git

Perché ES6 non ha funzioni di freccia sottile? Perché utilizzare string.Empty over "" durante l'assegnazione a un oggetto stringa

score 17 · Accepted Answer

Ci sono diversi modi per risolvere questo problema.

Se desideri apportare le modifiche per il primo commit senza interferire con le modifiche correnti, potresti voler utilizzare git stash . Ciò metterà via tutte le tue modifiche aperte, consentendoti di ripristinarle in un secondo momento. Usa git status per vedere che non sono più presenti. Ora crea il primo commit come sei abituato. Successivamente puoi utilizzare git stash pop per ripristinare le modifiche originali e creare il secondo commit, eseguendo il tuo lavoro principale.

Un altro modo sarebbe quello di fare tutte le modifiche richieste e quindi creare due commit, entrambi contenenti una parte del tuo lavoro. Per fare ciò è possibile utilizzare l'indice (noto anche come area di staging) fornito da git. Questa è un'area speciale che puoi usare per preparare i commit. Supponendo di aver modificato più file, è possibile aggiungerli all'indice utilizzando git add . Quando si esegue git commit , verranno impegnati solo i file aggiunti all'indice. git status ti mostrerà quali parti delle tue modifiche saranno confermate e quali no. Ad esempio, apparirà in questo modo dopo aver modificato i file a.txt, b.txt e c.txt e in seguito facendo git add a.txt :

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   a.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   b.txt
        modified:   c.txt

Quando stai facendo git commit in questo stato, solo le modifiche ad a.txt verranno aggiunte al tuo commit.

In aggiunta puoi rivedere le esatte modifiche da impegnare utilizzando git diff --cached , che ti mostrerà una differenza tra tutte le modifiche che verranno sottoposte a commit.

Se un file contiene modifiche per entrambi i commit, puoi anche aggiungere solo parti di esso all'indice usando "git add --patch b.txt". git ti fornirà una modalità interattiva che ti chiederà ogni cambiamento nel file dato se dovrebbe essere aggiunto all'indice. Questo potrebbe essere più difficile se si hanno delle modifiche nelle linee una accanto all'altra, che devono essere divise nei due commit, tuttavia ci sono modi per risolvere anche questo.

Se vuoi saperne di più sull'area di staging potresti voler leggere questo: link

Potresti anche voler leggere di più sull'aggiunta interattiva qui: link