Git и командная работа

Коммит хранит снимок всего проекта вместе с родительскими коммитами, автором и сообщением, и идентифицируется хешем от всего этого. Ветка представляет собой подвижное имя, указывающее на один коммит, а HEAD отмечает то, что у вас сейчас извлечено, обычно ветку. Коммит хранит всё дерево, а не дифф, и его хеш покрывает ещё и родителей, поэтому изменение старого коммита меняет все хеши после него: вот почему переписывание запушенной истории создаёт проблемы. Ветка всего лишь указатель: ref в .git/refs/heads/ с одним хешем, который каждый новый коммит сдвигает вперёд, поэтому ветка создаётся мгновенно. **HEAD** обычно содержит ref: refs/heads/main, поэтому новый коммит двигает эту ветку. Detached HEAD: HEAD хранит хеш коммита напрямую, после git checkout v1.4.0 или во время rebase и bisect. Коммиты, сделанные в этом состоянии, не принадлежат ни одной ветке: перед переключением выполните git switch -c fix/login или найдите их потом в git reflog.

git fetch скачивает новые коммиты и сдвигает ветки удалённого отслеживания вроде origin/main, но никогда не трогает вашу ветку и ваши файлы. git pull выполняет fetch, а затем merge (или rebase) вышестоящей ветки в текущую. Fetch всегда безопасен: выполните его, а затем git log main..origin/main, чтобы увидеть, что пришло, до того как это вливать. Обычный pull делает merge: если новые коммиты есть у обеих сторон, появляется коммит «Merge branch 'main' of …», который ничего не говорит о работе. **git pull --rebase** переигрывает ваши незапушенные коммиты поверх скачанных и сохраняет историю прямой; git config --global pull.rebase true делает это поведением по умолчанию. Ветки разошлись, а настройка не задана: современный Git останавливается с fatal: Need to specify how to reconcile divergent branches., пока вы не выберете pull.rebase или pull.ff only.

Merge соединяет две истории merge-коммитом и оставляет все существующие коммиты как есть. Rebase переигрывает ваши коммиты поверх другой ветки как новые коммиты с новыми хешами, и история получается прямой, поэтому rebase коммитов, которые уже есть у других, ломает их копии. Fast-forward: если main не сдвинулся с момента ответвления, merge просто передвигает метку main на ваш последний коммит; --no-ff создаёт merge-коммит принудительно, чтобы фича осталась видна как единое целое. Merge сохраняет настоящую историю и безопасен для общих веток; цена в графе, полном merge-коммитов. Rebase даёт линейный лог, который проще читать и по которому проще делать bisect; конфликты приходят по одному коммиту. Золотое правило: делайте rebase только тех коммитов, на которых никто больше не строит работу. Если сделать rebase и force-push ветки, которую коллега уже спулил, его старые коммиты и ваши новые станут двумя копиями одной работы.

Откройте каждый файл с конфликтом, поймите, что хотела каждая сторона, напишите версию, которая сохраняет оба намерения, и удалите маркеры. Затем соберите проект, прогоните тесты, выполните git add и завершите git commit или git rebase --continue; если запутались, git merge --abort вернёт всё как было. Смотрите на обе стороны и на базу: git status помечает файлы с конфликтом как UU, а git config --global merge.conflictStyle zdiff3 добавляет между сторонами исходный текст, и видно, что изменила каждая сторона. Разрешайте по смыслу: если одна сторона переименовала метод, а другая добавила его вызов, в результате нужно и то, и другое. Проверьте до коммита: запустите сборку и тесты, потому что код может компилироваться и всё равно быть смержен неправильно; git diff --check сообщает о каждом leftover conflict marker. Никогда не коммитьте маркеры, не оставляйте оба блока вслепую (две копии одного метода или импорта), не берите целиком одну сторону через --ours или --theirs, лишь бы конфликт исчез, и не мержите руками Package.resolved: его нужно сгенерировать заново.

git stash откладывает незакоммиченные изменения и оставляет чистую рабочую копию; git stash pop возвращает их обратно. git cherry-pick <sha> копирует изменение одного коммита в текущую ветку новым коммитом с новым хешем. git stash Новые файлы остаются на месте: обычный git stash сохраняет только отслеживаемые изменения; git stash -u захватывает и неотслеживаемые файлы. Локальны и легко забываются: стэши никогда не пушатся; давайте им имена (git stash push -m "wip: cart badge") и заглядывайте в git stash list. **pop может дать конфликт**: тогда Git оставляет запись, и после разрешения её удаляют через git stash drop; для долгого отвлечения надёжнее WIP-коммит. git cherry-pick Типичный сценарий: перенести фикс из main в release/1.4; -x записывает в сообщение «(cherry picked from commit …)». Одно изменение дважды: у копии другой хеш, поэтому последующий merge видит два коммита и даёт конфликт, если код вокруг них изменился.

