Geoff the Medio wrote:What I'd like is further clarification of the standard use of branches for releases in git, specifically relating to release-specific changes that wouldn't make sense to merge back to master.
There is no exact way git enforces or even suggests how to handle release branches. The decision itself how to or not to do release branches right/at all is up the specific project. The opinions I mentioned so far are just, well, my opinions. And I'm honest here: I'm stating my experience with projects, that are/were smaller than FreeOrion in size and number of committers, but they served me well so far. It can be very true that these experiences just don't work for FreeOrion. But that's something only time can tell.
Geoff the Medio wrote:I assume there's more reasoning behind what adrian_broher suggests that I haven't read yet.
This is a bit offtopic, but I can tell you my point of view here. I generally have the feeling (and yes, it's mainly a gut feeling without any hard facts supporting it) that when we (or any other software development team) need release-specific changes we failed at some point in designing the application or build system properly. In my opinion every commit should be (in theory, practice shows that this isn't possible) a potential release or release candidate, mind the lurking bugs of course. When we need to prepare the software in any way to make it release ready, this excludes squashing bugs, this also means that theses steps need to be repeated on every release properly, which is just another point of potential failure. And the other commits are things, bug fixes and updated documentation, that should and must be shared between the main development branch and the release branch. So merging back release branches only seems a sensible choice to me.