EOLE

{{toc}}

h1. Présentation

Site officiel : http://git-scm.com/

Tutoriaux intéressants : 

* http://team.gcu.info/~ange/git_article/

* le tutorial des man pages http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

* http://gitready.com/

* http://progit.org/book/

* http://www.unixgarden.com/index.php/administration-systeme/git-pour-les-futurs-barbus

* http://yannesposito.com/Scratch/fr/blog/2010-03-22-Git-Tips/

Les manpages des commandes sont accessibles avec la commande help directement, 

par exemple : 

<pre>

git help log

</pre>

*remarque* : Il faut utiliser une version récente de git-core (>1.6.3) pour pouvoir travailler avec les dépôts. 

h1. Paramétrage global

Il est nécessaire de déclarer vos noms et emails dans votre configuration git globale

<pre>

git config --global user.name "Prénom NOM"

git config --global user.email "prenom.nom@ac-acad.fr"

</pre>

Afin que le git ne demande plus de login/pass , il faut renseigner le fichier @~/.netrc@ :

<pre>

machine dev-eole.ac-dijon.fr

login monlogin

password monmotdepasse

</pre>

et paramétrer les droits du fichier :

<pre>

chmod 600 ~/.netrc

</pre>

h1. Premiers pas

* Récupérer un projet :

<pre>

git clone http://login@dev-eole.ac-dijon.fr/git/nom_projet

</pre>

Cela va créer un répertoire @nom_projet@ contenant un répertoire @.git@.

* Ajouter/retirer des fichiers :

<pre>

git add file1 file2 ...

git remove file1 file2 ...

</pre>

* Pour savoir quel est l'état des modifications :

<pre>

git status

</pre>

* Enregistrer les modifications localement :

<pre>

git commit -a -m"premiere version avec le scm git"

</pre>

* Enregistrer les changements sur le serveur : 

<pre>

git push

</pre>

*remarque* : Avant d'enregistrer les changements sur le serveur, pensez à éditer vos messages de commit, il est possible de les fusionner (Voir "Messages de commit").

* Récupérer les modifications du serveur et les fusionner localement :

<pre>

git pull

</pre>

Notre serveur GIT a plusieurs branches "branch".

* Pour afficher les branches disponibles sur le serveur :

<pre>

git branch -a

</pre>

* Pour paramétrer la prise en compte d'une branche :

<pre>

git config branch.2.2.remote origin

git config branch.2.2.merge refs/heads/2.2

</pre>

* Pour récupérer la branche localement (à ne faire que la première fois) :

<pre>

git fetch origin 2.2:2.2

</pre>

* Pour se placer dans la branche :

<pre>

git checkout 2.2

</pre>

* Récupérer les modifications du serveur :

<pre>

git pull

</pre>

* Pour se placer dans une autre branche, "master" par exemple :

<pre>

git checkout master

</pre>

h1. Branch

 * Récupérer une branche

<pre>

git checkout nomDeBrancheExistant

</pre>

 * Créer une branche

Se placer dans la branche que l'on veut copier

<pre>

git checkout maBrancheABrancher

...

git checkout -b maNouvelleBranche

</pre>

 * Ceci peut être décomposé en 2 commandes :

<pre>

git branch mabranche

git checkout mabranche

</pre>

 * Diffuser la branche sur le serveur

<pre>

git http-push http://user@194.167.18.22/git/eolebase mabranche

</pre>

* Créer une branche à partir d'un numéro de commit

<pre>

git checkout -b mabranche <numero_de_commit>

</pre>

* Supprimer une branche :

<pre>

git branch -D [nom-branche]

</pre>

* Supprimer une branche sur le dépôt origin

<pre>

git push origin :branche

</pre>

Cela correspond en fait à cette commande là : git push REMOTENAME LOCALBRANCHNAME:REMOTEBRANCHNAME sauf que LOCALBRANCHNAME est vide dans notre exemple.

* Voir les différences entre deux branches

(par exemple avant de merger) : 

<pre>

git diff-tree -p [nom-de-branche]

</pre>

* Pour changer de branche :

<pre>

git checkout autrebranche

</pre>

* Pour revenir à la branche principale :

<pre>

git checkout master

</pre>

* Une autre technique consiste à organiser localement une arborescence différente par branche :

