Domaines

À propos

Contactez-nous

Crédits & mentions légales

Devenez auteur

Les Éditions Diamond recrutent

Liste des sondages de nos magazines

Logo / Bannières

Recherche par auteur

1. Préambule

1.1 Note

Pinpin n’est pas sain d’esprit, mais on l’aime quand même beaucoup.

1.2 Historique

Git est un gestionnaire de configuration (j’ai horreur de ce terme). Il fut l’enfant prodigue de Linus Torvalds (vous savez le gars qui a commencé Linux), puis son développement est passé dans les mains d’un autre développeur (Junio C Hamano) et d’une équipe toujours très active. Il est basé sur un modèle décentralisé (comme SVK, GNU/Arch ou Mercurial et d’autres) et ses fonctionnalités sont inspirées de celles de Bitkeeper (l’outil propriétaire utilisé précédemment par l’équipe principale de Linux), ainsi que des besoins des différents développeurs l’utilisant. Il est devenu assez populaire. Ces temps derniers, certains projets ont migré de CVS ou SVN à Git. Cet article se veut une introduction pratique à Git. Il est la seconde édition du howto que j’avais écrit lors de mes premières utilisations de celui-ci. Sur un ton plus sérieux et un contenu révisé, il devrait vous fournir les notions nécessaires à une utilisation de Git dans la plupart des cas et dans les petits écarts que vous pourriez réaliser. Il est basé sur la documentation officielle de Git, disponible sur le site http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

1.3 Syntaxe

Au cours de cette documentation, il sera utilisé différentes conventions typographiques :

Dans les paragraphes de texte, les commandes citées le seront en gras, comme : git add ou git commit.
Lors de l’utilisation de mots anglais ou de termes techniques, ceux ci seront mis en italique, comme merger.
les exemples de code seront présentés de la façon suivante :

[user]
        name = theo
        email = theo@poisson.piquant.ca

[user]

name = theo

email = theo@poisson.piquant.ca

2. Utilisation de base

Git fonctionne en mode décentralisé, et propose évidemment les fonctions classiques : diff, commit, patch, branch sans être relié à un serveur qui centralise tout ça. Ce qui est un très bon point pour ceux qui veulent tirer profit des avantages d’un SCM à tout moment, même lorsqu’ils ne sont pas connectés à Internet ou au réseau sur lequel ils travaillent.

2.1 Restons courtois

Avant de faire quoi que ce soit, il est important de toujours se présenter aux gens que l’on rencontre. Pour Git, il suffit de créer ou d’éditer le fichier .gitconfig dans votre home directory et de le remplir de la façon suivante :

 [user]
        name = ange
        email = ange@poisson.piquant.ca

[user]

name = ange

email = ange@poisson.piquant.ca

2.2 Création du dépôt

On commence donc un nouveau projet, un peu de C pour se faire mousser, et on va gérer ça avec Git. Il suffit donc de créer un dépôt vierge :

$> cd && cd projets
$> mkdir c_101
$> cd c_101
$> git init

$> cd && cd projets

$> mkdir c_101

$> cd c_101

$> git init

2.3 Premières lignes

Tout d’abord, nous allons faire un bête code C qui affiche une ligne et se termine. Nous l’appellerons main.c.

#include <stdio.h>
int main(int argc, char *argv[])
{
        if (argc >= 1)
                printf(«you entered something : %s\r\n», argv[1]);
        return (0);
}

#include <stdio.h>

int main(int argc, char *argv[])

{

if (argc >= 1)

printf(«you entered something : %s\r\n», argv[1]);

return (0);

}

Déjà, Git peut nous indiquer des choses et nous dire que, par exemple, il a vu qu’il y avait un fichier qu’il ne connaissait pas dans le répertoire qu’il est censé gérer. Tout cela est visible avec la commande git status :

$> git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use «git add <file>...» to include in what will be committed)
#
#       main.c
nothing added to commit but untracked files present (use «git add» to track)

$> git status

# On branch master

# Initial commit

# Untracked files:

# (use «git add <file>...» to include in what will be committed)

# main.c

nothing added to commit but untracked files present (use «git add» to track)

