la genèse

Git est un logiciel de versionning de code, aussi appelé Source Code Management, décentralisé.

I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.

publiée en 2007, 4M de vues (10/2023)

• outil CLI
• auteur : Linus Torval
• création : 2005

Essentielle de la conférence (1/5)

Certains contributeurs utilisaient des tarball et patches.

Étude des Source Control Management (SCM) disponibles pour le travail collaboratif.

Avant git

Essentielle de la conférence (2/5)

Avant git - BitKeeper

• le seul SCM qui vaut la peine car décentralisé
• produit commercial mais gratuit pour les projets open sources
• restrictions d'utilisation :
  • pas de reverse engeneering
  • pas de construction d'un produit concurrent

Essentielle de la conférence (3/5)

Avant git

Contexte de développement  du noyau Linux :

• Très nombreux contributeurs
• Contributeurs épartillés sur le globe

Essentielle de la conférence (4/5)

Les implications de l'aspect distribué :

• Possibilité de travailler hors ligne
  • Gros gain de performance par rapport aux systèmes centralisés
• La notion de "branch" est une conséquence de base de l'aspect distribué
• Le merge de branche doit être simple et rapide,  ce qui est fait par git

Avec git - scm distribué

Essentielle de la conférence (5/5)

• Isolation des workflows plus simple
  • Exemple : la revue qualité du code peut être faite sur une branche sans impacter le travail des contributeurs
• Git a des garanties d'intégrité des données grâce à l'utilisation des SHA-1 : hash cryptographique
• Un ensemble de commandes proposé par git est clair
  • grande maîtrise de la gestion du dépôt

Avec git

Extrait de la commande man de git

Source : Ubuntu 24.10 - 01/2025

le git paradoxe

git est le SCM dominant :

1. Qui a déjà créer des branches ?
2. Qui a déjà fait un merge ?
3. Qui a déjà eu un conflit lors d'un merge ?
4. Qui a eu du mal à résoudre les conflits ?

Et github dans tout ça ?!?

GitHub est une plateforme de développement collaboratif en ligne qui se base sur git.

• application web
• auteur : Tom Preston-Werner, Chris Wanstrath, PJ Hyett et Scott Chacon
• création : 2008

publiée en 2008, 1.5K de vues (01/2025)

Microsoft a racheté GitHub en 2018.

Essentielle de la conférence (1/4)

Démonstration d'un exemple de contribution à 1 dépôt grâce à la fonctionnalité de Fork et PR de GitHub. GitHub est :

Tom Preston-Werner

• Centré sur l'utilisateur
• Possibilité de suivre un utilisateur
• Possibilité de suivre un dépôt
• Avoir un profil pour chaque utilisateur
• Création de dépôt simple
• Création de fork simple
• Création de Pull Request simple
• Des visualisations expréssive : network

Essentielle de la conférence (2/4)

Histoire des gestionnaires de version (SCM)

Chris Wanstrath

• RCS (1982)
• CVS (1986)
• SVN (2000)
• git (2005)

RCS

CVS

SVN

git (1/3)

git (2/3)

git (3/3)

Essentielle de la conférence (3/4)

• Chaque contributeur peut jouer le rôle de serveur distant pour les autres contributeurs : un serveur central n'est pas obligatoire
• Discussion des différents workflows de collaboration
• Présentation de l'intégration de git dans différents éditeurs de texte

Chris Wanstrath

Essentielle de la conférence (4/4)

Des commandes avancés de git

• Jongler avec les commits
  • git commit --amend
  • git rebase
  • git rebase -i
• Discussion sur git push -f
• Présentation de : git add -p, git blame, git bisect, git diff sur des fichiers binaires

Scott Chacon - tips and tricks

Livre Pro Git

développement collaboratif, l'histoire ne s'arrête pas

git existe depuis 2005, développé pour les besoins du noyau Linux. Les agents IA n'existaient pas à l'époque, l'usage de messageries instannées (Teams, Discord, Slack...) non plus.

Il existe des alternatives qui explorent d'autres workflow afin d'améliorer le travail collaboratif, en tenant compte des agents IA.

Pour ne citer qu'une seule alternative, l'éditeur Zed.

• application desktop : IDE
• auteur : Nathan Sobo, Antonio Scandurra et Max Brunsfeld
• création : 2024

publiée en 2025, 36K de vues (08/2025)

Env de developpement - GIT

git

