git - Gestion décentralisée de version

Références

git - https://grafikart.fr/tutoriels/git-presentation-1090#autoplay

git flow - https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow

Installation sur linux

# Installation de Git
sudo apt -y install git

Installation de git bash pour windows

git avec git flow : https://git-scm.com/download/win

Attention, au début de l'installation, une option vous permettra de choisir "main" et non pas "master" comme nom de branche par défaut.

Principes de base

git est un gestionnaire de versions, c'est à dire qu'il permet de garder une trace de toutes les versions d'un logiciel en développement.

Le logiciel (avec ses versions) est stocké dans un dépôt (repository) local et/ou distant. Le projet est disponible dans le répertoire de travail (working directory). Si un fichier est modifié, pour qu'il fasse partie de la prochaine version, il faut le marquer et le placer dans une zone d'attente dite "staging area" par une opération d'ajout "add". Les fichiers en attente participent à la prochaine version par une opération de "commit". Chaque commit est identifié par le résultat d'une fonction de hachage appelée "sha-1".

Les 3 principaux états d'un fichier local

staging area

Repository local vs distant (origin)

local origin

Configuration de base

Configuration de l'utilisateur

git config --global user.name "Bob Dylan"
git config --global user.email "bob@dylan.com"

Pour vérifier :

git config --global --get user.name
git config --global --get user.email

Créer les raccourcis pour les commandes les plus courantes

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

Faire en sorte que le nom de la branche de base soit bien "main". Attention cela sous-entend que vous avez une version de git supérieure à 2.30 (git --version pour vérifier)

git config --global init.defaultBranch main

Configuration générale

git config color.ui true

Commandes de bases

Créer un dépot local

git init

Revenir à la branche main

git checkout main

Ajouter les premiers fichiers du "working directory" dans la "staging area"

git add .

Retour d'un fichier appartenant à la "staging area" vers le "working directory"

git rm --cached nomdufichier

Retour d'un fichier modifié dans le "working directory" à son état lors du dernier "commit"

git checkout nomdufichier

Ajouter au "repository" local le code qui se trouve dans la "staging area"

git ci -m "Premier commit avec une explication sur le contenu."

Envoyer les derniers commits sur le repository distant

git push

Récupérer les derniers commits depuis le repository distant

git pull

Voir ou l'on en est du "working directory" et de la "staging area"

git status

Voir la différence entre la version actuelle d'un fichier et sa version dans le dernier commit

git diff nomdufichier

Créer un patch à partir de la différence entre 2 états du même fichier

git diff nomdufichier > custom_patch_file.patch

Voir les branches présentes dont la branche en cours

git br

Voir l'historique des commits

git log

Voir l'historique des commits avec un meilleur aperçu des branches

git log --all --decorate --oneline --graph

Annuler un commit

git revert sha_du_commit

Créer une branche develop

git checkout -b develop

Supprimer une branche

git branch -d nomdelabranche

Supprimer une branche alors qu'elle n'est pas fusionnée et qu'elle a au moins un commit

git branch -D

Faire un merge de develop sur master

git checkout master
git diff master..develop // pour voir les différences entre les deux branches
git merge develop // crée un commit

Supprimer la branche bonjour

git branch -d bonjour // valable dans le cas où la branche bonjour a été mergée
git branc -D bonjour // Attention supprime la branche bonjour même si elle comporte des commits qui n'ont pas été mergés : perte de travail !

Pousser ma branche master sur le repository github "origin"

git push origin main

Créer un repository distant sur gihub

Si ce n'est pas encore fait, créez un compte sur github
Cliquez sur le bouton vert "New" en haut à gauche pour obtenir l'interface suivante
Cliquez sur le bouton vert "Create repository" pour obtenir l'interface suivante :

Entrez les instructions ci-dessus entourées de rouge sur votre console locale en ayant vérifier que vous vous trouvez bien sur un répertoire qui possède déjà un repository (git st pour vérifier). Ces opérations vont relier la branche "main" de votre repository local à votre repository sur github. Vous devriez obtnir un message de ce type :

Énumération des objets: 5, fait.
	Décompte des objets: 100% (5/5), fait.
	Compression par delta en utilisant jusqu'à 8 fils d'exécution
	Compression des objets: 100% (4/4), fait.
	Écriture des objets: 100% (5/5), 113.50 Kio | 1.04 Mio/s, fait.
	Total 5 (delta 0), réutilisés 0 (delta 0), réutilisés du pack 0
	To github.com:yvandouenel/tpgit01.git
	 * [new branch]      main -> main
	la branche 'main' est paramétrée pour suivre 'origin/main'.

Cycle de vie d'un projet géré avec git flow

Git flow est un flux de travail (workflow) pour git. Git flow part du principe qu'il est nécessaire de créer plusieurs branches :

