On (git) branching strategies

Thanks for starting this. It’s an interesting topic, but also one I feel is almost impossible to reach some sort of consensus on, as it appears it comes down as much to personal preference as it does to some objective measure of ‘being better’ (do a search on Git branching strategies, there are hundreds if not thousands of results.

You also described this example workflow in Proposed changes to the ROS releases - #10 by carlosjoserg and I feel it’s brought as describing a common practice, but I’m not convinced it is.

My experience is that PRs are expected to target the newest development branch and are then selected for backporting if it makes sense. PRs not targeting the latest branch will either be retargeted or rejected. At least, this is what I see in more ‘mature’ repositories. ROS being as distributed / federated as it is, this may be different for the repositories that you see often.

Managing things this way seems to already be rather close to what you are suggesting (single development line: latest branch, PRs target that by default, backporting, and “add stuff to older release branches if required”).

“most repositories” is a rather vague statement, which makes it hard to verify. I know you didn’t want to point to any repositories in particular, but perhaps this topic would become more actionable if we had at least some numbers (“only 10 out of 100 repositories examined do this” ) or specific examples that clearly don’t or do things like this.