Управление рабочим процессом Git с несколькими разработчиками, вносящими большие изменения в файлы конфигурации XML

Question

Наша команда разработчиков (около 10-12 человек) работает с набором инструментов, которые вносят изменения в набор общих файлов конфигурации XML в нашем проекте. Эти XML файлы используются инструментами для настройки и автоматического создания большого фрагмента нашего программного стека. При работе с этими инструментами мы сталкиваемся со значительными Git проблемами рабочего процесса из-за следующих факторов:

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

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

Есть ли у кого-нибудь рекомендации по стратегиям, как справиться с этой ситуацией?

Спасибо за вашу помощь.

Answer 1

Сначала я дам вам совет для вашего конкретного рабочего процесса и как интегрировать несколько git тактик, которые могут помочь.

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

2. Узнайте об аргументе rerere для слияния и вообще. Это поможет упростить некоторые из происходящих крупных слияний.

Помимо этого, я бы порекомендовал изучить некоторые другие инструменты, которые включают генерацию кода, такие как комплекты моделирования UML (EA, и др. c), которые позволят вам получить более полный и понятный рабочий процесс. XML файлов - это полторы головной боли.

Answer 2

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

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

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

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