Le monsieur est bavard en effet. Il nous dit tout d’abord que nous utilisons la branche master (la branche par défaut), puis que nous sommes au commit initial, et qu’il y a un fichier qui n’est pas suivi. Résolvons donc ce problème tout de suite en disant à Git de le gérer. Il faut utiliser la commande git add fichier pour cela :

$> git add main.c
$> git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use «git rm --cached <file>...» to unstage)
#
#       new file: main.c
#

$> git add main.c

$> git status

# On branch master

# Initial commit

# Changes to be committed:

# (use «git rm --cached <file>...» to unstage)

# new file: main.c

Ok, le fichier est géré, et Git nous informe que le prochain commit inclura les changements faits à ce fichier. Il nous faut donc faire un commit en utilisant git commit.

$> git commit -m «first commit, basic functionnality»
Created initial commit b2a44cb: first commit, basic functionnality
 1 files changed, 7 insertions(+), 0 deletions(-)
 create mode 100644 main.c
$> git status
# On branch master
nothing to commit (working directory clean)

$> git commit -m «first commit, basic functionnality»

Created initial commit b2a44cb: first commit, basic functionnality

1 files changed, 7 insertions(+), 0 deletions(-)

create mode 100644 main.c

$> git status

# On branch master

nothing to commit (working directory clean)

L’option -m de git commit permet de passer directement le commentaire de commit. En l’absence de cette option, Git lancera votre éditeur préféré et reprendra la main une fois celui-ci quitté. Note: Si ce n’est pas déjà fait, prenez l’habitude d’écrire des commentaires de commit et si possible en anglais. À quelques exceptions près (une doc en français par exemple), ça ne mange pas de pain de le faire et ça facilite les développements futurs. Merci.

2.4 Rajouts, diff et nouveau commit

Afin de rajouter du piment et tester de nouvelles commandes, nous allons éditer le fichier main.c à nouveau :

#include <stdio.h>
int main(int argc, char *argv[])
{
        int i;
        for(i = 0; i < 5; i++) {
                if (argc >= 1)
                        printf(«you entered something : %s\r\n», argv[1]);
        }
        return (0);
}

#include <stdio.h>

int main(int argc, char *argv[])

{

int i;

for(i = 0; i < 5; i++) {

if (argc >= 1)

printf(«you entered something : %s\r\n», argv[1]);

}

return (0);

}

Jetons un œil à une commande que vous risquez d’utiliser souvent : git diff.

 $> git diff
diff --git a/main.c b/main.c
index b78d36e..429f1f9 100644
--- a/main.c
+++ b/main.c
@@ -1,7 +1,11 @@
#include <stdio.h>
 int main(int argc, char *argv[])
{
-        if (argc >= 1)
-                printf(«you entered something : %s\r\n», argv[1]);
+       int i;
+
+       for(i = 0; i < 5; i++) {
+               if (argc >= 1)
+                       printf(«you entered something : %s\r\n», argv[1]);
+       }
         return (0);
}

$> git diff

diff --git a/main.c b/main.c

index b78d36e..429f1f9 100644

--- a/main.c

+++ b/main.c

@@ -1,7 +1,11 @@

#include <stdio.h>

int main(int argc, char *argv[])

{

- if (argc >= 1)

- printf(«you entered something : %s\r\n», argv[1]);

+ int i;

+ for(i = 0; i < 5; i++) {

+ if (argc >= 1)

+ printf(«you entered something : %s\r\n», argv[1]);

+ }

return (0);

}

Pas mal, hein ? Il va donc falloir commiter ces changements, mais avant tout, vérifions avec git status où nous en sommes.

$> git status
# On branch master
# Changed but not updated:
#   (use «git add <file>...» to update what will be committed)
#
#       modified:   main.c
#
no changes added to commit (use «git add» and/or «git commit -a»)

$> git status

# On branch master

# Changed but not updated:

# (use «git add <file>...» to update what will be committed)

# modified: main.c

no changes added to commit (use «git add» and/or «git commit -a»)

