Serge NOEL
790 lines
40 KiB
Plaintext
790 lines
40 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="fr">
|
|
<head>
|
|
<title>JMRI: Git FAQ</title>
|
|
<meta name="author" content="Bob Jacobsen">
|
|
<meta name="keywords" content="JMRI technical code Git FAQ">
|
|
<!--#include virtual="/help/fr/parts/Style.shtml" -->
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
|
|
|
<!-- FAQ-Head -->
|
|
<script type="text/javascript">
|
|
/*<![CDATA[*/document.documentElement.className="hasJS";/*]]>*/
|
|
</script>
|
|
<link rel="stylesheet" type="text/css" href="/web/css/faq.css" media="screen"><!-- /FAQ-Head -->
|
|
</head>
|
|
|
|
<body>
|
|
<!--#include virtual="/help/fr/parts/Header_fr.shtml" -->
|
|
|
|
<div id="mBody">
|
|
<!--#include virtual="Sidebar.shtml" -->
|
|
|
|
<div id="mainContent">
|
|
<!-- Page Body -->
|
|
|
|
<h1>JMRI:FAQ Git</h1>
|
|
|
|
<p>Ceci est une Liste des Questions Fréquentes concernants GIT particulièrement comment
|
|
utiliser Git avec JMRI.</p>
|
|
|
|
<p>Il y a une <a href="getgitcode.shtml">page d'aide JMRI séparées</a> sur comment <a href=
|
|
"getgitcode.shtml">comment obtenir le code avec Git</a>.</p>
|
|
|
|
<p>Voir aussi le <a href="index.shtml">Technical index</a> pour de plus amples informations
|
|
sue la maintenance du code JMRI.</p>
|
|
|
|
<h2>Sujets Communs Utilisateur</h2>
|
|
|
|
<dl class="faq">
|
|
<dt id="install" class="on">Comment Installer Git?</dt>
|
|
|
|
<dd>
|
|
Git est un logiciel libre. Selon votre type ordinateur et vos préférences il y a
|
|
plusieurs façons de l'installer. Il y a plus d'informations sur le guide de la communauté
|
|
Git <a href="https://git-scm.com/book/en/v2/Getting-Started-Installing-Git">Getting
|
|
Started</a>.
|
|
<ul>
|
|
<li>L'obtenir depuis la page <a href="http://git-scm.com/downloads">Téléchargement
|
|
Git</a>.</li>
|
|
|
|
<li>Il est livré avec l'application GitHub Desktop, disponible depuis la page <a href=
|
|
"https://desktop.github.com">Téléchargement Git desktop</a> (OS X et Windows
|
|
seulement).</li>
|
|
|
|
<li>Pour le Mac, il est inclut quand vous <a href=
|
|
"https://developer.apple.com/xcode/download/">installer Xcode</a>.</li>
|
|
|
|
<li>Pour Linux vous pouvez essayer le paquet installateur, exemple: <code>sudo yum
|
|
install git</code> ou <code>sudo apt-get install git</code>.</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt>Configuration d'un environnement Git pour les Développeurs JMRI</dt>
|
|
|
|
<dd>
|
|
Vous pouvez régler votre répertoire local pour qu'il "pull" automatiquement depuis le
|
|
JMRI Master sur GitHub et "push" sur votre "fork" ( et aussi sur GitHub ):
|
|
<p><img src="/web/images/GitHubWorkflow.png" alt="">
|
|
</p>
|
|
|
|
<p>Cette flèche horizontale est la "Pull Request" ( et par conséquent "pull" ) qui
|
|
enregistre des informations sur la façon dont les choses entrent dans le référentiel.</p>
|
|
|
|
<p>Les flêches sont les deux opérations ( "push", "pull" ) et aussi les définitions de
|
|
<em>où</em> pour voir par exemple: un URL. Git peut stocker un raccourci pour une URL,
|
|
appelé " remote " Le remote par défaut est appelé "origin". Vous pouvez avoir plusieurs
|
|
remotes définis.</p>
|
|
|
|
<p>Via l'outil ligne de commande git vous pouvez faire ceci par la commande:</p>
|
|
|
|
<blockquote>
|
|
<code>$ git remote set-url --push origin
|
|
https://github.com/<em>username</em>/JMRI.git</code>
|
|
</blockquote>
|
|
où <code>username</code> est votre nom utilisateur github. Vous pouvez vérifier l'état
|
|
actuel des répertoires push et pull avec:
|
|
<blockquote>
|
|
<code>$ git remote -v</code><br>
|
|
<code>origin https://github.com/JMRI/JMRI.git (fetch)</code><br>
|
|
<code>origin https://github.com/<em>username</em>/JMRI.git (push)</code><br>
|
|
</blockquote>
|
|
Ceci dit que, par défaut, fetches et pulls viennent du référentiel principal JMRI/JMRI.
|
|
Quand vous "push", d'autre part il va sur votre propre répertoire
|
|
<p>Une fois que vous avez une copie de vos changements sur GitHub, il est facile de
|
|
<a href="https://help.github.com/articles/creating-a-pull-request/">générer un pull
|
|
request</a> (Lien vers GitHub)</p>
|
|
|
|
<ul>
|
|
<li>Dans un navigateur, naviguez jusqu'á répertoire sur GitHub qui a les changements
|
|
que vous voulez que quelqu'un "push" et</li>
|
|
|
|
<li>pressez l'icone de comparaison verte <img src="/web/images/GitHubPR1.png" alt=""> ,
|
|
puis cliquez sur "Create a Pull Resquest".</li>
|
|
|
|
<li>Après votre "pull request" a bien été revu, il peut être fusionné dans le
|
|
référentiel principal JMRI/JMRI. Le développeur JMRI qui "pulls" vos changements dans
|
|
la source de la communauté a besoin d'avoir accès á un répertoire en ligne qui a vos
|
|
changements, ce qui explique pourquoi vous avez besoin d'avoir une place sur GitHub en
|
|
premier lieu ...</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt id="working">Travailler avec Git</dt>
|
|
|
|
<dd>
|
|
<p>Avec SVN et CVS vous extrayez un "répertoire de travail" pour y effectuer vos
|
|
modifications. Travailler pendant un certain temps, et éventuellement engager ( commit )
|
|
toutes vos modifications dans le dépôt principal.</p>
|
|
|
|
<p>Git travaille avec un concept différent. Au lieu d'avoir de multiples répertoires de
|
|
travail, vous avez un simple répertoire qui a été "cloné" depuis le référentiel
|
|
principal. Si vous faites un petit changement individuel, vous pouvez travailler
|
|
directement sur la branche "master" en son sein. Si non, voir ci-dessous: <a href=
|
|
"#branch">Branchement</a>.</p>
|
|
|
|
<p>Pour comprendre Git, il est bon de connaitre les <em>places</em> variés dans votre
|
|
répertoire git local:</p>
|
|
|
|
<ul>
|
|
<li>Le contenu depuis le répertoire "remote", qui vit sous le répertoire caché
|
|
<code>.git/</code> ,</li>
|
|
|
|
<li>La zone "staging" ( appelée aussi "index" ou "cache" ), et</li>
|
|
|
|
<li>La "branche" nommée que vous utilisée, qui est dans</li>
|
|
|
|
<li>L'arbre de travail.</li>
|
|
</ul>
|
|
|
|
<p>Quand vous <em>clonez</em> un répertoire git, vous créez une structure répertoire qui
|
|
contient tous ces éléments. Á moins que vous arrêtiez, l'arbre de travail commence rempli
|
|
avec le contenu de la <em>master branch</em> du répertoire que vous avez cloné- et le
|
|
<em>staging area</em> est vide quand vous faites des changements dans les fichiers de
|
|
l'arbre de travail, vous avez besoin de les <em>ajouter</em> explicitement dans la la
|
|
zone de préparation. Git connait ces fichiers, mais ils ne font pas encore officiellement
|
|
partie de votre répertoire local.</p>
|
|
|
|
<p>Une fois que vous avez rempli la zone de préparation avec tout ce que vous avez
|
|
changé, une opération <em>commit</em> ( soumission ) engagera officiellement vos
|
|
modifications dans votre structure répertoire <code>.git/</code>.</p>
|
|
|
|
<p>Quand vous <em>pull</em> ou <em>push</em>, vous dites á Git de synchroniser votre
|
|
contenu <code>git/</code> avec avec celui du répertoire distant dont vous avez
|
|
initialement cloné le contenu.</p>
|
|
|
|
<p>La documentation suivante devrait vous aider á démarrer en utilisant soit la ligne de
|
|
commande git ou GitHub Desktop:</p>
|
|
|
|
<ul>
|
|
<li>Connectez-vous á GitHub et clonez votre propre copie du référentiel principal JMRI.
|
|
Ceci vous donne un endroit sûr où vous pourrez collez et extraire sans affecter les
|
|
autres.</li>
|
|
|
|
<li>Utilisation de Git:
|
|
<ul>
|
|
<li>Clonez le référentiel JMRI sur votre système local ( ou actualisez le ):
|
|
<blockquote>
|
|
<code>$ git clone https://github.com/JMRI/JMRI.git</code><br>
|
|
ou<br>
|
|
<code>$ git fetch</code><br>
|
|
<code>$ git diff ...origin</code><br>
|
|
<code>$ git merge origin/master<br>
|
|
Auto-merging ... files ...<br>
|
|
CONFLICT (content): Merge conflict in <em>some_file</em><br>
|
|
Échec Fusion Automatique; corriger les conflits et soumettez le résultat.<br>
|
|
$ vi <em>some_file</em> # Le fichier a des conflits marqués, éditer le pour
|
|
correction...<br>
|
|
$ git add <em>some_file</em><br>
|
|
$ git commit -m "Merged master fixed conflict"<br>
|
|
$ git merge origin/master</code><br>
|
|
ou<br>
|
|
<code>$ git pull https://github.com/JMRI/JMRI.git</code><br>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Faites vos changement localement, testez les, etc.
|
|
<blockquote>
|
|
<code>$ git add <em>newfile</em></code><br>
|
|
<code>$ git rm <em>newfile</em></code><br>
|
|
<code>$ git add .</code><br>
|
|
<br>
|
|
<code>$ git status</code><br>
|
|
<br>
|
|
<code>$ git fetch</code><br>
|
|
<code>$ git merge</code><br>
|
|
<br>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Rendez vos changements disponibles pour la communauté
|
|
<blockquote>
|
|
<code>$ git commit -m <em>"commit message"</em></code><br>
|
|
or<br>
|
|
<code>$ git commit -a -m <em>"commit message"</em></code><br>
|
|
</blockquote>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>Utilisation de GitHub Desktop
|
|
<ul>
|
|
<li>Clonez le référentiel JMRI sur votre système local en choisissant un élément de
|
|
l'onglet "Clone" dans le fichier >Clone repository.. menu et cliquez
|
|
"Clone":<br>
|
|
<a href="images/GhDtCloneDialog.png"><img src="images/GhDtCloneDialog.png" width=
|
|
"267" height="184" alt="GitHub Desktop PR dialog"></a></li>
|
|
|
|
<li>Faites vos changement localement, testez les, etc.<br>
|
|
Quand tout cela fonctionne, <em>soumettez</em> votre modification á votre
|
|
référentiel JMRI local en retournant á l'application GitHub Desktop, examinez
|
|
tous les changements constatés par le programme, entrez un Résumé [1] et une
|
|
Description [2] et enfin en cliquant sur le bouton [3] soumettre la <
|
|
branche> Bouton:<br>
|
|
<a href="images/GhDtWindow.png"><img src="images/GhDtWindow.png" width="410"
|
|
height="256" alt="GitHub Desktop Window"></a>
|
|
<p>Après votre Soumission, un point blanc apparaìtra près de la fin de la ligne
|
|
qui ressemble á une voie d'évitement dans un <em>plan de voie</em>. Cliquez pour
|
|
lire le titre. Pour voir les fichiers modifiés á un autre moment dans le temps,
|
|
cliquez sur un ancien point de soumission:<br>
|
|
<a href="images/GhDtWindowSeeCommit.png"><img src=
|
|
"images/GhDtWindowSeeCommit.png" width="456" height="79" alt=
|
|
"GitHub Desktop Commit"></a></p>
|
|
|
|
<p>Après une soumission, vos nouvelles modifications sont seulement ajoutées
|
|
avotre copie locale de votre branche. Pour les faire apparaìtre dans un endroit
|
|
où d'autres personnes peuvent les voir soit vous cliquez le bouton
|
|
<strong>Sync</strong> en haut á droite, choisissez Sync ( Cmd-S ) depuis le menu
|
|
répertoire, ou synchroniser automatiquement Github Desktop en cochant dans le
|
|
menu Edit l'élément Automatically Sync after Committing:<br>
|
|
<a href="images/GhDtSyncSetting.png"><img src="images/GhDtSyncSetting.png" width=
|
|
"154" height="122" alt="GitHub Desktop auto sync menu"></a></p>
|
|
</li>
|
|
|
|
<li>Quand vous avez travaillé sur quelque chose dans GhDt durant une semaine ou
|
|
plus, d'autres ont pu travailler définitivement sur d'autres parties de JMRI. Pour
|
|
intégrer ces nouvelles données dans votre copy, cliquez sur le bouton
|
|
<strong>Update from JMRI/master</strong> en haut á gauche du panneau ( ou
|
|
choisissez "Pull" depuis le menu "Repository )<br>
|
|
Vous verrez une animation d'un symbôle de branche dans un cercle, passant de la
|
|
ligne blanche vers le bas á la ligne en dessous:<br>
|
|
<a href="images/GhDtUpdateFrom.png"><img src="images/GhDtUpdateFrom.png" width=
|
|
"456" height="79" alt="GitHub Desktop Pull"></a>
|
|
<p>Ceci vous dit que du nouveau code a été copié dans votre répertoire, et dans
|
|
quelques secondes cclui-ci sera aussi copié sur votre ordinateur, aussi vous
|
|
pourrez z voir ou l'utiliser, á moins que qu'ils aient travaillé sur les mêmes
|
|
lignes de code ( Voir Résoudre un Conflit de Fusion, ci-dessous )</p>
|
|
</li>
|
|
|
|
<li>pour rendre vos changements disponibles pour la communauté cliquez "Pull
|
|
Request" ( bouton en haut á droite ), entrez un titre et cliquez "Create".<br>
|
|
|
|
<table summary="">
|
|
<tr>
|
|
<td><a href="images/GhDtPRCreate.png"><img src="images/GhDtPRCreate.png"
|
|
width="129" height="215" alt="GitHub Desktop Create PR dialog"></a>
|
|
</td>
|
|
<td>Le nom du bouton PR changera en <strong>#123</strong><br>
|
|
signalant que vous ne pouvez pas faire d'autre PR dans cette branche<br>
|
|
depuis ici ( mais vous pouvez encore soumettre des modifications ):</td>
|
|
<td><a href="images/GhDtPRCreated.png"><img src="images/GhDtPRCreated.png"
|
|
width="129" height="215" alt="GitHub Desktop PR Created message"></a>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Normalement, un PR est destiné á la branche principale du référentiel
|
|
original, dit JMRI: master. Vous pouvez "pull" votre propre répertoire distant,
|
|
mais seuls, les maintenanciers, pourront "pull" vos modifications dans le "vrai"
|
|
JMRI:master. Avant de le faire, ils étudient ce que vous avez écrit, peut être
|
|
même les mettre sur leur propre répertoire pout les tester avant de les fusionner
|
|
pour que tous les autres utilisateurs de JMRI les voient.<br>
|
|
Quand votre PR est pulled & fusionné & fermé, le nom PR #123 disparaìtra
|
|
et vous pourrez effacer la branche en toute sécurité.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt id="branch">Branchement</dt>
|
|
|
|
<dd>
|
|
Toujours travailler sur une <em>branche</em> nommée, jamais sur une nommée "master". Bien
|
|
que vous puissiez travailler directement sur la branche "master" par défaut, une bonne
|
|
"Pratique Git" vous encourage á créer une branche afin que vous puissiez travailler sur
|
|
elle et ne jamais gâcher votre copie locale de JMRI: master. Les branches dans Git sont
|
|
faciles et pas chères á créer et utiliser; vous pouvez avoir de multiple branches en même
|
|
temps, et basculer entre elles si vous travaillez sur des projets différents.
|
|
<p>nous recommandons que vous nommiez les branches démarrant avec votre nom d'utilisateur
|
|
GitHub ou vos initiales (par exepmle, "abc") ou quelque chose qui suggère que vous
|
|
travaillez dessus: <code>"abc-decoder-xml-change"</code>, <code>"abc-2015-09-14"</code>,
|
|
<code>"abc-next-cool-thing"</code>, et <code>"abc-patch-NNNN"</code> sont tous correcte.
|
|
De cette manière, nous savons que c'est vous.</p>
|
|
|
|
<ul>
|
|
<li>Utilisation de Git:
|
|
<ul>
|
|
<li>Pour créer une branche appelée ;<em>branchname</em>", vous faites<br>
|
|
|
|
<blockquote>
|
|
<code>git checkout -b <em>nomdebranche</em></code><br>
|
|
</blockquote>
|
|
Le "-b" dit de créer la branche. Pour basculer sur une branche existante, il
|
|
suffit d'oublier cette option:<br>
|
|
|
|
<blockquote>
|
|
<code>git checkout <em>nomdebranche</em></code><br>
|
|
</blockquote>
|
|
Pour voir toutes les branches actuelles, faire<br>
|
|
|
|
<blockquote>
|
|
<code>git branch</code><br>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Si d'autres personnes dans la communauté font des changements sur la branche
|
|
master, vous pouvez garder votre branche á jour en fusionnant ces changements avec
|
|
votre branche<br>
|
|
|
|
<blockquote>
|
|
<code>git checkout <em>branchname</em><br>
|
|
git merge -m"merging in current contents of master" master</code><br>
|
|
</blockquote>
|
|
( Si vous omettez l'option de message, vous pouvez être invité á en ajouter un
|
|
dans un éditeur ) Si des modifications ont été collectées et fusionnées, vous
|
|
pouvez ensuite les soumettre á votre branche:
|
|
<blockquote>
|
|
<code>git commit -a</code><br>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Lorsque vous avez terminé, fusionner vos modifications dans la ligne commune
|
|
de développement avec<br></p>
|
|
|
|
<blockquote>
|
|
<code>git checkout master<br>
|
|
git merge -m"merging to master" <em>branchname</em><br>
|
|
git commit -a</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Vous popuvez alors effacer votre branche ( si vous avez réellement fini avec
|
|
elle ) avec<br>
|
|
|
|
<blockquote>
|
|
<code>git checkout master<br>
|
|
git branch -d branchname</code>
|
|
</blockquote>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>Utilisation de GitHub Desktop:
|
|
<ul>
|
|
<li>Cliquez sur le bouton "Add a Branch( + )", donnez un nom pour votre nouvelle
|
|
branche et en utilisant "From": sélectionnez la branche où vous voulez créer la
|
|
nouvelle branche:<br>
|
|
<a href="images/GhDtNewBranch.png"><img src="images/GhDtNewBranch.png" width="208"
|
|
height="122" alt="GitHub Desktop Repo Setting"></a></li>
|
|
|
|
<li>Pour effacer une branche, sélectionnez la dans le menu contextuel "Show
|
|
Branches", et sélectionnez <strong>Delete "my-patch"</strong> depuis le menu
|
|
Branch.<br>
|
|
Vous ne pouvez pas le faire avec la branche master, aussi ne travaillez pas sur
|
|
elle, mais sur une branche nommée.<br>
|
|
<a href="images/GhDtDeleteBranch.png"><img src="images/GhDtDeleteBranch.png" width=
|
|
"156" height="79" alt="GitHub Desktop Repo Setting"></a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>Vous pouvez opter pour créer et effacer des branches sur le web GitHub aussi
|
|
facilement. Plus d'aide sur <a href=
|
|
"https://help.github.com/articles/creating-and-deleting-branches-within-your-repository/">
|
|
Github Web Branching</a>.</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt id="share">Partage de Branches</dt>
|
|
|
|
<dd>
|
|
Un des avantages des branches Git est qu'il est aisé pour les gens de les partager. Ceci
|
|
permet á une personne de travailler avec quelque chose qu'un autre a terminé, y compris
|
|
l'édition et de l'amélioration, sans qu'elle soit accessible pour tout le monde.
|
|
<p>Arnie a développé quelque chose sur la branche ""arnie-great-tool". Bill veut essayer
|
|
de l'utiliser sur sa mise en page. Les étapes sont les suivantes:</p>
|
|
|
|
<ol>
|
|
<li>Arnie le soumet au repertoire local,et ensuite le met sur son répertoire GitHub.
|
|
<blockquote>
|
|
<code>git checkout arnie-great-tool<br>
|
|
(work on changes)<br>
|
|
git commit -m"Added support for the Frobnab 2000"<br>
|
|
git push</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Bill peut ensuite le récupérer depuis le répertoire d'Arnie
|
|
<blockquote>
|
|
<code>git pull https://github.com/arnie/JMRI.git arnie-great-tool<br>
|
|
git checkout arnie-great-tool</code>
|
|
</blockquote>
|
|
où la première partie de "pull" est l'URL du répertoire d'Arnie.
|
|
</li>
|
|
|
|
<li>Bill peut travailler avec le code, et même le changer si nécessaire. S'il fait des
|
|
changement et veut les envoyer á Arnie, il fait le même processus á l'envers:
|
|
<blockquote>
|
|
<code>git commit -m"Fixed a bug in sternerstat handling"<br>
|
|
git push</code>
|
|
</blockquote>
|
|
Puis Arnie peut fusionner ces changements dans sa propre copie avec:
|
|
<blockquote>
|
|
<code>git checkout arnie-great-tool<br>
|
|
git pull https://github.com/bill/JMRI.git arnie-great-tool</code>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
</dd>
|
|
|
|
<dt>La résolution d'un conflit de fusion</dt>
|
|
|
|
<dd>
|
|
Il est pas rare que deux personnes ou plus ont des idées sur la même partie du programme
|
|
ou le site Web JMRI, chacun faisant des soumissions et et des PRs pour des parties des
|
|
mêmes fichiers. S'ils ont travaillé sur différentes lignes de texte ou de code dans un
|
|
fichier, GitHub sait comment combiner ces changements dans un seul fichier actualisé.
|
|
Vous pourriez avoir á vérifier que votre proposition fonctionne encore, car quelqu'un
|
|
pourrait avoir supprimer l'ancrage auquel vous sous référez etc. Si GHDt découvre qu'un
|
|
changement venant d'une personne a été inséré dans le master, et que vous avez préparé
|
|
des changements pour la même ligne, GitHub Desktop vous demande de l'aider á décider quoi
|
|
faire en affichant l'écran des Conflits ( Notez les points orange á côté de l'un des noms
|
|
de fichier ):<br>
|
|
<a href="images/GhDtConflictNote.png"><img src="images/GhDtConflictNote.png" width="410"
|
|
height="255" alt="GitHub Merge Conflict Note"></a>
|
|
<p>Cliquez sur ce nom et choisissez Show in Finder ou Open with External Editor ( GhDt
|
|
n'a pas d'outils d'édition).<br>
|
|
Pour trouver le point où le conflit est survenu, regarder les marqueurs
|
|
<code><<< HEAD ==== >>> master</code> qui sont insérés par GitHub:<br>
|
|
<a href="images/GhDtConfictmark.png"><img src="images/GhDtConfictmark.png" width="212"
|
|
height="184" alt="GitHub Merge Conflict marking in code"></a><br>
|
|
Choisissez laquelle des deux versions vous souhaitez conserver ( ou faire quelque
|
|
combinaison) et enlever les lignes <code>< === ></code>!<br>
|
|
<a href="images/GhDtConflictFixed.png"><img src="images/GhDtConflictFixed.png" width=
|
|
"212" height="184" alt="GitHub Merge Conflict solved in code"></a></p>
|
|
|
|
<p>Cette nouvelle proposition devra encore être soumise á JMRI, en lui donnant un titre
|
|
approprié, ex: Conflit résolu et cliquez Commit ( et Sync ). Cette soumission
|
|
supplémentaire sera ajoutée á votre PR et fera partie de la proposition que les
|
|
maintenanciers verront. Vous ne devriez pas garder de conflit de fusion pendant la nuit,
|
|
car les maintenanciers n'ont pas de possibilité de les corriger pour vous et ils devront
|
|
l'ignorer jusqu'á vous l'ayrésolu.</p>
|
|
</dd>
|
|
|
|
<dt id="ci-tests">Tests d'Intégration Continue</dt>
|
|
|
|
<dd>
|
|
Les référentiels principaux de JMRI exécutent un jeu de tests sur tous les Pull Request (
|
|
PR ). C'est appelé Intégration Continue ( CI ), et est une méthode éprouvée pour
|
|
maintenir le code á une qualité supèrieure.
|
|
<p>vous pouvez ajouter ceci á vos répertoires afin que chaque "push" soit automatiquement
|
|
testé</p>
|
|
|
|
<p>Les deux services de test CI sont appelés "Travis CI" et "GitHub":</p>
|
|
|
|
<ul>
|
|
<li>Travis fonctionne sur Linux. il fait d'abord un contrôle des mauvaises fins de
|
|
ligne (voir <a href="#lineends">plus loin ).</a> puis exécute le jeu complet de tests
|
|
JUnits, y compris les opérations de tests d'écran.</li>
|
|
</ul>
|
|
Pour ajouter ceux-ci á votre répertore personnel:
|
|
<ul>
|
|
<li>Pour Travis aller á <a href="https://travis-ci.org">la page web Travis</a> et
|
|
"Inscrivez vous". Utilisez votre compte GitHub et Email. Á la fin du processus, il vous
|
|
sera demandé vos répertoires GitHub á surveiller; vous pouvez sélectionner á la fois le
|
|
"JMRI" et fourches "du site".</li>
|
|
</ul>
|
|
A partir de lá, en "poussant" á votre propre référentiel va exécuter les tests. Vous
|
|
recevrez un email lorsque les tests sont terminés, ou vous pouvez vérifier sur le web.
|
|
</dd>
|
|
|
|
<dt id="lineends">Manipulation des Fins de Ligne</dt>
|
|
|
|
<dd>
|
|
Mac et Linux utilise un caractère LF á la fin de chaque ligne; Windows utilise la paire
|
|
CRLF. Les fichiers textes JMRI sont, par convention, chargés dans Git avec les fins de
|
|
ligne LF.
|
|
<p>Il est très important que les utilisateurs Windows ne convertissent pas
|
|
accidentellement un fichier avec fin de ligne CRLF. Quand cela se produit Git pense que
|
|
toutes les lignes ont été changées: Git ne peut plus fournir d'informations utiles et
|
|
parcellaires sur les changements faits plus tôt sur les fichiers.</p>
|
|
|
|
<p>Il y a un fichier ".gitattributes" qui en dit plus sur l'implantations des lignes de
|
|
commande Git qui gèrent cela correctement. Malheureusement , tous les IDEs n'obéissent
|
|
pas aux directives dans les fichiers. Par exemple, pour voir NetBeans sur windows gérer
|
|
proprement les fins de lignes, un plugin spécifique doit être installé. Voir la <a href=
|
|
"NetBeans.shtml">page JMRI NetBeans</a> pour les spécificités.</p>
|
|
|
|
<p>Si dans un fichier avec des fins de ligne changées est accidentellement soumis etet
|
|
transmis dans un pull-request ( PR ), Le mauvais fichier dans ce PR sera détecté pendant
|
|
le test Travis et le PI <strong>ne sera</strong> ni accepté ni fusionné. En outre, le PR
|
|
sera marqué avec une étiquette "CR LF". Puisque l'historique a déjá été perdu dans ce
|
|
fichier, l'étiquette CRLF rappelle au maintenanciers qu'l ne suffit pas de simplement
|
|
changer les fins de ligne par LF, soumettre et "push": 'historique a été <u>perdu</u> et
|
|
des mesures plus compliquées doivent être prises<br>
|
|
Les deux approches sont:</p>
|
|
|
|
<ol>
|
|
<li>Abandonner Le PR et les modifications sous-jacentes, effacer la branche, et refaire
|
|
comme il faut. Si vous travaillez proprement, avec vos changements dans une branche
|
|
séparée et la soumission de petits changements, c'est le plan d'action recommandé.</li>
|
|
|
|
<li>Alternativement, il est possible d'utiliser les outils Git pour enlever la
|
|
soumission impropre de la branche. C'est beaucoup plus compliqué. Demander á un des
|
|
développeurs ayant l'expertise de Git de le faire pour vous et n'oubliez de les
|
|
remercier.</li>
|
|
</ol>
|
|
|
|
<p>Les maintenanciers qui rencontre un PR actualisé avec une étiquette CRLF voudront
|
|
vérifier que tous les fichiers dans le PR <em>ne montrent pas</em> toutes les lignes
|
|
changées. Si elles le sont, même si elles ont la fin de ligne LF correcte, le PR ne
|
|
pourra pas être fusionné.</p>
|
|
|
|
<p>Beaucoup d'<a href="XmlEditors.shtml">Éditeurs XML</a> ont un Réglage des Préférences
|
|
pour les fins de ligne.<br>
|
|
Par exemple, dans Expresso cochez que les Line Ending sont paramétrées pour <strong>Unix
|
|
(LF)</strong> avant de démarrer l'édition de fichier JMRI:<br>
|
|
<a href="images/EspressoPrefsLF.png"><img src="images/EspressoPrefsLF.png" width="226"
|
|
height="219" alt="Espresso LF Preference setting"></a></p>
|
|
</dd>
|
|
|
|
<dt id="testPR">Test d'un Pull Request</dt>
|
|
|
|
<dd>
|
|
<p>Les Pull requests sont juste un cas particulier d'une branche. Si vous voulez les
|
|
tester avant de les fusionner dans un master, vous pouvez les apporter dans votre
|
|
répertoire local et travailler avec eux. <a href="images/GitHubPullPRLinks.png"><img src=
|
|
"images/GitHubPullPRLinks.png" align="right" width="392" height="104" alt=
|
|
"GitHub Web PR screen"></a></p>
|
|
|
|
<p>Dans quelques cas, le site web GitHub fournit des instructions disponibles sur la
|
|
droite du pull-request lui-même. Regardez près du bas du lien de discussion, dans le
|
|
dernier bloc d'information. La bonne chose á propos de ceux-ci est qu'elles comportent
|
|
automatiquement les bons noms de branche, etc, inclus.</p>
|
|
|
|
<p>S'il n'y a pas d'instruction d'affichée, il y a ici une séquence de choses á
|
|
faire:</p>
|
|
|
|
<ul>
|
|
<li>Chercher le référentiel source et le nom de branche. Pour le faire, regarder en
|
|
haut de la demande de branche pour une ligne disant:
|
|
<blockquote>
|
|
<u>user</u> wants to merge <u>3</u> commits into JMRI:master from
|
|
<u>user</u>:<u>branch</u>
|
|
</blockquote>
|
|
<a href="images/GitHubPRbranchInfo.png"><img src="images/GitHubPRbranchInfo.png"
|
|
width="446" height="114" alt="GitHub Web branch screen"></a>
|
|
</li>
|
|
|
|
<li>Ensuite, pousser cette branche sur votre propre machine avec la commande:
|
|
|
|
<pre><code>
|
|
git fetch https://github.com/<u>user</u>/JMRI.git <u>branch</u>:<u>local-branch</u>
|
|
</code></pre>où vous avez remplacer chaque valeur soulignée:
|
|
<ul>
|
|
<li>Changez "user" par le nom utilisateur GitHub correcte</li>
|
|
|
|
<li>Changez "branch" par le nom de branche dans le pull request ( c'est OK si c'est
|
|
par ex: master )</li>
|
|
|
|
<li>changez "local-branch" par ce que vous voulez appeler la branche sur votre
|
|
propre machine. <em>Celle-ci ne doit pas déjá existé</em>.Quelque chose comme
|
|
"ma-branche-utilisateur" Vous rappellera de qui est le dépôt dont vous l'avez tiré,
|
|
tout en marquant les changements ultérieurs comme les vôtres si vous les partagez
|
|
plus tard avec quelqu'un d'autre. ( Il est recommandé que vous démarriez vos noms
|
|
de branches avec votre propre nom, cela simplifie tout sorte s d'opérations )</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>La branche existe manitenant dans votre machine, Et vous pouvez juste vous déplacer
|
|
vers elle:
|
|
|
|
<pre><code>
|
|
git checkout <u>local-branch</u>
|
|
</code></pre>puis compler, tester, etc, comme vous le voulez. Vous pouvez même soumettre et
|
|
partager les changements si vous le désirez, parce que c'est maintenant votre propre branche de
|
|
développement: Elle a commencé á une autre personne, mais c'est maintenant la votre.
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt id="SFnetPatches">Manipuler un Patch SF.net</dt>
|
|
|
|
<dd>
|
|
Éventuellement, nous allons passer de l'utilisation du <a href=
|
|
"https://sourceforge.net/p/jmri/patches/">traqueur SF.net</a> pour les <a href=
|
|
"https://guides.github.com/features/issues/">questions GitHub</a> pour manipuler le code
|
|
auquel les gens souhaitent participer. En attendant, voici un moyen suggéré pour traiter
|
|
un patch SF.net.
|
|
<ol>
|
|
<li>Dans votre répertoire local, créer une branche pour maintenir le patch:
|
|
<blockquote>
|
|
<code>git checkout -b patch-NNNN</code>
|
|
</blockquote>
|
|
Ou NNNN est le numéro du patch.
|
|
</li>
|
|
|
|
<li>Fusionnez dans le code modifié si nécessaire.</li>
|
|
|
|
<li>Soumettez vos changements:
|
|
<blockquote>
|
|
<code>git commit -m"Patch-NNNN plus the patch subject line (author name)"</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Il est maintenant dans votre répertoire sur une branche qui lui est propre, où vous
|
|
pouvez où vous pouvez tester des choses comme d'habitude</li>
|
|
|
|
<li>Quand vous êtes satisfait, poussez le contenu soumis de votre répertoire local vers
|
|
votre répertoire GitHub ( En supposant que la configuration par défaut, où " pousser "
|
|
va á votre propre dépôt sur GitHub) avec
|
|
<blockquote>
|
|
<code>git push origin patch-NNNN</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Allez á votre répertoire sur GitHub et démarrez le processus "pull request".</li>
|
|
|
|
<li>Sur le second écran, commutez la branche à comparer dans votre répertoire depuis
|
|
"<strong>master</strong>" vers "<strong>patch-NNNN</strong>". Puis le reste du Pull
|
|
Request se passe comme avant..</li>
|
|
|
|
<li>Éventuellement, un maintenancier JMRI peut manipuler et fusionner le pull request,
|
|
qui mettra le patch des changements sur la branche master dans le référentiel.</li>
|
|
|
|
<li>Vous pouvez attendre pour fusionner sur le référentiel principal, et ensuite
|
|
réaliser un
|
|
<blockquote>
|
|
<code>git pull</code>
|
|
</blockquote>
|
|
pour actualiser votre répertoire local avec le patch sur votre master local via
|
|
<blockquote>
|
|
<code>git checkout master<br>
|
|
git merge patch-NNNN<br></code>
|
|
</blockquote>
|
|
</li>
|
|
</ol>
|
|
L'avantage de cette approche est qu'elle vous permet de garder votre propre travail
|
|
séparé de tous les correctifs que vous manipulez. Les patches sont sur des branches
|
|
différentes de votre travail, de sorte qu'ils ne se chevauchent pas.
|
|
</dd>
|
|
</dl>
|
|
|
|
<h2>Opérations Moins-Courantes</h2>
|
|
|
|
<dl class="faq">
|
|
<dt id="migrateSVN">Migration des modifications non validées á partir d'un fichier SVN</dt>
|
|
|
|
<dd>
|
|
<p>Comme nous avons migré de SVN á Git depuis 2015, vous pouvez avoir encore des éditions
|
|
basées sur un vieux code. Si vous avez des changements pour le code JMRI dans un fichier
|
|
SVN que vous souhaitez soumettre dans la version en développement actuel sur Git. Voici
|
|
ce que nous recommandons:</p>
|
|
|
|
<ol>
|
|
<li>"Actualisez"vers le Head de SVN. Vous pouvez faire cela n'importe où, parce que
|
|
vous devez le faire avant que vos changemenets puissent être soumis. Faites le
|
|
maintenant et résolvez les problèmes.
|
|
<blockquote>
|
|
<code>$ svn update</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Vérifiez l'état et sauvez la sortie. Double vérification qu'ils n'y aient pas de
|
|
conflits de montrés.
|
|
<blockquote>
|
|
<code>$ svn status</code><br>
|
|
<br>
|
|
save a copy to reference later ...<br>
|
|
<br>
|
|
<code>$ svn status > saved-status.txt</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Diff les sources et enregistrer la sortie
|
|
<blockquote>
|
|
<code>$ svn diff > patch.txt</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Clonez une copie du référentiel JMRI Git sur votre machine. ( Voir les <a href=
|
|
"getgitcode.shtml">pages précédentes</a> pour les instructions détaillées. )
|
|
<blockquote>
|
|
<code>$ git clone https://github.com/JMRI/JMRI.git</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Dans votre nouveau répertoire cloneé, vérifier les sources comme elles étaient
|
|
quand le code a été changé de SVN vers Git:
|
|
<blockquote>
|
|
<code>$ git checkout tags/svn-30001</code>
|
|
</blockquote>
|
|
Ceci définit votre copie de travail pour qu'elle soit exactement la même que le
|
|
dernier contenu de SVN, la même que la base pour le <code>svn diff</code> vous avez
|
|
pris plus tôt.<br>
|
|
</li>
|
|
|
|
<li>Appliquez les changements que vous avez fait dans SVN dans le nouvel arbre Git
|
|
<blockquote>
|
|
<code>$ patch -p0 < patch.txt</code>
|
|
</blockquote>
|
|
</li>
|
|
|
|
<li>Si vous avez créé et complété de nouveaux fichiers dans le répertoire de travail
|
|
SVN, par ex: des fichiers avec l'état "A" or "?":
|
|
<ul>
|
|
<li>Copiez ces fichiers á leur place correspondantes dans Git.</li>
|
|
|
|
<li>
|
|
<em>Ajoutez</em> les á la file d'attente de l'environnement de test Git: Pour que
|
|
<code>git ajoute ( chemin )</code> sur chacun d'entre eux pour dire quelque chose
|
|
á Git á leur sujet
|
|
<blockquote>
|
|
<code>$ git add <em>pathname/to/new/file</em></code>
|
|
</blockquote>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>Vérifiez l'état pour avoir une liste des changements.
|
|
<blockquote>
|
|
<code>$ git status</code>
|
|
</blockquote>
|
|
Vous devez voir la même liste de fichiers changés que l'"état SVN" vous avez exécuté
|
|
plus tôt.<br>
|
|
</li>
|
|
|
|
<li><code>git stash save</code>
|
|
</li>
|
|
|
|
<li><code>git checkout master</code>
|
|
</li>
|
|
|
|
<li><code>git stash pop</code><br>
|
|
<br>
|
|
Selon la progression dans Git, des conflits pourraient apparaìtre. Si oui, vous devez
|
|
les résoudre ici.</li>
|
|
</ol>
|
|
|
|
<p>Maintenant vous pouvez démarrer le développement, sans avoir perdu quoique ce
|
|
soit.</p>
|
|
</dd>
|
|
|
|
<dt id="CVSCookies">Les cookies CVS, RCS et SVN embarqués</dt>
|
|
|
|
<dd>
|
|
<p>Quand JMRI utilisait á l'origine CVS, nous utilisions des lignes comme: <code># La
|
|
ligne suivante est maintenue par CVS, SVP ne la changz pas<br>
|
|
# $Revision$</code> comme moyen de suivre les versions des fichiers. Quand nous avons
|
|
migré vers SVN, nous avons conservéces lignes dans certains fichiers, comme decodeur XML,
|
|
Fichier properties, etc que les utilisateurs étaient susceptibles de modifier et
|
|
soumettre de nouveau pour l'inclusion.</p>
|
|
|
|
<p>Mais avec Git il y a moins de besoin pour ces derniers. Donc, nous supprimons ces
|
|
lignes. Si lors de travaux sur un fichier vous en voyez, habituellement dans l'en tête,
|
|
vous pouvez les effacer.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<!--#include virtual="/help/fr/parts/Footer_fr.shtml" -->
|
|
</div>
|
|
<!-- closes #mainContent-->
|
|
</div>
|
|
<!-- closes #mBody-->
|
|
<script src="/js/help.js"></script>
|
|
<!-- FAQ-Tail -->
|
|
<script src="/web/js/faq.js"></script> <!-- /FAQ-Tail -->
|
|
</body>
|
|
</html>
|