On (git) branching strategies

[carlosjoserg]

Thanks for your inputs.

@gavanderhoorn

…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.

True, so it seems like it worth the discussion.

@gavanderhoorn

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.

@gavanderhoorn

“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.

I couldn’t query github by branch names, since only the default branch is indexed, though that wouldn’t explain the strategy either. And if you consider that other platforms like bitbucket or gitlab are also used, yes, I agree it is really hard to verify. However, I think we can agree that it is a very common practice in ROS repositories to use the first strategy, for either trunk or leaf projects, otherwise there wouldn’t be point to talk about, right?

I didn’t want to point at repositories because I wanted to be abstract about the discussion. But certainly examples help to illustrate the issue, and support the statement: “it can happen”. I already gave you one example on the ros_comm repository.

And, with all due respect to maintainers, just happened in the ros-controls project too, for instance: PR#335 just got merged on kinetic-devel with a new feature that would be good to have in further releases. And the melodic-devel branch is already there. So the melodic-devel branch does not have this commit, it will need to be added manually at some point, or a rebase of the melodic-devel branch too, which in this strategy is not a good idea either, I believe.

@de-vri-es

The correct devel branch changes all the time. With most non-ROS projects the workflow for making a PR is simple: update master, branch off, fix stuff, send PR. With most ROS projects you first have to check what the right devel branch is to split off from…

Precisely my question: Why don’t ROS projects choose the simple version? Which IMO is not only good to lower the barriers for new devs as you say later, but it is also safer.

@simonschmeisser

But I think this is mainly a communication issue, not a work flow or organizational one.

Also true, but what I’m interested in is on what are the benefits of using the first strategy above, because on the contrary, I think is not safe for the issue I illustrated before.