Extension :  Git Graph : mhutchie.git-graph

Exemple d'identifiant d'une extension

Windows :

• git bash
• WSL - Windows Subsystem for Linux

Linux :

sudo apt install git

VSCode

Env de developpement - GITHUB

1. Créer un compte sur github.com
2. Si ce n'est pas fait, ajouter sa clé ssh à github

Les commandes

LOCAL

DISTANCIEL

branch
checkout
merge
rebase

switch
tag

remote
config
init

clone
fetch
pull
push

Liste de toutes les commandes

L'essentiel

GIT - WORkFLOW

GIT - WORKFLOW

GIT - Atelier 1 (1/9)

• Créez un dossier "atelier-1" depuis le terminal
• Déplacez vous dans ce dossier
• Créez un dépôt local avec la commande "git init"
• Créez un fichier README.md avec votre éditeur de texte préféré. Pour le contenu du fichier, mettez la date et l'heure à laquelle vous avez créé le fichier REAME.md
• Inspectez l'état du dépôt avec la commande "git status"
• Lisez les messages retournés par le "git status"

GIT - Status des fichiers

git status permet de voir l'état des fichiers dans le dossiers qui contient le dépôt.

L'état Stage correspond à la salle d'attente du commit. C'est dans le Stage qu'on accumule les changements pour un commit à apporter au dépôt.

Remarque : on peut voir le Stage comme la salle d'attente

GIT - Atelier 1 (2/9)

• Selon les instructions fournies par la commande "git status", ajoutez le fichier README.md dans le Stage avec la commande "git add"
• Consultez l'état du dépôt avec la commande "git status"
• Avec la commande "git commit", créez un commit. Un commit doit toujours être décrit par un message. Mettez la description "Create README.md"
• Vous avez créé votre premier commit ! Consultez l'état du dépôt avec la commande "git status"

GIT - Atelier 1 (3/9)

• Modifiez le contenu du fichier README.md en mettant l'heure qu'il est actuellement
• Consultez l'état du dépôt avec la commande "git status"
• Consultez les différences présentent dans le dépôt avec la commande "git diff"
• Selon les instructions fournies par la commande "git status", ajoutez les modifications du fichier README.md dans le Stage avec la commande "git add"
• Consultez les différences présentent dans le dépôt avec les commandes "git diff" et  "git status"
• Avec la commande "git commit", créez un commit avec la description "Update README.md"
• Consultez l'état du dépôt avec la commande "git status"

GIT - Atelier 1 (4/9)

• Modifiez le contenu du fichier README.md en mettant votre nom et prénom en dernière ligne du fichier
• Consultez l'état du dépôt avec la commande "git status"
• Selon les instructions fournies par la commande "git status", on pourrait à nouveau ajouter les modifications du dépôt avec "git add". Mais vu que le fichier README.md est tracké par le dépôt, on dit que ce fichier fait partie du dépôt, l'option "-a" de la commande "git commit" va nous faire gagner du temps
• Consultez l'aide de la commande commit avec l'option "--help" ("git commit --help") pour savoir à quoi sert l'option "-a"
• L'option "-m" de la command commit est très utile aussi
• Consultez l'aide de la commande commit avec l'option "--help" ("git commit --help") pour savoir à quoi sert l'option "-m"

GIT - Atelier 1 (5/9)

• Ajoutez les modifications du fichier README.md avec la commande "git commit -a -m 'Update README.md: add my name'"
• Consultez l'état du dépôt avec la commande "git status"

GIT - Atelier 1 (6/9)

• Dans le fichier README.md, supprimer la ligne qui contient votre nom et prénom
• Créer un nouveau fichier dont le nom est au format <nom-prenom>.txt
• Dans ce fichier, ajoutez la couleur de la mer rouge
• Consultez l'état du dépôt à l'aide de la commande "git status"
• Ajoutez les modifications actuelles dans le Stage. Si vous passez le chemin d'un dossier à la commande "git add", vous pouvez ajouter l'ensemble des modifications concernant ce dossier avec une seule commande. Pour le dossier courrant, vous pouvez utiliser vous pouvez utiliser : "git add ."

Zut, le dernier commit ne correspond pas aux modifications désirés : vous devez le modifier !

GIT - Atelier 1 (7/9)

