Bitbucket: Conflict in remote repo, can't figure out how to resolve

Question

I hope I can express this properly... I have the following setup in Bitbucket (using Git protocol). I have a master repo that contains my application. I then fork the master repo per client in order to have the flexibility to make client specific changes without affecting the master. When a generic change is required, I push to master, and then sync with the fork and then do a pull into production.

The issue I'm having is that in Bitbucket, it's saying I have merge conflicts, but I have no clue how to resolve them. Locally, I have no conflicts. When I go into Bitbucket, it tells me I'm 2 commits behind the master repo so I click sync. It says there's merge conflicts, and I need to resolve them. I then see no way to resolve these conflicts. If I do a pull on the production server, it says there's conflicts and I need to resolve them, so I do. I go in with nano (as I HATE VIM) and clean out what I need to, and go about my business. But yet the forked repo seems to still be in conflict. I have no clue what I need to do in order to resolve this situation. Regardless, it has me at a standstill because I can't push any more changes to the fork until the conflicts get resolved.

Solution

When working with a fork, it is often helpful to have the upstream repository (your Master repository) configured as a remote as well as the fork (your Client A repository). For example, you probably already have an origin that represents the fork.

Add a new remote upstream to represent the "Master" repository:

git remote add upstream [email protected]:user/master-repo.git
git fetch upstream

Now you should be able to see all of the relevant branches. For instance, if you're trying to merge the master branch, these will be relevant:

• master (local)
• origin/master (Client A)
• upstream/master (Master repo)

If you visualize these branches with gitk or git log --all --graph --decorate you will probably be able to see where the conflict is coming from. Most likely you will want to merge changes from both remotes into your local master branch:

git checkout master
git merge upstream/master  # (Merge changes from the "Master" repo)
# Fix any merge conflicts that may arise
git merge origin/master    # (Merge changes from the Client A repo)
# Fix any merge conflicts that may arise

Once you have done this, you should be able to push cleanly to origin:

git push origin master

Comments

[Siraris]

Wouldn't it be better to use rebase to the upstream, and fix any conflicts locally?

[Chris]

@Siraris, the actual solution will depend on what you have, and what your project guidelines are. Merging upstream/master, then origin/master into master is just a suggestion. You may want to rebase onto upstream/master. But it is strongly discouraged to rebase published commits. I would avoid rebase if it would modify anything you've already pushed.

[Siraris]

OK, in re-reading what you wrote, I think what you're suggesting is what I want. One question though, if I do a git merge upstream/master, and then a git merge origin/master, will it merge my fork into the master, or will it only merge the master into the fork? I want to merge in the changes from the master, but I don't want to put the changes from the fork into the master.

[Chris]

Nothing in this process changes what's on upstream/master. You'll update master with changes from upstream/master, then with origin/master, so master will contain changes from both your Master repository and your fork. It's a good idea to test master at this point and make sure everything works as you expect. Then you'll push to origin (your fork). This will cause your fork to be updated with changes from upstream/master.

[Chris]

I believe you've got a separate local copy of your Master repository for "core" changes? That's what you should use for updating the Master repository.

[Siraris]

Yep! I have repos for the "Master" repo, and then the Client children. So any changes to "Master" will go through the local copy, and I just merge the changes locally using your method here. I'm going to try it out. If it works... I owe you my first born.

[Siraris]

Oh one other thing... do I need to fetch the upstream every time i do a merge? Or do I just do the checkout -> merge -> merge -> push?

[Chris]

@Siraris, you should fetch anytime you want to incorporate changes from a remote. This is what updates your remote refs, e.g. upstream/master and origin/master. Without fetching, your local copy won't see the new commits.