💡 Идея: Упрощаем жизнь с гитом, или изобретаем колесо?
Публичный пост
Продуктивность
Так повелось, что знакомство с гитом у меня началось с Sourcetree, а в последние годы я пересел на Sublime Merge, так что в батле я за графическую оболочку — привык к визуализации.
Но мне очень не хватает возможности добавить свою кнопку. Конечно, руки чесались написать что-то своё, но вот в тот же Sublime Merge вложено столько сил, что сколько времени мне придётся потратить, чтобы получить продукт схожего качества, пусть и с ограниченным под себя функционалом?
В SM есть возможность запуска своей команды, но только через поиск по имени, что, в общем-то, то же самое, что и в терминале — дольше, чем нажать на кнопку.
И тут я наткнулся в настройках на пункт Git Binary, куда можно передать любой бинарник. Так у меня родилась идея написать обёртку над гитом, которая, в дополнение к командам, передаваемым из SM, будет ещё и мои хотелки исполнять.
Работает это просто: консольное приложение получает все аргументы, которые переданы гиту. Парсим, делаем наши дела и вызываем уже гит с оригинальной командой.
Вот список фичей, которые у меня за несколько лет сформировались:
- Кнопка
fetch, если вызвана на мастере, должна удалять локальные ветки, которые уже были замержены в мастер. Но есть исключение — если в ветке есть коммит, который не был запушен по забывчивости, — хорошо узнать об этом после мержа. - Я работаю над разными платформами, и мне нравится указывать её в сообщении коммита, например, "[iOS] feature". Но каждый раз писать этот тег утомляет, тем более что в случае нашей монорепы определить его очень просто — по имени папки, в которой лежат изменённые файлы. Пишу только "feature", а тег добавляется автоматически. Эта же фича проверяет, нет ли в чекауте по ошибке изменений с другой платформы - тег должен быть один для всех файлов.
- Когда я только начинаю работать над фичей в новой ветке, люблю перед пушем сделать
rebase masterвместо мержа, чтобы не было лишних коммитов. Но нужно сначала перейти в мастер, сделать пулл и вернуться в текущую ветку. Всё это выполняется автоматически передrebase master. - Если PR для фичи уже прошёл ревью, делать
rebaseнекрасиво — сломается обычныйpullу других разработчиков. Но перед мержем мастера автоматически подтянем его изменения. - Специфично для iOS-разработки. У нас есть файл
swiftpm/Package.resolved, содержащий финальные версии пакетов. При смене ветки Xcode часто изменяет этот файл не по делу — считает версию до чекаута верной и откатывает пакеты до неё. Очень раздражает, когда переключаешься на ветку, идёшь дальше по своим делам, а этот файл изменён, и чекаут невозможен. Делаю емуgit resetперед каждой операцией, где он может помешать. Когда нужно его запушить, эта логика не помешает.
Обёртка написана на Swift, немного добавляет оверхеда, но времени и, главное, шаблонных телодвижений экономит очень много.
Есть идея сделать для этого какой-нибудь интерфейс — фильтр команды, список действий перед её исполнением, список после. Чтобы всё можно было настроить под себя, зная гитовые команды, без необходимости программировать, или использовать готовые шаблоны. Что-то вроде того, как устроены Workflow в Alfred.
Не могу отделаться от мысли, что изобретаю колесо — то ли похожее решение уже существует, то ли все более сложные вещи всё же делают через консоль?
git fetch --prune- удалит все локальные ветки, которых нету в ремоуте. Замердженная ветка в обычном флоу удаляется.Можно сделать или хуком или еще как-то. Логика звучит слишком кастомной для проекта. "Проверь файлы из коммита и скажи, что они относятся к одному набору relative путей и в зависимости от подставь свой commit.template". Причем основной проблемой будет написать правило, какие пути относятся к какой платформе - это в любом случае придется руками делать.
git fetch <remote> <sourceBranch>:<destinationBranch>позволит загрузить другую ветку без ее выкачки. Дальше просто ребейзишься.Я не понял у тебя несколько человек продолжают работать в ветке над фичей, после того как пуллреквест апрувнули? Им в любом случае или придется ребейзить ветку или отводить ее заново и продолжать работать в неотребейженной версии, просто отложив проблему, или можно мерджиться локально сделав локальный ребейз. В целом звучит как странное использование пулл реквестов - с закрытием пулл реквеста должна закрываться ветка.
Выглядит так, что правильным решением в твоих условиях будет: есть main (куда хотим замерджится) и есть devfeature (ветка разработки фичи, над которой работают несколько человек). Если необходимо залить кусок изменений из devfeature в main без полного мерджа, то необходимо отвести от devfeature ветку devfeature_to_be_merged и отправлять на pr уже ее. Тогда ее можно будет свободно ребейзить и не мешать другим. Но возможно это сделает будущий окончательный ребейз devfeature очень больным.
safeswitch=!git checkout -- "swiftpm/Package.resolved && git switch", но в целом это проблема не гита, а xcode. Я не настоящий сварщик, но правильно же, что это служебный файл "я выкачал такие-то пакеты пакадж менеджером", а не "у проекта зависимости таких-то версий". Если это так, то почему бы не пихнуть его в .gitignore и дело с концом?А я чет купил "вилку" после "Сорстри" и вроде как всего хватает...
в пункте 3 не надо переходить в мастер, делаешь git fetch, потом git rebase origin/master и он делает rebase сразу на remote branch
Штош, раз все начали делиться своими любимыми UI, расскажу про свой.
Вот в каком еще клиенте можно такое сделать за одну секунду?
И дальше работаешь в своей ветке.
Никаких тебе стешей, шелвов, чекаутов и прочей херни. Где ещё такое можно сделать?
Я знаю только SmartGit, поэтому и рекомендую.