Git MERGE vs REBASE: The Definitive Guide

The better way to learn Git with live coding and motion graphics:

----

This is the definitive tutorial for git rebase and git merge. We'll cover everything you'll need to know about how to use rebase and merge to streamline your version control workflow. Start by understanding the fundamentals of git merge: we'll cover 3-way merges, fast-forward merges and more. Then we'll then cover best practices for using git rebase in collaborative situations with other developers, and review common rebase pitfalls to avoid. We'll also explore some pro git rebase and merge workflow tips to help you master the most common git workflow.

CHAPTERS
0:00 Intro
0:18 Merging: 3-way merge
3:00 Merging: Fast-forward merge
4:47 Rebase
6:02 Merge & Rebase Workflow
6:41 Rebase Pitfalls

MY TECH

MUSIC
Music from Uppbeat (free for Creators!):
License code: 0Y2YDUPOMXGYYQML

#git #rebase #merge #github #learngit #gitmerge #gitrebase #development #softwareengineering #programming #coding #versioncontrol #developer #technology #tutorial #stepbystepguide #gitrepository #vcs #programmingtips #codersofinstagram #codingcommunity #learnprogramming #softwaredevelopment #codingtutorial #gitexplained

[azolee]

in my almost 15 year of using Git, this is by far the best video on how to use merge and rebase. thank you!

[ozymet]

This combination of a simple description of the processes with a clear, simple visualization is gold. Many professional coaches should learn from this. I haven't seen such a good way to explain processes that can be easily overcomplicated for a long time. I bow to such skills.

[ItsJustNeto]

This video must be the new standard, at least for any git-related educational content moving forward. Great job!

[davidgood]

As a single dev, I only ever use rebase amd NEVER merge just to keep the history strictly linear, however this is a luxury that larger teams might not have . The tip about only using rebase for your own local work is 100% the right way to use it, imo .

[johndibling]

Great video. I've been using Git forever, and this is probably the best explanation I've ever seen of merge, rebase and fast-forward.

[celikvolkan]

Best explanation I have ever seen on YouTube about merge vs rebase. Thank you for sharing.😺

[nanonkay]

I'd like to think of both as merging, but done differently. Here's how:

"Git merge" from a current branch into the target branch is when Git takes the latest changes of the current branch, then take the latest changes of the target branch and combine them. The new combination is made into a new commit and placed as the latest commit of the target branch. Git will still keep around the history of all the commits that had been made up until the merge of either branch.

"Git Rebase" from current branch into target branch is when Git first takes all the commits from the current branch, lines them up in the order they were made and puts them aside for now. Then Git takes the oldest commit from current branch and "merges" it with the latest commit on the target branch by doing it like a regular merge: combing the changes, make a new commit that represents those combined changes then places that new commit as the latest commit on the target branch. Then Git moves on the second oldest commit on the current branch and repeats the process. All the way until the latest commit of the current branch is merged. But remember, the current branch is still set aside, what will Git do with those commits that have effectively become duplicates? Git will just delete those commits, hence why history has been rewritten.

Hope this helps

[Wakeupdeep]

This was the best explanation I mean the best about the topic (personally) the animation and the simple description of the topic top notch.

[mariocalderon]

Thanks a lot!
At last after several years using Git, I (think) I finally grasped it.

[iddy]

thank you! clear and easy to understand! I am a fan of rebasing, and this video highlighted some of the value in the the other side. my contribution would be to suggest (if you want to maintain a linear history) that if there are multiple people working on a side branch you should be creating your own local branch from that and rebasing only the local branch on any changes pushed to a shared side branch. that way you can fetch and create review additions to it and continue to with your branch locally. and squashing + incremental commits is your friend!

[rpf]

Probably the best videos about git, out there. The animations are a huge help. Thank you so much!

[angelmacias]

This was great. My current job, devs keep telling me to rebase and I ask myself "why not merge". This explains it lol. Thx!!

[yashpandey]

Hey man, amazing video with great illustrative animations out there.

There's just one thing which I found confusing. So in most of the scenarios that I have worked in, the git workflow looks something like this:

1) Create a feature_branch from main: `git checkout -b feature_branch`.

2) Makes changes to your feature branch: `git add -A && git commit -m "Your commit message"`.

3) During the development process some changes were pushed and merged to the REMOTE main branch. So you need to sync your LOCAL main with the REMOTE main:
`git checkout main && git pull origin main`
Once that's done...

4) You checkout your feature_branch and merge the updated local main with your feature_branch: `git checkout feature_branch && git merge main`

5) You push your local feature_branch to remote and create a pull request: `git push origin feature_branch`

In this workflow we can probably replace the merge thing in step 4 with a rebase thing, if this feature branch is being worked on by a single contributor.

What confuses me in the video is that at 5:40 : when we are on the feature branch we run `git rebase main` and then we checkout to main and run `git merge feature_branch`.
Maybe that's done to illustrate fast forwarding merge here but in a production workflow isn't it discouraged to merge directly onto the main branch?

Let me know if I missed a point or something.

[ogreeni]

Great video! You seriously deserve more recognition.

[robwalker]

I quite like a semi linear approach. If I have a release/feature branch that multiple people are working on, rebase to keep in linear. Then when then when you want to merge to master, do a rebase and then merge with no fast forward. This way if you use gitversion, your main branch only has one commit per release but you have full history of commits for each release without a bird nest.

[ariyaneghbal]

Your videos are the most clear I ever seen on this topic and still contains enough details

[MobiusCoin]

Okay, now that I actually know what Rebase is, number one, the name makes a lot of sense. You're "rebasing" where your branch starts. But two, this doesn't seem to be an accurate history of work anymore. We're pretending that I started my work after whoever got their changes into main, somehow that feels wrong.

[erdemkosk]

This is the best git videos on youtube. This is amazing work. I am begging to you please move whole git with kind of videos

[tambuidev]

Great video and explanation! I honestly can't think of a scenario where I'd want to rebase, versus just using merge. The risk outweighs the benefit, and honestly the overhead of a merge process on your local repository is moot. Just my two cents.

[tarsala]

I always squash and never allow teammates to work on my branch. This way you maintain main branch clean with only feature commits and avoid conflicts with teammate locally. The only use case I had was when I was introducing a big feature >100 files and split my PR into 6, then I was rebasing branches in order of building block of the feature, where last branch was rebased into main feature branch after reviews of my peers.