branch vs. cherry-pick workflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]