On Tue, May 17, 2011 at 10:20 AM, Stephen Bash <bash@xxxxxxxxxxx> wrote: > That's certainly a valid approach. ÂI discussed it around the office and got push back on adding additional complexity to our branching model. ÂSo I'll document the "our" merge approach and perhaps revisit the branching model at the beginning of the next development cycle. At @work we use something like this. We have three branches: - trunk (aka master, but it started as a git-svn branch long ago...) - release - maint Our maint merges to both trunk and release, via an automated process except when a conflict requires human intervention. Occasionally someone will put something on trunk by accident that should've gone to maint. We revert it from trunk, cherry-pick to maint, and let it merge back down. (Aside, I've found hudson^wjenkins to be great for misc jobs like this and prefer it to cron these days for non-sytem-related periodic events.) j. -- 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