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 have more content on git in the works, I'm also working on a really cool git cheatsheet. Might take a bit though. If you want to get notified when that comes out, go to my website philomatics.com/ and leave your email there. I'm also super grateful if you share this video with a friend or colleague :) Have a great day!
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.
Better yet: Break up the work into small steps. The smaller, the better. It will improve the design and changeability of your code as a side effect. Strive to improve this gradually. From pull requests that are open for weeks, to days, to hours. Next step is to under an hour and to minutes. But at that point you should switch from pull requests to pair programming and commit to the main branch directly. Also, good test coverage and TDD is a requirement for this step. By that point, you'll have close to zero merge conflicts.
Those markers are also in older vcses like subversion. The big soft for me moving to git was in "ours" and "theirs" they don't always work the most intuitive way around.
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.
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.
Hey, thanks for your comment! Actually I didn't use the VSCode merge editor in this video because I kinda wanted to stay editor agnostic. Maybe I should do a GUI comparison in the future.
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.
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
Great question! So in your example, b1 modifies that line, BUT since you already started with "Hello World" git knows you want to overwrite it. The way you'd get a merge conflict would be this: Same as your scenario, but before the merge, you switch back to the main branch and do an additional commit also changing that same line, let's say to "Hi World". Now when you merge, git has conflicting information: one commit says "change that line to Hi World" and the other says "change that line to Good Bye World". Git needs your intervention to know which of those changes to pick.
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...
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).
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?
Great question! Unfortunately that's 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. I also generally recommend merging or rebasing often, at least daily. 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. In practice, this is quite difficult to judge correctly in my experience, and finding the right module/feature boundaries for multiple team members to work on is one thing that separates good from great managers.
If you have a decent tech lead you might choose work to run in parallel that doesn't touch the same files/classes. If you have a decent people lead then you might talk to each other or pair to resolve issues. You can't resolve the topic of conflicts by yourself, it's fundamentally a coordination issue.
Make small changes and merge quickly. The bigger the pull request is, and the longer it's opened, the greater likelihood that there will be merge conflicts, and the more difficult they become to resolve.
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 ❤😄
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)
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.
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.
Pretty useful video. I have issues merging because some changes doesn´t mark as a conflict and git just delete something that i want to keep, or keep something y have removed. Like Strings I change, it use de merging the one but i want the HEAD one, or when a function disapeared after a merge. And yes they where in nearest lines, is not like i change the order in the code or something. It just don't marked as conflict, just merge that cases.
I asked for this video as a comment on your other video but i have to say i'm a little sad. I thought you might have some tricks about how to use tools to visually parse diffs more effectively or something. The format of conflicts always breaks my brain bevause theyre usually much latger and much more conplicated than these examples. I'm guessing there arent any special tools or techniques that I'm unaware if then. I've tried using the conflict resolution editor but that has always made the problem worse somehow.
why there is merge conflict in example.html and example.js, I mean their name is same but not extension which means they are different files not same! clear my doubt anyone
Good question! Conflicts happen when the *changes* in two commits are conflicting. So here I set up the repo in such a way that the merge will cause conflicts, because the files were modified on both branches. So it's really not about the two different files (they are completely unrelated in terms of git), but the changes made to them on the different branches. Does that help? Feel free to ask a follow up question :)
@@philomatics means .html and .js both present in main and other branch ? and have change in same line in respective files, so the .HTML and .js are not interlinked but to the other branch .HTML and .js???
Oh that's a good point! In that case I guess you could just git rm --cached the file and commit. Then add it to gitignore in a fresh commit right after merging.
I have to disagree with @bart2019. 3-way merge tools are great, but they are one more dependency and tend to suffer from maintenance issues, performance issues, quality issues, or are not FOSS. I used to swear by kdiff3, until I realized it didn't work on Linux, got discontinued/spotty support on Mac. The few merge editors I tried after would struggle with large files or large repos (>100MB), and become unresponsive on a MacBook Pro. Understanding how to deal with conflicts directly in the source files is a boon, and allows you to work in various environments.
Oh sorry to hear that! What were you expecting? What problems are you running into when merging? Just comment here next time you are stuck and maybe I can help :) Or send me an email (check the YT about page).
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 have more content on git in the works, I'm also working on a really cool git cheatsheet. Might take a bit though. If you want to get notified when that comes out, go to my website philomatics.com/ and leave your email there.
I'm also super grateful if you share this video with a friend or colleague :) Have a great day!
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.
Great advice, fully agree!
Better yet: Break up the work into small steps. The smaller, the better. It will improve the design and changeability of your code as a side effect. Strive to improve this gradually. From pull requests that are open for weeks, to days, to hours. Next step is to under an hour and to minutes. But at that point you should switch from pull requests to pair programming and commit to the main branch directly. Also, good test coverage and TDD is a requirement for this step. By that point, you'll have close to zero merge conflicts.
Fast Forward and Rebase FTW
Those markers are also in older vcses like subversion. The big soft for me moving to git was in "ours" and "theirs" they don't always work the most intuitive way around.
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.
Your Channel will blow up, Keep at it!
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.
Hey, thanks for your comment!
Actually I didn't use the VSCode merge editor in this video because I kinda wanted to stay editor agnostic.
Maybe I should do a GUI comparison in the future.
@@philomatics Yeah, that would be an interesting video imo
Exactly, i also feel the same. The jetBrains git merge is too good. I want to use vim, but the Gui is very convenient.
For merging, I personally refer kdiff3, old but nice tool
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.
Yeah the GUI is really useful for merging!
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
Great question!
So in your example, b1 modifies that line, BUT since you already started with "Hello World" git knows you want to overwrite it. The way you'd get a merge conflict would be this:
Same as your scenario, but before the merge, you switch back to the main branch and do an additional commit also changing that same line, let's say to "Hi World". Now when you merge, git has conflicting information: one commit says "change that line to Hi World" and the other says "change that line to Good Bye World". Git needs your intervention to know which of those changes to pick.
Nice quick explanation and I love the animation too. Thanks a lot.
I used Sublime Merge and had no idea that those conflict markers are what git actually writes to a file
Yeah I think a surprisingly large number of people don't know this :D
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...
Should have mentioned gitconfig conflict style to get more information in the diff.
[merge]
conflictstyle = diff3
Cool suggestion, thanks!
I watched all videos on your channel and its very useful. Please do more videos like this. Waiting for upcoming videos 🤝
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).
Great as always :) thx for the git videos. There is always something new to discover
Do not finish the merge with commit, rather git merge --continue, then automatic commit message is applied
Cool tip, thanks for sharing!
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?
Great question!
Unfortunately that's 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. I also generally recommend merging or rebasing often, at least daily.
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.
In practice, this is quite difficult to judge correctly in my experience, and finding the right module/feature boundaries for multiple team members to work on is one thing that separates good from great managers.
@@philomatics So there is no escape from conflicts after all xD
Thank you for the insightful reply :))
If you have a decent tech lead you might choose work to run in parallel that doesn't touch the same files/classes. If you have a decent people lead then you might talk to each other or pair to resolve issues.
You can't resolve the topic of conflicts by yourself, it's fundamentally a coordination issue.
Make small changes and merge quickly. The bigger the pull request is, and the longer it's opened, the greater likelihood that there will be merge conflicts, and the more difficult they become to resolve.
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 ❤😄
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)
Excellent video and explanation. Thank you
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.
Thanks for the suggestion and kind words! I was considering a git GUI comparison for the future, maybe I can include that there :)
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.
Pretty useful video.
I have issues merging because some changes doesn´t mark as a conflict and git just delete something that i want to keep, or keep something y have removed. Like Strings I change, it use de merging the one but i want the HEAD one, or when a function disapeared after a merge. And yes they where in nearest lines, is not like i change the order in the code or something. It just don't marked as conflict, just merge that cases.
I asked for this video as a comment on your other video but i have to say i'm a little sad. I thought you might have some tricks about how to use tools to visually parse diffs more effectively or something. The format of conflicts always breaks my brain bevause theyre usually much latger and much more conplicated than these examples.
I'm guessing there arent any special tools or techniques that I'm unaware if then.
I've tried using the conflict resolution editor but that has always made the problem worse somehow.
Yeah unfortunately merging can get pretty messy. Big merges _are_ time consuming, there is no way around it. Merge early, merge often!
What's the extension that shows the parameter name in functions call?
Great question :) It's just a setting. Search the VSCode settings for "Inlay Hints", and scroll down for various options in JavaScript and TypeScript.
Hi, quick question : instead of making commit to resolve the merge why can't i just do `git merge --continue` ?
Sorry for the late reply! That works too, actually :)
Off topic, but how are you doing the cool graphics?
Thanks! In this video it's just video editing software (Camtasia). I also used Motion Canvas in another one.
why there is merge conflict in example.html and example.js, I mean their name is same but not extension which means they are different files not same!
clear my doubt anyone
Good question! Conflicts happen when the *changes* in two commits are conflicting.
So here I set up the repo in such a way that the merge will cause conflicts, because the files were modified on both branches.
So it's really not about the two different files (they are completely unrelated in terms of git), but the changes made to them on the different branches.
Does that help? Feel free to ask a follow up question :)
@@philomatics means .html and .js both present in main and other branch ?
and have change in same line in respective files, so the .HTML and .js are not interlinked but to the other branch .HTML and .js???
Yup, that's correct!
@@philomatics thanks
The problem is when you have a conflict in files that the editor cannot open. Like when you forget to set cache files in the .gitignore.
Oh that's a good point!
In that case I guess you could just git rm --cached the file and commit. Then add it to gitignore in a fresh commit right after merging.
More git ❤
Great !
Always overwrite and prepare a bag of marshmallows for roasting over the fire...
You don't need a stick, you'll roast right with it...
In my opinion it's a much better idea to use a 3-way merge tool to resolve conflicts instead of fixing this junk by hand.
Thanks for the suggestion! Might do a follow up on the best GUIs. What's your favorite merge tool?
I have to disagree with @bart2019.
3-way merge tools are great, but they are one more dependency and tend to suffer from maintenance issues, performance issues, quality issues, or are not FOSS.
I used to swear by kdiff3, until I realized it didn't work on Linux, got discontinued/spotty support on Mac. The few merge editors I tried after would struggle with large files or large repos (>100MB), and become unresponsive on a MacBook Pro.
Understanding how to deal with conflicts directly in the source files is a boon, and allows you to work in various environments.
Which tool are you using?
thank you !
3:15 Hilarious 😂
I used to fear merge conflicts.
now I fear rebase
I've got the perfect antidote for you ;) Video will be published in 1-2 weeks!
Do cherry-pick, please ❤
Thanks for the suggestion! Will consider it! :)
sad, i thought it would be something else
Oh sorry to hear that! What were you expecting? What problems are you running into when merging? Just comment here next time you are stuck and maybe I can help :) Or send me an email (check the YT about page).
How is :void (...data) these things are showing? Any extension?