.gitignore лишь не даёт добавить неотслеживаемые файлы; файл, который Git уже отслеживает, остаётся отслеживаемым, что бы ни говорили шаблоны. Уберите его из индекса через git rm --cached и закоммитьте это: файл останется у вас на диске, но уйдёт из репозитория. Шаблоны отсчитываются от того .gitignore, в котором записаны: /build/ совпадает только на этом уровне, build/ на любой глубине, а ! возвращает путь обратно; git check-ignore -v <path> называет сработавшую строку. iOS-проект игнорирует xcuserdata/ (состояние конкретного пользователя и личные схемы), .build/ от SwiftPM, DerivedData/, Pods/ в большинстве команд, отчёты и скриншоты fastlane и все файлы подписи: .p12, .mobileprovision, AuthKey_*.p8. В git остаются .xcodeproj (если его не генерируют Tuist или XcodeGen), xcshareddata/ с общими схемами, которые собирает CI, Package.resolved и Podfile.lock. **Ловушка после git rm --cached**: коллеги, которые спулят этот коммит, лишатся своей копии файла, и для конфига, заполненного вручную, это болезненно, так что предупредите их заранее.

В project.pbxproj оставьте записи обеих сторон (каждый добавленный файл встречается в нескольких секциях) и проверьте, что файл читается и проект собирается. Package.resolved создаёт резолвер: возьмите копию из main и разрешите заново. Большинство таких конфликтов предотвращают папки Xcode 16 или генерация проекта. Почему конфликты так часты: добавление одного файла пишет PBXFileReference, PBXBuildFile, строку в children его группы и строку в build phase таргета, и всё это в файле, который правит вся команда. Как разрешать: обычно обе стороны добавили разные файлы, поэтому оставьте оба блока в каждой секции; 24-символьные идентификаторы объектов практически никогда не пересекаются. Если обе стороны поменяли одну настройку сборки, выбирайте по смыслу. Докажите, что файл корректен: plutil -lint по этому файлу падает на оставшемся маркере или потерянной скобке; затем соберите проект, потому что повреждённый проект Xcode открыть откажется. **Не merge=union**: union-драйвер в .gitattributes сохраняет и обе версии изменённой строки, и поломка всплывает позже. **Package.resolved**: во время merge git checkout --theirs берёт версию из main (в rebase стороны меняются местами), затем xcodebuild -resolvePackageDependencies или File > Packages > Resolve Package Versions; дифф относительно main должен показывать только ваши новые пины. Профилактика: buildable folders из Xcode 16 (PBXFileSystemSynchronizedRootGroup) ссылаются на папку, а не на каждый файл, и Convert to Folder переводит существующую группу; код фич в локальных Swift-пакетах не попадает в списки файлов проекта; Tuist или XcodeGen убирают проект из git совсем.

A, B и C сдвигают main обратно на b2 и отличаются только тем, куда попадает изменение из c3: в индекс, в рабочую копию или никуда. D добавляет новый коммит, отменяющий c3, и ничего не переписывает, поэтому для запушенной ветки безопасен только git revert. **A, --soft**: лог заканчивается на b2, а git status показывает modified: Sources/Networking/APIClient.swift в разделе «Changes to be committed». Удобно, чтобы склеить последние коммиты. **B, --mixed**: лог заканчивается на b2, а то же изменение лежит в разделе «Changes not staged for commit». Удобно, чтобы разбить коммит. **C, --hard**: лог заканчивается на b2, рабочая копия чистая; о c3 помнит только git reflog, а незакоммиченные правки, которые стирает --hard, теряются навсегда. **D, revert**: в логе Revert "Add retry", c3, b2, a1; файлы совпадают с b2, а коллегам достаточно сделать pull. A, B или C на запушенной ветке: git status пишет «Your branch is behind 'origin/main' by 1 commit», а git push отклоняется как non-fast-forward; форс-пуш выдернет c3 из-под всех, у кого он уже есть. **git restore работает с файлами, а не с историей**: git restore <file> отбрасывает незакоммиченные правки, --staged убирает файл из индекса, а --source=b2 <file> возвращает старую версию одного файла, не сдвигая ветку.

