Projet

Général

Profil

GitBonnesPratiques » Historique » Version 85

Daniel Dehennin, 12/01/2017 15:30

1 40 Daniel Dehennin
{{toc}}
2 1 Redmine Admin
3 83 Daniel Dehennin
L'ancienne page de recueil de commandes Git est ici http://dev-eole.ac-dijon.fr/projects/eole/wiki/RecueilGit
4 54 Klaas TJEBBES
5 74 Daniel Dehennin
h1. Les bonnes pratiques c’est quoi ?
6 1 Redmine Admin
7 40 Daniel Dehennin
Ce document n’est pas une référence git, nous n’allons pas réécrire le
8 74 Daniel Dehennin
"Pro Git book":http://git-scm.org/book/fr, ni les autres références disponibles sur Internet.
9 1 Redmine Admin
10 67 Daniel Dehennin
Il existe même des "tutoriels":http://gitimmersion.fr/index.html pas à pas bien fait.
11 67 Daniel Dehennin
12 40 Daniel Dehennin
Nous allons partir du principe qu’un minimum de connaissance de l’outil git est acquis, notamment 
13 74 Daniel Dehennin
le "démarrage rapide":http://git-scm.org/book/fr/ch1-0.html et les "bases de git":http://git-scm.org/book/fr/ch2-0.html du livre "Pro Git book":http://git-scm.org/book/fr.
14 1 Redmine Admin
15 40 Daniel Dehennin
Nous allons essayer de décrire ici une méthodologie de travail basée sur le
16 74 Daniel Dehennin
système de gestion de version décentralisé "git":https://fr.wikipedia.org/wiki/Git avec les objectifs suivants :
17 1 Redmine Admin
18 40 Daniel Dehennin
* Communiquer entre développeur
19 40 Daniel Dehennin
* S’y retrouver dans ses développements, ou comment gérer des ajouts fonctionnels et des corrections de bug en parallèle
20 40 Daniel Dehennin
* Publier des modifications clairement identifiables et analysables, par des humains et des outils de tests automatiques
21 35 Daniel Dehennin
22 41 Daniel Dehennin
Ce document ne représente en rien _LA_ bonne méthode de travail, il s’agit juste d’une façon de faire,
23 41 Daniel Dehennin
appuyée par l’expérience d’autres personnes que l’on trouve un peu partout sur Internet.
24 1 Redmine Admin
25 78 Daniel Dehennin
Il est tout à fait possible de trouver autant, voir plus, de références prônant un point de vue opposé ou orthogonal au nôtre.
26 14 Klaas TJEBBES
27 1 Redmine Admin
h1. De la méthode agile
28 35 Daniel Dehennin
29 1 Redmine Admin
Comme il est défini dans le "manifeste agile":https://fr.wikipedia.org/wiki/Manifeste_agile#Les_4_valeurs, la première valeur est
30 79 Daniel Dehennin
> Les individus et leurs interactions.
31 35 Daniel Dehennin
32 79 Daniel Dehennin
Afin de travailler correctement en équipe, il faut communiquer, et l’outil de gestion de version "git":https://fr.wikipedia.org/wiki/Git, utilisé à EOLE, peut-être un excellent outil de communication.
33 23 Redmine Admin
34 23 Redmine Admin
h1. De l’écriture des "ChangeLog":https://fr.wikipedia.org/wiki/ChangeLog
35 35 Daniel Dehennin
36 74 Daniel Dehennin
Afin de communiquer avec les autres membres d’une équipe sur le travail que chacun effectue, l’écriture d’un ChangeLog, ou plus précisément d’un « commit message » dans la littérature anglaise (qui pourrait être traduit par « message de consignation ») se doit d’être fait correctement(sic).
37 1 Redmine Admin
38 74 Daniel Dehennin
Que penser d’un message comme « "typo":http://dev-eole.ac-dijon.fr/projects/eole-sso/repository/revisions/f2e5c52482c896b84e57333ba61654286b856f02 » ou encore « "correction d'une coquille":http://dev-eole.ac-dijon.fr/projects/cdc/repository/revisions/0dc6d59ca9c5294790ae1ebe0b035d8a3296ed22 » ?
39 35 Daniel Dehennin
40 73 Daniel Dehennin
Un message de commit *doit* expliquer le *pourquoi* de la modification afin de comprendre *ce qui a motivé* le changement.
41 73 Daniel Dehennin
42 81 Daniel Dehennin
Le changement en lui même est expliqué par le "diff":https://fr.wikipedia.org/wiki/Diff.
43 73 Daniel Dehennin
44 74 Daniel Dehennin
Nous pouvons établir une règle simple et souple, par exemple :
45 35 Daniel Dehennin
46 74 Daniel Dehennin
Un message de commit comprend :
47 35 Daniel Dehennin
48 74 Daniel Dehennin
* Une première ligne résumant le *pourquoi* du patch ;
49 35 Daniel Dehennin
* Une description longue optionnelle permettant d’expliciter le
50 74 Daniel Dehennin
  contexte du résumé donné en première ligne ;