• Consulter la documentation de la commande "git commit" pour savoir à quoi sert l'option "--amend"
• Pour modifier le "dernier" commit, utiliser l'option "--amend" de la commande "git commit". Dans notre cas "git commit --amend -m 'Amended commit: add new file <nom-prenom>.txt'"
• Consultez l'état du dépôt avec la commande "git status"

A retenir :

 - vous pouvez modifier un commit avec l'option "--amend"

Remarque :

Ici, la modification d'un commit s'est faite sur un commit qui n'était pas propagé sur un dépôt distant !

GIT - Atelier 1 (8/9)

• Tapez la commande "ls"
• Supprimez le fichier README.md avec la commande "git rm README.md"
• Tapez la commande "ls"
• Consultez l'état du dépôt à l'aide de la commande "git status"
• Selon les indications de la commande "git status", ajouter cette modification au dépôt avec la commande "git commit" avec la description "Delete README.md"
• Consultez l'état du dépôt à l'aide de la commande "git status"

Question : Combien de commit il y a-t-il dans ce dépôt ?

GIT - Atelier 1 (9/9)

• Consultez la documentation de la commande "git log" pour savoir à quoi sert cette commande
• Consultez les commits qui ont été fait avec la commande "git log"

Il est plus pratique de voir les commits réalisés dans un dépôt à l'aide d'outil graphique, dans notre cas, l'extension git-graph de VSCode.

• Ouvrez VSCode dans le dossier qui contient votre dépôt (commande "code . &")
• Ouvrir l'outil git-graph

l'historique des commits

GIT - Atelier 1 : recapitulatif

1. Vous avez manipulé les commandes suivantes :

• git init
• git status
• git add
• git commit

2. Vous savez travaillé sur 1 dépôt local sur 1 branche

3. Vous savez ajouter des modifications dans un dépôt : ajout, modification et suppression de fichier

4. Vous connaissez les différents états d'un fichier

5. La branche par défaut d'un dépôt s'appelle "main"

6. Vous savez consulter l'aide des commandes git

7. Vous pouvez visualiser l'historique des commits avec git-graph

• git log
• git rm

GIT - C'est quoi un Commit ?

GIT - Commit

Les propriétés d'un commit :

 - "stoque les différences" entre lui-même et le commit précédent;

 - est créé sur un ordinateur de développeur, localement;

 - est une "photographie" du dépôt dans un état donné;

 - peut avoir 0, 1 ou 2 commits parents;

 - est identifié par un hash, SHA1.

Pour qu'1 commit soit visible par d'autres développeurs, il faut qu'il soit accessible sur un serveur git, un dépôt git accessible en distanciel.

GIT - Atelier 2 (1/8)

• Copiez le dossier "atelier-1" dans un nouveau dossier "atelier-2" et déplacez vous dans ce-dernier
• Tapez la commande "ls"
• Consultez la documentation de  "git checkout"
• Récupérer le SHA1 du 1er commit de votre dépôt avec "git log" ou l'extension git-graph de VSCode
• Utilisez ce SHA1 avec "git checkout <SHA1>"
• Lisez le message produit par cette commande
• Visualisez l'historique des commits avec git-graph

A retenir :

 - le SHA1 est l'identifiant associé à un commit

 - vous pouvez vous déplacer dans l'historique des commits : 

les commits sont des "photographies" de l'état d'un dépôt !

GIT - Atelier 2 (2/8)

A retenir : 

 - une fois qu'un fichier est ajouté à un dépôt, il est très difficile de le supprimer du dépôt

• Après vous être déplacé sur le premier commit, listez les fichiers présents dans votre répertoire de travail avec la commande "ls"
• Déplacez-vous sur les différents commits et listez les fichiers

La référence "HEAD" nous permet de savoir où nous sommes dans l'historique des commits. C'est le "vous êtes ici" sur une carte. Après le premier commit, la référence "HEAD" est toujours quelque part dans l'historique des commits : elle référence toujours un commit.

GIT - Atelier 2 (3/8)

A retenir :

 - "git switch" est conçu pour se déplacer de branche en branche, contrairement à "git chechout"

• Consultez la documentation de "git branch"
• Consultez les branches qui sont de votre dépôt avec "git branch"
• Revenez sur la branche main de votre dépôt avec "git switch main"
• Consultez la branche sur laquelle vous êtes avec "git branch"
• Essayez d'utiliser la commande "git switch" pour vous déplacer sur le 1er commit

Lorsque vous utilisez la commande "git checkout" sur un SHA1, la référence "HEAD" n'est plus attachée à une branche.

