Ceci est une Liste des Questions Fréquentes concernants GIT particulièrement comment utiliser Git avec JMRI.
Il y a une page d'aide JMRI séparées sur comment comment obtenir le code avec Git.
Voir aussi le Technical index pour de plus amples informations sue la maintenance du code JMRI.
Faites un don à JMRI.orgsudo yum
install git ou sudo apt-get install git.
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.
Les flêches sont les deux opérations ( "push", "pull" ) et aussi les définitions de où 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.
Via l'outil ligne de commande git vous pouvez faire ceci par la commande:
$ git remote set-url --push origin
https://github.com/username/JMRI.git
où username est votre nom utilisateur github. Vous pouvez vérifier l'état
actuel des répertoires push et pull avec:
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$ git remote -v
origin https://github.com/JMRI/JMRI.git (fetch)
origin https://github.com/username/JMRI.git (push)
Une fois que vous avez une copie de vos changements sur GitHub, il est facile de générer un pull request (Lien vers GitHub)
,
puis cliquez sur "Create a Pull Resquest".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.
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: Branchement.
Pour comprendre Git, il est bon de connaitre les places variés dans votre répertoire git local:
.git/ ,Quand vous clonez 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 master branch du répertoire que vous avez cloné- et le staging area est vide quand vous faites des changements dans les fichiers de l'arbre de travail, vous avez besoin de les ajouter 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.
Une fois que vous avez rempli la zone de préparation avec tout ce que vous avez
changé, une opération commit ( soumission ) engagera officiellement vos
modifications dans votre structure répertoire .git/.
Quand vous pull ou push, vous dites á Git de synchroniser votre
contenu git/ avec avec celui du répertoire distant dont vous avez
initialement cloné le contenu.
La documentation suivante devrait vous aider á démarrer en utilisant soit la ligne de commande git ou GitHub Desktop:
$ git clone https://github.com/JMRI/JMRI.git
ou
$ git fetch
$ git diff ...origin
$ git merge origin/master
Auto-merging ... files ...
CONFLICT (content): Merge conflict in some_file
Échec Fusion Automatique; corriger les conflits et soumettez le résultat.
$ vi some_file # Le fichier a des conflits marqués, éditer le pour correction...
$ git add some_file
$ git commit -m "Merged master fixed conflict"
$ git merge origin/master
ou
$ git pull https://github.com/JMRI/JMRI.git
$ git add newfile
$ git rm newfile
$ git add .
$ git status
$ git fetch
$ git merge
$ git commit -m "commit message"
or
$ git commit -a -m "commit message"
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 plan de voie. Cliquez pour
lire le titre. Pour voir les fichiers modifiés á un autre moment dans le temps,
cliquez sur un ancien point de soumission:
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
Sync 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:
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 )
|
Le nom du bouton PR changera en #123 signalant que vous ne pouvez pas faire d'autre PR dans cette branche depuis ici ( mais vous pouvez encore soumettre des modifications ): |
|
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.
Quand votre PR est pulled & fusionné & fermé, le nom PR #123 disparaìtra
et vous pourrez effacer la branche en toute sécurité.
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: "abc-decoder-xml-change", "abc-2015-09-14",
"abc-next-cool-thing", et "abc-patch-NNNN" sont tous correcte.
De cette manière, nous savons que c'est vous.
Le "-b" dit de créer la branche. Pour basculer sur une branche existante, il suffit d'oublier cette option:git checkout -b nomdebranche
Pour voir toutes les branches actuelles, fairegit checkout nomdebranche
git branch
( 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:git checkout branchname
git merge -m"merging in current contents of master" master
git commit -a
Lorsque vous avez terminé, fusionner vos modifications dans la ligne commune
de développement avec
git checkout master
git merge -m"merging to master" branchname
git commit -a
git checkout master
git branch -d branchname
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:
git checkout arnie-great-tool
(work on changes)
git commit -m"Added support for the Frobnab 2000"
git push
git pull https://github.com/arnie/JMRI.git arnie-great-tool
git checkout arnie-great-tool
où la première partie de "pull" est l'URL du répertoire d'Arnie.
git commit -m"Fixed a bug in sternerstat handling"
git push
Puis Arnie peut fusionner ces changements dans sa propre copie avec:
git checkout arnie-great-tool
git pull https://github.com/bill/JMRI.git arnie-great-tool
Cliquez sur ce nom et choisissez Show in Finder ou Open with External Editor ( GhDt
n'a pas d'outils d'édition).
Pour trouver le point où le conflit est survenu, regarder les marqueurs
<<< HEAD ==== >>> master qui sont insérés par GitHub:
Choisissez laquelle des deux versions vous souhaitez conserver ( ou faire quelque
combinaison) et enlever les lignes < === >!
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.
vous pouvez ajouter ceci á vos répertoires afin que chaque "push" soit automatiquement testé
Les deux services de test CI sont appelés "Travis CI" et "GitHub":
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.
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 page JMRI NetBeans pour les spécificités.
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 ne sera 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é perdu et
des mesures plus compliquées doivent être prises
Les deux approches sont:
Les maintenanciers qui rencontre un PR actualisé avec une étiquette CRLF voudront vérifier que tous les fichiers dans le PR ne montrent pas 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é.
Beaucoup d'Éditeurs XML ont un Réglage des Préférences
pour les fins de ligne.
Par exemple, dans Expresso cochez que les Line Ending sont paramétrées pour Unix
(LF) avant de démarrer l'édition de fichier JMRI:
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. 
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.
S'il n'y a pas d'instruction d'affichée, il y a ici une séquence de choses á faire:
user wants to merge 3 commits into JMRI:master from user:branch
git fetch https://github.com/user/JMRI.git branch:local-branch
git checkout local-branch
git checkout -b patch-NNNN
Ou NNNN est le numéro du patch.
git commit -m"Patch-NNNN plus the patch subject line (author name)"
git push origin patch-NNNN
git pull
pour actualiser votre répertoire local avec le patch sur votre master local via
git checkout master
git merge patch-NNNN
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:
$ svn update
$ svn status
save a copy to reference later ...
$ svn status > saved-status.txt
$ svn diff > patch.txt
$ git clone https://github.com/JMRI/JMRI.git
$ git checkout tags/svn-30001
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 svn diff vous avez
pris plus tôt.
$ patch -p0 < patch.txt
git ajoute ( chemin ) sur chacun d'entre eux pour dire quelque chose
á Git á leur sujet
$ git add pathname/to/new/file
$ git status
Vous devez voir la même liste de fichiers changés que l'"état SVN" vous avez exécuté
plus tôt.git stash save
git checkout master
git stash popMaintenant vous pouvez démarrer le développement, sans avoir perdu quoique ce soit.
Quand JMRI utilisait á l'origine CVS, nous utilisions des lignes comme: # La
ligne suivante est maintenue par CVS, SVP ne la changz pas 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.
# $Revision$
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.