Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
<p align="center">
<h3 align="center">AI20 Projet othello</h3>
</p>
## Getting Started
### Prerequisites
### Installation
### Workflow
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:
- source branch: `feature-foo`, target branch : `develop`
#### Commit messages
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
(white-space, formatting, missing semi-colons, etc)
- **REFACTOR**: A code change that neither fixes a bug nor adds a feature
##### `<subject>` text
Subject line should contains succinct description of the change.
- use imperative, present tense: “change” not “changed” nor “changes”
- don't capitalize first letter
- no dot (.) at the end
##### Message body
- just as in `<subject>` use imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior