# Guide du Workflow Git
###### tags: `Développement`

C'est quoi un **workflow** ? En gros, c'est une **façon de travailler**, une ligne directrice pour faire notre travail. Ici, on va voir comment collaborer sur **ce** projet avec l'outil **Git**

## Les bases des bases

### Git

C'est un Système de Contrôle de Version (ou VCS en anglais). C'est un logiciel qui va enregistrer la liste des **modifications apportées au projet**. C'est pratique, car ça permet de revenir en arrière quand on fait une boulette.

Ces **modifications successives** sont appellés des **commits**. L'historique d'un dépôt Git est donc une succession de **commits**.

Sur Git, on peut séparer le projet en différentes **branches**. Chaque branche est indépendante et peut être modifiée sans que ça n'affecte les autres. On peut facilement passer d'une branche à l'autre, et Git se chargera de modifier les fichiers sur notre PC.

Il est possible ensuite de fusionner deux branches (**merge**) pour rassembler leur code en une seule branche. Pratique, pour collaborer.

### Les GUI (GitKraken et cie.)

Les **Interfaces Graphiques** pour Git sont juste des logiciels qui rajoutent une belle interface à Git, qui est à l'origine un logiciel en lignes de commandes.

<center><strong>L'interface de GitKraken</strong></center>

Mes conseils
**Pour les débutants :** [GitKraken](https://www.gitkraken.com/)
**Pour les plus avancés :** [SourceTree](https://www.sourcetreeapp.com/)
**Et sinon :** Git :upside_down_face:

Ici, [l'aide GitKraken](https://support.gitkraken.com/start-here/interface/), pour les paumés.

### Les "Hubs"

Ce sont des outils en ligne qui permettent d'uploader un dépôt Git, et de collaborer en ligne à plusieurs. C'est l'outil principal de l'Open Source.

Le plus connu est **Github** mais nous on utilisera **Gitlab** :fox_face:

Pour copier un dépôt en ligne sur notre PC, on le **clone**.
Pour récupérer les dernières modifications de la branche actuelle, on **pull**.
Pour envoyer nos modifications sur la branche actuelle, on **push**.

Seulement, il y a un problème. Si n'importe qui push, ça devient vite le bordel, n'importe qui peut ajouter un virus, grief le dépôt, c'est la merde. C'est là que viennent les **merge request**.

Elles se font le plus souvent en ligne sur le hub en question. L'idée est de proposer des modifications et les soumettre à la vérification des propriétaires du dépôt. Si ils l'acceptent, la branche est **merge**.

<center><strong>Une merge request sur Gitlab. On voit qu'il y a un espace de discussion pour donner des feedbacks sur la MR.</strong></center>

## Notre workflow

Voici comment on va procéder. Pour assurer une bonne qualité de code, et l'apprentissage des débutants, nous allons utiliser les **merge requests**.

Tout le monde aura l'autorisation de créer des branches, mais uniquement certains auront l'autorisation de merge.

Voici la marche à suivre pour développer une fonctionnalité.

### 0. Noms de branche

Une branche = une fonctionnalité, un bugfix, bref, un objectif. On ne crée pas une branche "Marcel" pour que celui-ci travaille sur le code. Voici comment nommer vos branches

`feat/<votre-feature>` Pour les branches de fonctionnalités.
`fix/<bug>` Pour les réglages de bug. On peut soit mettre un résumé du bug ou un numéro **d'issue**.
`asset/<nom>` Ajout d'un asset par un artiste, et intégration.
Pas de préfixe pour le reste.

Une branche n'est fermée que lorsqu'elle a été accomplique, c'est à dire que la fonctionnalité marche.

### 1. Ouvrir une branche

Sur GitKraken, c'est le bouton **Branch** tout en haut. Entrez un nom de branche, puis appuyez sur entrée.

### 2. Faire son travail

On enregistre régulièrement son travail en faisant des commits réguliers, à chaque fois qu'un avancement est fait dans la feature. On met un message de commit clair et compréhensible.

[Comment commit sur GitKraken ?](https://support.gitkraken.com/working-with-commits/commits/)

### 3. Push le travail sur notre branche en ligne

Plutôt simple, appuyez sur le bouton Push.

### 4. Créer une merge request

Allez sur le dépôt en ligne Gitlab, puis dans Merge Request. Ici vous pourrez cliquer sur "New Merge Request".

Ensuite, [suivez le guide](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-page).

Plus qu'à attendre que votre Merge Request soit acceptée.

### 5. Supprimer la branche une fois que le code a été merge (on en a plus besoin)

## Reporter des bugs

Plus tôt, j'ai parlé d'issue. C'est un des onglets du dépôt Gitlab. En fait, il permet de créer des "posts de forum" pour rapporter les bugs. Chaque issue a un numéro, et peut être assignée, annotée, discutée et fermée quand le bug est résolu.

On rapportera les bugs sur Gitlab plutôt que sur Trello.

## Intégration continue

Pour ce projet, nous allons utiliser le workflow de l'intégration continue. En gros : à chaque fois que vous ferez un **push** de vos modifications vers une branche en ligne, un **build** et des **tests** seront effectués. Si ils réussissent, votre branche est prête à être merge. Sinon, c'est à vous de corriger les problèmes de votre branche pour qu'elle soit viable.

Il y a 2 avantages à cela :
* Avoir des builds réguliers que l'on peut faire tester
* Être sûr que toutes les modifications fonctionnent et peuvent être build, pour éviter à passer des journées entières à corriger des bugs de build (vécu)

Ca ne change rien pour vous. Il y aura juste un bloc en bas de vos **merge requests** avec marqué "Build réussi" ou "Build échoué". Si c'est échoué, on ne regardera pas votre M.R., vous aurez tout le temps de la corriger.

Un petit schéma pour comprendre (regarder uniquement **Continuous Integration**, et pas Continuous Deployement).