Comments 16
Очень полезная, отличная статья. Автору большое спасибо.
Если честно, то не очень люблю конкретно вот такие ретроспективные статьи о которых пишет автор. Коротко и по делу - вот мой критерий оценки статей. Еще в библии сказано: "да и нет - остальное от лукавого..."
... вы поняли, как можно написать показательнее и прозрачнее
Вы осознали, насколько дурацкое имя у функции, которую вы написали еще в самом начале
На мой взгляд, это повод создать еще один коммит, только и всего.
Вы хотите немного поменять местами хронологию событий
Зачем?
Мой стиль использования git, наверное, можно назвать "наивным", но я предпочитаю использовать его в стиле "бумажного ежедневника" - если уж что-то в git попало, то всё, теперь уже навечно, не надо пытаться это корректировать. Бывают, конечно, исключения, вроде инфицирования репозитория большим динамически изменяющимся бинарником, тогда да, нужно почистить.
Git действительно позволяет проворачивать нам всяческие кунштюки, но же не забывайте, что в больших проектах бывает еще и человеческий лог, вики, документация и прочее, что тоже требует постоянной актуализации. Если вы залезете во внутренности действительно "взрослого" проекта, к примеру, Linux или git, то думаю, там вы вряд ли найдёте широкое применение описанных вами инструментов.
Я правильно понимаю, что в такие моменты (написания) существование git bisect полностью забывается? Не в укор, а скорее как вопрос "за жизу"
git, вероятно, не лучший инструмент, не лучшая система контроля версий для подобной задачи, где постоянное переписывание истории коммитов — типовой рабочий процесс.
Другими словами, автор всё ещё не понял негласные правила пользования гитом. Нет, гласные, но их вычитывать надо. И перемена истории, которая затрагивает еще пачку предыдущих веток, к "нормальному" поведению точно не относится.
Суть git-а как блокчейна -- в его линейности. Не нравится изначальное название функции? Если вы всё ещё в своей локальной ветке - перетасовывайте и переименовывайте как душе угодно. Опубликованные коммиты? Не трогать! Переименуй сейчас атомарным коммитом и портируй на старые ветки, коль угодно. Про дневник выше -- хорошая метафора.
мне кажется, случилось недопонимание
вы пишете, что автор не понял и приводите цитату автора, которая говорит все то же самое, что и вы
ваше замечание справедливо для гита как инструмента работы в команде. и автор с ними согласен. у автора предполагается вариант индивидуальной работы с гитом. это не то, что вы делаете на работе
автор использует гит таким образом просто потому, что не знает иного инструмента иди способа и всегда готов рассмотреть предложения
Глубокоуважаемый, безмерно дорогой и светлый автор статьи, не только во всей заключительной главе видно, что вы собираетесь зайти на второй круг хождения по граблям, но и по предыдущим вставкам тоже. И если вы с набитыми шишками уйдете с нынешними выводами, то второй круг обеспечен, а я не хочу его допускать. Сразу достигнуть дзена и прыгнуть к финалу можно (и помочь в этом может прочтение git-scm и подглядывание за очень крупными проектами, там же есть глава про разные методы организации работы).
Я не спрашивал ни одного из авторов таких статей, как они это сделали. И, возможно, зря
Мне кажется, они уже из группы тех авторов, которые статьи строчат как на конвеере. Значит, параллельно с кодом метят писать статью. Тогда и заготовки в виде тегов, а может даже скриншотов и отрывков мыслей будут под рукой для написания статьи.
Я вел GitHub репозиторий и аккуратно протоколировал все действия. Правило было буквально одно — ответственно относиться к коммитам.
// см. историю или рисунок: https://habrastorage.org/r/w1560/webt/ia/pd/p4/iapdp481fnizaeh4-9ltadvsdj4.png
Может, коммиты и атомарны, но названия у них не говорящие. И тут, может, уместно будет описать точки зрения, для которых важны описания коммитов:
разработчик: не запутаться самому в том, что сделал
ответственный за репозиторий: понять куда, что, и зачем? А еще именно здесь нужна атомарность и хорошее наименование, чтобы в случае проблем можно было откатить проблемный коммит и только его одного. В целях портирования коммитов и целостности истории, любые переписывания истории не допустимы при типичной работе. Для этого есть git revert, который 🥁...создает еще один коммит без дерганья истории.
автор ретроспективы: перекликается с пунктом 2, но хочется еще тупиковую историю изменений иметь. Обычно она оседает в проекте либо в виде непрошедших дискуссий/Pull Request-ов, либо в локальной репе, но тогда никуда не публикуется
Гипертрофированный пример у основоположницы надо смотреть, ядро Linux: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cb12b12ed32626ee2fa6291ba9a90b20a958c5f5
1,2,3 // PM: runtime: Documentation: ABI: Document time units for *_time
4, 5 // Many .../power/... time-related attributes have an "_ms" suffix and also include language in their ABI description to make clear that their time is measured in milliseconds. However, 'runtime_suspended_time' and 'runtime_active_time' have neither, and it takes me a nontrivial amount of time to poke through the source to confirm that they are also measured in milliseconds. Update the doc with "millisecond" units.
Куда: PM, power management subsystem
Что: документация
Чего: единиц измерения
Что именно
И почему
Поскольку ядро разрабатывается через эл. почту, то коммиты должны содержать не только сам код, но и полное пояснение всего, т.е. даже аргументацию нужности и важности. Поэтому и видна эта структура из четкого оглавления и подробного описания, где нет необходимости лезть и смотреть на измененные участки кода, чтобы прыгнуть в истории/откатить что-то. Атомарность коммитов заключается в том, что каждый можно откатить по отдельности при сохранении рабочей системы.
Переписывать историю нельзя, потому что это ломает весь workflow, а гит на него завязан: а) проверка истории с точки зрения безопасности б) не делать лишние телодвижения.
И после прочтения статьи, я так и не понял зачем переписывать историю здесь. Где нельзя уложиться в "надо подстроиться под инструмент, чтобы им продуктивно пользоваться"?
Ветка основная: ход повествования и развитие кода
Ответвление: тупиковый эксперимент, над которым некоторое время велась/будет вестись работа
Слияние с основной веткой: хороший эксперимент, перенимаем
Тег: на чем заострить внимание при написании статьи. Это не отдельная рабочая ветка, а один момент времени. Причем у тегов тоже может быть полновесное описание.
В этом пункте я не согласен с идей из статьи: "но вы хотите сохранить его в истории или, например, вы наткнулись на показательный баг, создайте ветку." - так как не предусмотрена дальнейшая разработка (пока), то не нужно делать ветку. Иначе же, если начинаете эксперементировать ("тупиковый сценарий" или нет), то сразу это делайте через отдельные ветки. Внедрение хороших экспериментов сразу видно через merge той ветки.
Если вам захотелось переписывать историю, то неизбежно придется обновлять всё, что ниже по хронологическому течению. Еще и поэтому этого делать не надо, но git rerere может упростить жизнь и запомнить принятые вручную решения при редактировании конфликтов.
А вам захочется ее переписать. Причин может быть множество:
На первое сразу отвечаю НЕТ, а на второе:
Спустя 10 коммитов вы поняли, как можно написать показательнее и прозрачнее
Значит спустя этих десять коммитов и будет, наконец, переименование.
Вы осознали, насколько дурацкое имя у функции, которую вы написали еще в самом начале работы с кодом, и вся история и все коммиты пронизаны использованием этой функции
Аналогично. Бывает. C'est la vie.
Вы хотите немного поменять местами хронологию событий
И это удобно делать, когда у вас маленькая ветка, которую вы готовите в виде PR. А не когда вы увлеклись переписыванием истории, и потому приходится обновлять еще N других веток, чтобы их синхронизировать. А если для написания статьи, то гит теребить незачем. Статья в этом смысле write-only: понадергали кода из гита, "обновили" его в статье, чтобы читался и был понятен в виде повествования и всё.
Вывод один, и он скучен: под инструмент надо подстраиваться. Но не критично, а созданные проблемы -- ССЗБ.
У меня исследование это всегда хаос, множество разрозненных полурабочих кусков кода / экспериментов. И часто для написания статьи весь процесс повторяю снова, но уже с полным пониманием какими путями двигаться к финалу. Например, последняя статья закончена аж спустя несколько лет после завершения проекта. Иногда даже специально начинаю писать статью, чтоб упорядочить происходящее, увидеть пробелы в материалах и что мог упустить.
уфф, тяжелый путь! но я примерно так и представлял себе написание больших статей о проделанной работе. когда я пытался работать в такой манере, вымотался ужасно. хотя результат того определенно стоил. как вы и говорите, это хорошо укладывает в голове полученный опыт. заодно можно привести в порядок сам проект, увидеть в нем ранее невидимые изъяны и должным образом подвести итоги проделанной работы
Мне кажется вы все немного переусложняете - вместо того чтобы переписывать всю историю, можно было бы создать отдельную повествовательную ветку (article-story) и cherry-pick-ать в нее нужные коммиты из основной боевой ветки, попутно их переименовывая и сквоша. Получился бы чистый и линейный рассказ, не ломая основную историю разработки
Да как вы пишете эти ваши ретроспективные статьи?