Branching model
For the team we will be using the branching model described here. You should take some time and read it carefully. Essentially, this means that on each branch you will be working on a single functionality.
You can create a new branch by using the command:
TL;DR:
In origin:
kinetic
- the stable branch.devel
- the development branch, where approved merge requests are integrated.release-X.Y
: the release branch, where preparations are made right before merging intokinetic
.
In your remote:
feature/[meta]/name-of-feature
: New functionality that will be added to the robot.fix/issue-NNN
: Fixing a bug that was found in existing code.Where [meta] will refer to the metapackage where your feature or bug belongs.
Features
Naming Convention:feature/[meta]/name-of-feature
Where [meta] will refer to the metapackage where your feature will be included:
manipulation
navigation
perception
planning
speech
scenario
Some basic rules:
Every feature gets its own branch.
Branches off from
devel
Merges into
devel
To create a feature branch:
To merge a feature branch:
Make sure you have the latest changes in devel
Merge devel into your branch
Update the changelog:
Create a merge request using the web version of gitgate.
Once your merge request is accepted, delete your branch
Bug fixes
Naming Convention: fix/issue-NNN
Where NNN is the issue number reflecting the bug.
Some basic rules:
Every bug gets its own branch.
Branches off from
kinetic
Merges into
kinetic
anddevel
To create a fix branch:
Work on your bug fix and commit your changes. When you have tested and have satisfactory results, create merge requests to both kinetic
and devel
:
To merge a fix branch, first update the changelog:
Create a merge request for
kinetic
using the web interface of gitgate. <!--3. Once it is approved, the version number needs to be updated:-->
Finally, create a merge request either in the release branch (if it exists) or in
devel
. Note: DO NOT merge on both.Once your merge request gets accepted, delete your branch.
Release branches
Naming Convention: release/X.Y.Z
Where X represents a major release, e.g.
migrating to a new ROS version
code integrated after a competition
code from several R&D and theses projects, usually at the end of a semester
And Y represents a minor release, e.g.
a single R&D project or thesis
a significant improvement in a functionality
a new scenario
This will only take place on the stable repository, not on your remote. Some basic rules:
Branches off from
devel
Merges into
kinetic
anddevel
To create a release branch:
During the next two months after the release, regular testing needs to take place and any bug fixes need to be taken care of. After the release is stable enough, it will be merged back into indigo
. If you have read this far, send me an email with a picture of your favorite robot to get a candy after our next meeting.
To merge a release branch, first update the changelog:
Then merge back into kinetic
and devel
In case of merge conflicts or issues (most likely because of the change in version number), fix them, commit your changes and then delete your branch:
Pull requests
Take a look at the merge request diagram here.
See also
Last updated
Was this helpful?