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