>> If we find bugs during pre-release testing, we fix them on release, then immediately merge release back on to master
As a self diagnosed Aspie, I can't tell if this article or your comment are April 1st jokes. Which I guess is kind of the point of April 1st jokes.
Meh. That seems sensible to me, I guess, if it's something that the developer will guarantee won't change anything (eg. a typo in a translated string). I think "automatically" generated commits like this should clearly be marked as such so if something does go wrong, it's possible to place the blame.
Back in days of yore, we decided to ship and updated the copyright string in the .text section of the product binary - from "Copyright 1989 SMI" to "Copyright 1991, Sun Microsystems", which subsequently changed the alignment of other sections and led to a 10% performance penalty (fixed by regenerating the order file.)
I've never thought there was such a thing as safe fix ever since...
Yep. Except note that it won't merge from `release` to `master`, because the script doesn't know whether you guys pushed other commits to `release` that you don't want to have on `master`. So it'll push just the source commit to both `release` and `master`.
One project i work on has two branches, master and release. We develop on master, then branch release from master when we want to make a release. If we find bugs during pre-release testing, we fix them on release, then immediately merge release back on to master. Note that this ensures that master is always a descendent of release, which means it's always safe to re-branch release. We don't use named feature branches; we make commits straight to release (and master). Could we use git-cascade to automate the immediate merge from release back to master?