Pour que les changements puissent être commités, il faut que le fichier soit rajouté à la liste des fichiers à commiter. Pour cela, deux méthodes : git add <fichier> ou git commit -a. La première vous permet de le faire en douceur, pour être sur des fichiers que vous allez commiter, la deuxième est la méthode express. Avec la première, il vous faudra faire un git commit afin de réaliser le commit, la deuxième fait les deux en même temps et vous donne la main pour rédiger le commentaire de commit. Mais, tout ça, vous savez faire désormais.

2.5 Revenir à un commit particulier

Dernière commande de base fort utile : git revert. Elle vous permet de revenir à un commit particulier et de remettre par la même occasion l’arbre dans l’état dans lequel il était à ce moment-là :

$> git revert ca57e3...
HEAD is now at ca57e39... patch de GuiGui2
$>

$> git revert ca57e3...

HEAD is now at ca57e39... patch de GuiGui2

Un petit souci avec cette commande, c’est qu’elle n’est capable de travailler que si votre branche de travail est propre : si vous n’avez pas fait de modifications depuis le dernier commit. Si vous faites un commit, puis vous remettez au travail pour vous rendre compte au bout de quelques lignes que ce que vous faites est erroné, vous voudrez peut être revenir au dernier commit sans en faire un. Pour cela, il suffit d’utiliser git reset :

$> git reset --hard HEAD
HEAD is now at ca57e39... patch de GuiGui2

1 2	$> git reset --hard HEAD HEAD is now at ca57e39... patch de GuiGui2

Cette commande vous remettra la branche telle qu’elle était à la sortie du commit précédent.

2.6 Voila, c’est fini !

Comme dans la chanson de Téléphone en effet, c’est ici que l’on termine avec les commandes de base. Récapitulons avant d’avaler une autre pilule.

Initialiser un dépôt : git init ;
Ajouter un fichier pour un commit : git add fichier ;
Consulter la liste des modifications depuis le précédent commit : git diff ;
Faire un commit : git commit ;
Revenir à un commit précédent : git revert commit.

3. Divagations

Après une longue réflexion, je pense qu’il est sage d’aborder la question des branches avant la question de la publication de vos travaux et de la confrontation quasi inévitable avec le monde extérieur et ses idées et avis sur vos travaux. Il se trouve que l’on veut parfois tester une idée particulière sans être sûr de l’utilité et de l’efficacité de celle-ci. Heureusement, les SCM ont depuis longtemps appris à gérer ces divagations et proposent un principe judicieux : les branches. La plupart des développeurs utilisant Git en font d’ailleurs une utilisation intensive. Vous comprendrez mieux pourquoi dans quelques chapitres. La création d’une branche utilise la commande git branch nom. Évidemment, vous pouvez choisir le nom que vous voulez pour les branches, il n’y a pas de loi là-dessus. La commande git branch vous donnera la liste des branches existantes dans votre dépôt et signalera la branche active (celle que vous êtes en train d’utiliser) par une étoile. Enfin, le passage d’une branche à une autre se fait avec la commande git checkout nom.

 $> git branch
* master
# [1]
$> git branch bistruct
$> git branch
  bistruct
* master
# [2]
$> git checkout bistruct
Switched to branch «bistruct»
$> git branch
* bistruct
  master
# [3]

$> git branch

* master

# [1]

$> git branch bistruct

$> git branch

bistruct

* master

# [2]

$> git checkout bistruct

Switched to branch «bistruct»

$> git branch

* bistruct

master

# [3]

On commence donc par lister les branches présentes (1), puis on crée une branche et on vérifie cette action (2). On voit alors qu’il y a bien deux branches, et que master est toujours la branche active. On passe alors sur la nouvelle branche (3) ce qui est constaté par un nouveau git branch. Lors de la création d’une branche, celle-ci est un clone de la branche qui a servi à la créer, ici master. On peut alors travailler sur l’une et l’autre de façon indépendante. Là où ça se corse un peu, c’est quand vous voulez intégrer les modifications faites dans une branche dans une autre, mais ce n’est rien qu’un merge après tout.

3.1 Maman ! Je n’arrive pas à merger les chats

Nous reprenons donc le main.c précédent, à peu de choses près :

 #include <stdio.h>