GIT - Atelier 2 (4/8)

A retenir : 

Vous ne pouvez pas avoir de modifications en cours lorsque vous vous déplacez dans l'historique.

• Placez vous sur le commit amendé avec "git checkout"
• Mettez à jour l'heure du fichier README.md
• Consultez l'état du dépôt avec "git status"
• Essayez de revenir sur la branche principale avec "git switch main"
• Lisez le message produit par cette commande
• Restorez votre espace de travail à l'état du commit sur lequel vous êtes avec la commande "git checkout ."

GIT - Atelier 2 (5/8)

• Mettez à nouveau à jour l'heure du fichier README.md
• Consultez l'état du dépôt avec "git status"
• Restorez votre espace de travail à l'état du commit sur lequel vous êtes avec la commande "git restore README.md"

La commande checkout a plusieurs usages :

 - se déplacer dans l'historique des commits

 - restorer l'espace de travail à l'état du commit courant

Le fait que la commande "git checkout" ait plusieurs usages ne simplifie pas la prise en main.

A retenir : 

Avec les commandes "git switch" et "git restore", l'usage de "git checkout" est plus rare.

GIT - Atelier 2 (6/8)

A retenir :

 - vous pouvez déplacer une branche uniquement si vous n'êtes pas sur la branche

• Placez vous sur la branche "main" avec "git switch main"
• Visualisez l'historique de commits avec git-graph
• Consultez la documentation pour l'option "-f" de "git branch"
• Essayer de déplacer la branche "main" au niveau du 1er commit avec "git branch -f main <SHA1>"
• Lisez le message d'erreur de git

Les branches dans git sont des étiquettes dans l'historique de commit : on peut déplacer une branche !

GIT - Atelier 2 (7/8)

Que voyez vous dans git-graph ?

• Placez vous sur le 1er commit avec "git checkout <SHA1>"
• Visualisez votre historique git avec git-graph
• Consultez la documentation pour l'option "-f" de "git branch"
• Déplacez la branche "main" au niveau du 1er commit avec "git branch -f main <SHA1>"

A retenir :

 - le déplacement de branche peut conduire à la perte de commits

GIT - Le dossier .git

Lors de la création d'un nouveau dépôt avec "git init", un dossier ".git" est créé à la racine du dépôt.

C'est ce dossier qui permet à git de fonctionner. On peut dire que c'est la base de données de git. Il y stocke :

 - la configuration locale du dépôt;

 - les refs vers les dépôt distants;

 - les objets git qui représentent des commits, des dossiers ou des fichiers;

 - les hooks.

Si vous souhaitez savoir ce qui se trouve dans le dossier .git, vous trouverez une bonne introduction dans l'article Git from the Bottom Up.

GIT - Atelier 2 (8/8)

Attention :

Ces manipulations sont non-standards !

Elles sont exposées dans un but pédagogique. Vous ne devriez pas en arrivé là !

• Supprimez le dossier ".git" du dossier "atelier-2", "rm -rf .git"
• Copiez le dossier ".git" du dossier "atelier-1" dans le dossier "atelier-2"
• Visualisez l'historique de commits avec git-graph

GIT - Atelier 2 : recapitulatif

1. Vous avez manipulé les commandes suivantes :

• git checkout
• git branch

2. Vous pouvez vous déplacer sur les différents commits d'un dépôt

3. La référence HEAD stoque votre position dans l'historique des commits, sur une branche ou non

4. La commande "git checkout" a plusieurs cas d'usage et a mené à l'introduction d'autres commandes, comme "git switch" ou "git restore"

5. On peut déplacer une branche uniquement si on n'est pas sur celle-ci

6. Le déplacement de branche peut entrainer la perte de commits

7. Le dossier ".git" est la base de données de git

• git restore
• git switch

GITHUB - Dépot distant

Les fonctionnalités essentielles des dépôts distants sont :

• la sauvegarde du code ailleurs que sur sa machine en local
• le partage le travail avec d'autres développeurs
• la possibilité de faire des revus de code avec des Merge Request
• utilisé un gestionnaire de tickets intégré à la plateforme, Issue
• la possibilité de créer des forks, copie d'un dépôt principal, en un clin d'oeil

GITHUB - A quoi sert les cles ssh ?

Les clés SSH sont une paire de clé publique/clé privée.

