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 developYou 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-fooNext, 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>
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