At my work we keep all of our monitoring scripts inside a git repo. There's a small team of people that make updates and there's one lead (me). We do releases every month.The branches and workflow are setup as follows:
master -> this is everything as it currently exists in the production environment
monthly -> everything that is going to be in the next monthly release ends up here
The rules are as follows:
- Nothing gets merged into master EXCEPT by the lead, and ONLY after the completion of a monthly release
- monthly MUST always be in a releasable (meaning stable and tested) state. This is imperative in the event we have to do an emergency release to fix a critical bug
- As a result of number 2, all development is done in a branch (our method makes no distinction between feature branches and fix branches)
- After whatever is being worked on is ready to be merged into monthly, a pull request is sent to the lead, who reviews the changes and either accepts or rejects them. If accepted, the changes get merged into monthly and will be included in the next release
- I dislike merge commits, so before merging into monthly I always rebase off monthly then merge so it's a fast-forward. This also lets me deal with conflicts in a branch that isn't one of the two critical ones which is ideal
Before settling on the above model, I reviewed a number of git branching models including git-flow and Scott Chacon's description of how things are done at github. I decided though that neither of those models really worked very well for how we do things at my place of employment. Incidentally, if you haven't read the posts describing git-flow and Scott Chacon's post about github you should, they're very informative. You can find the post describing git-flow
here and Scott Chacon's post
here.
In the end the method used by my team is closer to how they do it at github, though we don't do the immediate deployment that they do, and there's only one person who reviews the changes instead of a group of people.