Главная » Хабрахабр » Пара иногда востребованных хитростей при работе с git

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

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

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

Итак...

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

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

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

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

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

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

    git checkout feature
    git merge master -s ours

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Не позволяйте 3D-принтеру лениться

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

[Перевод] Знакомимся с альфа-версией снапшотов томов в Kubernetes

перев.: оригинальная статья была недавно опубликована в блоге Kubernetes и написана сотрудниками компаний Google и Huawei (Jing Xu, Xing Yang, Saad Ali), активную деятельность которых вы непременно видели в GitHub'е проекта, если когда-либо интересовались фичами и проблемами K8s, связанными с ...