Git

git est un système de gestion de version collaboratif qui permet de garder un historique des modifications effectuées sur un ensemble de fichiers à l’instar de TFS de Microsoft. L’une des particularités de Git est qu’il est possible de travailler en local en bénéficiant de la navigation à travers l’historique de nos fichiers.

Workflow

Initialisation local

Lorsqu’on veut qu’une arborescence puisse être gérée par le système Git, il faut initialiser le dossier « racine » c’est à dire que l’on crée un repository.
Pour cela on se positionne dans le dossier en question puis exécuter la commande : git init . Cela créera un dossier .git (caché) contenant toutes les informations (sous forme d’une arborescence de fichier) concernant le nouveau repository git.

Connexion au git server

Pour pouvoir travailler sur un repo distant il suffit :

1. d’avoir un compte sur le site (Github, bitbucket etc.) ou serveur git distant (git server est disponible sur Linux mais aussi sur les NAS synology par ex)
2. d’avoir un repository créé sur le serveur
3. de disposer de l’URI de ce repo distant et des droits suffisant pour se connecter à distance sur le serveur

git remote add nom_de_notre_connexion uri

Utilisation de base

État

• git status  : indique l’état de notre répo local ainsi que la branche sur la quelle nous travaillons. Il est intéressant de l’utiliser constamment pour voir où on en est dans le workflow
• git status -s : affichage compacte (short)
• git log  : donne l’historique des opérations (se positionner dans un répertoire déjà initialisé)
• git log --oneline  fourni un listing condensé

Ajout de fichiers

• git add .  : ajoute tous les fichiers modifiés listés dans la zone de staging. Cet ajout est local, et devra être suivi d’un git commit
• git commit -m "message de commit"  : sauvegarde en local toutes les modifications présentes dans la zone de staging et y associe un message (ne pas négliger ce message)
• git commit -am "message de commit" : cumul des 2 commandes précédentes
• git commit --amend  : permet de modifier le dernier commit pour ajouter/supprimer des fichiers ou modifier le message associé
• git commit --no-verify  : permet de bypasser les checks de pre-commit déclenchés par les hooks
• git push  : envoi sur le serveur git les modifications qui ont été commité en local. Attention pour que cette commande fonctionne, un repo distant doit avoir été préalablement ajouté (souvent nomé origin)

Gestion

• git pull  : récupère les modifications coté serveur (fichiers modifiés ou ajoutés). Cette commande est équivalent à un git fetch (récupère les fichiers distants) puis un git merge (ajouter les fichiers distant ajouté à notre branche)
• git rebase -i HEAD~10 : permet de nettoyer un historique (ici les 10 derniers) de commits dégueux pas encore pushés en utilisant ‘f’ fixup pour fondre les commits  (credit et aussi), voir aussi git rebase  ici
• git update-index --chmod=+x monscript.sh : sauvegarde un chmod +x sur ce script dans git, permission qui sera réstitué lors d’un git pull
• git reset HEAD -- chemin/fichier : retire le fichier de la zone de staging
• git reset --hard origin/master : annule toutes les modifications locales et se met au niveau de la remote master

Git Branch

Les branches permettent de travailler de façon isolée sur une « copie » de l’ensemble du code du répo et il est alors possible de simplement passer d’une branche à l’autre avec des git checkout. C’est utile par exemple lorsqu’on veut implémenter une nouvelle fonctionnalité ou corriger un bug sans affecter le code existant.
Pour info, la branche créée à l’initialisation du repo s’appelle « master » .

• git branch ma-nouvelle-branche  : création d’une nouvelle branche nommée « ma-nouvelle-branche »
• git branch  : liste les branches ainsi que celle qui est sélectionnée
• git checkout ma-nouvelle-branche  : permet de se positionner sur la branche « ma-nouvelle-branche »
• git checkout --  : se positionner sur la branche précédente, permet de jongler entre 2 branches
• git checkout -b ma-nouvelle-branche  : permet de créer une nouvelle branchema-nouvelle-branche et se positionner dessus
• git merge ma-nouvelle-branche : merge les commits de la branche  ma-nouvelle-branche sur la branche courante (se positionner sur Master pour redescendre ses devs)

Workflow

Le workflow GIT de base est donc le suivant (en répétant les étapes suivantes 1 et 2) :

• git pull (sur la branche master)
• …travailler sur des fichiers
• git checkout -b ma-nouvelle-branche
• git add .
• git commit -m "message de commit"
• git push

On a ainsi une branche ma-nouvelle-branche qui contiendra des modifications qu’il faudra rebase ou merge sur la master (qui est la branche de référence, clean).
Il existe des workflow rependus utilisés sur les projets comprenant de nombreux développeurs, notamment les plus connus qui sont les Gitflow (article) et le GitHub flow (pour les projets qui mettent en ligne très fréquemment).

Stash

Lorsqu’on veut mettre de coté du code que l’on ne souhaite pas forcément commiter, git nous propose le mécanisme de stash (remiser ou cacher).
Une fois mis coté, nous pouvons passer et travailler sur une autre branche, et appliquer les modifications stashés sur n’importe quelle branche plus tard.

• git stash -u : stash tous les fichiers, même les untracked
• git stash push -u -m "message de stash"
• git stash list : liste les stash empilés actuellement
• git stash apply : appliquer le dernier stash à la branche courante
• git stash apply --index : apply + remet les fichiers en zone de staging s’ils y étaient avant le stash
• git stash apply stash@{2} : applique le 3ème stash (indiqué par un stash list)
• git stash pop : apply et supprime le stash de la pile
• git stash drop stash@{2} : supprime le 3ème stash
• git stash branch ma-nouvelle-branche : cré

Git config

Git comporte 3 niveaux de configurations, que l’on peut modifier avec la commande git config:

1. git config --system  : appliquée à tous les utilisateurs du système, ainsi qu’à tous leurs repos modifie /etc/gitconfig
2. git config --global  :appliquée à 1 utilisateur, ainsi qu’à tous ses repos modifie ~/.gitconfig ou ~/.config/git/config
3. git config --local  : appliquée au répository modifie le fichier contenu dans l’arborescence du repo dans .git/config

Attention en cas de redéfinition de clés de config voici la priorité (la plus spécifique gagne):
local > global > system

Exemple du paramétrage d’une valeur de config utilisateur:
git config --global core.editor vi

Pour lister une config en particulier utliser :  git config --global -l

Git et SSH sous Windows

Sous Windows faire attention au format de clés SSH (qu’il suffit de tester en essayant de se connecter avec le compte dédié au serveur git sur ce seveur, s’il l’autorise), à défaut utiliser PuTTY Key Generator pour convertir la clé privée:

Il est ensuite préférable d’utiliser un fichier de config SSH (qui va associer une clé donnée à un serveur), ce fichier a créer s’il n’existe pas : %USERPROFILE%\.ssh\config  va contenir un ensemble de blocs

Host monserveurgit
    Hostname adresse.dsn.de.mon.server.git.com
    IdentityFile ~/.ssh/ed25519.ppk
    IdentitiesOnly yes

Outils

• Windows: choco install git  ou git SCM
• Linux: sudo apt install git-core -y && sudo apt autoremove -y
• Outils graphiques : Git Kraken (multiplateforme) et le tout nouveau Sublime Merge

Liens

• la doc git en Francais (pdf)
• ressources officiels et aide mémoire git (cheat sheet)
• demystifying git concepts
• Atlassian
• différences entre git merge et git commit
• comparatif des fournisseurs de service GIT
• détail de la différence entre git merge et git rebase
• how to undo anything avec git