Как управлять версиями для сольного автора, создающего непрограммные документы?

Question

Я писатель, а не программист. Я только сейчас впервые узнаю о контроле версий и о том, как он работает, и мне интересно, как контроль версий может упростить мой рабочий процесс.

В течение многих лет я использовал свою собственную версию контроля версий. Мои папки завалены такими файлами, как резюме-2012-06-01.doc, резюме-2012-06-15.doc, letter.txt, letter-old.txt, letter-v2.txt, story-notes.txt, story -notes-with-character-sketchches.txt story_draft1.txt, story_draft2.txt, story_draft2-shorter.txt и т. д.

Поскольку я работаю один, я никогда не буду разветвляться или объединяться - только фиксировать на ходу и иногда ссылаться на более старую версию файла.

Каковы лучшие практики использования контроля версий для управления рабочим процессом написания соло автора?

Я использую OSX и планирую использовать Git или Mercurial (все еще решаю, какой).

1. Должен ли я управлять версией всей своей папки «Документы» как единого хранилища? (Он содержит подпапки, такие как «Документы / истории / муки / персонажи /», «Документы / истории / муки / черновики», «Документы / истории / муки / мозговые штурмы», «Документы / резюме», «Документы / письма /» и т.д.). Или я должен создать отдельные репозитории для каждого проекта? Или даже отдельные репозитории для каждой подпапки в рамках проекта письма (/ интервью /, / веб-исследование /, / история-проекты / и т.д.)?
2. Есть ли преимущества в наличии нескольких небольших репозиториев, а не одного большого?
3. Должен ли я поддерживать какую-то версию контроля версий самостоятельно, вручную? Например, draft1.txt, draft2.txt, draft2-shorter.txt и т.д.? Или я должен позволить системе контроля версий сделать все это для меня?
4. В прошлом я пытался никогда ничего не удалять, а вместо этого спрятал старые файлы в папки, которые назывались backups /, archives / или old-version. Теперь, когда я использую контроль версий, могу ли я свободно удалять файлы, которые мне больше не нужны?

Answer 1

Должен ли я управлять версией всей своей папки «Документы» как единого хранилища?

Я настоятельно рекомендую подход репозитория к проекту (при условии, что проекты независимы друг от друга).

Подумайте об этом так: если вы собираетесь оглянуться назад на версию 3 месяца назад какого-то проекта - хотите ли вы перенести все другие проекты на ту же дату? Если вы хотите просмотреть все изменения, которые вы сделали со времени последнего коммита - сделаете ли вы это для каждого проекта или для всего каталога Documents [1]?

Вы не должны разделять больше, чем уровень проекта: сохраняйте свои текущие подкаталоги в качестве каталогов в каждом репо. Таким образом, одна фиксация может содержать, например, изменение в черновом файле, вводя новую историю для некоторого персонажа и обновление файла биографии того же персонажа, с этой новой историей, подробно описанной в нем. , Позже, если вы хотите удалить ("отменить") эту историю, у вас есть один коммит со всем, что уже связано.

Эта способность сохранять логически связанные изменения во многих файлах вместе (с дополнительным комментарием, объясняющим изменение), вероятно, является наиболее важным аргументом в пользу использования контроля версий для одного пользователя (поверх простого резервного копирования на основе даты). Позже, когда я вижу что-то странное и спрашиваю себя: «О чем я думал?», Мне очень легко ответить на этот вопрос.

Еще пара комментариев о вещах, которые вы не спрашивали:

• Ветвление - это может оказаться полезным для "игрового тестирования" идеи - я не знаю, насколько это распространено в письменной форме. В программировании я мог бы попробовать что-то, что потребует много коммитов, и я не уверен, что это сработает, - так что ветвь явно чувствует себя "безопаснее", чем возвращаться назад к тому времени, когда я думаю, что начал это.

• Git (и, вероятно, Mercurial) в основном предназначены для исходного кода; Обычно они сравнивают файлы по строкам, что, вероятно, означает целые абзацы для вас. Что еще более важно, если ваши файлы не являются текстовыми (например, если вы используете Word), настроить их на "понимание" внесенных изменений очень сложно, а в некоторых случаях может оказаться невозможным. Если ваша система контроля версий не может видеть сделанные вами изменения, вы теряете большую часть ее преимуществ.

