Day 10 : Git Rebase #90DaysofDevOps

Git rebase can integrate the changes from one branch to another by overcoming the problems that we might have faced while using the git merge command. The changes we will do will be recorded in the form of logs which are useful to go through if any mistakes happen.

What is Branching?

Branching means splitting from the master branch so that you can work separately without affecting the main code and other developers. On creating a Git repository, by default, we are assigned the master branch. As we start making commits, this master branch keeps updating and points to the last commit made to the repository. Branching in Git can show in the image below.

?

What is Git Rebase?

Rebasing in Git is a process of integrating a series of commits on top of another base tip. It takes all the commits of a branch and appends them to the commits of a new branch. Git rebasing looks as follows:?

?

?The technical syntax of rebase command is:

git rebase [-i | --interactive] [ options ] [--exec cmd] [--onto newbase | --keep-base] [upstream [branch]]        

Uses of Git Rebase?

The main aim of rebasing is to maintain a progressively straight and cleaner project history. Rebasing gives rise to a perfectly linear project history that can follow the end commit of the feature all the way to the beginning of the project without even forking. This makes it easier to navigate your project.

You can integrate the feature branch into the main branch in two ways. the first one is by merging directly into a main branch or first rebasing and then merging. The below diagram shows If you rebase the feature branch first it will facilitate a fast-forward merge. Integrating upstream updates into your local repository is frequently done by rebasing. Git merge causes an unnecessary merging to commit each time you want to see how the project has advanced when you pull in upstream modifications.

?

Some common use cases for git rebase include:

1. Keeping a clean and linear commit history: Git rebasing is mainly used for maintaining a linear history of commits, where commits are interrelated to the co-existing one. it makes it easy to understand code.
2. Updating a feature branch: By rebasing the feature branch will help us to maintain updates because it is generated from the main branch. The main branch will always be up to date.
3. Rebasing the feature branch can bring it up to date with the most recent changes in the main branch if it was generated from a main branch (such as master) and the main branch has since been updated with new commits.
4. Resolving merge conflicts: Git rebase will help us to resolve merge conflicts . It enables conflicts to be settled at each stage, leading to a cleaner merge, by applying each commit from the branch being rebased separately.

Git Standard vs Git Interactive Rebase

Git rebase is in interactive mode when the rebase command accepts an — I argument. This stands for Interactive. Without any arguments, the command runs in Standard mode. In order to achieve standard rebasing, we follow the following command:

git rebase master branch_x        

where branch_x is the branch we want to rebase

The above command is equivalent to the following command and will automatically take the commits in your current working branch and apply them to the head of the branch which will be mentioned:

git rebase master        

Whereas, in Interactive rebasing, you can alter individual commits as they are moved to the new branch. It offers you complete control over the branch’s commit history. In order to achieve interactive rebasing, we follow the following command:

git checkout branch_x
git rebase -i master        

This command lists all the commits which are about to be moved and asks for rebasing all commits individually and then rebasing them according to the choices you entered. This gives you complete control over what your project history looks like.

Git Rebase Commands

The following are the most used Git rebase commands:

1. git rebase master: The command “git rebase master” can be used to make all modifications found in your master branch part of your current branch.
2. git rebase –continue: When we are rebasing the branches we will face some conflicts and issues then we need to resolve the issue. After resolving the issue we again continue the rebasing processes for that we use “git rebase –continue”.
3. git rebase –abort: “Git rebase –abort” command cancels a rebase that is currently underway and restores the branch to its initial state.
4. git rebase –skip: When rebasing the branches we might face some unresolved conflicts to skip the particular encounters we will use? “git rebase –skip”. Skipping the commit is not good practice it will damage your codebase.
5. git rebase -I HEAD~3: With the help of this command, you can interactively rebase the most recent three commits onto the active branch. You can choose which commits to rebase, alter commit messages, and squash or divide commits in the interactive editor that is opened.

Make sure you have a backup of the entire code before executing the git rebase; this will allow you to restore the old code in case something goes wrong.

Configuration Options In Git Rebase

We can customize the behavior of the rebase according to our requirements. Here are some commonly used configuration options:

1. -I or –interactive: By using –interactive we can perform rebase interactively where we can edit or commits. By choosing this option, a text editor will open where you can choose which commits to rebase. You can even alter commit messages or combine several commits into a single commit.
2. –onto <newbase>: Using this option, a new base commit is specified for the rebase procedure. You can use it to rebase several commits onto a different branch or commit.
3. –skip: If a dispute arises while doing the rebase operation, this option skips a commit. It is employed to instruct Git to forgo a commit and carry out the rebase.
4. –no-verify: Any pre-commit hooks that have been set up in the repository are disregarded by this option. If you need to fast commit without starting any pre-commit checks, this can be helpful.
5. –auto squash: The “fixup” or “squash” flags on any commits are immediately applied when this option is selected. When using interactive rebase to clear up a commit history, this can be helpful.

Git rebases configuration options should be used carefully because they can significantly affect the repository’s commit history. Prior to sending changes to the repository, make sure to evaluate and thoroughly test all rebase-related modifications.

Git Rebase vs Merge

