If the change that you submitted has a merge conflict, you need to manually resolve it using git rebase. Rebasing is used to integrate changes from one branch into another to resolve conflicts when multiple commits happen on the same file. Never do a rebase on public (master) branches. You submit a change.
Rebasing is not going to magically remove all merge conflicts. In fact, you may encounter conflicts while rebasing. Sometimes, you will have to repeatedly resolve the same conflict while rebasing. However, merge conflicts happen because multiple changes happen to the same chunk of code simultaneously.
There are a couple situations where I've seen rebase
get stuck. One is if the changes become null (a commit has changes that were already made previously in the rebase) in which case you may have to use git rebase --skip
.
It's pretty easy to tell. If you do git status
it should show no changes. If so just skip it. If that isn't the case please post a copy of git status
and I can try to help further.
One of the times that I have run into this issue is when doing a git commit
after a git add
. So, the following sequence will produce the rebase error you mention:
git add <file with conflict>
git commit -m "<some message>"
git rebase --continue
While, the sequence below runs without any errors, and continues the rebase:
git add <file with conflict>
git rebase --continue
It might be possible that git add -A
with the "All" option is creating a similar situation. (Please note, I am very inexperienced in git, so this answer may not be correct.) To be safe, the git rebase --skip
seems to also work well in this situation.
Note: Git 2.0.2 (July 2014) has fixed one case where a git rebase --skip
would get stuck and wouldn't be able to go on with the current rebase.
See commit 95104c7 by brian m. carlson (bk2204
)
rebase--merge
: fix --skip
with two conflicts in a rowIf
git rebase --merge
encountered a conflict,--skip
would not work if the next commit also conflicted.
Themsgnum
file would never be updated with the new patch number, so no patch would actually be skipped, resulting in an inescapable loop.Update the
msgnum
file's value as the first thing in call_merge.
This also avoids an "Already applied
" message when skipping a commit.
There is no visible change for the other contexts in which call_merge is invoked, as the msgnum file's value remains unchanged in those situations.
$ vi src/com.... { verified, no >>> or <<< left, no merge markers }
$ git rebase --continue
Looks like you forgot to git add
your changes...
After a rebase with lots of conflicts (long git status
) I couldn't figure out what it was that I was supposed to stage. I use Git integrated with PhpStorm and it didn't show any unstaged files.
git add .
didn't solve it but this comment recommended calling
git diff-files --ignore-submodules
. That showed three files I had to specifically git add and that did the trick.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With