K210.ORG

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 из коробки предоставляет набор скриптов для автокомплита, но если ваш shell, как у меня, более экзотичен — найдите и поставьте автокомплит именно для него.

 

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 протоколу, это работает быстрее чем по http и сэкономит время в процессе работы:

 

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

 

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

 

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

 

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

 

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

 

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

 

> git fetch --all
> git rebase my_feature upstream/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'ам, до подачи 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 она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью:

 

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

 

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

 

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

 

> git push origin +feature

 

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

 

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

 

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

 

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

 

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

отсюда