Git : versionner ses sources

INTRODUCTION

• Objectifs :
  • connaître les commandes de base pour participer à un projet AUF

• Documentation AUF

• Environnement technique :
  • git-core
  • 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
  • git init
    • .git créé
  • .gitignore : suivre le modèle
  • git status
  • git add
• Amorcer le suivi
  • git commit
  • 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

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

    git clone ssh://gitosis@git.auf/espace-formation.git

  • git config
• Initialiser un dépôt git (pas fait dans l'atelier)
  • git config
  • git push

PROCESSUS DE VERSIONNAGE

• Éditer l'arborescence du projet
• git status
• git add
• git rm
• git commit
• git pull
• git push

BRANCHES

• Créer en local
  • git branch
  • créer en local à partir du serveur
    • git branch -t
• Créer sur serveur
  • git push
• Changer de branche
  • git checkout
• Fusionner les branches
  • git merge
• Conflits
• Supprimer en local
  • git branch
• Supprimer sur serveur
  • git push

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

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