CODEWITHSUNDEEP
gitgithubgit-fork
Chara
Chara

Reputation: 1075

Syncing branch with upstream repo

I forked a repo and created a new branch in my fork called B. After working on it for a while, I want to create a pull request for B, but the original repo has been committed to. Currently the branch is "3 commits ahead, 5 commits behind Original".

How can I ensure there are no conflicts when creating a Pull Request?

I know this sounds like a duplicate question but I couldn't find/couldn't understand any solutions on the web.

Upvotes: 1

Views: 488

Answers (1)

Scott Weldon
Scott Weldon

Reputation: 10217

First of all, something to consider is that if you didn't change any of the same lines of code that were changed in the original repo, then it is possible that there won't be any merge conflicts. If this is the case, then the maintainers should be able to use GitHub's merge button even though your branch is behind.

If this is not the case, or you still want to make sure your branch is up to date, then continue reading.

Your repo probably looks something like this:

A--B--C--D--E--F [master]
 \
  G--H--I [branch B]

(Do e.g. git log --all --oneline --decorate --graph to see similar output for your repo.)

You have two options: merge, or rebase. Check the CONTRIBUTING file in the repo if there is one, because often a project will have rules or guidelines about which option you should use.

Merge

To resolve all conflicts at once, you can merge from master in the original repo into your branch. You would do:

git checkout B
git merge --no-ff master

If necessary, resolve any conflicts and commit.

Your history would then look like this:

A--B--C--D--E--F [master]
 \        \
  G--H--I--J [branch B]

Rebase

To avoid that merge commit J, you can instead rebase your branch onto master.

git checkout B
git rebase master

Your history would then look like this:

A--B--C--D--E--F [master]
                \
                 G'--H'--I' [branch B]

The labels of e.g. G' indicate that the commits have the same (or similar) content as before, but since they have new parent commits, they are technically new commits (with new SHA1 hashes).

The benefit of merging is that you can resolve all conflicts at once, but it can lead to a messier history. The benefit of rebasing is that it can lead to a cleaner history, but since it involves rewriting history, it can cause conflicts if you have already published your branch. Again, check to see if the project has any rules / guidelines about which to use.

Upvotes: 2

Related Questions