Maintenant que vous savez manipuler git pour suivre des fichiers en local, je vais vous expliquer comment on s'en sert quand il y a un dépot sur un serveur et plusieurs personnes qui travaillent sur le projet. Je vais partir d'une configuration simple de travail dans laquelle vous serez le plus souvent amené à utiliser. Ici il y a un dépot git sur un serveur avec lequel on veut se synchroniser. Notre objectif bien sur est qu'il y ait la dernière version du projet à jour sur le serveur. Elle n'y sera pas à tous les instants mais je vais vous expliquer comment procéder. Ici je ne vais pas aborder les problèmes de merge (fusion de différentes version d'un fichier) et le travail sur différentes branches.

Prenons 2 personnes (A, et B) qui veulent travailler sur un projet, chacun fait une partie totalement différente du projet, il y a 3 dépots à synchroniser. On considère qu'on est dans un état initial ou les 2 personnes n'ont pas le dépot sur leur ordinateur et qu'il y a déjà des commits dans le dépot sur le serveur.

La première étape à faire pour A et B est d'envoyer une clef ssh à l'administrateur du serveur pour qu'ils puissent s'identifier sur le serveur. 

Créer une paire de clef ssh sous Linux

On suppose ici que vous n'avez pas déjà créé de clef ssh sur votre ordinateur. Ces clefs sont normalement stockées dans le répertoire caché ~/.ssh/ vous devez générer deux fichiers : id_rsa et id_rsa.pub.  id_rsa est votre clef privée, ne la donnez à personne! id_rsa.pub est votre clef publique, vous devrez l'envoyer à chaque fois qu'on vous donnera l'accès à un serveur git (un serveur peut contenir plusieurs dépots). Par exemple pour telle ou telle matière vous en aurez un, pour un projet (exemple PACT) ou pour le club.

Astuce: Copiez votre clef privée sur tous vos ordinateurs, comme ca vous serez identifié à chaque fois par la même et pas besoin de générer 150 paires différentes.

Pour générer une paire de clef, allez dans le répertoire ~/.ssh:
cd ~/.ssh
Créez le répertoire si il n'existe pas. Ensuite on va utiliser ssh-keygen pour générer une paire de  clef:
ssh-keygen
# Generating public/private rsa key pair.
# Enter file in which to save the key (/home/A/.ssh/id_rsa):
Entrez le nom du fichier si vous voulez le changer ou faites entrée. Vous devrez ensuite taper une passphrase, elle vous sera demandée à chaque session de travail avec git lorsque vous ferez des échanges avec le serveur. Retapez la quand on vous demande confirmation. La paire de clef sera générée et vous obtiendrez ca:
Your identification has been saved in /home/you/.ssh/id_rsa.
# Your public key has been saved in /home/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db 
Et voila vous avez votre paire de clef, vous n'avez plus qu'à envoyer par mail votre clef publique à l'administrateur du serveur et à copier votre clef privée (dans votre session linux à l'école, sur votre ordi fixe/portable chez vous).

Pour vous simplifier la vie j'ai concocté un petit script bash, vous aurez juste à rentrer votre nom prénom et adresse mail et le tour est joué, git est configuré et il vous génère une paire de clef. (Voir fichier attaché git_config.txt)

Ce tuto est juste une traduction de ce tutoriel.

Clôner un dépot

Vous êtes prêts à travailler maintenant, tout d'abord récupérez le dépot dont on vous à donné l'adresse ex blabla@serveur.com/depot.git ou encore depot@serveur.com
a406-05% git clone gitosis@serveur.com:elec2013                         
Cloning into 'elec2013'...
remote: Counting objects: 47, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 47 (delta 15), reused 0 (delta 0)
Receiving objects: 100% (47/47), 15.73 MiB | 5.11 MiB/s, done.
Resolving deltas: 100% (15/15), done.
Checking out files: 100% (40/40), done.
Ici l'adresse du serveur un exemple, git vous raconte tout ce qu'il fait. C'est bon vous avez clôné le dépot, vous pouvez le renommer comme vous voulez, placez vous dedans pour travailler et vous pouvez utiliser les commandes git en local.
mv elec2013 mon_depot_git
cd mon_depot_git

Se synchroniser avec le serveur