typedef struct BLAH {
        int cnt;
        char c;
} BLAH;
int main(int argc, char *argv[])
{
        int i;
        for(i = 0; i < 5, i++) {
                if (argc >= 1)
                     printf(«you entered something : %s\r\n», argv[1]);
        }
        return (0);
}

#include <stdio.h>

typedef struct BLAH {

int cnt;

char c;

} BLAH;

int main(int argc, char *argv[])

{

int i;

for(i = 0; i < 5, i++) {

if (argc >= 1)

printf(«you entered something : %s\r\n», argv[1]);

}

return (0);

}

On crée une branche bistruct et on édite le fichier main.c pour qu’il ressemble à ça :

#include <stdio.h>
typedef struct BLAH {
        int cnt;
        int cnt2;
        char c;
} BLAH;
int display_blah(BLAH a_blah) {
        printf(«struct is : %u, %u and %c\r\n», a_blah.cnt, a_blah.cnt2, a_blah.c);
        return(0);
}
int main(int argc, char *argv[])
{
        int i;
        BLAH one;
        for(i = 0; i < 5; i++) {
                if (argc >= 1)
                        printf(«you entered something : %s\r\n», argv[1]);
        }
        one.cnt = 1;
        one.cnt2 = one.cnt + 1;
        one.c = ‘a’;
        display_blah(one);
        return (0);
}

#include <stdio.h>

typedef struct BLAH {

int cnt;

int cnt2;

char c;

} BLAH;

int display_blah(BLAH a_blah) {

printf(«struct is : %u, %u and %c\r\n», a_blah.cnt, a_blah.cnt2, a_blah.c);

return(0);

}

int main(int argc, char *argv[])

{

int i;

BLAH one;

for(i = 0; i < 5; i++) {

if (argc >= 1)

printf(«you entered something : %s\r\n», argv[1]);

}

one.cnt = 1;

one.cnt2 = one.cnt + 1;

one.c = ‘a’;

display_blah(one);

return (0);

}

On procède donc au commit :

$> git add main.c
$> git commit -m «adding display function for the struct and testing it»
$>

$> git add main.c

$> git commit -m «adding display function for the struct and testing it»

On vérifie un peu ce qui diffère entre ses deux branches :

$> git diff master bistruct
...
$>

$> git diff master bistruct

...

Faisons ensuite un merge puisque l’on veut que ce code soit désormais intégré à la branche principale de notre travail.

$> git checkout master
$> git merge bistruct
Updating f9fe93d..f5c6f70
Fast forward
 main.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)
$>

$> git checkout master

$> git merge bistruct

Updating f9fe93d..f5c6f70

Fast forward

main.c | 15 ++++++++++++++-

1 files changed, 14 insertions(+), 1 deletions(-)

Bien, on a toujours nos deux branches et elles sont identiques (puisque nous n’avions rien changé entre-temps dans la branche master).

$> git branch
  bistruct
* master
$> git diff bistruct
$>

$> git branch

bistruct

* master

$> git diff bistruct

Surprise : pas de commit à faire. Pour vérifier, un push vers votre dépôt public et un clone de celui-ci vous donnera effectivement bien le master avec le résultat du merge. Pour cela, il nous faut donc un dépôt public.

3.2 Petit résumé

Pour gérer les branches, il vous faut vous souvenir de trois commandes :

création d’une branche : git branch nom ;
chargement d’une branche : git checkout nom ;
fusion de deux branches (de branche1 dans la branche active) : git merge branche1.

4. Dépôt public et utilisation

Pour de multiples raisons, on veut pouvoir publier son dépôt sur le domaine du Nain Ternet. Avec Git, on a plusieurs choix à la fois entre le développeur et son serveur public et entre le serveur public et les développeurs qui voudraient jeter un œil à notre travail. Ici, nous resterons simples en utilisant un lien ssh entre le développeur et son serveur, et un HTTPD pour le côté publication du dépôt. Si vous ne saisissez pas trop le principe, voici un schéma (inspiré de celui de la doc officielle), Théo étant un développeur utilisant Git :

<tt> Théo push Dépôt perso de Théo ------------------> Dépôt public de Théo ^ | | | | Théo pull | Les gens pull | | | | | les gens push V dépots public <------------------- les dépôts des gens des gens</tt>

