This article was originally published at: https://www.blog.duomly.com/git-rebase-tutorial-and-comparison-with-git-merge/

Intro

There are many ways of working with git, if they're clean, and don't do damages, probably most of them are good. 
But same as space vs. tab, in the IT world is a war between fans of git rebase, and fans of git merge. 

There are tons of arguments about:

-Which way is better?
-Which one is cleaner?
-Which is more comfortable?
-Which one gives a cleaner git graph? 
-Why it's important, and which one is more dangerous?
 
In this article, I will explain to you a few differences between git merge, git rebase, and the git interactive rebase.
I will tell a bit about what pros and cons (there are no better or worse options, mostly in IT, there are just preferences).
I'll try to answer for a few the most frequently asked questions about them as well.
 
Let's go!
 
If you prefer video, here is the youtube version.

 

Git rebase:

How does git rebase work

When we develop features, we usually create the feature branch from our main branch.
We use git rebase when we want to take all commits from our feature branch, and move them into the main branch.
 
This type of git rebase will not give us so much possibility to manipulate on each commit, and will take all of them and move into the destination.
 
To have much better control over all of the commits is worth to take a look into the git interactive rebase, that will give us much more customization possibilities.
 

How do you develop a rebase

Starting the git rebase is very simple, and we just need one line of the code inside our terminal.
 
We can develop a rebase by typing:

git checkout feature-branch
git rebase your-main-branch(for example master or develop)

How do I fix rebase conflicts

I would like to show you two ways of solving conflicts with rebase.
 
Solve git conflict:
You can solve conflicts manually, add files by:

git add

and type:

git rebase --continue

 
Skip commit:
You can skip the commit by typing:

git rebase --skip

Is git rebase safe

If we know what we do, yes, git rebase is safe.
Anyway, we need to care.
Because even if we do not make big damages, kicked rebase can put us into a time-consuming journey about fixing the issue.
 

Why git rebase is dangerous

Git rebase can be a bit dangerous when we do it without care.
Especially in the time-pressure project.
There is needed to use force push, and it rewrites some history. 
Of course, there is a possibility to undo kicked rebase. Still, it takes a bit more time than, for example, just reverting commits.
 

Git rebase pros

-Clean git graph
-Easier access to one, a single commit
-Cleaner main branch
 

Git rebase cons

-When rebase remote you need to use force push
-Can be dangerous because it rewrites the history
-Not very easy for the beginners
-With normal rebase we have not so many possibilities to manipulate commits
 

Git interactive rebase:

How does git interactive rebase work

Git interactive rebase works very similarly to the normal rebase.
It gives us a visible editor that can help us to manage each commit easily, so we don't are blind with commits that we move.
It's especially helpful with big branches, big repositories, and not very clean git history.
 

Git interactive rebase example

To do git interactive rebase, we need to follow similar steps as we did with a normal one, type in your terminal:

git checkout feature-branch
git rebase -i your-main-branch(for example master or develop) 

 
Next, you will see a list of commits that you will be able to select one of the methods for each of them:

-pick, you will keep and push commit to the main
-reword, you will change the message of the commit
-edit, that means you will be able to edit the commit
-squash, commits with that method will be squashed into one
-fixup, similar to squash, but you will delete log of the commit
-drop, it will remove a commit

Git interactive rebase pros

-Same as normal rebase
-The nice editor that gives us the possibility to easier manipulate of every commit
-We can quickly clean the mess in our repo's history
 

Git interactive rebase cons

-Similar as normal rebase
 

Git merge

How does git merge work

Git merge is a method that takes all content of our current branch and will put that inside our target branch.
 
For example, we can merge our feature branch into our master branch.
 
In this case, git will create a new merge commit and will take all of the content(history, code, commits) from the feature branch and will put all of that into our master branch.
 

What is the difference between merge and rebase

The main difference between merge and rebase is the fact that rebase creates a very clean and friendly git graph, and the merge can generate something like graph-spaghetti.
 

How to do git merge

We can do it in three ways:
 
The first method is a combination of fetch and merge.
Mostly used to merge main-branch inside your branch to solve conflicts local before creating merge requests in your apps like GitHub or BitBucket.

The pull one:

git checkout feature-branch
git pull origin your-main-branch(for example master or develop)

The merge:

git checkout feature-branch
git merge your-main-branch(for example master or develop)

Should I rebase before merge

You can do rebase to squash your commits, and clean your gitflow a bit.
Next, you could do the merge and have a clean graph.
 

Git merge pros

-A high-speed method of joining branches
-Easy for everybody
-Very easy reverting when kicked


Git merge cons

-Not clean logs
-Git graph and history aren't very clean
-Debugging using git methods like bisect can be more difficult
 

Conclusion

Congratulations, now you are the git rebase master!
 
I will not tell you which one is better because every project is different. Some are big, and for years, some of them are under time-pressure, some companies take care of quality a lot, and some don't at all.

Anyway, now, you should be able how to recognize which one is better for your type of project, what are pros, cons, and dangers.
 
I hope I've explained to you the main points between these three main methods of updating branches, and you will not have problems to use them in the future.
 
If you still have questions or would you like to make me create some article for the topic that interests you, feel free to leave a comment!
 

 
Thanks for reading,
Radek from Duomly