Использование Git для написания тезисов

Ответ 1

Существуют некоторые технические соображения и рекомендации. Я собираюсь сделать второй, специально для написания тезисов и/или документов. Для технических, вы можете проверить любой учебник git.

• Определите структуру каталогов для своей диссертации. Вы можете изменить его позже, и используйте git для отслеживания изменений. Имея хорошую структуру облегчит вашу жизнь.

• Работа с несколькими файлами (используйте include и/или ввод в LaTeX). Вы можете разделить их по главам или разделам. Это облегчит отслеживание изменений, которые связаны с определенными частями вашего тезиса (например, git log content/introduction.tex).

• Отслеживайте только файлы, которые вы собираетесь касаться, а не те, которые сгенерированы автоматически. Создание файла .gitignore поможет вам много (LaTeX создает много рабочих файлов).

• Как и в программах, делайте микро-коммиты, то есть: один фиксатор за идею/функцию/исправление/активность.

• Каждый раз, когда вы совершаете, записываете значимые сообщения (высокий уровень), которые объясняют, что вы пытались достичь в каждом изменении. Через неделю вы можете не помнить, что вы пытались выполнить.

• Отслеживание всех действий/идей/исправлений [см. (4) и (5)] может быть очень полезно, чтобы знать, сколько вы сделали (используя git log). Вы можете написать свой предварительный отчет для своего руководителя (ов) на основе git log. Более того, вы можете совместно использовать репозиторий своим супервизором (используя веб-интерфейс), и они могут проверять все, что вы делали в своей диссертации. Для следующей встречи они будут знать, чего ожидать (это будет зависеть от того, насколько вы любите своих наблюдателей после RSS).

• Использование git будет полезно для поддержания хорошего настроения (иногда вы чувствуете, что не слишком много сделали, но отслеживание каждого изменения поможет вам сохранить вещи в перспективе).

• Для каждого отправляемого отчета о проделанной работе создайте тег. Для следующего отчета вы можете проверить обе версии и применить latexdiff. Это будет полезно для отслеживания изменений между версиями, которые вы отправляете для пересмотра. Это также поможет вам проверить, обратили ли вы отзывы, полученные вами за предыдущий отчет.

Наконец, но не в последнюю очередь, я рекомендую вам прочитать " успешная git ветвящаяся модель". Это очень короткая статья о рабочем процессе git. Вы можете применять те же самые понятия, когда пишете свою диссертацию. Например, если вы пишете эксперимент, вы можете создать для него ветку и объединить ее, когда она "готова". Если вам придется пересмотреть его позже, было бы легче увидеть, какие были изменения и почему.

Ответ 2

Когда я писал кандидатскую диссертацию, я использовал git для управления документом и всеми его цифрами, и я очень рад, что сделал это, не в последнюю очередь потому, что он упростил запись script что показывает ваши успехи, поскольку вы идете вперед;) Основные преимущества, которые я нашел:

• Так как git - это система управления распределенной версией, она легко работает на нескольких машинах. Если вам нужна последняя версия вашего ноутбука на вашем настольном компьютере, вы можете просто pull прямо с ноутбука и там работать. Когда вы уходите, вы идете на свой ноутбук и тянете с настольной машины.
• Если вы работаете на нескольких компьютерах, у вас есть последняя резервная копия вашей работы (включая ее полную историю), и если вы хотите создать дополнительные резервные копии, вы можете просто нажать на новый открытый репозиторий в другом месте (как Ответ VonC указывает).
• Вы можете внести большие изменения в свой документ, зная, что предыдущая версия надежно сохранена, и что если вы хотите получить старую версию, это легко сделать.
• Возможность фиксации вашего репозитория, когда вы в автономном режиме, очень полезна, особенно потому, что отсутствие доступа в Интернет упрощает запись;) Я также сохранил PDF файлы всех документов, которые я цитировал в том же хранилище, чтобы сделать это проще работать в автономном режиме, хотя это значительно завысило репозиторий, поэтому некоторые могут советоваться с этим.

