AI20 Projet othello
Getting Started
Prerequisites
Installation
Workflow
This branching model is based on Vincent Driessen's "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, 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>
[TYPE]
Allowed - 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