Understanding and resolving merge conflicts – Donny Wals

Git is nice, and when it really works effectively it may be a breeze to work with. You push , pull, commit, department, merge, however then… you get right into a merge battle, On this put up, we’ll discover merge conflicts. We’ll have a look at why they occur, and what we are able to do to keep away from operating into merge conflicts within the first place.

Let’s begin by understanding why a merge battle occurs.

Understanding why a merge battle occurs

Git is often fairly good at merging collectively branches or commits. So why does it get confused typically? And what does it imply when a merge battle happens?

Let me begin by saying {that a} merge battle will not be your fault. There’s a great likelihood that you just couldn’t have prevented it, and it’s most definitely not one thing it’s best to really feel unhealthy about.

Merge conflicts occur on a regular basis and they’re at all times fixable.

The rationale merge conflicts occur is that git typically will get conflicting details about adjustments. For instance, perhaps your coworker break up an enormous Swift file into two or extra recordsdata. You’ve made adjustments to elements of the code that was now moved into an extension.

The next two code snippets illustrate the earlier than scenario, and two “after” conditions.

// Earlier than
struct MainView: View {
  var physique: some View {
    VStack {
      Textual content("That is an instance")

      Button("Counter ++") {
        // ...
      }
    }
    .padding(16)
  }
}

// After on department major
struct MainView: View {
  var physique: some View {
    VStack {
      Textual content("That is one other instance")
      Textual content("It has a number of traces!")

      Button("Counter ++") {
        // ...
      }
    }
    .padding(16)
  }
}

// After on characteristic department
struct MainView: View {
  var physique: some View {
    VStack {
      MyTextView()

      CounterButton()
    }
    .padding(16)
  }
}

When git tries to merge this, it will get confused.

Programmer A has deleted some traces, changing them with new views whereas programmer B has made adjustments to these traces. Git wants some help to inform it what the suitable solution to merge that is. A merge battle like that is no one’s fault as a result of it’s completely affordable for one developer to be refactoring code and for one more developer to be engaged on part of that code.

Often you’ll attempt to keep away from two builders engaged on the identical recordsdata in a brief timespan, however on the similar time git makes it in order that we can work on the identical file on a number of branches so it’s not frequent for builders to synchronize who works on which recordsdata and when. Doing so could be an enormous waste of time, so we as a substitute we depend on git to get our merges proper normally.

Each time git sees two conflicting adjustments on the identical a part of a file, it asks a human for assist. So let’s transfer on to seeing totally different approaches to resolving merge conflicts.

Resolving merge conflicts

There’s no silver bullet for resolving your merge conflicts. Usually you’ll select one in all three choices while you’re resolving a battle:

• Resolve utilizing the incoming change (theirs)
• Resolve utilizing the present change (mine)
• Resolve manually

In my expertise you’ll often need to use a handbook decision when fixing merge conflicts. Earlier than I clarify how that works, let’s take a Fast Have a look at how resolving utilizing “mine” and “theirs” works.

A merge conflicts at all times occurs while you attempt to apply adjustments from one commit onto one other commit. Or, while you attempt to merge one department into one other department.

Generally git can merge elements of a file whereas different elements of the file trigger conflicts. For instance, if my commit adjustments line 2 of a selected file, and the opposite commit removes that line. My commit additionally provides a couple of traces of code on the finish of the file, and the opposite commit doesn’t.

Git could be sensible sufficient to append the brand new traces to the file, however it might probably’t work out what to do with line 2 of the recordsdata since each commits have made adjustments in a means that git can’t merge.

On this case, we are able to make a option to both resolve the battle for line 2 utilizing my commit (make a change to line 2) or utilizing the opposite commit (delete the road altogether).

Deciding what must be finished can typically require some work and collaboration.

In case your coworker deleted a selected line, it’s price asking why they did that. Perhaps line 2 declares a variable that’s now not wanted or used so your coworker figured they’d delete it. Perhaps you didn’t examine whether or not the variable was nonetheless wanted however you utilized a formatting change to do away with a SwiftLint warning.

