Являются ли частые осложненные конфликты слиянием признаком проблем?

В нашей команде мы используем Git в качестве источника контроля. У нас есть несколько областей кода, которые почти независимы, но имеют некоторое перекрытие. В последнее время мы обсуждали рабочие процессы и подходы к использованию системы контроля версий. Одна жалоба, которая возникает, когда я продвигаю использование рабочего процесса ветви функций, заключается в том, что люди часто сталкиваются со сложными конфликтами слияния, которые они неправильно разрешают. Под сложным я подразумеваю «неочевидно, как решить». В свете этого более активно используются другие рабочие процессы, такие как рабочий процесс на основе «pull rebase».

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

Правильно ли я думаю об этом? Являются ли сложные конфликты слиянием признаком чего-то хорошего или плохого?

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

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

Я привык к рабочему процессу "fetch-rebase-push". На самом деле это первый, самый примитивный рабочий процесс, который описан в вашем руководстве. Вот его преимущества:

• Истинная непрерывная интеграция
• Раннее управление конфликтами - сразу после написания и проверки кода
• Быстрый ответ - «Эй, Боб, кубическая интерполяция, которую ты написал, дает забавный результат, ты не мог бы взглянуть на это, пока я на ланче?»
• Никаких слияний - чистая временная шкала, как если бы один разработчик написал everithyng

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

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

Слияния и перебазировки должны вызывать точно такие же конфликты для тех врожденных конфликтов, которые должен разрешить человек (т.е. два разработчика изменяют одну и ту же строку кода). В других конфликтах слияния на самом деле имеют тенденцию быть чище, потому что вы не изменяете коммиты SHA-1 повсюду. Я не уверен, как вам удается попасть в состояние, когда слияния вызывают больше конфликтов, чем перебазировок, но это, безусловно, признак того, что рабочий процесс некоторых людей испорчен, и им, вероятно, необходимо больше узнать о том, как работает git. Они удаляют коммиты слияния других людей, когда они делают свои локальные ребазы, или что-то в этом роде?

Преимущество и недостаток метода pull-rebase в том, что он очень похож на централизованные рабочие процессы, к которым привыкли многие люди. Вам не нужно понимать ветвление, чтобы использовать его.

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

Проект, над которым я работаю, время от времени сталкивается с подобными проблемами, и, похоже, это связано с несколькими факторами:

• Мы используем Visual Studio и такие файлы, как Visual Studio .sln - это просто XML-документы (которые плохо реагируют на текстовые слияния), полные Guids (которые Git не может понять лучше, чем остальные), и их легко можно плохо объединены и вызывают потерю файлов.
• Некоторые люди работают над похожими областями кода, так что изменения, которые будут переданы, могут быть рядом друг с другом в классах. Хотя в этой ситуации это неизбежно, такой тип конфигурации будет очень тяжелой работой для любой системы контроля версий. Даже если вы хорошо общаетесь в своей команде, иногда люди не осознают, что сталкиваются с кодом друг друга, и возникают конфликты.

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

Если разработчики не изменяют исторические коммиты (вместо чистых слияний), конфликты в git-модели типов рабочих процессов объектов являются признаком тесно связанной кодовой базы (/ brandnew codebase) или перекрывающегося назначения функций.

У вас есть главная (главная) ветка, и все работают в своих ветках.

Работа в тематических ветках может занять от нескольких часов до нескольких месяцев.

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

Просто чтобы прояснить терминологию, под «обратным слиянием» я подразумеваю слияние из функциональной ветви в основную ветвь, а под «прямым слиянием» я имею в виду слияние из основной ветви в функциональную ветвь. Исходя из того, что я испытал ранее, вы, скорее всего, увидите больше конфликтов слияния при обратном слиянии, чем в случае прямого слияния.

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