Handling Merge Conflicts
When you are working with a team on a project, you will likely experience merge conflicts. Git does not know which version of the code to keep, so you have to help Git by manually specifying which version to use.
Two common conflicts you may encounter are:
- Edit collisions: when you and a team member edit the same section of code in the same file.
- Removed file collisions: when you edit a file, but a team member deleted the file from the repository.
Resolving Edit Collisions
For example, if you edit code on line 5 in Square.java, and your teammate made a change on line 5 of the same file and pushes his or her changes to the remote repository, you will experience an edit collision when you try to pull your teammate’s changes from the remote repository. That means your version of the file conflicts with your team member’s version of the file.
If your pull request results in a CONFLICT, then you will need to resolve the conflict.
For example, in Git Bash:
In the figure above, Git says that a conflict exists in the Square.java file.
Similarly, in eGit:
In the figure above, eGit says that the pull results in the CONFLICTING state.
To resolve the conflict, you should:
- Switch back to Eclipse.
- Right-click your project in Package Explorer.
- Choose Refresh to ensure Eclipse has refreshed to show the updated files that were pulled from the remote repository.
Eclipse will show red problem markers in the files that conflict.
Opening Square.java reveals:
Conceptual Knowledge: Collision Resolution Options
When a collision happens, Git adds a special block of text into the code file. These lines of text that Git added are called conflict markers. The block of text contains both versions of code where the conflict occurred. For example:
- Everything between the «««< HEAD and ======= lines presents the version of code in your local repository on your machine.
- Everything between the ======= and »»»> [checksum] lines presents the version of code that was pulled from the commit snapshot represented by the given SHA-1 checksum hash.
Now, you have three options:
- Keep your local changes
- Take your teammate’s changes
- Change the conflicting code to something completely new
In Eclipse, manually delete the conflict markers, and edit the code to be the final version you wish to save.
Now that you have manually fixed the collision in your code file:
- Save the updated
Square.java, which now has all conflicts resolved. - Add the
Square.javafile to move it to your staging area. - Finally, commit to record a snapshot of your updated code into your local repository.
Now, you should push your changes to your remote repository so that your teammates can pull the updated code and continue working with the most up-to-date codebase.
Resolving Removed File Collisions
You may encounter removed file collisions if you edit a file, but a teammate deletes the file in the remote repository. Git does not know whether to keep your edits or delete the file entirely.
When you pull your teammate’s code from the remote NCSU GitHub repository, you may see a message similar to:
CONFLICT (modify/delete): Square.java deleted in HEAD and modified in 6d4cd552fd63ce5856145171c2382767088104a8.
Version 6d4cd55 of Square.java left in tree.
Automatic merge failed; fix conflicts and then commit the result.
You have two options:
- Keep the edited file: To keep the edited version of the file, add the file to your staging area, then commit the code again to re-establish its presence in the repository.
- Delete the file:
- To delete the file from the repository using Git Bash, use the
git rm [filename]command. - To delete the file using eGit, right-click the file in Package Explorer and select Team > Remove from Index. Then, right-click and Delete the file in Package Explorer
- Now, commit so that Git knows the file has been deleted from the repository.
- To delete the file from the repository using Git Bash, use the
Resolving Conflicts on Configuration Files
Conflicts can also happen in project configuration files. For example, the configuration files .project and .classpath are required for Eclipse to recognize your project as an Eclipse project, but the files are not listed in Package Explorer. Instead you can see them on your file system.
If you have a conflict with no visible conflict markers in Eclipse, the conflict may be on a configuration file. You will have to resolve the conflict on your file system using a text editor and Git Bash.