The branching strategy we use at ZoeCity is similar to the git-core repository itself (I think).
It roughly looks like this: 1. Develop everything in master. 2. Staging is pushed from master. 3. Production-worthy? Tag it as a x.0.0 release against master. 4. Create a branch called 'maint' from that same tag. 5. Further work happens in master (bug fixes + new features) 6. Bug fixes are cherry-picked into 'maint' after they are tested in staging (via a master push) 7. Enough fixes in maint? Tag it as a x.0.1 release againt maint. Push to production. The iffy part is step 6 where cherry-picking can be slightly difficult. To make things slightly manageable, we include the bug ID in the commit message. There will be times when additional remote branches are created especially when more than one developer is working on a topic branch. But these are rebased into master after they are sufficiently stable and the remote branch deleted. Regards, kamal --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to github@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
