Learn Git Rebase in 6 minutes // explained with live animations!
The better way to learn Git. Discover how visual animation and live coding examples can shortcut your Git journey: learngit.io/
Newsletter readers get my videos early: newsletter.themoderncoder.com/
----
LINKS
Written rebase reference: www.themoderncoder.com/a-bett...
Rebase caveats: www.atlassian.com/git/tutoria...
MY TECH
www.themoderncoder.com/wfh-ny...
MUSIC
Intro/outro music by Dyalla: / dyallas
DESCRIPTION
In this git rebase tutorial, I'll show you a different way of approaching git branching/merging with rebase. My team at Amazon adopted the workflow you'll see in the video and we love it. Whether you're mostly a solo developer or on a large team, give this a shot, I guarantee that even if you don't use rebase all the time, it will become an essential part of your development toolkit.
Пікірлер: 1 100
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.
@themoderncoder
5 жыл бұрын
Thanks for the comment Mrigendra! It's motivating
@BenjaminCronce
4 жыл бұрын
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.
@jaytran247
3 жыл бұрын
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.
@UPIL.INDONESIA
3 жыл бұрын
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.
@factfetch5441
2 жыл бұрын
Every video has such a comment for sure.. no matter if 50% of viewers weren't able to understand 🤣
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
@PaulSebastianM
4 жыл бұрын
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
@alexeyvolkov7878
4 жыл бұрын
@@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
4 жыл бұрын
Fully agree. Rebasing feature branches are nice to make the history clean. I don't see the advantage of rebasing master at all.
@BenjaminCronce
4 жыл бұрын
@@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.
@PhysicsITGuy
4 жыл бұрын
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?
Like the others mentioned, the animations really helped! thank you for taking the time to do them. ❤
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.
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.
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
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.
6 years later and this is still an amazing video! Super clear and intuitive, 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.
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
A lovely visual way to explain quite complicated concepts, and delivered in less than 7 minutes. Great job, thanks!
That lil animation with commits moving across speaks a thousand words. Well done. Will share with my team.
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 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 KZread 👍
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.
Really appreciate the animations. It made visualizing the whole process a lot easier. The best description of rebasing I've seen. Thank you!
this is the best video on rebase i found on youtube
@aguirregabiriathomas6195
5 жыл бұрын
I agree !!
@MarkEdwardTan
4 жыл бұрын
Definitely agree too! Thanks
@alexanderjesusvargas5998
4 жыл бұрын
I agree!
@filbertshi5932
3 жыл бұрын
AGREED
UPDATED REBASE VIDEO: kzread.info/dash/bejne/rIOi2cmxmaaWf6Q.htmlsi=eSYbRNIooTNCb5g- MORE GIT VIDEOS: kzread.info/head/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM
@kamok1017
4 жыл бұрын
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`
@Jianju69
4 жыл бұрын
Thank you for this! Git is somewhat mysterious, and this is illuminating.
@scottamolinari
4 жыл бұрын
Yeah, if you could do one on cherry picking too, that would be great! I'm still often confused on that process. :o
@stojadinovicp
4 жыл бұрын
And code review be damned?
@TheElexec
4 жыл бұрын
@@kamok1017 nice"
Nice video, great job. Love the simplistic way you overlay the animation over your code. It's nice and simple, but effective. Keep up the great work!!!
This is so incredible! What an incredible tutorial! Definitely liked and subscribed! As someone who's been making regular merge mistakes lately as a new full stack developer, I"M SO GRATEFUL FOR THIS! I understand it now!!! :)
Bro, thanks so much!!!! really enjoyed the graphics on the video that went along with what you were saying.
@themoderncoder
6 жыл бұрын
Victor Villacis thanks for taking the time to comment. I'm glad all that time spent on those animations is paying off!
@RalphEmersonIligan
5 жыл бұрын
super-duper easy to understand the concept with your graphics.. thank you very much
@Lankathilaka
4 жыл бұрын
True. This help a lot
@sallerc
4 жыл бұрын
Agree, the graphics in sync with your commands was great
@Hangman11
4 жыл бұрын
and the graphics, that is really whats it all about
Hey, thank you (specially) for the animations! I was struggling on digesting how git rebase worked and that helped me so much!
Thank you for explaining this so well. Almost 5 years later, this is still the best explanation of this on KZread.
This is the best tutorial for git rebase ive watched. Your video quality is the best and explanations were also crystal clear. Thank you so much!
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!
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 👍
@shashwatmehta9733
4 жыл бұрын
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.
@jatd104
4 жыл бұрын
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.
@hanzladev
3 жыл бұрын
@@shashwatmehta9733 agree with your point, rebase before pushing commits on remote
@hanzladev
3 жыл бұрын
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
@chaitanyakolluru2256
9 ай бұрын
How would you recommend solving this problem?
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.
Finally a video that goes straight to the point and uses a graph to illustrate. Thank you very much!
Best git video on KZread. 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.
@MatthewMcGuff
4 жыл бұрын
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.
simple and precise . good job!
Thank you for such a clear, easy to understand tutorial of Git! You have totally solved the question that I always have when using Git.
I really like how you show graphically how the branches changes while you execute the commands! nice methodology, got a new subscriber
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”
Thank you very much, this is the only video that actually made me understand how re-basing works. Love the animation and practical too as I learn better visually and practically.
I've been doing this for over ten years and this is the best explanation I've seen...well done!
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 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?
@BenjaminCronce
4 жыл бұрын
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.
@meh398
4 жыл бұрын
@@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?
@ricardoamendoeira5689
4 жыл бұрын
@@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.
The best explanations with visual content I have ever seen, I was so struggling to understand git-rebase. Thanks a lot! 🙏🏼
Wow, this was a high quality explanation, with animations and everything. Keep up the good work man, you're quite helpful.
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.
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.
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
I am a visual Learner, and I found the way you synchronized the graph with the command line really brilliant and easy to digest
When you did "git rebase my_cool_feature" at the end, what happened to the my_cool_feature branch? Is it deleted?
@TestTest-mv7yj
4 жыл бұрын
No, the branch remains there until you deleted it.
I mean, the graphs becomes easier to look at but what good is that if you lose history?
@Philbertsroom
4 жыл бұрын
You don't "lose" history
@Gismo359
4 жыл бұрын
@@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
4 жыл бұрын
@@Gismo359 You're replacing the old history with functionally equivalent history...
@Gismo359
4 жыл бұрын
@@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.
@Philbertsroom
4 жыл бұрын
@@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
This is a great source to get a concise explanation of rebasing with Git. Very well done, thank you 🤓
you are a legend man. Don't usually write comments but this is just amazing. Your animations are amazingly in sync with your steps.
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!
@kmr_tl4509
4 жыл бұрын
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.
@alfredomoreira6761
4 жыл бұрын
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)
@PaulSebastianM
4 жыл бұрын
@@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).
@Marty
4 жыл бұрын
@@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.
@Marty
4 жыл бұрын
@@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 think this is the worst usage of git I've ever seen.
@vwwvwwwvwwwvwwvvwwvw
4 жыл бұрын
why? genuinely curious.
@SuperPranx
4 жыл бұрын
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.
@themoderncoder
9 ай бұрын
Updated video that addresses some of these rebase shortcomings in more detail: kzread.info/dash/bejne/rIOi2cmxmaaWf6Q.html
@jordanrodrigues1279
7 ай бұрын
@@vwwvwwwvwwwvwwvvwwvwThe illustrations are very misleading. A "branch" in git is a bookmark somewhere on the commit graph that points out the lastest commit. When you first switch -c (or checkout -b but checkout is stinky, it's missing modern safety features and is much more likely to eat your uncommitted work) or branch my-new-feature you add a new bookmark at the current location. There's no half-completed edge. Most importantly commits are not sorted into branches. There's no requirement to choose "this commit is on main vs new-feature" We actually say "main contains this commit" which means that the commit is the current tip of main or it's somewhere in the history of main. To classify commits into boxes we actually need ranges. Like "main.." means "part of this timeline but not part of main" -- that's very common because it's commits that you're thinking about but haven't released as main-level stable. The opposite "..main" is commits that are in main, published or integrated, but the code here hasn't been affected by them yet.
@jordanrodrigues1279
7 ай бұрын
@@vwwvwwwvwwwvwwvvwwvw5:19 Also he shows rebase as a shift. But it's not a shift you can't move commits. You can only make new commits or forget old ones (which takes a long time). Rebase copy-pastes changes. It interprets your work as a series of patches and re-applies them somewhere else. Then it changes the branch bookmark to the end of the new commits. This means the old commits are abandoned. It's really important to understand the entire picture here. The abandoned commits might still exist in another branch - which is both a good and bad thing. Good because it means I can't accidentally modify an inactive branch. Bad because if you try to merge both branches, the merge can become more confusing.
Just sub'd. Excellent video, been using Git for nearly 6 years and someone has finally been able to explain rebasing to me succinctly.
Well-explained video and great graphics. Imo one of the best videos on KZread regarding this topic.
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.
@MrHatoi
4 жыл бұрын
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.
@samuelgoncalves5616
4 жыл бұрын
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!
Thank you so much for the illustrations and the guidelines. It’s so informative and its impossible for anyone to to not get rebase after this video. Instant sub thanks man!
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.
Just what I was expecting . Proper workflow example , one of the best out there!!!👌
This is the best tutorial on Git. Code + Animations are an awesome combo. Thank you so much!
Was struggling with the concept, but your illustration and explanation made it a lot easier. Thanks dude.
Love how you show the branches visually. Thanks alot.
Thank you for presenting this with clear animations. It really clarified the thing for me without overcomplicating.
I haven't seen any git tutorial videos with this much animation and easy explanation. Great work!!!
@themoderncoder
Жыл бұрын
Glad to hear that. Check out my other recent git videos and let me know what you think: kzread.info/dash/bejne/o2ln18-OZdmzm84.html. I'm trying to ramp back up
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.
Thank you - very good, step-by-step instructions with graphics. I like how you broke up each step and explained it.
This is an amazing video. Those animations really helped me in understanding rebase. You, my friend, have earned a subscriber today 👍👍👍
i love tutorials that are quick and to the point. This is some quality stuff here. Subscribed
I was searching for a proper article that explains merge and rebase. This is the video I was searching for. Fantastic graphical representation of both merge and rebase
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.
Stellar video dude, damn this is so much more clear than anything else out there. Keep up the great work, you've got the knack!
Possibly one of the best videos explaining the topic. Looking forward to more videos around git workflow
I've been around the development block. This video was great dude. Best video ive watched on explaining these particular concepts. Id pay to see a whole series of git videos like this.
@themoderncoder
Жыл бұрын
Heck yeah, thanks for the kind words. I'm working on a web application for learning Git concepts that will feature tons of videos, animations, graphics and other good stuff . I've been sending out monthly newsletters with progress updates and feature previews, it would be awesome to have you on the email list. Check it out: waitlist.learngit.io/
Amazing tutorial! Very clear and the example section was useful to visualize how the changes move. Thank you 🙏🏽
The animation gave a very clear image in my mind on the rebase workflow. Incredible job!
The most clear and concise video I've seen with a practical example. Thank you! 😄
Seriously thank you! You did a much better job explaining merging and rebase. Im just not advance enough for the other videos and I thought you gave things in a much easier format to understand!
wow, the animation is amazing for us to understand. It's way much clearer than other videos.
Fantastic explanation, with awesome visual presentation. One of the top 5 presentations I've watched on KZread. Thanks a lot !
After years of not being understand rebase, this video finally hits home! Thanks!
The animations really helped! I love this video, simple and straightforward! Subscribed.
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've watched a couple of videos, but this was the only one that explained rebase well. Thanks a lot for the animations
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.
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
I have never watched a tuto like this, i completed understood rebase in a few minutes. I will subscribe, thanks a lot!
Thank you. Very clear explanation. Especially, including the remote repo in the workflow is useful.
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!
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.
Thanks ! was contributing to an open source project, coming from years of svn, that was really obscure for me, it finally makes sense what is happening and how I should use that feature of git regarding the project. To the point, great visuals, no "fluff/subsribe/blahblah/un-necessary content" that makes the video "too long" and hard to follow, really great pedagogical content
Short, simple, to the point. No useless fluff. Real life example, plus easy to follow diagram.
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. :)
@themoderncoder
5 жыл бұрын
Thanks awesome! Thanks for leaving that comment, it's motivating
Probably watched half a dozen videos...but nobody taught this concept better than u...the animations were ❤️
The visuals make it super clear to understand. Great content.
Excellent combination of command line and animation, extremely helpful. Personally I find the ability to rebase a feature branch useful when there have been some hotfixes applied to main, but I always prefer then just doing a merge when combining the feature branch back into master.
really explaining git with animation does make it easy to understand. Really a good tutorial definitely gonna share your video with others.
Dude, million thanks. Best video on the topic for sure. Good luck with your channel! Keep us busy with new content 😎
@themoderncoder
6 ай бұрын
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: kzread.info/dash/bejne/rIOi2cmxmaaWf6Q.htmlsi=eSYbRNIooTNCb5g-. Appreciate you watching!
This was an excellent and clarifying video, thanks! (the graphics helped a lot to visualize each step)
Bulls eye! Quick, short and a good animation helped to understand concept very quick.... Thanks for the video.... Subscribed
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.
@themoderncoder
Жыл бұрын
More are coming in a few weeks!
Thank you very much that was super informative and easy to digest! The side by side of code and animated git log were very helpful.
This helped immensely. Your visualizations were perfect. Thank you.