<pre>

git/master

   /mabranche

</pre>

* Savoir dans quelle branche on se trouve :

<pre>

git branch

</pre>

* Voir la branche courante avec le dernier log :

<pre>

git show-branch

</pre>

* Envoyer pour la _première fois_ le contenu de la branche courante sur le serveur :

<pre>

git push origin HEAD

</pre>

Arrivé à ce stade il peut être intéressant d'utiliser @git-gui@ (@/usr/lib/git-core/git-gui@) ou @giggle@.

Pour voir l'historique des différentes branches dans @guit-gui@, "@menu>dépôt>Voir l'historique de toutes les branches@"

* Autres commandes de base :

<pre>

git log

git log --pretty=oneline --all

git diff

</pre>

h2. Branches distantes

* Si vous avez déjà cloné le master d'un projet, pour visualiser les branches disponibles :

<pre>

git branch -a

</pre>

devrait renvoyer quelque chose comme ceci :

<pre>

* master

  remotes/origin/2.2

  remotes/origin/HEAD -> origin/master

  remotes/origin/master

  remotes/origin/upstream

</pre>

* Pour récupérer la branche 2.2 :

<pre>

git co 2.2

</pre>

va récupérer la branche 2.2 auprès du serveur origin.

Une autre méthode:

<pre>

git branch --track 2.2 remotes/origin/2.2

</pre>

h1. Merge

Fusion : action consistant à fusionner une branche avec une autre ("mabranche" avec @master@ par exemple)

Exemple : @merge@ de la branche *mabranche* dans la branche *master* 

* Se placer dans la branche @master@ :

<pre>

git checkout master

git merge mabranche

git push

</pre>

*remarque* : après un @merge@, il n'y a pas de @commit@ à faire, juste @pull@.

Si vous n'êtes pas satisfait du @merge@, il faut revenir en arrière avec un 

<pre>

git reset --hard

</pre>

**Résoudre un conflit de @merge@**

Si lors d'un @merge@ il y a eu un problème du type :

<pre>

Auto-merged file.txt

CONFLICT (content): Merge conflict in file.txt

Automatic merge failed; fix conflicts and then commit the result.

</pre> et que

<pre>

git commit

</pre> répond qu'il reste des fichiers à merger (unresolved merge), *Il n'y a donc pas eu véritablement de commit*

de même qu'un

<pre>

git status

</pre>

Il faut alors éditer le fichier concerné, résoudre le conflit à la main et faire un nouveau un @commit@ :

<pre>

git add [file.txt]

git commit -m"résolution du conflit"

</pre>

* Pour repérer les fichiers qui n'ont pas été fusionné :

<pre>

git ls-files --unmerged

</pre>

h1. Stash

*git stash* permet de sauvegarder des modifications locales afin de les appliquer plus tard.

* Sauvegarde des modifications :

<pre>

# git stash save "en attente"

Saved working directory and index state On master: en attente

</pre>

* Liste des modifications sauvegardées :

<pre>

git stash list

stash@{0}: On master: en attente

</pre>

* Revenir à l'état sauvegardé (_stash@{1}_ pour restaurer la 2ème sauvegarde) :

<pre>

git stash apply [stash@{0}]

</pre>

* Nettoyer la liste des sauvegarde :

<pre>

git stash clear

</pre>

h1. Message de commit

*IMPORTANT* : ne pas effectuer de modifications sur des commits déjà envoyés sur le serveur origin (le dépot).

Avant d'envoyer vos données sur le serveur, il est possible de modifier/améliorer les messages de commit.

h2. Modifier le dernier message de commit

<pre>

git commit --amend

</pre>

Modifier, sauvegarder et quitter.

h2. Modifier les trois derniers messages

* On lance un rebase

<pre>

git rebase -i HEAD~3

</pre>

* Un éditeur de texte s'ouvre avec quelque chose qui ressemble à ça:

<pre>

pick 6ffa65b update des bases de donnees editable=0 et pas 2

pick 9697740 update des bases vers 2.2.3 : nettoyage et ajout d'un __init__.py (ref #11)