git rebase -i origin/main показывает список коммитов ветки; если заменить pick на squash, fixup, reword или drop или переставить строки, коммиты перепишутся в историю, которую приятно читать. Переписанной ветке нужен форс-пуш, и --force-with-lease откажет, если кто-то успел запушить в неё. Команды: reword правит сообщение, edit останавливается, чтобы дополнить или разбить коммит, squash вливает коммит в предыдущий и сохраняет оба сообщения, fixup вливает и отбрасывает сообщение, drop удаляет коммит. Фиксапы по ходу работы: git commit --fixup=<sha>, а затем --autosquash ставит каждый фиксап под его цель. **--force перезаписывает вслепую: коммит, который коллега час назад запушил в ветку, исчезает. --force-with-lease** пушит, только если удалённая ветка там, где её видел ваш последний fetch; иначе ! [rejected] … (stale info). Слабое место: фоновый fetch из IDE обновляет origin/feature, и проверка всё равно проходит; --force-if-includes (Git 2.30+) дополнительно требует, чтобы удалённая вершина входила в вашу историю. Только своя ветка: переписывание main или общей ветки нарушает золотое правило с любым флагом.

Reset или rebase не удаляет коммиты, а лишь перестаёт на них указывать. git reflog перечисляет все позиции, в которых побывал HEAD, поэтому нужно найти хеш до аварии и вернуть на него ветку через git reset --hard <sha> или git branch rescue <sha>. Читайте сверху вниз: HEAD@{0} означает текущее состояние; нужное состояние записано в строке сразу под reset: moving to HEAD~2 или сразу под строкой rebase (start). У каждой ветки свой reflog: git reflog show feature/search, где feature/search@{1} означает предыдущую вершину ветки. Сразу после rebase или reset всё отменяет git reset --hard ORIG_HEAD. Не уверены? git branch rescue <sha> закрепит коммит под именем, прежде чем вы начнёте осматриваться. Что вернуть нельзя: правки, которые ни разу не коммитились и не попадали в стэш, потому что reset --hard их перезаписывает; файлы из индекса живут только как висячие объекты, которые иногда находит git fsck --lost-found. Локален и устаревает: reflog нет ни на сервере, ни в свежем клоне; по умолчанию недостижимые записи истекают через 30 дней (остальные через 90), и после этого git gc может удалить сами коммиты.

Вы помечаете один коммит плохим, а более старый хорошим, и Git ищет делением пополам среди коммитов между ними: извлекает средний, вы проверяете его и отвечаете good или bad, и диапазон сокращается вдвое, пока не останется один коммит. Тысяча коммитов укладывается примерно в десять шагов. Начало и конец: git bisect start, git bisect bad, git bisect good v1.4.0; git bisect reset возвращает туда, откуда вы начали. **git bisect run <cmd> отвечает за вас: код выхода 0 означает good, от 1 до 127 означает bad, а 125 значит «этот коммит проверить нельзя, пропусти». Сначала напишите проверку: тест, который падает на этом баге, и оставьте его неотслеживаемым, потому что checkout не трогает неотслеживаемые файлы. Пропускайте то, что не собирается, кодом 125, иначе bisect обвинит коммит, который просто не скомпилировался. Старые коммиты, старые зависимости**: xcodebuild разрешает собственный Package.resolved каждого коммита, а коммит, которому нужен другой Xcode, пропускается, а не помечается плохим. **git bisect start --first-parent** идёт только по собственным коммитам main и называет влитый pull request, который всё сломал. Нестабильные тесты всё портят: один неверный ответ уводит поиск не в ту половину.

Хорошее сообщение коротким заголовком в повелительном наклонении говорит, что делает коммит, а в теле объясняет зачем. Conventional Commits добавляют машиночитаемый префикс (feat:, fix:, feat!:), чтобы инструмент сам выбрал следующую семантическую версию и собрал changelog прямо из истории. Заголовок: около 50 символов, повелительное наклонение («Add retry to upload», а не «Added»), без точки в конце. После пустой строки тело с переносом на 72 символах, где объяснена причина; что изменилось, и так видно в диффе. Одно логическое изменение на коммит, чтобы его можно было откатить или перенести через cherry-pick отдельно. Формат: type(scope): description, с типами вроде feat, fix, refactor, perf, test, docs, ci и chore. Связь с semver: fix поднимает patch, feat поднимает minor, а ! после типа или футер BREAKING CHANGE: поднимает major. Инструменты: release-please или semantic-release превращают историю в changelog и тег. Маркетинговую версию приложения всё равно решает продуктовая команда, но сгенерированные заметки становятся текстом обновления в TestFlight и App Store. При squash-мерже коммитом в main становится заголовок pull request, поэтому проверяйте заголовки PR в CI; хук commit-msg с commitlint ловит остальное локально.

