Skip to content

Documentation sur Git

Par Nicolas Dewaele - adminrezo.fr

Document sous licence CC BY-SA

I- Installation

Sous Windows

  • Télécharger Git for Windows qui inclus pas mal d'outils
  • Installer en laissant toutes les options par défaut
  • Lancer Git for Windows

Sous Linux

Utiliser les outils de packaging de votre distribution pour installer git, git-flow et zsh (plus pratiques pour Git) :

apt update && apt install -y git git-flow zsh

ou

yum -y install git git-flow zsh

Facultatif :

  • Installer Oh-my-zsh :

sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

  • Changer le thème par défaut : changer la variable ZSH_THEME dans le fichier ~/.zshrc :

ZSH_THEME="pygmalion"

Outils graphiques (facultatif)

Certains outils peuvent vous permettre d'utiliser graphiquement Git mais attention, il faut d'abord bien comprendre le fonctionnement en CLI de Git avant de l'utiliser avec une interface graphique.

II- Utilisation basique

Première configuration

  • Définir votre Nom et votre e-mail pour que les commits soient identifiés :
git config user.name "Prénom Nom"
git config user.email "votreemail@domaine.com"

Jouer avec l'historique

Un premier usage de Git est simplement de pouvoir naviguer dans l'historique de vos versions.

cd repertoire/de/votre/code
git init # initialise le dépôt
# Modifiez un ou plusieurs fichiers
# ...
git add fichier1 fichier2 fichierN # ajouter les fichiers que vous voulez au commit
git commit -m "add: L'amélioration" # commit = enregistrement dans l'"arbre" git.

Vous pouvez faire autant de commits que vous voulez (un commit par avancée dans votre projet).

Dans un dépôt avec plusieurs commits, vous pouvez voir l'historique des commits avec :

git log

Vous pouvez également revenir sur un commit précédent de différentes manières :

git diff id-de-commit # Voir la différence entre la version actuelle et un ancien commit
git diff id-de-commitA id-de-commitB  # Voir la différence entre 2 commits
git checkout id-de-commit # Retourner sur un ancien commit
git checkout master # ... avant de revenir à la tête
git revert id-de-commit # Replacer la tête de l'arbre en arrière ⚠

Fichier gitignore

Créer un fichier .gitignore dans votre répertoire contenant la liste des fichiers que vous ne voulez pas inclure dans Git.

Voir le fonctionnement de gitignore.

Jouer avec les branches

Le développeur qui travaille sur un projet a plusieurs contraintes : - travailler sur plusieurs fonctionnalités en parallèle - travailler en équipe - publier une partie du code mais pas tout

Les branches Git sont faites pour ça : Par défaut, on travaille sur la branche master qui est publiée.

Si on veut ajouter une fonctionnalité, on va créer une nouvelle branche dérivée de la branche principale. Cette nouvelle branche sera fusionnée par la suite pour être intégrée.

git branch feature/lenom # Crée la branche dérivée de la branche où vous étiez précédemment
git checkout feature/lenom # Se déplace sur la branche "feature/lenom"
# Travail
# ...
git add ...
git commit ...
git checkout develop # Se déplace sur la branche où l'on était précedemment
git merge feature/lenom # Fusionne la branche feature/lenom avec develop
git branch -D feature/lenom # Supprime la branche feature/lenom qui a déjà été fusionnée

Conflits

Admettons que vous ayez travaillé dans la branche feature/lenom sur le fichier "fichier1.py" et qu'un collègue ait lui aussi travaillé sur le fichier "fichier1.py" dans la branche develop.

Quand vous allez fusionner feature/lenom avec develop, vous aurez à résoudre un conflit.

Il faudra alors comparer les deux versions, supprimer les lignes dont vous ne voulez plus et refaire la fusion.

C'est pénible à faire. Pour éviter ça, suivez les conseils du chapitre suivant et utilisez Git Flow.

Remisage (stash)

En cas de conflit, d'interruption au milieu d'un travail, vous pouvez mettre de côté les modifications depuis votre dernier commit. Cette fonctionnalité s'appelle le remisage (stash) :

