From 803564bb5a9afdf44c632d8c5a75761d89d19650 Mon Sep 17 00:00:00 2001 From: "alexandre.ducarne" <alexandre.ducarne@renault.com> Date: Wed, 11 Sep 2019 17:02:19 +0200 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20Modify=20README.MD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 75 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index bd2ff50..806f9aa 100644 --- a/README.md +++ b/README.md @@ -1 +1,75 @@ -Projet de développement pour l'UV AI12 \ No newline at end of file +<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 -- GitLab