Простое управление версиями для текстовых документов (Linux)

Да, вы должны использовать git*.

Теперь позвольте мне объяснить, почему. Учитывая текущий (довольно туманный) набор критериев в вашем вопросе, ответ кажется довольно очевидным. Если бы вы знали больше, вы бы даже не задавали этот вопрос. Вы уже дошли до края обрыва, теперь вам нужно только уговорить совершить прыжок.

_{* Или Fossil, Mercurial, Darcs, Bazaar или другие DVCS, в зависимости от предпочитаемого вами внешнего интерфейса, который будет объяснен.}

Текущая сцена и немного истории:

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

• неуклюжий

  Примечательные записи*: CVS, Subversion.

  Прежде чем системы DVCS покорили мир, существовали системы VCS. Их можно охарактеризовать центральным хранилищем/сервером и звездообразной структурой пользовательских рабочих областей/клиентов. Это был незаменимый ценный инструмент для того, чтобы держать команду программистов на одной волне и даже адаптироваться для других целей. Один программист может работать с несколькими системами и экспериментировать с ветвями и тегами. Они спасли много дней. Но они были неуклюжими по своей природе. Они усложняют некоторые простые задачи . Во-первых, это были накладные расходы на их настройку, необходимость в сервере и специальных протоколах для их подключения. Затем была боль от того, что ты сделал что-то не так. Достаточно сказать, что они выполнят работу для вашего варианта использования, но приведут к компромиссам, усложняющим жизнь.

• выбитый

  Примечательная запись: RCS.

  Потому что, когда «полномасштабная» система, включающая серверы, клиенты, аутентификацию и все такое прочее, было слишком сложно проглотить, можно было использовать урезанную систему, которая жила в своем собственном маленьком пузыре. RCS сделала это, отказавшись от идеи репозитория и просто изменяя версии по одному файлу за раз. У вас была file.txtи рядом с ней file.txt,vбыла история версий. Вы можете легко создать его экземпляр для каждого файла и использовать несколько простых инструментов для работы с различиями, откатом времени и т. д.

  Теперь, прежде чем вы скажете: «Ага, это как раз то, что я искал!», прочтите, пожалуйста, потому что это уже не самый простой и не рекомендуемый способ сделать это. Легкий вход был достигнут ценой низкого операционного потолка , который наверняка рано или поздно стеснит ваш стиль.

• распределенный

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

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

Итак, давайте сядем и скажем, как бы вы использовали этот инструмент.

Для целей этого ответа я собираюсь придерживаться git, потому что это одна из наиболее широко распространенных систем. Его легко установить практически в любой системе (на случай, если он еще не установлен), и имеется широкий спектр доступной документации, охватывающей практически любой вариант использования. Он также расширяем и распознается многими сторонними системами и т. д. При этом он не обязательно лучше, чем его ближайший конкурент, Bazaar или Mercurial.

• Если вы живете в экосистеме Ubuntu, вы можете взглянуть на Bazaar, потому что Canonical использует его для всего, и он хорошо интегрируется с вашей средой. Их служба панели запуска похожа на Github, но адаптирована для разработки программного обеспечения Ubuntu. Если вы планируете играть в этой экосистеме, подумайте bzrоб обучении вместо git, чтобы один инструмент работал как для вашего личного мира, так и для экосистемы, в которой вы участвуете. Если вы не работаете над проектами, координируемыми на панели запуска, я бы предложил использовать git.

• Если кто-то из ваших коллег хорошо разбирается в Mercurial, вы можете попробовать его использовать. Это очень мощная DVCS с некоторыми преимуществами по сравнению с Git. Часто утверждается, что он быстрее для некоторых операций из-за более оптимизированного потока данных. Все инструменты упакованы в один двоичный файл, а не собраны вместе из кучи отдельных (и иногда избыточных) инструментов, таких как Git. Его можно расширять с помощью привязок Python, и можно создавать внешние системы, которые очень тесно с ним интегрируются. Эта парадигма достаточно похожа на Git, поэтому, изучив ее, вы также сможете ошибаться в репозитории git. В конце концов, однако, git сейчас является самым популярным игроком в этой области, и его использование даст вам более быстрый доступ к помощи, когда она вам понадобится.

_{* Приношу свои извинения всем системам VCS без названия. CVSNT, CA, CC, Perforce, Plastic, PVCS, Star, SVK, Vault, Vesta, VSS и многие другие. Ваши имена никогда не будут забыты , это уже просто память.}

Как gitподходит для вашего варианта использования:

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

На самом деле Git можно использовать гораздо проще.

Подобно RCS, git хранит информацию о версии локально рядом с вашим контентом. Заметное отличие заключается в том, что это делается для каждого каталога, а не для каждого файла.

• РКС:

    file1.txt
    file1.txt,v
    file2.txt
    file2.txt,v
  

  Файл ,vдля каждого файла содержит текущий список истории файла, сохраняя дельту между каждой последующей версией.

