Hogyan lehet megérteni és megoldani a konfliktusokat a Git-ben

Ott van ez a szó, amelyet minden fejlesztő utál látni: konfliktus. Just A Git-tel (vagy más verzióvezérlő rendszerekkel) való együttműködés során nincs lehetőség az alkalmi egyesülési konfliktusok megkerülésére.

De amikor a fejlesztőkkel beszélek, gyakran hallom, hogy szorongás vagy kellemetlenség érződik az egyesülési konfliktusok körül.

A konfliktusok kezelése gyakran sötét, titokzatos hely marad: olyan helyzet, amikor a dolgok rosszul vannak összetörve, és nem világos, hogyan lehet onnan kilépni (anélkül, hogy a helyzetet tovább rontanánk).

Bár igaz, hogy az összeolvadási konfliktusok a fejlesztő életének elkerülhetetlen részét képezik, a kényelmetlenség ezekben a helyzetekben teljesen opcionális.

A cikkem célja az, hogy tisztázzam ezt a témát: hogyan és mikor fordulnak elő általában konfliktusok, mik azok valójában, és hogyan lehet ezeket megoldani - vagy visszavonni.

Ha megfelelően megérted ezeket a dolgokat, sokkal lazábban és magabiztosabban tudod kezelni az összeolvadási konfliktusokat. ?

Hogyan és mikor fordulnak elő konfliktusok

A név már azt mondja: "egyesítési konfliktusok" előfordulhatnak a különböző forrásból származó elkötelezettségek integrálása során.

Ne feledje azonban, hogy az "integráció" nem korlátozódik csak "ágak egyesítésére". Ez akkor is megtörténhet, ha újraváltoztat vagy interaktív újrabázisol, amikor cseresznyeválogatást vagy húzást hajt végre, vagy akár Stash újbóli alkalmazásakor.

Mindezek a műveletek valamiféle integrációt hajtanak végre - és ilyenkor egyesülési konfliktusok történhetnek.

De persze, ezek a tevékenységek nem eredményezik merge konfliktus minden alkalommal (hála Istennek!). Ideális esetben csak ritkán kell ilyen helyzetekbe kerülnie. De mikor fordulnak elő pontosan konfliktusok?

Valójában a Git egyesítő képességei az egyik legnagyobb előnye: az ágak összevonása a legtöbbször könnyedén működik, mert a Git általában képes egyedül megoldani a dolgokat.

De vannak olyan helyzetek, amikor ellentmondásos változások történtek - és ahol a technológia egyszerűen nem tudja eldönteni, mi a jó vagy a rossz. Ezek a helyzetek egyszerűen megkövetelik az emberi döntést.

Az igazi klasszikus az, amikor pontosan ugyanaz a kódsor változott két végrehajtás során, két különböző ágon. Gitnek nincs módja tudni, melyik változást részesíti előnyben! ?

Van néhány más, hasonló helyzet - például amikor egy fájlt az egyik ágban módosítottak és egy másikban töröltek -, de ezek valamivel ritkábbak.

A "Tower" Git asztali grafikus felhasználói felület például szép módon képes megjeleníteni az ilyen helyzeteket:

Hogyan lehet tudni, ha konfliktus történt?

Ne aggódjon: Git nagyon világosan megmondja, ha konfliktus történt. ?  

Először azonnal értesíti Önt a helyzetről , például amikor az összeolvadás vagy az újbóli bontás konfliktus miatt meghiúsul:

$ git merge develop Auto-merging index.html CONFLICT (content): Merge conflict in index.html CONFLICT (modify/delete): error.html deleted in HEAD and modified in develop. Version develop of error.html left in tree. Automatic merge failed; fix conflicts and then commit the result.

Amint a fenti példából látható, amikor egyesítést próbáltam végrehajtani, összeolvadási konfliktust hoztam létre - és Git nagyon világosan és azonnal közli a problémát:

  • Ütközés történt az "index.html" fájlban.
  • Újabb ütközés történt a "error.html" fájlban.
  • És végül a konfliktusok miatt az egyesítési művelet kudarcot vallott.

Ezek azok a helyzetek, amikor be kell ásnunk a kódba, és meg kell néznünk, mit kell tennünk.

Abban a valószínűtlen esetben, ha figyelmen kívül hagyta ezeket a figyelmeztető üzeneteket, amikor a konfliktus bekövetkezett, a Git ezenkívül tájékoztatja Önt, amikor fut git status:

$ git status On branch main You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add/rm ..." as appropriate to mark resolution) deleted by us: error.html both modified: index.html