In a scenario like this, it’s secure to resolve your battle utilizing “their” change. The road could be eliminated so you’ll be able to inform git that the incoming change is what you need.

In different conditions issues may not be as simple and also you’ll have to do a handbook merge.

For instance, let’s say that you just break up a big file into a number of recordsdata whereas your coworker made some adjustments to one of many features that you just’ve now moved into a distinct file.

If so, you’ll be able to’t inform git to make use of one of many commits. As a substitute, you’ll have to manually copy your coworker’s adjustments into your new file in order that every part nonetheless works as supposed. A handbook battle decision can typically be comparatively easy and fast to use. Nevertheless, they will also be somewhat advanced.

In case you’re not 100% certain about the easiest way to resolve a battle I extremely advocate that you just ask for a second pair of eyes that will help you out. Ideally the eyes of the creator of the conflicting commit as a result of that can assist be sure to don’t by chance discard something your coworker did.

Throughout a merge battle your venture received’t construct which makes testing your battle decision nearly unattainable. When you’ve resolved every part, be sure to compile and take a look at your app earlier than you commit the battle decision. If issues don’t work and you don’t have any concept what you’ve missed it may be helpful to only rewind and check out once more by aborting your merge. You an do that utilizing the next command:

git merge --abort

It will reset you again to the place you had been earlier than you tried to merge.

In case you strategy your merge conflicts with warning and also you pay shut consideration to what you’re doing you’ll discover that the majority merge conflicts could be resolved with out an excessive amount of hassle.

Merge conflicts could be particularly tedious while you attempt to merge branches by rebasing. Within the subsequent part we’ll check out why that’s the case.

Resolving conflicts whereas rebasing

While you’re rebasing your department on a brand new commit (or department), you’re replaying each commit in your department utilizing a brand new commit as the start line.

This will typically result in fascinating issues throughout a rebase the place it feels such as you’re resolving the identical merge conflicts over and over.

In actuality, your conflicts can hold popping up as a result of every commit may have its personal incompatibilities along with your new base commit.

For instance, think about the next diagram as our git historical past:

You’ll be able to see that our major department has obtained some commits since we’ve created our characteristic department. For the reason that major department has modified, we need to rebase our characteristic department on major in order that we all know that our characteristic department is absolutely updated.

As a substitute of utilizing a daily merge (which might create a merge commit on characteristic) we select to rebase characteristic on major to make our git historical past look as follows:

We run git rebase major from the command line and git tells us that there’s a battle in a selected file.

Think about that this file appeared like this once we first created characteristic:

struct MainView: View {
  var physique: some View {
    VStack {
      Textual content("That is an instance")

      Button("Counter ++") {
        // ...
      }
    }
    .padding(16)
  }
}

Then, major obtained some new code to make the file appear like this:

struct MainView: View {
  var physique: some View {
    VStack {
      Textual content("That is one other instance")
      Textual content("It has a number of traces!")

      Button("Counter ++") {
        // ...
      }
    }
    .padding(16)
  }
}

However our characteristic department has a model of this file that appears as follows:

struct MainView: View {
  var physique: some View {
    VStack {
      MyTextView()

      CounterButton()
    }
    .padding(16)
  }
}

We didn’t get to this model of the file on characteristic in a single step. We even have a number of commits that made adjustments to this file so once we replay our commits from characteristic on the present model of major, every particular person commit may need a number of conflicts with the “earlier” commit.

Let’s take this step-by-step. The primary commit that has a battle seems to be like this on characteristic:

struct MainView: View {
  var physique: some View {
    VStack {
      MyTextView()

      Button("Counter ++") {
        // ...
      }
    }
    .padding(16)
  }
}

struct MyTextView: View {
  var physique: some View {
    Textual content("That is an instance")
  }
}

I’m certain you’ll be able to think about why it is a battle. The characteristic department has moved Textual content to a brand new view whereas major has modified the textual content that’s handed to the Textual content view.

We will resolve this battle by grabbing the up to date textual content from major, including it to the brand new MyTextView and proceed with our rebase.