• мерзавец:

     directory
     + file1.txt
     + file2.txt
     + .git
       + glob1
       + glob2
  

  Материалы в папке .git на самом деле имеют причудливые имена и довольно сложны, но вам не нужно об этом знать. Концептуально все, что он делает, это сохраняет различия между версиями вещей в вашем каталоге. По сути, каждый глобус представляет собой изображение того, как выглядел ваш каталог во время каждой фиксации. Много сложной математики снижает накладные расходы, так что сохраняются только дельта-данные.

Теперь это может показаться сложным, но вам действительно не нужно знать ничего из этого. Набор инструментов отслеживает все причудливые вещи для вас. Основное использование так же просто, как и RCS, но дает вам возможность расти в будущем.

Начало работы будет примерно таким:

# Change to the directory that has files you want to version.
cd ~/pathto/yourtextfiles

# Initialize git to keep track of that folder
git init

Сделанный. Сервера не нужны. Только вы и ваши файлы с контролем версий. За исключением того, что у вас пока нет файлов под наблюдением, поэтому git на самом деле ничего не наблюдает. Git не жадный в том смысле, что он не отслеживает все в папке, а только то, что вы ему сообщаете. Итак, следующий шаг — указать, какие файлы вы хотите отслеживать.

# Add some files to the system, assuming these already exist the your dir
git add file1.txt file2.txt

# Commit the changes you just made
git commit -m "initial add"

Обратите внимание, что в отличие от большинства систем, это двухэтапный процесс. Прежде чем вы зафиксируете что-то и поместите в репозиторий как новую версию, вы должны «подготовить» их. Не каждое изменение, которое вы вносите в свой рабочий каталог, автоматически считается чем-то, что вы хотите сохранить при каждом коммите. Возможно, вы изменили два файла, но хотите отметить только один.

# Edit a bunch of files
vim file1.txt
vim file2.txt
vim file3.txt

# Only mark one of them as going it your next commit
git add file2.txt

# Commit it to history
git commit -m "fixed typo"

Обратите внимание, что изменения в файле file1.txt еще не сохраняются в репозиторий, а файл3.txt пока вообще не отслеживается. Вы можете увидеть, что в ранее отслеженном файле есть неустановленные изменения, запустив git statusи что это за изменения, запустив git diff. Этот статус точки говорит вам, что вы внесли изменения в файл 1.txt и что в вашем каталоге есть неотслеживаемый файл 3.txt. Diff покажет вам изменения, которые вы внесли в файл file1.txt с момента последней подготовки и фиксации.

Один «подводный камень», о котором вы должны быть предупреждены о том, чтобы начать, чтобы он не укусил вас в будущем, заключается в том, что — потому что концепция репозитория git — это целый каталог, и изменения в файлах рассматриваются как образ этого каталога в момент времени — вам следует подумать о том, чтобы иметь отдельные репозитории для разрозненных проектов. Вместо того, чтобы создавать единый репозиторий из «Моих документов», вы должны создавать отдельные репозитории из каталогов, содержащих какое-то значимое подмножество ваших документов, будь то по теме, по формату, по проекту или что-то еще. Это упростит дальнейшую работу, когда вы захотите работать со «всеми документами, связанными с x», с другого компьютера без необходимости иметь каждый документ, который вы когда-либо создавали на этом компьютере. Гит не позволяетвы должны проверить поддерево репозитория *, это все или ничего, поэтому ошибитесь в сторону создания множества гранулированных репозиториев для тесно связанных наборов данных, по одному на каталог.

На самом деле это все, что нужно для базового использования. Оттуда почти все, что вы можете себе представить, возможно, но в этот момент вы будете задавать вопрос об использовании, а не о рекомендации программного обеспечения.

_{* Subversion, например, позволяла это, и я к этому привык. Это укусило меня на раннем этапе, когда я предполагал, что git позволит что-то подобное. У меня были ВСЕ мои личные файлы в одном большом репозитории svn, и я наивно предполагал, что git станет его заменой. Урок усвоен, и мои файлы лучше классифицированы.}

Но командные строки пугают!

Конечно, существует множество интерфейсных графических интерфейсов, которые позволяют вам не пользоваться командной строкой и визуально представлять, что происходит с вашими файлами. Многие из них имеют сходство с IDE и могут служить точкой входа в систему управления документами, используя их для запуска вашего любимого редактора* или даже для использования встроенного редактора. Поскольку вы спросили о серверной части о том, как должны храниться ваши файлы, я дал рекомендацию использовать gitв качестве диспетчера версий, но если вы имеете в виду, как это должно выглядеть и работать с точки зрения внешнего интерфейса, вы должны спросить это как отдельный вопрос.

_{* Конечно gvim, хорошо подходит для этого варианта использования ;-)}

В заключение:

Заходи, вода в порядке!

Один! Два! Три! Перейти git init .

Видишь, это было не так сложно.