51 80 Daniel Dehennin
* Une liste de fichier et leurs modifications.
52 77 Daniel Dehennin
53 80 Daniel Dehennin
Une *ligne vide* sépare les différentes parties : la première est obligatoire et la troisième est optionnelle pour les changements triviaux
54 35 Daniel Dehennin
55 74 Daniel Dehennin
Par exemple :
56 1 Redmine Admin
57 35 Daniel Dehennin
<pre>
58 85 Daniel Dehennin
  Le répertoire /usr/share/eole/noyau/ est nécessaire
59 35 Daniel Dehennin
60 1 Redmine Admin
  * debian/dirs: Création du répertoire.
61 85 Daniel Dehennin
62 85 Daniel Dehennin
Ref: #2405
63 1 Redmine Admin
</pre>
64 1 Redmine Admin
65 35 Daniel Dehennin
<pre>
66 85 Daniel Dehennin
  Simplification de la gestion des noyaux
67 35 Daniel Dehennin
  
68 35 Daniel Dehennin
  * creole/fonctionseole.py: Suppression du code effectué par
69 1 Redmine Admin
    eole-kernel-version depuis sa version 2.3-eole37~2.
70 1 Redmine Admin
    Renommage de la variable 'boot_ok' en 'need_boot'.
71 85 Daniel Dehennin
72 85 Daniel Dehennin
Ref: #2406
73 1 Redmine Admin
</pre>
74 35 Daniel Dehennin
75 74 Daniel Dehennin
Cela impose les règles suivantes :
76 1 Redmine Admin
77 74 Daniel Dehennin
# « Ne jamais utiliser l’option "-m" de la commande "git commit" »
78 74 Daniel Dehennin
# « Ne pas décrire ce que fait le commit mais pourquoi »
79 1 Redmine Admin
80 62 Daniel Dehennin
La description de se que fait un commit est le rôle du "diff":https://fr.wikipedia.org/wiki/Diff.
81 1 Redmine Admin
82 74 Daniel Dehennin
Ainsi, le second exemple donné plus haut n’est pas correct : « la première ligne ne décrit pas pourquoi on simplifie la gestion des noyaux ».
83 35 Daniel Dehennin
84 1 Redmine Admin
h1. De la cohérence de l’histoire du monde
85 35 Daniel Dehennin
86 82 Daniel Dehennin
Un système de gestion de version permet avant tout de conserver un livre d’histoire d’un projet.
87 1 Redmine Admin
88 82 Daniel Dehennin
Dans les premiers systèmes de gestion de version, cette histoire était centralisée. Il fallait avoir le droit d’écrire dans le « livre des comptes et légendes » afin d’y ajouter un morceau
89 1 Redmine Admin
90 82 Daniel Dehennin
Impossible donc de réécrire l’histoire sans être tout puissant sur le registre.
91 1 Redmine Admin
92 82 Daniel Dehennin
Grâce aux systèmes décentralisés comme "git":https://fr.wikipedia.org/wiki/Git, tout le monde peut avoir une copie privée de l’histoire publique d’un projet, pour cela il suffit de « cloner » l’histoire originale :
93 82 Daniel Dehennin
94 14 Klaas TJEBBES
<pre>
95 1 Redmine Admin
  moi@work:~/src$ git clone git://far-far.away.example.net/bidule.git
96 35 Daniel Dehennin
</pre>
97 1 Redmine Admin
98 82 Daniel Dehennin
À partir de là il est possible de vouloir y ajouter ses propres morceaux, et cela sans rien demander à personne.
99 1 Redmine Admin
100 82 Daniel Dehennin
On modifie le projet et on consigne les nouveaux événements dans notre copie locale de l’histoire du projet :
101 74 Daniel Dehennin
102 35 Daniel Dehennin
<pre>
103 1 Redmine Admin
  moi@work:~/src/bidule(master)$ $EDITOR src/bidule.c # On modifie un fichier du projet
104 1 Redmine Admin
  moi@work:~/src/bidule(master)$ git add src/bidule.c # On ajoute un événement à enregistrer dans le livre d’histoire
105 35 Daniel Dehennin
  moi@work:~/src/bidule(master)$ git commit # On consigne ce nouvel événement
