hgbook
changeset 958:f42151a42f9e
Merge with William
author | Romain PELISSE <belaran@gmail.com> |
---|---|
date | Sun Feb 22 16:52:18 2009 +0100 (2009-02-22) |
parents | 320142ca5144 5abf0e11ce7e |
children | b3cb66d935cf dd7511a5c127 |
files | fr/tour-basic.tex |
line diff
1.1 --- a/fr/tour-basic.tex Sun Feb 22 16:20:08 2009 +0100 1.2 +++ b/fr/tour-basic.tex Sun Feb 22 16:52:18 2009 +0100 1.3 @@ -467,14 +467,19 @@ 1.4 Vous pouvez utiliser n'importe quelle valeur pour votre \texttt{username}, 1.5 car cette information est destinée à d'autres personnes et non à être 1.6 interprétée par Mercurial. La convention que la plupart des personnes 1.7 +<<<<<<< local 1.8 suivent est d'utiliser leurs noms suivies de leurs adresses emails, 1.9 comme montrée ci-dessus: 1.10 +======= 1.11 +suivent est d'utiliser leur nom suivi de leur adresse email, 1.12 +comme montrée ci dessus: 1.13 +>>>>>>> other 1.14 1.15 \begin{note} 1.16 Le mécanisme interne du serveur \textit{web} intégré à Mercurial, 1.17 masque les adresses emails, pour rendre plus difficile leurs 1.18 récupérations par les outils utilisés par les \textit{spammmers}. 1.19 - Ceci réduit la probabilité que vous receviez encore plus de 1.20 + Ceci réduit la probabilité que de recevoir encore plus de 1.21 \textit{spam} si vous vous publiez un dépôt sur internet. 1.22 \end{note} 1.23 1.24 @@ -483,7 +488,7 @@ 1.25 Lorsqu'on effectue une opération de \textit{commit}, Mercurial 1.26 lance automatiquement un éditeur de texte pour permettre de saisir 1.27 un message qui décrira les modifications effectuées dans ce 1.28 -\textit{changeset}. Ce message est nommée le \emph{message de 1.29 +\textit{changeset}. Ce message est nommé le \emph{message de 1.30 \textit{commit}}. Ce sera un enregistrement pour tout lecteur 1.31 expliquant le pourquoi et le comment de vos modifications, et il sera 1.32 affiché par la commande \hgcmd{log}. 1.33 @@ -496,7 +501,7 @@ 1.34 \emph{empty line} 1.35 HG: changed hello.c 1.36 \end{codesample2} 1.37 -Mercurial ignore les lignes qui commence avec ``\texttt{HG:}'', il 1.38 +Mercurial ignore les lignes qui commencent avec ``\texttt{HG:}'', il 1.39 ne les utilise que pour nous indiquer quels fichiers modifiés il se 1.40 prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a 1.41 aucune conséquence sur l'opération de \textit{commit}. 1.42 @@ -505,7 +510,11 @@ 1.43 1.44 Comme \hgcmd{log} n'affiche que la première ligne du message de 1.45 \textit{commit} par défaut, il est souvent considéré comme une bonne 1.46 +<<<<<<< local 1.47 pratique de rédiger des messages de \textit{commit} qui tiennent 1.48 +======= 1.49 +pratique de rédiger des messages de \textit{commit} qui n'entrent que 1.50 +>>>>>>> other 1.51 sur une seule ligne. Voilà un exemple concret de message de 1.52 \textit{commit} qui \emph{ne suit pas} cette directive, et qui a donc 1.53 un résumé peu lisible. 1.54 @@ -519,22 +528,35 @@ 1.55 A ce sujet, il faut noter qu'il n'existe pas de règle absolue dans ce 1.56 domaine. Mercurial lui-même n'interprète pas les contenus des messages 1.57 de \textit{commit}, ainsi votre projet est libre de concevoir différentes 1.58 +<<<<<<< local 1.59 politiques de mise en page des messages. 1.60 +======= 1.61 +politiques de formatage des messages. 1.62 +>>>>>>> other 1.63 1.64 Ma préférence personnelle va au message court, mais informatif, qui offre 1.65 -des précisions supplémentaires à ce que pourrait m'apprendre une commande 1.66 +des précisions supplémentaires par rapport à ce que pourrait m'apprendre une commande 1.67 \hgcmdargs{log}{--patch}. 1.68 1.69 \subsection{Annuler un \textit{commit}} 1.70 1.71 Si, en rédigeant le message, vous décidez que finalement vous ne 1.72 +<<<<<<< local 1.73 voulez pas effectuer ce \textit{commit}, il suffit de simplement quitter 1.74 l'éditeur sans sauvegarder. Ceci n'aura aucune conséquence sur le dépôt ou 1.75 +======= 1.76 +voulez pas effectuer ce \textit{commit}, il suffit de quitter simplement 1.77 +l'éditeur sans sauver. Ceci n'aura aucune conséquence sur le dépôt ou 1.78 +>>>>>>> other 1.79 les fichiers de l'espace de travail. 1.80 1.81 +<<<<<<< local 1.82 Si vous exécuter la commande \hgcmd{commit} sans aucun argument, elle 1.83 +======= 1.84 +Si vous exécutez la commande \hgcmd{commit} sans aucun argument, elle 1.85 +>>>>>>> other 1.86 enregistre toutes les modifications que vous avez faites, comme le montre 1.87 -la commande \hgcmd{status} et \hgcmd{diff}. 1.88 +les commandes \hgcmd{status} et \hgcmd{diff}. 1.89 1.90 \subsection{Admirer votre travail} 1.91 1.92 @@ -544,7 +566,11 @@ 1.93 identique à celle du \hgcmd{log}, mais qui n'affiche que la dernière 1.94 révision du dépôt. 1.95 \interaction{tour.tip} 1.96 +<<<<<<< local 1.97 On fait couramment référence à la dernière révision du dépôt comme 1.98 +======= 1.99 +On fait couramment référénce à la dernière révision du dépôt comme 1.100 +>>>>>>> other 1.101 étant la révision \textit{tip}, ou plus simplement le \textit{tip}. 1.102 1.103 \section{Partager ses modifications} 1.104 @@ -560,7 +586,11 @@ 1.105 1.106 Pour commencer, construisons un clone de notre dépôt \dirname{hello} 1.107 qui ne contiendra pas le changement que nous venons d'effectuer. Nous 1.108 +<<<<<<< local 1.109 l'appellerons notre dépôt temporaire \dirname{hello-pull}. 1.110 +======= 1.111 +appelerons notre dépôt temporaire \dirname{hello-pull}. 1.112 +>>>>>>> other 1.113 \interaction{tour.clone-pull} 1.114 1.115 Nous allons utiliser la commande \hgcmd{pull} pour apporter les 1.116 @@ -591,16 +621,20 @@ 1.117 1.118 Nous avons jusqu'à maintenant grossièrement définie la relation 1.119 entre un dépôt et un espace de travail. La commande \hgcmd{pull} que 1.120 -nous avons exécuter dans la section~\ref{sec:tour:pull} a apportée 1.121 +nous avons exécutée dans la section~\ref{sec:tour:pull} a apporté 1.122 des modifications, que nous avons vérifiées, dans notre dépôt, mais 1.123 il n'y a aucune trace de ces modifications dans notre espace de travail. 1.124 En effet, \hgcmd{pull} ne touche pas (par défaut) à l'espace de 1.125 travail. C'est la commande \hgcmd{update} qui s'en charge. 1.126 \interaction{tour.update} 1.127 1.128 -Il peut sembler un peu étrange que la commande \hgcmd{pull} ne met 1.129 +Il peut sembler un peu étrange que la commande \hgcmd{pull} ne mette 1.130 pas à jour l'espace de travail automatiquement. Il y a en fait une 1.131 +<<<<<<< local 1.132 très bonne raison à cela : vous pouvez utilisez la commande 1.133 +======= 1.134 +très bonne raison à cela: vous pouvez utiliser la commmande 1.135 +>>>>>>> other 1.136 \hgcmd{update} pour mettre à jour votre espace de travail à l'état 1.137 dans lequel il était à \emph{n'importe quelle révision} de l'historique 1.138 du dépôt. Si vous aviez un espace de travail contenant une ancienne 1.139 @@ -610,30 +644,47 @@ 1.140 1.141 Néanmoins, comme les opérations de \textit{pull} sont très souvent 1.142 suivies d'un \textit{update}, Mercurial vous permet de combiner les 1.143 -deux aisément passant l'option \hgopt{pull}{-u} à la commande 1.144 +deux aisément en passant l'option \hgopt{pull}{-u} à la commande 1.145 \hgcmd{pull} 1.146 \begin{codesample2} 1.147 hg pull -u 1.148 \end{codesample2} 1.149 1.150 Si vous étudiez de nouveau la sortie de la commande \hgcmd{pull} dans 1.151 +<<<<<<< local 1.152 la section~\ref{sec:tour:pull} quand nous l'avons exécuté sans l'option 1.153 \hgopt{pull}{-u}, vous pouvez constater qu'elle a affiché le rappel assez 1.154 utile comme quoi vous devez encore effectuer une opération pour mettre à jour 1.155 +======= 1.156 +la section~\ref{sec:tour:pull} quand nous l'avons exécutée sans l'option 1.157 +\hgopt{pull}{-u}, vous pouvez constater qu'elle a affiché un rappel assez 1.158 +utile : vous devez encore effectuer une opération pour mettre à jour 1.159 +>>>>>>> other 1.160 votre espace de travail: 1.161 \begin{codesample2} 1.162 (run 'hg update' to get a working copy) 1.163 \end{codesample2} 1.164 1.165 +<<<<<<< local 1.166 Pour découvrir sur quelle révision de l'espace de travail on est, utilisez 1.167 +======= 1.168 +Pour découvrir quelle révision de l'espace de travail en est où, utiliser 1.169 +>>>>>>> other 1.170 la commande \hgcmd{parents}. 1.171 \interaction{tour.parents} 1.172 Si vous regardez de nouveau le dessin~\ref{fig:tour-basic:history}, vous 1.173 +<<<<<<< local 1.174 verrez les flèches reliant entre eux les \textit{changeset}. Le nœud 1.175 d'où la flèche \emph{part} est dans chaque cas un parent, 1.176 et le nœud où la flèche \emph{arrive} est un enfant. 1.177 +======= 1.178 +verrez que les flèches reliant les \textit{changeset} entre eux. Le noeud 1.179 +dont la flèche mène \emph{de quelquepart} est dans chaque cas un parent, 1.180 +et le node dont la flèche mène \emph{vers quelquepart} est un enfant. %%%TODO: vers quelque part ? 1.181 +>>>>>>> other 1.182 L'espace de travail a un parent de la même manière, c'est ce \textit{changeset} 1.183 que l'espace de travail contient à ce moment. 1.184 +%%%TODO : difficile à comprendre : l'espace de travail a un parent, de la même manière, c'est ce changeset que l'espace... 1.185 1.186 Pour mettre à jour l'espace de travail d'une révision particulière, 1.187 indiquez un numéro de révision ou un \textit{changeset~ID} à la commande 1.188 @@ -641,8 +692,13 @@ 1.189 \interaction{tour.older} 1.190 Si vous ne précisez pas de manière explicite de numéro de révision 1.191 la commande \hgcmd{update} mettra à jour votre espace de travail avec 1.192 +<<<<<<< local 1.193 le contenu de la révision \textit{tip}, comme montré dans l'exemple 1.194 ci-dessus lors du second appel à \hgcmd{update}. 1.195 +======= 1.196 +le contenu de la révsion \textit{tip}, comme montrée dans l'exemple 1.197 +ci dessus lors du second appel à \hgcmd{update}. 1.198 +>>>>>>> other 1.199 1.200 \subsection{Transférer les modifications à un autre dépôt} 1.201 1.202 @@ -653,7 +709,7 @@ 1.203 ``pousser'' tout simplement} nos modifications. 1.204 \interaction{tour.clone-push} 1.205 La commande \hgcmd{outgoing} nous indique quels changements nous 1.206 -allons transférer vers l'autre serveyr. 1.207 +allons transférer vers l'autre serveur ? 1.208 \interaction{tour.outgoing} 1.209 Et la commande \hgcmd{push} effectue réellement le transfert. 1.210 \interaction{tour.push} 1.211 @@ -670,8 +726,13 @@ 1.212 1.213 \subsection{Partager ses modifications à travers le réseau} 1.214 1.215 +<<<<<<< local 1.216 Les commandes que nous avons étudiés dans les sections précédentes 1.217 ne se limitent pas aux dépôt locaux. Chacune commande fonctionne de la même 1.218 +======= 1.219 +Les commandes que nous avons étudiées dans les sections précédentes 1.220 +ne sont pas limitées aux dépôt locaux. Chacune fonctionne de la même 1.221 +>>>>>>> other 1.222 manière à travers une connexion réseau, il suffit de lui passer une 1.223 URL à la place d'un chemin de fichier local. 1.224
2.1 --- a/fr/tour-merge.tex Sun Feb 22 16:20:08 2009 +0100 2.2 +++ b/fr/tour-merge.tex Sun Feb 22 16:52:18 2009 +0100 2.3 @@ -1,7 +1,7 @@ 2.4 \chapter{Un rapide tour de Mercurial: fusionner les travaux} 2.5 \label{chap:tour-merge} 2.6 2.7 -Nous avons maintenons étudié comment clôner un dépôt, effectuer 2.8 +Nous avons maintenons étudié comment cloner un dépôt, effectuer 2.9 des changements dedans, et récupérer ou transférer depuis un 2.10 autre dépôt. La prochaine étape est donc de \emph{fusionner} les 2.11 modifications de différents dépôts. 2.12 @@ -9,9 +9,9 @@ 2.13 \section{Fusionner différents travaux} %%%TODO: better translation 2.14 %%% for 'Merging streams of work' ? 2.15 La fusion\footnote{NdT: Je garde fusion mais le jargon professionnel 2.16 -employera généralement le terme \textit{merge}.} est un aspect 2.17 +emploiera généralement le terme \textit{merge}.} est un aspect 2.18 fondamental lorsqu'on travail avec un gestionnaire de source 2.19 -distribé. 2.20 +distribué. 2.21 \begin{itemize} 2.22 \item Alice et Bob ont chacun une copie personnelle du dépôt d'un 2.23 projet sur lequel ils collaborent. Alice corrige un \textit{bug} 2.24 @@ -25,8 +25,8 @@ 2.25 \end{itemize} 2.26 2.27 Parce que la fusion est une opération si commune que je dois réaliser, 2.28 -Mercurial la rend facile. Etudions ensemble le déroulement des opérations. 2.29 -Nous commencerons par faire un clone d'encore un autre dépôt (vous voyez 2.30 +Mercurial la rend facile. Étudions ensemble le déroulement des opérations. 2.31 +Nous commencerons par faire un clone de encore un autre dépôt (vous voyez 2.32 comment on fait ça tout le temps ?) puis nous ferons quelques modifications 2.33 dessus. 2.34 \interaction{tour.merge.clone} 2.35 @@ -49,7 +49,7 @@ 2.36 2.37 \interaction{tour.merge.pull} 2.38 2.39 -Néanmoins, la commande \hgcmd{pull} nous indique quelquechose au 2.40 +Néanmoins, la commande \hgcmd{pull} nous indique quelque chose au 2.41 sujet des ``heads''. 2.42 2.43 \subsection{\textit{Head changesets}} %%%TODO: Hard (too?) to translate 2.44 @@ -103,15 +103,16 @@ 2.45 \end{figure} 2.46 2.47 Ceci met à jour de l'espace de travail de manière à ce qu'il contienne 2.48 -les modifications des \emph{deux} \textit{heads}, ce qui apparait dans 2.49 +les modifications des \emph{deux} \textit{heads}, ce qui apparaît dans 2.50 les sorties de la commande \hgcmd{parents} et le contenu de 2.51 \filename{hello.c}. 2.52 \interaction{tour.merge.parents} 2.53 2.54 -\subsection{Committing the results of the merge} 2.55 - 2.56 -Whenever we've done a merge, \hgcmd{parents} will display two parents 2.57 -until we \hgcmd{commit} the results of the merge. 2.58 +\subsection{Effectuer le \textit{commit} du résultat de la fusion} 2.59 + 2.60 +Dès l'instant où vous avez effectuer une fusion, \hgcmd{parents} vous 2.61 +affichera deux parents, avant que vous n'exécuter la commande 2.62 +\hgcmd{commit} sur le résultat de la fusion. 2.63 \interaction{tour.merge.commit} 2.64 Nous avons maintenant un nouveau \textit{tip}, remarquer qu'il contient 2.65 \emph{à la fois} nos anciennes \textit{heads} et leurs parents. Ce sont 2.66 @@ -128,10 +129,10 @@ 2.67 \section{Fusionner les modifications en conflit} 2.68 2.69 La plupart des fusions sont assez simple à réaliser, mais parfois 2.70 -vous vous trouverez à fusioner des fichiers où la modification touche 2.71 +vous vous trouverez à fusionner des fichiers où la modification touche 2.72 la même portion de code, au sein d'un même fichier. À moins que ces 2.73 modification ne soient identiques, ceci aboutira à un \emph{conflit}, 2.74 -et vous devrez décider comment réconcillier les différentes modifications 2.75 +et vous devrez décider comment réconcilier les différentes modifications 2.76 dans un tout cohérent. 2.77 2.78 \begin{figure}[ht] 2.79 @@ -148,7 +149,7 @@ 2.80 du conflit est de décider à quoi le fichier devrait ressembler. 2.81 2.82 Mercurial n'a pas de mécanisme interne pour gérer les conflits. 2.83 -À la place, il exéctue un programme externe appelé \command{hgmerge}. 2.84 +À la place, il exécute un programme externe appelé \command{hgmerge}. 2.85 Il s'agit d'un script shell qui est embarqué par Mercurial, vous 2.86 pouvez le modifier si vous le voulez. Ce qu'il fait par défaut est 2.87 d'essayer de trouver un des différents outils de fusion qui seront 2.88 @@ -159,7 +160,7 @@ 2.89 2.90 Il est aussi possible de demander à Mercurial d'exécuter un autre 2.91 programme ou un autre script au lieu de la commande \command{hgmerge}, 2.92 -en définissant la variable d'environement \envar{HGMERGE} avec le nom 2.93 +en définissant la variable d'environnement \envar{HGMERGE} avec le nom 2.94 du programme de votre choix. 2.95 2.96 \subsection{Utiliser un outil graphique de fusion} 2.97 @@ -186,7 +187,7 @@ 2.98 qui indiquent des conflits non résolus, avec un fusion manuel et pertinente 2.99 de ``notre'' version et de la ``leur''. 2.100 2.101 -Tout les quatres panneaux sont \emph{accrochés ensemble}, si nous déroulons 2.102 +Tout les quatre panneaux sont \emph{accrochés ensemble}, si nous déroulons 2.103 les ascenseurs verticalement ou horizontalement dans chacun d'entre eux, les 2.104 autres sont mise à jours avec la section correspondantes dans leurs fichiers. 2.105 2.106 @@ -199,56 +200,65 @@ 2.107 \end{figure} 2.108 2.109 Pour chaque portion de fichier posant problème, nous pouvons choisir 2.110 -de résoudre le le conlfit en utilisant en utilisant une combinaison 2.111 +de résoudre le le conflit en utilisant en utilisant une combinaison 2.112 de texte depuis la version de base, la notre, ou la leur. Nous pouvons 2.113 aussi éditer manuellement les fichiers à tous moments, si c'est 2.114 nécessaire. 2.115 2.116 Il y a \emph{beaucoup} d'outils de fusion disponibles, bien trop pour 2.117 -en parler de tous ici. Leurs disponibilités varient selon les plateformes 2.118 -ainsi que leurs avantages et incovénients. La plupart sont optimisé pour 2.119 +en parler de tous ici. Leurs disponibilités varient selon les plate formes 2.120 +ainsi que leurs avantages et inconvénients. La plupart sont optimisé pour 2.121 la fusion de fichier contenant un texte plat, certains sont spécialisé 2.122 -dans un format de fichier précis (générallement XML). 2.123 - 2.124 -\subsection{A worked example} 2.125 - 2.126 -In this example, we will reproduce the file modification history of 2.127 -figure~\ref{fig:tour-merge:conflict} above. Let's begin by creating a 2.128 -repository with a base version of our document. 2.129 +dans un format de fichier précis (généralement XML). 2.130 + 2.131 +\subsection{A worked example} %TODO: Find a translation for this ! 2.132 + 2.133 +Dans cet exemple, nous allons reproduire la modification de l'historique 2.134 +du fichier de la figure~\ref{fig:tour-merge:conflict} ci dessus. Commençons 2.135 +par créer un dépôt avec une version de base de notre document. 2.136 + 2.137 \interaction{tour-merge-conflict.wife} 2.138 -We'll clone the repository and make a change to the file. 2.139 +Créons un clone de ce dépôt et faisons une modification dans le fichier. 2.140 \interaction{tour-merge-conflict.cousin} 2.141 -And another clone, to simulate someone else making a change to the 2.142 -file. (This hints at the idea that it's not all that unusual to merge 2.143 -with yourself when you isolate tasks in separate repositories, and 2.144 -indeed to find and resolve conflicts while doing so.) 2.145 +Et un autre clone, pour simuler que quelqu'un d'autre effectuer une 2.146 +modification sur le fichier. (Ceci pour suggérer qu'il n'est pas rare 2.147 +de devoir effectuer des \textit{merge} avec vos propres travaux quand 2.148 +vous isoler les tâches dans des dépôts distincts. En effet, vous 2.149 +aurez alors à trouver et résoudre certains conflits). 2.150 \interaction{tour-merge-conflict.son} 2.151 -Having created two different versions of the file, we'll set up an 2.152 -environment suitable for running our merge. 2.153 +Maintenant que ces deux versions différentes du même fichier sont 2.154 +créées, nous allons configurer l'environnement approprié pour exécuter 2.155 +notre \textit{merge}. 2.156 \interaction{tour-merge-conflict.pull} 2.157 2.158 -In this example, I won't use Mercurial's normal \command{hgmerge} 2.159 -program to do the merge, because it would drop my nice automated 2.160 -example-running tool into a graphical user interface. Instead, I'll 2.161 -set \envar{HGMERGE} to tell Mercurial to use the non-interactive 2.162 -\command{merge} command. This is bundled with many Unix-like systems. 2.163 -If you're following this example on your computer, don't bother 2.164 -setting \envar{HGMERGE}. 2.165 +Dans cette exemple, je n'utiliserais pas la commande Mercurial 2.166 +habituelle \command{hgmerge} pour effectuer le \textit{merge}, 2.167 +car il me faudrait abandonner ce joli petit exemple automatisé 2.168 +pour utiliser un outil graphique. À la place, je vais définir 2.169 +la variable d'environnement \envar{HGMERGE} pour indiquer à 2.170 +Mercurial d'utiliser la commande non-interactive \command{merge}. 2.171 +Cette dernière est embarqué par de nombreux systèmes ``à la Unix''. 2.172 +Si vous exécuter cet exemple depuis votre ordinateur, ne vous 2.173 +occupez pas de définir \envar{HGMERGE}. 2.174 \interaction{tour-merge-conflict.merge} 2.175 -Because \command{merge} can't resolve the conflicting changes, it 2.176 -leaves \emph{merge markers} inside the file that has conflicts, 2.177 -indicating which lines have conflicts, and whether they came from our 2.178 -version of the file or theirs. 2.179 - 2.180 -Mercurial can tell from the way \command{merge} exits that it wasn't 2.181 -able to merge successfully, so it tells us what commands we'll need to 2.182 -run if we want to redo the merging operation. This could be useful 2.183 -if, for example, we were running a graphical merge tool and quit 2.184 -because we were confused or realised we had made a mistake. 2.185 - 2.186 -If automatic or manual merges fail, there's nothing to prevent us from 2.187 -``fixing up'' the affected files ourselves, and committing the results 2.188 -of our merge: 2.189 +Parce que \command{merge} ne peut pas résoudre les modifications 2.190 +conflictuelles, il laisse des \emph{marqueurs de différences} 2.191 +\footnote{NdT: Oui, je traduis \textit{merge markers} par un sens 2.192 +inverse en Français, mais je pense vraiment que c'est plus clair 2.193 +comme ça...} à l'intérieur du fichier qui a des conflits, indiquant 2.194 +clairement quelles lignes sont en conflits, et si elles viennent de 2.195 +notre fichier ou du fichier externe. 2.196 + 2.197 +Mercurial peut distinguer, à la manière dont la commande \command{merge} 2.198 +se termine, qu'elle n'a pas été capable d'effectuer le \textit{merge}, 2.199 +alors il nous indique qu'il faut devons effectuer de nouveau cette 2.200 +opération. Ceci peut être très utile si, par exemple, nous exécutons un 2.201 +outil graphique de fusion et que nous le quittons sans se rendre compte 2.202 +qu'il reste des conflits ou simplement par erreur. 2.203 + 2.204 +Si le \textit{merge} automatique ou manuel échoue, il n'y a rien pour 2.205 +nous empêcher de ``corriger le tir'' en modifiant nous même les fichiers, 2.206 +et enfin effectuer le \textit{commit} du fichier: 2.207 \interaction{tour-merge-conflict.commit} 2.208 2.209 \section{Simplifying the pull-merge-commit sequence}