Готов спорить, что вы работаете с Git. Может, конечно, вы пользуетесь Subversion или какой-то другой системой контроля версий, но я знаю Git и писать буду о ней. Для кого-то из вас эта статья может показаться субъективной, но у меня есть мнение, и я хочу поделиться им в интернете! У Джейсона МакКрири есть несколько заметок про Git, в том числе статья, где он описывает суть git rebase лучше, чем я бы смог, даже если бы захотел. Почитайте.

Зачем нам Git?

  • Откат назад — потому что нам нужно иметь возможность спокойно отменить изменения, которые портят код.
  • Отслеживание изменений — потому что нам важно понимать, что требовалось, чтобы реализовать ту или иную функцию, или как один код связан с другим. Главным образом нам интересно, почему разработчик решил написать какой-то кусок кода именно так.

Естественно, у Git полно других функций, но для целей этой статьи достаточно этих двух.

Первые шаги

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

Первая случилась, когда я в течение нескольких дней работал над новым функционалом. У меня была привычка коммитить даже небольшие изменения кода, а потом сохранять незавершенную работу c пометкой WIP (work in progress) в конце дня. Не знаю, где был мой напарник, когда все пошло наперекосяк, но в какой-то момент я командой merge слил свою ветку с веткой master и отправил все изменения в удалённый репозиторий командой push.

Где-то через полчаса в чат повалились вопросы о том, что в мастере делают коммиты о слиянии и промежуточных изменениях. Было жутко неудобно. Но другой разработчик потом подсказал мне что нужно было делать: склеить коммиты с помощью команды squash и переместить изменения из одной ветки в другую командой rebase.

Вторая ошибка была ещё хуже. Я отправил в ветку master код, из-за которого что-то поломалось. Заметив это, я сразу понял, в чём проблема, и решил всё исправить. План был такой: исправить тесты и код, изменить коммит с помощью amend и отправить код обратно в ветку master (с помощью force push). На все про всё ушло минут пять, и я был уверен, что никто ни о чём не догадается. Естественно, очень скоро в чате снова случилась паника. Народ интересовался, почему не получается отправить изменения в master, если пару минут назад был сделан rebase. Опять пришлось сознаваться, что я накосячил.

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

Немного советов

Представьте, что вы работаете над новым функционалом в ветке, и вот вы готовы сделать запрос на внесение изменений (pull request) или каким-то другим способ отправить код на рассмотрение.

  • Перемещайте изменения с помощью rebase, чтобы ваша ветка всегда была актуальной. Полезно это делать часто, чтобы не пропустить последние коммиты ветки master. Запомните: это нужно делать до того, как вы создадите pull request или сольете изменения в ветку master. Я всегда ворчу, когда вижу pull request для ветки, которая на 3 коммита опережает и на 30 коммитов отстает от master.
  • Склеивайте много коммитов. По этому вопросу иногда спорят, а зря. Помните, что весь смысл коммитов в том, чтобы рассказывать последовательную историю (и чтобы была возможность легко откатиться назад, если что-то пойдет не так). Это значит, что в коммитах ветки master не должно быть префиксов WIP и комментариев типа «исправил ещё немного опечаток». Можете как угодно контролировать коммиты, пока работаете над веткой, но обязательно склеивайте их в один с помощью squash, прежде чем отправить в master. Я предпочитаю склеивать коммиты с помощью интерактивного режима команды rebase. Если вдруг вам придется откатить коммит, то иметь по одному коммиту на ветку будет очень удобно: вы сможете откатить всё, не разрушая ветку master, и не придется возиться со слиянием коммитов с помощью merge.
  • 50/72: В сообщении коммита 50 символов, в описании — ещё 72. Вот одна из тысячи статей о том, в чём логика правила 50/72. Множество инструментов создано с учётом того, что коммиты выглядят определённым образом. Инструменты настроены так, чтобы мне лишний раз не приходилось отвлекаться. Важное замечание: вы действительно должны добавлять комментарии к коммитам. Там достаточно места, чтобы объяснить, почему вы сделали тот или иной выбор, или написать что-нибудь полезное.
  • Уберите ваши отвратительные коммиты о слиянии из моей ветки master. Если вы соблюдали предыдущие рекомендации, то у вас будет чистенький и аккуратный pull request, который опережает ветку master. Нет никакого смысла делать коммиты merge. Если вы используете GitHub, тогда вы просто можете применить команды rebase и merge. Или, если вы любите рисковать, то можете просто слить свою ветку с master. Главное, учтите следующее: команда git merge my_branch даже не создаст коммита merge. Этим Git как бы говорит вам, что вы всё делаете правильно.

Выводы

«Сегодня код может понадобиться лишь раз, но его всегда должно быть легко изменить». Сэнди Метц.

Аудитория истории ваших коммитов в Git, как и самого вашего кода — это вы сами в будущем и ваши будущие коллеги. Упростите им жизнь. Мои рекомендации могут поначалу показаться неважными и утомительными, но к ним на самом деле очень легко привыкнуть. И польза от них намного перевешивает неудобства. Так что когда соберетесь сказать спасибо, просто создайте псевдоним git praise для команды git blame.

Перевод оригинальной статьи: «How I Git» by Andy Mention