Git: бесконечные слияния. Я устал от них

Недавно я начал работать в Git с командой из 8 человек. Мы решили, что это хорошая практика для работы отдельно в каждой личной ветке (кто-то читал об этом где-то). После некоторого времени работы в такой топологии я разозлился о том, сколько времени требуется, чтобы получить/слить изменения с мастера и нажать/объединить его обратно. Половина времени, которое я трачу на выпуск, - это слияние с кем-то.

Я хочу получать последние изменения от мастера каждые 2 часа. Но каждый раз мне приходится тратить время, чтобы объединить их в мою ветку.

Я предполагаю, что Git в порядке, и мы выбрали неправильный рабочий процесс. Хо, мы можем избежать частых слияний и всегда иметь последнего мастера?

UPD.

Как Нил заметил правильно - некоторые из нас работают одновременно на одном фрагменте кода. То, что мы получим слияния в других VCS'ах - это правда. но не так часто, как в Git!

Например: я хотел переименовать класс в проекте. Этот класс широко используется в проекте. Я сделал это в своей ветке. Хорошо, у меня есть каждый раз, когда я выхожу из мастера - сливается с моим товарищем по команде. Затем я решил окончательно объединить его, чтобы овладеть. Еще один сливается. Я сделал это. Тогда мой товарищ по команде тянет и получает другое слияние. Так что время, затрачиваемое на слияния в команде, теряется впустую.

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

UPD. 2

Также часто случается, что я получаю слияние с кодом, который я никогда не изменял. Это странно, поскольку я должен разрешать конфликты кода, о которых я понятия не имею. Может быть, есть и некоторые обходные пути, избегающие этих слияний?

ОТВЕТЫ

Ответ 1

Есть три инструмента, которые могут помочь вам

  • Держите историю линейной, используя rebase. Это только приводит к разрешению конфликтов вокруг, но идея заключается в том, что перед тем, как нажать на репозиторий или запросить выталкивание из вашего репозитория со стороны стороннего производителя, используйте git rebase поверх текущей версии. Примечание: не делайте этого в опубликованной истории. Это гарантирует, что другой человек не должен разрешать конфликты.

    Язык в щеке: если вы устали от слияния, вы можете git pull --rebase вместо;-) Хотя это не поможет вам разрешить конфликты.

  • Если вы снова и снова решаете один и тот же конфликт, попробуйте включить git rerere - - это инструмент, который re использует re связанный re решение конфликтных слияний.

    Вам нужно установить конфигурационную переменную rerere.enabled, чтобы включить эту команду.

  • Если стандартный трехсторонний слияние текста не работает для вас, но ваши конфликты слияния могут быть разрешены программно, вы можете настроить файл слияния для указанных файлов. См. Описание атрибута merge в gitattributes manpage.

Альтернативное решение - это смена работы.

Вместо того, чтобы сначала вытаскивать, разрешая слияние, а затем нажав на "центральный" репозиторий, вы можете попросить сопровождающего отменить изменения от вас (git request-pull может помочь здесь).

Если вы являетесь сопровождающим, вы можете попросить разработчика либо исправить его изменения, чтобы он сливался чисто (например, путем переустановки поверх текущей версии), либо попросил их объединиться. Они могут лучше знать, как разрешать конфликты.

Ответ 2

Если у вас много конфликтов слияния, которые необходимо разрешить вручную, ваша проблема заключается в макете кода в вашем приложении - это означает, что несколько человек постоянно работают в одних и тех же исходных файлах. Возможно, вам придется посмотреть, как сделать ваш код более модульным, чтобы отдельные разработчики не должны были изменять одни и те же файлы при работе с различными функциями. Если вы этого не сделаете, у вас будут проблемы слияния со всеми VCS.

Ответ 3

Кажется, что несколько человек работают над одним файлом и часто меняются. Это означает, что ваше разделение задач или модуляция проекта неверны.

Обновление:

  • Лично я считаю, что ветки лучше, если они специфичны для конкретного объекта, а не для конкретного человека. Во всяком случае, если вы решили работать в одном филиале (мастер). Нажимайте часто нажимайте часто. Но убедитесь, что каждое нажатие достаточно стабильно для компиляции.
  • Также поддерживайте другую стабильную ветвь, где вы можете поддерживать стабильную версию своего приложения.

Ответ 4

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

Эта проблема не связана с git, она связана с используемой моделью ветвления и с какими частями кода, который вы меняете. Если вы хотите полностью избавиться от слияний, невозможно, если вы хотите избавиться от конфликтов слияния, начните смотреть на то, что такое конфликты, и как вы можете работать более ортогональным образом.

Может быть, кто-то меняет файл и подталкивает его к разным окончаниям строк, чем другие люди. Этот файл всегда будет иметь конфликты слияния с людьми, использующими другое завершение строки, например. если у вас есть люди, развивающиеся как в unix, так и в окнах.