Qual è il modo migliore (e più sicuro) per unire un ramo Git in master?

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:

1. Non è sicuro, perché non sappiamo se ci sono conflitti tra il ramo di prova e il ramo master.

2. 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:

• se non siete sicuri delle operazioni di rebasing, fate riferimento a: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

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.