La plateforme Github utilise votre clé publique pour vous authentifier : c'est votre clé SSH qui vous permet de faire des modification sur vos dépôt.

GIT/GITHUB - Atelier 3 (1/3)

• Depuis votre compte Github, créez un nouveau dépôt "atelier-3"
• Déplacez vous dans le répertoire qui contient les dépôt "atelier-1" et "atelier-2"
• Récupérer le dépôt avec "git clone <URL>" du dépôt Github
• Déplacez vous dans le dossier "atelier-3"
• Listez les dépôts distants avec "git remote -vv"
• Faites de même pour les dossier "atelier-1" et "atelier-2"

A retenir :

 - généralement, un dépôt distant est configuré pour un dépôt local, mais ce n'est pas une obligation

GIT/GITHUB - Atelier 3 (2/3)

• Refaire toutes les étapes de l' "Atelier 1" MAIS après chaque commit, utiliser "git push" pour mettre à jour le dépôt distant
• Consultez la page d'accueil de votre dépôt Github après chaque "git push", vous devriez pouvoir vérifier que votre dernier commit est bien arrivé sur le dépôt Github

Question :

A quelle étape de l' "Atelier 1" est-ce que "git push" vous retourne un message d'erreur ?

Indice : au moment du amend pour modifier un commit, vous devriez quelque chose de curieux dans le git-graph

Lorsque vous tentez de pousser vos modifications, vous devriez avoir un message d'erreur similaire :

• Consultez l'option "-f" de "git push"
• Mettez à jour la branche "main" distante avec "git push -f"

git indique qu'il y a une divergence et propose de faire un "git pull" pour récupérer les modifications de "la branche distante". MAIS ce n'est pas ce qu'on souhaite ici. On veut mettre à jour le dépôt distant avec l'état de notre branche "main" locale.

GIT/GITHUB - Atelier 3 (3/3)

GIT/GITHUB - les 3 types de branche

Branche sur un dépôt distant

Référence locale d'une branche distante

Branche locale

Source

GIT/GITHUB - divergence non visible localement

Les branches distante et local "master" ont évolué, mais localement la référence "origin/master" n'a pas bougé

GIT/GITHUB - divergence

"git fetch" permet de mettre à jour les références locales

GIT/GITHUB - Resolution de divergence

Il y a 3 moyens pour résoudre une divergence :

 - "git push -f" : réserver au cas où vous êtes seul à travailler sur la branche divergente

 - "git merge" : fusion des développement, peut engendrer des conflits à résoudre

 - "git rebase" : réapplication des commits, peut engendrer des conflits à résoudre

GIT - Atelier 3 : recapitulatif

1. Les commandes git découvertes dans cet atelier :

• git push
• git fetch

2. Vous savez travaillé sur 1 dépôt distant sur 1 branche

3. Sur Github, le contenu fichier README.md à la racine d'un dépôt est affiché sur sa page d'accueil

3. Vous savez identifier une divergence de branche

4. La commande "git push" permet de mettre à jour une branche distante

5. La commande "git fetch" permet de mettre à jour les références locales de branches distantes

GIT - WORkFLOW

Github - leS workshopS

• Comment se manifeste l'aspect décentralisé dans les commandes git ?
• Le commit : la brique de base
• Comprendre de l'historique des commits d'un dépôt

la théorie

• Outil pour visualiser l'historique : Git Graph par exemple
• Faire des branches et des merges sur des mini-projets
• Quelles sont les bonnes pratiques pour miniser les conflits ?
• Appliquer le GitHub flow : workflow proposé par github

workshop (1/4)

Immersion dans le développement collaboratif avec la mise à jour d'un fichier texte.

WORKSHOP 0

Chat online

Au besoin, pour partager des informations simplement, vous pouvez utiliser un chat en ligne.

• La mise au tour par tour nécessité de la synchronisation entre les développeurs
• Cela ne permet pas de distribuer le travail en parallèle

workshop (2/4)

Mieux collaborer grâce aux branches.

Les branches git peuvent être vues comme des étiquettes que l'on place dans l'historique de commits.

Mieux mettre à jour un fichier texte grâce aux les branches git (et leur résolution de conflit 😉)

Ce workshop vous permettra d'utiliser la commande "git merge" pour mettre merger une branche dans une autre.

WORKSHOP 1

workshop (3/4)

Lorsque vous utilisez un dépôt Github, les merges sur la branche main ne se font généralement pas en local. Github permet d'outil des Pull Request, ce qui permet aussi de faire de la revue de code.

