Git: бесконечные слияния. Я устал от них - PullRequest
10 голосов
/ 28 мая 2011

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

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

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

UPD.

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

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

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

UPD.2

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

Ответы [ 4 ]

14 голосов
/ 28 мая 2011

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

10 голосов
/ 28 мая 2011

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

Обновление:

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

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

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

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

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

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

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


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

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

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

5 голосов
/ 28 мая 2011

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...