Може приклади якісь допоможуть?...

Було:

# main branch
class MyClass:
    def method1(self):
        print("This is method 1")

Гілка девелопера Петра:

# branchA
class MyClass:
    def method1(self):
        print("This is method 1")

    def method2(self):
        print("This is method 2 from branchA")

Гілка девелопера Миколи:

# branchB
class MyClass:
    def method1(self):
        print("This is method 1")

    def method3(self):
        print("This is method 3 from branchB")

Тімлід мерджить пул ріквести після рев'ю:

# main branch after merge
class MyClass:
    def method1(self):
        print("This is method 1")

    def method2(self):
        print("This is method 2 from branchA")

    def method3(self):
        print("This is method 3 from branchB")

О! Здається пригадав обставини. Переписуємо проект А на Б, таскаємо з А в Б велику кількість готового коду, скажімо, всі моделі. Намагаємось їх в проекті Б не чіпати, щоб нові фічі з А можна було легко переносити в Б разом з оновленими моделями, однак, іноді трапляється, що потрібно додати якийсь функціонал.

Тож маємо в проекті Б:

class Model_Something {
...
public static function new_method_for_B()
{
...
}

Копіюємо оновлену модель:

class Model_Something {
...
public static function new_method_from_A()
{
...
}

Тобто це не зовсім мердж, а перезаписування моделі новою версією. І тоді в мене є вибір, відкотити зміну - повернути метод for_B, але тоді зникне метод from_A. Зазвичай я копіюю останній, відкочую, а тоді вставляю скопійоване...

PS: Поточню, що мова йде про зміни, які припадають на ті самі рядки... Коли вони не перетинаються, можна легко відкотити затерті зміни, не втрачаючи нового коду з проекту А.

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

пояснюю.
в гілці мастер створюю файл з клясом та методом sayHello.
далі створюю гілку А, додаю до клясу новий метод sayBye.
далі йду взад у мастер і створюю гілку Б, в ній додаю метод sayHaslo.
потім мерджу гілку А в мастер.
тепер хочу змерджити мастер в гілку Б, і маю ось це.

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

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

Угу. Взагалі-то дуже корисно користуватися якимось гуєм до гіту. Мені дуже подобався smartgit, але він пропрієтарний. Непоганий також модуль git вбудований у phpstorm (теж пропрієтарний). З безкоштовних можу з великою натяжкою порекомендувати лише git-cola (до речі для порівняння там використовується kdiff3, але його можна замінити на той же meld, якщо він більш до вподоби). Ну і зовсім вже на крайній випадок - плагіни для vscode, як на мене вони не зручні, але практично всі операції, які бувають потрібні, там виконати можна... іноді дуже через сраку, але можна )

PS: А зовсім забув. Є ще TortoiseGit під віндовз...

1. треба просто більше познайомитись з git, більше практики
2. раціонально розприділяти таски (мінімізувати одночасну зміну сутності)
3. старатись писати чистий код, ознайомитись з принципами SOLID. Щоб не було такого - створити клас на сто пятсот рядків коду, в якому методи на всі випадки і різні таски потребують зміни в ньому.
4. Користуватись diff-інструментами типу meld, winmerge.

Також через різні git gui (типу SourceTree, SmartGit) можна легше боротись з конфліктами (use theirs, use mine).

Ну але іноді буває шо треба все вручну порезолвити, ніц не поробиш ) Ідеального нічого немає )