git для пишущих

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

Хорошо работает с текстовой информацией, которая за один раз изменяется не очень сильно. Плохо — c двоичными файлами, и там, где происходят объёмные не-смысловые изменения, типа текста с постоянно заново происходящей разбивкой на строки.

Мне удобно говорить и думать об этом на примере git, ибо то, чем я пользуюсь. Особенности пользования другими не представляю, выбрала git годы назад, и пока решением довольна.

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

Что я получаю заодно?

• Свободу устройства проекта. Работаю я с одним файлом или с сотней, в одном каталоге или у меня целое дерево подкаталогов, для git — неважно. Как мне удобнее.
• Свободу минимализма и удаления. Можно спокойно держать проект в актуальном-минимальном состоянии, удалять всё, что захотелось удалить, просто потому, что в любом случае, ничего ж не пропадает. Если оно нужно, я потом достану из истории. А если нет — то и нет.
• Простоту сохранения в историю. Мне не надо измышлять, где хранить кучу версий, стоит ли вот это изменение копирования всего ещё раз туда, и вообще. Потому что сейчас любое мелкое исправление вполне стоит коммита, это почти не прибавляет объёма хранилищу, и делается в две привычные команды + описание изменения.
• Безопасность крупных замен, и подобных действий. Уже были ситуации, когда я нечаянно затирала что-то, ахала, обнаружив это даже не сразу, а через время… и с облегчением выдыхала, вспомнив про git. Ибо всего делов-то — найти последнюю хорошую версию, и достать её.
• Практически не использовала, но — удобство хранения «версий для других». Типа, что-то кому-то отправила и отметила, что вот это. И если отправленное так и кануло, то оно не мозолит глаза и мозг, а если там что-то потребовалось делать именно на основе той самой версии — несложно достать и делать. Заметим, никак не обижая текущую мою личную работу.
• По идее, но вообще не пробовала, должно давать удобство взаимодействия с соавторами, бета-ридерами и прочими хорошими людьми, помогающими писать. Точнее, пробовала, но в работе.

Когда не имеет смысла? Наверное, для одноразовых мимолётных текстов, которые, может быть, стоит даже хранить, но которые не будут изменяться.

• Какое-то время омерзительно плохо получалось коммитить каждое изменение. Иногда неделями забывала коммитить и не хотела об этом помнить, типа сбивает «поток». Но пока поток - делаешь, что делается. Вот когда «и увидел бог, что это хорошо», конкретный отдельный забег кончился — тогда самое время коммита. Ещё тут спасает flashbake, который автокоммитит в случае достаточно больших перерывов. И емаксовая штука на ту ж тему.
• Нет опыта совместного написания литературного текста c использованием git. Пока что было не с кем.
• В связи с предыдущим, наверное, не привыкла использовать ветки, что, похоже, стесняет. Хвала мне, я хотя бы теги ставлю иногда.

• git init - создать новый пустой репозиторий в текущем каталоге (после этого нужны add и commit)
• git add – добавить что-то в отслеживаемое/фиксируемое.
• git commit зафиксировать (создать коммит) в текущей ветке.
• git log – посмотреть что в логах.
• git diff и git status — посмотреть что вы уже сделали в течение работы.
• git tag – задать именованную метку для коммита (текущей точки).
• git reset и git checkout (с параметрами пути) – отмена последних изменений изменений (откат изменений).
• git checkout и git branch – переключение ветвей.
• git show-branch – посмотреть где вы (в какой ветке).
• git merge – слить (объединить) локальные ветви репозитория.

• http://stackoverflow.com/questions/7775881/using-git-for-writing-thesis - человек спрашивал совета про написание диссертации или подобной работы. Некоторое количество советов получил. Из того, что там примечательно для меня:
  • теги на те версии, которые отправляет куратору. Сильно поможет ориентироваться. Собственно, с тех пор и поняла, зачем теги.
  • совет писать отчёты о продвижении куратору же с опорой на git log.
  • git для поддержания хорошего настроения - путём смотрения, что было сделано, когда кажется, что ничего не делается. Вот как следующий раз начну печалиться, так и.
  • git diff --color-words игнорирует границы строк, показывает разницу по словам. То же делает --word-diff=color.
• http://thewagner.net/blog/2013/08/09/my-blogging-workflow-with-git/ - процесс описан. Я там не собираюсь заимствовать ничего, зато понятнее, как я не хочу делать. Например, я не хочу отказываться от истории написания.
• http://writers.stackexchange.com/questions/10440/what-is-the-purpose-of-version-control - обсуждение, зачем vcs писателям.
• https://news.ycombinator.com/item?id=6537471 – интересное обсуждение про аналоги контроля версий в вордах. Ессно, там оно внутри одного документа и такое себе, хотя лучше, чем никакое :) В обсуждении есть про то, как люди взаимодействуют, в том числе совет https://news.ycombinator.com/item?id=6539871, «If you don't already do it, set up separate branches for each advisor/supervisor so you can add their comments there, then merge it back with your own work. i.e., just pretend that they're using git too, but do it for them».