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

Короткий ответ Конфликт возникает, когда Git не может автоматически объединить изменения в одном и том же участке файла из двух веток; разрешение — открыть файл, выбрать нужные строки между маркерами <<<<<<</=======/>>>>>>>, убрать маркеры, протестировать результат и закоммитить его. Как это работает подробнее при merge/rebase Git построчно сравнивает версии файла относительно общего предка; если один и тот же диапазон строк изменён в обеих ветках по-разному, автоматическое слияние невозможно, и Git вставляет конфликтные маркеры. Пример кода Что использовать на практике Рекомендация. нужно открыть файл, понять смысл обеих версий, собрать корректный итоговый код, удалить все маркеры, прогнать тесты/линтер, затем git add <file> и git commit (для merge) или git rebase --continue. git status подсказывает, какие файлы ещё в конфликте. Подводные камни Риск. закоммитить файл, не удалив маркеры конфликта; слепо брать «свою» или «чужую» версию через git checkout --ours/-

Читать полностьюbranching

Короткий ответ Для 40 инженеров с несколькими параллельными релизами жизнеспособны и trunk-based с feature flags (минимизирует merge-боль, требует зрелой CI/CD), и схема с release-ветками на каждую поддерживаемую версию плюс строгий процесс cherry-pick hotfix'ов (даёт изоляцию релизов, но увеличивает нагрузку на слияние); выбор зависит от числа одновременно поддерживаемых в production версий. Как это работает подробнее trunk-based держит одну главную ветку, в которую непрерывно мержатся маленькие изменения, скрытые за feature flags; это требует сильного автоматического тестирования, так как main должен быть постоянно готов к релизу. Схема с release-ветками изолирует стабильность каждой версии, но требует явного переноса фиксов между ветками. Пример кода Что использовать на практике Рекомендация. если поддерживается только последняя версия в production — trunk-based масштабируется лучше на 40 инженеров; если параллельно поддерживаются несколько версий у разных клиентов — release-ветки неизбежны, и важна автома

Читать полностьюbranching

Короткий ответ Ветка — это указатель на цепочку коммитов, позволяющий разрабатывать функциональность изолированно от основной линии; merge создаёт коммит слияния и сохраняет историю обеих веток, а rebase переносит коммиты поверх новой базы, делая историю линейной. Как это работает подробнее branch — лёгкий указатель (хеш последнего коммита), а не копия файлов; HEAD переключается между ветками. merge делает трёхстороннее слияние с общим предком; rebase переигрывает коммиты один за другим на новую базу. Пример кода Что использовать на практике Рекомендация. rebase используют для приватных feature-веток перед открытием PR, чтобы история была чистой; merge — для объединения в основную ветку, чтобы не терять контекст. Публичную ветку, от которой уже ответвились другие, rebase'ить нельзя. Подводные камни Риск. rebase общей ветки после того, как её запушили и другие от неё ответвились, — ломает историю у коллег; путают git merge --squash с обычным merge.

Читать полностьюbranching

Короткий ответ git bisect автоматизирует бинарный поиск: вы помечаете известный «хороший» и «плохой» коммит, а Git последовательно предлагает промежуточные коммиты для тестирования, сужая диапазон за логарифмическое число шагов; git cherry-pick уместен, когда нужно перенести один конкретный коммит (например, hotfix) в другую ветку без слияния всей истории. Как это работает подробнее git bisect start, затем bad/good на границах диапазона; Git чекаутит средний коммит, вы отмечаете результат — за ~log2(50)≈6 итераций находится первый плохой коммит. git bisect run <script> автоматизирует это при наличии автоматического теста. Пример кода Что использовать на практике Рекомендация. перед bisect нужен надёжный тест, однозначно отличающий «баг есть» от «бага нет»; cherry-pick удобен для hotfix в несколько веток, но при частом использовании на много коммитов лучше рассмотреть merge/rebase. Подводные камни Риск. bisect без чистого критерия (баг то воспроизводится, то нет из-за флакующего теста) даёт неверный резу

Читать полностьюbranching