branch vs. cherry-pick workflow

jshalvi· Jul 8, 2009, 20:51 UTC · lore

our team recently switched over to git, and for months I've been happily developing on branches (as in one branch per work product/bug) and submitting those branches to our project lead to merge.

Now I'm the one that has to do the merges, and I've learned that all the other developers simply develop on their own main branch, and the project lead cherry picks commits off each developer's main branch. Except for mine, of course, which he just has to merge. They've even gone so far as to put the bug number in the commit message so the project lead knows which commit to cherry pick.

Am I crazy to think this is ass-backwards?

It seems dangerous to rely on cherry-picking like this. Are there any good technical reasons to insist on a branch/merge workflow as opposed to this commit/cherry-pick workflow? It may sound like a simple question, but everyone seems happy doing it this way... I really don't feel like trying to convince developers to wear their shirts right-side-out when wearing them inside-out gets the job done just as well for them ;)

Thanks for any insight

-- 
View this message in context: http://www.nabble.com/branch-vs.-cherry-pick-workflow-tp24399128p24399128.html
Sent from the git mailing list archive at Nabble.com.

Sitaram Chamarty· Jul 8, 2009, 22:59 UTC · re: jshalvi · lore

Re: branch vs. cherry-pick workflow

On 2009-07-08 20:51:38, jshalvi <jshalvi@gmail.com> wrote:

> It seems dangerous to rely on cherry-picking like this.  Are there any good
> technical reasons to insist on a branch/merge workflow as opposed to this
> commit/cherry-pick workflow?  It may sound like a simple question, but

man git-workflows and look at the section "MANAGING BRANCHES" gives a very nice, though brief, overview of why branching is better in general.

Regards,

Sitaram