Пара иногда востребованных хитростей при работе с git

Хочу поделиться рецептами решения пары задач, которые иногда возникают при работе с git, и которые при этом не "прямо совсем очевидны".
Сперва я думал накопить подобных рецептов побольше, однако всему своё время. Думаю, если есть польза, то можно и понемногу...

Итак...

Преамбула. Есть основная ветка (master), в которую активно коммитаются новые фичи и фиксы; есть параллельная ветка feature, у которой разработчики уплыли на какое-то время в собственную нирвану, и потом внезапно обнаружили, что уже месяц не мержились с мастером, и мерж "в лоб" (голова с головой) стал уже нетривиален.

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

Цель: смержиться. При этом, чтобы это был "чистый" мерж, без особенностей. Т.е. чтобы в публичном репозитории в графе веток две нитки соединялись в единственной точке с сообщением "merged branch 'master' into feature". А всю "вот эту вот" головную боль о том, сколько времени и сил это заняло, сколько было конфликтов было решено и сколько волос при этом поседело хранить незачем.

Фабула. То, что в гите можно редактировать последний коммит ключиком --amend знают все. Фишка в том, что этот "последний коммит" при этом может находиться где угодно и содержать что угодно. Например, это может быть не просто "последний коммит в линейную ветку", где забыли поправить опечатку, но и мерж-коммит от обычного или "осьминожного" слияния. --amend ровно так же накатит предложенные изменения и "встроит" изменённый коммит в дерево, как будто он в самом деле появился в результате честного слияния и разрешения конфликтов. По сути git merge и git commit --amend позволяет полностью разделить"застолбление места" ("этот коммит в дереве будет находиться ЗДЕСЬ") и содержание самого коммита.

Основная идея сложного мерж-коммита с чистой историей проста: сперва "столбим место", создавая чистый мерж-коммит (невзирая на содержимое), затем переписываем его с помощью --amend, делая содержимое "правильным".

1. "Столбим место". Это легко сделать, назначив при мерже стратегию, которая не будет задавать лишних вопросов о разрешении конфликтов.

   git checkout feature
   git merge master -s ours
   

   
   

2. Ах, да. Надо было перед мержем создать "резервную" ветку из головы feature. Ведь ничего же на самом деле не слито… Но пусть это будет 2-м пунктом, а не 0-м. В общем, переходим не не-слитую feature, и теперь честно сливаем. Любым доступным способом, невзирая ни на какие "грязные хаки". Мой личный способ — просматриваем мастер-ветку от момента последнего слияния и оцениваем возможные проблемные коммиты (например: поправили в одном месте опечатку — не проблемный. Массово (на много файлов) переименовали какую-либо сущность — проблемный. И т.д.). От проблемных коммитов создаём новые ветки (я делаю бесхитростно — master1, master2, master3 и т.д.). И потом сливаем ветку за веткой, двигаясь от старых к свежим и исправляя конфликты (которые при таком подходе обычно самоочевидны). Другие методы предлагайте (я не волшебник; я только учусь; буду рад конструктивным замечаниям!). В конечном итоге, потратив (может быть) несколько часов на чисто рутинные операции (которые можно доверить юниору, ибо сложных конфликтов при таком подходе просто нет), получаем финальное состояние кода: все нововведения/фиксы мастера успешно портированы в ветку feature, все релевантные тесты на этом коде прошлись и т.д. Успешный код должен быть закоммитан.

   
   

3. Переписываем "историю успеха". Находясь на коммите, где "всё сделано", запускаем следующее:

   
   

git tag mp
git checkout mp
git reset feature
git checkout feature
git tag -d mp

(расшифровываю: с помощью тэга (mp — merge point) переходим в detached HEAD состояние, оттуда reset на голову нашей ветки, где в самом начале "застолблено место" обманным мерж-коммитом. Тэг больше не нужен, поэтому его удаляем). Теперь мы стоим на первоначальном "чистом" мерж-коммите; при этом в рабочей копии у нас "правильные" файлы, где всё нужное смержено. Теперь нужно добавить все изменённые файлы в индекс, и особенно тщательно просмотреть на non-staged (там будут все новые файлы, возникшие в основной ветке). Все нужные оттуда добавляем тоже.
Наконец, когда всё готово — вписываем в зарезервированное место свой правильный коммит:

git commit --amend

Ура! Всё получилось! Можно небрежно пушить ветку в публичный репозиторий, и никто не узнает, что на этот мерж вы на самом деле потратили пол-дня рабочего времени.

Преамбула: в файл кодили-кодили, и наконец накодили так, что даже вижуал-студия стала подтормаживать, его переваривая (не говоря уже о JetBrains). (Да, мы снова в "неидеальном" мире. Как всегда).

Умные мозги подумали-подумали, и выделили несколько сущностей, которые можно отпочковать в отдельный файл. Но! Если просто взять, скопипастить кусок файла и вставить в другой — это будет с точки зрения git совершенно новый файл. В случае любых проблем поиск по истории однозначно укажет лишь "где этот инвалид?", который разделил файл. А найти оригинальный источник бывает нужно вовсе не "для репрессий", а сугубо конструктивно — чтобы узнать, ЗАЧЕМ была изменена вот эта строчка; какую багу это фиксило (или не фиксило никакую). Хочется, чтобы файл был новый, но при этом вся история изменений всё же осталась!

Фабула. С некоторыми слегка досадными краевыми эффектами это можно сделать. Для определённости — есть файл file.txt, из которого хочется выделить часть в file2.txt. (и при этом сохранить историю, да). Запускаем вот такой сниппет:

f=file.txt; f1=file1.txt; f2=file2.txt
cp $f $f2
git add $f2
git mv $f $f1
git commit -m"split $f step 1, converted to $f1 and $f2"

В результате получаем файлы file1.txt и file2.txt. У них у обоих совершенно одинаковая история (настоящая; как у исходного файла). Да, оригинальный file.txt пришлось при этом переименовать; в этом и состоит "слегка досадный" краевой эффект. К сожалению, найти способ сохранить историю, но чтобы при этом НЕ переименовывать исходный файл, я не смог (если кто смог — расскажите!). Однако гит всё стерпит; никто не мешает теперь отдельным коммитом переименовать файл обратно:

git mv $f1 $f
git commit -m"split finish, rename $f1 to $f"

Теперь у file2.txt гилт покажет ту же историю строчек, что и у оригинального файла. Главное — не сливайте эти два коммита вместе (а то вся магия исчезнет; пробовал!). Но при этом никто не мешает редактировать файлы прямо в процессе разделения; необязательно это делать позже отдельными коммитами. И да, можно выделять сразу много файлов!

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

Let's block ads! (Why?)