Sometime we had decided on a branching strategy. Basically, I'm still happy with it, but I want to suggest a small change: instead of merging from trunk/master to release branches if necessary, we should better commit to the lowest branch which needs a change and then merge upwards (it's usually best if the developer solving an issue does the merge as they can resolve merge conflicts right away). This has the big benefit, that necessary merges can't be easily forgotten. Furthermore, doing it this way results in a cleaner Git history.
Consider what this workflow would look currenly (active branches are 1.6 and master) like for a bug fix:
Code: Select all
$ cd local-git-repo
$ git checkout 1.6
. . . edit file(s) . . .
$ git commit
$ git checkout master
$ git merge 1.6
$ git push --all
If the merge would be forgotten, the next developer fixing another bug would notice that the final merge won't be as expected, and could cater to it (for instance, by notifying the other dev about the issue).
Note that this is basically the PHP Git workflow.
(Not part of this proposal, but not completely unrelated: How to Write a Git Commit Message.)