Perché git fonde un ramo in se stesso?

Question

Mi sono svegliato questa mattina e ho esaminato la cronologia di commit di uno dei repository privati ​​del mio team di sviluppo su BitBucket. Ho visto questo:

Anonymous impegnata fcde879 MERGE

Merge branch 'sviluppare' di https://bitbucket.org/abc/xyz in sviluppare

Questo è, uh, un po 'insolita. La mia ipotesi era che questo fosse stato spinto da una nuova macchina che non aveva git configurato correttamente. Tuttavia, non ero sicuro del motivo per cui lo stava facendo. Su BitBucket, mostra due hash separati come commit parents, ma non ha l'opzione "view raw commit" di altri commit.

Ho controllato quel ramo, tirato e guardato il registro manualmente.

sidious@DS-1:/path/to/repo$ git log -1 --format=raw 
tree 2931d14f48e61eaf0bbe0660af5b5dd76c07f063 
parent 6bb38dee681df7620ffa42b6790641a7873166f2 
parent f59c82e19e3e79310a53e273bab78139c49ff063 
author root <root@somemachine> 1437069530 +0000 
committer root <root@somemachine> 1437069530 +0000 

Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop 

Per quanto posso dire, il genitore 6BB è sul ramo sviluppo e il genitore F59 sembra essere da un ramo diverso. È piuttosto difficile dire cosa sta succedendo.

Ho cercato ma non sono riuscito a trovare una risposta, e ho bisogno di tornare al grind, quindi ho posto la mia domanda qui: perché git fonde un ramo in se stesso? O meglio, perché questa nomenclatura viene usata come messaggio di commit?

Answer 1

Questo scenario non è inusuale.

La chiave qui è che i rami di essere fuse sono diversi: è develop ramo del repository remoto viene fusa per incorporazione in locale (di lavoro) develop ramo dello sviluppatore.

Nel repository locale dello sviluppatore ci sono due rami distinti:

• develop = Il ramo lui/lei sta attualmente lavorando. I nuovi commit vanno qui.
• origin/develop = Ciò è essenzialmente un'istantanea che il repository corrente contiene sullo stato del ramo develop sul server remoto. Viene aggiornato con le modifiche remote quando si esegue fetch o pull e con le modifiche locali dopo il successo di push.

Ora, quando si esegue git pull, accadono due cose. Questo perché git pull è essenzialmente un alias per altre due operazioni GIT: fetch e merge:

• fetch - porta tutti i nuovi commit (se presente) dal repository remoto al origin/develop ramo locale.
• merge - prende i nuovi commit e li applica al lavoro locale develop branch.Questo può avvenire in due modi:
  • se il ramo di lavoro locale non contiene la storia divergente (nuova impegna che il telecomando non conosce), poi avanza semplicemente il puntatore develop ramo avanti, fai che punti all'ultima commit in origin/develop. Questa operazione è nota come unione rapida .
  • se lo sviluppatore ha dei nuovi commit propri che non sono presenti nel repository remoto e, quindi non nel ramo origin/develop, viene eseguita un'unione regolare, il che significa che c'è un nuovo commit, contenente le modifiche da entrambi rami. Per impostazione predefinita, git assegna messaggi come questi a tali commit: Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop.

Così, lo scenario è uno abbastanza comune.

Ora, se questo accade molto spesso e non ti piace vedere grafici di cronologia di commit molto complessi contenenti commit come quello di cui stiamo parlando, prova a cercare in using rebase instead of merge.

È possibile farlo in due modi (quando ottenere le modifiche dal server remoto):

• git fetch; git rebase
• git pull --rebase

Answer 2

Il proprietario aveva alcuni commit sullo sviluppo che non avevano spinto, quindi eseguito git pull e recuperato/fuso in nuovi commit da sviluppare che erano nel repository remoto.

Answer 3

ho ricevuto lo stesso tipo di messaggio. Merge branch 'feature/customfeature' of https://mylocalrepo.com/project.git into develop e non ha ancora rotto nulla lol ... quindi non fatevi prendere dal panico. È sufficiente unire il ramo di sviluppo remoto al ramo di sviluppo locale. Fino a quando sorgono conflitti, si dovrebbe essere pronti per partire :)

Answer 4

Se si vuole evitare questo tipo di fusione scorta prima di tirare, in questo modo:

git stash 
git pull 
git stash pop