[ros-users] [Discourse.ros.org] [Quality Assurance] On (git) branching strategies

Carlos J Rosales Gallegos ros.discourse at gmail.com
Wed May 16 14:40:08 UTC 2018

Thanks for your inputs.

[quote="gavanderhoorn, post:2, topic:4785"]

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

[quote="gavanderhoorn, post:2, topic:4785"]

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.


[quote="gavanderhoorn, post:2, topic:4785"]

most repositories is a rather vague statement, which makes it hard to verify. I know you didnt 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 dont 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](https://github.com/ros-controls/ros_controllers/pull/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`](https://github.com/ros-controls/ros_controllers/commits/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.

[quote="de-vri-es, post:3, topic:4785"]

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.

[quote="simonschmeisser, post:4, topic:4785"]

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.


[Visit Topic](https://discourse.ros.org/t/on-git-branching-strategies/4785/5) or reply to this email to respond.

More information about the ros-users mailing list