Привет, меня зовут Сергеев Сергей aka gurugray ^[1]. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

1. Используй свежее

Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.

> git --version
git version 2.27.0

2. Настрой инструмент

Настройте себе публичный email не аффилированный с текущей компанией. Это позволит вам тонко настраивать идентификацию под разные репозитории и не задумываться о настройках по умолчанию, а GitHub будет показывать вашу активность, даже если вы смените место работы.

> git config --global user.email "gurugray@yandex.ru"

> cd company_project
> git config user.email "gurugray@manychat.com"

Если вы не пользуетесь консолью и vim'ом для редактирования, то вам стоит настроить и ваш редактор:

> git config --global core.editor "code --wait"

3. Настрой autocomplete

В моей практике не часто встречается разработчик, который не настраивал автокомплит если работал в консоли. Однако если вы переходите с другого инструмента, отсутствие этой функциональности сильно вас затормозит.

Git из коробки предоставляет набор скриптов ^[2] для автокомплита, но если ваш shell, как у меня ^[3], более экзотичен — найдите и поставьте автокомплит именно для него.

4. Ускоряй часто используемое

Настройте себе псевдонимы ^[4] (aliases) для быстрой работы. Для каждого человека удобство ощущается по-разному и я не рекомендую увлекаться однобуквенными псевдонимами, особенно если вы часто работаете на других рабочих станциях или используете ssh для удалённой работы на серверах — вам либо придётся тратить время на борьбу с различиями, либо растаскивать свой файл настроек по всем машинам (что не всегда плохо, конечно). Также не старайтесь заменить псевдонимами любое сочетание команд — половину вы забудете, а к половине привыкните более, чем оно того заслуживает.

Я перешёл на Git с SVN, потому для меня базовые псевдонимы перекочевали оттуда, а "b" — единственный однобуквенный псевдоним.

> git config --global alias.st "status -sb"
> git config --global alias.co "checkout"
> git config --global alias.ci "commit -a"
> git config --global alias.b "branch"

5. Обзорность помогает решать проблемы

Я часто работаю с историей проекта — нужно понять, что и когда влилось, и какие состояния проекта этому предшествовали. Часто важно знать последовательность комитов и топологию дерева истории. Git из коробки помогает показать дерево истории проекта:

> git log --oneline --graph --branches

Но для полноты картины хочется видеть и авторов, и даты и в удобной расцветке, потому мой псевдоним выглядит не так дружелюбно с параметром --pretty=format::

> git log --graph --date=short --branches --pretty=format:'%C(yellow)%h%C(reset) %ad | %C(75)%s%C(reset) %C(yellow)%d%C(reset) [%an]'

6. Следуй протоколу

Всегда клонируйте репозиторий, в который вносите правки по git+ssh протоколу ^[5], это работает быстрее чем по http и сэкономит время в процессе работы:

> git clone git@github.com:gurugray/gurugray

7. Разделяй источники

Если вы работаете с репозиториями по «форковой» модели ^[6] (когда к основному репозиторию есть доступ только на чтение, а все pull-request'ы подаются из форка) называйте основной репозиторий upstream это поможет не путаться в командах отведения веток и push'а в свой origin. Не забывайте про протокол, если репозиторий открыт только для чтения, то его можно клонировать без ssh-слоя, что тоже даст экономию времени в процессе работы:

> git clone git://github.com/gurugray/gurugray -o upstream

8. Контролируй процесс

Не используйте команду pull, это составная команда и делает несколько действий сразу. Часто при работе с репозиторием новички допускают ошибку не понимая, как эта команда обновляет текущую ветку, и замусоривают свою историю или неправильно работают с дефолтной веткой. Я рекомендую явно обновлять репозиторий локально, затем явно обновлять свою ветку:

> git fetch --all
> git rebase my_feature upstram/master

9. Не вводи себя в заблуждение

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

> git fetch --all
> git checkout -b my_feature upstream/master

> git branch -D master

10. Не бойся исправлять

Если вы следите за чистотой истории и хотите исправить состояние проекта зафиксированное несколько комитов назад, то достаточно закомититься с параметром --fixup= и передать нужный хэш комита для последующего причёсывания истории

> git commit -m "Feature A is done"
> ...
> git commit -m "Feature B is done"
> git commit --fixup=fe2f857

> git log --oneline
a5050e7 fixup! Feature A is done
633e33f Feature B is done
...
fe2f857 Feature A is done
cb5db88 Previous commit

11. Не бойся быстро исправлять

Один из полезных псевдонимов — замена последнего комита текущим состоянием, позволяет «подклеить» текущее состояние к последнему зафиксированному, при этом не включая режим редактирования сообщения:

> git config --global alias.fixlast "commit --all --amend --no-edit"

12. Перебазируй

Научитесь и пользуйтесь командой rebase в интерактивном режиме и с параметром --autosquash с которым использование --fixup будет ещё более удобным, а сам ребейз помогает причёсывать историю и аккуратно оформить комиты, например по принятым у вас guidline'ам ^[7], до подачи pull-request'а для успешного его принятия.

> git rebase -i --autosquash cb5db88
pick fe2f857 Feature A is done
fixup a5050e7 fixup! Feature A is done
pick 733e2ff Feature B is done

> git log --oneline
633e33f Feature B is done
...
5778cbb Feature A is done
cb5db88 Previous commit

13. Сбрасывай ненужное

Научитесь и пользуйтесь командой reset ^[8] она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью:

> git reset @~4
> git commit --all

14. Контролируй деструктивный push

Если вы хотите запушить изменённую историю, советую использовать полный синаксис команды и не использовать ключ --force -f, это позволит не привыкать к настройкам по-умолчанию и не приведёт к случайным перетираниям истории на сервере:

> git push origin +feature

15. Помни про летописца

Не забывайте про reflog эта команда поможет разобраться с проблемами в локальном репозитории если что-то пошло не так ^[9] — спасательный круг для новичков, к которому они редко подходят:

> git reflog
> ...
> git reset --hard FOUND_HASH

Все советы выше помогут быстрее работать с репозиторием и быстрее получать ответы об истории разработки поиска ошибок и выявления узких мест в регламенте работы, но эта тема для отдельной статьи.

Есть ещё много возможностей для тонкой настройки Git'а под себя и для решения более специфичных кейсов, но описанные выше возможности инструмента позволяют вам каждый день удобно работать не теряя в скорости.

Автор: Сергеев Сергей

Источник ^[10]