diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 7c879362..21dba339 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -29,23 +29,23 @@ Pour créer une branche et y basculer tout de suite, vous pouvez lancer la comma [source,console] ---- -$ git checkout -b prob53 -Switched to a new branch "prob53" +$ git checkout -b iss53 +Switched to a new branch "iss53" ---- Cette commande est un raccourci pour : [source,console] ---- -$ git branch prob53 -$ git checkout prob53 +$ git branch iss53 +$ git checkout iss53 ---- .Création d'un nouveau pointeur de branche image::images/basic-branching-2.png[Création d'un nouveau pointeur de branche.] Vous travaillez sur votre site web et validez vos modifications. -Ce faisant, la branche `prob53` avance parce que vous l'avez extraite (c'est-à-dire que votre pointeur `HEAD` pointe dessus) : +Ce faisant, la branche `iss53` avance parce que vous l'avez extraite (c'est-à-dire que votre pointeur `HEAD` pointe dessus) : [source,console] ---- @@ -53,11 +53,11 @@ $ vim index.html $ git commit -a -m "ajout d'un pied de page [problème 53]" ---- -.La branche prob53 a avancé avec votre travail -image::images/basic-branching-3.png[La branche prob53 a avancé avec votre travail.] +.La branche iss53 a avancé avec votre travail +image::images/basic-branching-3.png[La branche iss53 a avancé avec votre travail.] À ce moment-là, vous recevez un appel qui vous apprend qu'il y a un problème sur le site web qu'il faut résoudre immédiatement. -Avec Git, vous n'avez pas à déployer en même temps votre correctif et les modifications déjà validées pour `prob53` et vous n'avez pas non plus à vous fatiguer à annuler ces modifications avant de pouvoir appliquer votre correctif sur ce qu'il y a en production. +Avec Git, vous n'avez pas à déployer en même temps votre correctif et les modifications déjà validées pour `iss53` et vous n'avez pas non plus à vous fatiguer à annuler ces modifications avant de pouvoir appliquer votre correctif sur ce qu'il y a en production. Tout ce que vous avez à faire, c'est simplement de rebasculer sur la branche `master`. Cependant, avant de le faire, notez que si votre copie de travail ou votre zone d'index contiennent des modifications non validées qui sont en conflit avec la branche que vous extrayez, Git ne vous laissera pas changer de branche. @@ -128,33 +128,33 @@ Maintenant, vous pouvez retourner travailler sur la branche qui contient vos tra [source,console] ---- -$ git checkout prob53 -Switched to branch "prob53" +$ git checkout iss53 +Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Nouveau pied de page terminé [issue 53]' -[prob53 ad82d7a] Nouveau pied de page terminé [issue 53] +[iss53 ad82d7a] Nouveau pied de page terminé [issue 53] 1 file changed, 1 insertion(+) ---- -.Le travail continue sur `prob53` -image::images/basic-branching-6.png[Le travail continue sur `prob53`.] +.Le travail continue sur `iss53` +image::images/basic-branching-6.png[Le travail continue sur `iss53`.] -Il est utile de noter que le travail réalisé dans la branche `correctif` n'est pas contenu dans les fichiers de la branche `prob53`. -Si vous avez besoin de les y rapatrier, vous pouvez fusionner la branche `master` dans la branche `prob53` en lançant la commande `git merge master`, ou vous pouvez retarder l'intégration de ces modifications jusqu'à ce que vous décidiez plus tard de rapatrier la branche `prob53` dans `master`. +Il est utile de noter que le travail réalisé dans la branche `correctif` n'est pas contenu dans les fichiers de la branche `iss53`. +Si vous avez besoin de les y rapatrier, vous pouvez fusionner la branche `master` dans la branche `iss53` en lançant la commande `git merge master`, ou vous pouvez retarder l'intégration de ces modifications jusqu'à ce que vous décidiez plus tard de rapatrier la branche `iss53` dans `master`. [[s_basic_merging]] === Fusions (_Merges_) Supposons que vous ayez décidé que le travail sur le problème #53 était terminé et prêt à être fusionné dans la branche `master`. -Pour ce faire, vous allez fusionner votre branche `prob53` de la même manière que vous l'avez fait plus tôt pour la branche `correctif`. +Pour ce faire, vous allez fusionner votre branche `iss53` de la même manière que vous l'avez fait plus tôt pour la branche `correctif`. Tout ce que vous avez à faire est d'extraire la branche dans laquelle vous souhaitez fusionner et lancer la commande `git merge`: [source,console] ---- $ git checkout master Switched to branch 'master' -$ git merge prob53 +$ git merge iss53 Merge made by the 'recursive' strategy. README | 1 + 1 file changed, 1 insertion(+) @@ -177,12 +177,12 @@ image::images/basic-merging-2.png[Un _commit_ de fusion.] Il est à noter que Git détermine par lui-même le meilleur ancêtre commun à utiliser comme base de la fusion. Ce comportement est très différent de celui de CVS ou Subversion (avant la version 1.5), où le développeur en charge de la fusion doit trouver par lui-même la meilleure base. Cela rend la fusion beaucoup plus facile dans Git que dans les autres systèmes. -À présent que votre travail a été fusionné, vous n'avez plus besoin de la branche `prob53`. +À présent que votre travail a été fusionné, vous n'avez plus besoin de la branche `iss53`. Vous pouvez fermer le ticket dans votre outil de suivi des tâches et supprimer la branche : [source,console] ---- -$ git branch -d prob53 +$ git branch -d iss53 ---- [[s_basic_merge_conflicts]] @@ -196,7 +196,7 @@ Si votre résolution du problème #53 a modifié la même section de fichier que [source,console] ---- -$ git merge prob53 +$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. @@ -235,10 +235,10 @@ Votre fichier contient des sections qui ressemblent à ceci : ->>>>>>> prob53:index.html +>>>>>>> iss53:index.html ---- -Cela signifie que la version dans `HEAD` (votre branche `master`, parce que c'est celle que vous aviez extraite quand vous avez lancé votre commande de fusion) est la partie supérieure de ce bloc (tout ce qui se trouve au-dessus de la ligne `=======`), tandis que la version de votre branche `prob53` se trouve en dessous. +Cela signifie que la version dans `HEAD` (votre branche `master`, parce que c'est celle que vous aviez extraite quand vous avez lancé votre commande de fusion) est la partie supérieure de ce bloc (tout ce qui se trouve au-dessus de la ligne `=======`), tandis que la version de votre branche `iss53` se trouve en dessous. Pour résoudre le conflit, vous devez choisir une partie ou l'autre ou bien fusionner leurs contenus vous-même. Par exemple, vous pourriez choisir de résoudre ce conflit en remplaçant tout le bloc par ceci : @@ -303,7 +303,7 @@ Le message de validation par défaut ressemble à ceci : [source,console] ---- -Merge branch 'prob53' +Merge branch 'iss53' Conflicts: index.html diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index ec495e15..880e8f43 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -10,7 +10,7 @@ Si vous la lancez sans argument, vous obtenez la liste des branches courantes : [source,console] ---- $ git branch - prob53 + iss53 * master test ---- @@ -22,8 +22,8 @@ Pour visualiser la liste des derniers _commits_ sur chaque branche, vous pouvez [source,console] ---- $ git branch -v - prob53 93b412c fix javascript issue -* master 7a98805 Merge branch 'prob53' + iss53 93b412c fix javascript issue +* master 7a98805 Merge branch 'iss53' test 782fd34 add scott to the author list in the readmes ---- @@ -33,11 +33,11 @@ Pour voir quelles branches ont déjà été fusionnées dans votre branche coura [source,console] ---- $ git branch --merged - prob53 + iss53 * master ---- -Comme vous avez déjà fusionné `prob53` un peu plus tôt, vous la voyez dans votre liste. +Comme vous avez déjà fusionné `iss53` un peu plus tôt, vous la voyez dans votre liste. Les branches de cette liste qui ne comportent pas le préfixe `*` peuvent généralement être effacées sans risque au moyen de `git branch -d` puisque vous avez déjà intégré leurs modifications dans une autre branche et ne risquez donc pas de perdre quoi que ce soit. Pour visualiser les branches qui contiennent des travaux qui n'ont pas encore été fusionnés, vous pouvez utiliser la commande `git branch --no-merged`  : diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index c669f96e..d1447375 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -12,7 +12,7 @@ Cela signifie que vous pouvez avoir plusieurs branches ouvertes en permanence po De nombreux développeurs travaillent avec Git selon une méthode qui utilise cette approche. Il s'agit, par exemple, de n'avoir que du code entièrement stable et testé dans leur branche `master` ou bien même uniquement du code qui a été ou sera publié au sein d'une _release_. Ils ont alors en parallèle une autre branche appelée `develop` ou `next`. Cette branche accueille les développements en cours qui font encore l'objet de tests de stabilité — cette branche n'est pas nécessairement toujours stable mais quand elle le devient, elle peut être intégrée (via une fusion) dans `master`. -Cette branche permet d'intégrer des branches thématiques (_topic branches_ : branches de faible durée de vie telles que votre branche `prob53`), une fois prêtes, de manière à s'assurer qu'elles passent l'intégralité des tests et n'introduisent pas de bugs. +Cette branche permet d'intégrer des branches thématiques (_topic branches_ : branches de faible durée de vie telles que votre branche `iss53`), une fois prêtes, de manière à s'assurer qu'elles passent l'intégralité des tests et n'introduisent pas de bugs. En réalité, nous parlons de pointeurs qui se déplacent le long des lignes des _commits_ réalisés. Les branches stables sont plus basses dans l'historique des _commits_ tandis que les branches des derniers développements sont plus hautes dans l'historique. @@ -41,7 +41,7 @@ Une branche thématique est une branche ayant une courte durée de vie créée e C'est une méthode que vous n'avez probablement jamais utilisée avec un autre VCS parce qu'il y est généralement trop lourd de créer et fusionner des branches. Mais dans Git, créer, développer, fusionner et supprimer des branches plusieurs fois par jour est monnaie courante. -Vous avez déjà vu ces branches dans la section précédente avec les branches `prob53` et `correctif` que vous avez créées. +Vous avez déjà vu ces branches dans la section précédente avec les branches `iss53` et `correctif` que vous avez créées. Vous y avez réalisé quelques _commits_ et vous les avez supprimées immédiatement après les avoir fusionnées dans votre branche principale. Cette technique vous permet de changer de contexte rapidement et complètement. Parce que votre travail est isolé dans des silos où toutes les modifications sont liées à une thématique donnée, il est beaucoup plus simple de réaliser des revues de code. Vous pouvez conserver vos modifications dans ces branches pendant des minutes, des jours ou des mois puis les fusionner quand elles sont prêtes, indépendamment de l'ordre dans lequel elles ont été créées ou traitées.