A GIT how-to for beginning and advanced developers

GIT Repos: Mine VS Theirs Explained

This post will explain without fuzz what’s the deal with that Mine VS Theirs thing when you want to resolve a conflict.

I’ve used GIT repos for over 9 years now, and there hasn’t been a year that I didn’t learn something new about working with a GIT repo. Either a better way to maintain your code versions, branches and release management, or another option for a GIT command that I didn’t know existed before.

That alone states how much power lies within the GIT cli on your machine.

Doubt On What Your GIT Tool Means?

You know that feeling when you’re working on another code merge from your branch to a central branch — like develop or test — and just aren’t sure what that message means that your tool is throwing at you this time?

I mean, we all know that a merge conflict needs some fixing. But what should you consider as “mine” within the GIT universe?

A simple search on Stack Overflow shows 500 search results on the simple question of what “mine” and “theirs” means. It might be time to show you why those words were chosen in the first place, before we dive into their meaning.

It’s All About Perspective

And that is the simplest and most useful fact. Because in GIT, most commands are put it into the perspective of a single truth: the current branch that you’ve checked out.

GIT doesn’t care about that awesome feature or bug fix that you’re working on late in the evening. Not more than your fridge cares about what you stash in it, anway… It is created for the sole purpose of keeping your code safe and remember what you’ve done with it in the past.

GIT cares about two things only: what branch you’re currently working on, and what changes you’ve been applying to that branch.

Any given moment in time, the current branch that you’ve checked out and are working on, together with any changes that you’ve applied, is the one reality for your codebase.

But What’s Considered Mine?

That’s a fine question, dear reader. But let’s start by making sure that you get the perspective and focus that GIT has, as it will help you to better understand what GIT considers “mine”.

As far as GIT goes, it does making sure that the code that it bears and keeps safe for you is stored and archived correctly is why it is around. Keeping your code safe and, from the standpoint of you as a user calling it “mine” seems logical and simple.

This also counts for things like pulling and pushing code:

You push your current code towards the destination and pull remote code into your current local codebase.

Your checked out code and the changes that you applied to that are the only thing that is of interest to GIT on your machine.

Mine will always be reasoned as being the code and its state in the current branch that you’re working in and the state of that code.

For example, let’s just state you’re a nice person who likes to code and maintains the code in branch A — the same branch that you’ve checked out right now. You want to include some nifty changes from branch B and do this by merging that branch into branch A.

Then branch A is considered “mine” since:

• you checked out branch A
• this is the current singular truth for your code

If you are lucky enough you’ll have no merging conflicts. But if you do have merging conflicts, you can hopefully now see that when you get that dialog that asks you to choose between “mine” and “theirs” that means:

• mine: your code as it was residing in branch A, just before the merge
• theirs: the code from the source, branch B, that has been taken into your code in the current branch A

Given this explanation, selecting “mine” will let you choose your code from branch A as the code of choice to keep after resolving the conflict.

Whereas selecting “theirs” will overwrite the code from the branch that you’re taking into the current branch and overwrites the code from branch A.

Choose Wisely

Now you know what you can consider as yours (mine) and theirs, you can decide for better or worse what code to keep when resolving the next conflict in your GIT repo.

Make sure you only select entire files to resolve at once when you’re absolutely sure you want to keep your code or the code you’re merging into your code by selecting theirs.

Whenever you’re in doubt of what was changed, it’s best to peek at a specific file and see what changes are being brought home to your current code aka mine.

To Conclude

The take aways that you should have gotten from this article:

• GIT always takes the current checked out branch and its changes as the single truth of your code base
• GIT sees your current code state as “mine” and any changes that you try to merge into that as “theirs”

Hopefully, this will save you some time next time you need to work on fixing a merge conflict on your projects in GIT.

Code Hard, Ship Harder ✌🏻