L'utilisation de Git pour l'écriture de la thèse

Question

Je suis de la planification à l'utilisation de Git pour la rédaction de ma thèse avec Latex. Que Git est spécialement conçu pour le développement de logiciels, serait-il envisageable pour mes besoins? Si c'est un bon choix pour moi, alors quoi de spécial et d'unique fonctionnalités sont disponibles dans Git, qui sont idéales pour la rédaction d'une thèse. Aussi je voudrais savoir quelles sont les précautions que je dois prendre avant d'entrer dans le Git de flux de travail. Je suis un débutant complet pour Git, donc ce qui doit être mon point de départ avant d'entrer en elle.

Answer 1

Il y a quelques considérations techniques et les meilleures pratiques. Je vais, pour la seconde, spécifiquement pour la rédaction de votre thèse et/ou des documents. Pour la technique, vous pouvez vérifier tout git tutoriel.

1. Définir la structure de répertoire pour votre thèse. Vous pouvez le changer plus tard, et l'utilisation de git pour le suivi de l'évolution. Avoir une bonne structure serait rendre votre vie plus facile.

2. Travailler avec plusieurs fichiers à inclure et/ou d'entrée en LaTeX). Vous pouvez les diviser en chapitres ou sections. Cela rendra plus facile pour suivre les changements qui impliquent des parties spécifiques de votre thèse (par exemple, git log content/introduction.tex).

3. Suivre uniquement les fichiers que vous allez toucher, pas ceux d'auto-généré. La création d'un bon .gitignore fichier vous aidera beaucoup (LaTeX générer beaucoup de fichiers de travail).

4. Comme dans les programmes, de faire des micro-s'engage, c'est: un commit par idée/fonction/fix/activité.

5. Chaque fois que vous s'engager, écrire des messages significatifs (de haut niveau) qui explique ce que vous essayez d'atteindre dans chaque modification. Après une semaine, vous risquez de ne pas rappeler ce que vous avez essayé d'accomplir.

6. Garder la trace de chaque activité/idée/fix [voir (4) et (5)] pourrait être très utile de savoir combien vous avez fait (à l'aide d' git log). Vous pouvez écrire votre avance de votre superviseur(s) basé sur l' git log. Même plus, vous pouvez partager le référentiel avec votre directeur de recherche (à l'aide d'une interface web), et ils peuvent vérifier ce que vous avez fait dans votre thèse. Pour la prochaine réunion, ils savent à quoi s'attendre (cela dépendra de la façon dont sont friands à vos superviseurs en suivant un flux RSS).

7. À l'aide de git sera utile pour vous garder en bonne humeur (parfois vous sentez que vous n'avez pas fait trop, mais d'avoir une trace de chaque changement vous aidera à garder les choses en perspective).

8. Pour chaque rapport d'avancement de vous envoyer, créer une balise. Pour le prochain rapport, vous pouvez télécharger la version et appliquer latexdiff. Il sera utile pour le suivi des modifications entre les versions vous soumettre pour révision. Ce sera également vous aider à vérifier si vous avez tenu compte de la rétroaction que vous avez reçu pour le rapport précédent.

Au dernier mais non le moins, je vous recommande de lire "Un succès Git ramification modèle". C'est un très court article sur un workflow git. Vous pouvez appliquer les mêmes concepts que lorsque vous rédigez votre thèse. Par exemple, si vous écrivez une expérience, vous pouvez créer une branche pour elle, et de fusionner une fois qu'il est "prêt." Si vous avez la revoir plus tard, il serait plus facile de voir quels ont été les changements impliqués et pourquoi.

Answer 2

Quand j'ai écrit ma thèse de Doctorat,1 j'ai utilisé git pour gérer le document et l'intégralité de ses chiffres, et je suis très heureux que je l'ai fait, pas moins, car il est facile d'écrire un script qui graphes votre voie comme vous allez le long ;) Le chef des avantages que j'ai trouvé:

• Depuis git est un système distribué, système de contrôle de version, il est facile de travailler sur plusieurs machines. Si vous avez besoin de la dernière version à partir de votre ordinateur portable sur votre ordinateur de bureau, vous pouvez juste pull directement à partir de l'ordinateur portable et d'y travailler. Lorsque vous quittez, vous allez à votre ordinateur portable et de tirer à partir de l'ordinateur de bureau.
• Si vous travaillez sur plusieurs ordinateurs, vous disposez d'une sauvegarde récente de votre travail (y compris son histoire complète), et si vous voulez créer des sauvegardes, vous pouvez juste pousser à un nouveau dépôt nu ailleurs (comme VonC la réponse de points).
• Vous pouvez faire de grands changements à votre document en sachant que la version précédente est stocké de manière sécurisée, et que si vous voulez récupérer l'ancienne version, c'est facile à faire.
• Être en mesure de s'engager à votre référentiel lorsque vous êtes en mode hors connexion est très utile, surtout depuis pas avoir accès à internet, il est beaucoup plus facile à écrire ;) j'ai aussi gardé les fichiers Pdf de tous les documents que j'ai cités dans le même référentiel pour le rendre plus facile à travailler en mode hors connexion, bien que ce considérablement gonflé le dépôt, de sorte que certains pourraient avis contre cette.

