Commit 803564bb authored by alexandre.ducarne's avatar alexandre.ducarne
Browse files

馃摑 Modify README.MD

parent 09c087cb
Projet de d茅veloppement pour l'UV AI12
\ No newline at end of file
<p align="center">
<h3 align="center">AI20 Projet othello</h3>
## 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>
##### 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: 鈥渃hange鈥 not 鈥渃hanged鈥 nor 鈥渃hanges鈥
- don't capitalize first letter
- no dot (.) at the end
##### Message body
- just as in `<subject>` use imperative, present tense: 鈥渃hange鈥 not 鈥渃hanged鈥 nor 鈥渃hanges鈥
- includes motivation for the change and contrasts with previous behavior
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment