Git workflow & review process
This page presents the global workflow for contributing to to be continuous development.
All original contributions to to be continuous are licensed under the GNU Lesser General Public License, version 3.0 or later.
All contributions are subject to the Developer Certificate of Origin (DCO). The DCO is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project.
Contributors must sign-off that they adhere to these requirements by adding a
Signed-off-by line to commit messages, as shown below:
This is the commit message Signed-off-by: John Dev <firstname.lastname@example.org>
Git has a handy
-s command line option to append this automatically to your commit message:
$ git commit -s -m 'This is the commit message'
Contribute to an existing template
All submissions, including submissions by project members, need to be reviewed before being merged.
- Create an issue describing the bug or enhancement you want to propose (select the right issue template).
- Make sure the issue has been reviewed and agreed.
- Create a Merge Request, from your own fork (see forking workflow documentation).
Don't hesitate to mark your MR as
Draftas long as you think it's not ready to be reviewed.
- When merged, a new release will be performed.
Initial release of a new template (advanced)
- Start posting a message with topic
New template: bla blaon the to be continuous Google Group, and present the scope and goal of your template.
- If agreed by the core team, a new project will be created from template skeleton
with private visibility in the to be continuous GitLab group. You'll be granted
developeraccess to it.
- Fork the project to your own space, select the right
initial-xxxbranch to start from (depending on the kind of template you're developing).
- As soon as you like, create a Merge Request to the original repository in Draft mode.
- You may ask for help, advices and reviews anytime during your development process.
- Once you think your template is ready, mark it as Ready and ask for a review.
- An initial development shall be reviewed and approved by at least 2 other contributors from the core team.
- When approvals are met: the MR can be merged, and an initial release will be performed.
- Then the project visibility is changed to public, and your template becomes official .
The release process is based on semantic-release.
As a result, releases are performed automatically when commits on the
master branch indicate a new release is required (see below).
Git Commit Guidelines
Commits in your merge requests should be atomic and semantic.
- Please properly squash your merge requests before submitting them.
- Fixup commits can be used temporarily during the review process but things should be squashed at the end to have meaningful commits.
- If you need help to do that, just ask :)
We are using semantic-release to manage our template releases.
This nice tool automatically takes care or version management, package publishing and release note generation, based on Commit message syntax.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitLab as well as in various git tools.
If the commit reverts a previous commit, it should begin with
revert:, followed by the header
of the reverted commit.
In the body it should say:
This reverts commit <hash>., where the hash is the SHA of the commit
Must be one of the following:
||A new feature||minor|
||A bug fix||patch|
||Documentation only change(s)||none|
||Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)||none|
||A code change that neither fixes a bug nor adds a feature||none|
||A code change that improves performance||none|
||Adding missing or correcting existing tests||none|
||Changes to the build process or auxiliary tools such as doc. generation, CI/CD||none|
breaking changes shall be mentionned in the footer by prefixing line(s) with
The scope is optional and it could be anything specifying the place of the commit change. For example
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitLab issues that this commit closes.
breaking changes should start with the word
BREAKING CHANGE: with a space or two newlines.
The rest of the commit message is then used for this.