Today, I stumbled upon a tweet where a developer wrote that someone on their team didn’t know how to resolve Git conflicts. In this post, I’ll be exploring this topic. When I face such a challenge, I like to delve deep into the problem and understand how I can master the given issue.
To understand the problem, we first need to go back to the basics of Git, specifically understanding branches. As beginners, we usually manage everything on the master or main branch because we are still learning Git. However, as a development team member, things have become much more complex (this might have been the issue in the example mentioned), and we need to open multiple branches.
Why? To grasp the simplest example, consider that we create separate branches for development and testing and only revert to the main branch, the code we release into production. Of course, this has many nuances, as the DevOps CI/CD pipeline adds another layer to it all, but let’s work with branches X, Y, and Z for now. I’ll touch upon these, and finally, we’ll resolve potential conflicts.
How to use checkout?
1. Checkout X Branch: This step involves switching to an existing branch named X. This command changes your current working branch to X.
git checkout X2. Create and checkout Y Branch from X: This command creates a new branch named Y and checks it out immediately.
git checkout -b Y3. Merge Z into Y: To merge changes from another branch Z into our current branch Y, we first must ensure we’re on the Y.
git checkout Y
git merge ZThis command will bring all the changes Z into Y. If there are merge conflicts, you’ll need to resolve them before completing the merge.
4. Open a Pull Request (PR) from Y Targeting X:
This step is usually done through a Git hosting service like GitHub, GitLab, or Bitbucket, not directly via the command line. You’ll navigate to the repository on the web interface of your service, go to the ‘Pull Requests’ section, and create a new pull request. You will select Y as the “source” branch and X as the “target” or “base” branch for the pull request. This means you’re proposing to merge changes from Y into X.
The above process is a typical workflow in collaborative projects using Git, allowing multiple developers to work on different features or fixes while keeping the main (or other target branches) stable.
So, how do you solve Git conflicts if there is one?
Ok, let’s go back to the topic of the Git conflicts. Merging a branch Z into another Y (as in our previous example) can lead to conflicts, significantly if the same parts of the code have been altered differently in both branches. The git merge command itself doesn’t automatically solve conflicts. Instead, it highlights them and asks you, the developer, to manually resolve them.
Here’s a general approach to resolving merge conflicts:
1. Identify Conflicts
When you run git merge Z and there’s a conflict, Git will output a message indicating that conflicts need to be resolved.
2. Manual Resolution
Open the conflicting files in your code editor. Git marks the conflicting areas in the file so you can easily identify them. They are typically marked with <<<<<<<, =======, and >>>>>>> tags. Example:
<<<<<<< HEAD (current change)
Code as it appears in the current branch (Y)
=======
Code as it appears in the branch being merged (Z)
>>>>>>> Z3. Edit the File
Decide how you want the code to look after the merge. This might involve choosing one side’s changes over the other or combining elements from both sets of changes.
4. Mark as Resolved
After editing, save the file. Then, mark the conflict as resolved using:
git add [filename]5. Complete the Merge
Once we have resolved all conflicts and added all the changes, complete the merge with the following:
git commitThis step will open an editor to write a merge commit message. Save and close the editor to complete the commit.
6. Verify:
Testing your code to ensure the merge didn’t introduce any issues is always good practice.
Suddenly, I remembered that episode from the Silicon Valley series, where the teenage cloud specialist, whose job was setting up the cloud, tampered with the code and fretted under the desk because of the problem he had caused. Now, don’t do that!
Resolving conflicts requires careful consideration to ensure that the final code is functional and incorporates the necessary changes from both branches. If the conflicts are complex or you are unsure how to resolve them, discussing with other team members who may have more context on the changes made in both branches is advisable.
Happy Git-ing!
https://docs.gitlab.com/ee/user/project/merge_requests/conflicts.html
Leave a Reply