Как обычно используют git? Пара базовых команд, чтобы «всех синхронизировать». Разочарование от git часто возникает у тех, кто никогда не выходит за пределы этого поверхностного понимания. Однако освоение git наверняка окупится. Сколько времени вы тратите на использование git? Я бы предположил, что на вашем поясе немало инструментов, которые вы используете вдвое реже и потратили вдвое больше времени на изучение.

Если хотите больше узнать о git, предлагаю начать с главы 10 книги Pro Git (это бесплатно!), затем главы 2, 3 и 7. Остальное необязательно. В этой статье мы обсудим, как применить описанные в книге инструменты для дисциплинированной и продуктивной работы в git.

Основы: хорошие описания коммита

Возможно, вы слышали это раньше, но потерпи́те. Как правило, не нужно использовать git commit -m "ваше сообщение здесь". Начните с настройки git для использования любимого редактора: git config --global core.editor vim, затем просто запустите git commit. Откроется редактор, и вы сможете написать в нём своё описание коммита. Первую строку следует ограничить длиной 50 символов и завершить предложением: после применения этот коммит... «исправит рендеринг текста на языках CJK», «добавит поддержку протокола v3», «отрефакторит обработку CRTC» и т. д. Затем добавьте одну пустую строку и переходите к расширенному описанию коммита, которое должно быть жёстко отформатировано в 72 столбца и включать такие детали, как обоснование коммита, компромиссы, ограничения подхода и т. д.

Мы используем 72 символа, потому что это стандартная ширина сообщения электронной почты, а электронная почта — важный инструмент для git. Ограничение в 50 символов используется, потому что первая строка становится темой вашей электронной почты, и в начало можно добавить много текста вроде “[PATCH linux-usb v2 0/13]”. Вы можете найти такие ограничения форматирования раздражающими и обременительными, но учтите, что другие читают логи не в том же контексте, что и вы. Я часто читаю логи коммитов на вертикальном мониторе, и он не втиснет в одну строку столько текста, сколько ваш дисплей 4K 16:9.

Каждый коммит должен быть автономным изменением

Каждый коммит должен содержать только одно изменение — избегайте небольших несвязанных изменений в одном коммите (в этом отношении я мог бы почаще прислушиваться к собственным советам). Кроме того, избегайте разбиения одного изменения на несколько коммитов, если только идея не разбивается на отдельные шаги, каждый из которых представляет собой полноценное изменение. Если в вашем рабочем дереве несколько изменений и вам нужно зафиксировать только некоторые из них, попробуйте git add -i или git add -p. Кроме того, каждый коммит должен компилироваться, успешно проходить все тесты и избегать известных багов, которые будут исправлены в будущих коммитах.

Теперь можно взять любой коммит и ожидать, что код будет работать правильно. Это пригодится и позже, например, в процессе выборочного включения коммитов в ветку релиза. Такой подход также повышает полезность git-bisect¹, потому что если вы ожидаете, что код скомпилируется и успешно пройдёт тесты для каждого коммита, то вы можете передать git-bisect скрипт, который программно проверяет дерево на наличие ошибки и избежит ложных срабатываний. Эти автономные коммиты с хорошими описаниями упростят подготовку описаний релиза с помощью git-shortlog, как это делает Линус с релизами Linux.

Трудно сделать всё правильно с первого раза

Мы подходим к одной из самых важных особенностей git, которая отличает его от своих предшественников: редактирование истории. Все системы управления версиями поставляются с какой-то «машиной времени», но раньше они были в основном доступны только для чтения. Однако машина времени git отличается: вы можете изменить прошлое. На самом деле вас даже поощряют делать это! Но предупреждаю: изменяйте только то прошлое, которое ещё не вошло в стабильную публичную ветку.

Суть в следующем. Писать коммиты без ошибок, автономные коммиты с хорошим описанием — трудно с первой попытки. Редактировать историю, наоборот, легко, и это часть эффективного рабочего процесса git. Ознакомьтесь с git-rebase и свободно его используйте. Можете использовать rebase для изменения порядка, объединения, удаления, редактирования и разделения коммитов. Например, я обычно вношу некоторые изменения в файл, отправляю fixup-коммит (git commit -m fixup), а затем использую git rebase -i, чтобы влить его в более ранний коммит.

Различные советы

• Читайте маны! Выберите случайную страницу git man и прочитайте её сейчас. Кроме того, если вы не читали страницу git man верхнего уровня (просто man git), сделайте это.
  
• В нижней части каждого мана для команды git высокого уровня обычно находится список команд git низкого уровня, на которые опирается команда высокого уровня. Если хотите узнать больше о том, как работает команда git высокого уровня, попробуйте прочитать эти справочные страницы.
  
• Узнайте, как выбирать нужные коммиты с помощью rev selection.
  
• Ветки полезны, но вы должны научиться работать без них, а также иметь хороший набор инструментов на поясе. Используйте команды вроде git pull --rebase, git send-email -1 HEAD~2 и git push origin HEAD~2:master.

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