Qual è il flusso di lavoro git giusto con rami di funzionalità condivisi?

Question

Dire che ho una filiale denominata feature che è stata diramata master. Entrambi, developer1 e developer2 checkout feature. developer1 impegna una modifica a feature e lo spinge. Quindi lo sviluppatore3 invia qualcosa a master. A questo punto, master e feature divergono, ognuna con un commit separato.

Qual è il modo giusto per ottenere le ultime da master nello feature, se sono presenti conflitti? Devo ribasare master nello feature o unirlo in?

EDIT:

Devo dire che in questo caso non vorrei riscrivere la storia su Developer2. Perché sarebbe male. Destra?

Answer 1

Considerando feature ramo è già condivisa, non dovrebbe essere rapportati master (come cambia la sua - condiviso - la storia).

Una semplice fusione master-feature sarà sufficiente (senza speculare come il motivo per cui dev3 spinto al master in primo luogo).

---

Come Adam Dymitrukcomments, questo è chiamato un "back-merge", e, a seconda del ruolo che si attribuisce a master, è lecito chiedersi: se master rappresenta lo stato di produzione stabile, si dovrebbe unire -master, non damaster.

Ma ancora una volta, la mia risposta non ha fatto supposizione su tale ruolo.

---

Questo è il motivo per il famoso git-flow illustra nelle sue blog post unioni che stanno venendo - master (da, per esempio, un ramo hotfix, come ho commented earlier)

Answer 2

il terzo sviluppatore non dovrebbe scrivere una funzionalità sul master. La rara eccezione è un hotfix. Ma anche in questo caso, dovrebbe essere il proprio ramo quindi unito a --no-ff sul master. Ho scritto un lungo post su ramo per elemento qui: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Answer 3

git è un ottimo strumento; ma, non può sostituire tra gli sviluppatori.

È necessario chiedere se le modifiche in masterdevono essere essere incluse in feature. Idealmente, un ramo di funzionalità deve avere la minima quantità di codice possibile.

Se la modifica (s) deve assolutamente essere inclusa in feature, quindi ci sono fondamentalmente due opzioni: git rebase; e, git cherry-pick.Suppongo che potresti eseguire una fusione all'indietro da master a feature; ma, ciò può portare a situazioni non buone ...

cherry-pick consente di applicare uno specifico commit o più commit all'attuale HEAD, mantenendo commenti e informazioni sull'autore. Dopo aver corretto con successo cherry-pick, git è abbastanza intelligente da sapere che i due commit sono gli stessi quando si fondono feature di nuovo in master. Se si tratta solo di alcuni commit di cui stiamo parlando, allora cherry-pick dovrebbe essere sufficiente.

rebase consente di applicare il ramo corrente (linea di commit) a partire da un punto diverso nella storia. Come hai sottolineato, questo può essere problematico per developer1 e developer2 che hanno già copie di feature. Avrebbero inoltre bisogno dello rebase del loro sviluppo locale sulla nuova filiale feature.

In ogni caso, il commit direttamente su master da sviluppatore3 avrebbe dovuto essere nel proprio ramo di funzione e quel ramo di funzione avrebbe dovuto essere unito. Quel ramo di funzione potrebbe quindi essere stato fuso in feature secondo necessità. Supponendo che solo uno (il più recente) impegnarsi in master, si potrebbe porre rimedio alla situazione come segue:

# Ensure clean working directory 
$ git stash 

# Create new branch at master 
$ git branch some-descriptive-name master 

# Move master back one commit 
$ git checkout master 
$ git reset --hard HEAD^ 

# Merge the new branch into master 
$ git merge --no-ff some-descriptive-name 

# Forcibly update master 
# YOU SHOULD COMMUNICATE WITH OTHER DEVS BEFORE DOING THIS 
$ git push -f origin master 

# Merge the new branch into feature 
$ git checkout feature 
$ git merge --no-ff some-descriptive-name 

Non posso sottolineare abbastanza quanto sia importante una buona comunicazione è perché questi tipi di "Oops" le cose possono e accadere tutto il tempo.

Buona fortuna!

EDIT:

La parte su cherry-pick ING è stata scritta con il presupposto che c'era solo un paio di commit (o solo uno) per master e che tutto sarebbe andato cherry-pick ed.

x -- y (master) 
\ 
    a -- b -- c (feature)