Mieux mettre à jour un fichier texte grâce aux Pull Requests.

WORKSHOP 2

workshop (4/4)

L'utilisation de "git merge" pour :

• intégrer des modifications dans la branche main
• résoudre des conflits sur les branches de développement

peut rendre l'interprétation de l'historique des commits compliquée.

Pour pallier à cette difficulté, il est possible  d'utiliser "git rebase" pour linéariser en partie l'historique des commits.

WORKSHOP 3

La méthode github flow - Extrait

1. A short, descriptive branch name enables your collaborators to see ongoing work at a glance.
2. Give each commit a descriptive message to help you and future contributors understand what changes the commit contains.
3. Ideally, each commit contains an isolated, complete change.
4. By committing and pushing your changes, you back up your work to remote storage.
5. Create a pull request to ask collaborators for feedback on your changes.
6. Once your pull request is approved, merge your pull request.
7. After you merge your pull request, delete your branch.

GIT - Merge VS rebase

Relève de la politique de développement, de l'équipe de développement.

Pro du merge : commande simple, génère généralement moins de conflit.

Con du merge : créer un historique qui peut être compliqué à relire.

Pro du rebase : simplifie l'historique.

Con du rebase : si une branche est déjà partager, il est déconseillé de faire des rebases. Sous entendu, le rebase est licite uniquement sur des branches locales.

workshop - MA recommadation

1. Privilégier les branches
   courtes en temps

Une branche qui dure 2 jours, c'est parfait.

Si elle peut être plus courte, c'est mieux encore.

workshop - Bonus 1

Jongler avec les commits :

• git commit --amend
• git cherry-pick
• git rebase -i

Demo live

workshop - Bonus 2

Configurer plusieurs remotes.

Lorsque vous travaillez depuis un fork, vous aurez besoin de récupérer les mise à jour qui sont faites depuis le dépôt parent de votre fork.

Sur un des dépôts précédents, configurez le dépôt à partir duquel vous avez le fork comme un dépôt distant. Donnez lui le nom "official" pour le distinguer de votre remote actuel, "origin".

• git remote

Demo live

workshop - Bonus 3

Pour comparer l'état d'un projet à différents points de l'historique des commits, il est nécessaire d'avoir un outil externe qui permet de comparer des dossier.

J'utilise l'outil meld pour se faire et la commande suivante :

• git difftool --dir-diff

Il est nécessaire de configurer correctement l'environnement git pour qu'il utilise le bon outil de comparaison.

Demo live

workshop - Bonus 4

Quand vous ajoutez un commit sans l'option "-m", il y a un éditeur par défaut qui apparaît (nano, vim, etc...). Pour changer l'éditeur par défaut, vous pouvez ajuster la variable d'environnement GIT_EDITOR.

Ex : export GIT_EDITOR=gedit

Demo live

workshop - Bonus Github

Lorsque que vous êtes sur la page d'un dépôt Github, si vous appuyez sur ".", cela ouvre une version en ligne de VSCode dans le navigateur.

Ca peut être pratique pour explorer plus rapidement et simplement un projet sans devoir le cloner.

Demo live

workshop - Bonus git alias

Le terminal "zsh" avec l'extension "oh-my-zsh" installe par défaut une quantité d'alias pour git. Vous pouvez les consulter avec la commande :

Si vous n'avez pas "oh-my-zsh" d'installer, vous pouvez consulter les alias dans leur dépôt.

Vous pouvez aussi définir vos alias dans votre fichier de configuration git :

GIT - config

Pour pouvoir faire des commit, git exige que vous ayez votre username et email configuré localement sur votre machine. 

Les configurations git sont hiérarchisées dans 3 fichiers de configuration :

 - local au dépôt ".git/config", git config --local

 - pour un utilisateur "~/.gitconfig", git config --global

 - pour le system "/etc/gitconfig", git config --system.

Pour lister les configurations pour un dépôt : git config -l

A faire :

• Utiliser git config pour changer un élément de configuration au niveau local et global, par exemple "push.autoSetupRemote" pour voir la hierarchisation des configuration

GIT - .gitignore

Le fichier .gitignore permet de configurer les fichiers/dossiers qu'on souhaite ignorer dans le dépôt.

A faire :

