Never fear merge conflicts again - git merge/pull tutorial

What I wish I had known when I started using git.

0:00 - Aborting the merge
0:26 - Understanding conflict markers
1:30 - Automatic merge options
2:38 - Doing a manual merge
3:36 - Understanding complex conflicts
4:09 - Adding the resolved files
4:32 - Completing the merge

LEGAL DISCLAIMER
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Everything here is for informational purposes only. All non-licensed clips used for fair use commentary, criticism, and educational purposes. See Hosseinzadeh v. Klein, 276 F.Supp.3d 34 (S.D.N.Y. 2017); Equals Three, LLC v. Jukin Media, Inc., 139 F. Supp. 3d 1094 (C.D. Cal. 2015).

[philomatics]

Something I really wish I had mentioned in the video:

When you're working on a feature branch, you can avoid a lot of headaches by merging (or rebasing, video on that coming soon) your main branch into the feature branch as often as possible, at least daily. (git checkout YOUR_BRANCH && git merge main). The result of that is that each merge is relatively small, and thus easier to handle.

Unfortunately large and difficult merges are often more of a management than a technical problem. If it's possible to cleanly separate the code into modules, such that it makes sense for these modules to live in different files, then that would be the way to go. In the ideal world you would then both work on your own files, on separate branches, and merge once you're done. Of course it can still happen that you both need to touch the same file (for example when it's glue code), but then at least the conflicts should be pretty minimal.

If it's not possible or sensible to split up into multiple files/modules, then I'd argue that probably this functionality can't really be split up among multiple engineers. I'm actually with Fred Brooks, who argues that the ideal size for an engineering team is very small, around 6 (!) people, even for very large projects. It's just very difficult to split up software projects into separate modules.

Finding the right module/feature boundaries for multiple team members to work on is one thing that separates good from great managers.

Might be an interesting topic for a video - let me know!


I'm also super grateful if you share this video with a friend or colleague :) Have a great day!

[jbragg]

I think many people are very scared of merge conflicts, they think it's a mistake if they had conflicts, that they did something wrong, they panic. It's just a common event when using any type of version control system. 95% of the time, the conflicts are easy to figure out, and with just learning git markers, the concept of "our code" and "their code", it's easy stuff.

The thing that kinda sucks is if you're working on a feature branch for a long time, and let the main branch get very ahead of your branch (lots of new code to merge into your branch to update it). If many things changed, it's likely many conflicts will happen and fixing them will take a while. That's why as a rule of thumb, you should merge the main branch into your branch very often. It will make it much easier to handle little conflicts if they happen, and also your branch makes more sense because it's not based on an outdated version of the project.

[Yem]

One of the things I still have issues with to a certain extent, is understanding why main and branch1 merging doesn't result in a conflict

Say for example I have an index.htm file with a header that says "Hello World", I initialize it with git init + add + commit, no issues there
I create a branch; call it b1 from main and I change the same exact line from Hello World to Good Bye World, I add + commit, no issues there
I then switch to main and merge the two, even though I'm literally modifying the same exact line, I don't get merge conflicts from it, which is still something im trying to comprehend but having issues with

Great explanation on your part mate, especially when solving merge conflicts

[andrewpoloni]

Another superb video! I've often said that how easy/hard git merges are depends on your particular git configuration and which tools you have set up to be the default diff/merge tools. If you have a tool that lets you do two- or three-way comparisons of the file changes in your branch/main branch/merged file it tends to make life a lot easier than having to edit a single file with the merge markers.

[nico]

Seeing this in VS Code, I must say the merge editor in JetBrains products is so much better. Especially at handling conflicts when you need code from both in multiple lines. I think the same for the git integration in general. I also know how to do it from the CLI, but I prefer the GUI because it's very convenient.

[shivamshandilya]

Your Channel will blow up, Keep at it!

[TheThirdWorldCitizen]

I do most things on the terminal, but certain actions like merge conflicts I just use the GUI to visualize the merge conflicts better and it detects the changes automatically once you’re done.

[unsorted]

Nice quick explanation and I love the animation too. Thanks a lot.

[mikelinsi]

Sometimes it was difficult to explain what it really means, so that it’s not just a technical issue or bad behavior that happened. It really meant that the feature the developer worked on for weeks might be built on older, already out-of-production code, and they need to refit their code. Sometimes I just see that they accept their side without thinking about this...

[ashkanahmadi]

Excellent video and explanation. Thank you

[lokith.s]

I watched all videos on your channel and its very useful. Please do more videos like this. Waiting for upcoming videos 🤝

[kezzyhko]

I used Sublime Merge and had no idea that those conflict markers are what git actually writes to a file

[kernelverflow]

Great as always :) thx for the git videos. There is always something new to discover

[Anton-vuou]

You can also use git merge --continue; after you added the fixed files. It may be usefull, because it looks like GitLab does not recognize the merge otherwise and won't show show you it in the repository graph (visualization of branches and commits).

[onceuponatime]

Good video! 😊 In the company we use beyond compare for merge conflicts etc.
I'm now again at a point, when I was stashing my (10+) changes in Git Extensions (by staging relative changes and then used stash staged - to get the stash in portions), updating and building the modules, and then step by step applied the stash portions again (which I also - if there are more changes, copy into a local file) - handling the merge conflicts one by one). But often, when it's the same file and also the same line where the changes are, I get overwhelmed, apply the changes of others, and then copy the code from stash or backup into the file again. don't know, maybe I need to checkout some guides for git extention and beyond comoare by time 😅

Don't work much with git on the command line, but its interesting - like a look under the hood (on what the gui does without me seeing it) x)

keep on doing that great videos ❤😄

[Velocoder]

Would be great if you can explain 3-way merge using some UI merge editors. They have their own way of naming things that always confuses me.
Great explanation! Great channel.

[DrEpico]

What I don't understand as a git beginner is that how I should work on a project in a way that doesn't contradict with other people's code
Like if I work on a file that someone else is working on too, wouldn't that constantly mess up stuff? Or should I make a different branch for myself in the first place and etc?

[surviplays]

A long time ago I had to spend a week to merge conflicts due to upgrade whole core, cuz one of our team merged it incorrectly, but there was about hundreds of files, some of them had full code rewrite, some new or deleted. And my ide haven't nice dialog that have now to make this process easy)

[nium-xp]

What's the extension that shows the parameter name in functions call?

[TheExileFox]

When I started using git, I found it really awkward to resolve "detached head" problems which popped up after making some really tedious changes to my code.