ПШЕ AndroidStudio
- Все хорошо, только перед влитием обязательно засквош коммиты.
- Заскво...Что?Примерно такая реакция была у меня после получения апрува первого пул реквеста на первой неделе работы в одной крупной компании. Причина такой реакции весьма простая — далеко не каждый заказчик/работодатель может себе позволить такую роскошь как большая команда на одну платформу, в особенности это касается мобильной разработки. Из-за ненадобности и возможности быстрой коммуникации в своем мирке, далеко не все вещи, которые используют крупные мастера своего дела, обретают актуальность в небольших командах. Говоря проще —, а на кой мне это надо, если мы и так хорошо без этого жили и хорошо справлялись?
После перехода в новую компанию я столкнулся с той же проблемой, но уже по другую сторону баррикад. Если вы еще не догадались о чем пойдет речь дальше — это GIT, говоря точнее, его встроенный инструментарий в AndroidStudio и как он позволяет сделать нашу работу проще.
Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал (и жалею).
Amend commit
В случае, когда Вы решили дополнить свои изменения к последнему коммиту, стоит воспользоваться следующей коммандой:
// Дополнит последний коммит изменениями без изменения сообщения
git commit --ammend
// Дополнит и изменит сообщение последнего коммита
git commit --ammend "New commit message"А можно ускорить процесс:
Edit commit message
Допустим, Вы создали большой PR с большим количеством коммитов, да перед пушем заметили, что одно из сообщений некорректно и было бы неплохо его отредактировать, пока жесткий ревьювер не четвертовал Вас за такую оплошность:
Interactive rebase
Я боюсь представить выполнение одной из недавних задач по рефакторингу без знаний использования этого инструмента. Проблема заключалась в том, что мне нужно было отрефакторить N файлов. Каждое изменение следовало делать отдельным коммитом, чтобы не собирать большую пачку в одну кучку и была возможность отдельного форсирования каждого из файлов/коммитов в будущем.
Пачка была быстро собрана, коммиты получились хаотичные, да еще и на ревью получил порцию исправлений… Окей, не проблема.
Проверяем отставание наших изменений от ветки, в которую мы хотим вливаться.
//Покажет хеши и коммит мессаджи
git cherry master -v
// Подсчитает нам количество отставших коммитов
git cherry master | wc -l Либо через GUIню:
Дальше скачем в tools:
Указываем количество коммитов, которые хотим отредактировать:
Или сразу укажем таргeт ветку:
Дальше определяемся что нам нужно сделать:
И редактируем:
Подробнее про команды:
# Commands:
# p, pick = использовать коммит(оставить при своем)
# r, reword = использовать коммит, но отредактировать его сообщение
# e, edit = редактирование коммита, без возможности amend-а(без слияния)
# s, squash = слить с предыдущим коммитом с возможностью редактирования итогового сообщения
# f, fixup = аналог сквоша,без возможности редактирования сообщения(отбросит сообщение коммита который сливаем)Коммиты отредактированы, осталось только подлить все на ремут сервер. Но ведь история изменена? И хэши явно не совпадают с тем, что находится на удаленной ветке.
Force push перезатрет нашу историю и примет новые изменения как родные.
Multiple remotes
Скорее всего это лишнее, но, исходя из моей практики, далеко не все обращают внимание на эту фичу.
Что это? В случае работы в 2 и более ремут хранилищах (актуально, когда доступ в основное хранилище по прямому запросу закрыт), быстрое переключение между удаленным ветками для пушей/пулов тоже упрощен:
Git blame
Полезный трюк для просмотра автора внесенных изменений:
Теперь про более эффективную работу. Если Вы не поленились и внесли правила ведения коммитов в Вашем проекте, стоит включть IssueNavigationLink:
//Пример паттерна формирования коммит мессаджа
-: (Кроме всего этого, Вы можете настроить проверку формирования коммит мессаджа с помощью git-hooks — https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
Отредактируем файл project/.idea/vcs.xml:
Подбросим свою регулярку для анализа коммит месаджа:
Теперь просмотр истории либо блейма возможен с навигацией напрямую в задачу таск трекинговой системы с автоподстановкой необходимого ID.
Git cherry-pick
Не путать с командой cherry!
Допустим, Вы работаете над фичей/фиксом, во время работы заметили блокирующий Вас баг и поправили его, да всю свою работу не закончили и в рабочую ветку не влились. Ваши компаньоны отрепортили, что проблема блокирует не только Вас, но и кого-то другого, и было бы неплохо поделиться им. Но Вы все еще работаете над своей задачей, а отвлекаться нет желания… В таком случае, будет проще всего забрать Ваш 1 коммит в другую ветку и экстренно вмержить его в рабочую (фризную ветку). Как это сделать?
Готово:
Заключение
В заключении хотелось бы сразу вспомнить вечный холивар на тему: терминал или GUI редактор для работы с VCS? Тут дело вкусовщины. Понятно дело, что CLI GIT-а более мощный инструмент и для спецефичных задач без него никуда. Но для ежедневных задач встроенный пакет утилит для работы с системами контроля версий в AS — просто must have и сократит время разработки в разы. Надеюсь, что Вы нашли что-то новое в этой статье и помог облегчить Ваши трудовые будни.
