This is a great video for explaining the difference between merge and rebase. The only thing that seemed "weird" to me was rebasing feature branch on master. I like to use rebase to keep a feature branch up to par with master, but then use merge to move feature changes into master (once development is finished on the feature).

Quick example: 0:30 In the project: 2:00 Merge a 'summarized' new feature: 4:25 git merge --squash branch-name : 5:50 Adding the new 'merge' commit: 6:30 Second way with rebase: 8:00 git rebase master: 9:20 Explanation: 10:25 Playlist: Git & GitHub - Managing Your Code: @

I’ve been trying to wrap my head around this git stuff for a month now and things like this have just alluded me. But this demonstration was perfectly and concisely clear. Thank you for opening my eyes.

I’ve watched tons of git videos as I try to increase my understanding of keeping history clean when merging code. This is one of the best I’ve seen, hands down. The example was clear and you explained exactly what the different options would produce in terms of history/commits. Thank you, this is a huge help.

Excellent. Best source (written or video) that I've ever come across that simply shows you how to use rebase to your advantage when working on a feature branch.

Good to know. So far I only used merge. So when I'm on a long-living feature branch I sometimes merged the master branch from time to time in, to get the latest updates and to make merging into the master easier later. Now I will use rebase for this

Oh I finally understand why it's called rebase, because you are effectively changing the m2 commit feature is based off of to the m3 commit. You have effectively rebased it! thanks!

I felt like I just wanted to reach into the screen, go back in time and give this guy a great big hug 😁 Such a good explanation 👏🏾

Today I learned about git merge --squash! Thank you!

This is a really good video because you slowed things down and thoroughly went through and explained stuff, repeating the key important points over and over. This is important information to understand basic of git. Thank you!

Worth mentioning that when doing 'git rebase master' while being in the feature branch, the original f1 commit was rewinded on top of the feature branch with a new commit id. Whereas when doing 'git rebase feature' while being in the feature branch, there was nothing really to be rewinded (there were no new commits on master) so master branch was just fast forwarded i.e. none of the commit ids changed. In short, When in feature branch with feature branch ahead, commits in master will have same ids, but feature commits will have new ids When in master branch with feature branch ahead, commits in master will have same ids, and it will same feature commit ids to master branch

I think the golden rule is you should merge to master branch and rebase the feature branches

Awesome explanation. As a beginner i was struggling through it and now understood the concept of rebase just in 16 minutes :)

Could you please make another video when different developers touched the same file in different branches? For merging and rebase concepts. Thank you.

thanks for the really clear tutorial

Finally a explanation about rebase that actually make sense. Thanks a lot. Great work.

Awesome! Super simple explanation for understanding 'squash' and 'rebase'. Also useful in avoiding merge commits (maintaining a clear/clean history) - just use 'git pull --rebase' before pushing all local commits to repository (since git pull is effectively just a git fetch followed by git merge).

Great tutorial. Never seen the squash command being used directly on master like that. I am used to doing an interactive rebase on the branch and squashing on the branch before merging with master Doing this flow with pull request would be nice to see. That is how we currently work at my job

Great video. Super clear explanation. Loved the idea of having the code and the commit being the same text, it makes everything so much clear.

Awesome explanation. As a beginner, i was struggling through it and now understood the concept of rebase just in 16 minutes

I’m a rebaser and proud of it :) lol, I always work with private feature branches, either taken from master or from a public feature branch. My workflow is to then rebase from the source branch prior to merging (or creating a PR). This way I can validate that my code changes, through unit and integrations tests, work with the latest code. Not saying it’s the right way that’s just how I work, wanted to share! Happy merging!

The best `git rebase` explanation I've found so far!

Coming back to this video on a yearly basis since 2018

I would be happier if this covered normal merge (with merge commit) versus rebase which usually brings more heated discussion.

Thanks! I readed other sources but didnt get it clear until now! thanks again!

Simply the best explanation I saw for rebase and merge. Thank you so much!

I finally "got" it .. the very "fine detail" of how rebase works start at around 10:45 of this video. Using my own way of thinking: Whichever branch you are about to issue a rebase command against another branch, the steps are: 1) Git "rewinds" both branch "timelines" until it finds the common "denominator" ( ie: common commit both branches share). 2) Git then finds all the changes that happened in the current branch past the common "denominator" and puts them "aside" - let's call this "my current branch changes" .. 3) Git will then find the changes of the other branch that happened past the common "denominator" and puts them "aside" - let's call this "the other branch changes" .. 4) Git will now re-create a new branch timeline after the common "denominator" on the current active branch we issued the rebase command using the following "formula": "other branch changes" + "my current branch changes" and will add that timeline of events after the common "denominator" .. So the new branch timeline on the branch we issued the rebase command will be: .... "common denominator commit" + "commit changes of the other branch after the common denominator" + "commit changes of my current branch after the common denominator" While now all is "crystal clear" to grasp this concept, nevertheless it took my about two days of thinking and reasoning and replaying this video several times until I got it .. Thank you for providing this video.

FINALLY someone explained it fully with examples and conflicts, rather than just reading out the commands

wow truly helpful in understanding the rebase command I would have used in last project but somehow not confident on how things would be, now all my doubts are cleared now. Thanks for the video.

Excellent explanation using real time example. Thanks a lot for your effort to depict the exact git merge and rebase scenario. Loved it.

The pseudo-algorithm (at 10:25) for git rebase was a very good step-by-step guide showing what is going on under the hood while execution the rebase operation.

Many thanks for the tutorial. This helps me a lot in understanding merge vs rebase.

Now I understood the difference and fundamental logic behind it. Thanks for the video.

Excelent explanation. One of the few tutorials that actually made me get a little bit closer to understanding the difference between the two.

Extremely helpful, I'll make sure to check out the rest of your videos

