[Перевод] Советы по организации работы c Git
Как обычно используют 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-bisect1, потому что если вы ожидаете, что код скомпилируется и успешно пройдёт тесты для каждого коммита, то вы можете передать 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 — это инструмент, который выполняет двоичный поиск между двумя коммитами в вашей истории, просматривая коммиты между ними по одному, чтобы вы могли проверить наличие ошибки. Таким образом можно вычислить коммит, который вызвал проблему. ↑
