2016-03-05 33 views
6

Sto cercando di aiutare un collaboratore a capire che cosa ci fosse un mucchio di avvertimenti di "vuoto commit" nella sua recente unione. Ho aperto gitk, e ho visto qualcosa di simile:In che modo questi commit di git sono stati duplicati nel ramo sbagliato?

_o (Z) Merge branch 'new-branch'        (yesterday) 
o | (Y) Fix bad merge           (person 1) 
o_| (X) Merge branch 'master' into new-branch     (recent) 
o | (W) Last legitimate commit that belongs on new-branch  (person 1) 
| |  ... work on master ... 
o | (F) Legitimate commit that actually belongs on new-branch (person 2) 
| |  ... work on master ... 
o | (E) Legitimate commit that should have been on master  (person 2) 
o | (D') Even more work etc...        (committed by person 2) 
o | (C') More work in master         (committed by person 2) 
o | (A') Normal work in master        (committed by person 2) 
| o (D) Even more work etc...         (authored by random person) 
| o (C) More work in master         (authored by random person) 
o | (B) Starting to work on new-branch      (person 1) 
|_o (A) Normal work in master         (authored by random person) 
o Common Ancestor            (weeks ago) 

Così, ovviamente, le due persone che lavorano su questo ramo dovrebbero si sono fuse dal maestro nel loro ramo più spesso, e quindi queste pile di avvertimenti di unione sarebbe stato più evidente . Il membro del team il cui nome era nel campo di comunicazione dei commit duplicati dice che probabilmente ha fatto un pull -rebase per causarli, ma non riesco a capire come potrebbe funzionare. Qualcuno può spiegare cosa potrebbe essere successo?

Non sto cercando un modo per correggere gli avvisi di unione, poiché sembravano benigni. Voglio solo capire cosa è successo in modo da poter evitare che accada in futuro. La mia squadra è relativamente nuova da git, quindi sto cercando di aiutarli a capirlo un piccolo passo alla volta, usando per lo più prove ed errori.

Grazie!

+0

E 'possibile che abbiano fatto delle scelte di ciliegie? – jeerbl

+0

Ne dubito. Quello che ho semplificato a 4 commit errati era in realtà più simile a 15.Mi sento come se ricordasse che la ciliegia ha raccolto 15 commit. Grazie per averlo sollevato come una possibilità! –

+0

Quando si aggiorna il ramo di funzionalità con il master, accertarsi di rebase invece di unire il master. Questo essenzialmente prende il master attuale e seleziona tutte le modifiche delle caratteristiche su di esso. – lorengphd

risposta

1

Quando si esegue un rebase su un ramo, si riscrive la cronologia di quel ramo. Tutti i commit interessati avranno i loro ID modificati almeno (anche se non ci sono stati cambiamenti di contenuto all'interno del commit). Per questo motivo, potrebbe sembrare come se si stessero commettendo duplicati, cosa che in realtà non è possibile. Hai due commit diversi con lo stesso contenuto.

Il modo di riprodurre questo comportamento di "duplicazione commit" è in genere eseguire un rebase di un ramo che è già stato inviato a un repository remoto e quindi unirlo nuovamente allo stesso ramo remoto. Il rebase cambierà gli ID dei tuoi commit e l'unione manterrà entrambe le coppie di commit "duplicati", anche se le loro modifiche produrranno lo stesso contenuto.

  1. Nella vostra repository esistente, creare un nuovo ramo "caratteristica" dal ramo "master": git checkout -b feature
  2. aggiungere un nuovo file "file feature.txt" e si impegnano sul ramo "caratteristica" : git add . ; git commit -m "added new file on master branch"
  3. Passare al ramo "master" e aggiungere un altro nuovo file lì e si impegnano anche questo: git checkout master ; git add . ; git commit -m "added new file on master branch"
  4. Spingere al ramo della funzione sul repository remoto: git checkout feature ; git push --set-upstream origin feature
  5. Ora, effettuare un rebase del ramo "feature" sul ramo "master": git rebase master
  6. Se si tenta di trasferire questo ramo "funzione" all'archivio remoto, verrà visualizzato un errore che è necessario eseguire "git pull" primo. Questo è il punto in cui ottieni effettivamente i tuoi commit "duplicati", a causa dell'unione (git pull è una scorciatoia per git fetch ; git merge), ricorda anche che il contenuto dei commit è lo stesso, ma a causa del rebase del branch, gli ID dei commit sono diversi ora e quindi sono considerati come una cosa diversa, quindi: git pull
  7. Controlla la tua filiale ora in una GUI, con "git gui" (vai al menu principale - Archivio - Visualizza la cronologia della funzione) e vedere qualcosa del genere: enter image description here
  8. o semplicemente usare git log per vedere direttamente nella riga di comando: enter image description here