Чи часто виникають складні конфлікти злиття - ознака проблем?

У нашій команді ми використовуємо Git як джерело управління. У нас є декілька областей коду, які майже незалежні, але мають певне перекриття. Останнім часом ми обговорювали робочі процеси та підходи до використання джерела управління. Однією скаргою, яка виникає, коли я сприяю використанню робочого циклу функції, є те, що люди часто стикаються зі складними конфліктами злиття, які вони неправильно вирішують. Під складним, я маю на увазі "не очевидно, як вирішити". Зважаючи на це, інші робочі процеси активніше використовуються, такий робочий процес, що базується на "витягуванні".

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

Чи правильно я думаю про це? Чи є складні конфлікти злиття ознакою чогось доброго чи поганого?

Не неможливо, що проблема полягає у вашому коді. Якщо у вашій кодовій базі багато взаємозв'язків між модулями, то кожна зміна матиме суттєві труднощі скрізь, і кожен розробник взаємодіє з будь-яким іншим кодом, це буде кошмаром.

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

Я звик до робочого процесу "fetch-rebase-push". Насправді це перший, найпримітивніший робочий процес, описаний у вашому підручнику. Ось такі переваги:

• Справжня безперервна інтеграція
• Раннє управління конфліктами - відразу після того, як один написав і протестував код
• Швидка відповідь - "Гей, Бобе, кубічна інтерполяція, яку ти написав, дає смішний вихід, ти можеш поглянути на це, поки я в обід?"
• Жодних об'єднань не робиться - чиста хронологія як би один розробник написав everithyng

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

Я особисто хотів би мати справу з частими, легкими конфліктами злиття (фактично перезавантаження), а не рідкісними, всеохоплюючими жахами злиття.

Злиття та знижки повинні викликати абсолютно однакові конфлікти для тих притаманних конфліктів, які людина повинна вирішити (тобто два розробники, що змінюють один і той же рядок коду). Для інших конфліктів злиття насправді є більш чистими, оскільки ви не змінюєте SHA-1 комітетів у всіх місцях. Я не впевнений, як вам вдасться потрапити в стан, коли злиття викликають більше конфліктів, ніж знижки, але це, безумовно, знак того, що робочий процес у деяких людей заплутаний, і їм, ймовірно, потрібна додаткова підготовка щодо того, як працює git. Чи вони видаляють комісії для злиття інших людей, коли вони роблять свої місцеві знижки, чи щось подібне?

Користь і недолік методу "pull-rebase" полягає в тому, що він дуже схожий на централізовані робочі процеси, до яких звикли багато людей. Вам не потрібно розуміти розгалуження, щоб ним скористатися.

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

Проект, над яким я працюю, час від часу має подібні проблеми, і, здається, це є наслідком пари факторів:

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

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

Якщо розробники не змінюють історичні зобов’язання (замість чистих об'єднань), конфлікти в функції функції git типу робочого процесу є ознакою щільно зв'язаної кодової бази (/ brandnew codebase) або перекриття присвоєння функції.

У вас є головна (головна) галузь, і всі працюють у своїх галузях функцій.

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

Раз у раз хтось поверне їх об'єднання змін у основну гілку. Ваша команда повинна переконатися, що лише одна людина робить зворотне злиття одночасно. Як тільки це буде зроблено, вам потрібно переадресувати об'єднання з головного відділення у свою функціональну гілку. Після того, як всі роблять злиття вперед, іншій особі може бути дозволено повернути об'єднання в основну гілку. Інакше занадто багато змін буде обернено назад, і у вас буде багато конфліктів злиття на вашому злитті вперед.

Просто для уточнення термінології під "зворотним злиттям" я маю на увазі об'єднання від функції гілки в основну гілку, а під "вперед об'єднання" я маю на увазі об'єднання з головної гілки в особливість гілки. Виходячи з того, що я відчував раніше, ви, ймовірно, побачите більше конфліктів злиття при зворотному злитті, на відміну від злиття вперед.

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