I am nothing, no one, nobody, no more

C’est un article du 3 Juillet que j’avais posté sur mon précédent blog et que j’ai envie de “sauver” ici.

Warning : Ce tutorial peut être suivi de manière totalement linéaire. Je l’ai rédigé car je n’ai pas trouvé de how-to pour faire quelque chose aussi bateau que cela. Il est basé (niveau documentation) sur les 3 liens qui concluent l’article. Il peut être suivi de la même façon en préfixant les paths de ssh:// pour faire du git sur ssh. Il faut surtout ne pas penser en architecture “clients/serveur” à la CVS/SVN mais penser que l’on a des dossiers avec lesquels on peut se synchroniser. Et donc l’envoi de fichier(s) est distinct du “commit”.

Notation et Contexte : M1 pour Machine 1 qui contiendra le repository “public” et sur laquelle on peut coder également (donc update et commit). M2 pour Machine 2 qui ne fait que coder / update / commit.

Créer un repo sur M2

Ça semble assez logique car c’est là que l’on a les sources mais on pourrait faire dans l’autre sens (mais PAS de manière symétrique !). On commence donc sur M1.

cd mes_sources/
git config --global user.name "my name"
git config --global user.email me\@u.com
git init

Faire le premier commit (import)

git add ce_que_l_on_veut
git commit

(git commit fait récursivement les dossier comme svn)

Mettre en place le dépot (repository) public sur M1

/!\ On est toujours sur M2

git clone --bare ~/mes_sources/ mes_sources.git
touch mes_sources.git/git-daemon-export-ok
scp -r mes_source.git login\@M1:.

(ou où l’on veut, ou n’importe quel moyen de copier de ce dossier de M2 vers M1) Nota : Il peut être avisé de créer un login spécial (du style : “git”) sur M1 afin qu’il puisse être accédé par tout le monde.

Commit depuis M1 sur M1

/!\ On est maintenant sur M1

mkdir codeur_M1 && cd codeur_M1 (optionel)
git clone chemin_vers_repo_public (ou git clone login\@localhost:chemin_vers_repo_public)

Effectuer des envois de fichier

/!\ Restons sur M1

modifiez ce que vous voulez dans votre copie privée du repo (le dossier SANS .git) puis

git commit -a -m "tous les fichiers modifiés"

Note : si on veut seulement envoyer certains fichiers on ne fait que :

• git add fichier1 fichier2 fichier3

• git commit -m "certains fichiers"

git push

Envoie effectivement les fichiers

Travailler la première fois depuis M2

/!\ Nous sommes maintenant sur M2

git pull login\@M1:repo_public.git

faire des changements et un commit

git push login\@M1:repo_public.git

Si on fait un git pull depuis le répertoire (repo privé) où on travaille sur les sources (celui SANS .git) sur M1 on voit que les changements ont été répercutés. On constate par cette commande qu’il n’y a plus besoin de dire de où on pull (pareil pour push) une fois la première commande exécutée : c’est sauvegardé dans .git/config en tant que remote “origin”. On remarque également que l’on peut push à un endroit et pull à un autre. On peut changer les “lieux” des git push/pull à tout moment soit dans le .git/config soit en spécifiant le chemin.

En résumé (schéma tiré du manuel de GIT)

                      you push
your personal repo ------------------> your public repo
      ^                                     |
      |                                     |
      | you pull                            | they pull
      |                                     |
      |                                     |
      |               they push             V
their public repo <------------------- their repo

Quelques commandes

git push

ou

git push login\@machine:repo_public

pour envoyer les fichiers

git pull

ou

git pull login\@machine:repo_public

pour prendre les fichiers

git commit -a

pour faire un

git add

des fichiers modifiés et les commit

Exactement comme pour SVN :

• git rm

• git mv

• git status

• git log

• git blame

Des liens

1. Équivalents GIT/SVN (mais attention au mode de pensée !)
2. Un tutorial assez complet
3. Le manuel entier de GIT

Tags: cvs, git, svn, versionning