1	<tt> Théo push Dépôt perso de Théo ------------------> Dépôt public de Théo ^ \| \| \| \| Théo pull \| Les gens pull \| \| \| \| \| les gens push V dépots public <------------------- les dépôts des gens des gens</tt>

4.1 Préparation des ingrédients

La première chose à faire est de réaliser un dépôt prêt à l’emploi, une sorte de poudre pour gâteau au chocolat auquel vous n’aurez plus qu’à rajouter les œufs.

$> cd && cd projets
$> git clone --bare c_101 c_101.git
$> touch c_101.git/git-daemon-export-ok

$> cd && cd projets

$> git clone --bare c_101 c_101.git

$> touch c_101.git/git-daemon-export-ok

Nous voici avec notre sachet de poudre.

4.2 Da http way

Aussi connue sous le nom de " pfff, j’ai pas envie de me compliquer la vie ". Copiez le répertoire précédemment obtenu sur votre serveur web

theo@workstation:~/> scp -r c_101.git theo@webserver:~/
...
theo@webserver:~/> mv c_101.git /home/theo/public_html/c_101.git
theo@webserver:~/> cd public_html/c_101.git
theo@webserver:~/public_html/c_101.git/> git --bare update-server-info
theo@webserver:~/public_html/c_101.git/> chmod a+x hooks/post-update

theo@workstation:~/> scp -r c_101.git theo@webserver:~/

...

theo@webserver:~/> mv c_101.git /home/theo/public_html/c_101.git

theo@webserver:~/> cd public_html/c_101.git

theo@webserver:~/public_html/c_101.git/> git --bare update-server-info

theo@webserver:~/public_html/c_101.git/> chmod a+x hooks/post-update

Désormais, le dépôt est clonable via la commande suivante :

	$> git clone http://poisson.piquant.ca/~theo/c_101.git

1	$> git clone http://poisson.piquant.ca/~theo/c_101.git

4.3 Poussez madame !

Lors de la préparation des ingrédients, l’état du dépôt à cet instant t précis est intégré (son historique si vous préférez), mais il faut continuer à l’alimenter si vous voulez que les gens puissent suivre. Lorsque vous faites un commit et que vous voulez que les gens accèdent à votre travail, il vous faut pousser ces changements vers le dépôt public. En principe, il vous faut utiliser la procédure suivante : 1. git commit (si ce n’est déjà fait) ; 2. git repack && git prune ; IMPORTANT 3. git push

$> git commit -m “adding top notch functionnalities”
$> git repack && git prune
$> git push ssh://poisson.piquant.ca/~theo/c_101.git master

$> git commit -m “adding top notch functionnalities”

$> git repack && git prune

$> git push ssh://poisson.piquant.ca/~theo/c_101.git master

IMPORTANT : Git repack Git repack est une commande importante que vous devriez exécuter relativement souvent (une fois par jour ou une fois par heure suivant le rythme de vos commits). Git gère les commits sous la forme d’objets et les entasse au fur et à mesure. Le problème, c’est que ça peut devenir rapidement le bordel s’il y en a trop à gérer en même temps. Cela peut prendre de la place et encombrer le système (Git). Pour résoudre ces problèmes, il faut utiliser la commande git repack qui va permettre de restocker les objets dans des packs et ainsi optimiser le stockage et le boulot de Git. Pour que ce soit bien propre, il faut ensuite passer un coup de balai avec git prune. Si vous avez des doutes, regardez de temps en temps le nombre d’objets en liberté avec git count-objects : $> git count-objects 6930 objects, 47620 kilobytes Ici, sur un vieux projet, on voit le nombre d’objets en déroute et la place qu’ils prennent… Après un git repack et un git prune, on peut voir des résultats différents : $> git count-objects 0 objects, 0 kilobytes Bref, faites un git repack && git prune de temps en temps. En tant qu’informaticiens, nous sommes fainéants, et, pour éviter de taper toute cette URL à chaque fois, on va rajouter ce dépôt dans la config de Git. Pour cela, il suffit d’éditer le fichier .git/config pour ajouter quelque chose dans ce goût-là :

