ПШЕ 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"

А можно ускорить процесс:


git-amend-commit

Edit commit message

Допустим, Вы создали большой PR с большим количеством коммитов, да перед пушем заметили, что одно из сообщений некорректно и было бы неплохо его отредактировать, пока жесткий ревьювер не четвертовал Вас за такую оплошность:


git-amend-commit

Interactive rebase

Я боюсь представить выполнение одной из недавних задач по рефакторингу без знаний использования этого инструмента. Проблема заключалась в том, что мне нужно было отрефакторить N файлов. Каждое изменение следовало делать отдельным коммитом, чтобы не собирать большую пачку в одну кучку и была возможность отдельного форсирования каждого из файлов/коммитов в будущем.
Пачка была быстро собрана, коммиты получились хаотичные, да еще и на ревью получил порцию исправлений… Окей, не проблема.

Проверяем отставание наших изменений от ветки, в которую мы хотим вливаться.

//Покажет хеши и коммит мессаджи
git cherry master -v 
// Подсчитает нам количество отставших коммитов
git cherry master | wc -l 

Либо через GUIню:


git-rebase-1

Дальше скачем в tools:


git-rebase-1

Указываем количество коммитов, которые хотим отредактировать:


git-rebase-2

Или сразу укажем таргeт ветку:


git-rebase-3

Дальше определяемся что нам нужно сделать:


git-rebase-3

И редактируем:


git-rebase-3

Подробнее про команды:

# Commands:
#  p, pick = использовать коммит(оставить при своем)
#  r, reword = использовать коммит, но отредактировать его сообщение
#  e, edit = редактирование коммита, без возможности amend-а(без слияния)
#  s, squash = слить с предыдущим коммитом с возможностью редактирования итогового сообщения
#  f, fixup = аналог сквоша,без возможности редактирования сообщения(отбросит сообщение коммита который сливаем)

Коммиты отредактированы, осталось только подлить все на ремут сервер. Но ведь история изменена? И хэши явно не совпадают с тем, что находится на удаленной ветке.


git-rebase-3

Force push перезатрет нашу историю и примет новые изменения как родные.


Multiple remotes

Скорее всего это лишнее, но, исходя из моей практики, далеко не все обращают внимание на эту фичу.


git-push-multiple-remotes

Что это? В случае работы в 2 и более ремут хранилищах (актуально, когда доступ в основное хранилище по прямому запросу закрыт), быстрое переключение между удаленным ветками для пушей/пулов тоже упрощен:


git-push-multiple-remotes

Git blame

Полезный трюк для просмотра автора внесенных изменений:


git-rebase-3

Теперь про более эффективную работу. Если Вы не поленились и внесли правила ведения коммитов в Вашем проекте, стоит включть IssueNavigationLink:

//Пример паттерна формирования коммит мессаджа
-: 

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


git-issue-nav-link-1

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


    
    

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


git-issue-nav-link-2

Git cherry-pick

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


git-issue-nav-link-2
git-issue-nav-link-2

Готово:


git-issue-nav-link-2

Заключение

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


© Habrahabr.ru