Git и рабочий процесс

Система контроля версий как запись того, почему код именно такой, а не только способ обмениваться файлами. Ветвление, code review, слияния и умение выпутаться, когда что-то пошло не так.

Почему это важно. История — единственная документация, которая гарантированно останется через два года. Если git log отвечает на вопрос «почему здесь эта строка», загадка превращается в минуту работы; история из «fix», «fix2» и «wip» оставляет только догадки.

Что нужно понимать

• Что должно попадать в один коммит и почему это ровно одно изменение
• Что должно быть в сообщении — причина, а не пересказ диффа
• Что на самом деле происходит при merge и при rebase
• Как безопасно откатывать и какие операции переписывают общую историю
• Ради чего оптимизирована модель ветвления и ваша ли это задача вообще

Основные темы

Коммиты

• Одно логическое изменение, которое собирается само по себе
• Сообщения: первая строка, дописывающая фразу «этот коммит…», и тело с ответом на «почему»
• Разбиение изменений по частям через add -p
• amend и squash — пока ничего не ушло в общую ветку

Ветвление

• Trunk-based, GitHub flow, git flow — и выбор под частоту релизов
• Короткоживущие ветки и чем дороже обходятся долгие
• Как держать ветку актуальной: merge или rebase, и как договориться об одном правиле на команду
• Конфликты и их разрешение через понимание обеих сторон

Review

• Pull request'ы, достаточно небольшие, чтобы их действительно читали
• Что должно быть в описании
• Fixup-коммиты и обсуждение, за которым можно уследить

Когда всё пошло не так

• reflog — страховка, о которой большинство узнаёт слишком поздно
• revert против reset и что из этого безопасно в общей истории
• bisect, чтобы найти коммит, который что-то сломал
• stash, cherry-pick, worktree для параллельной работы

Гигиена

• .gitignore и правило никогда не коммитить секреты — история остаётся навсегда
• Большие файлы и почему репозиторий уже не уменьшится
• Теги и отметки релизов
• Хуки для проверок, которые нельзя пропускать

Уровни

Уровень	Как это выглядит
Junior	Коммитит, пушит, открывает pull request'ы, разрешает простые конфликты.
Middle	Собирает изменения в читаемые коммиты, уверенно делает rebase, пользуется reflog и bisect, пишет сообщения, объясняющие причину.
Senior	Задаёт команде модель ветвления и review, годами удерживает историю полезной и выходит из серьёзных ошибок, ничего не потеряв.

Практика

Для начала

• Разложите изменения по частям Разбейте сумбурное рабочее дерево на два связных коммита через git add -p.

• Напишите «почему» Возьмите пять своих последних сообщений и перепишите их так, чтобы они объясняли причину.

• Прочитайте историю Запустите git log -p на файле, который писали не вы, и восстановите его историю.

Глубже

• Найдите регрессию через bisect Найдите коммит, в котором появился баг, с помощью git bisect run.

• Перепишите до публикации Превратите ветку из пятнадцати сумбурных коммитов в четыре, которые рассказывают историю.

• Верните потерянное Удалите ветку, которая была нужна, и восстановите её через reflog.

Проверьте себя

• Ваше последнее сообщение коммита объясняет почему или только что?
• Соберётся и запустится ли код на любом коммите главной ветки?
• Что делать, если коммит ушёл не в ту ветку?
• Когда rebase небезопасен и почему?
• Как найти коммит, в котором баг появился три месяца назад?
• Попадал ли когда-нибудь секрет в ваш репозиторий — и лежит ли он там до сих пор?

Материалы

• Pro Git — та самая книга, бесплатная и полная. Главы 3 и 7 — те, после которых люди начинают работать иначе.
• How to Write a Git Commit Message — пост Криса Бимса и причина, по которой изрядная часть open source пишет в одном стиле.
• Oh Shit, Git!?! — рецепты восстановления ровно для тех ситуаций, в которых начинается паника. В закладки — заранее.
• Trunk Based Development — аргументы в пользу короткоживущих веток и честно разобранные компромиссы по сравнению с git flow.
• Git branching interactive tutorial — визуальная песочница. Самый быстрый способ действительно понять rebase, а не бояться его.