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.
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.
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
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 RU-vid 👍
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 RU-vid. 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.
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?
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 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
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!
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
Glad to hear that. Check out my other recent git videos and let me know what you think: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-q53umU5vMkk.html. I'm trying to ramp back up
5 лет назад
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.
'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!
UPDATED REBASE VIDEO: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zOnwgxiC0OA.htmlsi=eSYbRNIooTNCb5g- MORE GIT VIDEOS: ru-vid.com/group/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM
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`
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”
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.
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 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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zOnwgxiC0OA.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.
@@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
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
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
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.
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.
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
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!
I watched 4-5 RU-vid 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!
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.
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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zOnwgxiC0OA.htmlsi=eSYbRNIooTNCb5g-. Appreciate you watching!
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.
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.
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.
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.
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.
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.
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
Thanks! Glad it helped. I have an updated video too if you’re interested: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zOnwgxiC0OA.htmlsi=2KqQ_3HSpixVH3jD
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.
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)
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.
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/
