Git : versionner ses sources

INTRODUCTION

• Objectifs :
  • Savoir gérer un dépôt git local
  • Savoir gérer des évolutions parallèles avec les branches
  • Savoir les usages de base pour le suivi des serveurs à l'AUF

• Documentation AUF

• Environnement technique :
  • git
  • gitk
• Pourquoi versionner?
  • historique : voir versions passées
  • expérimentation : explorer une nouvelle version possible
  • travail collaboratif : travail sur versions en parallèle (en local, sur branches...) puis fusion des versions
• Pourquoi Git?
  • nouvelle génération
  • distribué (local, hors-ligne)

VERSIONNER EN LOCAL

• Initialiser un dépôt git
  • créer un répertoire en local et s'y déplacer

    mkdir atelier
    cd atelier

  • initialiser un dépôt vierge

    git init

    • .git créé = tout le dépôt en local
  • vérifier l'état du dépôt

    git status

  • créer du contenu (un répertoire et un fichier) sous atelier

  • créer le fichier caché commandant à git d'ignorer certains fichiers ou répertoires

    • .gitignore : suivre le modèle

  • ajouter les fichiers et répertoires à l'index de git

    git add .

• Amorcer le suivi
  • engager ses changements

    git commit -a -m "message de commit"

  • vérifier le journal des commits

    git log

  • vérifier l'historique des versions (commits)

    gitk

INTERFACE WEB DU SERVEUR

• projets
• shortlog
  • liste de commits
  • tag master = head master
• commit
  • hash identifiant commit et son parent
  • diff, blob, (blame), history (+ diff to current)
• commitdiff
• tree : l'arborescence des sources (web)
• snapshot : les sources (téléchargement)
• heads (= branches)

VERSIONNER SUR SERVEUR

• Initialiser un dépôt git sur le serveur (pas fait dans l'atelier)

  • configurer en local l'URL où sera le dépôt sur serveur

    git config remote.origin.url ssh://gitosis@git.auf/atelier

  • pousser sur le serveur son code local

    git push origin master

• Récupérer localement un dépôt git existant sur serveur (qui n'a pas encore été récupéré)

  git clone ssh://gitosis@git.auf/bacasable

PROCESSUS DE VERSIONNAGE

• vérifier l'état du dépôt local

  git status

• tirer en local la dernière version du serveur

  git pull

• éditer l'arborescence du projet
• au besoin, ajouter les fichiers et répertoires à l'index de git

  git add .

• au besoin, supprimer des fichiers ou répertoires de l'index de git

  git rm nom_fichier

• engager ses changements

  git commit -a -m "message significatif de commit"

• s'assurer d'avoir la dernière version avant de pousser

  git pull

• pousser sa nouvelle version locale sur le serveur

  git push

EXERCICE TRAVAIL COLLABORATIF

• S'assurer d'avoir cloné le dépôt bacasable

• Ajouter un fichier portant votre prénom à la racine du projet : ex.: thomas.txt

• Commiter la modification
• Pusher le commit sur le serveur
• Puller la dernière version du serveur
• Vérifier les commits sur le web et dans gitk
• Modifier le fichier indiqué par le présentateur de l'atelier
• Commiter, pusher
• Régler un conflit :
  • Éditer la ligne du fichier indiqué par le présentateur de l'atelier
  • Essayer de pusher à son signal
  • Puller à son signal
  • Régler le conflit (édition version finale voulue)
  • Commiter, pusher

BRANCHES

Des branches pour faire évoluer le code en parallèle...

Ex.: pour expérimenter (nouvelle fonctionnalité) ou gérer différents degrés de maturé du code (workflow de développement)

• Lister les branches

  Branche en cours = précédée d'astérisque

  • locales

    git branch

  • distantes (remotes)

    git branch -r

  • toutes (all)

    git branch -a

• Créer en local
  • créer branche neuve à partir du commit en cours

    git branch mabranchelocale

  • créer branche en local à partir du serveur

    git branch mabranchelocale -t labrancheserveur

• Créer sur serveur

  git push origin labrancheserveur

• Configurer la branche

  git config branch.mabranchelocale.remote origin
  git config branch.mabranchelocale.merge refs/heads/mabrancheserveur

• Changer de branche

  git checkout verscetteautrebranche

  Se lit: "Je fais le checkout de la branche en cours pour aller vers cette autre branche"

• Fusionner les branches

  git merge cetteautrebrancheici

  Se lit: "Je fusionne ici la branche en cours avec cette autre branche"

  • Fusion pas symétrique :

    (branche1) git merge branche2 ≠ (branche2) git merge branche1

• Conflits
• Supprimer en local

  git branch -d mabranchelocale

• Supprimer sur serveur

  git push :labrancheserveur

EXERCICE BRANCHES

• Vérifier qu'aucune branche n'existe sur le serveur nommée avec votre prénom
• Créer une branche locale perso nommée avec votre prénom (ou autre si existe déjà) : ex.: thomas
• Vérifier la création de la branche locale dans gitk
• Mettre cette nouvelle branche sur le serveur
• Vérifier la création de la branche distante sur le web et dans gitk

• Configurer votre branche pour pouvoir puller et pusher directement (sans ajouter origin labrancheserveur)

• Attendre les instructions du release manager (ici = présentateur) pour fusionner la branche master à jour dans votre branche perso

• Mettre à jour votre branche perso sur le serveur
• Trouver un collègue et faites en sorte que vos 2 branches soient identiques :
  • Copier en local la branche du collègue
  • Fusionner la branche du collègue avec la vôtre
  • Seulement l'un de vous met sa branche perso fusionnée sur le serveur
  • Vérifier l'asymétrie : seulement une branche inclut l'autre
  • Le second met sa branche perso fusionnée sur le serveur
  • Vérifier la symétrie : les 2 tags verts sont sur le même commit

WORKFLOW DE DÉVELOPPEMENT

• Développement (branch dev, environnement DEV)
  • développement dans environnement DEV (local)

  • branche dev : code stable développé

  • validation informatique du release
• Tests (branch test, environnement TEST)
  • merge de branche dev dans la branch test

  • branche test : code stable à tester par responsables métier

  • déploiement dans environnement de TEST (serveur, identique à PROD)
  • validation métier du release
• Production (branch master, environnement PROD)
  • merge de branch test dans la branch master

  • branch master : code stable validé

  • déploiement dans environnement de PROD
  • utilisation par utilisateurs finaux

Convention : la branche master fait toujours autorité.

CONCLUSION

• Tout projet doit être versionné sur le dépôt central (privé ou public)
• Aller plus loin :
  • Participer aux projets

    • de l'AUF : Dépôt AUF

    • d'autres projets Open source : GitHub

  • Explorer au besoin le Site officiel, notamment sa documentation