pick e56a7a4 Configuration des bases de donnees pour le passage en version 2.2.3 (fixes #11 : fixé)

# Rebase cd9333c..e56a7a4 onto cd9333c

#

# Commands:

#  p, pick = use commit

#  r, reword = use commit, but edit the commit message

#  e, edit = use commit, but stop for amending

#  s, squash = use commit, but meld into previous commit

#

# If you remove a line here THAT COMMIT WILL BE LOST.

# However, if you remove everything, the rebase will be aborted.

#

</pre>

* Changer pick en edit sur les lignes correspondantes aux commit à modifier, par exemple :

<pre>

edit 6ffa65b update des bases de donnees editable=0 et pas 2

pick 9697740 update des bases vers 2.2.3 : nettoyage et ajout d'un __init__.py (ref #11)

pick e56a7a4 Configuration des bases de donnees pour le passage en version 2.2.3 (fixes #11 : fixé)

</pre>

* Sauver et quitter.

* Lancer la commande :

<pre>

git commit --amend

</pre>

* Modifier les messages de commit, par ex :

<pre>

update des bases de donnees editable=0 et pas 2 (ref #11)

</pre> 

* Sauvegarder et quitter

* Lancer la commande :

<pre>

git rebase --continue

</pre>

* Vérifier les messages de commit

<pre>

git log

</pre>

h2. Fusionner des commits

Il est possible de fusionner des commit afin d'éviter des commits multiples pour des modifications mineures.

* Lancer un git rebase

<pre>

git rebase -i HEAD~3

</pre>

<pre>

pick 16098ec Ajout d'icône gepi et cdt (ref #51)

pick f244e89 Deplacement d'icone

pick 7c8670c Deplacement des icones sources

# Rebase 5f5bfee..7c8670c onto 5f5bfee

#

# Commands:

#  p, pick = use commit

#  r, reword = use commit, but edit the commit message

#  e, edit = use commit, but stop for amending

#  s, squash = use commit, but meld into previous commit

#

# If you remove a line here THAT COMMIT WILL BE LOST.

# However, if you remove everything, the rebase will be aborted.

#

</pre>

* Changer pick en squash fusionne votre commit avec la ligne au-dessus

<pre>

pick 16098ec Ajout d'icône gepi et cdt (ref #51)

squash f244e89 Deplacement d'icone

squash 7c8670c Deplacement des icones sources

</pre>

* Sauver et quitter, Un éditeur s'ouvre:

<pre>

# This is a combination of 3 commits.

# The first commit's message is:

Ajout d'icône gepi et cdt (ref #51)

# This is the 2nd commit message:

Deplacement d'icone

# This is the 3rd commit message:

Deplacement des icones sources

# Please enter the commit message for your changes. Lines starting

# with '#' will be ignored, and an empty message aborts the commit.

# Not currently on any branch.

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

#       modified:   eole/tmpls/update_creole_posh.sql

#       renamed:    plugins/plugin_desktop/icones/old/Corbeille.png -> plugins/plugin_desktop/icones/Corbeille.png

#       renamed:    plugins/plugin_desktop/icones/old/Courrier.png -> plugins/plugin_desktop/icones/Courrier.png

#       renamed:    plugins/plugin_desktop/icones/old/agenda.png -> plugins/plugin_desktop/icones/agenda.png

#       new file:   plugins/plugin_desktop/icones/cdt.png

#       modified:   plugins/plugin_desktop/icones/dir.png

#       modified:   plugins/plugin_desktop/icones/gepi.png

#       renamed:    plugins/plugin_desktop/icones/old/mail.jpg -> plugins/plugin_desktop/icones/mail.jpg

#       modified:   plugins/plugin_desktop/icones/mail.png

#       new file:   sources-desktop/icones/cdt.xcf

#       renamed:    plugins/plugin_desktop/icones/grand/moodle.gif -> sources-desktop/icones/moodle.gif

#

# Untracked files:

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

#

#       databases/bdd/scribe-posh.sql.sav

</pre>

* Éditer les messages (un message suffit)

<pre>

# The first commit's message is:

Ajout d'icône pour les applications scribe (ref #51)

# This is the 2nd commit message:

# This is the 3rd commit message:

# Please enter the commit message for your changes. Lines starting

</pre>

* Sauver et quitter

* Vérifier que cela ressemble bien à ce que vous voulez

<pre>

git log

</pre>

h1. Trucs et astuces

* Résoudre un signalement avec l'ajout de "fixes #<numéro du signalement>"

<pre>

git commit -m"La nouvelle feature fixes #<numéro du signalement>"

git http-push ....

</pre>

* Faire référence à un signalement

<pre>

git commit -m"bla bla bal du bug #<numéro du signalement>"

</pre>

* Activer la coloration syntaxique 

<pre>

git config --global color.ui true

</pre>

* Pour controler les fichiers à ne JAMAIS prendre en compte (@commit@), utiliser le fichier @~/.gitignore@. Exemple d'un fichier @~/.gitignore@ :

<pre>

# ignorer le fichier lui même

.gitignore

# les fichiers de sauvegarde VIM

*~

# ignorer les fichiers html générés

*.html

# sauf mon_fichier.html que je veux prendre en compte

!mon_fichier.html

# ignorer les dossiers @.svn@

.svn

# ignore documentation buid html files

.build

</pre>

* Le fichier @~/.gitconfig@ peut permettre d'éviter de taper trop au clavier :

<pre>

[alias]

      st = status

      di = diff

      co = checkout

      ci = commit

      br = branch

      sta = stash

</pre>

* Pour éviter de taper l'URL et son mot de passe à chaque @push@ et @pull@, il faut :

 * configurer l'URL du projet

<pre>

git config remote.origin.url http://194.167.18.22/git/projet/

git config remote.origin.mirror false

</pre>

 * renseigner le fichier @~/.netrc@ :

<pre>

machine dev-eole.ac-dijon.fr

login monlogin

password monmotdepasse

</pre>

 * paramétrer les droits du fichier @~/.netrc@ :

<pre>

chmod 600 ~/.netrc

</pre>

Ensuite @git push@ et @git pull@ ne posent plus de questions.

* Pour faire le ménage :

<pre>

git repack

git prune

</pre>

* Pour repérer des @commit@ dans des branches qui n'ont pas été fusionnés (@merge@) dans la branche principale :

* Pour voir les @commit@ dans la branche *ma_branche* qui n'ont pas été fusionnés (@merge@) dans *master* : 

<pre>

git cherry -v master ma_branche

</pre>

h1. De subversion vers git

Il n'existe pas de commande *@update@*. Lorsqu'un fichier a été modifié localement par erreur et qu'on veut récupérer l'original, les habitudes étaient :

<pre>

rm mon_fichier

svn update

</pre>

A la place, il faut faire

<pre>

git checkout mon_fichier

</pre>

Pour revenir à un checkout frais dans le projet entier, utiliser *@reset@*. On peut annuler un commit en faisant :

<pre>

git reset --hard HEAD

</pre>

h1. Créer un patch et l'intégrer

Dans un projet (Ex.: conf-horus) on a créé une branche "ma_branche" dans laquelle on a fait des modifications (par rapport à "master").

On veut récupérer un fichier recensant les différences entre la branche *master* et la branche *ma_branche* (un fichier @diff@) :

<pre>

git diff master [nom-de-branche]  > file.patch

</pre>

* Une fois le patch récupéré, pour l'inclure dans la branche *master* :

<pre>

git apply --stat file.patch

git apply --check file.patch

</pre> permet de tester le patch, et :

<pre>

git apply file.patch

</pre> permet de l'appliquer

h1. Tags

*git* fait une différence entre les branches et les tags, cela se voit bien avec *git-gui* (vue de l'historique des branches).

Une branche est modifiable, un tag ne l'est pas. 

* Création du @tag@ :

<pre>

git tag mon-premier-tag

</pre>

* Liste des tags :

<pre>

git tag

</pre>

* Commit d'un @tag@ :

<pre>

git push --tags http://login@dev-eole.ac-dijon.fr/git/sandbox

</pre>

 * ou bien :

<pre>

git push http://login@dev-eole.ac-dijon.fr/git/sandbox <nom_tag>

</pre>

 * ou encore :

<pre>

git push http://login@dev-eole.ac-dijon.fr/git/sandbox <nom_branche> <nom_tag>

</pre>

* Recupérer un @tag@ :

<pre>

git checkout tags/<nom_tag>

</pre>

* Pour voir quel @commit@ exactement a été taggé :

<pre>

git show <nom_tag>

</pre>