106 35 Daniel Dehennin
</pre>
107 1 Redmine Admin
108 82 Daniel Dehennin
Mais l’histoire, c’est un sujet sensible. On ne badine pas avec l’histoire et on ne la réécrit sous aucun prétexte.
109 35 Daniel Dehennin
110 82 Daniel Dehennin
Peu importe si la vérité est ailleurs, l’important c’est que tout le monde soit d’accord sur la même version des faits.
111 35 Daniel Dehennin
112 82 Daniel Dehennin
Si un plaisantin modifie l’histoire et la publie à tout vent, il y aura conflit.
113 35 Daniel Dehennin
114 74 Daniel Dehennin
Nous allons donc édicter la règle suivante :
115 35 Daniel Dehennin
116 35 Daniel Dehennin
« On ne réécrit pas l’histoire connue »
117 35 Daniel Dehennin
118 82 Daniel Dehennin
Cela sous entend donc que nous pouvons réécrire comme il nous plaît toute l’histoire qui nous est privée, c’est à dire inconnue de tous les autres.
119 35 Daniel Dehennin
120 68 Daniel Dehennin
Mais dès qu’un événement est rendu public, ce n'est plus possible.
121 35 Daniel Dehennin
122 74 Daniel Dehennin
h1. Trop de pull, c’est trop chaud !
123 35 Daniel Dehennin
124 35 Daniel Dehennin
Que se passe-t-il si un jour nous souhaitons apprendre les nouvelles
125 74 Daniel Dehennin
histoires de par le monde ?
126 35 Daniel Dehennin
127 35 Daniel Dehennin
Que ce passe-t-il si un jour nous souhaitons partager nos petites
128 74 Daniel Dehennin
histoires avec le reste du monde ?
129 35 Daniel Dehennin
130 35 Daniel Dehennin
La plupart du temps, la réponse donnée à ces questions commence par
131 74 Daniel Dehennin
quelque chose comme « fais-toi donc un pull ».
132 35 Daniel Dehennin
133 74 Daniel Dehennin
Cela se traduit, en terme git, par :
134 1 Redmine Admin
135 35 Daniel Dehennin
<pre>
136 1 Redmine Admin
  moi@work:~/src/bidule(master)$ git pull
137 1 Redmine Admin
</pre>
138 35 Daniel Dehennin
139 74 Daniel Dehennin
Cela est strictement équivalent aux deux commandes suivantes :
140 1 Redmine Admin
141 35 Daniel Dehennin
<pre>
142 35 Daniel Dehennin
  moi@work:~/src/bidule(master)$ git fetch origin
143 1 Redmine Admin
  moi@work:~/src/bidule(master)$ git merge origin/master
144 1 Redmine Admin
</pre>
145 35 Daniel Dehennin
146 35 Daniel Dehennin
Mais il existe quelques soucis avec cette méthode, la première étant
147 74 Daniel Dehennin
« qu’une histoire entre en conflit avec l’une des vôtres ».
148 35 Daniel Dehennin
149 74 Daniel Dehennin
Un autre problème est que cette méthode « mélange » littéralement
150 35 Daniel Dehennin
l’histoire publique avec vos histoires privées, même s’il n’y a pas de
151 35 Daniel Dehennin
conflit, il peut-être difficile de savoir si le résultat aura un sens
152 1 Redmine Admin
ou non.
153 1 Redmine Admin
154 35 Daniel Dehennin
Dans git, chaque commit a une généalogie, le parent du commit que je
155 1 Redmine Admin
m’apprête à faire est le dernier commit enregistré dans le dépôt.
156 35 Daniel Dehennin
157 21 Joël Cuissinat
Lors d’un pull sur un dépôt contenant des modifications, git créé un
158 41 Daniel Dehennin
commit ayant deux parents dont le seul but est de mélanger la généalogie.
159 37 Daniel Dehennin
160 41 Daniel Dehennin
Il est donc préférable d’utiliser la méthode décomposée en deux commandes.
161 37 Daniel Dehennin
162 37 Daniel Dehennin
Cela permet de vérifier au préalable si des changements
163 74 Daniel Dehennin
sont à intégrer, et lesquels, avec les commandes suivantes :
164 37 Daniel Dehennin
165 37 Daniel Dehennin
* ChangeLog des différences
166 38 Daniel Dehennin
<pre>
167 37 Daniel Dehennin
  moi@work:~/src/bidule(master)$ git log master..origin/master
168 37 Daniel Dehennin
</pre>
169 44 Fabrice Barconnière
* Liste des fichiers modifiés
170 38 Daniel Dehennin
<pre>
171 37 Daniel Dehennin
  moi@work:~/src/bidule(master)$ git diff --stat master..origin/master
172 37 Daniel Dehennin
</pre>
173 37 Daniel Dehennin
* Modification du code
174 38 Daniel Dehennin
<pre>
175 37 Daniel Dehennin
  moi@work:~/src/bidule(master)$ git diff master..origin/master
