Ch3. Interactions with other changes
Git is pretty straightforward until we start working with others.
Like you see, it doesn't take long for the git history to start confusing when multiple people are involved. The common scenario we encounter is merge conflicts , which means your changes to the target branch is conflicting. Without resolving it, you cannot merge it. So let's see how to resolve the them with an example.
You start working on your branch feature off the master. If someone updated master while you are working on your branch, master and your branch will start diverging. When it's time to put your change to master, you have to figure out which changes you should take. To do so, follow the steps
- Identify the conflicting parts
Let's run
git status. If there are any conflicts, this command will sayUnmerged path. If you open up those, you can see something similar to this.
<<<<<<< HEAD
// this is some content to mess with
a := b
fmt.Println("test")
=======
// totally different content to merge later
a := c
>>>>>>> Master
=== is the divider between current branch and master in this example.
Think well and decide which parts to take
You want to take either part of it. Or you want to take little bit of each part and combine them together. Situation can vary. So judge based on your context.Now remove symbols
<<< , >>>, ===and commit
Once you determine which parts to take, the rest is simple. Let's say you want to take your current implementation, then delete parts down===to avoid merge conflicts. The last step is to commit change with the meaningful message.
You are good to go! You can do this quickly if you know - which branch you are taking clearly. For example, if you you want to take all changes from master, you can simply run git merge -X theirs master. Be careful about the relative term theirs. The opposite is git merge -X ours master.
Now you learn about merge issues and how to resolve them. You level up once again! For more useful content, follow me @bitethecode or on Github!
Top comments (4)
The challenge with merge conflicts is that it indicates that two people have modified the same area of code, presumably for a reason. The challenge of merge conflicts is knowledge what was changed and how to combine the so both reasons remain intacked.
It is important the goal isn't to just get it to compile.
Sure. That is why we call it 'conflicts'. I talked about how we can resolve them in technical perspectives after talking with other devs and planning which one to take.
My solution is to always check in first & let the other dev handle it. 🤓
That can work up to certain points.. If you are in a position to guide someone through, time to learn depth😉