-
develop
origin:
staging
what: Releases in development. Only mergeable via Pull Request
-
staging
:origin:
master
what: This branch receives patches from
develop
branch as release candidates and is supposed to be stable code, with proper version number, to final tests on an mirror to production environment; -
master
:what: This branch runs stable code and is directly related to production. Every push in this branch sends this code version to production;
$branchType/$branch-description
Branches we write in English. It's just convention.
fix
: fixes a bug;feat
: adds a new feature;refactor
: refactors/improves an existing feature;chore
: config changes, tools/libraries updates, builds adjustments and so forth;docs
: documentation updates, no production code updated.
A short trace separated message describing what is being developed.
feat/user-preferences
refactor/product-creation
fix/organization-update
chore/remote-signer-secrets
feat/user-preferences-fields-with-validations
: too long, specifications should be in commitsrefactor/product
: too short and doesn't say anything about what is being refactoredfix/add-new-user
: it's ambiguous, we should take care to do not looks like the type is not related to its actionfeat-user-preferences
: out of convention, thefeat
type anduser-preferences
description should be separated with slash/
.
$action($scope): $commitTitle
$commitBody
Commits we write in English. It's just convention.
Action type made in the commit in context:
fix
: bugs fixes;hotfix
: critical bug fixes passive to be sent to main branches (see Main Branches section) without a Pull Request;refactor
: refactoring or improving existing features;chore
: Config changes, tools/libraries updates, builds adjustments and so forth;test
: Add missing tests or refactoring tests; no production code change;docs
: changes or increments to the documentation;style
: formatting, missing semi colons, etc; no production code changed;feat
: when it adds a new feature or belongs specifically to a feature development and it's not related to any fix, hotfix, refactor or chore in the application.
The scope you're working on. Good examples of scope are:
- user
- database
- config
- proxy
- server-init
The first line cannot be longer than 70 characters, the second line is always blank and other lines should be wrapped at 80 characters. The type and scope should always be lowercase as shown below.
- uses the imperative, present tense: "change" not "changed" nor "changes"
- includes motivation for the change and contrasts with previous behavior
Pull Requests we write in Portuguese, since it's our primary language and it makes easier to everyone understand what's being released.
First thing in a Pull Request title is its prefix.
[$ACTION] $message
The possible actions are:
FIX
HOTFIX
FEAT
REFACTOR
DOCS
CHORE
A simple message of this Pull Request as its title. It must be concise and short.
[FIX] Organization Resources loading
It's the release note of this Pull Request. It must be detailed but not lengthened. If you can make it short then do it. Just think it's a message that everyone must understand, from programmers to non-programmers.
The last line of the Pull Request body you place a footer information for relating to the issues it's related and can be closed, like:
Closes #234
In case of multiple issues:
Closes #453, #567
Create your branch → Build and commit → open a Pull Request to develop
branch → deliver
https://karma-runner.github.io/1.0/dev/git-commit-msg.html
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
https://www.conventionalcommits.org/en/v1.0.0-beta.3/
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase