-
Notifications
You must be signed in to change notification settings - Fork 2
Git workflow
Personal branches are the place for the development of new features, hot fixes, etc. and their unit tests. Developers push their commits in these branches, nowhere else.
The integration branches receive the merges from personal branches. They reflect the head of the development of the software, the place for the integration testing. No one should push directly into the integration branches
The master branch always represents the last production/maintenance, stable release (not the developement release such as alpha, beta and rc releases). We should not push any commit in the master branch. We should only merge commits, from the current integration branch, that contributes to the last production/maintenance release. Personal branches, development tags, even integration branches may be deleted. So don’t forget to merge commits on the master branch at every production/maintenance cut. The master branch must never been deleted.
Every release (alpha, beta, rc and of course production/maintenance release) should be tagged so as we can track back the code.
As tags and releases are equivalents, the tag names have exactly the same syntax. Production/maintenance tags must never been deleted. Development tags, alpha, beta and rc releases, may be deleted. Production tags are made from the master branch whereas development tags are made from integration branches. Signing the git tag for the production/maintenance releases will improve the security. We should be careful to never make gaps in the version numbering.
-
The integration branch name syntax is int_X.x where X represents the major version of the software in development. Example: int_2.x for any version v2.x.y
-
The personal branch name syntax is dev_X.x_[PersonalTag] where where X represents the version of the software in development and [PersonalTag] an unique tag that is specific to a developer.
Developers work on their own development branches and the unit tests must be executed in the development branches so as to prevent failures as much as possible. Every time the developers need to merge their contributions into the current integration branch, the following procedure applies:
- Checkout the development branch.
- Merge the integration branch into the devevelopemnt branch so as to update the development branch.
- Run the unit tests in the developement branch. If they pass, continue.
- Push to the remote development branch
- Checkout the integration branch
- Merge the development branch into the integration branch.
- Push to the remote integration branch.
- Tag the integration branch, eventually.