Más szavakkal: ne aggódjon, ha nem veszi észre az összeolvadási konfliktusokat. Git biztosítja, hogy ne hagyja figyelmen kívül őket.

Hogyan lehet visszavonni egy konfliktust a Git-ben és mit kezdeni

Az összeolvadási konfliktusok bizonyos sürgősséggel járnak. És jogosan: meg kell küzdenie velük, mielőtt folytathatja munkáját.

De bár figyelmen kívül hagyásuk nem opció, az "összeolvadási konfliktusok kezelése" nem feltétlenül jelenti azt, hogy meg kell oldanod őket. Lehetséges azok visszavonása is!

Ezt érdemes lehet megismételni: mindig lehetősége van az összevonási konfliktus visszavonására és visszatérésre a korábbi állapotba. Ez akkor is igaz, ha már elkezdte az ütköző fájlok megoldását és zsákutcába került.

Ezekben a helyzetekben nagyon jó szem előtt tartani, hogy mindig újra lehet kezdeni és visszatérni egy tiszta állapotba, még mielőtt a konfliktus bekövetkezne.

Erre a célra a legtöbb parancs jön egy --abortlehetőség, például git merge --abortés git rebase --abort:

$ git merge --abort $ git status On branch main nothing to commit, working tree clean

Ez azt a bizalmat keltheti önben, hogy valóban nem tudja elrontani. Mindig megszakíthatja, visszatérhet a tiszta állapotba, és elölről kezdheti.

Milyenek a konfliktusok valójában a Gitben

Most már nyugodtan, abban a tudatban, hogy semmi sem törhet el, nézzük meg, hogy néz ki valójában egy konfliktus a motorháztető alatt. Ez demisztifikálja azokat a kis bugyusokat, és egyúttal segít abban, hogy elveszítse iránti tiszteletüket, és bizalmat szerezzen önmagában.

Példaként nézzük meg a szerkesztőben található (jelenleg ütköző) "index.html" fájl tartalmát:

Git volt olyan kedves, hogy megjelölte a fájlban a problémás területet, beillesztve azt <<<<<<< HEADés >>>>>>> [other/branch/name]. Az első jelölő után megjelenő tartalom a jelenlegi munkaágunkból származik. Végül egy =======karakteres sor választja el a két ütköző változást.

Hogyan lehet megoldani egy konfliktust Git-ben

Fejlesztőként most az a feladatunk, hogy megtisztítsuk ezeket a sorokat: miután befejeztük, a fájlnak pontosan úgy kell kinéznie, ahogy szeretnénk.

Szükség lehet arra, hogy beszéljen a csapattársával, aki az "egyéb" változtatásokat írta, és eldöntse, melyik kód valójában helyes. Talán a miénk, talán az övék - vagy talán a kettő keveréke.

This process - cleaning up the file and making sure it contains what we actually want - doesn't have to involve any magic. You can do this simply by opening your text editor or IDE and starting to making your changes.

Often, however, you'll find that this is not the most efficient way. That's when dedicated tools can save time and effort:

  • Git GUI Tools: Some of the graphical user interfaces for Git can be helpful when solving conflicts. The Tower Git GUI, for example, offers a dedicated "Conflict Wizard" that helps visualize and solve the situation:
  • Dedicated Merge Tools: For more complicated conflicts, it can be great to have a dedicated "Diff & Merge Tool" at hand. You can configure your tool of choice using the "git config" command. (Consult your tool's documentation for detailed instructions.) Then, in case of a conflict, you can invoke it by simply typing git mergetool. As an example, here's a screenshot of "Kaleidoscope" on macOS:

After cleaning up the file - either manually or in a Git GUI or Merge Tool - we have to commit this like any other change:

  • By using git add on the (previously) conflicted file, we inform Git that the conflict has been solved.
  • When all conflicts have been solved and added to the Staging Area, you need to complete the resolution by creating a regular commit.

How to Become More Confident and Productive

Many years ago, when I started using version control, merge conflicts regularly freaked me out: I was afraid that, finally, I had managed to break things for good. ?

Only when I took the time to truly understand what was going on under the hood was I able to deal with conflicts confidently and efficiently.

The same was true, for example, when dealing with mistakes: only once I learned how to undo mistakes with Git was I able to become more confident and productive in my work.

I highly recommend taking a look at the free "First Aid Kit for Git", a collection of short videos about how to undo and recover from mistakes with Git.

Have fun becoming a better programmer!

About the Author

Tobias Günther is the CEO of Tower, the popular Git desktop client that helps more than 100,000 developers around the world to be more productive with Git.