I do agree that this video was well done, but "must" is a strong word. git is a just merkle tree, like ZFS or bitcoin. You can't re-write history, but you can create an alternate one.
Yep, all articles out there assume we know rebase already, while they're trying to explain what rebase was. It's like teaching people to drive a car while the student even doesn't know how to turn on the car.
The way this is demonstrated with "live command typing" combined with "animated slides" is very intuitive! I imaging this takes quite some preparation/post-production. Thanks for that.
I am a student at a Japanese University. I study programming for myself. Thank you for making good movies all the time. I wish there was a super like button on TH-cam 👍
Wow, I thought git rebase was complex, but you managed to explain it in under 7 minutes EXTREMELY clearly. The graphics really helped. Great work man. Thanks so much
Thanks a lot! It seems like no one can explain how git works, so they make videos without graphs just talking in a confusing manner making it harder to understand. Thank you again!
1. Rebasing master into the feature branch is dangerous if someone else working on that feature too. 2. Rebasing feature into master isn't a good solution, cause you can't revert all feature (if needed), you have to revert all commits one-by-one of that feature. 3. Git history can be nice and clean if you will merge features into the master with not allowing fast-forwarding and use "first-parent" when looking into log graph. In that case you will get just merge-commits which describes what that feature does and no other commits. 4. If you are working with tags, and, for example, track revisions of commits in your feature branch, rebasing will mix all tags into master. so, as for me, rebasing sub-branches into feature branch after code review is a good idea, but rebasing into master or from master into feature branch doesn't look like a good solution
Can you squash a feature branch AFTER merging it in order to achieve something similar to first-parent when looking at the log graph? m | \ | * m | | ----> | \ | * | * (squashed after merge to master having taken place) | / | / m m
@@PaulSebastianM , I'm afraid, i don't get your question. I can squash feature branch before merging, but I don't see any reason for that. Your master graph will be clean on first-parent, and additionally, you will have every commit in feature branches. it is convenient, as for me
@@freefallintoflames Agree. Rebasing master sounds like a horrible idea. It can cause all kinds of havoc. There are exceptions to the rules, but I've seen people accidentallied master because "git push -f" and borked the rebase. Didn't take long before we started marking master as protected.
I agree. The only time rebase made sense to me was when I needed to cut a feature out of a branch. I could not care less if my commit log is a straight line. Why not preserve the history as it is?
If you'd like to preserve the idea of merge requests and approvals I recommend doing rebasing only on feature branches and when it's good to go open a PR to merge with master. This will help prevent damage being done in master as well.
this is a really key point, all examples i've always seen of the rebase method, forgets to point out when doing pull requests it's best to squash merge, rather than rebase, i.e golden rule of rebasing public branches is frowned upon.
really love the way you organized things at 4minutes with the branch updating as you go. Even better than you showed local master vs remote master. Nicely explained as well.
Best git video on TH-cam. I've been using this strategy since 2013 and it's still the best approach I've found. I'd suggest just ignoring everything after 5:25 and just open a PR to the repo at that point. Then try to get your code reviewed/merged first so someone else has to deal with merge conflicts-otherwise you will have to rebase your PR frequently depending on the size of the team working on the repo.
I agree with Cory. Seems like push to master this way only makes sense when you have complete trust that the changes your are introducing the master are good ones. Most development teams will want to implement a Pull Request (PR) so that peer review, CI/CD, etc. can be applied to the potential feature before its becomes part of master.
seriously.. i've watched a ton of videos, read countless stackoverflow explanations and other articles and still didnt quite see the benefit or thoroughly understand merge vs rebase. but this video made it make sense. thank you.
The extra time you have spent creating the animations is well worth it - especially recognising that at some point your local work has to be pushed up to the origin repo - this is the best video on rebasing I have come across - I've subscribed to your channel - thank you for creating this tutorial.
This video has been up for longer than the duration of my career and I'm just now finding it. I've read or watched about 100 descriptions of Git rebase, with static diagrams of before and after, but they never really demonstrate the steps. Really well done. I'm going to go try it right now.
I watched 4-5 TH-cam videos on rebasing, but I still didn't understand what it does. However, after watching your video, I now understand rebasing clearly. Thank you so much from the bottom of my heart!
Tutorials like THESE must be added to any command on GIT documentation! GIT in itself, without any specific real world examples is so complicated (at least for me) and I understood about 60% of the theory they were trying to teach me in GIT docs but still not sure if I'm supposed to rebase from master onto my branch or checkout to my branch and then rebase master in order to get the latest master branch code changes to my feature branch and was reluctant to even try to do it ! This is exactly the video I needed to see, thank you my friend
This a very good demonstration 👍Props for that! However, I strongly advise against using rebase this way. Better avoid rebase all together. With bigger projects you will spend 10x more time on solving conflicts. There will be conflicts on files that your feature branch didn't even touch and often you need to solve conflicts on the same lines multiple times because rebase goes commit by commit. And all of this trouble and wasted time just for fewer lines history :) Those lines are very rarely needed anyway. Modern tools also can compare branches and list you missing commits from both sides and clearly show the state of branches. Git rebase is a very powerful tool but at the same time has potential to delete other people work because you need to do force push (or merge with remote again solving conflicts usually :)) ) Anyway, I left my 2 cents, thanks for reading and good luck 👍
I don't understand "has potential to delete other people work". Why do you need to force push? Unless you're re-rebasing commits you already pushed before (which of course is very bad), I can't think of a scenario where you'd need to force push.
Completely agree, on a larger project this would be a shit show. Imagine going through 50 commits that you don't even know what got changed or how it worked. Keeping an untouched master branch and having your feature branch not be behind in commits will allow any merge to be light and any conflicts easy to handle.
Thanks for the advice, i am new to this world i just want to add one thing here, if you are using scrum/agile development flow and creating individual branches for each of your tasks, then you will be rebasing only your commits reason for rebasing 1) squash unnecessary commits into one commit 2) remove unwanted commits from other branch if you have taken pull or created your branch from their branch, i mean your branch contain work of other branch which isn't ready for merge, you can use rebase --onto to remove all those commits 3) Clean history of course :) don't rebase master/release branch or any branch on which 2 or more developers actively working, Golden Rule 😜: 1) Rebase your branch before pushing commits on remote 2) use git merge at time of merging branch into master/release branch
'git pull --rebase origin master' while on your feature branch is a shortcut to update and rebase your feature branch without switching to the master. Thanks for the video!
Dear Modern Coder, Appreciate your time for this video. I asked from my parner to look into this video to understand between rebase / Merge. Rebase / Merge comes into picture while you are working in two different branches. by the way I was working on same branch - develop. it made me bit surprise when he asked me rebase it first before taking fetch/pull. Anyhow it nice explanation between rebase and merge - If you say Git merge it into master, it will combine the tasks of feature into master by creating a single new commit at the tip of master. On the other hand, if you say Git rebase , it will place the entire commit history of the feature branch on the tip of master. It means that your entire feature branch will be reattached to the tip of master and it will look like a linear sequence of commits.
Thank you for the clear explanation! I did it step by step and found out that I was corrupting my feature branch. in order to avoid that, I had to add a force push command right after rebasing feature with master. The full command list that worked for me looks like this: git checkout master git pull git checkout feature4 git rebase master git push -f git checkout master git rebase feature4 git push
I can say this is the best tutorial after watching tons of clips about rebase, and this is the first time I finally figure out how to use rebase.
5 ปีที่แล้ว +4
Despite pushing to master, that was good explained. I'm using interactive rebase a lot for editing older local commits and organize the tree after PR. Git is awesome!
I've never run into the "cluttered git graph" in my nearly 10 years of being a professional developer. Rebasing, from my experience, just makes the commit history in your trunk branch harder to work with, and is prone to introducing conflict resolution errors. If you're having issues with branching, maybe the solution isn't to try and obfuscate the branching problem. Maybe you need to take a look at what's causing the issue in the first place.
2- In your pattern, when we want to get feature branch changes in local master, you used “rebase”. I think, if we had used “merge”, it would have given the “same output” and commits in local master would have been linear (because in the previous step, we had moved the last changes of the local master to the feature branch). Do you agree to use merge at that point? The good thing about this way is that you can introduce a template for the entire git-flow diagram: “Integrate from origin maser to local feature with rebase” “And vice versa, Integrate from local feature to origin maser with rebase”
UPDATED REBASE VIDEO: th-cam.com/video/zOnwgxiC0OA/w-d-xo.htmlsi=eSYbRNIooTNCb5g- MORE GIT VIDEOS: th-cam.com/play/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM.html
You can combine the 4 steps, the `git checkout master && git pull && git checkout my-branch && git rebase master` with a single command: `git pull origin master --rebase`
SUPERB... Video. Crisp and upto the point. Nugget sized videos - addressing specific topics THANK YOU SO MUCH This video saved me a lot of reading and researching time
Awesome, thanks for taking the time to leave a comment. These videos (and especially my new ones) take an insane amount of time/effort to produce, so it's nice to know they're helping!
I always wanted to create a workflow like this but my limited knowledge with git didn't allow. Thanks a lot for putting this video in concise and straight forward manner. masterBr featureBr featureBr> git rebase masterBr (updating features baseline) masterBr> git rebase featureBr (bringing feature in same line of master)
Glad to hear that. Check out my other recent git videos and let me know what you think: th-cam.com/video/q53umU5vMkk/w-d-xo.html. I'm trying to ramp back up
I don't quite understand how it fixes the "mess", you'll still have tons of feature branches side by side if you have a lot of co-workers. And if you just want the linear history for master, you can look only at the master branch log, right?
The mess is when a feature branch has a bunch of merge commits from master. The history graph starts to look like someone was braiding some string. Then you have all of the overlapping feature branches, and soon it looks like a rope.
@@BenjaminCronce but it helps to tell features' branches apart, right? if the history is just a straight line, is it wrong if i say it will be hard to track each feature's merge time?
@@BenjaminCronce Oh, I get it now. I was assuming that feature branches were rebased on top of master when needed (to get a fix from master) but still using merge commits from feature branch to master.
Never rebase master branch onto a feature branch unless you are sure what are you doing. Here my golden rule, if a branch is public DO NOT ever rebase it. Someone might be working with a commit, which on your rebase strategy might be re-written. Additionally, the new tree structure when you rebase master onto feature is only visible locally for your (you might have also duplicate commits if the master branch has forked from your feature branch). The other developers would be still using the origin master branch.
I hear you both and have updated this video to clarify a better rebasing strategy: th-cam.com/video/zOnwgxiC0OA/w-d-xo.html That said I don’t agree that using rebase to move commits onto master is inherently dangerous in such a way as to suggest this video be deleted. It may not be best practice, but there’s a difference between not strictly following best practice and a dangerous anti-pattern.
Using rebase to ensure locally that master works well with your changes is a great idea, but pushing straight without any kind of peer review is insane.
@@Philbertsroom You rewrite history - which means you lost your original history. Specifically, you lose the state before the feature branch was merged because you force it on top of the commits in master.
@@Philbertsroom It is not equivalent - you cannot navigate the old feature branch in the same way that you could before rebasing. It causes headaches if there are multiple people working on the same feature branch, or if something not related to your branch changes before the rebase.
@@Gismo359 Just have a naming convention for commits or add which feature the commit is related to in the commit message. These "issues" can be fixed with a slight change of workflow
I strongly recommend NOT to use this! Rebasing destroys your --first-parent history that is so important for enterprise projects. You will have every small commit of every feature branch in your masters first parent history. This makes it impossible to track what feature and when exactly it was merged onto the master. You lose the possibility of generating changelogs/releasenotes just from your git history. Also this makes it hard to find the culprits of failing build on your CI pipeline. This may be suitable for very small and hobby projects, but I think it's better not to get used to this and use git in a way that is suitable even for bigger projects. As a rule of thumb: Never rebase anything that's already pushed!
You can rebase and squash feature branches into one commit describing the feature. This lets you have a clean, linear history, with each commit describing one feature. Squash is missing in this tutorial.
I do not agree completely! When you are on your FEATURE BRANCH, you should ALWAYS REBASE against remote target branch. Because you want to want to fix conflicts on your local branch, and not have to merge remote branch to your local branch to do this. Then when your code is ready to be put on REMOTE BRANCH, ALWAYS MERGE by making a pull request first for review. ALWAYS activate Squash option of your pull request tool to not merge all the single commits. This workflow is clean and entreprise approved in big companies with huge projects (i work for one)
@@alfredomoreira6761 isn't this what the video author is already doing? He's rebasing the feature branch to the remote master branch by pulling the remote changes and then rebasing the feature branch on it, and taking care of conflicts there while still on the feature branch (he just doesn't have conflicts in the example but mentions taking care of them if they arise).
@@kmr_tl4509 With squashing you will lose every single commit from your developers that may contain valuable information on WHY a line of code was changed. This is very important when dealing with problems from customers later on.
@@alfredomoreira6761 I assume you mean that you have to rebase your local master onto the origin/master when pulling, that is correct. With squashing you lose valuable information from the development. But that is - of course - up to you and your company.
Agreed. I've done worse while I was learning, but not now. The golden rule of rebasing: "If it's a remote branch you never rebase... ever. If it's a local one do whatever you want before you push it for the first time.". It took me two weeks of attempting to resolve the mess I created by doing just that, and it took a lot of reading to get to a semi-competent level where I could establish rules for my team to follow, without leaving the possibility of messing up in the process. Today we only use rebase once in a blue moon, and even then, only if absolutely necessary. It's a nice 'tool' but you have to be careful with it.
Yes I agree, I didn’t feel as though this video make it clear enough how that commit movement happens behind the scenes during rebase. I’ve addressed that in the updated video (linked above in this thread), let me know if you have a chance to watch that - I think it does a better job in general of explaining the merge vs rebase difference
this method of doing tutos is amazing honestly this is the first time i see something with animation like that, man continue like that, keep up the work and THANK YOU
Don't rebase. Wanting to have a "nice, clean straight line graph" is the dumbest excuse to rewrite history. Version control is not supposed to be visually pleasing and its even harder to understand things when you rewrite history. Very bad practice IMO.
I was thinking exactly the same thing, merge commits look messy if you try to lay them out visually on a timeline but that's not the point at all. If anything putting it all in a straight line makes it harder to understand because you lose all of the important information from the branches and merges.
There is nothing about being visually pleasing. It's all about being able to track properly every commit. To see which feature were implemented at what specific point in time. To see what commit caused which bug. And, mostly, to revert properly.
FINALLY a tutorial that explains in a very clear and fun way how git rebase works! A big thank you to you for your video which is useful to all of the developers!
your git explaining video is amazing. It makes me open eyes about git workflow without any difficulty and plus I didn't feel toxic over git thing anymore. Thank you. Please create more of git workflow videos.
Thanks! This video clears out my question. I've had confusion for months understanding the difference between merge and rebase. I'm a noob, I admit. Most articles out there, assume that the reader knows how to rebase, and never pointed out detailed steps on how to do rebase.
You are a magician, all the post I have studied is actually a waste of time. Only your video animation made it simple for me to understand what am I expecting. Best wishes to you. make more videos like this.
Whether rebase to master is good or not is different topic but the way you explained with graphic + commands is superb, I will never forget now what is rebase ! Would watch all your other videos
I’m really thankful for you having produced this material on git rebase. Thank you. Also, I really appreciate the write-up as well. Great contribution. Subscribed.
This is the best tutorial that I have ever seen. It has real example and a graphics and animation to clearly visualize what was going on. Every tutorial in the youtube should be like this. Excellent work my friend! Keep up the good work. Thank you for this.
Good to see it. Before this I thought that rebase does not dismiss my feature branch, only displays like it would have been branched from other commit of the main branch.
I think the way you have animated the process of what was happening while you were doing the stuffs are very clear and help a lot to understand how Rebase works. Thank you, I have used this video to explain the process of rebase to others. :)
Great visualization with the branches, and what you type and what happens all is visible at once. So much better than what other people do, where you see either the code or the branch-visualization, but not all at once. Well done.
Good quality in the video. Well done. In our environment, no branch is allowed to make pushes to master. Only merges after code review. But Rebase can still be used on the feature branches you are working on when you have to pull other's changes that have been merged to master.
Definitely, and I can see the reasoning why you'd want to only allow merges after CRing. When you merge, no history is lost so you'll easily be able to go back and track each feature as it was developed and pick out exactly when it made it into your master branch.
I found rebase is really nice when doing PCB layout with Kicad. You pull when you start and rebase when you are done. The nature of it makes it so that you can't collaborate but it makes it easy for people to add in changes to the schematic and pick up on your work.
Thanks, I'm hustling for new videos. My current videos take these motion graphics up a notch so they take quite a while to produce. While you're waiting, if you have some time, check out the updated rebase video I did a couple months back: th-cam.com/video/zOnwgxiC0OA/w-d-xo.htmlsi=eSYbRNIooTNCb5g-. Appreciate you watching!
why haven't I watched this before? Thank you for making this and thanks YT for putting it on my recommendation. I've tried reading a lot of articles on "Git Merge vs Rebase". I still struggled to understand. Your visual guide helped me understand it. Now I have to practice and understand where to apply this workflow. Thanks, mate 💯. Keep up the good work 👍
Git must be explained with real examples and animations. This was the best tutorial I have seen on internet so far. Top quality content. Subscribed.
Thanks for the comment Mrigendra! It's motivating
I do agree that this video was well done, but "must" is a strong word. git is a just merkle tree, like ZFS or bitcoin. You can't re-write history, but you can create an alternate one.
agree with you. the git command is kinda make me confuse for long time. Thanks god someone have made this video to explain it with illustration.
Yep, all articles out there assume we know rebase already, while they're trying to explain what rebase was. It's like teaching people to drive a car while the student even doesn't know how to turn on the car.
Every video has such a comment for sure.. no matter if 50% of viewers weren't able to understand 🤣
The way this is demonstrated with "live command typing" combined with "animated slides" is very intuitive! I imaging this takes quite some preparation/post-production. Thanks for that.
I am a student at a Japanese University.
I study programming for myself.
Thank you for making good movies all the time.
I wish there was a super like button on TH-cam 👍
Wow, I thought git rebase was complex, but you managed to explain it in under 7 minutes EXTREMELY clearly. The graphics really helped. Great work man. Thanks so much
Like the others mentioned, the animations really helped! thank you for taking the time to do them. ❤
Thanks a lot! It seems like no one can explain how git works, so they make videos without graphs just talking in a confusing manner making it harder to understand. Thank you again!
6 years later and this is still an amazing video! Super clear and intuitive, thank you!
Even after 6 years, this was the best video explaining rebase.
Check out the updated version! th-cam.com/video/zOnwgxiC0OA/w-d-xo.html
1. Rebasing master into the feature branch is dangerous if someone else working on that feature too.
2. Rebasing feature into master isn't a good solution, cause you can't revert all feature (if needed), you have to revert all commits one-by-one of that feature.
3. Git history can be nice and clean if you will merge features into the master with not allowing fast-forwarding and use "first-parent" when looking into log graph. In that case you will get just merge-commits which describes what that feature does and no other commits.
4. If you are working with tags, and, for example, track revisions of commits in your feature branch, rebasing will mix all tags into master.
so, as for me, rebasing sub-branches into feature branch after code review is a good idea, but rebasing into master or from master into feature branch doesn't look like a good solution
Can you squash a feature branch AFTER merging it in order to achieve something similar to first-parent when looking at the log graph?
m
| \
| * m
| | ----> | \
| * | * (squashed after merge to master having taken place)
| / | /
m m
@@PaulSebastianM , I'm afraid, i don't get your question. I can squash feature branch before merging, but I don't see any reason for that. Your master graph will be clean on first-parent, and additionally, you will have every commit in feature branches. it is convenient, as for me
Fully agree. Rebasing feature branches are nice to make the history clean. I don't see the advantage of rebasing master at all.
@@freefallintoflames Agree. Rebasing master sounds like a horrible idea. It can cause all kinds of havoc. There are exceptions to the rules, but I've seen people accidentallied master because "git push -f" and borked the rebase. Didn't take long before we started marking master as protected.
I agree. The only time rebase made sense to me was when I needed to cut a feature out of a branch.
I could not care less if my commit log is a straight line. Why not preserve the history as it is?
Probably watched half a dozen videos...but nobody taught this concept better than u...the animations were ❤️
If you'd like to preserve the idea of merge requests and approvals I recommend doing rebasing only on feature branches and when it's good to go open a PR to merge with master. This will help prevent damage being done in master as well.
this is a really key point, all examples i've always seen of the rebase method, forgets to point out when doing pull requests it's best to squash merge, rather than rebase, i.e golden rule of rebasing public branches is frowned upon.
I think it's better to rebase first, squash and then open a pr
really love the way you organized things at 4minutes with the branch updating as you go. Even better than you showed local master vs remote master. Nicely explained as well.
Best git video on TH-cam. I've been using this strategy since 2013 and it's still the best approach I've found. I'd suggest just ignoring everything after 5:25 and just open a PR to the repo at that point. Then try to get your code reviewed/merged first so someone else has to deal with merge conflicts-otherwise you will have to rebase your PR frequently depending on the size of the team working on the repo.
I agree with Cory. Seems like push to master this way only makes sense when you have complete trust that the changes your are introducing the master are good ones. Most development teams will want to implement a Pull Request (PR) so that peer review, CI/CD, etc. can be applied to the potential feature before its becomes part of master.
seriously.. i've watched a ton of videos, read countless stackoverflow explanations and other articles and still didnt quite see the benefit or thoroughly understand merge vs rebase. but this video made it make sense. thank you.
The extra time you have spent creating the animations is well worth it - especially recognising that at some point your local work has to be pushed up to the origin repo - this is the best video on rebasing I have come across - I've subscribed to your channel - thank you for creating this tutorial.
This video has been up for longer than the duration of my career and I'm just now finding it. I've read or watched about 100 descriptions of Git rebase, with static diagrams of before and after, but they never really demonstrate the steps.
Really well done. I'm going to go try it right now.
this is the best video on rebase i found on youtube
I agree !!
Definitely agree too! Thanks
I agree!
AGREED
I watched 4-5 TH-cam videos on rebasing, but I still didn't understand what it does. However, after watching your video, I now understand rebasing clearly. Thank you so much from the bottom of my heart!
Really glad this helped you out!
That lil animation with commits moving across speaks a thousand words. Well done. Will share with my team.
Watching it in 2024. This is pure gold!
Tutorials like THESE must be added to any command on GIT documentation! GIT in itself, without any specific real world examples is so complicated (at least for me) and I understood about 60% of the theory they were trying to teach me in GIT docs but still not sure if I'm supposed to rebase from master onto my branch or checkout to my branch and then rebase master in order to get the latest master branch code changes to my feature branch and was reluctant to even try to do it ! This is exactly the video I needed to see, thank you my friend
Thank you for explaining this so well. Almost 5 years later, this is still the best explanation of this on TH-cam.
This a very good demonstration 👍Props for that! However, I strongly advise against using rebase this way. Better avoid rebase all together. With bigger projects you will spend 10x more time on solving conflicts. There will be conflicts on files that your feature branch didn't even touch and often you need to solve conflicts on the same lines multiple times because rebase goes commit by commit. And all of this trouble and wasted time just for fewer lines history :) Those lines are very rarely needed anyway. Modern tools also can compare branches and list you missing commits from both sides and clearly show the state of branches. Git rebase is a very powerful tool but at the same time has potential to delete other people work because you need to do force push (or merge with remote again solving conflicts usually :)) ) Anyway, I left my 2 cents, thanks for reading and good luck 👍
I don't understand "has potential to delete other people work". Why do you need to force push?
Unless you're re-rebasing commits you already pushed before (which of course is very bad), I can't think of a scenario where you'd need to force push.
Completely agree, on a larger project this would be a shit show. Imagine going through 50 commits that you don't even know what got changed or how it worked. Keeping an untouched master branch and having your feature branch not be behind in commits will allow any merge to be light and any conflicts easy to handle.
@@shashwatmehta9733 agree with your point, rebase before pushing commits on remote
Thanks for the advice, i am new to this world i just want to add one thing here,
if you are using scrum/agile development flow and creating individual branches for each of your tasks, then you will be rebasing only your commits
reason for rebasing
1) squash unnecessary commits into one commit
2) remove unwanted commits from other branch if you have taken pull or created your branch from their branch, i mean your branch contain work of other branch which isn't ready for merge, you can use rebase --onto to remove all those commits
3) Clean history of course :)
don't rebase master/release branch or any branch on which 2 or more developers actively working,
Golden Rule 😜:
1) Rebase your branch before pushing commits on remote
2) use git merge at time of merging branch into master/release branch
How would you recommend solving this problem?
'git pull --rebase origin master' while on your feature branch is a shortcut to update and rebase your feature branch without switching to the master. Thanks for the video!
Bro, thanks so much!!!! really enjoyed the graphics on the video that went along with what you were saying.
Victor Villacis thanks for taking the time to comment. I'm glad all that time spent on those animations is paying off!
super-duper easy to understand the concept with your graphics.. thank you very much
True. This help a lot
Agree, the graphics in sync with your commands was great
and the graphics, that is really whats it all about
Dear Modern Coder, Appreciate your time for this video. I asked from my parner to look into this video to understand between rebase / Merge.
Rebase / Merge comes into picture while you are working in two different branches. by the way I was working on same branch - develop. it made me bit surprise when he asked me rebase it first before taking fetch/pull.
Anyhow it nice explanation between rebase and merge -
If you say Git merge it into master, it will combine the tasks of feature into master by creating a single new commit at the tip of master.
On the other hand, if you say Git rebase , it will place the entire commit history of the feature branch on the tip of master. It means that your entire feature branch will be reattached to the tip of master and it will look like a linear sequence of commits.
A lovely visual way to explain quite complicated concepts, and delivered in less than 7 minutes. Great job, thanks!
Thank you for the clear explanation! I did it step by step and found out that I was corrupting my feature branch. in order to avoid that, I had to add a force push command right after rebasing feature with master.
The full command list that worked for me looks like this:
git checkout master
git pull
git checkout feature4
git rebase master
git push -f
git checkout master
git rebase feature4
git push
Very short and sweet... every second and word was most valuable. You made it so easy to understand. Thank you so much for your efforts.
I can say this is the best tutorial after watching tons of clips about rebase, and this is the first time I finally figure out how to use rebase.
Despite pushing to master, that was good explained.
I'm using interactive rebase a lot for editing older local commits and organize the tree after PR. Git is awesome!
I spent the lat 24 hrs trying to figure out how the whole process of rebase was and how it works. Now with your video makes total clear
I've never run into the "cluttered git graph" in my nearly 10 years of being a professional developer.
Rebasing, from my experience, just makes the commit history in your trunk branch harder to work with, and is prone to introducing conflict resolution errors.
If you're having issues with branching, maybe the solution isn't to try and obfuscate the branching problem. Maybe you need to take a look at what's causing the issue in the first place.
Great visual explanation at the end.
2- In your pattern, when we want to get feature branch changes in local master, you used “rebase”. I think, if we had used “merge”, it would have given the “same output” and commits in local master would have been linear (because in the previous step, we had moved the last changes of the local master to the feature branch). Do you agree to use merge at that point? The good thing about this way is that you can introduce a template for the entire git-flow diagram:
“Integrate from origin maser to local feature with rebase”
“And vice versa, Integrate from local feature to origin maser with rebase”
I have watched this video multiple times. explanation is very clear and simple, and most important video is short
Hey, thank you (specially) for the animations! I was struggling on digesting how git rebase worked and that helped me so much!
After years of not being understand rebase, this video finally hits home! Thanks!
UPDATED REBASE VIDEO: th-cam.com/video/zOnwgxiC0OA/w-d-xo.htmlsi=eSYbRNIooTNCb5g-
MORE GIT VIDEOS: th-cam.com/play/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM.html
You can combine the 4 steps, the `git checkout master && git pull && git checkout my-branch && git rebase master` with a single command:
`git pull origin master --rebase`
Thank you for this! Git is somewhat mysterious, and this is illuminating.
Yeah, if you could do one on cherry picking too, that would be great! I'm still often confused on that process. :o
And code review be damned?
@@kamok1017 nice"
SUPERB... Video. Crisp and upto the point.
Nugget sized videos - addressing specific topics
THANK YOU SO MUCH
This video saved me a lot of reading and researching time
Awesome, thanks for taking the time to leave a comment. These videos (and especially my new ones) take an insane amount of time/effort to produce, so it's nice to know they're helping!
This is the first video I've seen.
People who use git like this, don't like curly braces, semicolons, and work on OSX.
I always wanted to create a workflow like this but my limited knowledge with git didn't allow. Thanks a lot for putting this video in concise and straight forward manner.
masterBr featureBr
featureBr> git rebase masterBr (updating features baseline)
masterBr> git rebase featureBr (bringing feature in same line of master)
simple and precise . good job!
I haven't seen any git tutorial videos with this much animation and easy explanation.
Great work!!!
Glad to hear that. Check out my other recent git videos and let me know what you think: th-cam.com/video/q53umU5vMkk/w-d-xo.html. I'm trying to ramp back up
I don't quite understand how it fixes the "mess", you'll still have tons of feature branches side by side if you have a lot of co-workers.
And if you just want the linear history for master, you can look only at the master branch log, right?
The mess is when a feature branch has a bunch of merge commits from master. The history graph starts to look like someone was braiding some string. Then you have all of the overlapping feature branches, and soon it looks like a rope.
@@BenjaminCronce but it helps to tell features' branches apart, right? if the history is just a straight line, is it wrong if i say it will be hard to track each feature's merge time?
@@BenjaminCronce Oh, I get it now. I was assuming that feature branches were rebased on top of master when needed (to get a fix from master) but still using merge commits from feature branch to master.
I don't know why I found rebasing confusing before, I couldn't get my head around it fully. This video did it for me, thanks
Never rebase master branch onto a feature branch unless you are sure what are you doing. Here my golden rule, if a branch is public DO NOT ever rebase it. Someone might be working with a commit, which on your rebase strategy might be re-written. Additionally, the new tree structure when you rebase master onto feature is only visible locally for your (you might have also duplicate commits if the master branch has forked from your feature branch). The other developers would be still using the origin master branch.
I was very confused by what he did in this video (i think the video should be removed/edited). Rebasing the master branch to the feature seems crazy.
I hear you both and have updated this video to clarify a better rebasing strategy:
th-cam.com/video/zOnwgxiC0OA/w-d-xo.html That said I don’t agree that using rebase to move commits onto master is inherently dangerous in such a way as to suggest this video be deleted. It may not be best practice, but there’s a difference between not strictly following best practice and a dangerous anti-pattern.
That's the best demo of not just merge and rebase but also quick recap for pull, merge, push and when should one do each of these. Thanks
Using rebase to ensure locally that master works well with your changes is a great idea, but pushing straight without any kind of peer review is insane.
I have never watched a tuto like this, i completed understood rebase in a few minutes. I will subscribe, thanks a lot!
I mean, the graphs becomes easier to look at but what good is that if you lose history?
You don't "lose" history
@@Philbertsroom You rewrite history - which means you lost your original history. Specifically, you lose the state before the feature branch was merged because you force it on top of the commits in master.
@@Gismo359 You're replacing the old history with functionally equivalent history...
@@Philbertsroom It is not equivalent - you cannot navigate the old feature branch in the same way that you could before rebasing.
It causes headaches if there are multiple people working on the same feature branch, or if something not related to your branch changes before the rebase.
@@Gismo359 Just have a naming convention for commits or add which feature the commit is related to in the commit message. These "issues" can be fixed with a slight change of workflow
I am a visual Learner, and I found the way you synchronized the graph with the command line really brilliant and easy to digest
I strongly recommend NOT to use this!
Rebasing destroys your --first-parent history that is so important for enterprise projects. You will have every small commit of every feature branch in your masters first parent history. This makes it impossible to track what feature and when exactly it was merged onto the master. You lose the possibility of generating changelogs/releasenotes just from your git history. Also this makes it hard to find the culprits of failing build on your CI pipeline. This may be suitable for very small and hobby projects, but I think it's better not to get used to this and use git in a way that is suitable even for bigger projects.
As a rule of thumb: Never rebase anything that's already pushed!
You can rebase and squash feature branches into one commit describing the feature. This lets you have a clean, linear history, with each commit describing one feature. Squash is missing in this tutorial.
I do not agree completely! When you are on your FEATURE BRANCH, you should ALWAYS REBASE against remote target branch. Because you want to want to fix conflicts on your local branch, and not have to merge remote branch to your local branch to do this.
Then when your code is ready to be put on REMOTE BRANCH, ALWAYS MERGE by making a pull request first for review. ALWAYS activate Squash option of your pull request tool to not merge all the single commits.
This workflow is clean and entreprise approved in big companies with huge projects (i work for one)
@@alfredomoreira6761 isn't this what the video author is already doing? He's rebasing the feature branch to the remote master branch by pulling the remote changes and then rebasing the feature branch on it, and taking care of conflicts there while still on the feature branch (he just doesn't have conflicts in the example but mentions taking care of them if they arise).
@@kmr_tl4509 With squashing you will lose every single commit from your developers that may contain valuable information on WHY a line of code was changed. This is very important when dealing with problems from customers later on.
@@alfredomoreira6761 I assume you mean that you have to rebase your local master onto the origin/master when pulling, that is correct. With squashing you lose valuable information from the development. But that is - of course - up to you and your company.
I've been doing this for over ten years and this is the best explanation I've seen...well done!
When you did "git rebase my_cool_feature" at the end, what happened to the my_cool_feature branch? Is it deleted?
No, the branch remains there until you deleted it.
Finally a video that goes straight to the point and uses a graph to illustrate. Thank you very much!
I think this is the worst usage of git I've ever seen.
why? genuinely curious.
Agreed. I've done worse while I was learning, but not now. The golden rule of rebasing: "If it's a remote branch you never rebase... ever. If it's a local one do whatever you want before you push it for the first time.". It took me two weeks of attempting to resolve the mess I created by doing just that, and it took a lot of reading to get to a semi-competent level where I could establish rules for my team to follow, without leaving the possibility of messing up in the process. Today we only use rebase once in a blue moon, and even then, only if absolutely necessary. It's a nice 'tool' but you have to be careful with it.
Updated video that addresses some of these rebase shortcomings in more detail:
th-cam.com/video/zOnwgxiC0OA/w-d-xo.html
Yes I agree, I didn’t feel as though this video make it clear enough how that commit movement happens behind the scenes during rebase. I’ve addressed that in the updated video (linked above in this thread), let me know if you have a chance to watch that - I think it does a better job in general of explaining the merge vs rebase difference
if we go with rebase, then how can we use Merge Request?
this method of doing tutos is amazing honestly this is the first time i see something with animation like that, man continue like that, keep up the work and THANK YOU
Don't rebase. Wanting to have a "nice, clean straight line graph" is the dumbest excuse to rewrite history. Version control is not supposed to be visually pleasing and its even harder to understand things when you rewrite history. Very bad practice IMO.
I was thinking exactly the same thing, merge commits look messy if you try to lay them out visually on a timeline but that's not the point at all. If anything putting it all in a straight line makes it harder to understand because you lose all of the important information from the branches and merges.
There is nothing about being visually pleasing. It's all about being able to track properly every commit. To see which feature were implemented at what specific point in time. To see what commit caused which bug. And, mostly, to revert properly.
FINALLY a tutorial that explains in a very clear and fun way how git rebase works! A big thank you to you for your video which is useful to all of the developers!
The best explanation to those tricky to understand concepts. Visualization of the commands helped me to understand those concepts.
your git explaining video is amazing. It makes me open eyes about git workflow without any difficulty and plus I didn't feel toxic over git thing anymore. Thank you. Please create more of git workflow videos.
More are coming in a few weeks!
I've seen tons of videos that show the logs, different animations and stuff but somehow, with yours I just clicked. Thanks a lot!!
Of course - thanks for letting me know this resonated with you!
Thanks! This video clears out my question. I've had confusion for months understanding the difference between merge and rebase. I'm a noob, I admit. Most articles out there, assume that the reader knows how to rebase, and never pointed out detailed steps on how to do rebase.
thank you a lot, with your animation it is easier to understand what going on. Most people just talking and it's really hard to follow.
Short, simple, to the point. No useless fluff. Real life example, plus easy to follow diagram.
You are a magician, all the post I have studied is actually a waste of time. Only your video animation made it simple for me to understand what am I expecting. Best wishes to you. make more videos like this.
Oh man... can't tell how good this explanation is.. i was fed up of the examples made here on youtube. Thanks.
I just tried rebase for the first time in my life in my job. it worked smoothlz. thx! 😃
Whether rebase to master is good or not is different topic but the way you explained with graphic + commands is superb, I will never forget now what is rebase ! Would watch all your other videos
Just sub'd. Excellent video, been using Git for nearly 6 years and someone has finally been able to explain rebasing to me succinctly.
most straight forward guide ever found on rebase
I’m really thankful for you having produced this material on git rebase. Thank you. Also, I really appreciate the write-up as well. Great contribution. Subscribed.
This is the best tutorial on Git. Code + Animations are an awesome combo. Thank you so much!
Just what I was expecting . Proper workflow example , one of the best out there!!!👌
This is the best tutorial that I have ever seen. It has real example and a graphics and animation to clearly visualize what was going on. Every tutorial in the youtube should be like this. Excellent work my friend! Keep up the good work. Thank you for this.
you are a legend man. Don't usually write comments but this is just amazing. Your animations are amazingly in sync with your steps.
Best lecture on rebasing I have ever watched. Thank you.
This is what we want. Someone who can explain what's happening n the real time production
Brilliant use of Visualization AND live code demonstration. All very helpful for a confusing concept.
Thanks so much for this video, I'm a visual learner and the way you paired those diagrams with your simple explanation made it so easy to understand.
Good to see it. Before this I thought that rebase does not dismiss my feature branch, only displays like it would have been branched from other commit of the main branch.
Was struggling with the concept, but your illustration and explanation made it a lot easier. Thanks dude.
I think the way you have animated the process of what was happening while you were doing the stuffs are very clear and help a lot to understand how Rebase works. Thank you, I have used this video to explain the process of rebase to others. :)
Thanks awesome! Thanks for leaving that comment, it's motivating
The best explanations with visual content I have ever seen, I was so struggling to understand git-rebase. Thanks a lot! 🙏🏼
Really appreciate the animations. It made visualizing the whole process a lot easier. The best description of rebasing I've seen. Thank you!
I've watched a couple of videos, but this was the only one that explained rebase well.
Thanks a lot for the animations
I'm wayyy late but this is by far the best explanation of rebase I could find on the internet. Love the animation. Kudos
Appreciate you saying that! Never too late, I’m coming out with new git videos as we speak
Like they say... a picture is worth a thousand words. Thanks for the awesome graphical explanation this was driving me crazy
Great visualization with the branches, and what you type and what happens all is visible at once.
So much better than what other people do, where you see either the code or the branch-visualization, but not all at once.
Well done.
Good quality in the video. Well done. In our environment, no branch is allowed to make pushes to master. Only merges after code review. But Rebase can still be used on the feature branches you are working on when you have to pull other's changes that have been merged to master.
Definitely, and I can see the reasoning why you'd want to only allow merges after CRing. When you merge, no history is lost so you'll easily be able to go back and track each feature as it was developed and pick out exactly when it made it into your master branch.
Best explanation out of hundreds on the web. Thank you!
wow, the animation is amazing for us to understand. It's way much clearer than other videos.
I found rebase is really nice when doing PCB layout with Kicad. You pull when you start and rebase when you are done. The nature of it makes it so that you can't collaborate but it makes it easy for people to add in changes to the schematic and pick up on your work.
This is the best and simplest explanation about merge vs rebase
Thanks for the clear explanation. best video on rebase on youtube. solved the confusion I have been having for a year.
Possibly one of the best videos explaining the topic. Looking forward to more videos around git workflow
Dude, million thanks. Best video on the topic for sure. Good luck with your channel! Keep us busy with new content 😎
Thanks, I'm hustling for new videos. My current videos take these motion graphics up a notch so they take quite a while to produce. While you're waiting, if you have some time, check out the updated rebase video I did a couple months back: th-cam.com/video/zOnwgxiC0OA/w-d-xo.htmlsi=eSYbRNIooTNCb5g-. Appreciate you watching!
well explained on git rebase with graphical view. my gratitude to you. much appreciated !!
Mathew. from Colorado
why haven't I watched this before? Thank you for making this and thanks YT for putting it on my recommendation. I've tried reading a lot of articles on "Git Merge vs Rebase". I still struggled to understand. Your visual guide helped me understand it. Now I have to practice and understand where to apply this workflow. Thanks, mate 💯. Keep up the good work 👍
And I subscribed for more.