Git en bref

Concept

Git, c’est quoi ?

Git est un logiciel de gestion de version. Il permet de conserver un historique complet des versions d’un projet de manière décentralisée. Git est très utilisé par la communauté des développeurs parce qu’il facilite, entre autres, le travail collaboratif sur un projet avec notamment la gestion de conflits quand deux développeurs travaillent sur un même fichier.

Il est aussi possible de revenir rapidement sur différentes versions d’un projet. Une « branch », au sens Git, permet de s’éloigner du projet principal pour développer par exemple une nouvelle fonctionnalité ou répondre à une demande. Une fois finie, il est possible de revenir au projet principal simplement sans avoir à faire de multiple copier/coller, ou avoir plusieurs dossiers contenant le même projet ou programmes sous différentes versions. Les différentes versions cohabitent dans un seul dossier pour passer facilement de l’une à l’autre sans perte d’information.

Les différents types de branches

Branche	Environnement	Origine	Fonction
master	Production	Aucune	Code stable, testé et validé. C’est la branche qui est sur le serveur de production ou qui va être mise en production.
hotfix	Aucun	master	Branche où l’on corrige les bugs présents dans la branche master (production). Utilisée uniquement pour un bug bloquant en production nécessitant une mise en production rapide.
staging	Test	develop	Branche sur laquelle on corrige les bugs détectés pendant la phase de test.
develop	Aucun	master	Code de la prochaine version de l’application. Une fois qu’une fonctionnalité (feature) est terminée, le code est fusionné dans cette branche.
feature	Aucun	develop	Code en cours de développement qui implémente une fonctionnalité à intégrer dans la prochaine version de l’application.

Utilisation

Comment lire le schéma :

Master

La branche « Master » qui est en bleu sur le schéma est la branche qui est en production.

Elle a le numéro de version 0.1. Lorsque qu’un incident (bug) arrive en production et qu’il est bloquant, c’est-à-dire que toute l’application ou une partie de l’application ne fonctionne plus, il faut rapidement fixer le bug. Pour ce cas seulement on utilise la branche hotfix qui est en rouge sur le schéma. Lorsque le patch créé sur la branche hotfix est testé et validé, alors uniquement à ce moment-là il sera possible de fusionner la branche hotfix à la branche master pour la mise en production. La fusion sur la branche master implique une montée de version mineure de l’application et donc la version de l’application passe de 0.1 à 0.2. La branche hotfix est supprimée une fois fusionnée avec la branche master et develop car son rôle est terminé.

Develop

Pour le développement de la prochaine version de l’application, la branche permanente « Develop », en violet sur le schéma, est prévue à cet effet. Cette branche est basée sur « Master ».

Si un hotfix est réalisé sur la branche « Master », il faut le répercuter sur cette branche. La branche « Develop » a pour rôle d’accueillir les nouvelles fonctionnalités en vue de la prochaine version de l’application. Tous nouveaux développements de fonctionnalités partent de cette branche représentées par les branches de feature en vert sur le schéma. Un fois le développement de la nouvelle fonctionnalité achevé, testé et validé par le développeur, il met à jour sa branche par rapport à la branche« Develop » pour éviter les conflits et les régressions de code. Ensuite cette branche est fusionnée sur la branche « Develop ». Le développeur peut commencer le développement d’une nouvelle fonctionnalité et créer une branche de feature depuis la branche « Develop » et ainsi embarque la ou les nouvelles fonctionnalités qui sont sur la branche « Develop » à l’instant où il la crée.

Release

Une fois le développement de la nouvelle version achevé, nous créons une branche « Release », en turquoise sur le schéma, pour la mise en recette de la version.

S’il y a des retours de recette, le développement sera effectué sur cette branche. Une fois la version recettée et validée, la branche « Release » est fusionnée avec la branche « Master » pour la mise en production de la nouvelle version. Cette fusion implique une montée de version de l’application, et ainsi l’application passe de la version 0.2 à 1.0. Une fois la nouvelle version en production, la branche « Release » est fusionnée sur la branche « Develop » et la branche « Release » est supprimée car son rôle est terminé. Voilà comment fonctionne globalement la méthode GitFlow. Cette méthode de gestion des branches est très adaptée à l’intégration continue.

Travailler avec Git

Pour travailler avec Git et GitHub, il faut savoir comment récupérer un projet, créer une branche de travail, sauvegarder son travail et mettre à disposition son travail sur le serveur GitHub.

Récupération d’un projet

Pour récupérer un projet git en local sur votre machine de travail, il faut utiliser la commande git clone :

git clone <url du dépôt git>

Cette commande va aller récupérer le dépôt broker sur le serveur GitHub. Le répertoire broker est créé avec à l’intérieur le code source et son historique. Le répertoire «.git » contient l’ensemble de l’historique du code du projet, à ne jamais supprimer.

Création d’une branche

Une branche dans Git sert à pouvoir développer sa fonctionnalité ou son bug fix depuis une version du projet sans impacter la branche principale. Dans la méthode GitFlow, les branches de travail partent des branches permanentes.

Pour voir si une branche est créée sur le dépôt, il faut que votre dépôt local soit à jour, voir 3.1.5, et utiliser la commande git branch. Avec l’option « -a », nous pouvons voir toutes les branches locales et distantes (elles sont préfixées par le mot « remote ») :