• Créez un dossier .gitignore où vous précisez que vous ignorez le dossier "tmp"
• Consultez l'état du dépôt avec "git status"
• Modifiez le fichier ".gitignore" pour faire apparaître et disparaître les messages de "git status" par rapport au dossier "tmp"

GIT - Jeu interactif

La popularité de git à mener à le construction de jeu interactif pour apprendre à l'utiliser. La notion de branche est une des première notion difficile à appréhender de git.

Learn Git Branching

A faire :

Réaliser les 2 premiers niveaux de "Introduction Sequence" de "Learn Git Branching"

GIT - Commit Description

Pour se retrouver rapidement lorsque vous lisez l'historique de commits d'un dépôt, les descriptions des commits sont très utiles.

Dépendant des dépôts, des conventions peuvent être mise en place.

A faire :

Lire cet article pour s'imprégner d'une façon de faire.

GIT - VSCode (1/2)

git est intégrer par défaut à VSCode.

A faire :

Reprenez le workshop 0 et faite un commit en utilisant l'intégration de git dans VSCode.

La description du commit devra avoir un sujet et un corps de message.

GIT - VSCode (2/2)

L'extension git graph ne sert pas uniquement à visualiser l'historique de commits. Il permet, entre autres, de se déplacer de l'historique de commits avec un checkout, de créer des branches, de merger une branche dans une autre, de faire des rebases, etc...

A faire :

Reprenez le workshop 1 :

• utilisez l'ingration de git pour créer vos commits
• utiliser git-graph pour créer vos branches et mergez vos branches dans la branche principale

GITHUB - CI/CD

L'intégration continue, ou Continuous Integration (CI), et la livraison continue, ou Continuous Delivery (CD) font maintenant partie des pratiques du développement logiciel.

L'intégration continue consiste à mettre en place des tests automatisés dans un dépôt.

La livraison continue consiste à mettre en place des mise à jour automisées de fichiers binaires ou le déploiement d'une application web en fonction de la réussite de l'étape d'intégration continue.

Cela permet d'assurer la qualité du logiciel et de réduire le temps entre le développement de fonctionnalité et leur utilisation par les clients.

GITHUB - Github Action (1/2)

Sur Github, les Github Actions permettent, à travers des fichiers de configurations dans le dépôt, de mettre en place ces pratiques.

Depuis janvier 2024, Github propose des certifications par rapport à l'utilisation de sa plateforme.

La 1ère étape consiste à mettre en place 1 worflow avec 1 job.

A faire :

• Suivre le module Automate development tasks by using GitHub Actions pour vous familiarisez avec le concept de Workflow
• Réaliser leur exercice d'introduction soumis sous forme de dépôt pour voir une première mise en application de Workflow

GITHUB - Github Action (2/2)

La 2ième étape consiste à découvrir comment configurer plusieurs jobs dans un workflow. Les jobs peuvent s'exécuter en parallèle ou en série s'ils dépendent les uns des autres.

A faire :

• Suivre le module Build continuous integration (CI) workflows by using GitHub Actions pour vous familiarisez avec la notion de dépendance entre les jobs
• Réaliser leur exercice associé à cette notion de dépendance

GITHUB - Github Action Application

Vous savez maintenant mettre un place un workflow sur un dépôt Github.

A faire :

• Proposer un worflow à mettre en place sur le workshop 4 de ce cours. Cela peut être le nombre d'auteur présent dans le fichier "authors.txt" par exemple.
• Implémenter ce workflow dans votre dépôt du workshop 4

GIT - Fonctionnement interne

GIT - un commit en détail (1/2)

Source : Page 62 de Git going with DVCS

GIT - un commit en détail (2/2)

Source : Page 97 de Git going with DVCS

Advanced Git TUtorial

GIT - Les branching modèles

Beaucoup de choix possibles pour le modèles de développement d'un projet :

 - faire une branche par feature,

 - faire une branche par équipe,

 - faire une branche par personne,

 - utiliser uniquement des merges, ou uniquement des rebase,

 - créer des tags pour identifier des releases,

 - utiliser des forks pour développement donc un fork par personne,

 - etc

Workflow alternatif

GIT - pretty log

Il est parfois utile d'avoir un affiche de la commande "git log" qui soit plus visuellement simple à interpréter.

Vous pouvez définir un alias à cet effet :

Une fois que votre alias est défini, ici "lg", vous pouvez l'utiliser avec la commande suivante :

GIT - TUtoriel

git propose des commandes intégrées pour apprendre à l'utiliser :