main ou master est la branche sur laquelle se trouvera le code abouti et c'est donc la version en production
develop est la branche sur la quelle on travaille pour les améliorations de faibles importance
les branches de features permettent aux codeurs de développer des fonctionnalités (features) plus importantes, qui vont prendre plus de temps.

Git flow fait intervenir la notion de tag et de changelog. Un tag permet de repérer un point marquant dans l'historique de git. Il se crée en général quand on décide de fusionner (merge) la branche develop avec la branche main. Le fichier txt (ou md) changelog est un sommaire des différentes changements opérés sur votre branche main. Voici à quoi peut ressembler un début de fichier changelog :

version 0.1.0 - 8/03/2021
----------------------------
Le cv de Jason avec bootstrap 5 et un js pour donner l'illusion d'une écriture en temps réél

branches

Initialiser git flow

git flow init

Répondre aux questions de la façon suivante :

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 
How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/home/yvan/Dropbox/Formation/Diginamic/2022/git/.git/hooks]

Les commandes de base avec git flow

Ajouter une branche de fonctionnalité :

git flow feature start nomdelafonctionnalite

Fusionner (merge) une branche de fonctionnalité

git flow feature finish nomdelafonctionnalite

Etapes pour créer une nouvelle version du logiciel que l'on utilisera en production (la premiere est en général la v0.1.0)

git flow release start x.x.x
// Création ou modification du fichier changelog.txt cf plus haut
// commit du fichier changelog.txt
git flow release finish 'x.x.x'
git push --tags
git push
git push origin main

Hotfix : pour ajouter rapidement une modification sur la branche main qui sera également répercutée sur develop

// Attention, commencer la hotfix avant de modifier les fichiers
// le numéro de hotfix doit être cohérent avec le fichier changelog.txt
git flow hotfix start 0.1.2
// Modification à opérer en urgence
// add et commit de la modification
// Modification du fichier changelog
// add et commit de la modification de changelog
git flow hotfix finish '0.1.2'
git push --tags
git push
git push origin main

Interface et fonctionnalités sur github.com

Rendez-vous sur votre repository distant (type https://github.com/yvandouenel/tpgit01)
Trouvez dans l'interface comment on passe d'un branche à l'autre, d'un répertoire à l'autre et comment on visualise les fichiers ainsi que leur historique
Trouvez comment voir la différence entre deux commits successifs (cf bouton sha)
Trouvez comment voir la différence entre deux commits non successifs en utlisant la comparaison du type : https://github.com/yvandouenel/tpgit01/compare/5c6c4b0de2c18945408cdd8a952add8c2f439bc5..ac7633616972cd53890512a05c540245b2f160e1
Trouvez le moyen d'ajouter un "collaborateur" à l'un de vos repository sur l'interface de github

Premières manipulations

Créer un nouveau répertoire "testgit" dans ~/dev/ et se positionner dedans en ligne de commande

cd ~/dev

mkdir testgit

cd testgit/

Créer le dépot git

git init

Créer un fichier test.txt

nano test.txt

puis écrire "Ceci est un test" puis ctrl + x pour fermer puis entrer pour enregistrer

Voir ce qu'il y a de nouveau dans le dépot git

git status

Ajouter le fichier test.txt avant commit

git add test.txt

Commiter avec le message d'explication : "Ceci est mon premier commit"

git ci -m "Ceci est mon premier commit."

Envoyer sur le serveur

git push

Vérifier que le dépot est "propre"

git st

Récupérer les fichiers depuis le serveur github

git clone https://github.com/yvandouenel/xxx.git

Principaux alias

git config --global alias.st 'status'
git config --global alias.ci 'commit'
git config --global alias.co checkout
git config --global alias.br branch

Configuration

Ajouter la couleur

git config color.ui true

Ajouter du temps durant lequel on aura pas besoin de s’identifier à nouveau :

git config --global credential.helper "cache --timeout 7200"

Ne pas prendre en compte les changements sur les droits des fichiers :

nano .git/config filemode = false

Pour aller plus loin ...

Fork

Un fork est une copie d'un dépôt. Créer un fork vous permet d'expérimenter librement des modifications sans affecter le projet d'origine.

Explications sur fork

Pull request

Trouver un repository sur github sur lequel vous voulez contribuer
Faire un "Fork"
Cloner le "fork" en local
Créer une nouvelle branche (develop par exemple si elle n'existe pas)
Opérer les changement et les pousser (sur votre "fork")
Pousser sur votre "fork"
Se rendre sur l'interface de github et cliquer sur le bouton "Compare & pull request"
Cliquer sur le bouton "Create pull request"
Attendre que le "reviewer" accepte votre code ou vous demande de le modifier

Explications sur pull request

Revenir en "arrière"

Les différentes façons de revenir vers un ancien "commit"

Notion de HEAD

coopernet Réussir son site web et ses applications de la conception à la réalisation