[remote «public-repo»]
        url = ssh://poisson.piquant.ca/~theo/c_101.git

1 2	[remote «public-repo»] url = ssh://poisson.piquant.ca/~theo/c_101.git

Désormais, pour faire un push, il suffit de taper la commande suivante :

	$> git push public-repo

1	$> git push public-repo

4.4 Publication d’une branche supplémentaire

Par défaut, lorsque vous faites un git push, Git ne va pousser que la branche master, mais il est possible que vous vouliez que d’autres branches soient aussi publiées sur votre dépôt public. Dans ce cas, il faut faire un push explicite de cette branche vers le dépôt voulu :

	$> git push public-repo une_branche

1	$> git push public-repo une_branche

Désormais, lorsque vous ferez un git push public-repo, les branches master et une_branche seront poussées si elles ont été mises à jour depuis le précédent push. Votre public adoré peut désormais suivre différentes branches de votre travail.

4.5 Petit résumé

Les idées à retenir cette fois ci sont :

création d’un dépôt prêt à l’emploi avec git clone —bare dépot_local dépot_local.git ;
copie du prêt à l’emploi sur le serveur public ;
nettoyage et maintenance du dépôt local : git repack && git prune ;
export vers le dépôt : git push ;
publication d’une branche supplémentaire :git push depot branche la première fois, git push les fois suivantes.

5. Travail à plusieurs

Maintenant que l’on a publié notre dépôt, plusieurs personnes se sont mis en tête d’y jeter un coup d’œil et de nous retourner commentaires et diff. Elles voudraient bien savoir comment faire.

5.1 Get a clone

La première tâche de chaque personne voulant jeter un œil au travail d’une autre est de récupérer une copie de son dépôt public.

richard@vache$> cd && mkdir projets && cd projets
richard@vache$> git clone http://poisson.piquant.ca/~theo/c_101.git

1 2	richard@vache$> cd && mkdir projets && cd projets richard@vache$> git clone http://poisson.piquant.ca/~theo/c_101.git

Cette commande va créer un clone local de notre dépôt. Note : Ici, nous avons un sujet un peu délicat qui a trait aux bonnes manières ou aux bonnes pratiques de développement. La commande git clone va créer un dépôt local à partir du dépôt distant. Il va récupérer la ou les branches du dépôt distant. La question est alors de savoir sur quelle branche travailler : faut-il travailler directement sur la branche master ou sur une branche créée à partir de celle-i ? Dans le premier cas, un git pull sur la branche master ne gênera pas votre travail et vous pourrez suivre correctement les travaux des autres développeurs. Mais, c’est à vous de décider. Consultez http://www.kernel.org/pub/software/scm/git/docs/everyday.html (en) pour avoir une idée de différents modus operandi.

5.2 Suivre plusieurs branches distantes

5.2.1 Lister les branches accessibles

Une commande utile pour connaître les branches accessibles est git branch -a. Cette commande vous montrera les branches locales et distantes. La commande git branch -r permet de lister les branches distantes seulement, et git branch les branches locales. Reprenons à partir d’un clone frais :

$> git clone http://poisson.piquant.ca/~theo/c_101.git
$> cd c101
$> git branch/me
* master
$> git branch -r
  origin/HEAD
  origin/bistruct
  origin/master
$> git branch -a
* master
  origin/HEAD
  origin/bistruct
  origin/master

$> git clone http://poisson.piquant.ca/~theo/c_101.git

$> cd c101

$> git branch/me

* master

$> git branch -r

origin/HEAD

origin/bistruct

origin/master

$> git branch -a

* master

origin/HEAD

origin/bistruct

origin/master

5.2.2 Ajouter une branche à suivre

Par défaut, donc, vous suivez déjà la branche origin/master. On voit ici que la branche origin/bistruct est aussi accessible. Pour ce faire, il faut utiliser la commande git fetch.

$> git fetch origin bistruct:bistruct
Fetching refs/heads/bistruct from http://poisson.piquant.ca/~theo/c_101.git using http
* refs/heads/bistruct: storing branch ‘bistruct’ of http://poisson.piquant.ca/~theo/c_101
  commit: xxxxxx
$> git branch
  bistruct
* master
$>