git add ...
git commit ...
# Travail ...
# Travail ...
# Travail ...
# Travail ...
# Argh ! Vous devez partir au milieu de votre travail
# Vous ne pouvez pas commiter du travail a moitié fait !
git stash # Mets au placard le code que vous avez modifié depuis le dernier commit
git stash list # Liste tous les remisages
git stash show stash{X} # Montre le remisage X
git stash drop stash{X} # Supprime le remisage X
git stash apply stash{X} # Reprend le remisage X

Sachez que le remisage est commun à toutes les branches.

Tags

Quand vous finalisez une version de votre projet, vous voulez sûrement la "figer" pour qu'elle ne soit plus modifiée par la suite.

Quand vous définissez un tag, il sera toujours associé à cette version du code et vous pourrez dire à vos clients de prendre la version du numéro du tag qui va bien.

git tag # liste les étiquettes
git checkout branche-qui-va-bien # Se placer sur la branche à étiqueter
git tag -a v0.9 -m "Message de la version 0.9" # Créer une nouvelle étiquette
git tag # liste les étiquettes

Conseils pour ne pas s'embrouiller avec Git

Mettre des messages explicites à vos des commits

Il ne faut pas sous estimer le rôle des messages (nommage) de commits Git. Ils doivent être clairs pour que tous les développeurs puissent comprendre ce qui s'est passé depuis le dernier commit.

Méthodologie de messages : - "add : ..." : Ajout d'une fonctionnalité - "mod : ..." : Modification d'une fonctionnalité - "rem : ..." : Suppression d'une fonctionnalité

Travailler sur la bonne branche

Le meilleur moyen de travailler correctement, surtout à plusieurs est d'utiliser Git Flow Ils doivent être clairs pour que tous les développeurs puissent comprendre ce qui s'est passé depuis le dernier commit.

Méthodologie d'utilisation des branches : - master : Branche principale où le public prend le code (stable) - develop : Branche de développement, la branche où toutes les fonctionnalités tombent - release : Branche où avancent chaque version, chaque incrément de votre projet - feature/ma-nouvelle-feature : Branches sur lesquelles les développeurs travaillent pour de nouvelles fonctionnalités - hotfix/mon-correctif : Branches de développement d'un correctif de fonctionnalité court - bugfix/mon-correctif : Branches de développement d'un correctif de bug court - vX.Y : Tags avec les numéros de version

III- Configuration d'un compte sur un serveur

Ce que vous avez vu jusque là (add, commit, branch, tag, ...) peut se faire sur son poste de travail sans connexion Internet mais à un moment, vous allez vouloir sauvegarder, publier, travailler à plusieurs et il vous faudra vous synchroniser avec un serveur.

Sachez qu'il n'y a pas besoin de serveur particulier pour partager du code avec Git, on peut quasiment le faire se le mode du peer to peer (chacun est à la fois serveur et client) mais des serveurs Git permettent des fonctionnalités plus avancées.

Gitlab est un service en ligne gratuit, permettant ça, de la même manière que Github qui, lui, est fourni par Microsoft. Gitlab est également un logiciel libre, hébergeable en local pour toutes les entreprises qui souhaitent garder leur code chez elles.

Compte sur Gitlab

  • Créer un compte sur Gitlab.
  • Créer un nouveau projet sur votre compte Gitlab
  • Sur votre PC, allez dans le répertoire de votre projet ou créez-le si c'est un nouveau projet
  • Configurer votre projet pour fonctionner avec Git
cd répertoire
git init
git remote add origin git@git.esiee.fr:MONCOMPTE/MONDEPOT.git
git add . --all
git commit -m "Initial commit"
git push -u origin master

Travail avec un dépôt distant (pull / push)

Quand vous commencez votre journée, il faut être sûr que votre répertoire local est bien synchrone avec le serveur :

git pull

Quand vous avez avancé sur votre projet, vous pouvez publier vos commits sur le serveur avec :

git push

Fichier README.md

Créer un fichier README.md dans votre répertoire.

Ce fichier sera la "page d'accueil" de votre dépôt.

Il utilise la syntaxe Markdown, qui est très simple à écrire.

Voir le fonctionnement de gitignore.