Both merge and rebase are used to merge branches but the difference lies in the commit history after you integrate one branch into another. In Git merging, commits from all the developers who made commits will be there in the git log. This is really good for beginners cause the head can be rolled back to commit from any of the developers. Whereas, in git rebases, a commit from only a single developer will be stamped in the git log. Advanced developers prefer this cause it makes the commit history linear and clean. The command for merging is given as:

git merge branch_x master        

This creates a new commit in the merged branch that ties together the histories of both branches, giving you a branch structure that looks like this as opposed to rebasing what we saw above:?

?

Note: After performing rebasing, we are by default on the last commit of the rebased branch.

Git Rebase Abort

Once you did the rebase of the branch and you want to undo the changes and revert back to the previous changes it is possible by using the “git reset” command. It will undo the git raise command and roll back to the Periovus version?

git reset --hard <branch-name>        

“– hard” is like a hard option and we use “branch name”. By doing the above two steps you can undo the changes. ?

Steps to Recover Lost Changes Process of Upstream Rebase

By following the below steps you can recover the changes you lost in the process of ?Upstream Rebase.

Step 1: First, go through the local repository for missing commits reflog. The reflog keeps track of all repository modifications, such as branch updates, merges, and rebase. Run the git reflog command to see the reflog. Find the commit IDs for the lost changes you made and copy the most recent one.

Step 2: Create a new branch by using the commit Id you recovered which is lost by using the below command.

git branch <new branch name> <commit id>        

Step 3: After creating the new branch by using cherry-pick command you can recover the changes that were lost in the upstream rebase. For this use the below command.

cherry pick <commit id>         

Step 4: While using the cherry-pick command you may face lots of conflicts and problems that need to be resolved. After resolving the conflicts use the below command and stage the files.

git add <file>         

Step 5: The last and final step after completion of all the above steps by resolving all the errors, know to push the branch that has been created newly to the remote repository by using the below command.

 git push -u origin <new branch name>.        

After completion of all the above steps, we can check our remote repository like (GitHub) whether the new branch is pushed with all the lost changes or not.

Git Pull Rebase

The “git pull –rebase” command helps us to perform fetching and rebasing on top of those changes. Git pull will fetch the files from the remote repository and merges them with the branch we want to merge.

But, when you use the git pull —rebase command, Git pulls updates from the remote repository and rebases your current branch on top of them, thereby applying your local commits on top of the fresh remote updates. As a result, the commit history becomes linear and is simpler to read and comprehend.

How to Git Pull Rebase in the Command Line?

Step 1: Use the below command to fetch the remote repository.

git fetch <remote>        

Step 2: Know to apply the following command to rebase your local branch on top of new changes.?

git pull --rebase        

if any conflicts are encountered the processes will be paused and you have to resolve the conflicts after that you can use the below command to continue the process.

 git rebase --continue         

Advantages of Git Rebase

Here are some advantages of Git rebase:

1. Cleaner commit history: Git rebase can help you to maintain an organized and cleaner commit history. Because git rebase marges the multiple branches with all the changes which results in a more streamlined and linear commit history.
2. Changes can be understood easily: Git rebase will help us to maintain an organized and cleaner commit history, which makes it very easy to understand the changes in the codebase. Helpful when you are trying to perform debugging or troubleshooting issues.?
3. Repository maintained up-to-date: Rebasing is a method for updating feature branches with the most recent modifications made to the master branch or other development branches. This makes it easier to make sure that code updates are based on the most recent codebase version.
4. Improves collaboration: Rebasing makes it simpler to merge changes from many branches into a single codebase, which enhances team collaboration. If changes are added to the target branch one commit at a time, it can also aid in reducing the number of merge conflicts.

Cashback rebates provide numerous advantages, but it’s vital to remember that you should utilize them responsibly. Rebasing has the potential to change the repository’s commit history, which could be problematic if improperly handled. When conducting a rebase, always consult the team and make sure all changes have been extensively tested before merging them into the source.

Disadvantages of Git Rebase

Here are some disadvantages of Git rebase:

1. Complicated: When compared with merging rebasing is more complicated, and it will be more complicated when dealing with complex commit histories. Each and every detail must require attention and time will be consumed more when compared to the merging.
2. Lost of commits: Git rebase overwrites a branch’s commit history, therefore any commits that are not included in the rebase may be lost. This could occur if the incorrect branch is rebased or if conflicts are not properly resolved.
3. Problems with public repositories: Rebasing can be problematic for public repositories because it changes a branch’s commit history. Other developers may find it challenging to work together on the same codebase as a result, particularly if they are unfamiliar with the rebased commit history.
4. Breakdown of stream branches: Because the commit history has been changed, rebasing may break downstream branches that are based on the original branch. Changes from the downstream branch may be more challenging to integrate as a result of merge conflicts.

Before making any significant changes to the commit history of a branch, it is crucial to thoroughly weigh the risks and benefits of utilizing Git rebase and to consult with other team members. Rebasing is a potent tool for optimizing the codebase and managing commits, but it must be handled with prudence and knowledge of all its ramifications.

Frequently Asked Questions

1. What is rebase vs merge in git?

Answer:?

To merge two different branchs you can use git merge and to integrate the changes of one branch to other branch we use git rebase.

2. What is the difference between git cherry-pick and rebase?

Answer:?

Cherry-pick will applies changes from a given commit to the current branch. integrate the changes of one branch to other branch we use git rebase.