Viene creato un nuovo ramo da master
, lo chiamiamo test
.
Ci sono diversi sviluppatori che si impegnano in master
o creano altri rami e poi si uniscono a master
.
Diciamo che il lavoro su test
sta durando diversi giorni e si vuole tenere continuamente aggiornato test
con i commit dentro master
.
Farei git pull origin master
da test
.
Domanda 1: Questo è l'approccio giusto? Altri sviluppatori avrebbero potuto facilmente lavorare sugli stessi file che ho lavorato io btw.
Il mio lavoro su test
è finito e sono pronto a fonderlo di nuovo su master
. Ecco i due modi che mi vengono in mente:
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
Non sto usando --rebase
perché da quanto ho capito, rebase otterrà le modifiche da master
e impilerà le mie sopra di esse, quindi potrebbe sovrascrivere le modifiche fatte da altre persone.
Domanda 2: Quale di questi due metodi è giusto? Qual è la differenza?
L'obiettivo in tutto questo è mantenere il mio ramo test
aggiornato con le cose che accadono in master
e più tardi potrei unirle di nuovo in master
sperando di mantenere la linea temporale il più lineare possibile.
Come lo farei
git checkout master
git pull origin master
git merge test
git push origin master
Se ho un ramo locale da uno remoto, non mi sento a mio agio nel fondere altri rami oltre a questo con quello remoto. Inoltre non vorrei spingere i miei cambiamenti, fino a quando non sono soddisfatto di ciò che voglio spingere e anche io non vorrei spingere le cose, che sono solo per me e il mio repository locale. Nella tua descrizione sembra che il test
sia solo per te? Quindi non c'è motivo di pubblicarlo.
git cerca sempre di rispettare i tuoi e gli altri cambiamenti, e così farà --rebase
. Non credo di poterlo spiegare adeguatamente, quindi dai un'occhiata a il libro Git - Rebasing o git-ready: Intro into rebasing per una piccola descrizione. È una caratteristica piuttosto interessante
Questa è una domanda molto pratica, ma tutte le risposte precedenti non sono pratiche.
Come
git checkout master
git pull origin master
git merge test
git push origin master
Questo approccio ha due problemi:
Non è sicuro, perché non sappiamo se ci sono conflitti tra il ramo di prova e il ramo master.
Si "spreme" tutti i commit di test in un unico merge commit su master; cioè sul ramo master, non possiamo vedere tutti i log di cambiamento del ramo di test.
Quindi, quando sospettiamo che ci siano dei conflitti, possiamo avere le seguenti operazioni git:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Prova merge
prima di commit
, evita un commit veloce con --no-ff
,
Se viene riscontrato un conflitto, possiamo eseguire git status
per controllare i dettagli dei conflitti e provare a risolvere
git status
Una volta che abbiamo risolto i conflitti, o se non ci sono conflitti, commettiamo
e push
.
git commit -m 'merge test branch'
git push
Ma in questo modo si perde la storia dei cambiamenti registrati nel ramo di test, e renderebbe il ramo master difficile per gli altri sviluppatori capire la storia del progetto.
Quindi il metodo migliore è usare rebase
invece di merge
(supponiamo, quando in questo tempo, abbiamo risolto i conflitti di ramo).
Di seguito è riportato un semplice esempio, per le operazioni avanzate, fate riferimento a http://git-scm.com/book/en/v2/Git-Branching-Rebasing
git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
Sì, quando hai fatto il rebasing, tutti i commit del ramo Test saranno spostati sulla testa del ramo Master. Il vantaggio principale del rebasing è che si ottiene una storia del progetto lineare e molto più pulita.
L'unica cosa da evitare è: non usare mai rebase
sul ramo pubblico, come il ramo master.
Non fare mai operazioni come le seguenti:
git checkout master
git rebase -i test
Dettagli per https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
appendice:
Né un rebase né un merge dovrebbero sovrascrivere le modifiche di qualcuno (a meno che non si scelga di farlo quando si risolve un conflitto).
L'approccio abituale durante lo sviluppo è
git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
Quando si è pronti per il merge in master,
git checkout master
git log ..test # if you're curious
git merge test
git push
Se sei preoccupato di rompere qualcosa durante il merge, git merge --abort
è lì per te.
Usare push e poi pull come mezzo di fusione è stupido. Non sono nemmeno sicuro del perché stai spingendo test a origin.