GIT en mode collaboratif

Ou plus exactement git en mode collaboratif, sans push, et en forçant les responsables à relire le code…

Gros programme… Mais si il y a un scm qui permet cela facilement c’est bien GIT. Voici donc un exemple complet expliquant aux développeur voulant débuter avec GIT comment utiliser les clones et les branches. Ont retrouve dans cet exemple deux intervenants, le developpeur lead qui est responsable du code et de sa relecture et le developpeur qui va faire les modifications.

Les avantages de l’utilisation décrite si dessous sont les suivants :

  • Pas de PUSH, et donc pas de PULLs risqués, en effet les développeurs qui viennent de SVN ont souvent au début le reflex de remplacer le svn commit par un git commit et git push affin de publier leur modif. On se retrouve alors avec des git pull difficile à gérer, et on a alors recours a git cherry-pick qui est franchement pénible à utiliser.
  • Le développeur lead est obligé de vérifier le travail du dev (et ca c’est bien

Création du projet

Premièrement, créons un projet…

guil@laptop:~/dev$ mkdir -p project/trunk

guil@laptop:~/dev$ cd project/trunk

guil@laptop:~/dev/project/trunk$ git init
Initialized empty Git repository in /home/gluchet/dev/project/trunk/.git/

Chaque projet a besoin d’un fichier README, ont prend donc un puissant éditeur de texte, vim (troll inside),  pour en créer un…

guil@laptop:~/dev/project/trunk$ vim README.txt

Voyons ce que donne une des commandes de base de git « git status ». Status affiche le… status du répertoire, les fichiers ajoutés, supprimés, à commité, etc

guil@laptop:~/dev/project/trunk$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
# README.txt
nothing added to commit but untracked files present (use "git add" to track)

il nous dit d’ajouter le fichier, on obéit…

guil@laptop:~/dev/project/trunk$ git add README.txt

Maintenant il dit quoi ?

guil@laptop:~/dev/project/trunk$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# new file:   README.txt
#

« Changes to be committed », ok on commit…

guil@laptop:~/dev/project/trunk$ git commit -m 'initial commit' README.txt
[master (root-commit) 90bd4da] initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README.txt

Créer les clones

Maintenant le travail va commencer, il nous faut cloner le dépôt. Pour le devlead, on clone le trunk…

guil@laptop:~/dev/project$ git clone trunk/.git devlead
Initialized empty Git repository in /home/gluchet/dev/project/devlead/.git/

Pour le dev, on clone le devlead…

guil@laptop:~/dev/project$ git clone devlead/.git dev1
Initialized empty Git repository in /home/gluchet/dev/project/dev1/.git/

Contrairement à svn où l’on fait de multiple checkout d’un dépôt, on se retrouve ici avec une arborescence plus proche d’un arbre généalogique.

Et on a donc les répertoires suivants…

guil@laptop:~/dev/project$ ls
dev1  devlead  trunk

Le dev travaille

Il faut maintenant commencer à coder… Quelles branches sont dispo…

guil@laptop:~/dev/project/dev1$ git branch
* master

On crée une branche pour la nouvelle feature…

guil@laptop:~/dev/project/dev1$ git branch issue1

guil@laptop:~/dev/project/dev1$ git checkout issue1
Switched to branch 'issue1'

guil@laptop:~/dev/project/dev1$ git branch
* issue1
  master

L’étoile devant le nom de la branche indique la branche active.

On modifie des trucs, toujours avec vim (troll again ?), puis on commit…

guil@laptop:~/dev/project/dev1$ git status
# On branch issue1
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   README.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

guil@laptop:~/dev/project/dev1$ git add README.txt

guil@laptop:~/dev/project/dev1$ git commit -m 'Fix the issue1' README.txt
[issue1 ad0e465] Fix the issue1
 1 files changed, 3 insertions(+), 0 deletions(-)

Arriver là le dev doit juste informer le dev lead qu’il a implémenter le truc ds la branche « isseu1″ de son clone. Pour ca il peut envoyer un mail, un sms, un tweet, lui taper sur l’épaule, laisser un post-it sur sa tasse de café, ou utiliser je ne sais quelle autre méthode de communication.

Le dev lead récup les commits du dev

On repasse au point de vue dev lead, dans son clone, le fichier README.txt est toujours l’ancien…

guil@laptop:~/dev/project/devlead$ more README.txt 
This is my project README file

Le dev lead va créer une branche pour récupérer les modifs du dev sans pourrir tout son clone…

guil@laptop:~/dev/project/devlead$ git branch issue1bydev1

guil@laptop:~/dev/project/devlead$ git checkout issue1bydev1 
Switched to branch 'issue1bydev1'

guil@laptop:~/dev/project/devlead$ git branch
* issue1bydev1
  master

Reste plus qu’à récup les commits du dev… on prend les commit dans la branche issue1 du repertoire dev1 et on les met ds la branche courante…

guil@laptop:~/dev/project/devlead$ git pull ../dev1 issue1
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../dev1
 * branch            issue1     -> FETCH_HEAD
Updating 90bd4da..ad0e465
Fast-forward
 README.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

On vérifie le code

guil@laptop:~/dev/project/devlead$ more README.txt 
This is my project README file

you can install this amazing software using the Makefile (as soon as it will be
available)

Le dev lead merge les modifs

Le dev lead a peut être modifié le code en vérifiant le travail du dev, on vérifie…

guil@laptop:~/dev/project/devlead$ git status
# On branch issue1bydev1
nothing to commit (working directory clean)

Tout est ok, le dev lead peut merger sur son master, on repasse sur la branche master…

guil@laptop:~/dev/project/devlead$ git checkout master
Switched to branch 'master'

Vous vous souvenez du contenu du fichier README ? (regardez plus haut dans la branche issue1bydev1). Il est différent sur la branche master…

guil@laptop:~/dev/project/devlead$ more README.txt 
This is my project README file

On merge la branche issue1bydev1 ds la branche courante (master)…

guil@laptop:~/dev/project/devlead$ git merge issue1bydev1
Updating 90bd4da..ad0e465
Fast-forward
 README.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

On vérifie le résultat du merge, le fichier README.txt a changé…

guil@laptop:~/dev/project/devlead$ more README.txt 
This is my project README file

you can install this amazing software using the Makefile (as soon as it will be
available)

On peut supprimer la branche utilisé pour récupérer les commits du dev…

guil@laptop:~/dev/project/devlead$ git branch -d issue1bydev1
Deleted branch issue1bydev1 (was ad0e465).
guil@laptop:~/dev/project/devlead$ git branch
* master

Le dev lead met à jour le trunk

Maintenant la modification peut être intégré au trunk, ce qui permettra à tous ceux qui ont cloner le trunk de la récupérer….

guil@laptop:~/dev/project/trunk$ git pull ../devlead master
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../devlead
 * branch            master     -> FETCH_HEAD
Updating 90bd4da..ad0e465
Fast-forward
 README.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Le dev met régulièrement son clone à jour

Que se passe-t-il pour le dev ? Ds quel état sont ses branches…

guil@laptop:~/dev/project/dev1$ git branch
* issue1
  master

guil@laptop:~/dev/project/dev1$ git checkout master
Switched to branch 'master'

guil@laptop:~/dev/project/dev1$ git branch
  issue1
* master

Le fichier README.txt est toujours l’ancien… Normal le dev n’a pas mergé les modifications faites dans la branche issue1…

guil@laptop:~/dev/project/dev1$ more README.txt 
This is my project README file

Essayons un pull…

guil@laptop:~/dev/project/dev1$ git pull
From /home/gluchet/dev/project/devlead/
   90bd4da..ad0e465  master     -> origin/master
Updating 90bd4da..ad0e465
Fast-forward
 README.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Oh! Mes modifications ont été vérifiées et acceptées! Elles apparaissent…

guil@laptop:~/dev/project/dev1$ more README.txt 
This is my project README file

you can install this amazing software using the Makefile (as soon as it will be
available)

About the Author: Guillaume Luchet

Guillaume Luchet est Directeur de la R&D et Lead Développeur chez Bilendi Technology, entrepreneur et développeur freelance.