Хороший pull request делает одну вещь, читается за один присест и объясняет, зачем он нужен и как проверен. Хорошее ревью сначала проверяет поведение и дизайн, оставляет форматирование инструментам и помечает, насколько важен каждый комментарий. Как автор Маленький и об одном: несколько сотен изменённых строк; рефакторинг, переименование и фича идут отдельными pull request, чтобы каждый можно было отревьюить и откатить отдельно. Описание: что и зачем, как проверено, в чём вы не уверены, скриншоты или запись с симулятора для изменений UI, в светлой и тёмной теме и ссылка на задачу. Сначала просмотрите свой дифф сами: забытые логи и закомментированный код ловить вам. Как ревьюер В таком порядке: делает ли код то, что просит задача, что ломается (граничные случаи, ошибки, конкурентность), вписывается ли он в архитектуру, упадёт ли тест без этого изменения; имена и стиль идут последними или остаются линтеру. Помечайте вес: blocking:, suggestion:, nit:, и одобряйте с комментариями, когда остались только мелочи. Спрашивайте, а не приказывайте: «Что будет здесь, если запрос упадёт по таймауту?» учит больше, чем переписанный кусок кода. Когда вы не согласны Отвечайте на каждый комментарий: исправлено или причина; после двух кругов поговорите пять минут или позовите техлида, а решение запишите в треде.

