branch vs. cherry-pick workflow

branch vs. cherry-pick workflow

[jshalvi]

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.

Re: branch vs. cherry-pick workflow

[Sitaram Chamarty]

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