Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 23 additions & 23 deletions book/03-git-branching/sections/basic-branching-and-merging.asc
Original file line number Diff line number Diff line change
Expand Up @@ -29,35 +29,35 @@ 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]
----
$ 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.
Expand Down Expand Up @@ -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(+)
Expand All @@ -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]]
Expand All @@ -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.
Expand Down Expand Up @@ -235,10 +235,10 @@ Votre fichier contient des sections qui ressemblent à ceci :
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> 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 :

Expand Down Expand Up @@ -303,7 +303,7 @@ Le message de validation par défaut ressemble à ceci :

[source,console]
----
Merge branch 'prob53'
Merge branch 'iss53'

Conflicts:
index.html
Expand Down
10 changes: 5 additions & 5 deletions book/03-git-branching/sections/branch-management.asc
Original file line number Diff line number Diff line change
Expand Up @@ -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
----
Expand All @@ -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
----

Expand All @@ -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`  :
Expand Down
4 changes: 2 additions & 2 deletions book/03-git-branching/sections/workflows.asc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down