An unmerged path means you have run git merge, or the equivalent of git merge, and it tried to merge two different sets of changes to that file, but failed.
This means that you must now combine the two sets of changes in that file. Git will have left behind, in your work-tree, its best effort at combining the two sets of changes, but Git is quite certain that what it left behind is not correct. You then mention:
let's say in development config is set to localhost, and in production server config is set to server ip ...
If the conflict is over the IP addresses in a configuration file, Git is right: it will not have resolved the conflict properly.
The danger is that by putting these files in as version-controlled files, a future git merge operation will think it has resolved a merge correctly when instead, it has put the wrong IP address in.
Configuration files should not be version-controlled. See Committing Machine Specific Configuration Files for one good way to do this. There are others; e.g., you can commit config.sample rather than config.php and have config.php as an ignored file, that each user must write based on the version-controlled config.sample.
In the meantime, however, you still have to clean up the existing mess. The merge conflict occurred because these two files are already version controlled. Unless version-controlling them was your own mistake as part of writing the one change you just made—which seems impossible1—you should undo the version-controlling as a separate operation (independent of other changes).
Thus, you might use this procedure: Open the two conflicted files backend/config/main.php and frontend/config/main.php in your editor and check the configurations carefully. Fix them as needed, and save the result. Then use the commands:
git add backend/config/main.php
git add frontend/config/main.php
to put the corrected versions into place. It's likely that they now match the previous versions on the current branch, so that git status will no longer show them at all. (If git status does show them, use git diff --cached to see what you have changed.) In any case, this will mark the two files as fully resolved in the index. You can now make a new commit. If the two config files match the ones in the current (HEAD) commit, the only thing changed in your new commit will be the file backend/modules/company/controllers/XyzController.php.
(Remember, a commit has a complete snapshot of every committed file. The next commit you make is based on whatever is in the index right now, i.e., whatever you git add. Once you make the commit, the new HEAD commit and the index now match, so that git status says that there is nothing to commit.)
In order to get a merge conflict, the file must be present in both tip commits, or in the merge base and one tip commit, or in all three commits. Remember that a merge works from three versions of each file:
- the merge base version, which is the one that was in place before either branch began to diverge;
- the
--ours version, which is the one in the HEAD commit; and
- the
--theirs version, which is the one in the other branch tip.
If you mistakenly added a configuration file to your branch, but it was not present in the base and is not in --theirs, there would be no conflict. Therefore, it must be in at least one of the other two commits. Presumably you did not write the base version yourself, nor did you make the other branch-tip commit. If that's true, you could not have caused this configuration-file-is-now-version-controlled issue in the first place.