[1] На самом деле вы можете сделать это для каждого подкаталога, даже если вы используете один репозиторий для всего, и это не намного больше работы; Но если вы всегда будете этим заниматься, просто держите их отдельно.

Answer 2

Должен ли я управлять версией всей своей папки «Документы» как единого хранилища?

Я бы начал таким образом, да. Со временем, если вы чувствуете, что репо слишком громоздко, вы можете разбить его на несколько репо. Единственное хранилище будет полезно видеть ваши изменения сразу по всей папке «Документы». С отдельными репозиториями вам придется заходить в каждую папку, чтобы делать коммиты.

Есть ли преимущества в наличии нескольких небольших репозиториев, а не одного большого?

Наличие меньших репо означает меньший размер для каждого репо. Если вы когда-нибудь хотели поделиться некоторыми документами, было бы легче, если бы у вас было несколько репозиториев вместо одного. Или, возможно, "частное" репо и "публичное" репо.

Должен ли я поддерживать какую-то версию контроля версий самостоятельно, вручную? Например, draft1.txt, draft2.txt, draft2-shorter.txt и т.д.? Или я должен позволить системе контроля версий сделать все это для меня?

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

A--B--C--D--E--F  (master)
       \
        X--Y--Z  (shorter)

Раньше я пытался никогда ничего не удалять, а вместо этого спрятал старые файлы в папки, называемые backups/, archives/ или old-version. Теперь, когда я использую контроль версий, могу ли я свободно удалять файлы, которые мне больше не нужны?

git будет хранить все изменения, которые вы когда-либо вносили, в любой файл. Так что если вы хотите вернуться на день или год назад, можете. Если по какой-то причине вам нужно удалить файл, вы можете

git rm draft1.txt
git commit -m 'remove unused file'

Answer 3

Должен ли я управлять версией всей своей папки «Документы» как единого хранилища? (Он содержит подпапки, такие как «Документы / истории / муки / персонажи /», «Документы / истории / муки / черновики», «Документы / истории / муки / мозговые штурмы», «Документы / резюме», «Документы / письма /» и т.д.). Или я должен создать отдельные репозитории для каждого проекта? Или даже отдельные репозитории для каждой подпапки в рамках проекта письма (/ интервью /, / веб-исследование /, / история-проекты / и т.д.)?

Обычно вы создаете один репозиторий для каждого проекта, но для вашего случая я не думаю, что это имеет значение. По сути, если вы единственный, кто когда-либо будет работать над всем этим (вы не делитесь частями с другими людьми), тогда, вероятно, один репо вполне подойдет.

Есть ли преимущества в наличии нескольких небольших репозиториев, а не одного большого?

Главным образом, предотвращение бедствий в одном хранилище, затрагивающих другое :)

Должен ли я поддерживать какую-то версию контроля версий самостоятельно, вручную? Например, draft1.txt, draft2.txt, draft2-shorter.txt и т.д.? Или я должен позволить системе контроля версий сделать все это для меня?

Определенно последний.

Раньше я пытался никогда ничего не удалять, а вместо этого спрятал старые файлы в папки, называемые backups/, archives/ или old-version. Теперь, когда я использую контроль версий, могу ли я свободно удалять файлы, которые мне больше не нужны?

Резервное копирование всего репо. Храните его безопасно где-нибудь в облаке. Убедитесь, что вы знаете, как восстановить старые версии по мере необходимости.

Answer 4

Должен ли я управлять версией всей своей папки «Документы» как единого хранилища?

Нет. Для вопроса типа "Можно ли" ответ будет не столь обязательным, но "репозиторий на проект" имеет много преимуществ

• Общая история для всех объектов в хранилище означает, что эволюция в одном проекте не влияет на другие проекты
• В случае многофайловых проектов вы можете легко разделить и разделить файлы на подпроекты (когда и если это необходимо)

Есть ли преимущества в наличии нескольких небольших репозиториев, а не одного большого?

Управляемость, размер (возможных) переносов по клону | pull | push, размер каждого репозитория

Должен ли я поддерживать какую-то версию контроля версий самостоятельно, вручную?

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

Теперь, когда я использую контроль версий, могу ли я свободно удалять файлы, которые мне больше не нужны?

Да, если вы сохраняете репозитории законченной работы (в некотором месте резервирования), у вас есть старый результат ("файлы") с добавленным значением «полная история изменений, а не только конечное состояние»