After fixing conflicts git still complains?

I usually rebase when I pull in changes from my teammates, and often time I have conflicts:

...
CONFLICT (content): Merge conflict in app/views/search/index.html.erb
Auto-merging public/stylesheets/application.css
CONFLICT (content): Merge conflict in public/stylesheets/application.css
Failed to merge in the changes.
Patch failed at 0001 organizing

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

So after opening eac开发者_如何转开发h file with a conflict, fixing it then committing the fixed files:

~/Projects/myApp[956f6e1...]% git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

I still get the same error...

~/Projects/myApp[64b3779...]% git rebase --continue                         
Applying: organizing
No changes - did you forget to use 'git add'?

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

I've sort-of always had this problem, but I guess never really chose to address it, I would I always just get lazy and git rebase --skip.

How do I actually resolve the conflict the right way?

So after opening each file with a conflict, fixing it then committing the fixed files...

The problem is that you aren't supposed to commit the fixes. If a.txt has a merge conflict, then your shell log should look like:

$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue

Calling git rebase --continue will take care of the commit itself.

I'm not sure how to "get back" to before your commit, when you're in the middle of a rebase. git reset --hard HEAD would probably do the trick, but personally I'd feel safer just going straight to git rebase --abort and starting over without committing in the middle.

I agree with Mark Rushakoff that fixing commits should not include committing them.

There is at least one other way that git will continue to say that "You must edit all merge conflicts and then mark them as resolved using git add" even after you have done just this. This may occur if you remove files from git version control, but leave the unversioned file sitting in your working tree and then try to perform a rebase.

I was able to fix this problem as follows:

1. Terminate rebase with git rebase --abort
2. Determine offending file by looking at git status
3. I moved my unversioned files to my tmp directory
4. Redo the rebase - in my case git svn rebase
5. If you want the unversioned file hanging around, move it back where you want it (I left mine in my tmp directory)

Hope that helps.

When this happened to me, I managed to solve it after realizing I had edited (and added to the index) during the rebase a file which does not have a conflict, I guessed this might be wrong. So I used git checkout -- <filename-with-no-conflict>, and then git rebase --continue, and it worked.

With Git 2.14 (Q3 2017), this kind of advice given in a rhetorical question that does not require an answer (like "did you forget to use 'git add'?") will be no more.

See commit 6963893, commit 9932242, commit 6c48686 (11 May 2017) by Jean-Noel Avila (jnavila).
^{(Merged by Junio C Hamano -- gitster -- in commit e638108, 29 May 2017)}

usability: don't ask questions if no reply is required

When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following:

    git: 'stahs' is not a git command. See 'git --help'.
    Did you mean this?

    stash

and then exits.

The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.

The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the yes program.

The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level.

To improve the general usability of the Git suite, the following rule was applied:

if the sentence

• appears in a non-interactive session
• is printed last before exit
• is a question addressing the user ("you")

the sentence is turned into affirmative and proposes the option.

In your case, "did you forget to use 'git add'?" is now replaced with:

You should 'git add' each file with resolved conflicts to mark them as such.
You might run git rm on a file to accept "deleted by them" for it.

Much clearer.

I had merge conflicts that I had addressed, yet I was still seeing

You have unmerged paths.

All I had to do is git add <file that had conflicts> and everything was good to go from there.

I found myself in the same boat and git rebase --continue didn't help. Running rm -fr .git/rebase-apply fixed the issue though