Unisci il monitoraggio per la raccolta di ciliegie Git?

Question

Ad esempio, ho un ramo dev e un ramo stable.

Nel caso in cui sono stati selezionati diversi commit da dev a stable.

C'è un modo per far conoscere a Git i commit raccolti con ciliegie, ed evitare di unirli in modo doppio se in seguito unisco, rebase o cherry-pick un intervallo sovrapposto, da dev di nuovo a stable? (Per la quale è una fusione di base di monitoraggio funzione in SVN)

Answer 1

V'è in realtà un comando chiamato git cherry che stampa ogni commit che non si fonde tra due rami.

Per ogni commit stampato, il segno "+" significa che è possibile unirlo, il segno "-" significa che si seleziona già quel commit.

L'output è lungi dall'essere bello.

Per coloro che sono venuti da SVN e vengono utilizzati per svnmerge.py, ho fatto una "inutilmente svnmerge -l" script bash equivalente per git, che ho chiamato gitavail:

#!/bin/bash 

# get current branch 
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) 

# get tracked branch (1st argument), if no arg or arguments are only options, assume master 
if test -z $1 || grep -q '^-' <<< $1; 
then TRACKED_BRANCH=master 
else TRACKED_BRANCH=$1; shift 
fi 

# Log commits available for merge from tracked branch 
LOG_OPTIONS=$* 
for i in $(git cherry $CURRENT_BRANCH $TRACKED_BRANCH | egrep '^\+' | awk '{print $2}'); do git --no-pager log -n1 $i ${LOG_OPTIONS}; echo; done 

supponendo che si sta su un ramo, e si desidera elencare ciò che è ammissibile per unire dal ramo principale, basta eseguire:

gitavail --name-status 

e avrete un output molto simile a "inutilmente -l svnmerge".

Immagino che i commit di cherry-pick non debbano essere modificati manualmente (per quanto riguarda i conflitti?), Se le modifiche patch id, git cherry non si renderanno conto che il commit è già stato selezionato.

Answer 2

git cherry-pick è un caso divertente di git rebase piuttosto che git merge, in modo che riscrive in realtà il commit si ciliegia scelto in modo che applicare le stesse modifiche alla parte superiore del ramo hai scelto la ciliegia. Poiché gli ID commit di git sono basati sul contenuto del commit, il nuovo commit ha un ID diverso e pertanto è considerato un commit completamente diverso da git.

git merge, d'altra parte, crea un merge merge; questo è il modo con cui gli attrezzi git si fondono. Un commit di unione segna un punto in cui convergono due (o più) storie divergenti. È possibile chiamare git merge [commit-id] anziché git cherry-pick [commit-id] per creare in modo esplicito un commit merge, ma ciò comporta non solo gli effetti del singolo commit cherry-picked, ma anche l'intero set di modifiche nella cronologia divergente di quel ramo.

Con tutto ciò che detto, "doppia fusione" di solito non è un problema in git. Se provi ad unire con una cronologia che contiene un changeset già presente, diventerà un no-op quando le storie sono incollate insieme; a Git interessa davvero solo lo stato dell'albero in ogni commit, non i cambiamenti che lo hanno portato in quello stato.

Answer 3

Notevole anche che il flag -x per cherry-pick aggiunge lo SHA del commit originale alla fine del messaggio di commit.

Mi piace aggiungere lo SHA abbreviato alla fine del riepilogo di commit, per semplificare l'associazione del commit selezionato con l'originale quando si guarda il registro. Può essere d'aiuto anche indicare chi ha fatto la scelta migliore, con il flag di interruzione -s.

Esempio:

> git cherry-pick -sex 27d4985

#333: fixes all the things (27d4985) 

- how it fixes all the things 

(cherry picked from commit 27d49855238364d0184ad344884a366b5b16e) 

Signed-off-by: Chuck Norris <chuck@example.com>