День в настоящей команде

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

git switch main
git pull --ff-only            # перемотать main к origin/main, отказать если разошлись
git switch -c feat/checkout-coupons origin/main

--ff-only — это страховочный ремень: если твой локальный main каким-то образом содержит коммиты, которых нет в origin/main, pull откажет вместо тихого создания merge-коммита. Ветка, названная по своей цели (feat/checkout-coupons), — это то, что унаследуют PR и итоговый squash-коммит.

Делай работу маленькими, атомарными коммитами — каждый цельный, обратимый шаг. Коммит должен собираться и рассказывать одну историю. Стейдж осознанно и пиши настоящее сообщение:

git add -p                    # стейдж по кускам, а не всё дерево вслепую
git commit -m "Validate coupon code before applying discount"
# ... ещё работа ...
git commit -m "Add expired-coupon error path + test"

Атомарные коммиты — не бюрократия: они делают возможными git revert, git bisect и код-ревью. Ревьюер читает последовательность ясных шагов; единый коммит «wip» на 600 строк не ревьюется.

Оставайся актуальным через rebase на origin/main — не давай ветке дрейфовать. Пока ты работаешь, коллеги мёржат в main. Ветка, разошедшаяся на дни, превращается в кошмар при слиянии. Подтягивай их работу под свою, чтобы твои коммиты всегда лежали поверх свежего ствола:

git fetch origin
git rebase origin/main        # переиграть твои коммиты поверх свежего main
# разреши конфликты сейчас, пока они маленькие, затем:
git rebase --continue

Rebase держит историю линейной и поднимает конфликты рано и маленькими порциями, вместо одного гигантского столкновения в момент слияния. Делай это хотя бы раз в день на живой ветке.

Push, открой PR и правь ревью через fixup + force-with-lease. Опубликуй ветку, открой pull request и дай CI отработать. Когда придёт ревью, не громозди сверху коммиты «учёл замечания» — вкладывай правки в тот коммит, которому они принадлежат:

git push -u origin feat/checkout-coupons      # первая публикация, ставит upstream
# ревью просит изменить коммит с валидацией:
git add -p
git commit --fixup=<sha-коммита-валидации>
git rebase -i --autosquash origin/main        # autosquash вставит fixup на место
git push --force-with-lease                    # безопасный force: откажет, если remote сдвинулся

--force-with-lease — это деталь, по которой нельзя торговаться: обычный --force затёр бы любой коммит, который коллега запушил в твою ветку с момента твоего последнего fetch. --force-with-lease проверяет, что remote всё ещё там, где ты думаешь, и иначе прерывается.

Когда CI зелёный и ревью одобрено — squash-merge и возврат к чистому main. Большинство trunk-based команд схлопывают ветку в один коммит на main — грязные промежуточные шаги ветки сворачиваются в одну чистую запись с заголовком по PR. Затем синхронизация и зачистка:

# слияние через кнопку PR «Squash and merge» (или gh pr merge --squash)
git switch main
git pull --ff-only            # принести новый squash-коммит в локальный main
git branch -d feat/checkout-coupons       # удалить локальную ветку (смёржена)
git push origin --delete feat/checkout-coupons   # удалить удалённую ветку

Цикл замкнут: main держит один аккуратный коммит, ни одна ветка не висит, и ты готов резать следующую фичу со свежей базы.