176 21 Joël Cuissinat
</pre>
177 35 Daniel Dehennin
178 74 Daniel Dehennin
Mais cela n’empêche nullement :
179 35 Daniel Dehennin
180 74 Daniel Dehennin
* D’être potentiellement désastreux : chaque « fusion » (merge) et
181 74 Daniel Dehennin
  « consignation » de « fusion » (merge commit) sont à la charge de
182 74 Daniel Dehennin
  chaque développeur ;
183 35 Daniel Dehennin
* Votre histoire devient illisible. Elle intègre tout un tas de
184 74 Daniel Dehennin
  « fusion » inexplicables ;
185 35 Daniel Dehennin
* Retrouver à quel moment précis et quel modification a entraîné un
186 35 Daniel Dehennin
  changement de comportement devient impossible du fait des
187 74 Daniel Dehennin
  « fusions »
188 1 Redmine Admin
189 1 Redmine Admin
Tout mélanger dans la même branche, qui devient alors un tronc, pose
190 1 Redmine Admin
des soucis quant à la lecture de l’histoire du projet.
191 21 Joël Cuissinat
192 21 Joël Cuissinat
193 35 Daniel Dehennin
194 21 Joël Cuissinat
h1. Pour s’y retrouver, il faut s’accrocher aux branches
195 35 Daniel Dehennin
196 35 Daniel Dehennin
Une branche est une ligne d’histoire divergente d’un projet, leur
197 44 Fabrice Barconnière
utilisation dans git est très simple et légère.
198 35 Daniel Dehennin
199 74 Daniel Dehennin
La création d’une branche peut se faire de deux façons :
200 35 Daniel Dehennin
201 74 Daniel Dehennin
# Créer une branche que j’utiliserais plus tard :
202 40 Daniel Dehennin
<pre>
203 1 Redmine Admin
  moi@work:~/src/projet(master)$ git branch mabranche
204 74 Daniel Dehennin
  moi@work:~/src/projet(master)$ # on commit dans la branche « master »
205 40 Daniel Dehennin
</pre>
206 74 Daniel Dehennin
# Créer une branche et commencer à travailler dedans :
207 40 Daniel Dehennin
<pre>
208 40 Daniel Dehennin
  moi@work:~/src/projet(master)$ git checkout -b mabranche
209 74 Daniel Dehennin
  moi@work:~/src/projet(mabranche)$ # on commit dans la branche « mabranche »
210 35 Daniel Dehennin
</pre>
211 35 Daniel Dehennin
212 41 Daniel Dehennin
Chacune de ces commandes permet de définir, en dernier argument, le point de départ de la nouvelle branche.
213 35 Daniel Dehennin
214 1 Redmine Admin
Par défaut ce point de départ est le dernier commit de la branche courante.
215 35 Daniel Dehennin
216 1 Redmine Admin
Tout les commit effectués sur cette branche sont localisés à cette branche.
217 1 Redmine Admin
218 74 Daniel Dehennin
Cela permet de se focaliser sur une activité :
219 1 Redmine Admin
220 74 Daniel Dehennin
* Sans risquer d’impacter la vision que les autres ont de l’histoire ;
221 74 Daniel Dehennin
* Sans se soucier de ce qui peut arriver sur les autres branches ;
222 1 Redmine Admin
* Sans fusionner les modifications de la branche principale dans la
223 35 Daniel Dehennin
  branche courante.
224 1 Redmine Admin
225 41 Daniel Dehennin
Il faut travailler ensuite à intégrer cette nouvelle histoire à la ligne principale.
226 1 Redmine Admin
227 35 Daniel Dehennin
h2. Les voies du temps sont interpénétrables
228 35 Daniel Dehennin
229 74 Daniel Dehennin
C’est le principe utilisé par le pull, ce qui est nommé dans la littérature le « merge workflow ».
230 36 Daniel Dehennin
231 41 Daniel Dehennin
Ce qui est fait lors d’un @git pull@ entre une branche locale et une branche sur un dépôt distant,
232 74 Daniel Dehennin
« remote » en jargon git, est applicable entre deux branches d’un dépôt local.
233 35 Daniel Dehennin
234 41 Daniel Dehennin
En pratique, on se positionne sur la branche qui doit intégrer les modifications d’une autre,
235 74 Daniel Dehennin
par exemple une branche publique, et on fusionne la branche privée de développement dans cette branche publique :
236 1 Redmine Admin
237 1 Redmine Admin
<pre>
238 36 Daniel Dehennin
  moi@work:~/src/projet(master)$ git merge mabranche
