A practical way to git rebase

If you are a software developer, then you must have encountered git rebase or you may have heard this term. Though there is a number of ways/style people use when they work with git, few people use standard/tool to accomplish their task.

git rebase is one of those tasks which can help you to make your life comfortable.

So what is this git rebase, and when you need that. I will explain this through the scenario then it will be crystal clear to you. This is a basic explanation to help you understand the git-rebase.

Note:- If you have any Github or similar accounts then it's better to practice this while reading. For this scenario, I will use my GitHub account and you can find the repository at the below link:

Let's take a brief overview of the basics:

Q) what is git?

git is one of the very powerful distributed version control tools. It helps us to manage the software version, changes, commit, patch, and record who changed what and when.

Q) what is the local repository in git?

git is a distributed version control tool. If you have to make any changes to it, then you must bring that copy to your machine. This local copy is referred to as a local repository. You make your changes to the local machine and then you push it to the remote (central repository).

Q) what is a git snapshot?

A snapshot is the state of the entire git project at a certain moment. This is how git manages the changes. It keeps track of all the files which has changed in the commit.

Q) what is the term state means in the git?

Git has 3 states: Modified, staged, and committed.

git has one primary branch or default branch called master. This is just like any other branch which gets created when you use the git init command to initiate a git project.

Q) what is the git branch?

Technically git branch is a pointer to a snapshot of the changes. Let's say you want to contribute to some project. Instead of directly writing into the main codebase you can create a branch (point your local repository to a snapshot). This way you can make the changed to this snapshot, and later point in time you can club these changes to the main codebase (default/master branch).

So you have understood now that many people can contribute to the code base right?

Before proceeding further you must be comfortable with the below diagram. Though there is a number of ways to visualize these state. I will use the below diagram to explain my thoughts:

git state

A commit is represented by a circle with some explanation( In general we can use commit hash to represent the state, I am using letters to represent the state description). All the commits are interlinked with a line. It means someone has changed the state of the codebase from committing a (snapshot a) to commit b (snapshot b), and then to commit c (snapshot c).

Scenario: You are working on a project called the food delivery app. There are many software developers who are contributing to this project. On one nice day, you got to work on a feature (say featureA). How would you proceed?

Approach: You will first take the latest code base snapshot, and bring it back to your local machine.

How do you bring the latest changes to the local repository?

git pull origin master (This will bring the latest master changed to your local)
Now you need to create a branch
git checkout -b featureA

And voila you started working on your code.

After a day or so some of your colleagues have pushed a nice feature to the codebase, and you want to bring it to your repository. How would you do that? Hmmm, there are few other options available to bring those changes to your local, and git rebase is one of them.

git rebase means you are now bringing all the snapshot changed present in the code base and you will apply your changes on top of that. This is very easy to visualize through the diagram. Let's consider the below diagram:

Interpretation: You took a snapshot at commit b and made commit b1. After that, there are some changes gone to the code base (master branch). Now the question was, how would you bring the master changes to your branch?

Though there are different ways and based on the use case/scenario people use different ways to tackle this challenge. In the case of git rebase you bring the changes as it appears you took a snapshot from the latest changes once everyone pushed it.

Let's follow these steps to bring those changes to your local repository:

Step 1 ) checkout to the master branch, and pull the latest changes.

git checkout master // This will switch your branch to your local master snapshot.
git pull origin master // update origin master

Step 2 ) Now switch to your feature branch.

git checkout featureA

Step 3 ) Do the git-rebase. Here the base branch is master. Doing rebase here will incorporate base branch commit into your feature branch.

git rebase master (this will rebase on top of master.)

Step 4 ) Git will try to apply the commits from the branch-to-rebase onto the current branch. If there are any conflicts, Git will pause the rebase and inform you which files have conflicts. You need to resolve these conflicts manually by editing the conflicting files.

Step 5 ) Once you resolve the conflicts, stage the changes using the command:

git add <file1> <file2> ...

Replace <file1>, <file2>, etc., with the names of the conflicted files.

Step 6 ) Once you have resolved the conflicts and staged the changes, continue the rebase by running:

git rebase --continue

Step 7 ) Git will attempt to apply the remaining commits. If there are no further conflicts, the rebase will complete successfully. However, if additional conflicts arise, repeat steps 4–6 until all conflicts are resolved.

Step 8 ) After the rebase is complete, you can push the rebased branch to the remote repository using:

git push --force

That's it!!!

Now your snapshot will look as it's taken from the latest master.

If you have any questions or if there’s something specific you’d like to know, please leave a comment and share your thoughts about this article. I’m looking forward to hearing your feedback!