git branch -a
develop
feature
master
remotes/origin/develop
remotes/origin/feature
remotes/origin/master
remotes/origin/test 

Une fois la vérification faite, vous pouvez créer votre branche depuis la branche souhaitée. Pour changer de branche il faut utiliser la commande git checkout.

Une fois sur la branche souhaitée, utilisez la commande git branch pour créer votre branche de travail. Dans la méthode GitFlow, pour créer une branche de travail « Feature » vous devez partir de la branche « Develop ».

Exemple :

#on change de branche, on va sur la branche « Develop »
git checkout develop

#on vérifie qu’on soit bien sur la branche « Develop »
$git branch -a
* develop

#on crée la branche « Feature »
git branch feature

#on vérifie que la branche « Feature » soit bien créée.
$git branch -a
  develop
* feature

La branche « Feature » vient d’être créée depuis la branche « Develop ».

Sauvegarder son travail

Une fois le développement partiel ou total de votre fonctionnalité fait, vous devez sauvegarder votre travail au sens Git du terme. Pour cela vous devez ajouter votre code à votre branche grâce à un ou plusieurs commits. Un commit représente l’ensemble des modifications qui ont été faites sur la branche depuis le dernier commit. Le commit prend la forme d’une chaine de caractère alphanumérique qui est unique au projet.

Pour réaliser un commit, les commandes suivantes doivent être saisies :

# permet de visualiser toutes les modifications apportées à la branche.
git status 

# permet d'ajouter le(s) fichier(s) modifié(s) au futur commit.
git add <path du fichier> 

# Enregistre toutes les modifications ajoutées avec git add. Cela créé un nouveau point sur la branche.
git commit 

Lors de la création d’un git commit, un éditeur de texte s’ouvrira dans le terminal afin de rédiger un message qui sera lié au commit. En général, ce message porte sur la fonctionnalité qui a été développée ainsi que toute information qui pourrait être importante pour comprendre celle-ci.

Une fois le commit créé, toutes les modifications doivent être envoyées au dépôt distant car toutes les commandes effectuées modifient le dépôt Git local.

Mettre sa branche sur le serveur GitLab

Pour transmettre au serveur GitLab votre branche et vos modifications, vous devez utiliser la commande git push :

git push origin <nom de la branche>

Exemple :

git push origin feature

Cette commande va envoyer au dépôt distant GitLab (origin) la branche ainsi que tous les commits avec les modifications.

À l’exécution de cette commande, le serveur demande le login et le mot de passe GitLab.

Mettre à jour le dépôt local et les branches locale

Pour mettre à jour le dépôt local et les branches locales, vous devez dans un premier temps récupérer les modifications du dépôt distant. Pour cela on utilise la commande fetch :

# Met à jour le dépôt local par rapport au dépôt distant.
git fetch origin

Avec cette commande, le dépôt local est mis à jour mais vous n’avez pas récupéré/fusionné ces modifications sur les branches locales. Pour cela, l’utilisation de la commande pull est nécessaire :

git pull origin <nom de la branche>

Exemple :

git pull origin develop

La branche « Develop » est maintenant à jour sur votre machine par rapport au serveur GitHub.

Liste des commandes

Ci-dessous les commandes Git habituelles dans diverses situations :

Démarrer une zone de travail (voir aussi : git help tutorial)

• clone : Cloner un dépôt dans un nouveau répertoire
• init : Créer un dépôt Git vide ou réinitialiser un existant

Travailler sur la modification actuelle (voir aussi : git help revisions)

• add : Ajouter le contenu de fichiers dans l’index
• mv : Déplacer ou renommer un fichier, un répertoire, ou un lien symbolique
• reset : Réinitialiser la HEAD courante à l’état spécifié
• rm : Supprimer des fichiers de la copie de travail et de l’index

Examiner l’historique et l’état (voir aussi : git help revisions)

• bisect : Trouver par recherche binaire la modification qui a introduit un bogue
• grep : Afficher les lignes correspondant à un motif
• log : Afficher l’historique des validations
• show : Afficher différents types d’objets
• status : Afficher l’état de la copie de travail

Agrandir, marquer et modifier votre historique

• branch : Lister, créer ou supprimer des branches
• checkout : Basculer de branche ou restaurer la copie de travail
• commit : Enregistrer les modifications dans le dépôt
• diff : Afficher les changements entre les validations, entre validation et copie de travail, etc
• merge : Fusionner deux ou plusieurs historiques de développement ensemble
• rebase : Réapplication des commits sur le sommet de l’autre base
• tag : Créer, lister, supprimer ou vérifier un objet d’étiquette signé avec GPG

Collaborer (voir aussi : git help workflows)

• fetch : Télécharger les objets et références depuis un autre dépôt
• pull : Rapatrier et intégrer un autre dépôt ou une branche locale
• push : Mettre à jour les références distantes ainsi que les objets associés

Coloration Git bash

https://github.com/magicmonty/bash-git-prompt

• Clone this repository to your home directory. git clone https://github.com/magicmonty/bash-git-prompt.git ~/.bash-git-prompt --depth=1
• Add to the ~/.bashrc:

if [ -f "$HOME/.bash-git-prompt/gitprompt.sh" ]; then
    GIT_PROMPT_ONLY_IN_REPO=1
    source "$HOME/.bash-git-prompt/gitprompt.sh"
fi

Ignorer les changements de mode de fichier:

Exécuter la commande :

git config core.fileMode false