Resolving Git merge conflicts

Question

A Git repository has been cloned on several developers' local machines. Some changes have been made to the code in the repository. We're now getting the error:

error: Your local changes to the following files would be overwritten by merge:

        public_html/sites/file
        public_html/sites/file1.txt
        public_html/sites/file2.txt
Please, commit your changes or stash them before you can merge.
Aborting

I've read quite a few threads online, and several different options have been suggested. One approach was run:

 git stash
 git pull
 git stash pop

I think I understand the basic principle of stashing. My question is, is this a good solution, and could I run into any issues using this approach? I have a reasonable understanding of web development in general, but I'm a fairly basic Git users and wouldn't have a lot of ability to get myself out of trouble at this point.

Solution 1

git stash is perfectly legitimate, though as Greg said, for some reason fixing the conflicts can get strange. But they are still fixable, you won't actually fubar anything. The command as I know to re-apply the stash is git stash apply, though pop may be an alternative that I'm not aware of (or it could do something different, I don't know, so you probably want to use apply.)

Is there a reason you don't want to commit those changes before merging? Generally that's the right thing to do.

Another option is:

git stash
git checkout -b newwork
git stash apply
git commit ...

This creates a new branch, which will allow you to get your master up to date without conflicts, (checkout master again, then pull or fetch + merge). Then you can merge your branch back with (while still on master) git merge newwork. You can resolve the conflicts on master, while still retaining the work on newwork without any conflicts. This is a bit safer if you are worried about conflicts really screwing things up, but generally, conflicts are just part of the process, so don't worry too much about them.

Solution 2

It's good practice to always commit any local changes before pulling (merging) new code. If you don't commit, then Git doesn't know how you want to manage your local changes. Merge only with a clean working tree.

There may be conflicts in the merge, due to the same files being changed locally and by somebody else. In my experience, resolving conflicts from an actual merge operation is slightly simpler than resolving the same conflict from a stash pop operation.

Solution 3

I have another solution:

git reset --hard FETCH_HEAD

It works in almost cases.