Цифровой садик - приветственная

Цифровой садик - приветственная | Полный список всего, что тут есть | RSS | Подписаться через follow.it

29.06.2022

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 писателям.

Если у вас есть мысли, комментарии, предложения или отклики по поводу этой страницы или этого цифрового сада в целом, напишите мне сообщение на agnessa@agnessa.pp.ru. Мне ооочень интересно!

Задонатить.


An IndieWeb Webring 🕸💍