Во-первых, похоже, что ветка разработки разделена между многими разработчиками (иначе конфликтов не будет)
Похоже, что вопрос по сути касается ветки разработки, ветка master довольно неактуальна на этот вопрос: конфликты возникают между локальной копией ветки разработки и удаленной б во время извлечения, я прав? (Я предполагаю это для ответа)
Если так ... Я не работал с ClearCase, но как разрешаются конфликты, если изменения вносятся в один файл, тот же метод, тот же метод линия? Как очистить кейс, чтобы узнать, какую копию выбрать во время «вытягивания»? Очевидно, это должно вызвать некоторый интерактивный процесс, который позволит программисту решить, что выбрать ...
Это как раз процесс разрешения конфликта. Когда вы говорите:
До этого я работал в прозрачном режиме, и у нас не было столько конфликтов. я что-то не так делаю в плане работы?
Я бы ответил, что это в значительной степени зависит от программной базы кода и программистов, а не от самого инструмента, а именно от того, часто ли люди модифицируют одни и те же файлы они будут получать частые конфликты. В качестве альтернативы, если кодовая база достаточно велика, и работа разработчика обычно не «перекрывается», конфликт будет разрешен автоматически.
Теперь вы должны понимать, что разрешение конфликтов - это не что-то плохое, это часть работы. Я могу дать только пару советов:
часто вносить изменения в местное отделение. Если разработчик примет изменение, запустит функцию и не будет, скажем, один месяц, есть вероятность, что будет большой конфликт. Кроме того, если разработчик тянет пару раз в день, вероятность конфликта мала, и конфликт, если он существует, легко разрешается
Рассмотрите возможность использования git pull --rebase из ветка развития. Это может помочь очистить историю коммитов. Я подозреваю, что в настоящее время журнал коммитов «залит» многочисленными коммитами слияния. В общем, сделайте это, если вы понимаете разницу между слиянием и перебазированием.