Mémento de Git
=============

## Synopsis
Ce mémento est un résumé de l'utilisation de Git pour le travail collaboratif.

## Gestion de code sous GIT
### Les commandes utiles
Commande                    | Explication
--------------------------- |:------------
`git status`                | informations générales (fichiers non commités, branche ...)
`git pull`                  | récupérer les changements sur le serveur
`git push`                  | envoyer vos changements sur le serveur
`git checkout master`       | aller sur la branche master
`git checkout -b my-branch` | créer la branche my-branch
`git add my-file`           | ajouter my-file au stage
`git add -A`                | ajouter tous les fichiers modifiés au stage
`git commit`                | créer un commit avec tous les fichiers fu stage

### Les commits
Un **commit** est un enregistrement du code dans l'historique de la branche.
Un commit obéit doit être :
- le plus petit possible (peu de changements)
- fonctionnel (le code peut être exécuté sans lancer d'erreur)

Il est possible d'annuler les changements non commités, ce qui permet d'expérimenter du code puis de revenir à un état stable sans oublier de code expérimental quelque part.

#### Le stage
GIT utilise le **stage** pour marquer les modifications à enregistrer. Par défaut une modification n'est pas dans le stage et apparaît en rouge lorsqu'on fait un `git status`. Pour ajouter les modifications apportées à un fichier dans le stage on fait un `git add path/to/my/file`. Si on fait un `git commit` après on enregistre alors toutes les modifications du stage dans l'historique de la branche.

Ceci permet de contrôler le contenu de ses commits (*exemple: j'ai un fichier de configuration que je ne veux pas ajouter dans git*).

### Les branches
Une branche permet d'écrire son code sans risquer d'entrer en conflit avec le travail des autres collaborateurs. La branche principale est `master`

**:warning: On ne push jamais sur la branche master**

On crée une nouvelle branche chaque fois qu'on implémente une nouvelle fonctionnalité (*exemple: utiliser la base de données pour récupérer les données*).
Une fois le travail terminé on fait une **pull request**, qui consiste à demander à que son code soit intégré à la branche master.

#### Créer une branche
Depuis la branche master :
1. on s'assure qu'on est sur master et que le code est à jour avec `git status` ;
2. on met à jour le code avec `git pull` ;
3. on crée une nouvelle branche avec `git checkout -b "my-branch"`.

#### Travailler sur sa branche
On itère par commits. Une fois la fonctionnalité entièrement implémentée à l'aide d'un ou plusieurs commits la branche peut être mergée (**merging** en anglais) on peut faire une **pull request** (ou PR en abrégé) si on utilise github afin
que le code de la branche soit enregistré dans master.

Les étapes sont :
1. envoyer la branche sur github avec `git push` ;
2. se rendre sur la *page github du projet* puis dans l'onglet *Pull requests* ;
3. cliquer sur *New pull request* ;
4. dans la liste *compare* choisir votre branche ;
5. cliquer sur *Create pull request*.

Maintenant vos collaborateurs peuvent venir consulter votre pull request, voir tous les changements que votre branche va apporter à master afin de s'assurer que vous n'introduisez pas d'erreur et commenter/valider votre PR.

Lorsque les changements ont été vérifiés un des collaborateurs peut alors accepter la PR, ce qui va merger votre code dans master. Si il n'y a pas de conflits ce sera fait automatiquement, sinon il faudra faire un rebase en local (voir plus loin).

### Gérer les conflits de merging
Lorsqu'on merge une branche dans une autre, si un fichier a été modifié dans les deux branches il peut y avoir un conflit: git ne sait pas quelles modifications enregistrer et lesquelles annuler.

Il faut alors en local:
1. faire un `git pull` sur les 2 branches pour s'assurer d'avoir des versions à jour
2. se rendre sur la branche à merger avec `git checkout my-branch` ;
3. faire `git rebase --onto master` (si on veut merger *my-branch* sur *master*) ;

Git va alors dérouler l'historique des commits jusqu'à arriver aux fichiers conflictuels, par commit.

Il faut alors faire pour chaque commit conflictuel :
1. `git status` pour voir quels fichiers posent problème
2. éditer les fichiers pour corriger les problèmes
3. ajouter les modifications au stage avec `git add -A`
4. relancer le processus avec `git rebase --continue`

Une fois que le rebase est complété, il faut refaire un `git push` pour l'envoyer sur le serveur github et compléter la PR.