This branching model is based on Vincent Driessen's "[A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)," which presents an excellent visual and programmatic guide to git branching with style.
In the following examples `feature-foo` or `hotfix-foo` should be replaced with a short phase describing the feature or hotfix.
#### Feature branches
Feature branches are used to implement new enhancements for upcoming releases. A feature branch should be _ephemeral_, i.e. it should only last as long as the feature itself is in development. Once the feature is completed, it must be merged back into the `integration` to be tested. Once done, a merge request from `feature-foo` to `develop` should be made.
Consider an example in which we to implement a new feature called `feature-foo`:
Begin by switching to a new branch `feature-foo`, branching off of `develop`:
```
$ git checkout -b feature-foo develop
```
You should use `feature-foo` to implement and commit all changes required for your new feature.
- Make many small commits so that the history of development for your feature branch is clear and so that it is easy to pinpoint and edit or cherry-pick specific commits if necessary.
- Avoid merging your feature branch with other feature branches being developed in parallel. This _MIGHT_ cause a lot of problems down the line when doing a pull request to merge your feature back into the master branch.
When your feature is complete, rebase it to the current HEAD of `develop` push it to the remote repo to prepare for a `merge request`.
```
$ git rebase origin/develop
$ git push -f origin/feature-foo
```
Next, you will want to [create a merge request](https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html), so that the repository administrator can review and merge your feature. You will want to create the following pull request:
Any line of the commit message cannot be longer than 80 characters ! This allows the message to be easier to read on gitlab as well as in various git tools.
```
[TYPE] <subject>
<BLANK LINE>
<body>
```
##### Allowed `[TYPE]`
-**FEATURE**: A new feature
-**FIX**: A bug fix
-**DOCS**: Documentation only changes
-**STYLE**: Changes that do not affect the meaning of the code
