flux de travail git + LaTeX
J'écris un très long document en LaTeX. J'ai mon ordinateur de travail et mon ordinateur portable sur lesquels je travaille tous les deux. Je dois garder tous les fichiers synchronisés entre les deux ordinateurs, ainsi qu'un historique de révision. J'ai choisi git comme DVCS et j'héberge mon référentiel sur mon serveur. J'utilise également Kile + Okular pour l'édition. Kile n'a pas de plugin intégré à Git. De plus, je ne collabore avec personne sur ce texte. Je pense également à mettre un autre référentiel privé sur codaset, si mon serveur n'est pas accessible pour une raison quelconque.
Quelle est la pratique de flux de travail recommandée dans ce cas? Comment peut-on installer des branches dans ce schéma de travail? Existe-t-il un moyen de comparer deux versions du même fichier? Qu'en est-il d'utiliser une cachette?
Modifications apportées à votre flux de travail LaTeX:
La première étape pour gérer efficacement un flux de travail git + latex consiste à apporter quelques modifications à vos habitudes LaTeX.
Pour commencer, écrivez chaque phrase sur une ligne séparée . Git a été écrit dans le code source du contrôle de version, où chaque ligne est distincte et a un objectif spécifique. Lorsque vous écrivez des documents dans LaTeX, vous pensez souvent en termes de paragraphes et vous les écrivez comme un document fluide. Cependant, dans git, les modifications apportées à un seul mot d'un paragraphe sont enregistrées en tant que modifications apportées à l'ensemble du paragraphe.
Une solution consiste à utiliser
git diff --color-words( voir ma réponse à une question similaire dans laquelle je montre un exemple). Cependant, je dois souligner que le fractionnement en lignes séparées est une bien meilleure option (je ne l’ai mentionnée qu’en passant dans cette réponse), car j’ai constaté que cela entraînait des conflits de fusion très minimes.Si vous avez besoin de regarder le code diff, utilisez le fichier natif diff. Pour voir la différence entre deux commits arbitraires (versions), vous pouvez le faire avec les
shas de chacun des commits. Voir le documentation pour plus de détails et aussi cette questionD'autre part, si vous avez besoin de regarder le diff de votre sortie formatée , utilisez
latexdiffqui est un excellent utilitaire (écrit en Perl) qui prend deux fichiers latex et produit une sortie soignée en PDF comme ceci ( image source ):![]()
Vous pouvez combiner
gitetlatexdiff(pluslatexpandsi nécessaire) en une seule commande à l'aide de git-latexdiff (par exemple,git latexdiff HEAD^pour afficher la différence entre votre arbre de travail et l'avant-dernier commit). .Si vous écrivez un long document en latex, je suggérerais diviser différents chapitres dans leurs propres fichiers et appelez-les dans le fichier principal à l'aide de la commande
\include{file}. De cette façon, il est plus facile pour vous de modifier une partie localisée de votre travail, mais également pour le contrôle de version, car vous savez quelles modifications ont été apportées à chaque chapitre, au lieu de devoir le déterminer à partir des journaux d'un grand fichier.
Utiliser git efficacement:
Utilisez des branches! . Il n'y a peut-être pas de meilleur conseil que je puisse donner. J'ai trouvé les branches très utiles pour garder une trace de "différentes idées" pour le texte ou pour "différents états" du travail. La branche
masterdevrait être votre corps de travail principal, dans son état le plus récent "prêt à publier", c’est-à-dire si toutes les branches, s’il y en a une que vous souhaitez mettre votre nom, ce devrait être la branche principale. .Les branches sont également extrêmement utiles si vous êtes étudiant diplômé. Comme tout étudiant diplômé en attestera, le conseiller est tenu d'apporter de nombreuses corrections, avec lesquelles vous n'êtes pas d'accord. Pourtant, on pourrait s’attendre à ce que au moins les modifie pour le moment, même s’ils sont annulés plus tard après des discussions. Ainsi, dans de tels cas, vous pouvez créer une nouvelle branche
advisoret apporter des modifications à leur goût, tout en maintenant votre propre branche de développement. Vous pouvez ensuite fusionner les deux et choisir ce dont vous avez besoin.Je suggérerais également de scinder chaque section en une branche différente et de ne focaliser que sur la section correspondant à la branche sur laquelle vous vous trouvez. Créez une branche lorsque vous créez une nouvelle section ou des sections factices lorsque vous effectuez votre commit initial (votre choix, vraiment). Résistez à l'envie de modifier une section différente (par exemple, 3) lorsque vous n'êtes pas sur sa branche. Si vous avez besoin d’éditer, validez celui-ci puis extrayez l’autre avant de créer une branche. Je trouve cela très utile car il conserve l’historique de la section dans sa propre branche et vous indique également en un coup d’œil (à partir de l’arbre) quel âge a une section. Peut-être avez-vous ajouté à la section 3 des éléments nécessitant un ajustement de la section 5 ... Bien sûr, ceux-ci seront probablement observés au cours d'une lecture attentive, mais je trouve utile de voir ceci d'un coup d'œil pour pouvoir changer de vitesse si je m'ennuie d'une section.
Voici un exemple de mes branches et de fusions d'un article récent (J'utilise SourceTree sur OS X et git à partir de la ligne de commande sous Linux). Vous remarquerez probablement que je ne suis pas l'auteur le plus fréquent du monde ni que je laisse des commentaires utiles tout le temps, mais ce n'est pas une raison pour que vous ne suiviez pas ces bonnes habitudes. Le message principal à retenir est que travailler dans les succursales est utile. Mes pensées, mes idées et mon développement se déroulent de manière non linéaire, mais je peux les suivre via des branches et les fusionner lorsque je suis satisfait (j'avais également d'autres branches qui ne mènent nulle part et qui ont ensuite été supprimées). Je peux aussi "taguer" les commises s’ils veulent dire quelque chose (par exemple, soumissions initiales à des revues/soumissions révisées/etc.). Ici, je l'ai étiquetée "version 1", c'est là que se trouve le brouillon. L'arbre représente une semaine de travail.
![enter image description here]()
Une autre chose utile à faire est d’apporter des modifications à l’ensemble du document (telles que le changement de
\alphaà\betapartout) valide par lui-même. De cette façon, vous pouvez annuler les modifications sans avoir à revenir sur autre chose (il y a différentes façons de le faire en utilisant git, mais bon, si vous pouvez l'éviter, alors pourquoi pas?). Il en va de même pour les ajouts au préambule.Utilisez un dépôt distant et poussez vos modifications en amont régulièrement. Avec des fournisseurs de services gratuits tels que github et bitbucket (ce dernier vous permet même de créer des pensions privées avec un compte gratuit), il n'y a aucune raison de ne pas les utiliser si vous travaillez avec git/Mercurial. À tout le moins, considérez-le comme une sauvegarde secondaire (j'espère que vous en avez une principale!) Pour vos fichiers latex et un service qui vous permet de continuer à éditer à partir de l'endroit où vous l'avez laissé sur un autre ordinateur.
J'ai un flux de travail similaire. Même si on travaille sur une branche à la fois, il est avantageux d’avoir des branches distinctes pour différents états de travail. Par exemple, imaginez envoyer un bon brouillon de votre document à votre conseiller. Alors, vous avez une idée folle! Vous voulez commencer à modifier certains concepts de base, à retravailler certaines sections principales, etc. etc. Vous devez donc vous démarquer et commencer à travailler. Votre branche maîtresse est toujours dans un état «libérable» (ou aussi proche que vous êtes en ce moment). Ainsi, alors que votre autre branche est folle et a des changements radicaux, si un autre éditeur veut voir ce que vous avez, ou si vous êtes un étudiant qui soumet une conférence, la branche principale est toujours libérable, prête à fonctionner (ou prête à montrer votre conseiller). Si votre directeur de thèse souhaite voir le brouillon le matin à la première heure, oui, vous pouvez masquer/enregistrer/valider/valider vos modifications actuelles, utiliser des balises ou effectuer une recherche dans le journal, mais pourquoi ne pas conserver des branches distinctes?!
Disons que votre branche principale a l'état "libérable" de votre travail. Vous souhaitez maintenant le soumettre à plusieurs revues à comité de lecture, chacune ayant des exigences de mise en forme différentes pour le même contenu et vous vous attendez à ce qu'elles reviennent avec plusieurs petites critiques différentes sur la façon dont vous pouvez éditer le document pour l'adapter à leurs lecteurs, etc. Vous pouvez facilement créer une branche pour chaque journal, apporter des modifications spécifiques au journal, soumettre et lorsque vous recevez les commentaires, apportez les modifications sur chaque branche distincte.
J'ai également utilisé Dropbox et git pour créer le système que vous décrivez ci-dessus. Vous pouvez créer un référentiel sans système d'exploitation dans votre dossier de dépôt. Vous pouvez ensuite pousser/tirer de l’un ou l’autre des ordinateurs vers votre liste déroulante pour rester à jour à tous les points Ce système ne fonctionne généralement que lorsque le nombre de collaborateurs est faible, car il existe un risque de corruption si les utilisateurs essaient simultanément de transmettre au référentiel dropbox.
Vous pouvez également, techniquement, conserver UN SEUL référentiel dans le dossier Dropbox et effectuer tout votre travail à partir de là. Je le déconseillerais cependant, car certaines personnes ont mentionné que Dropbox rencontrait des problèmes pour synchroniser des fichiers en constante évolution (fichiers internes de gits).
J'ai essayé d'implémenter ceci en tant que fonction bash, je l'ai inclus dans mon ~/.bashrc pour le rendre toujours disponible.
function git-latexdiff {
if [[ $# != 2 ]];
then
printf "\tusage: git-latexdiff <file> <back-revision> \n";
Elif [[ $2 -lt 0 ]];
then
printf "\t<Back-revision> must be positive\n";
else
dire=$(dirname $PWD/$1);
based=$(git rev-parse --show-toplevel);
git show HEAD~$2:$(echo $dire| sed 's!'$(echo $based)'/!!')/$1 > $1_diff.tmp;
latexdiff $1 $1_diff.tmp > $1_diff.tex;
pdflatex $1_diff.tex;
okular $1_diff.pdf;
rm $1_diff*;
fi;
}
Notez que cette fonction nécessite l’installation de latexdiff (et se trouve sur le chemin) . Il est également important qu’elle trouve pdflatex et okular.
Le premier est mon moyen préféré de traiter LaTeX, de sorte que vous puissiez le changer également pour latex . Le second est mon lecteur PDF, je suppose que vous voudrez utiliser evince sous gnome, ou une autre solution.
Il s’agit d’une version rapide, conçue avec un seul document à l’esprit, car avec git, vous perdrez beaucoup de temps et d’effort à suivre un document LaTeX contenant plusieurs fichiers. Vous pouvez aussi laisser git faire cette tâche, mais si vous le souhaitez, vous pouvez aussi continuer à utiliser \include
Une autre option consiste à utiliser Authorea , qui est une sorte de Github pour les articles scientifiques. Chaque article dans Authorea est un dépôt Git. Et le LaTeX que vous composez est rendu au format HTML5 (ainsi que le format PDF, lorsque vous compilez).
utilisez ceci pour version diff si vous êtes sur Windows, pas de versement, mais un simple script bat Il fonctionne parfaitement sous windows10, miktex2.9: