Git MERGE vs REBASE: Everything You Need to Know

Animation tools: Adobe Illustrator and After Effects.

Checkout our bestselling System Design Interview books:

ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

[Haitaish]

2 minutes into the video and animations help understand rebase 1000x better than any static explanation on any website ever could.
Thank you.

[mhopado]

My workflow
1. Create a feature branch.
2. Keep pulling and rebasing the changes from the main branch cmd : git pull -- rebase
3. Once done with my features, squash all commit to one
4. Merge the features branch into main

[AlbertLeng]

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!

[sperrfeuer]

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. 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.

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 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).

[Dmittry]

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.

[tushar]

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.

[Furki_]

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 ❤

[hello_world_zz]

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.

[jmwild]

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 I like rebase conceptually better, I might start getting into the habit of using rebase in the future.

[esra_erimez]

These animations really facilitate the meaning of these concept in a clear and concise manner. Thank you.

[julienwickramatunga]

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 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!

[cerio]

Wow. I've watched some of your videos and they are MASTERPIECES. You put a lot of work into these videos and it's great! Keep up the great work!

[MrZiyak]

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 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

[DanelonNicolas]

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❤

[alexeibrinza]

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 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.

[Clem.E]

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.

[emekaokezie]

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.

[enistoteles]

Sir, your videos are just perfect. Keep the good work up, cant have enough of it.

[aaraz]

This guy graphics is always the best to understand and remember, thanks man !!