ПШЕ AndroidStudio или как использовать VCS Tools по полной

- Все хорошо, только перед влитием обязательно засквош коммиты.
- Заскво...Что?

Примерно такая реакция была у меня после получения апрува первого пул реквеста на первой неделе работы в одной крупной компании. Причина такой реакции весьма простая — далеко не каждый заказчик/работодатель может себе позволить такую роскошь как большая команда на одну платформу, в особенности это касается мобильной разработки. Из-за ненадобности и возможности быстрой коммуникации в своем мирке, далеко не все вещи, которые используют крупные мастера своего дела, обретают актуальность в небольших командах. Говоря проще — а на кой мне это надо, если мы и так хорошо без этого жили и хорошо справлялись?

После перехода в новую компанию я столкнулся с той же проблемой, но уже по другую сторону баррикад. Если вы еще не догадались о чем пойдет речь дальше — это 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:

//Пример паттерна формирования коммит мессаджа
<PROJECT_ID>-<TASK-ID>: <COMMIT MESSAGE>

(Кроме всего этого, Вы можете настроить проверку формирования коммит мессаджа с помощью git-hooks — https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
Отредактируем файл project/.idea/vcs.xml:

Подбросим свою регулярку для анализа коммит месаджа:

<IssueNavigationLink>
    <!--Регулярное выражение в зависимости от Вашего паттерна-->
    <option name="issueRegexp" value="([A-Za-z]+-)(d+)" />
    <!--Адрес для подстановки Вашей задачи-->
    <option name="linkRegexp" value="https://github.com/IlyaPavlovskii/Android-Environments/issues/$2" />
</IssueNavigationLink>

Теперь просмотр истории либо блейма возможен с навигацией напрямую в задачу таск трекинговой системы с автоподстановкой необходимого ID.

Git cherry-pick

Не путать с командой cherry!
Допустим, Вы работаете над фичей/фиксом, во время работы заметили блокирующий Вас баг и поправили его, да всю свою работу не закончили и в рабочую ветку не влились. Ваши компаньоны отрепортили, что проблема блокирует не только Вас, но и кого-то другого, и было бы неплохо поделиться им. Но Вы все еще работаете над своей задачей, а отвлекаться нет желания… В таком случае, будет проще всего забрать Ваш 1 коммит в другую ветку и экстренно вмержить его в рабочую(фризную ветку). Как это сделать?

Готово:

Заключение

В заключении хотелось бы сразу вспомнить вечный холивар на тему: терминал или GUI редактор для работы с VCS? Тут дело вкусовщины. Понятно дело, что CLI GIT-а более мощный инструмент и для спецефичных задач без него никуда. Но для ежедневных задач встроенный пакет утилит для работы с системами контроля версий в AS — просто must have и сократит время разработки в разы. Надеюсь, что Вы нашли что-то новое в этой статье и помог облегчить Ваши трудовые будни.

Автор: Илья Павловский

Источник