Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: https://bytebytego.ck.page/subscribe
Animation tools: Adobe Illustrator and After Effects.
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
The digital version of System Design Interview books: https://bit.ly/3mlDSk9
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.
Category
Show more
Comments - 227
@
@Haitaishقبل 8 أشهر2 minutes into the video and animations help understand rebase 1000x better than any static explanation on any website ever could. Thank you. 488
@
@AlbertLengقبل 8 أشهرOne of the best channels to learn about sw technologies. No fluff talks, no distracting music, no ads, pure substance with straight to the point explanations and amazing animation! 59
@
@sperrfeuer4158قبل 6 أشهرThere's a reason merging squash commits is so popular, and that's because it's the easiest and most compatible with how most people use git. id="hidden2" class="buttons"> Most people want their branch to be their own workspace, and while in some kind of fantasy world each commit would be filled with very useful information, in reality it's mostly swear words and short notes. Having squash commits and PRs can force developers to write a longer, better description of their entire feature when merging instead, and get rid of all the mostly scattered and hard to understand commits from the feature branch. The only people I've ever met that prefer rebasing are people who live and breathe git and feel like every commit is sacred, but this is an incredibly tedious way to work -- if your features are so large that you feel that the history of a hundred commits is necessary, just make smaller features, or better yet, actually comment your code like you're supposed to. ....وسعت93
@
@AlexandruPatranescuقبل 8 أشهرTried various strategies and so far I prefer to always work with merge commits and almost no rebase (unless the branch was never published). Merge id="hidden3" class="buttons"> from main branch to feature branch. Merge from feature branches to master when ready, no squash, no fast forward, always creating a merge commit. I don't find the history messy as it's exactly as development happened. Remember that you can always see history with --first-parent if you want to see only a commit (similar with how squash result can be viewed). ....وسعت38
@
@hello_world_zzقبل 8 أشهرAlex, you truly are the epitome of excellence. With my 15 YOU as a SWE, I can confidently say that collaborating with someone of your calibre has undoubtedly been the utmost highlight in my professional journey. 7
@
@Furki4_4قبل 8 أشهرI've never used rebase and squash techniques but i like the way they combine the commits in the feature branches to the main branch. Thank you ❤ 4
@
@Dmittryقبل 8 أشهرWe squash our personal PRs and merge our team branch to main. To update my branches I prefer rebase . But rebase is not so good if several people work on the same branch. 90
@
@tushar8133قبل 8 أشهرBelieve me, you always make us clear long due complex topics in a single shot. I have been trying to figure out this topic for the past few years, but never understood. Thanks a lot! We ❤ your channel. 1
@
@eleet321قبل 4 أشهرAbsolutely love the visual way that you taught this, it's crystal clear. Thank you!
@
@jmwild1قبل 8 أشهرThis is a great visual summary of each. I was always skeptical of using rebase and always merged with local commits before pushing my changes. But I think id="hidden7" class="buttons"> I like rebase conceptually better, I might start getting into the habit of using rebase in the future. ....وسعت10
@
@MrZiyak99قبل 8 أشهرI used to rebase the main branch into my feature branch. the issue with that which not many talk about is that if you're too many commits behind you'll id="hidden8" class="buttons"> be forced to fix merge conflicts on a commit by commit basis. i usually prefer merging now and then user interactive rebase to pick commits in my feature branch before pushing to main ....وسعت6
@
@esra_erimezقبل 8 أشهرThese animations really facilitate the meaning of these concept in a clear and concise manner. Thank you.
@
@sjadevقبل 5 أشهرBy far the best explanation I've seen on this topic
@
@sameershah141قبل 8 أشهرThe animation visualisation is great!!! 2
@
@mhopadoقبل 8 أشهرMy workflow 1. Create a feature branch. 2. Keep pulling and rebasing the changes from the main branch cmd : git pull -- rebase 3. id="hidden9" class="buttons"> Once done with my features, squash all commit to one 4. Merge the features branch into main ....وسعت3
@
@enistotelesقبل 8 أشهرSir, your videos are just perfect. Keep the good work up, cant have enough of it. 1
@
@DanelonNicolasقبل 8 أشهرI love to update my branches and the merge them to master using squash haha. I love this channel. my new favourite of this year haha❤ 1
@
@aaraz101قبل 6 أشهرThis guy graphics is always the best to understand and remember , thanks man !!
@
@alexeibrinza2719قبل 8 أشهرI prefer the hybrid approach. First create a new feature branch from main branch. Add a few commits on feature branch. If the commits all belong to the id="hidden10" class="buttons"> same task or represent the same feature, fixup/squash them. If each commit represents distinct functionality or it makes sense to revert a part of the feature, not the whole feature, then don't use fixup/squash. After the work is done - rebase the branch with the main. Using this technique, you can combine both squash/rebase as needed. ....وسعت6
@
@saravanansomu8296قبل 8 أشهرThis is amazingly simple and precise explanation. Thank you Sahn Lam.
@
@Sranju23قبل 8 أشهرThank you, for covering the topic that always gives me little anxiety while executing those commands 1
@
@michaelvilain8457قبل 3 أشهرThanks for this. It explained the details of these three features exquisitely.
@
@swedishpsychopath8795قبل 6 أشهرThis guys explanation wasn't too bad, I guess. Thank you! 2
@
@nampt991قبل 8 أشهرI love your channel sooooo much . Thanks a lot with my all grateful. Your video untied the huge knot in my brain . thanks again! I will always be your big fan!
@
@teeesenقبل 5 أشهرWhat a great video! Here is why I ask my team to avoid rebases and squashes. Sometimes I look back at the history for dead ends, i.e. commits with no descendants. id="hidden12" class="buttons"> Without rebases and squashes these generally fit one of three categories. (A) Work that later turned out not be needed, (B) work that is on-going and hasn’t yet gone into a merge request, and (C) work that should have gone into a merge-request, but didn’t. Hopefully the first category is rare. Rebase and squash create new commits and the older versions of those commits are left in the repository without descendents. That creates another category of commits without descendants: (D) useful work that was replicated elsewhere. It’s often hard to distinguish (D) from (B) and (C). Far from having a clean history, you have a messy history with a lot of dead ends and commits that replicate work on other commits. Well that’s how I see it, but I’m interested in reading the comments to see why others like rebasing and squashing. ....وسعت
@
@julienwickramatunga7338قبل 8 أشهرVery nice video, short and insightful! Thank you for reminding us that as anything in IT (and in life really), choosing a Git strategy is about id="hidden13" class="buttons"> pros and cons, and is specific to a given context. No strategy is better than another, there just tools for teams to use, to get the job done. Have a nice day! ....وسعت
@
@Clem.Eقبل 8 أشهرWith Git rebase, I find myself rebasing more often on the main branch in order to prevent the branch from diverging to much. It has the benefit of avoiding too many conflicts on the final rebase. 2
@
@emekaokezie4251قبل 8 أشهرUpdating my main branch, I prefer working with GIT MERGE. It feels a lot more straightforward for me more importantly is the fact that I can track my commit history when I make use of the MERGE option. 5
@FloBee10قبل 5 أشهرi've used merge only. Glad to learn about rebase!
@
@srm3378قبل 5 أشهرThank you so much!!! Subscribing faster than I ever have for any channel
@
@premkatta1128قبل 3 أشهرclear and straight to the point explanation and animations made concept very much easier to understand.. Thanks ! and subscribed !!!!!!
@
@zillboyقبل 3 أشهرI have used "git merge & squash" rebase sounds good. I'm gonna learn and do that. Thanks for explanation.
@
@truchuynh211قبل 8 أشهرVery details! Thanks so much for helping the community understand more. I usually use Squash Commit to add the featured branch to the main after testing the new component on the featured brand.
@
@ortervesقبل 8 أشهرRebase and merge ("semi-linear merge" - not fast forward!) is superior for cleaner change information. I call it the "knotted-rope". id="hidden17" class="buttons"> After rebasing but before merging, I frequently reset soft and selectively commit the files in sets with messages that best describe what was done, in way that ensures each commit builds on the last. Sometimes it's necessary to commit partial file changes or even adjust the changes directly to better express a 'sub-commit'. You can always compare the resulting refactoring with the original rebased branch head commit to confirm the sum total is the same, so there's no risk of losing changes with this approach. What you end up with is clean, readable sets of delineated commits that are useful for future investigation into the history of changes - while still allowing the development process to be continuously committing to a branch without too much concern for the messages or presentation of the commits. It's a nice have your cake and eat it too approach ....وسعت1
@
@vamsibalaga7057قبل 8 أشهرgreat pictorial explanation.. Kudos to the Idea. Thank you
@
@user-ch8sh7ki5dقبل 8 أشهرDude you rules, I like all your videos! Thank you for your input )
@
@gusromul3356قبل 6 أشهرgood job bbg! nice and simple explanation.. ill certainly check your other work
@
@ashwin_mahajanقبل 8 أشهرLove your content, cool graphics to help understand.
@
@robertjif6337قبل 8 أشهرI can finally understand what rebase really does thanks man
@
@MrGreg557قبل 8 أشهرGreat video. It's also good to note that git rebase is a form of rewriting history. This means that it should be used much more carefully when you id="hidden18" class="buttons"> work with other people on the same feature branch. Anyway, I personally used git merge + rebase with squash on main most often in many organizations.. ....وسعت1
@
@the_alien293قبل 4 أشهرwe need complete git playlist like this
@
@VincentJenksقبل 6 أشهرAh, The Great Debate. I’ve hunkered around many a whiteboard and heard endless iterations of passionate arguments for all approaches. Regardless of what you personally prefer, it all comes down to the project, your team, and what works for everyone. There’s no hard and fast rule and all approaches have their merit. ....وسعت
@
@joecox9958قبل 2 أشهرvery nice and clear, voice also very clear, thanks!
@
@funkynerd_comقبل 8 أشهرI'm probably doing it wrong, but there's two projects I work on and do it differently on each. One project is with a small team of 3 developers id="hidden20" class="buttons"> and we only merge. Commit history is not "messy" due to the size of the team and feature concurrency, but we get tonnes of detail which is helpful when tracking down regressions. My other project though, I use squash commits. Gitlab does a good job of building commit messages out of the feature commit history so I don't really lose anything. Main history is cleaner, etc. ....وسعت1
@
@amandasimonds9قبل 6 أشهرthank you. i learned something new today
@
@kingsleyzuze9949قبل 8 أشهرI basically just use git merge, but I think I'll try git squash more as I sometimes have multiple branches feeding into main - thank you for this one. 1
@GrzesiuG44قبل 8 أشهرFor me rebasing works great in open source like enviornment, where Focus and review is on the changes contributed. In enviornment where many people work id="hidden22" class="buttons"> full time on a code base, the process is also part of what you need to track, so simple merges are both better and can avoid wrongly resolved conflicts - and you should build your linear history using different tool (like PR history). ....وسعت
@
@zahidshabbir1385قبل 8 أشهرThis YouTube tutorial excellently clarifies the Git dilemma between merge and rebase, offering concise insights for confident version control choices. id="hidden23" class="buttons"> A must-watch for mastering efficient collaboration and branch management. Can you please share name of video editing software you're using. thanks ....وسعت
@
@nayan.jقبل 8 أشهرAll these fuss about rebase and a detailed and precise 5min video cleared that up for me. Thanks
@
@stpaquetقبل 8 أشهرsquash is my main go to at the moment. though from time to time I use the merge approach.
@
@pavankumard5276قبل 5 أشهرReally good tutorial wish there was an example to show the git commands for the following
@
@iHariPatelقبل 8 أشهرI been using merge only , now I understood rebase is good idea for clean history 1
@
@RishabKapadiaقبل 6 أشهرthis should be default way to explain GIT. too good.
@
@frederik_hdقبل 7 أشهرwhen there is a merge conflict I usually rebase my feature branch - and after development I create a PR with an clean and clear git history means combining id="hidden24" class="buttons"> commits and checking git messages - and the merge into the main branch I always use squash commit ....وسعت1
@
@filipstojiljkovic4711قبل 7 أشهرExcellent video, however I feel like squash is not in the same category as rebase and merge (which video may confuse people of being so), its more of a id="hidden25" class="buttons"> strategy of how we merge our final changes to the main branch, and not how we keep track of main branch with our feature branch. I think if solo using feature branch, rebase is the best way to go, after which you merge PR with squashed commits. ....وسعت
@
@ericcartmanshقبل 8 أشهرThis is such a cool, useful and beautiful video
@
@minlaxzقبل 8 أشهرI used both, MERGE and REBASE. Sometimes, it's better to leave a history (merge commit), since it's easier to be tracked. But sometimes, id="hidden26" class="buttons"> I used 'rebase', where I don't need to track anything. ....وسعت
@
@Primalmoonقبل 8 أشهرWorking in a large monorepo, rebasing and squashing is essentially required. without it the branch history quickly becomes a tangled mess, as you end id="hidden27" class="buttons"> up with many more merge commits than actual code commits, and then the rest of the commits are a few thousand commits from one developer that was following the TDD practice of making a new commit every time the tests were passing. As long as you can convince people to squash the history can remain readable. And rebasing helps keep the amount of catastrophic merge conflicts to a minimum by not squashing in the same commits that someone else is merging, which will be happening all the time in an active repo. ....وسعت1
@
@adarshchacko6137قبل 5 أشهر sums it up and it does come in handy. Thank you @ByteByeGo
@
@francescoleto2823قبل 8 أشهرSquash feature branch is my preferred option, it guarantees a cleaner history
@
@amboojmittal2993قبل 8 أشهرNice video. Git rebase seems good option. I use git merge a lot.
@
@jorden123قبل 8 أشهرRebase whenever you want to get your feature branch in sync with main, when done implementing - squash, tag and merge into main.
@
@stephenreaves3205قبل 8 أشهرfeature branches are rebased from main at least daily, generally only squash commits if there's like 10+ commits per feature branch, then merge onto main
@
@Oda3908قبل 8 أشهرmain -> feature = rebase feature -> main = squash + merge rebase would be painful if the feature branch existed too long, you need id="hidden29" class="buttons"> to resolve conflicts from the oldest commit to the latest one(standard mode), squashing commits in the feature branch can improve the rebase experience, personally a better solution is to make a smaller task and PR. ....وسعت7
@
@BhaveshAgarwalقبل 8 أشهرByteByteGo - please share the tools and softwares you use to create these wonderful videos. It will be extremely helpful to learn them and use it for work and share knowledge in general. Thanks in advance!
@
@mestlabs9922قبل 7 أشهرI really love your videos. I have subscribed to bytebytego and continue to learn from the content you share. I have one question about your video animation. id="hidden31" class="buttons"> What do you use to animate the system design animations in this video explanation of Kafka. I have a presentation and I would love to do something like that for my presentation. Thank you. ....وسعت
@
@joecox9958قبل 2 أشهرhope you get one for git graph with clear statement for a simple git process flow: pull, checkout, merge, push, and associated with the graph change.
@
@shubhamgawali8030قبل 2 أشهرwhile developing a changes on local I prefer git rebase and after creating a PR I merge the feature branch to master
@
@RajinderYadavقبل 3 أشهرI've always have rebase mess up, and then trying to back out is a major pain. I understand how it works, but I somehow always have it blow up in my id="hidden32" class="buttons"> face. So I just opt out for merge, it just works and is zero mental load to get going with development. ....وسعت
@
@thatGeorgeRقبل 8 أشهرIt would be good to touch problems that git rebase may lead to. Not every one aware about a pitfalls that you may face using git rebase unthoughtful. Good video by the way.
@
@aishasuleman2882قبل 8 أشهرNice video What software do you use to create the animated presentation?
@
@seekinginfoقبل 8 أشهرWhich tool is used to make these nice visualizations and diagrams. Would appreciate the input
@
@reza_majidiقبل 8 أشهرI personally use rebase before merging my feature branch to staging. In this way every merge conflicts will be resolved in my branch before merge. I also occasionally rebase to staging to get the latest changes. 1
@
@withpratapقبل 8 أشهرHow to create such visuals? Any tools you used can you recommend any?
@
@zshnقبل 8 أشهرGit rebase is a nightmare in a large team working on same files. Developers spent time resolving conflict on their local and then in production. Without id="hidden35" class="buttons"> context, fully backed unit tests and collaboration it can easily create a mess. 1 dev renaming a function while the 2 other devs changing the contents of the function. Now multiply that. Git merge is my preferred approach. We have a main branch, develop branch and feature branches. We git merge from feature to develop on a daily basis and git rebase and squash commit from develop to main on a release basis. ....وسعت
@
@MichaelScharfقبل 8 أشهرI use rebase to squash 20-50 small commits on my feature branch into a few meaningful ones before merging. I typically commit up to 10 times an hour. 1
@
@harinathxxxقبل 8 أشهرI have used git Merge which will be easy to maintain and add to bug fix
@
@thomasluk4319قبل 8 أشهرi would want to know more abnoout squash, for the git command, should I use rebase -i ?
@
@balsu79قبل 6 أشهرWhat tool you use for the animations - it's cool
Related videos for Git MERGE vs REBASE: Everything You Need to Know:
Thank you. 488
Merge id="hidden3" class="buttons"> from main branch to feature branch.
Merge from feature branches to master when ready, no squash, no fast forward, always creating a merge commit.
I don't find the history messy as it's exactly as development happened.
Remember that you can always see history with --first-parent if you want to see only a commit (similar with how squash result can be viewed). ....وسعت 38
1. Create a feature branch.
2. Keep pulling and rebasing the changes from the main branch cmd : git pull -- rebase
3. id="hidden9" class="buttons"> Once done with my features, squash all commit to one
4. Merge the features branch into main ....وسعت 3
Thank you for reminding us that as anything in IT (and in life really), choosing a Git strategy is about id="hidden13" class="buttons"> pros and cons, and is specific to a given context.
No strategy is better than another, there just tools for teams to use, to get the job done.
Have a nice day! ....وسعت
After rebasing but before merging, I frequently reset soft and selectively commit the files in sets with messages that best describe what was done, in way that ensures each commit builds on the last. Sometimes it's necessary to commit partial file changes or even adjust the changes directly to better express a 'sub-commit'.
You can always compare the resulting refactoring with the original rebased branch head commit to confirm the sum total is the same, so there's no risk of losing changes with this approach.
What you end up with is clean, readable sets of delineated commits that are useful for future investigation into the history of changes - while still allowing the development process to be continuously committing to a branch without too much concern for the messages or presentation of the commits. It's a nice have your cake and eat it too approach ....وسعت 1
Thank you
Can you please share name of video editing software you're using. thanks ....وسعت
Sometimes, it's better to leave a history (merge commit), since it's easier to be tracked.
But sometimes, id="hidden26" class="buttons"> I used 'rebase', where I don't need to track anything. ....وسعت
feature -> main = squash + merge
rebase would be painful if the feature branch existed too long, you need id="hidden29" class="buttons"> to resolve conflicts from the oldest commit to the latest one(standard mode), squashing commits in the feature branch can improve the rebase experience, personally a better solution is to make a smaller task and PR. ....وسعت 7
What software do you use to create the animated presentation?