Le chef de conseils que je donnerais:

• Commettre fréquemment, et assurez-vous toujours que vous gardez la sortie de l' git status vide, soit par l'ajout de fichiers dont vous avez besoin, liste dans .gitignore. Vous ne voulez pas risquer d'avoir des fichiers importants sans traces.
• N'utilisez jamais l'histoire de la réécriture de commandes (par exemple, git rebase), juste pour être sûr et ne jamais utiliser git est dangereux commandes comme git reset --hard et git checkout -f. Vous ne serez jamais voir votre référentiel complet, de sorte que vous ne se soucient pas ce que l'histoire ressemble - c'est beaucoup plus important que vous ne faites rien qui pourrait perdre (ou le rendre plus difficile à extraire) de votre travail.
• Lorsque vous êtes en train de regarder les différences entre les versions, utilisez l' --color-words option d' git diff. Sinon, votre diffs sera basé sur la ligne, et si vous reformatez un paragraphe en LaTeX, ça va être dur de voir ce que les vrais changements sont - git diff --color-words ignore les sauts de lignes, et montre juste les vieux mots en rouge et les nouveaux mots dans le vert.

1 ... avec LyX plutôt que directement en LaTeX, mais les problèmes sont essentiellement les mêmes.

Answer 3

C'est principalement conçu comme un commentaire, mais il s'est avéré un peu trop long, donc je suis annonce comme une réponse.

J'ai utilisé darcs pour ma thèse de Maîtrise, et ont été à l'aide de RCS, CVS et SVN pour beaucoup de documentation / projets d'écriture dans le passé. L'ensemble de ces outils fournissent la fonctionnalité de base que je veux -- possibilité de revoir mes modifications, remonter dans l'histoire, vérifiez dans "points d'annulation" lorsque je commence à écrire quelque chose de nouveau.

Il y a de vieux et essayé des recommandations pour la rédaction de la documentation avec le contrôle de version. À l'aide d'un format texte est important pour l'obtention sane diff. En outre, une astuce utile, j'ai ramassé (IIRC de Kernighan, écrit à propos de l'observance Troff source dans le contrôle de version) est de s'assurer que toutes les lignes sont raisonnablement court. J'ai tendance à frapper entrer tous les quelques lignes, avec un oeil vers le maintien d'une telle clause, ou idiome sur une seule ligne, de sorte que la diff sera minime si je décide de revoir ce détail plus tard.

Answer 4

Git va travailler. Latex est effectivement le code source, il doit donc être parfaitement bien.

Cela dit,Git, tout génial, a que légèrement courbe d'apprentissage abrupte, car il permet beaucoup de choses pour collaborer avec de nombreuses personnes, la manipulation divergentes des histoires,etc. Son grand avantage est dans la fusion des conflits ( ce qui se passe si je modifie un fichier et quelqu'un d'autre modifie un fichier, et nous avons essayez de télécharger/s'engager pour un serveur?).

Si vous voulez juste la version de votre thèse, vous êtes peu probable de même frappé le conflit de fusion de cas (puisque vous êtes le seul à l'édition) et, a fortiori, les multiples histoires de cas.
Je voudrais utiliser quelque chose de plus simple comme SVN, qui, tout en pire pour faire les deux choses que j'ai décrit, s'adapte à vos besoins et est plus facile à apprendre.

Aussi, git stocke tout dans une .git fichier dans le dossier où vous vous trouvez. Si vous supprimez ce dossier , vos données ont disparu.

Answer 5

Dans un DVCS, un "flux de travail" signifie:

• fusion de flux de travail (que vous ne devriez pas besoin de beaucoup plus dans votre cas)
• workflow de publication (push à une distance repo)

Avec votre local .repo git, vous serez en mesure de comparer avec les versions précédentes (qui peut venir dans maniable)
Mais l'avantage d'un DVCS, c'est quand:

• vous enregistrez votre travail par le biais d'un poussoir à distance à un repo (ou, pour les fins de sauvegarde, d'un faisceau)
• vous synchronisez votre travail entre les deux PC différents (comme dans "Comment pousser un dépôt git local à un autre ordinateur?" ou dans "serveur git entre le portable et le PC (Windows 7)").
  Ensuite, une fois que la synchronisation est effectuée (par le biais d'un git push), vous pouvez prendre votre deuxième environnement complètement hors-ligne, et continuent à bénéficier de l'historique complet de votre repo.
  C'est là un DVCS questions dans votre cas.