git rebase merge conflict

Question

I forked a github repo and worked on my github repo.
I have made pull-requests and it was completed.

After that the upstream had some more commits so now I want to rebase, I guess thats what I have to do.
But I'm getting these merge conflicts:

First, rewinding head to replay your work on top of it...
Applying: Issue 135 homepage refresh
Using index info to reconstruct a base tree...
<stdin>:17: trailing whitespace.
      %h4 
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging app/views/layouts/application.html.haml
CONFLICT (content): Merge conflict in app/views/layouts/application.html.haml
Auto-merging app/views/home/index.html.haml
CONFLICT (content): Merge conflict in app/views/home/index.html.haml
Auto-merging app/views/home/_group_projects.html.haml
CONFLICT (content): Merge conflict in app/views/home/_group_projects.html.haml
Failed to merge in the changes.
Patch failed at 0001 Issue 135 homepage refresh

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

I don't know how to fix these, please help.

Answer 1

Rebasing can be a real headache. You have to resolve the merge conflicts and continue rebasing. For example you can use the merge tool (which differs depending on your settings)

git mergetool

Then add your changes and go on

git rebase --continue

Good luck

Answer 2

If you have a lot of commits to rebase, and some part of them are giving conflicts, that really hurts. But I can suggest a less-known approach how to "squash all the conflicts".

First, checkout temp branch and start standard merge

git checkout -b temp
git merge origin/master

You will have to resolve conflicts, but only once and only real ones. Then stage all files and finish merge.

git commit -m "Merge branch 'origin/master' into 'temp'"

Then return to your branch (let it be alpha) and start rebase, but with automatical resolving any conflicts.

git checkout alpha
git rebase origin/master -X theirs

Branch has been rebased, but project is probably in invalid state. That's OK, we have one final step. We just need to restore project state, so it will be exact as on branch 'temp'. Technically we just need to copy its tree (folder state) via low-level command git commit-tree. Plus merging into current branch just created commit.

git merge --ff $(git commit-tree temp^{tree} -m "Fix after rebase" -p HEAD)

And delete temporary branch

git branch -D temp

That's all. We did a rebase via hidden merge.

Also I wrote a script, so that can be done in a dialog manner, you can find it here.

Answer 3

Note: with Git 2.14.x/2.15 (Q3 2017), the git rebase message in case of conflicts will be clearer.

See commit 5fdacc1 (16 Jul 2017) by William Duclot (williamdclt).
^{(Merged by Junio C Hamano -- gitster -- in commit 076eeec, 11 Aug 2017)}

rebase: make resolve message clearer for inexperienced users

Before:

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort"

After:

Resolve all conflicts manually, 
mark them as resolved with git add/rm <conflicted_files>
then run "git rebase --continue".

You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".')

The git UI can be improved by addressing the error messages to those they help: inexperienced and casual git users.
To this intent, it is helpful to make sure the terms used in those messages can be understood by this segment of users, and that they guide them to resolve the problem.

In particular, failure to apply a patch during a git rebase is a common problem that can be very destabilizing for the inexperienced user.
It is important to lead them toward the resolution of the conflict (which is a 3-steps process, thus complex) and reassure them that they can escape a situation they can't handle with "--abort".
This commit answer those two points by detailing the resolution process and by avoiding cryptic git linguo.

Answer 4

If you don't mind squashing into one big commit, easiest way I do it is git reset --soft <rebase-target> from your current branch then git commit.

So for example, you're on your branch and your target to rebase on is origin/master. Assuming you have no unstaged/working changes:

# Merge and fix any conflicts from master
git merge origin/master
# Push your changes in case you mess up and want to start over from remote
git push
# Move HEAD to rebase target, leaving all your work staged
git reset --soft origin/master
# Commit staged changes as giant commit
git commit -m "feat(foo): new feature"
# Confirm your changes, run tests, etc. Then force push
git push -f

You don't have to worry about redoing merge conflicts because the entire difference between your branch and rebase target is moved onto the staging area, all ready to be committed.

Answer 5

In some overcomplicated cases with deleted, renamed, changed files possible lifesaver may be to use empty "buffer" commit with all files deleted. It gives more flexibility on it's own and additionally next commit after empty then will became more reliable and snapshot-similar.