Simple and clear explanation. Well done !

I'm at 2nd minute but already see that you explain everything very clearly!! Great & thanks for the video!!

I just left the video in the middle of it to say thanks so much for such a Crystal clear explaination

Great explainer. I reckon rebasing avoids merge conflicts, good for non shared branches as long as you do a pull from master first as somebody commented below before switching into the feature branch to rebase from master

Straight Forward & deep dive explanation. Thanks for your effort.

this is one of the most clear explanations on the subject, thanks

My life is changed forever, thank you so much 😊

amazing explanation, and excellent visual ! thanks many times !

Best explanation on reset and revert

Just found this video randomly. Very well explained. Thanks. I subscribed you channel now😀.

Thanks for taking the time. Great explanation!

Thank you sir this was very useful and I always wondered what the difference was between rebase and merge. Excellent explanation!!

Very nice. Teaching git is not only code but concepts as well . Thanks a lot !

You just rebased my Git understanding. Thank you!

This is a very challenging subject to explain with words, and you did a great job.

Great video! been trying to understand rebase and this was one of the most helpful explainations

Thanks, Manu! Love your channel (I mean you and Max tho)! You are doing a great content! Hope we'll see a lot of new stuff from you, guys, in the future!

Perfect demonstration, i have never understood this until now

Awesome, Very well organised and explained, Thank you so much!

Great video, even for a beginner like me. Something that didn't click for me is that the first commit of one branch is common with the other, hence the branch is "based off" another one: with this in mind is fairly easy to understand rebasing, and also helped me to better read git log graphs, which seemed a little strange at first for me: if I had a main and a dev branch and I'm only commiting on dev, I would expect to see two "lines", one for main and one for dev. But in the graph output I saw only one and didn't understood why, until I realised that the commit were I branch off is the BASE of dev, so it makes sense to have just one line, if I'm only committing to dev!

I am enlightened for life about merging the branches.

I can't thank you enough for this. Cheers for great video!

i guess Max and You were brothers. Best Explanation :). thank u so much !!!

Thanks for such a good tutorial and i like the demonstration by picking up a scenario.

oh! my! god! why didn't I get that before? I completely ignored rebase, never saw the interest in it... but the way you explained it, amazing! Also instant like on --squashed! thanks for this video, really!

Really good example and explanation! Thank you, Manu! Greetings to Max as well ;)

Great demonstration! You are really good at explaining the concepts, similar to how Max does it. The individuals here asking for more pictures in my opinion need to work more with Git to better understand the basics. The explanations were really clear, and I only have around a year and a half experience. This is not easy stuff by any means, so if you're confused, just take a step back and practice adding, committing, branching, and merging some more.

Great Video !! Explanation was very clear and easy to understand.

Great explanation of the rebase, thank you.

Best Explanation i've found. thanks a lot Sir! Brilliant!

Great video and the way you have explained this topic is best! i want more videos on Git thanks

This was surprisingly clear. I think you did a terrific job of being very clear, with easy-to-understand examples. Also - kudos for using VS Code. I'm not much of a Microsoft fan, but VS Code rocks!

Tip: CMD+K clears the console in most apps, Terminal, VSCode, Webstorm, even Chrome DevTools!

I loved the naming conventions for branches and commit messages; unambiguous and to the point.

Great explanation...again, Manu. Thank you very much. Could you please do a video on gitflow in the (near) future. That's a subject I really need to master.

easiest tutorial ever. Thank u so much sir. :-)

Very good video, keep up the good work. Just subscribed - thanks

Thank you. Perfect tutorial!

Thanks for the easy explanation and demo.

Clear video with exact points Very helpful

Best Video I have seen on Git Merge Vs Rebase!!!

Thanks for clarifying this concept 👍

Awesome explanation. THANK YOU.

Thank you for this great video. very useful.

I was looking for a example video to share with some devs, and this is an example of a video that complicates something that is very easy. Basically "merge" keep the history of the branch untouched and "rebase" moves your code/code that is different between branches to the tip of the branch you are rebasing and insert newer/the difference of the code before, simple like this.

Thank you for the great explanation.

i have a question. sometimes on feature branch, we have lots of commits. whenever we try to rebase, lots of conflicts occurs. whenever we try to solve this conflicts, it starts with first commit to solve. it is very complex process. how can we deal with it?

Thank you for explaining clearly

Thanks a lot. Very nicely explained.

thank you, you presented this very well.

Thank you for this explanation .. but I have one question as I realized that it always add the new commits from the current branch as the last commits .. can we control this order or not? another question .. If I want to revert the commit after I did "rebase" then what is going to happen? let's suppose that master is m1 m2 m3 feature is m2 f1 and we are currently in the master and did git rebase feature ... now the master is m1 m2 f1 m3 right? if we choose this commit and select reverse .. the master will back m1 m2 m3 ? right ?

Very well explained. Thanks!

You're an awesome teacher !!

thanks for the detailed explanation.

Great video Manu. Thank you

Wow, superb, appreciated!

thanks for this awesome explanation

very beautifully explained. thank you

Not sure why you didn't make the terminal window taller, since the "code" window had at most 3 lines, and why you didn't use `--oneline' instead of scrolling to see the commits. I think it would have been easier to see the "whole" picture that way. Just my opinion, though. As for the explanation and examples, superb job! Thanks.

Very nicely explained. Thanks for the good knowledge sharing

Amazing explanation very clearly understood

This is an excellent explainer, thank you. And I know you were just using very simple examples, but nobody should rebase anything into `master` or any other common branches, ever! Rebasing should only happen in feature branches.

Thanks Manuel, well explained!

Detailed and clear. Thanks!

I was deciding whether or not he had a german accent; but then he said "entwickelments" instead of developments and it all became clear to me.