Git policy: git merge or git cherry-pick

Lukast dev lukast.dev at gmail.com
Mon Jan 31 13:27:50 GMT 2011


Hello,

I would like to have your opinion about the preferable and consistent way of
merging of the code from the features branches we have into master.

There are more ways:
1. git cherry-picking
a) cherrypick single commits
b) produce one squashed patch for master and commit it

2. git merge

We discussed about it a little, but I think we need more arguments for the
decision.

boud:
o cherry-picking gives the nicest history I think
about merge
o but then the development branch should never be deleted, otherwise
we have one big commit that nobody can every bisect anymore and never
figure out the history of
o if you are going through master trying to find a particular commit
that broke something -- you get big mega commits again

sebsauer:
o cherry-pick'ing is useful if you have only 1-2 commits you like to
take over else, if you like to take over a range or everything, then
just merge. That's at least how I do it :)

Zagge:
o git merge

CyrilleB
o personnaly I go for merging
o then in the master history you get one commit that correspond to the
new feature, and if you want more details you can follow the history
of that commit
o boud: I'd still like the commit message to have the log, though
(example git merge --log origin/words-toc-korinek-tvrdy )

slangkamp
o rebase should also be possible in some cases


Jan, how did you merged your gluepoints branch?



More information about the calligra-devel mailing list