Я бы посоветовал в этом случае использовать https://draftin.com/ , см. здесь краткий обзор конкретных функций, которые вы, возможно, захотите использовать.

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

1. Контроль версий: ДА , обязательно. Это основная функция черновика, и она великолепна, поскольку не мешает вам, когда вы не хотите ее видеть, но она всегда будет вам полезна, когда вы или кто-либо, с кем вы делитесь своим текстом, запутались. вместе с документом. (По умолчанию чужие правки не включаются в ваши версии документа, вы должны принять их заранее.)

2. Совместимость с Ubuntu/Mint: ДА , в конце концов, это веб-сайт. Любой приличный браузер справится с задачей, я тестировал автономную функцию только на хроме, у которого есть PPA для Ubuntu.

3. Простота пометки/комментирования/маркировки: НЕТ . Дело в том, что черновик должен справиться с этим за вас, позволяя вам отмечать основные и второстепенные версии ваших документов и четко указывать, кто внес правки. В этом отношении черновик не будет для вас лучшим инструментом.

4. Простой просмотр тегов/ярлыков, поиск: не уверен . Ну, по крайней мере, если черновые наборы тегов для вас вас устраивают.

5. Простое «восстановление» предыдущих версий: ДА . Вы можете не только восстанавливать предыдущие версии, но также можете сохранить полезные биты в обеих версиях и редактировать текущую версию, просматривая различия с любой другой версией (версиями).

6. возможность делать diffs: YES . Иногда ошибаются (самый досадный случай — при переписывании абзаца: драфтин считает, что я заменяю каждое предложение новым, смешивая старое и новое в разнице, тогда как я предпочел бы, чтобы новый абзац был отделен от предыдущего). старый, но цветовые коды делают его менее ужасным.) Однако дифференциалы работают нормально.

7. возможность синхронизации с разными машинами: ДА , из-за характера веб-страницы. Однако автономный режим странный и требует ручной синхронизации.

8. простая структура каталогов/иерархия для документов: ДА, но даже слишком просто. Вы можете помещать документы в папку, но мне еще предстоит найти способ вложения папок, что является большим недостатком.

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

Используйте « Ископаемое »

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

Однако, работая семь лет над созданием любимой системы, я нашел ее в Fossil . Это упоминалось один или два раза в SoftwareRecs, но, как правило, остается незамеченным (IMO).

Для этого пользователя Fossil отвечает на все преимущества, которые задокументировал Калеб в отношении системы на основе Git, и добавляет пару преимуществ для моего мозга/рабочих «привычек» . И это прекрасно отвечает моему первоначальному варианту использования/критериям (конечно):

• контроль версий (необходимо, очевидно!)
• Ubuntu/Mint дружественный (PPA было бы здорово) | но PPA не нужен!
• простая пометка/комментирование/маркировка «коммитов»
• простой просмотр тегов/меток
• простой поиск тегов/меток
• простое «восстановление» предыдущих версий
• возможность делать диффы
• возможность синхронизации с разными машинами
• простая структура каталогов/иерархия для документов

Дополнительные преимущества

По сути, для меня есть два преимущества (но это не впечатлит опытных пользователей Git):

1. Fossil легко размещается самостоятельно . Это также может быть верно для Git , но мне кажется, что Fossil может быть более простым самообслуживанием, чем Git. <shrug/>Хотя это не один из моих основных критериев из моего первоначального поста, я предпочитаю этот подход (т.е. не полагаюсь на сторонние сервисы).
2. Хотя процессы очень похожи на Git , подход Fossil (опять же) кажется мне немного более упорядоченным (или простым), так что некоторые беспокойства, которые я испытывал при использовании Git на протяжении многих лет (как и я), являются не проблема.
3. Бонус! Его также очень просто использовать на разных платформах (я регулярно переключаюсь между Ubuntu и MacOS); Опять же, Git, конечно, можно использовать и на любой платформе, но планка входа для Git на системах, отличных от Linux, кажется немного выше, чем для Fossil.
4. Бонус 2! Fossil называют «GitHub-in-a-box», поскольку его единственный исполняемый файл (легко устанавливаемый в системах Win/MacOS/*nix) включает в себя не только контроль версий, но и отслеживание проблем, вики, форум, «чат». " как средство, и встроенный веб-интерфейс ... все в одном. Радостный! (Не то чтобы нужно было использовать эти дополнительные функции, но они, так сказать, предоставляются бесплатно.)

Ироничное замечание Калеба (наверняка!) о Fossil (среди прочего) ("Ваши имена никогда не будут забыты , это уже просто память") вряд ли относится к Fossil... это то, что управляет разработкой SQLite. , так что не собирается уходить в ближайшее время!:)

git — хорошее решение для контроля версий. Специально для открытого текста.

• Изучите встроенную в ReText поддержку системы контроля версий. (не могу найти)
• Попробуйте git интерфейсы. Мне нравится гит-кола.
• Попробуйте внешние инструменты сравнения/слияния. Мне нравится Мелд.