$> git fetch origin bistruct:bistruct

Fetching refs/heads/bistruct from http://poisson.piquant.ca/~theo/c_101.git using http

* refs/heads/bistruct: storing branch ‘bistruct’ of http://poisson.piquant.ca/~theo/c_101

commit: xxxxxx

$> git branch

bistruct

* master

Quelques explications : git fetch prend trois arguments. Le premier est le nom ou l’URL du dépôt depuis lequel on va récupérer la branche (ici origin), le deuxième est le nom de la branche que l’on veut récupérer (bistruct) et le troisième est le nom qu’aura cette branche localement. C’est bon ? Tout le monde est toujours là ?

5.2.3 Ajouter un dépôt distant supplémentaire

Dans le cas où plusieurs personnes travaillent sur le même projet que vous, il vous faudra probablement suivre leurs branches. À l’heure actuelle, vous avez cloné un dépôt, généralement celui du développeur principal, et vous suivez ses branches et bossez sur les vôtres. Pour pouvoir suivre aussi les branches d’un autre développeur, vous devez indiquer à Git que vous voulez le faire. Pour cela, il faut utiliser la commande git remote et plus particulièrement son option add.

$> git remote
origin
$> git remote add imil git://lutin.jard.in/git/c101.git
$> git remote
imil
origin
$> git branch -r
  origin/HEAD
  origin/bistruct
  origin/master
  imil/master
  imil/pinpin
$>

$> git remote

origin

$> git remote add imil git://lutin.jard.in/git/c101.git

$> git remote

imil

origin

$> git branch -r

origin/HEAD

origin/bistruct

origin/master

imil/master

imil/pinpin

Explications : nous commençons par lister les dépôts distants que Git connaît (seulement origin au départ), puis nous rajoutons un dépôt que nous nommons imil en passant l’URL qui le définit. La liste des dépôts distants gérés s’allonge donc, ainsi que la liste des branches accessibles. Il ne reste plus qu’à appliquer le paragraphe précédent " Ajouter une branche à suivre " pour chaque branche que vous voulez suivre.

5.3 Tenir les branches distantes à jour

Il y a deux solutions pour cela :

git fetch ;
git pull.

5.3.1 git fetch

Cette commande va récupérer les modifications faites sur les branches distantes sans les merger avec votre travail. Néanmoins, ces branches sont accessibles en tant que branches distantes dans .git/refs/remotes/origin/master. Rien ne vous empêche de faire un fetch comme expliqué dans le paragraphe " Ajouter une branche à suivre ".

5.3.2 git pull

Cette commande va récupérer les modifications faites sur les branches distantes et les merger avec votre travail.

5.4 Préparer un patch

Maintenant que vous savez utiliser les branches et accéder aux branches de vos – peut-être – camarades, vous n’aurez aucun mal à faire des diff entre vos branches et les leurs. Mais faire des diff ne rime pas à grand-chose, et, pour participer au développement, il n’y a pas trente-six choix : il faut faire tourner le code. Car comme le disait un grand homme " passe passe le code… " Deux solutions pour ça :

demander au développeur concerné de faire un pull (on parle de pull request),
faire un patch et l’envoyer au développeur concerné

Dans le premier cas, il vous faut un dépôt public accessible par le développeur, ça vous savez faire. Dans le deuxième cas, il suffit d’utiliser la commande git format-patch, ça vous connaissez pas encore.

	$> git format-patch origin

1	$> git format-patch origin

Explications : la commande git format-patch prend un argument, la référence à qui vous destinez le patch, d’où l’utilisation d’origin ici. Mais, prenez garde, car cette commande génère un patch pour chaque commit qui diffère d’origin, et chacun de ces commits est sous la forme d’un mail " prêt à l’emploi ". Pour ceux qui ne veulent pas utiliser ce genre de choses, il reste évidemment la solution d’utiliser la commande git diff.

	$> git diff -p origin > cleaning_the_mess.patch

1	$> git diff -p origin > cleaning_the_mess.patch

Ce qui produit le patch cleaning_the_mess.patch.

5.5 Appliquer un patch