239 1 Redmine Admin
</pre>
240 35 Daniel Dehennin
241 1 Redmine Admin
Pour ensuite publier ces modifications par @git push@.
242 35 Daniel Dehennin
243 35 Daniel Dehennin
Ceci induit les mêmes inconvénients que l’utilisation des pull.
244 35 Daniel Dehennin
245 74 Daniel Dehennin
Lorsque l’on passe du temps à travailler sur une branche privée, il est tentant de « fusionner » régulièrement une branche publique de référence, afin de se mettre à jour.
246 35 Daniel Dehennin
247 1 Redmine Admin
Mais cette pratique ne fait que rendre illisible l’histoire privée de cette branche.
248 1 Redmine Admin
249 59 Daniel Dehennin
Cela rend très difficile la relecture de chaque modification apportée par cette branche car son histoire n’est plus simplement une suite logique d’étapes afin d’arriver à un résultat voulu.
250 59 Daniel Dehennin
251 59 Daniel Dehennin
Fusionner des branches amont ("upstream":http://fr.wiktionary.org/wiki/upstream) dans votre branche de travail en cours sans une raison réellement valable est considéré comme une très mauvaise pratique.
252 59 Daniel Dehennin
253 59 Daniel Dehennin
Un telle fusion dans une direction erronée (upstream=>branche privée) ne devrait être fait qu’en cas d’absolue nécessitée, par exemple, lorsque votre travail en cours nécessite des nouveautés effectuées sur la branche upstream.
254 59 Daniel Dehennin
255 59 Daniel Dehennin
Autrement, votre branche de travail ne sera plus sur un sujet particulier mais deviendra un amas informe de commit de sources diverses et avariées, venant de votre propre branche mais aussi d’upstream contenant du travail fait par d’autres sur des sujets tout aussi divers et variés.
256 35 Daniel Dehennin
257 1 Redmine Admin
h2. On ne construit que sur les épaules de géants
258 35 Daniel Dehennin
259 35 Daniel Dehennin
Il existe une autre approche à la problématique généalogique des
260 74 Daniel Dehennin
commits, nommé dans la littérature « rebase workflow ».
261 35 Daniel Dehennin
262 35 Daniel Dehennin
Ce principe utilise la réécriture de l’historique, par conséquent,
263 1 Redmine Admin
elle ne peut être utilisée que sur des commits non publiés.
264 35 Daniel Dehennin
265 74 Daniel Dehennin
Le principe est le même que le greffage en botanique :
266 35 Daniel Dehennin
267 74 Daniel Dehennin
# On coupe la branche ;
268 1 Redmine Admin
# On la greffe sur une autre.
269 35 Daniel Dehennin
270 45 Fabrice Barconnière
En pratique, c’est surtout utilisé pour préparer l’intégration de nos
271 1 Redmine Admin
modifications dans une branche publique.
272 35 Daniel Dehennin
273 74 Daniel Dehennin
C’est un peu le miroir du « merge workflow ».
274 35 Daniel Dehennin
275 74 Daniel Dehennin
Dans le « merge workflow », la fusion se fait sur la branche publique
276 1 Redmine Admin
et les conflits sont gérés dans l’histoire de la branche publique.
277 35 Daniel Dehennin
278 74 Daniel Dehennin
Dans le « rebase workflow », c’est l’inverse, tout se fait dans la
279 1 Redmine Admin
branche que l’on souhaite intégrer à la branche publique.
280 35 Daniel Dehennin
281 74 Daniel Dehennin
La procédure est décomposée comme suit :
282 35 Daniel Dehennin
283 74 Daniel Dehennin
# Mise de côté de tous les commits de la branche depuis sa création :
284 35 Daniel Dehennin
  on revient dans le tronc de développement (branche privée) à la
285 74 Daniel Dehennin
  version sur laquelle notre branche est basée ;
286 35 Daniel Dehennin
# Intégration de tous les changements de la branche publique survenus
287 74 Daniel Dehennin
  depuis ;
288 35 Daniel Dehennin
# Application de tous les commits mis de côté, il faut gérer les
289 35 Daniel Dehennin
  éventuels conflits.
290 35 Daniel Dehennin
291 35 Daniel Dehennin
Avant la procédure, la branche privée était basée sur la branche
292 45 Fabrice Barconnière
publique à un certain instant dans le passé.
293 35 Daniel Dehennin
294 35 Daniel Dehennin
Après la procédure, la branche privée est basée sur le dernier commit
295 35 Daniel Dehennin
de la branche publique.
296 35 Daniel Dehennin
297 35 Daniel Dehennin
On a donc changé la base de la branche, d’où le nom de cette méthode.
298 35 Daniel Dehennin
299 74 Daniel Dehennin
Tout cela se fait simplement par :
300 1 Redmine Admin
301 35 Daniel Dehennin
<pre>
302 1 Redmine Admin
  moi@work:~/src/projet(mabranche)$ git rebase master
303 1 Redmine Admin
</pre>
304 35 Daniel Dehennin
305 35 Daniel Dehennin
Il est possible de faire fréquemment des rebases des branches privées
306 45 Fabrice Barconnière
par rapport à la branche publique où seront intégrées les
307 1 Redmine Admin
modifications.
308 35 Daniel Dehennin
309 35 Daniel Dehennin
On minimise ainsi les conflits ou, plus précisément, on les dilue dans
310 1 Redmine Admin
le temps.
311 35 Daniel Dehennin
312 35 Daniel Dehennin
Ce principe de rebase est à utiliser, au moins avant l’intégration à
313 35 Daniel Dehennin
la branche publique, afin d'avoir une histoire plus propre de la
314 1 Redmine Admin
branche et ce en fusionnant certains commits.
315 35 Daniel Dehennin
316 45 Fabrice Barconnière
Dans ce cas on ne rebase pas par rapport à une branche publique, mais
317 19 Joël Cuissinat
par rapport à un commit de la branche privée.
318 35 Daniel Dehennin
319 35 Daniel Dehennin
Par exemple, ne pas avoir un commit ajoutant une fonctionnalité et les
320 19 Joël Cuissinat
30 suivants qui corrigent les inévitables erreurs typographiques.
321 19 Joël Cuissinat
322 35 Daniel Dehennin
323 74 Daniel Dehennin
h1. « Le blabla c’est bien, mais en pratique ? » par moi©®™
324 35 Daniel Dehennin
325 74 Daniel Dehennin
h2. Puisque je vous dis que les branches ça ne coûte rien !
326 35 Daniel Dehennin
327 36 Daniel Dehennin
Dans git, une branche est simplement un fichier dans l’arborescence du
328 1 Redmine Admin
répertoire @.git/refs/heads/@.
329 35 Daniel Dehennin
330 35 Daniel Dehennin
Ce fichier contient l’identifiant du dernier commit de cette branche,
331 35 Daniel Dehennin
c’est le "SHA1":http://fr.wikipedia.org/wiki/SHA1 du contenu de l’objet (les détails sont accessibles dans
332 74 Daniel Dehennin
"Les tripes de Git":http://git-scm.org/book/fr/ch9-0.html).
333 35 Daniel Dehennin
334 36 Daniel Dehennin
L’identifiant de commit référence un fichier dans l’arborescence du
335 74 Daniel Dehennin
répertoire @.git/objects/@, avec :
336 35 Daniel Dehennin
337 35 Daniel Dehennin
* les deux premiers caractères (1 octet noté en hexadécimal) sont le
338 74 Daniel Dehennin
  nom d’un sous répertoire ;
339 1 Redmine Admin
* le reste des caractères sont le nom du fichier.
340 35 Daniel Dehennin
341 35 Daniel Dehennin
Connaître l’identifiant du dernier commit est suffisant pour remonter
342 1 Redmine Admin
l’arbre généalogique.
343 35 Daniel Dehennin
344 35 Daniel Dehennin
Faire une nouvelle branche se résume donc à créer un fichier ne
345 1 Redmine Admin
contenant qu’un identifiant.
346 35 Daniel Dehennin
347 74 Daniel Dehennin
On créé une branche dédiée pour le développement à faire :
348 35 Daniel Dehennin
<pre>
349 1 Redmine Admin
  moi@work:~/src/projet(master)$ git checkout -b issue/42 master
350 1 Redmine Admin
</pre>
351 35 Daniel Dehennin
352 1 Redmine Admin
h2. Le clonage déontologiquement correcte
353 35 Daniel Dehennin
354 35 Daniel Dehennin
Afin de tester nos modifications avant publication, nous pouvons
355 35 Daniel Dehennin
copier les fichiers sur une machine de test, par quelque moyen que ce
356 1 Redmine Admin
soit.
357 35 Daniel Dehennin
358 35 Daniel Dehennin
Un de ces moyens, et le plus simple dans notre cas, est d’utiliser
359 1 Redmine Admin
git.
360 35 Daniel Dehennin
361 74 Daniel Dehennin
Étant donné que :
362 35 Daniel Dehennin
363 35 Daniel Dehennin
* Nous souhaitons tester les modifications apportées par le
364 74 Daniel Dehennin
  développement enregistré dans une branche non publiée ;
365 35 Daniel Dehennin
* Nous ne souhaitons pas publier cette branche privée tant que tout ne
366 74 Daniel Dehennin
  sera pas propre ;
367 35 Daniel Dehennin
368 1 Redmine Admin
Nous allons créer une copie conforme de notre dépôt, sur la machine de test.
369 35 Daniel Dehennin
370 1 Redmine Admin
Le fonctionnement est simple, un dépôt git, qu’il soit sur un serveur
371 1 Redmine Admin
http ou dans notre répertoire, peut servir de base à un clone.
372 35 Daniel Dehennin
373 1 Redmine Admin
Et un clone, ça peut se faire par "SSH":http://fr.wikipedia.org/wiki/SSH.
374 35 Daniel Dehennin
375 74 Daniel Dehennin
Nous avons besoin :
376 35 Daniel Dehennin
377 74 Daniel Dehennin
* D’une machine de test ;
378 74 Daniel Dehennin
* D’un accès "SSH":http://fr.wikipedia.org/wiki/SSH sur cette machine ;
379 53 Daniel Dehennin
* De l’outil git installé sur cette machine.
380 35 Daniel Dehennin
381 35 Daniel Dehennin
Aucun fichier ne sera éditer sur cette machine, cela évite de
382 1 Redmine Admin
s’éparpiller.
383 35 Daniel Dehennin
384 35 Daniel Dehennin
Nous mettrons à jour ce dépôt par des pull, ce qui ne posera aucun
385 35 Daniel Dehennin
soucis comme expliqué plus haut du fait qu’il n’y aura aucune
386 1 Redmine Admin
modification locale à la machine de test.
387 1 Redmine Admin
388 35 Daniel Dehennin
<pre>
389 35 Daniel Dehennin
  moi@work:~/src/projet(master)$ ssh user@test-machine
390 35 Daniel Dehennin
  user@test-machine:~$ git clone ssh://moi@work/home/moi/src/projet && cd projet
391 1 Redmine Admin
  user@test-machine:~/projet(master)$ git checkout -b issue/42 origin/issue/42
392 1 Redmine Admin
  user@test-machine:~/projet(issue/42)$ # On est prêt
393 1 Redmine Admin
</pre>
394 1 Redmine Admin
395 1 Redmine Admin
On garde un shell sur la machine de test, on y reviendra souvent, à
396 1 Redmine Admin
moins d’être très fort et de tout réussir du premier coup.
397 35 Daniel Dehennin
398 74 Daniel Dehennin
h2. Les commits, c’est radioactif ?
399 1 Redmine Admin
400 74 Daniel Dehennin
Un commit, c’est un instantané du code à un instant « T ».
401 1 Redmine Admin
402 1 Redmine Admin
Si nous souhaitons tester l’impact de chaque commit sur un projet, il
403 1 Redmine Admin
est préférable que chacun d’eux soit fonctionnel.
404 1 Redmine Admin
405 1 Redmine Admin
Par exemple, si on modifie le nom d’une fonction ou d’une variable, on
406 46 Fabrice Barconnière
doit, dans le même commit, modifier toutes les utilisations de l’ancien
407 35 Daniel Dehennin
nom.
408 1 Redmine Admin
409 74 Daniel Dehennin
Chaque commit se doit d’être le plus « atomique » possible.
410 1 Redmine Admin
411 1 Redmine Admin
h2. Cycle de développement et tests
412 1 Redmine Admin
413 74 Daniel Dehennin
# On code :
414 1 Redmine Admin
<pre>
415 47 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ ${EDITOR} src/bidule.py
416 35 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git add src/bidule.py
417 35 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git commit
418 35 Daniel Dehennin
</pre>
419 74 Daniel Dehennin
# On nettoie la machine de test :
420 40 Daniel Dehennin
<pre>
421 40 Daniel Dehennin
  user@test-machine:~/projet(issue/42)$ make uninstall
422 40 Daniel Dehennin
</pre>
423 74 Daniel Dehennin
# On met à jour le dépôt de la machine de test :
424 35 Daniel Dehennin
<pre>
425 40 Daniel Dehennin
  user@test-machine:~/projet(issue/42)$ git pull origin
426 40 Daniel Dehennin
</pre>
427 74 Daniel Dehennin
# On met en place la nouvelle version du code à tester :
428 35 Daniel Dehennin
<pre>
429 40 Daniel Dehennin
  user@test-machine:~/projet(issue/42)$ make install
430 40 Daniel Dehennin
</pre>
431 48 Daniel Dehennin
# On test, si des problèmes persistent, on boucle sur 1 et on peut même utiliser un [[GitTrucsEtAstuces#Tu-balises-quand-tu-commit|petit truc]] pour s’y retrouver dans toutes ces itérations.
432 35 Daniel Dehennin
433 40 Daniel Dehennin
h2. Publication du développement
434 40 Daniel Dehennin
435 74 Daniel Dehennin
# On détermine le nombre de modification de notre branche par rapport à la branche « master »:
436 35 Daniel Dehennin
<pre>
437 41 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git log --oneline master..HEAD | wc -l
438 41 Daniel Dehennin
5
439 41 Daniel Dehennin
</pre>
440 74 Daniel Dehennin
# On nettoie notre histoire privée, dans notre exemple, à partir du 5e commit avant la fin:
441 41 Daniel Dehennin
<pre>
442 41 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git rebase -i HEAD~5
443 40 Daniel Dehennin
</pre>
444 74 Daniel Dehennin
# On rebase sur la dernière version de la branche publique :
445 40 Daniel Dehennin
<pre>
446 40 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git fetch origin
447 40 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git rebase origin/master
448 40 Daniel Dehennin
</pre>
449 74 Daniel Dehennin
# On intègre à la branche publique :
450 40 Daniel Dehennin
<pre>
451 40 Daniel Dehennin
  moi@work:~/src/projet(issue/42)$ git checkout master
452 40 Daniel Dehennin
  moi@work:~/src/projet(master)$ git merge issue/42
453 40 Daniel Dehennin
</pre>
454 74 Daniel Dehennin
# On [[GitTagging|tag]] un numéro de version, dans cet exemple, nous utilisons un "timestamp":http://fr.wikipedia.org/wiki/Timestamp :
455 40 Daniel Dehennin
<pre>
456 40 Daniel Dehennin
  moi@work:~/src/projet(master)$ git tag -s -m "release/$(date +%Y%m%d.%H%M)" release/$(date +%Y%m%d.%H%M)
457 40 Daniel Dehennin
</pre>
458 74 Daniel Dehennin
# On publie :
459 40 Daniel Dehennin
<pre>
460 40 Daniel Dehennin
  moi@work:~/src/projet(master)$ git push origin
461 40 Daniel Dehennin
</pre>
462 35 Daniel Dehennin
463 35 Daniel Dehennin
h1. Webographie
464 52 Daniel Dehennin
465 74 Daniel Dehennin
* "Pro git book":http://git-scm.org/book/fr/
466 1 Redmine Admin
* "Git Immersion":http://gitimmersion.fr
467 72 Daniel Dehennin
* "Git de bas en haut (en)":http://newartisans.com/2008/04/git-from-the-bottom-up
468 84 Daniel Dehennin
* "Activer le complètement automatique pour Bash":http://repo.or.cz/git/debian.git/blob/HEAD:/contrib/completion/git-prompt.sh
469 71 Daniel Dehennin
* "Utiliser des alias Git":https://git.wiki.kernel.org/index.php/Aliases
470 65 Daniel Dehennin
* "A successful git branching model":http://nvie.com/posts/a-successful-git-branching-model/
471 65 Daniel Dehennin
* "Le principe de DaggyFixes, par mercurial":http://mercurial.selenic.com/wiki/DaggyFixes
472 65 Daniel Dehennin
* "Le principe de DaggyFixes, par monotone":http://wiki.monotone.ca/DaggyFixes/
473 43 Daniel Dehennin
* "Avoiding Git Disasters: A Gory Story":http://www.randyfay.com/node/89
474 35 Daniel Dehennin
* "A rebase workflow":http://www.randyfay.com/node/91
475 35 Daniel Dehennin
* "Simpler Rebasing (avoiding unintentional merge commits)":http://randyfay.com/node/103
476 35 Daniel Dehennin
* "A git workflow for agile teams":http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
477 35 Daniel Dehennin
* "The case for git rebase":http://darwinweb.net/articles/the-case-for-git-rebase
478 74 Daniel Dehennin
* "Maintaining a project":http://git-scm.org/book/ch5-3.html
479 35 Daniel Dehennin
* "Packaging software using Git":http://www.golden-gryphon.com/software/misc/packaging.html
480 1 Redmine Admin
* "Packaging with git":http://wiki.debian.org/PackagingWithGit/
481 60 Daniel Dehennin
* "Software Branching and Parallel Universes":http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
482 60 Daniel Dehennin
* "Using signed tag in pull requests":http://git-blame.blogspot.com/2012/01/using-signed-tag-in-pull-requests.html
483 60 Daniel Dehennin
* "Trouver la source des cherry-pick avec git ?":http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
484 60 Daniel Dehennin
* "Making Sense of Revision-Control Systems":http://cacm.acm.org/magazines/2009/9/38901-making-sense-of-revision-control-systems/fulltext
485 61 Daniel Dehennin
* "One best practice workflow with git":http://wildfalcon.com/archives/2008/05/05/best-practice-work-flow-with-git/
486 63 Daniel Dehennin
* "GitGuys":http://www.gitguys.com/