I'm about to commit a final checkin in my project before I merge to master. I've staged my changes, but when I try to commit, I get an error about conflicts:
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
I'm not 100% sure, but is "unmerged" another way to say "has conflict"? If so, I have no idea where these conflicts may be. All of my source files are either A and M, and all of the ones in the staging area are the same.
Can someone offer a simple way to track these down?
I'm not 100% sure, but is "unmerged" another way to say "has conflict"?
Yes. Git refers to files as unmerged when they contain conflicting changes that need to be reconciled.
The error message you've posted is for example what you get when you try to finalize a merge without resolving its conflicts first. In your case, it might be that you had an on ongoing operation that integrates changes (like merge, rebase, cherry-pick, revert) that wasn't completed.
In order to tell which command is still being run, you can open Git CLI from your repository, and check the operation piped to your current branch. For example, if you had an ongoing merge on the master
branch, you should see (master|MERGING)
. Alternatively, you could run git status
and be presented with the following message:
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
To get a list of conflicting/unmerged files, you can use either git ls-files
or git diff
:
git ls-files -u
git diff --name-status --diff-filter=U
Once you've detected your conflicts, you should resolve them, stage them, and finally commit.
If you've made some other changes amid the ongoing command (merge, rebase, or other), and you don't want them to be part of the final commit, you can stash them. This operation will save your further changes into a stack to be later reapplied, leaving you with only the modifications you want to include in the operation's commit. Once the commit succeeds, you can re-apply the stashed changes to your working directory, and create a second commit.