Really appreciate you saying that. It means a lot coming from someone like you with so much experience. If you have a chance to share this video with someone who might benefit, please do. Cheers!
This combination of a simple description of the processes with a clear, simple visualization is gold. Many professional coaches should learn from this. I haven't seen such a good way to explain processes that can be easily overcomplicated for a long time. I bow to such skills.
I'd like to think of both as merging, but done differently. Here's how: "Git merge" from a current branch into the target branch is when Git takes the latest changes of the current branch, then take the latest changes of the target branch and combine them. The new combination is made into a new commit and placed as the latest commit of the target branch. Git will still keep around the history of all the commits that had been made up until the merge of either branch. "Git Rebase" from current branch into target branch is when Git first takes all the commits from the current branch, lines them up in the order they were made and puts them aside for now. Then Git takes the oldest commit from current branch and "merges" it with the latest commit on the target branch by doing it like a regular merge: combing the changes, make a new commit that represents those combined changes then places that new commit as the latest commit on the target branch. Then Git moves on the second oldest commit on the current branch and repeats the process. All the way until the latest commit of the current branch is merged. But remember, the current branch is still set aside, what will Git do with those commits that have effectively become duplicates? Git will just delete those commits, hence why history has been rewritten. Hope this helps
Actually rebase removed those commits, using a delete word is not appropriate here. Once a commit has been made you can't delete them. But you can remove it from the your branch or anywhere in the history.
Hey man, amazing video with great illustrative animations out there. There's just one thing which I found confusing. So in most of the scenarios that I have worked in, the git workflow looks something like this: 1) Create a feature_branch from main: `git checkout -b feature_branch`. 2) Makes changes to your feature branch: `git add -A && git commit -m "Your commit message"`. 3) During the development process some changes were pushed and merged to the REMOTE main branch. So you need to sync your LOCAL main with the REMOTE main: `git checkout main && git pull origin main` Once that's done... 4) You checkout your feature_branch and merge the updated local main with your feature_branch: `git checkout feature_branch && git merge main` 5) You push your local feature_branch to remote and create a pull request: `git push origin feature_branch` In this workflow we can probably replace the merge thing in step 4 with a rebase thing, if this feature branch is being worked on by a single contributor. What confuses me in the video is that at 5:40 : when we are on the feature branch we run `git rebase main` and then we checkout to main and run `git merge feature_branch`. Maybe that's done to illustrate fast forwarding merge here but in a production workflow isn't it discouraged to merge directly onto the main branch? Let me know if I missed a point or something.
Your absolutely right: in many production workflows you'd let the PR process do the work of integrating of your changes into main instead of doing it yourself like I demonstrated in the video. I didn't want to make the video too complicated by trying to introduce PRs into the mix, but I feel like creating a video specifically covering PRs and code review could be a good idea.
thank you! clear and easy to understand! I am a fan of rebasing, and this video highlighted some of the value in the the other side. my contribution would be to suggest (if you want to maintain a linear history) that if there are multiple people working on a side branch you should be creating your own local branch from that and rebasing only the local branch on any changes pushed to a shared side branch. that way you can fetch and create review additions to it and continue to with your branch locally. and squashing + incremental commits is your friend!
As a single dev , I only ever use rebase amd NEVER merge just to keep the history strictly linear , however this is a luxury that larger teams might not have . The tip about only using rebase for your own local work is 100% the right way to use it , imo .
Great video and explanation! I honestly can't think of a scenario where I'd want to rebase, versus just using merge. The risk outweighs the benefit, and honestly the overhead of a merge process on your local repository is moot. Just my two cents.
Thank you for this great explanation. To clarify, at 9:18, you say "use rebase to re-anchor your feature branch onto baseline". If I understand correctly, more accurate would be to say "use rebase to re-anchor your feature branch THAT WAS NEVER PUSHED TO THE REMOTE onto baseline"? This would mean, check git branch -a and if you dont see your local branch in remotes, you are safe to use rebase; otherwise, use git merge.
I quite like a semi linear approach. If I have a release/feature branch that multiple people are working on, rebase to keep in linear. Then when then when you want to merge to master, do a rebase and then merge with no fast forward. This way if you use gitversion, your main branch only has one commit per release but you have full history of commits for each release without a bird nest.
I'm literally working on a video about merge conflicts right now! In the meantime the process is pretty similar to cherry pick conflicts if you want to check out my video on that: th-cam.com/video/aUeNbpSkY8k/w-d-xo.htmlsi=EWbgwrKwbulROvID&t=131
Hi there, I’m new to collaborating in a team using git. I want to understand the best practices of branching or pulling. Here's a scenario: Time 1: A created a feature branch based on origin master. Time 2: A worked on 1 commit on the feature branch. Time 3: There is a new commit (maybe a merge) in the origin master branch. Time 4: The next day, A wants to continue to work on the feature branch. Question: 1. Should he do a git pull in the morning before doing his work? 2. Also, after the pull, how should he incorporate the changes in master into his feature branch? Or should he? 3. Lastly, if the changes in master totally removed some main functions where his feature branch is based on, what should he do? Thank you!!
I absolutely agree with what you said towards the end and that's what I like to do: rebase on personal feature_branch, merge the feature_branch on main. But how can we do this when doing PRs? I mean...you can do rebase and merge, but if there are conflicts, who should deal with them? How to organise with the team?
I’d say (personally) since you’re the one merging into existing work, then you’re on the hook for making sure it’s compatible (I.e. resolving conflicts). That said, I don’t believe you should be entirely responsible for figuring out how to resolve if the original authors are more authoritative on the files that are in conflict. Still, even if others help you figure out what to do, you’d still have to author it IMO
Amazing video.. Was struggling a bit with conflicts and the log and decided to dedicate an hour for a couple videos to once and for all kill all the missing pieces in my mental model even though I use git for years... One thing that wasn't 100% clear is at the end of the video the "recommended workflow" tells you to rebase your branch and then merge it when ready, but that doesn't apply if the branch is on remote and has more people working on it correct? That would mean that remote branches should never get the latest changes from their parent branch unless absolutely necessary, and in that case you'd need to merge from the parent branch.
Right, that would necessarily apply if multiple people are working on the same remote branch. Like you said though, in those cases you can merge main INTO the remote branch - you’ll just end up with a merge commit which isn’t too bad.
I always squash and never allow teammates to work on my branch. This way you maintain main branch clean with only feature commits and avoid conflicts with teammate locally. The only use case I had was when I was introducing a big feature >100 files and split my PR into 6, then I was rebasing branches in order of building block of the feature, where last branch was rebased into main feature branch after reviews of my peers.
I use Apple Motion to create the animations. Then stitch all the animations together with Final Cut. It’s a bit of a manual process unfortunately - these videos take me a very very long time to make lol
Okay, now that I actually know what Rebase is, number one, the name makes a lot of sense. You're "rebasing" where your branch starts. But two, this doesn't seem to be an accurate history of work anymore. We're pretending that I started my work after whoever got their changes into main, somehow that feels wrong.
Sounds like you understand rebase pretty well - the good and the bad ;) But yeah in all seriousness, pretending you started your work somewhere else is a caveat you need to account for especially when working with others.
@MobiusCoin Sure it's not an accurate history in the sense that it doesn't show who did what work when. But the question is, does that matter? Chances are your company has that kind of history available in other places, like Jira or a similar software. The real point of source control is to document the history of when the code changed, not when the code was actually typed into a file. If you think about it like that, no real "history" is lost in a rebase vs a merge. If I merge my branch, main will have my code from that point on. If I rebase and fast-forward merge, the same thing will happen.
@@joshuagauss8179 They don’t but a rebased git history is very unpleasant to read. You effectively have to go through the entire history to make sure you got all changes after a certain day.
In flow, when we have master branch and release branch for patches, when developers have merged master changes into they feature/fix branch, it is hard to rebase it to patch release branch.
Thank you! I’m trying to build up my reputation for making super high quality tech videos. If you have a chance to share this video with someone, or on Reddit etc. I’d really appreciate it!
Great explanation. I have a question: you mentioned using rebase is not recommended when there are multiple contributors working on the same branch because the remote and local version will diverge. But when same branch is shared by multiple people at the same time, doesn't it diverge anyway because of different commits by the contributors? If yes, which specific aspect you are talking about?
Those are different kind of "diverge". When the coworker pushes their changes to the branch, you will pull those changes down and merge if necessary, but the commit hashes will not have changed so everything will be ok because the shared history matches up to that point. If you had rebased then now the commit hashes don't match (C' and D' instead of C and D) so the branch history won't match and everything will be a mess. I am learning it too but hope this helps...
@needmoreprivacy4947 got it right. When multiple collaborators are simply ADDING commits to an existing branch, Git is able to use standard merge protocols to combine those new commits together. But if one person rebases, it's as if they made a copy, and continued working on top of an entirely new branch. Now, when the time comes for those two collaborators to combine their changes, Git assumes you're trying to merge two distinct and unrelated branches (which is a much more difficult operation than merging the same branch with new changes). I hope that makes sense. It's a little confusing to try and explain verbally.
I always merge latest from main/dev branch into my feature branches, so my feature branches always up to date. Then PR into main/dev branch when I’m done with a feature
I think you may have an incorrect mental model of vim. The escape is not part of the quit command. The default mode in vim is the command mode. i puts you into insert mode and escape leaves insert mode and returns you to command mode. Colon moves you to another mode: ex mode where you can type ex commands. The ex command you're using in this situation is wq. If you're using escape before quitting even when in command mode, then it suggests you're not thinking of insert mode as something you dip in and out of before returning to the steady state of command mode and possibly missing out on the incredible power of command mode.
Your comment is a nice, succinct explanation of what I glossed over in the video. It seemed more approachable to gloss over vim modes to make sure folks could save & close a file without knowing which mode they were in. I'll admit my vim knowledge beyond simple commands is limited, I remember first starting out watching senior devs fly through code in vim, and being very jealous. Hopefully one of these days I'll find the time to up my skills!
@@themoderncoder Yep, vim is complicated, mostly because it's very different from almost any other editor that just lets you type and go. It's not helped that it's built on top of a very limited editor designed for teletypes (ed and then ex) When I was starting out, I had the same misunderstanding of vi, but someone much smarter than me gently corrected me and I became much more fluent.
There is a main branch and a feature branch which is based on main branch commit MBC1. Now my other developer added MBC2 and MBC3 commits in main branch. I commited FBC1 and FBC2 into my feature branch. When i want to incorporate those two commits of master into my feature branch, i will do a rebase with master. After rebasing, i end up with same two branches master and my feature branch where master history is not changed but my feature branch will contain MBC2, MBC3 commits added and then after these two commits, my individual commits will be added in the history of my branch wvich are FBC1 and FBC2 . Is my understanding correct ?
Yeah, you got it. The only part I’d phrase slightly differently is your second paragraph. Instead of your feature branch “containing” MBC2 and MBC3, it’s more like your feature branch is now “based on” MBC2 and MBC3 since those commits are still on main. But ultimately your understanding is functionally correct. If actually did want to incorporate MBC2 and MBC3 into your feature branch AFTER FBC1 and FBC2, you could actually merge main INTO your feature branch. You’d end up with a merge commit on your feature branch, and you could keep committing on top of that merge commit on your feature branch.
At 5:06, I didn't get the idea why we checked out to feature branch for rebase to work. Aren't we actually doing it as following: "Change the base of your feature branch to the latest commit (head) of the master branch"..? I'm a bit confused here, pls help.
Rebase can only operate on the checked out branch (this is a weird nuance of the Git architecture). Technically, you could run “git rebase master feature” without checking out the feature branch first and this would complete the rebase in the same way you see in the video at 5:06; however, “git rebase master feature” is just shorthand for “git checkout feature” followed by “git rebase master” so either way you’re checking out the feature branch
Nice video but it would be even nicer if you could demonstrate it with the github and merging options of pull requests so not locally but remotely too ;)
at 1.26, when we merge feature to main, by this time main has another commit already and so feature is not really on point. my question here is main being 1 commit ahead (hence not sync with feature) will be an issue for us when we do merge feture into main (from main).
Thanks for your video. Could you please this scenario which I see sometimes? So when I do git pull, it says "do stash or commit", then I do "stash", then if I do git pull again, I see the same message "do stash or commit". So what to do in this scenario.
@@themoderncoder The final result is awesome, because you don't leave explanation to be abstracted in people's mind but give a visual representation of what actually happens, so it's easier to understand. Great content!
Thanks. But if this tutorial is for a beginner, I wish you take it slow and elaborate about merging. When you say git merge localBranch, does it mean merging to local main repo? Because you're now the one to merge to the remote main, it's the lead in my case. Most tutorials I watched, most of them they just spit out what' merge or pull, not.,.../., I can read that
Everything Git does is local until you push. You can assume this whole video is talking about only changing your local repository. Check out my video on remote repositories (th-cam.com/video/ByBGTkrQ-QU/w-d-xo.html), then come back to this video. I think that will clear a lot of things up.
I had faced an issue while uptaking merge branch additional commits into feature branch using git merge in gitlab UI where merge conflict was arising. When I resolved then conflict on gitlab UI itself and merge request was granted, both the main and feature branches got merged into each other and main branch had the commits of feature branch😠. Any reason for this weird behaviour?
great video but the vim part was too obvious for people who use it and maybe confusing to people who don't. I would have kept that out, the text editor is irrelevant at the end of the day, maybe they even have nano configured
Yeah, I've struggled with this for a while. Folks need to know how to save and exit VI because it's typically the default text editor, but it's not very intuitive. Especially for beginners when Git just pops it open in the terminal. I fear if I leave this out, folks will get stuck at that part of the process
Hi I have a question. I have a parentfolder which contains 4 Javascript project subfolders. I have git on the parent folder so I could upload all the subfolders to one folder on github . I also have git on every subfolder to manage each project. In total I have 5 gits, is it legit to use it like that or is there a better way? I just want to group the projects in one folder on github.
That’s technically possible (I’ve never personally done it, but it’s in the official docs: see Git Submodules git-scm.com/book/en/v2/Git-Tools-Submodules ). As for if it’s legit or not, I would say that you should have a pretty good reason to do it like that. GitHub repos are free, so if the repos are not related to one another you should probably break them out into their our repositories. If you let me know more about your use-case I could maybe point you in the right direction
git pull --rebase origin master Critical next command when pushing to remote. git push --force Oh, and kids, don't work on the same branch as others. Create your own working branch.
It probably has to do with the direction in which rebase/merge integrates the changes. Merge looks at the tips of both branches (the most recent commits from both main and your branch) whereas you can think of rebase as rewinding and replaying. So rebase would instead look to merge the earliest commit on your branch into main first (instead of the latest commit). You can try squashing all your branch changes first into a single commit, then the merge and rebase would likely result in the same set of merge conflicts.
I'm not 100% sure on that one. Maybe someone here can weight in? Theoretically it's bad practice to rebase someone else's commits in the first place, but assuming you had a good reason to do so anyways I'm guessing you'll be updating the committer field, but not the original author. Again, not 100% on that answer, but here is a relevant post about author vs committer stackoverflow.com/questions/18750808/difference-between-author-and-committer-in-git
We spend the whole video talking about rebase then in the end say that using rebase to merge into a main branch is bad practice. without any further explanation. When else would we use rebase? our shop is trying to get our developers using rebase consistently. so we're trying to explain to them why we do it
The final section of the video (starting at 6:40) explains the potential downsides of using rebase to move commits onto a shared branch, like main. I think that's what you're looking for. For what it's worth, I don't personally believe that using rebase to move commits onto main, is bad practice, it just requires the user to be aware of the edge cases mentioned at 6:40
Im confused a bit by your comment, maybe you can clarify. The 9:19 and 6:05 animation show the same workflow & animation - both rebase the feature branch then merge that branch into main. Both show a fast-forward merge.
@@themoderncoder I was mistaken in what I thought you meant. I think I was thrown off from the wording. You said "merge to bring those changes back onto shared branches"; I know now you meant merge feature --> main, but I _thought_ you meant merge main --> feature. I thought this cuz the moment you said "merge", there was that extra commit in main that wasn't in the feature branch in the animation.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
MORE GIT VIDEOS: th-cam.com/play/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM.html
in my almost 15 year of using Git, this is by far the best video on how to use merge and rebase. thank you!
Really appreciate you saying that. It means a lot coming from someone like you with so much experience. If you have a chance to share this video with someone who might benefit, please do. Cheers!
@@themoderncoder already did it :)
Great video. I've been using Git forever, and this is probably the best explanation I've ever seen of merge, rebase and fast-forward.
This combination of a simple description of the processes with a clear, simple visualization is gold. Many professional coaches should learn from this. I haven't seen such a good way to explain processes that can be easily overcomplicated for a long time. I bow to such skills.
Probably the best videos about git, out there. The animations are a huge help. Thank you so much!
For someone like myself just starting out in programming, this is pure diamond. THanks for making this
I'd like to think of both as merging, but done differently. Here's how:
"Git merge" from a current branch into the target branch is when Git takes the latest changes of the current branch, then take the latest changes of the target branch and combine them. The new combination is made into a new commit and placed as the latest commit of the target branch. Git will still keep around the history of all the commits that had been made up until the merge of either branch.
"Git Rebase" from current branch into target branch is when Git first takes all the commits from the current branch, lines them up in the order they were made and puts them aside for now. Then Git takes the oldest commit from current branch and "merges" it with the latest commit on the target branch by doing it like a regular merge: combing the changes, make a new commit that represents those combined changes then places that new commit as the latest commit on the target branch. Then Git moves on the second oldest commit on the current branch and repeats the process. All the way until the latest commit of the current branch is merged. But remember, the current branch is still set aside, what will Git do with those commits that have effectively become duplicates? Git will just delete those commits, hence why history has been rewritten.
Hope this helps
That’s a good mental model for rebase - thanks for taking the time to write that up 👍
Actually rebase removed those commits, using a delete word is not appropriate here.
Once a commit has been made you can't delete them.
But you can remove it from the your branch or anywhere in the history.
This video must be the new standard, at least for any git-related educational content moving forward. Great job!
BY FAR, the best channel on git
Thanks for saying that!
had a hard time wrapping my head around git and thanks to you you've made that topic very understandable to me thank you so much!
Hey man, amazing video with great illustrative animations out there.
There's just one thing which I found confusing. So in most of the scenarios that I have worked in, the git workflow looks something like this:
1) Create a feature_branch from main: `git checkout -b feature_branch`.
2) Makes changes to your feature branch: `git add -A && git commit -m "Your commit message"`.
3) During the development process some changes were pushed and merged to the REMOTE main branch. So you need to sync your LOCAL main with the REMOTE main:
`git checkout main && git pull origin main`
Once that's done...
4) You checkout your feature_branch and merge the updated local main with your feature_branch: `git checkout feature_branch && git merge main`
5) You push your local feature_branch to remote and create a pull request: `git push origin feature_branch`
In this workflow we can probably replace the merge thing in step 4 with a rebase thing, if this feature branch is being worked on by a single contributor.
What confuses me in the video is that at 5:40 : when we are on the feature branch we run `git rebase main` and then we checkout to main and run `git merge feature_branch`.
Maybe that's done to illustrate fast forwarding merge here but in a production workflow isn't it discouraged to merge directly onto the main branch?
Let me know if I missed a point or something.
Your absolutely right: in many production workflows you'd let the PR process do the work of integrating of your changes into main instead of doing it yourself like I demonstrated in the video. I didn't want to make the video too complicated by trying to introduce PRs into the mix, but I feel like creating a video specifically covering PRs and code review could be a good idea.
@@themoderncoder can you pls create a video on this? it will be really helpful
Best explanation I have ever seen on TH-cam about merge vs rebase. Thank you for sharing.😺
This was great. My current job, devs keep telling me to rebase and I ask myself "why not merge". This explains it lol. Thx!!
there is even better merge --squash which gives same linear history, but not commit automatically, not ruin your feature branch and safe to play with.
thank you! clear and easy to understand! I am a fan of rebasing, and this video highlighted some of the value in the the other side. my contribution would be to suggest (if you want to maintain a linear history) that if there are multiple people working on a side branch you should be creating your own local branch from that and rebasing only the local branch on any changes pushed to a shared side branch. that way you can fetch and create review additions to it and continue to with your branch locally. and squashing + incremental commits is your friend!
Thanks a lot!
At last after several years using Git, I (think) I finally grasped it.
Your videos are the most clear I ever seen on this topic and still contains enough details
Appreciate you saying that
Production quality is remarkable.
As a single dev , I only ever use rebase amd NEVER merge just to keep the history strictly linear , however this is a luxury that larger teams might not have . The tip about only using rebase for your own local work is 100% the right way to use it , imo .
Thank you for the example of rebase of shared repo. I did't learned it from another video. Thanks a lot
This was the best explanation I mean the best about the topic (personally) the animation and the simple description of the topic top notch.
Appreciate you saying that!
Great video and explanation! I honestly can't think of a scenario where I'd want to rebase, versus just using merge. The risk outweighs the benefit, and honestly the overhead of a merge process on your local repository is moot. Just my two cents.
Excellent video, I've always been worried about using rebase, this helps massively
That’s so nice to hear. Glad it helped
Amazing tutorial !! really appreciate posting this tutorial explaining "git merge" and "git rebase"
Thank you for this great explanation. To clarify, at 9:18, you say "use rebase to re-anchor your feature branch onto baseline". If I understand correctly, more accurate would be to say "use rebase to re-anchor your feature branch THAT WAS NEVER PUSHED TO THE REMOTE onto baseline"? This would mean, check git branch -a and if you dont see your local branch in remotes, you are safe to use rebase; otherwise, use git merge.
Yep, you got it :)
Best git teacher of all time
This is the best git videos on youtube. This is amazing work. I am begging to you please move whole git with kind of videos
Appreciate it! I'm trying to make this my full time gig, if you ever come across a chance to share this video with someone, please do!
I quite like a semi linear approach. If I have a release/feature branch that multiple people are working on, rebase to keep in linear. Then when then when you want to merge to master, do a rebase and then merge with no fast forward. This way if you use gitversion, your main branch only has one commit per release but you have full history of commits for each release without a bird nest.
You meant it when you said definitive guide :) thanks for the efforts, subbed.
Appreciate it
Great video! You seriously deserve more recognition.
Thanks for that compliment. If you ever have a chance to share one of my videos to someone else, or on Reddit or something, I’d really appreciate it!
How to handle the case when while doing rebase and we encountered conflicts ? Best video i found for my confusion on rebase and merge ❤
I'm literally working on a video about merge conflicts right now! In the meantime the process is pretty similar to cherry pick conflicts if you want to check out my video on that: th-cam.com/video/aUeNbpSkY8k/w-d-xo.htmlsi=EWbgwrKwbulROvID&t=131
Best git videos on youtube!!
Hi there, I’m new to collaborating in a team using git. I want to understand the best practices of branching or pulling.
Here's a scenario:
Time 1: A created a feature branch based on origin master.
Time 2: A worked on 1 commit on the feature branch.
Time 3: There is a new commit (maybe a merge) in the origin master branch.
Time 4: The next day, A wants to continue to work on the feature branch.
Question:
1. Should he do a git pull in the morning before doing his work?
2. Also, after the pull, how should he incorporate the changes in master into his feature branch? Or should he?
3. Lastly, if the changes in master totally removed some main functions where his feature branch is based on, what should he do?
Thank you!!
I absolutely agree with what you said towards the end and that's what I like to do: rebase on personal feature_branch, merge the feature_branch on main.
But how can we do this when doing PRs? I mean...you can do rebase and merge, but if there are conflicts, who should deal with them? How to organise with the team?
I’d say (personally) since you’re the one merging into existing work, then you’re on the hook for making sure it’s compatible (I.e. resolving conflicts). That said, I don’t believe you should be entirely responsible for figuring out how to resolve if the original authors are more authoritative on the files that are in conflict. Still, even if others help you figure out what to do, you’d still have to author it IMO
Amazing video.. Was struggling a bit with conflicts and the log and decided to dedicate an hour for a couple videos to once and for all kill all the missing pieces in my mental model even though I use git for years...
One thing that wasn't 100% clear is at the end of the video the "recommended workflow" tells you to rebase your branch and then merge it when ready, but that doesn't apply if the branch is on remote and has more people working on it correct? That would mean that remote branches should never get the latest changes from their parent branch unless absolutely necessary, and in that case you'd need to merge from the parent branch.
Right, that would necessarily apply if multiple people are working on the same remote branch. Like you said though, in those cases you can merge main INTO the remote branch - you’ll just end up with a merge commit which isn’t too bad.
Thank you so much. Very helpful in understanding git merge vs rebase.
I always squash and never allow teammates to work on my branch. This way you maintain main branch clean with only feature commits and avoid conflicts with teammate locally. The only use case I had was when I was introducing a big feature >100 files and split my PR into 6, then I was rebasing branches in order of building block of the feature, where last branch was rebased into main feature branch after reviews of my peers.
This a good anecdote for folks - in the real world sharing branches is not very common and workflows like you describe are more the norm.
Crystal clear ! I'm glad I've found your channel and eager to discover more
Definitely check out my other videos - there is a ton more there!
Excellent content, don't stop
Excellent explanation and a nice, clean video. Well done. Subbed
You saved my life, God bless you 😅
Great content! What are you using to make slides?
I use Apple Motion to create the animations. Then stitch all the animations together with Final Cut. It’s a bit of a manual process unfortunately - these videos take me a very very long time to make lol
Just amazing!! Thank you so much for your work! Nothing even close to your explanations of the work of git does not exist.
Appreciate you saying that! I really try
Okay, now that I actually know what Rebase is, number one, the name makes a lot of sense. You're "rebasing" where your branch starts. But two, this doesn't seem to be an accurate history of work anymore. We're pretending that I started my work after whoever got their changes into main, somehow that feels wrong.
Sounds like you understand rebase pretty well - the good and the bad ;) But yeah in all seriousness, pretending you started your work somewhere else is a caveat you need to account for especially when working with others.
@MobiusCoin Sure it's not an accurate history in the sense that it doesn't show who did what work when. But the question is, does that matter? Chances are your company has that kind of history available in other places, like Jira or a similar software.
The real point of source control is to document the history of when the code changed, not when the code was actually typed into a file. If you think about it like that, no real "history" is lost in a rebase vs a merge. If I merge my branch, main will have my code from that point on. If I rebase and fast-forward merge, the same thing will happen.
I thought that commit timestamps do not change on rebase.
@@joshuagauss8179 They don’t but a rebased git history is very unpleasant to read. You effectively have to go through the entire history to make sure you got all changes after a certain day.
They don't. This is not an issue at all, ever :) Rebase away!
Great explanation. Well done!!
First time i have seen such an attractive videos regarding git, captivating !!
great stuff
In flow, when we have master branch and release branch for patches, when developers have merged master changes into they feature/fix branch, it is hard to rebase it to patch release branch.
This version is much better than the original version.
Hoping I see you point out rebase leaves a clean tree, merge creates new commits.
Yep you nailed it. Great video man!
seems to me rebasing into feature branches, and merging into master, is the cleanest option
Great video. Thanks. What software fif you use to animate?
I use Final Cut Pro and Apple Motion
😮 Excellent video! Btw, what is the cool font used in the videos? JetBrainssMono Nerd Fonts isn’t it?
Iosevka’s nerd font! I use it in my ide too. Love it
clean explanation!
Amazing 😮
Thanks Shivam!
This video is fantastic. Thanks for sharing
The quality of this video is 10x the other ones that you can find around
Thank you! I’m trying to build up my reputation for making super high quality tech videos. If you have a chance to share this video with someone, or on Reddit etc. I’d really appreciate it!
Really it is a super helpful video, Thank you!
excellent video, thanks for making it
Great explanation.
I have a question: you mentioned using rebase is not recommended when there are multiple contributors working on the same branch because the remote and local version will diverge. But when same branch is shared by multiple people at the same time, doesn't it diverge anyway because of different commits by the contributors? If yes, which specific aspect you are talking about?
Those are different kind of "diverge". When the coworker pushes their changes to the branch, you will pull those changes down and merge if necessary, but the commit hashes will not have changed so everything will be ok because the shared history matches up to that point. If you had rebased then now the commit hashes don't match (C' and D' instead of C and D) so the branch history won't match and everything will be a mess. I am learning it too but hope this helps...
@needmoreprivacy4947 got it right. When multiple collaborators are simply ADDING commits to an existing branch, Git is able to use standard merge protocols to combine those new commits together. But if one person rebases, it's as if they made a copy, and continued working on top of an entirely new branch. Now, when the time comes for those two collaborators to combine their changes, Git assumes you're trying to merge two distinct and unrelated branches (which is a much more difficult operation than merging the same branch with new changes). I hope that makes sense. It's a little confusing to try and explain verbally.
@@themoderncoder thank you
Great video! Thanks
Great video, thanks for the effort.
Best explanation
Fantastic. I've subscribed !!
Nice edit and animation
I always merge latest from main/dev branch into my feature branches, so my feature branches always up to date. Then PR into main/dev branch when I’m done with a feature
Can you do a video of How to revert already merged branch from a main branch.
Like undo the merge commit? Or undo the fast-forward?
I prefer rebase and fast forward to keep the main branch perfect. Then the conflicts live on the feature branch.
I think you may have an incorrect mental model of vim. The escape is not part of the quit command. The default mode in vim is the command mode. i puts you into insert mode and escape leaves insert mode and returns you to command mode.
Colon moves you to another mode: ex mode where you can type ex commands. The ex command you're using in this situation is wq.
If you're using escape before quitting even when in command mode, then it suggests you're not thinking of insert mode as something you dip in and out of before returning to the steady state of command mode and possibly missing out on the incredible power of command mode.
Your comment is a nice, succinct explanation of what I glossed over in the video. It seemed more approachable to gloss over vim modes to make sure folks could save & close a file without knowing which mode they were in. I'll admit my vim knowledge beyond simple commands is limited, I remember first starting out watching senior devs fly through code in vim, and being very jealous. Hopefully one of these days I'll find the time to up my skills!
@@themoderncoder Yep, vim is complicated, mostly because it's very different from almost any other editor that just lets you type and go. It's not helped that it's built on top of a very limited editor designed for teletypes (ed and then ex)
When I was starting out, I had the same misunderstanding of vi, but someone much smarter than me gently corrected me and I became much more fluent.
very cool , thank you !!!
Really Good Video
Crisp video.
What if we need to reset changes after rebasing to the main branch after rebase the feature branch to the main branch
Excellent
There is a main branch and a feature branch which is based on main branch commit MBC1. Now my other developer added MBC2 and MBC3 commits in main branch. I commited FBC1 and FBC2 into my feature branch. When i want to incorporate those two commits of master into my feature branch, i will do a rebase with master.
After rebasing, i end up with same two branches master and my feature branch where master history is not changed but my feature branch will contain MBC2, MBC3 commits added and then after these two commits, my individual commits will be added in the history of my branch wvich are FBC1 and FBC2 . Is my understanding correct ?
Yeah, you got it. The only part I’d phrase slightly differently is your second paragraph. Instead of your feature branch “containing” MBC2 and MBC3, it’s more like your feature branch is now “based on” MBC2 and MBC3 since those commits are still on main. But ultimately your understanding is functionally correct.
If actually did want to incorporate MBC2 and MBC3 into your feature branch AFTER FBC1 and FBC2, you could actually merge main INTO your feature branch. You’d end up with a merge commit on your feature branch, and you could keep committing on top of that merge commit on your feature branch.
Thank you!
PRO TIP: Hit ESC, hold SHIFT and hit Z twice - instead of writing ":wq".
At 5:06, I didn't get the idea why we checked out to feature branch for rebase to work. Aren't we actually doing it as following: "Change the base of your feature branch to the latest commit (head) of the master branch"..? I'm a bit confused here, pls help.
Rebase can only operate on the checked out branch (this is a weird nuance of the Git architecture). Technically, you could run “git rebase master feature” without checking out the feature branch first and this would complete the rebase in the same way you see in the video at 5:06; however, “git rebase master feature” is just shorthand for “git checkout feature” followed by “git rebase master” so either way you’re checking out the feature branch
Nice video but it would be even nicer if you could demonstrate it with the github and merging options of pull requests so not locally but remotely too ;)
I should do a video on pull requests - that’s a good suggestion
at 1.26, when we merge feature to main, by this time main has another commit already and so feature is not really on point. my question here is main being 1 commit ahead (hence not sync with feature) will be an issue for us when we do merge feture into main (from main).
Thanks for your video. Could you please this scenario which I see sometimes?
So when I do git pull, it says "do stash or commit", then I do "stash", then if I do git pull again, I see the same message "do stash or commit". So what to do in this scenario.
Try staging your new (untracked) files first using “git add .” or similar before running stash
Thanks
How do you make such beautiful animated presentations?
I use a combination of Apple Motion and keyframe animation in Final Cut Pro!
@@themoderncoder The final result is awesome, because you don't leave explanation to be abstracted in people's mind but give a visual representation of what actually happens, so it's easier to understand. Great content!
Thanks. But if this tutorial is for a beginner, I wish you take it slow and elaborate about merging. When you say git merge localBranch, does it mean merging to local main repo? Because you're now the one to merge to the remote main, it's the lead in my case. Most tutorials I watched, most of them they just spit out what' merge or pull, not.,.../., I can read that
Everything Git does is local until you push. You can assume this whole video is talking about only changing your local repository. Check out my video on remote repositories (th-cam.com/video/ByBGTkrQ-QU/w-d-xo.html), then come back to this video. I think that will clear a lot of things up.
We use rebase and we can because we are a small team and dont share feature branch so we dont have the problem
at 9:16 I think both animations show the rebasing?
Yeah at 9:16 the workflow shows 2 rebases followed by a fast-forward merge
You are the best
If you push your feature branch to remote, but no one touches your branch, is rebase still safe?
Yeah, rebase should be pretty safe in that scenario.
I had faced an issue while uptaking merge branch additional commits into feature branch using git merge in gitlab UI where merge conflict was arising. When I resolved then conflict on gitlab UI itself and merge request was granted, both the main and feature branches got merged into each other and main branch had the commits of feature branch😠. Any reason for this weird behaviour?
@TheModernCoder pls make video on git stash too
Gotchu:
th-cam.com/video/BSLzA8oCT7g/w-d-xo.html
Summary:
- Git rebase should be done from shared branch to feature branch
- Git merge should be done from feature branch to shared branch
Exactly! That's a good rule of thumb
great video but the vim part was too obvious for people who use it and maybe confusing to people who don't. I would have kept that out, the text editor is irrelevant at the end of the day, maybe they even have nano configured
Yeah, I've struggled with this for a while. Folks need to know how to save and exit VI because it's typically the default text editor, but it's not very intuitive. Especially for beginners when Git just pops it open in the terminal. I fear if I leave this out, folks will get stuck at that part of the process
@@themoderncoder yeah true that
Hi I have a question. I have a parentfolder which contains 4 Javascript project subfolders. I have git on the parent folder so I could upload all the subfolders to one folder on github . I also have git on every subfolder to manage each project. In total I have 5 gits, is it legit to use it like that or is there a better way? I just want to group the projects in one folder on github.
That’s technically possible (I’ve never personally done it, but it’s in the official docs: see Git Submodules git-scm.com/book/en/v2/Git-Tools-Submodules ). As for if it’s legit or not, I would say that you should have a pretty good reason to do it like that. GitHub repos are free, so if the repos are not related to one another you should probably break them out into their our repositories. If you let me know more about your use-case I could maybe point you in the right direction
git pull --rebase origin master
Critical next command when pushing to remote.
git push --force
Oh, and kids, don't work on the same branch as others. Create your own working branch.
I my case rebasing onto main creates way more conflicts than merge main into feature. Why is that happening? Is there a way to prevent this?
It probably has to do with the direction in which rebase/merge integrates the changes. Merge looks at the tips of both branches (the most recent commits from both main and your branch) whereas you can think of rebase as rewinding and replaying. So rebase would instead look to merge the earliest commit on your branch into main first (instead of the latest commit). You can try squashing all your branch changes first into a single commit, then the merge and rebase would likely result in the same set of merge conflicts.
Great explanation!
Will rebase delete the original commit authors?
I'm not 100% sure on that one. Maybe someone here can weight in? Theoretically it's bad practice to rebase someone else's commits in the first place, but assuming you had a good reason to do so anyways I'm guessing you'll be updating the committer field, but not the original author. Again, not 100% on that answer, but here is a relevant post about author vs committer stackoverflow.com/questions/18750808/difference-between-author-and-committer-in-git
nice
what about git pull origin main
What about it?
We spend the whole video talking about rebase then in the end say that using rebase to merge into a main branch is bad practice. without any further explanation. When else would we use rebase? our shop is trying to get our developers using rebase consistently. so we're trying to explain to them why we do it
The final section of the video (starting at 6:40) explains the potential downsides of using rebase to move commits onto a shared branch, like main. I think that's what you're looking for. For what it's worth, I don't personally believe that using rebase to move commits onto main, is bad practice, it just requires the user to be aware of the edge cases mentioned at 6:40
9:19 That animation is not what a merge would look like of updates in `main` onto shared feature branches. It'd be like the 6:05 animation.
Im confused a bit by your comment, maybe you can clarify. The 9:19 and 6:05 animation show the same workflow & animation - both rebase the feature branch then merge that branch into main. Both show a fast-forward merge.
@@themoderncoder I was mistaken in what I thought you meant. I think I was thrown off from the wording. You said "merge to bring those changes back onto shared branches"; I know now you meant merge feature --> main, but I _thought_ you meant merge main --> feature. I thought this cuz the moment you said "merge", there was that extra commit in main that wasn't in the feature branch in the animation.
Oh gotcha. Thanks for clarifying
gogo gaga