GitFlow держит долгоживущие develop и main, а также ветки release и hotfix, и рассчитан на плановые релизы с версиями. GitHub flow означает короткие ветки от main, которые вливаются через PR и выкатываются. Trunk-based идёт дальше: ветки живут день-два, а недоделанное прячется за флагами. GitFlow: feature/* от develop, release/* замораживается для тестирования, hotfix/* от main и вливается обратно в обе ветки. Подходит для нескольких крупных релизов в год, в остальных случаях тяжёл, а develop уходит от того, что стоит у пользователей. GitHub flow: каждое изменение идёт через pull request с ревью в main и выпускается оттуда же; нужен CI, достаточно хороший, чтобы main всегда можно было выпустить. Trunk-based: то же, но ветки живут от нескольких часов до пары дней, а всё неготовое закрыто фича-флагами; мержей больше всего, конфликты мельче всего. Релизные ветки под ревью App Store: приложение нельзя передеплоить за минуты, поэтому от main отрезают release/4.3, когда сборка уходит на ревью, переносят в неё фиксы через cherry-pick с -x и ставят тег на каждую отправленную сборку (v4.3.0), чтобы хотфикс начинался с того, что реально стоит у пользователей. Как выбирать: по частоте релизов и цене сломанного релиза; большинство команд приходит к trunk-based плюс короткоживущие релизные ветки.

Pre-commit хук должен запускать быстрые самоисправляющие проверки только по застейдженным файлам, например форматтер и быстрый линт. Настоящей проверкой остаётся CI, потому что хуки не клонируются вместе с репозиторием, а git commit --no-verify пропускает их намеренно. Почему хук ничего не гарантирует: .git/hooks/ локален и никогда не пушится, так что в свежем клоне хуков нет, пока их кто-нибудь не установит; проверка, которая обязана выполняться, живёт в CI и в защите веток. Общая настройка: закоммитьте lefthook.yml (или .pre-commit-config.yaml, или папку .githooks/ вместе с git config core.hooksPath .githooks) и устанавливайте его из скрипта настройки проекта. Что туда идёт: SwiftFormat и SwiftLint по застейдженным .swift-файлам; секунды, а не минуты, иначе люди начнут тянуться к --no-verify. Добавляйте в индекс то, что исправил хук: если форматтер переписал файлы после git add, в коммит уйдёт неотформатированная версия; в lefthook их добавляет обратно stage_fixed: true. Что остаётся за бортом: сборку, тесты и всё, что требует симулятора, берёт на себя CI. Другие хуки: commit-msg может проверять формат Conventional Commits, а pre-push запускать быстрые юнит-тесты.

Сначала отзовите секрет и выпустите новый, потому что он уже в истории, во всех клонах и форках, а новый коммит прячет его только из последней версии. Затем, если старое значение тоже должно исчезнуть, перепишите историю через git filter-repo и сделайте форс-пуш. Первый час Сначала замена, потом расследование: отзовите ключ App Store Connect API в App Store Connect, выкатите замену и проверьте по логам доступа, не пользовался ли им кто-то после пуша. Почему нового коммита мало: все старые коммиты по-прежнему содержат значение, боты сканируют публичные пуши в течение минут, а в приватном репозитории копия есть у каждого человека, CI-раннера и интеграции с правом чтения. Чистка истории Переписывание: в свежем клоне git filter-repo --sensitive-data-removal --invert-paths --path fastlane/AuthKey_ABC123XYZ9.p8 убирает файл из всех коммитов (--replace-text вместо этого заменяет строку), а git push --force --mirror origin перезаписывает сервер; защиту веток на это время придётся ослабить. Чего это стоит: меняются хеши всех последующих коммитов, ломаются открытые pull request, а коллегам нужно клонировать заново, потому что один пуш из старого клона вернёт секрет обратно. На GitHub ссылки pull request и кешированные страницы хранят старые коммиты, пока их не удалит поддержка GitHub, а у форков остаются свои копии. В следующий раз Ключи и сертификаты живут в хранилище секретов CI, в Keychain или в зашифрованном репозитории fastlane match, а значения для сборки в игнорируемом .xcconfig; в репозитории лежит файл-пример с именами без значений. Сканер секретов (gitleaks, trufflehog) в pre-commit хуке и в CI плюс push protection на стороне хостинга остановят следующий секрет до того, как он попадёт в репозиторий.

Revert отменяет изменения, но не историю: два коммита PR #42 по-прежнему в main, поэтому второй merge приносит только то, что появилось в ветке после, то есть один фикс. Чтобы вернуть фичу, откатите сам revert (git revert <revert-sha>), а затем влейте фикс. Что видит Git: база слияния main и ветки теперь равна старой вершине ветки, которая уже входит в main. От неё ветка изменила один файл, поэтому merge применяет одно изменение поверх main, из которого revert убрал всё остальное. Вывод выдаёт проблему: Merge made by the 'ort' strategy., а затем Sources/Cart/Cart.swift | 1 + для фичи из двух коммитов. Как исправить: откатить сам ревёрт-коммит (Git назовёт результат Reapply "Merge PR #42: discounts"), а затем влить ветку; на GitHub то же делает кнопка Revert в pull request с ревёртом. Если фикс трогает код, добавленный фичей, merge остановится с конфликтом (CONFLICT (modify/delete), если файл был новым), и проблема хотя бы будет заметна. **-m 1**: у merge-коммита два родителя, и -m 1 говорит revert сохранить сторону main; почти всегда нужно именно это. Revert всё равно правильный инструмент: в общем main он остаётся единственной отменой, которая ничего не переписывает. Ловушка в том, что сама отмена теперь тоже часть истории, поэтому запишите план в pull request с ревёртом.

Монорепозиторий выбирают, когда код меняется вместе: приложения делят дизайн-систему, API-клиент и модели, и один pull request должен обновить библиотеку и всех её пользователей сразу. Отдельные репозитории подходят частям со своими владельцами и циклами релизов ценой версионирования между ними. Что даёт монорепозиторий Атомарные изменения: ломающее изменение в общем пакете и его исправление во всех приложениях попадают в один pull request с одним ревью; никакой матрицы «приложение 2 всё ещё на core 1.4». Один набор инструментов и правил: одна версия Xcode, один конфиг SwiftLint и локальные Swift-пакеты, подключённые по пути, а не по версии. Чего он стоит CI должен собирать только изменённое, иначе каждый pull request гоняет всё: сопоставляйте изменённые пути (git diff --name-only origin/main...) с пакетами и тест-планами, которые они затрагивают. Владение: CODEOWNERS по папкам, чтобы код платежей ревьюила команда платежей. Масштаб и доступы: клон постоянно растёт (помогают git clone --filter=blob:none и sparse checkout), а права выдаются на репозиторий целиком, так что подрядчик видит всё. Независимые релизы усложняются: каждому пакету нужны свои теги (core-v1.4.0) и инструменты публикации. Чего стоят отдельные репозитории Каждое общее изменение означает публикацию, новую версию и pull request в каждом потребителе, а потребители расходятся по версиям. Они выигрывают для open-source пакетов, для кода с другим уровнем доступа и для команд, которые действительно выпускаются по своему графику.