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.
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.
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.
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.
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)
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.
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 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.
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.
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.
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
Your Channel will blow up, Keep at it!
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 :)
Nice quick explanation and I love the animation too. Thanks a lot.
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!
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 ❤😄
I watched all videos on your channel and its very useful. Please do more videos like this. Waiting for upcoming videos 🤝
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
Excellent video and explanation. Thank you
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)
Great as always :) thx for the git videos. There is always something new to discover
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.
thank you !
More git ❤
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.
Should have mentioned gitconfig conflict style to get more information in the diff.
[merge]
conflictstyle = diff3
Cool suggestion, thanks!
Do not finish the merge with commit, rather git merge --continue, then automatic commit message is applied
Cool tip, thanks for sharing!
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!
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?
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!
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 :)
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...
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
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.
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.
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.
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).