= Git : versionner ses sources = <> ---- == INTRODUCTION == * Objectifs : * connaître les commandes de base pour participer à un projet AUF * [[Git/Développeur|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 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/espace-formation }}} == 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 {{{espace-formation}}} * 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 : [[http://git.auf.org|Dépôt AUF]] * d'autres projets Open source : [[https://github.com/|GitHub]] * Explorer au besoin le [[http://git-scm.com/documentation|Site officiel]], notamment sa [[http://git-scm.com/documentation|documentation]] ----