8

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.

Siraris
  • 1,088
  • 3
  • 13
  • 21
  • Do you have a local copy of each repository? It's easiest to resolve merge conflicts locally and then push them out from there. – ChrisGPT was on strike Jan 08 '14 at 18:47
  • I have a local copy, yes. But I see no conflicts in my local repo. How do I get the merge conflict to be represented locally so I can resolve it and push it back? – Siraris Jan 08 '14 at 18:49
  • When you say you've forked the repository, is this a real fork (a separate repository), or a branch within the main repository? If you have multiple repositories, do you have a local copy of each one? – ChrisGPT was on strike Jan 08 '14 at 18:51
  • This is a forked repo. So if I have Master Repo I then fork Client A Repo. When I try to sync client A inside of Bitbucket, (aka sync Client A with Master Repo) it says there's merge conflicts, but there's no tool inside bitbucket that I can see that allows me to resolve the conflicts. – Siraris Jan 08 '14 at 18:55

1 Answers1

11

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 git@bitbucket.org: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
ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
  • Wouldn't it be better to use rebase to the upstream, and fix any conflicts locally? – Siraris Jan 08 '14 at 23:12
  • @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](http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing). I would avoid `rebase` if it would modify anything you've already `push`ed. – ChrisGPT was on strike Jan 08 '14 at 23:19
  • 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. – Siraris Jan 08 '14 at 23:27
  • 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`. – ChrisGPT was on strike Jan 08 '14 at 23:39
  • 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. – ChrisGPT was on strike Jan 08 '14 at 23:40
  • 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 Jan 08 '14 at 23:44
  • 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? – Siraris Jan 08 '14 at 23:45
  • @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 `fetch`ing, your local copy won't see the new commits. – ChrisGPT was on strike Jan 09 '14 at 03:13