Now, the following commit that modified this file may also have a battle to resolve. This time, we have to inform git find out how to get from our beforehand fastened decide to this new one. The rationale that is complicated git is that the commit we’re making an attempt to use can now not be utilized in the identical means that it was earlier than; the bottom for each commit in characteristic has modified so every commit must be rewritten.

We have to resolve this battle in our code editor, after which we are able to proceed the rebase by operating git add . adopted by git rebase --continue. It will open your terminal’s textual content editor (typically vim) permitting you to vary your commit message if wanted. While you’re proud of the commit message you’ll be able to end your commit by hitting esc after which writing :wq to put in writing your adjustments to the commit message.

After that the rebase will proceed and the battle decision course of must be repeated for each commit with a battle to guarantee that every commit builds appropriately on high of the commit that got here earlier than it.

While you’re coping with a handful of commits that is high quality. Nevertheless should you’re resolving conflicts for a dozen of commits this course of could be irritating. If that’s the case, you’ll be able to both select to do a merge as a substitute (and resolve all battle directly) or to squash (elements of) your characteristic department. Squashing commits utilizing rebase is a subject that’s fairly superior and may very well be defined in a weblog put up of its personal. So for now, we’ll skip that.

While you’ve determined the way you need to proceed, you’ll be able to abandon your rebase by operating git rebase --abort in your terminal to return to the state your department was in earlier than you tried to rebase. After that, you’ll be able to resolve to both do a git merge as a substitute, or you’ll be able to proceed with squashing commits to make your life slightly bit simpler.

Git rebase and your distant server

In case you’ve resolved all of your conflicts utilizing rebasing, you’ve got barely altered the entire commits that had been in your characteristic department. In case you’ve pushed this department to a distant git server, git will let you know that your native repository has n commits that aren’t but on the distant, and that the distant has a (often) equal variety of commits that you don’t but have.

If the distant has extra commits than you do, that’s an issue. It is best to have pulled first earlier than you probably did your rebase.

The rationale that you must pull first in that state of affairs is since you want to have the ability to rebase all commits on the department earlier than you push the rewritten commits to git since with the intention to do a push like that, we have to inform git that the commits we’re pushing are appropriate, and the commits it had remotely needs to be ignored.

We do that by passing the --force flag to our git push command. So for instance git push --force characteristic.

Observe that it’s best to at all times be tremendous cautious when pressure pushing. It is best to solely ever do that after a rebase, and should you’re completely certain that you just’re not by chance discarding commits from the distant by doing this.

Moreover, should you’re engaged on a department with a number of folks a pressure push could be somewhat irritating and problematic to the native branches of your coworkers.

As a normal rule, I attempt to solely rebase and pressure push on branches that I’m engaged on on my own. As quickly as a department is being labored on my others I change to utilizing git merge, or I solely rebase after checking in with my coworkers to guarantee that a pressure push won’t trigger issues for them.

When doubtful, at all times merge. It’s not the cleanest answer as a result of merge commits it creates, however at the very least it received’t trigger points on your teammates.

In Abstract

Merging branching is a daily a part of your everyday work in git. Whether or not it’s since you’re tying to soak up adjustments somebody made right into a department of your individual or it’s since you need to get your individual adjustments in to your major department, understanding totally different merging strategies is vital.

No matter how you propose to merge branches, there’s a risk to run right into a merge battle. On this put up, you’ve realized why merge conflicts can occur, and how one can resolve them.

You’ve additionally study why rebases can run into a number of merge conflicts and why it’s best to at all times resolve these conflicts one after the other. Briefly, it’s as a result of git replays every commit in your department on high of the “present” commit for the department you’re rebasing on.

The important thing to resolving conflicts is at all times to maintain your cool, take it straightforward, and work by means of the conflicts one after the other. And when doubtful it’s at all times a good suggestion to ask a coworker to be your second pair of eyes.

You additionally realized about pressure pushing after rebasing and the way that may be problematic should you’re working in your department with a number of folks.

Do you’ve got any strategies you like to make use of whereas resolving conflicts? Let me know on X or Threads!