Lorsque vous recevez un patch, une bonne idée serait sûrement de faire une branche à partir de votre master et de tester sur cette nouvelle branche.

5.5.1 Mail généré par git format-patch

Si vous avez accès à votre boite mail depuis votre console de développement, vous pouvez utiliser la commande git am. Cette commande vous permet d’appliquer une série de patchs présents dans votre mailbox ou dans votre maildir. Mais, en vérité, il gère tout répertoire comme un maildir. Il suffit donc de copier " brut de pomme " vos mails-patchs dans un répertoire et de le donner en pâture à Git. Note : Un point à noter concernant l’encodage : depuis quelque temps, on entend parler d’utf8 et certains programmes qui le gèrent vont même jusqu’à l’utiliser par défaut. C’est le cas de Git. Je vous invite donc à regarder le man de git am et notamment les options -utf8 et --no-utf8.

5.5.2 Patch généré à la mano

Si vous avez reçu un patch " fait main " (comme les chaussures oui), pour cela, il faut utiliser la commande git apply qui prend en arguments le ou les patchs que vous voulez et les applique à la branche active. Une option intéressante de cette commande est --check. Elle permet de tester le patch sur la branche active et de vous dire si oui ou non il passe.

5.6 Petit résumé

Pour cette dernière section, la liste est longue :

cloner un dépôt distant localement : git clone url ;
suivre une branche d’un dépôt distant déjà listé par Git : git fetch dépôt branche_distante:branche_locale ;
ajouter un dépôt distant dans la liste : git remote add nom_local url ;
tenir à jour ses branches : git fetch et git pull ;
préparer un patch : git format-patch branche_de_référence ou git diff -p branche_de_référence > nom.patch.

6. Le fin mot de l’histoire

Voilà, vous devriez désormais pouvoir vous débrouiller avec Git pour la plupart des cas. Dans le cas où vous seriez bloqué, consultez la documentation officielle relativement fournie. Personnellement, Git s’est révélé un compagnon de travail admirable, simple d’utilisation, rapide, léger. Je l’apprécie particulièrement pour les raisons suivantes :

Pas de serveur dont je dépends pour travailler : même sans accès internet ; je peux profiter des bienfaits d’un SCM et cela right out of the box : pas de setup à faire.
Gestion des branches transparentes : Git les manipule sans souci et sans vous demander de créer des répertoires et des répertoires. Vous passez de l’une à l’autre par une seule commande, Git s’occupe de tout.
Documentation : chaque commande est documentée de façon claire (git command —help).

Évidemment, certains pourraient me dire que d’autres SCM proposent déjà cela et que Git n’est qu’une énième réinvention de la roue. C’est peut-être vrai, Mercurial et quelques autres sont sûrement intéressants, mais personnellement, c’est Git que je préfère. J’espère que cet article vous a plu et qu’il vous aidera à faire le pas si vous vous sentez mal avec d’autres SCM (ou plus, si affinités). Pour finir, je tiens à remercier les lutins, barbus et amis qui m’ont aidé à écrire (ou relire) cet article et à me mettre au libre en général : merci.

Donnez votre avis - 1 commentaire(s)

jakikiller dit :

23 février 2011 à 12:09

Vraiment trés bon article.
Trés utile et trés bien expliquer.
Agréable à lire.
Merci beaucoup

Vous souhaitez commenter cet article ?

Inscrivez-vous ou Connectez-vous

Brèves	Flux RSS
01/05/13 Édito : Linux Pratique N°77
30/04/13 Édito : GNU/Linux Magazine N°160
30/04/13 Édito : GNU/Linux Magazine Hors-Série N°66
15/04/13 Édito : MISC Hors-Série N°7
29/03/13 Édito : Linux Essentiel N°31
Toutes les brèves »

Communication	RSS Com.	RSS Presse
28/03/13 Linux Essentiel N°31 – Communiqué de presse
28/03/13 GNU/Linux Magazine N°159 – Communiqué de presse
05/03/13 Linux Magazine, Partenaire de Symfony Live Paris
04/03/13 Linux Pratique, Partenaire des Rencontres du Libre
01/03/13 Misc, Partenaire de Insomni’Hack
Tous les communiqués de presse » Nos autres communiqués »