Главный совет, который я бы дал:

• Обязательно выполняйте операции и всегда следите за тем, чтобы вы сохраняли вывод git status пустым, добавляя файлы, которые вам нужны, или перечисляете их в .gitignore. Вы не хотите рисковать тем, что важные файлы не отслеживаются.
• Никогда не используйте команды перезаписи истории (например, git rebase), чтобы быть безопасными и никогда не использовать git опасные команды, такие как git reset --hard и git checkout -f. Никто никогда не увидит ваш полный репозиторий, поэтому вам все равно, как выглядит история - гораздо важнее то, что вы не делаете ничего, что могло бы потерять (или сделать его более трудным для извлечения) вашей работой.
• Когда вы смотрите на различия между версиями, используйте параметр --color-words для git diff. В противном случае ваши различия будут линейными, и если вы переформатируете абзац в LaTeX, будет трудно понять, что представляют собой реальные изменения - git diff --color-words игнорирует разрывы строк и просто показывает старые слова в красном и новые слова в зеленом цвете.

¹... с LyX, а не напрямую в LaTeX, но проблемы по существу одинаковы.

Ответ 3

В основном это просто комментарий, но он оказался слишком длинным, поэтому я публикую его как ответ.

Я использовал darcs для моей магистерской диссертации, и в прошлом использовал RCS, CVS, SVN и Git для множества проектов документации/написания. Все эти инструменты предоставляют базовую функцию, которую я хочу - возможность просматривать мои изменения, возвращаться в историю, отмечать "точки отмены", когда я начинаю писать что-то новое.

Существуют старые и проверенные рекомендации по написанию документации с контролем версий. Использование только текстового исходного формата важно для получения вменяемых различий. Кроме того, полезный совет, который я взял (IIRC от Kernighan, пишущий о сохранении исходного кода Troff в управлении версиями), заключается в том, чтобы убедиться, что все строки достаточно короткие. Я стараюсь вводить каждые несколько строк, стараясь сохранить один конкретный пункт или идиому на одной строке, так что разница будет минимальной, если я решу пересмотреть эту конкретную деталь позже.

Ответ 4

Git будет работать. Латекс - это действительно исходный код, поэтому он должен быть отлично.

Тем не менее, Git, хотя и удивительный, имеет слегка крутую кривую обучения, потому что он позволяет многое для сотрудничества с несколькими людьми, обработки расходящихся историй и т.д. Его действительно большое преимущество заключается в слиянии конфликтов (что происходит, если я изменяю файл, а кто-то другой меняет файл, и мы оба пытаемся загрузить/передать его на какой-то сервер?).

Если вы просто хотите опубликовать свой тезис, вы вряд ли даже столкнетесь с конфликтующим случаем слияния (поскольку вы его только редактируете), не говоря уже о случае с несколькими историями.
Я бы использовал что-то более простое, как SVN, что хуже для того, чтобы сделать две вещи, которые я описал, соответствует вашим потребностям и легче учиться.

Кроме того, git хранит все в файле .git в папке, в которой вы находитесь. Если вы удалите эту папку, ваши данные исчезнут.

Ответ 5

В DVCS workflow означает:

• Объединить рабочий процесс (который вам не нужен в вашем случае)
• рабочий процесс публикации (нажмите на удаленное репо)

С вашим местным реестром .git вы сможете сравнить с предыдущими версиями (что может пригодиться)
Но преимущество DVCS заключается в следующем:

• вы сохраняете свою работу путем нажатия на удаленное репо (или для целей резервного копирования, комплект)
• Вы синхронизируете свою работу между двумя разными компьютерами (например, в Как перенаправить локальный репозиторий git на другой компьютер? "или в" git сервер между ноутбуком и ПК (MS Windows 7) ").
  Затем, как только синхронизация будет выполнена (через git push), вы можете отключить свою вторую среду в автономном режиме и по-прежнему пользоваться полной историей своего репо.
  Именно здесь имеет значение DVCS.