On considère que le serveur possède la derniere version (dernier commit = HEAD) du projet et que personne d'autre que vous ne vas y apporter de modification dans l'immédiat. La première chose à faire quand vous commencez une session de travail est de synchroniser votre dépot avec le serveur. Pour ce faire on utilise la commande git pull quand vous êtes dans votre dépot.
~/depot: git pull
...
...
...
git va vous afficher un certain nombre d'informations. Sur le nombre d'objets récupérés etc.

Important: Avec un pull vous allez écraser votre work en le remplacant par la version du projet qui est sur le serveur. Vous pouvez d'abord faire un git fetch pour récupérer le dernier commit sans écraser votre work. Faire par exemple un git diff pour voir ce qu'il y a de nouveau. Puis un git merge pour fusionner le tout. Je ne vous explique pas le merge tout de suite.

N'oubliez pas, il faut que votre dépot soit dans un commit plus ancien que celui présent sur le dépot si vous voulez que tout se passe directement. Rassurez vous c'est souvent le cas.

Dans l'autre sens il faut utiliser la commande git push qui va envoyer vos commits vers le serveur.

Résumé d'une session de travail

Quand vous commencez à travailler sur votre projet après que d'autres personnes aient fait des modifications:
  • 1 git pull pour récupérer la dernière version
  • Vous faites des modifications, puis quand vous êtes sentez qu'il faut sauvegarder
  •  1 ou plusieurs git add  de vos fichiers modifiés/nouveaux
  • 1 git commit  et voila vous avez créé un commit.
  • Continuez à modifier
  • git add des nouvelles modifs
  • git commit puis quand vous avez fini de travailler
  • git push
Et voilà vous avez travaillé et synchronisé votre dépot avec le serveur.

N'oubliez pas: plusieurs add dans un commit et vous pouvez faire plusieurs commit avant de faire push.

Travailler à 2 de facon simple

Vous allez me dire: "mais pour l'instant je continue à travailler seul".  Je vais vous expliquer comment faire quand vous êtes plusieurs pour utiliser git sans vous prendre la tête. Vous serez rarement plus de 3,4 sur un même dépot git donc vous pourrez appliquer ce que je vais vous dire.

Reconsidérons nos deux compères A et B et le dépot sur le serveur S. A et B ne travaillent pas sur les mêmes fichiers (en tout cas pas en même temps). A et B on déjà clôné le dépot et ils sont tous dans le commit C. Il y a 2 fichiers sur le dépot, A travaille sur F1 et B travaille sur F2. 

On va noter l'état des différents dépots de cette facon [dépot A, serveur S, dépot B]  avec l'état du commit pour chacun ex: [C,C,C].

Pour simplifier, il faut qu'ils se débrouillent pour toujours récupérer les modifications de l'autre avant de push.

Au départ on est dans l'état [C0,C0,C0]

A rajoute des lignes dans F1

A add F1

A commit, on obtiens le commit C1

A push, on est donc dans l'état [C1,C1,C0]

Pour que B puisse travailler il doit récupérer le commit:

B pull on est dans l'état [C1,C1,C1], B est à jour il peut travailler.

B modifie F2

B add F2,

B commit, (C2) [C1,C1,C2]

B push [C1,C2,C2].

A pull [C2,C2,C2]

etc etc.   Si vous suivez ce schéma vous n'aurez jamais besoin de faire de merge.

Cas ou A et B travaillent sur même fichier.

Dans ce cas la méthode expliquée plus haut fonctionne. Ce qu'on veut éviter c'est que A et B aient fait des commits différents en même temps. C'est à dire d'être dans l'état [A_C4,C,B_C2]  par exemple. Car ici si A push B ne pourra pas pusher, il devra d'abord récupérer le commit de A, fusionner(merger) son commit avec celui de A puis pusher.

Voilà c'est tout ce que vous avez besoin de savoir pour commencer à travailler avec git. N'ayez pas peur d'essayer, n'oubliez pas que git se rappelle de tout, vous pouvez toujours annuler (plus ou moins facilement) une fausse manipulation.  Avec cette technique vous pourrez déjà travailler à plusieurs tout en versionnant vos projets. Avec l'habitude vous pourrez faire des choses plus compliquées. Je vous détaillerai comment utiliser le merge plus tard. 

Pour l'instant on n'utilise pas la notion de branche, vous serez amené à utiliser des branches quand vous travaillerez sur un projet en équipe de manière plus régulière.