Git and merge conflicts explained for the non-technical
You’re a project manager on a software engineering team. You plan, monitor and close out projects. You keep the team moving forward and remove blocks. At some point the engineers might declare they have a merge conflict that needs to be resolved before they can move forward.
If you aren’t quite sure what a merge conflict actually is and don’t understand why it needs to be resolved, this short video is for you.
Let’s start by explaining what git is and how the engineers use it.
Git, sometimes stands for ‘Global Information Tracker’ and that is exactly what it does. It tracks who wrote which sections of code and when.
Let’s walk through a typical scenario. An engineer is working on a feature, let’s call it ‘feature A’. She spends all of Monday writing code on her laptop, that is, her local computer. The Git way to ‘save’ code is to commit it to a branch. Let’s break that down. Or rather, let’s build that concept up.
A ‘branch’ is a version of the code base that is being worked on. Many people can contribute to a single branch. There must be a default branch. It is typically called ‘main’. Our engineer will copy the main branch onto her local computer.
When our engineer is ready to start working on feature A, she will make a new branch off of main, called ‘feature_A’. That means everything in the main branch will also be in her feature branch. Now all the code she writes for feature A, should get saved to the feature_A branch. That is, she should commit it to the feature_A branch.
Now that our developer has saved her work by committing it, she can work on something else by simply switching branches. Git will keep track of which part of the code base changed and when. However, if her computer would suddenly kick the bucket, go belly up, self implode (you get the idea), she would lose all the work she had spent the day working on, as it was only saved on her local machine.
Cue version control!! Version control platforms host our code. This allows developers to save their code to a remote repository where it can be accessed by others. The engineers on the team, all access the same remote repository, think GitHub, Bitbucket etc. By pushing the branch to the remote repository, she is both backing up her work and sharing it with her team.
Another engineer, is also working on feature_A. That engineer will pull the feature_A branch from the remote repository onto their local machine and start working on it. Just like our first engineer, when he is ready, he will commit his code and push it to the remote repository where it will be merged into the feature branch, along with everyone else’s code.
That brings us to our original question. What is a merge conflict? When multiple people are committing code to the same branch, there is potential for their code to conflict. That is, multiple engineers modified the same line of code and git doesn’t know which is the correct version. This is a merge conflict.
To resolve it, the engineers must look at each line of code that is in conflict and determine whose code should go into the code base. Depending on the complexity of the changes, resolving the merge conflict can be a quick process or a long, arduous task. In either case, the developer must concentrate to ensure that they are not removing necessary code. They also must resolve the merge conflict before they can continue.
With that, you should now understand how software engineers use git and version control software and why merge conflicts occur.