What Is Git Rebase 2026 | Git Rebase Tutorial | Github Rebase Explained | Simplilearn

Key Takeaways

Have you ever faced the challenge of cleaning up your git commit history by fixing conflicts or syncing your changes with the latest updates from the main branch? If so, then you're not alone. Whether you are collaborating on a team project or just managing your own codebase, mastering git rebase operation can save you a lot of headaches. Imagine being able to effortlessly replay your comets on top of another base, resolve merge conflicts like a pro and keep your code base in perfect harmony. Well, that's exactly what we are going to explore in today's session. Now, before we move on, here's the agenda of our today's session. First of all, we are going to start with an introduction to what is git rebase. Then we are going to explore how to use git rebase. Moving ahead, we are going to understand how to handle conflicts during a rebase. Then we are going to explore interactive rebase. After that, we are going to explore rebasing merge commits. And finally, we are going to do hands-on activity. Before we move on, just a quick info guys. Simply learn has got DevOps engineers master program. You can become a DevOps expert with hands-on projects and also explore IBM AWS and Azure's official content. You're going to master all the stages of DevOps life cycle. You can access blended learning via live online classes with free interactive labs. You can also access official learning content from IBM and earn certificates. This course is in collaboration with IBM. So guys, hurry up now and join the course. The course link is mentioned in the description box. Now here's a short quiz to test your knowledge. What does the get rebase command do? And your option are merges two branches into a single comet, reapplies comet from one branch onto another base, deletes all comets from current branch or creates a new branch from the current commit. Please mention your answers in the comment section below. Before we dive into the session, I request you guys that do not forget to hit the subscribe button and click the bell icon so that you don't miss out any update from our end. So let's get started. So guys let us first understand what is get rebase. Get rebase is a powerful tool in g that allows developer to rewrite the comet history. It is used to integrate changes from one branch to another by replaying commits. It can make the project history cleaner and more linear unlike merge which creates new merge commit to integrate changes from one branch into another. Now let us discuss about some of the key features of git rebase. First of all it reapplies commits on the top of another base. That's the core functionality of git rebase. Now this helps us to move or rebase the commits of a branch on top of another branch making history look like it was developed on the top of that branch from the beginning. Next you can also see the linear history. Git actually helps in maintaining linear history through rebase which means that instead of seeing typical branch and merge structure you can use clean and straight line of commits. then you have no merge commit unlike git merge. Git rebase does not create merge commit keeping the project history neat. Then you can also rewrite the git commit history. Get rebase gives you the ability to modify the commit history. You can reorder squash meaning combine or remove commits from a branch history. Now this is a pretty amazing feature to discuss about that is conflict resolution. When conflict occurs during the rebase process, g pauses the rebase allowing you to resolve the conflict manually before continuing. So these were some of the very important features of git rebase. Now before we deep dive into git rebase, let us recap some of the important things about git such that you are comfortable when doing hands-on on git rebase. Now you can see I have opened the official documentation of git. So first let's understand what exactly is git. Git is a version control system. It allows multiple developers to work on same project simultaneously without interfering each other's work. Git tracks changes to your project files and helps you manage version of your project over time. It makes collaborating with other easier by keeping track of who changed what and when. Now let us talk about repository. So you can see all over here I have opened a repository. Now repository is a collection of files tracked by git. It includes all your project history. So you can see all over here it shows three commits. Last commit was 4 days ago. This was last month commit. Then you can see Jenin files got updated 4 days ago. So any commit or any changes to my file which I'm doing is you can see all over here it's reflecting. Now let us talk about branch. So branch is a parallel version of your project. By default, your project start with a branch called master or main. Then you have something called feature branch. So a feature branch is a branch which is created from the main or development branch. Often it is main or master to develop a new feature or functionality independently from rest of the project. It is basically used to isolate changes related to that specific feature or task making it easier to work on without affecting the main project until the feature is complete and ready to be integrated. Now let us talk about what a branch. So a git branch is like a copy of your project where you can make changes without affecting the main project. Typically it's called master or main branch. Now this allows you to work on new feature or bug fixes in isolation. Let me give you one scenario. Imagine you are working on an e-commerce application where the master branch is stable and it holds the core product. Now as a developer you create new branch called feature like add payment gateway to work on adding a payment gateway feature to the app. Now you can see all over here in this given diagram. So we have A B C D as a master branch and from B I have created E and F which are feature branch where basically what I'm trying to do is I'm trying to create a feature which is adding the payment gateway to our app and here you can see E and F are the commits on the feature branch that we have done. Now let us try to understand by the given example. Consider this is your master branch. Okay. So A, B, C and D are the commits on the master branch and A and F are commits on the feature branch that we are discussing like the payment gateway which we are adding to the e-commerce application. Now once the given feature is complete, we can use get rebase to incorporate those changes back into the master branch. So this is kind of a very important concept. Now let us move to the next diagram that we have and here we are going to discuss about get merge. Now there is one more command which is called as get merge. So get merge is a command that combines two branches together. If you're working on a feature branch like feature add payment gateway and you want to bring your changes back to the master branch then you can use git merge. Now this creates a new merge commit that connects the two branches. For example, if you can see in this given diagram, this is a master branch. A, B, C, D are the given commits and E and F are the given commits on the feature branch. Now let's say after merging the feature branch which is add payment gateway to the master a new commit M is created. So from all over here you can see here we have created a new commit when we are trying to integrate new feature to this given master branch which is your ad payment gateway. So I hope so guys you would have got a brief idea regarding this. Now let me also recap what exactly is get rebase. So if I talk about get rebase. So get rebase is a command that reapplies commits from one branch on the top of another branch. So unlike merge which creates a merge commit, rebase moves the entire history of changes from one branch making it on top of another branch and it makes it look as though those changes were made from the beginning. In the case of our e-commerce app, instead of merging the feature branch into the master branch, we can use rebase to make it appear as if the changes feature/ add payment gateway were made from the starting of the commit in the master branch. So without adding new merge commit. So after performing the git rebase your project would look something like this. So you can see all over here in this given diagram before git rebase let's say you have these given commits on the master branch then this is a feature branch efg are the required commits and there is another feature too let's say it could be another sub feature working under the payment gateway hij are the required commit now after you are applying the get rebase command you can see all over here we have a b c d commits on the master branch and it is going to look like e fdash g dash so your given structure is going to look like this. This is pretty interesting. Now let us discuss about a very important concept called git conflict. Sometimes during rebase or merge, git can't automatically decide how to combine changes if two developers have edited the same part of a file in conflicting base. Now this is called as conflict. For example, let's say both of you and your teammate modify the same line in a file such that there is a given file like app.js. Now, let's say when you're trying to merge or rebase, git won't be able to automatically combine the changes. Instead, it will stop and ask you to resolve the conflict manually. Now, what are the steps to resolve a conflict? So, you are going to see something like this. your changes here and your teammates changes here. Now if you are seeing something like this then it is marked by git as conflict because git is confused right now which of the given changes to be added to the main branch. So here you will have to edit the file. You have to resolve it manually by choosing which changes to keep and then you can push the given thing to the main branch. So once you have resolved the conflict you can stage the file and continue with the rebase or the merge thing. I hope so guys you would have got a brief idea about this. Now let me also discuss the importance of git in team collaboration in team environment. Git is very much essential for managing different aspects of a project. Multiple developers can work on the same project in parallel also and without interfering with each other's work. Now, here's how it's going to work. First, the branching is going to come up. Means developers are going to create feature branches to work on isolated parts of the project. Then, you can do rebase or merge. So, once the feature is complete, developers need to incorporate their changes into the main project. Typically, it's going to be a master or a main branch. You can discuss about git rebase and merge, which are basically the two ways to achieve what you have done. Now if I talk about the conflict management like when working with a team you'll often run into the situation where two developers have edited the same line of the file in different ways. Now git actually helps you to resolve these conflicts which is very very much essential concepts working in a team environment. Now before we move into the next part of our lecture let us try to recap all the important git commands. The first one that we have is g branch. So you can type get branch and there you can give a branch name. So basically this command is going to create a new branch. Next up we have is get checkout. So with the help of get checkout you can give your given branch name all over here. Okay. Now this is going to do what? This is going to switch to the specified branch. Next command that we have is called get pull. So if I talk about get pull what this is going to do it is basically going to pull the latest changes from the remote repository. So we can write something like this. Post the latest changes from the remote repository. Next command we have is called get commit. Now this command is going to do what? This is going to save your changes to the local repository. Next command we have is called get fetch. So what does this this command do? Basically it is going to fetch the updates from the remote repository but it does not merge them. So you have to remember them that basically it fetches the updates from remote but it does not merge them. Next up we have this command. It is called get merge. Now basically this merges changes from one branch to the another. So you can just type merge changes. Okay. Now we have this given command called get rebase. Basically what this is going to do that it is going to reapply the commits on the top of another branch making history look linear. So you can just remember something like this that it reapplies the commits. Now the next command that we have is called get status. So guys what does a get status do? Basically it shows the status. So basically what you have worked on your working directory like it is staged unstaged or unttracked files or you're going to get the status with just this given command. Then you have next command that is called get log. What this command is going to do? This is going to display the commit history. Now guys, I hope so you are comfortable with the basic git commands. In the next step, what we can do is let's try to simulate these things by creating branches, working with our own branch and committing them. So basically we can use git rebase to keep your branches updated with the latest changes from master or any branch. Then we can also handle the merge conflicts. They can also learn how to resolve conflicts manually during the rebase process. And finally after all these thing you are going to get a brief idea how you can collaborate with team and in what scenario you can use what kind of git commands such that you are keeping up with your feature branches up to date. Now before we deep dive into it, let us discuss first how does git rebase actually work. To explain this concept better, let us consider a real world scenario of how a team of developers work using git in their project. Let's say you are a part of a software development team working on a project called e-commerce and there are several developers working on different features and each feature is being developed in its own feature branch. All feature branches are based on the main branch which is called master git and the project looks something like this. Here you're going to have master branches and let's say A, B, C and D are the required commit. And let's say you have a feature one in which these are the required commits E, F and G. And next there is another feature two where HIG are the given commits. Now let us try to imagine that EFG are the commits on the feature one branch where developer one is working. HIG are the commits on the feature two branch where developer two is working. As you can see, feature one and feature two branches are based on an older version of master commit which is C. Meanwhile, master has received new commits D from other developers and the features are still being worked on. Now, here is the problem. If developer one finishes feature one and wants to merge it into the master branch, Git will create a merge commit M to merge feature one with the master. Similarly, if developer two finishes feature two, git will create another merge commit. Now, the problem here is that the history will be messy because there will be multiple merge commits that add extra complexity. Now, you can see before rebase. Okay. So, you have this given diagram all over here. In this case, after merging feature one and feature two into master, you get a messy history because of the merge commits M&N. So guys based on this given diagram you can see that after merging feature one and feature two into the master you get a message history because of the merge commits m andn. So here you have merge commit m and here you have merge commit n. So guys the solution here is you can use git rebase instead of merging. When we use git rebase we can update feature one and feature two with the latest changes from the master. Now this ensures that when we eventually merge these feature we don't have to unnecessarily merge commits. Here's how you can do it by applying the rebase. So after you have applied the rebase you can see all over here you are going to get a b c d commits in the master and e fdash gd dash on feature one. So guys, developer one will first rebase the feature one branch onto the latest commit from the master. Now this replace the commits E, F and G from feature one on the top of commit D. So now the commit history looks cleaner something like this. Now you can see all over here in the feature two is now based on the latest master commit and it is rebased on the top of feature one. So if you could see all over here we have the linear commit history and it looks much more cleaner and if you could see the older version how our given git history looked it is looking very very messy. Now this is the exact benefit of applying git rebase in our given code. Now let us discuss some of the benefits of using g rebase in this scenario. We are going to get a very cleaner history. we can avoid having multiple merge commits and the commit history will look linear. There will be no merge commit noise. So by using rebase we are avoiding unnecessarily merge commits like m&n that we created earlier in the merge scenario and it is kind of very easy to follow. A linear history is easier for developers to understand and trace through especially when debugging and reviewing the code. Now let us discuss a very important scenario called merge conflict. During rebase conflicts can arise when g tries to reapply commits and find changes that conflict with each other. Let's see how git handles conflicts during the rebase scenario. Suppose both developer one and developer 2 have modified the same line. Let's say the given file is app.js. Now when the rebase is going to happen, git will encounter a merge conflict because it cannot decide which changes to take from feature one and feature two. And here you have to intervene manually. So developer one and developer two each change the same line in a given file and but on different branches. The branches are feature one and feature two. Let's say developer one commits the changes on feature one and developer two commits a different change to the same line but in feature two. Now when developer one rebases the feature one on the top of master the rebase will succeed without conflicts as no changes overlap with master. But when developer two rebases the feature two git is going to encounter a merge conflict between these two branches. Now g is going to show you a conflict which is basically merge conflict in app.tjs. So this you are going to see something on your terminal. Now the question is how you can resolve the given conflict. First of all open your given file. Let's say there you have written the given changes and you can see here is developer 2's change, here is developer 1's change and then you can manually resolve the conflict by choosing the correct changes or combining both the changes. Now once it is resolved you can stage the file. Then just type get add app.js and then you can continue to rebase. Just type all over here. Get rebase - continue. So if you want to stop rebase and return to the original state, what you can do all over here? So you can type something like this get rebase hyphen and then type about. So, Git Rease is actually a very powerful tool basically which can help you maintain a cleaner and a linear comet history by reapplying comets on the top of another branch. It's commonly used when you're working with teams especially when you want to integrate changes from main branch into your feature branch without creating unnecessarily merge commits. By understanding rebates in real world development scenarios and handling merge conflicts carefully, teams can keep their git histories organized and avoid common issues like messy merges. I hope guys this has cleared you how git rebase is working. Now we are going to do some hands-on for better understanding. Now guys in this section we are going to do a hands-on activity. Now you can see here we have an e-commerce app as an example. Let's say you're working on an e-commerce app with the following folder structure. So you can see all over here you have given folder structure. Your parent folder structure is your e-commerce app. Then you have backend folder and a front-end folder. Now inside the backend folder you have controllers in which you have a file product controller.js. Next we have the model file. basically where you are giving the model of your given product. So I have made this using mongus. Now in the front end section you can see there are two things. So first is components in which I have the product list and next one I have views to display the homepage. Now this is a very basic setup for demonstration but don't worry this is just a kind of a project which you can imagine. Now let us proceed step by step. So first step is initializing the g repository. So go to your terminal be in your e-commerce app and type get init. So all over here type get init. Now you can see I have successfully initialized our get commit. Now let us try to add this given file. So type get add and then give add dot and it is going to add these given files. After that do your first commit and let's say you type get commit - m and in this you can give let's say first commit. Now you can see all over here we have made our first commit. Now your master branch has the initial commit. Let's move on to creating a feature branch. So create and switch to a feature branch where you can add some feature. So you can type something like this. Get checkout - B. Okay. Type get checkout. Let's say hyphen B. And let's say you give your given feature and give slash and let's say add hyphen product page. Okay. So this we have created a feature branch all over here and you can see it says switch to a new feature branch all over here. So we have created a feature branch. Now let us make changes in the feature branch. Let's assume that I have made changes to my given file which is in the front end folder and let us first direct to our front end folder and you can see I have this given react file and let's say I made some very basic changes all over here. So you can see let's try to do something and let's let's add one more line and u all over here just give a h1 tag and let's say uh this product is top rated. Now we have made certain changes in our given file let's say then what you can do is you can commit these changes. So all over here type something like this get then add then you can give front end then give slash and then let's say you type components which is your given folder directory and slash you have made changes to your product list. So basically this is a JSX file. So you can give dot JSX. Now type this and after this do a commit. Let's say get comment and you can give hyphen m and let's say you have added a new feature or you can say you have added something like add new product display feature. Now you can see all over here I have done this given commit. Now at this point my given feature hyphen add product page branch is ready with some changes. You can add new changes to the master branch. Meanwhile, let's say someone else is working on the master branch and has made changes like fixing issues in the back end. Let's say he has done some changes in the product controller.js. Now let's say you type something like this. Let's say constant get products. Okay. Then uh you create a async function. And after that what you do all over here is let's say you're basically returning a DB query. Return DB.query. And uh you can just type select and you can give your given query like select star from let's say products and where you can give status is active. So this what we have done right now. Let's close this given thing. And you can see all over here. So guys, let's assume that we have done this given change. Now let's assume that the master branch has a new commit which will be the base for our rebase. Now let's say after doing this given change, the backend developer does this following commit. Let's say he did a commit like fix query in the product controller to fetch active products. So you can give a commit m get commit and then you can give hyphen m and let's say all over here that you know fixed the product controller active products. Now after this press enter and you can see all over here. So guys some error has come up. Okay, what we can do all over here, we can retype the same thing. So go all over here and what you can do, you can change hyphen m to small m. Now after this just press enter. So you can see we have got this given status that modified backend controller.js. So guys after doing this we got to know that the master branch has new commit which will be the base for our given rebase. Now let's rebase the feature branch onto the master. Step one, start the rebase. Now you want to get the latest changes from master to your feature branch which is add product page branch. So you have to do this by rebasing first. So say get and you type checkout and let's say feature give hyphen and then let's say you have add product page. Just click enter after this. Now after this what you're going to do now after this what you're going to do is you're going to start the rebase. So type this get rebase master. So guys you can see I'm getting some error all over here. So first I need to add this then commit it and then I can rebase it. So I missed that step. So let's try to redo it. So let's type again get dad dot and let's say give a get commit hyphen m and let's say this time added new changes to product controller. Type enter. Now let's try to do get rebase. So type get rebase and let's say master. So you can see here it says current branch feature ad product page is up to date. So guys we have applied the latest changes and if there are no conflicts the rebase will complete without any issues. Now guys after that type this given command get log online graph - decorate hyphen all. Now this is going to show you all the commit history that you have made. So this you can see all over here you can see head we have added a new feature branch. So we have added new changes to the product controller. Then we have added new product display feature and you can also see in the master branch I have done my first commit. So in this way we actually applied all the given things and we have also applied get rebase to understand the given scenario. Now let us assume that the given merge conflict has happened. Let's say I assume that I have made changes to front end component hyphen product list dot jsx folder which is all over here. And let's say someone else modified the same section of the code in the master. So what g is going to do? G will try to apply your commit on the top of master but since the same file was changed so g will detect a merge conflict and git will stop and display this message conflict content. Next you can merge conflict in front end component hyphen product list.jsx. So for that open the conflicted file. Let's say in the product.jsx you're going to get the same message which I showed you earlier. So g is going to mark the given line where the conflict is happening. So manually resolve that first. So there is no automatic way where you can automatically resolve it. So there is a manual intervention. So you have to decide which line to exactly choose and then you need to save it and then you can push it to the repo. Now after you have resolved the conflict stage the resolve file. Okay. So you need to stage a file. Let's say you need to type get add and give in your folder structure like front end components and then hyphen product list.jsx then you continue to the rebase. Now you can perform the same operation that we did earlier but with this command get rebase - continue. Now let me explain what this has exactly happened when merge conflict has happened. So all you have did is that you have resolved your merge conflict. Then after resolving your conflict you have given the command get rebase and then you are continuing it. So what will happen guys? So g will continue applying the rest of the comments from our feature hyphen add product page branch on the top of master and if there are no conflicts the rebase will finish successfully. So this was a very short stimulation on the e-commerce app. Now what you can also do, you can also forcefully push the changes to the remote since rebase rewrites the commit history. So you'll need to force push your changes back to the remote history. And for that you need to type get and then you can just say push. Okay. And after that give hypheny force. Now why force push? See a regular get push won't work after rebase because the commit history has been rewritten. Force pushing is required to update the remote branch with the new commit history. So these are the given things you need to consider when your merge conflict has happened. I hope so guys you would have got a brief idea regarding this. Now let us try some of the scenario based things to understand more about grybase. Now guys let us go through the official documentation of get rebase and we are going to understand each of these commands one by one. Now the first command is get rebase. So basically what it does is it reapplies a commit on the top of another tip. So get rebase is a command which is used to reapply commits basically from one branch on top of another. In simpler terms, it allows you to move or replay your changes basically commits from one branch onto the another. It's kind of very much helpful when you want to keep a clean and a linear history. Now let us look at the hypnosis. So guys, you can see all over here it's written git rebase. Then uh there's a given square bracket. Then there's a i flag and you can see hyphen interactive. Then there are options. Then there are hyphen - executive command and in this there is cmd. Now what this is exactly? So if you see this the hypnosis section actually shows you the syntax for using gbase command. First of all if you could see hyphen i - interactive. So basically what it does is it allows you to perform an interactive rebase where you can choose which commits to apply edit or remove. Then you can see there is a this command hyphen x and cmd which means that you can run a custom shell command after each commit is applied. Then you can see there is another command hyphen onto new base. This means that it allows you to specify a new base commit or branch to apply your changes on the top of it. Then you can see all over here it's written hyphen root and then [clears throat] branch. So basically it is going to rebase the root commit the very first commit of the branch as well. Now if you could see this given line. So this line contains commands which you can use during a rebase to manage conflicts or continue the process. So you can see all over here I am getting hyphen continue. So which means that continue the rebase after resolving the conflict. Then there is hyphen skip. So it says that skip the current commit that has caused issues. Then you can also see all over here there is hyphen abort. So it means that you have to abort the rebase operation entirely. Then you can see all over here there is hyphen quit which says that abort the rebase but keep the changes. Then you can see all over here it's written hyphen edit to-do which basically means that edit the list of commits to be applied. Then you can see all over here this is hyphen - show then hyphen current then patch. Basically this means that it shows the current commit patch during an interactive rebase. Now let us try to understand what is written in this description. So it says that if the branch is specified get rebase will perform an automatic get switch and before doing anything else otherwise it is going to remain in the current branch. Let's say if you specify a branch to rebase onto then g will automatically switch to that branch before starting the rebase. If you don't specify a branch then git will continue to work with the current branch. Now you can see all over here it's written if upstream is not specified. So guys you can see all over here it says if upstream is not specified the upstream configured in branch name then dot remote and branch then dot merge options will be used and the hyphen fog point option is assumed. Now first let us try to understand what exactly is upstream. So guys upstream is the branch that you want to compare your current branch against. If you don't specify an upstream, so what is going to happen? Git will use the default upstream configured for your branch. Example, the remote branch it tracks. And if you are not on any branch or if the upstream isn't configured, then the rebase will abort because Git wouldn't know what to rebase onto. All the changes made by commits in the current branch but that are not in the upstream are saved to a temporary area. This is the same set of commits that would be shown by get log upstream.head or by get log for point. Now in this let us try to first understand what exactly is temporary area. So guys basically get saves all the commits from the current branch that are not in the upstream branch to a temporary area. This is similar to the commit shown by git log then upstream then dot dot head. Now if you use the hyphen -y fork point option then git calculates which commits to rebase using a different point in the history basically the fork point. Now if you could see all over here it says that the current branch is reset to upstream or a new base if the hyphen onto option was applied. So this has exact the same effect as get reset and hyphen hard. Now let us try to bit understand about resetting the branch. Let's say if you use the hyphen onto option then git will reset the current branch to the specified upstream or new base. This means that all the changes in the branch are effectively moved onto the new base as if you are starting fresh and from that point. Now guys let us try to understand bit about origin head. So this is a special reference that points to the original state of the branch before the reset. Now guys, you can see all over here there's a very special note in the documentation which says origin head is not guaranteed to still point to the previous branch tip at the end of the rebase if other commands that write that pseudo ref for example get reset are used during the rebase and the previous branch tip however is accessible using refflog of the current branch. Now basically it's trying to say that after the rebase origin head might not point to the original branch t if other commands that modify it like example get reset that are used during the rebase operation. However you can still access the previous branch tip using the refflock. So this is what in nutshell it means. Now it says that after resetting the branch git will reapply the save commits the ones that are not in the upstreams one by one and if any commit in the head has already been accepted in the upstream then it is going to introduce the same changes and that commit will be skipped during the rebase. So this is all what exactly it means. Now let us try to also understand conflict handling and commands which are present in the documentation. Now basically here it means to say that if there is a merge conflict then git will stop and wait for you to resolve it manually and after resolving the conflicts you can continue the rebase with git rebase hyphen continue and also you can skip the problematic commit with get rebase hyphen skip or abort. then also you can abort the given uh you know rebase operation with get hyphen - abort. Now let's try to understand this given example. Now let us assume the following history exist and there is a current branch which is topic. So if you could see all over here then a [clears throat] b c is the given topic and you can see dfg is in the master branch. From this point the results of the either following commands. For example, if you type git rebase master or git rebase master topic, it is going to reflect something like this. Now let's try to break it down in more simpler words. Let's say if you have two branches for example topic and master and after running git rebase master the commits from the topic a b and c will be reapplied onto top of the master which is the d efg resulting in very new commits for example like a hyphen b-en and c hyphen. Now let us try to understand this given part. It says basically if you want to change the base of your topic branch to the master instead of the next you can use hyphen onto and this command tells get to take the topic branch and reapply it on the top of master rather than next. Now let us try to understand further options and customization. In the remaining part of the documentation it lists several other options to fine-tune the rebase behavior. For example, if you could see the hyphen -y continue command which is basically continuing the rebase after resolving the conflict. Then you also have something like all over here which is says hyphen skip basically skipping the commit that has caused the merge conflict and then also you can see there is another option which is written hyphen abort. So basically meaning that you have to abort the rebase and reset the branch to its previous state. Now guys let us take each diagram and try to understand what it means step by step. So let us see the first scenario. So in this given scenario what we have is we are moving topic from next to master. So guys in this given diagram if you see all the O's are the commit. First we have the master branch. Then we have the next branch and then you can see there is a topic branch and these points to the respective commits on each of the branch. The visual tree here shows how the branches are created. Now let us try to understand what would have happened in this project. First someone worked on the master branch and created few commits. So for example you can consider these are the commits to the master branch. Then from somewhere in the middle of the master they created a new branch which was called as next. Then they tried to apply some new features. That's why you see a split all over here. So from master to the next. Now later from the next they created another branch called topic. So you could see all over here. Now you can understand that topic was created from the next. So guys, what is the problem in this given diagram that we have? So basically topic depends on some functionality that is now already merged to the master. Maybe let's say the next branch is unstable and has some extra unfinished changes and now you want topic to be based on the master not to the next. In other words, you want to pretend let's say I started working on topic from master not from the next branch. Now what we want it to look like after rebase operation. So you can see something like this. Now notice the changes in the master is still the same. But you can see in this diagram right now that the topic has moved. It no longer hangs below next. Instead it now hangs off to the master directly. Now you can see the commits on the topic are now listed with O and then there is inverted commas all over here. So let's call it as O prime which means that these are the new copies of old commits replayed on a new base. So Git doesn't literally drag and drop commit. It replays the changes from topic on top of master creating new commits. And the command that we have all over here is get rebase - onto master next topic. This kind of looks scary but let's break it. The general form of get rebase hyphen onto. Then you give basically a new base all over here. Then you have a upstream then you have a branch. So this is the given thing. Now in our case the new base is master. Okay. And the upstream is the next and you can see all over here that the branch that we are referring to is topic. So basically it says take all the commits that are on topic but not on next and replay them on top of master. So basically what is happening is git compares topic and next and finds the commits that are unique to the topic. After that, git then starts from the master branch which is basically our new base and then git replays each unique commit from topic onto the master one by one by creating new commits. For example, O prime from O. Now after that guys the branch pointer topic is moved to point to the last new commit. Now basically now topic appears as if it was created from master originally even though it started from next. Now let us try to understand the second scenario. In the second scenario, we are rebasing only a part of a branch. For example, topic B without topic A. So let's say this is our original diagram. So for example all over here A B C D are the commits from the master branch and from D someone created a topic A all over here and these are the respective commits E F and G and from topic A someone created topic B and HIG are the respective comets. So basically topic B is everything in topic A plus the commits in HIJ which happened in topic B. Now what we want exactly? So we want the commits HIG which is the work of topic B basically to be based directly on the master not on topic A such that you will result H prime I prime and J prime directly you can see it is attached to the master branch. Now after applying the same operation get rebase onto master topic A topic B and now you can see all over here that topic B is directly depending on master branch it is no longer depending on topic A now here we have applied this given flag hyphen onto then we have given the given branch names and this is the new branch and here we are using the same pattern so our new base is the master And this is the upstream branch and this is the given branch name that we want to apply the rebase operation. So guys from this the key takeaway is that take all the commits that are on topic B but not on topic A and replay them on the top of master branch. So that get looks at topic B and topic A finds the unique commits of topic B. Okay. And then you can see it has directly added to the master branch. And finally after doing so it replaced them on the top of the master branch which is basically after D. So you can see these are the given commits that are removed all over here from topic A. Now you can also see a very good observation all over here that topic B is independent of topic B. Now this is actually useful when topic B actually doesn't need the work from topic A and you want to clean up the history. Now let us look onto the third scenario. Let's say the branch topic A has these given commits for example E F G HIG. Now you later realize that the commits F and G are bad or should not be the part of the branch. So you want history something like E H prime I prime and J prime on topic A. And let's say you want to remove these given commands. So your given command is get rebase - onto. Then basically you are giving topic a let's say five topic a three topic a. So this looks kind of complex but let us try to understand this first. So if you see topic a all over here which is written. So this basically means the commit before I all over here. Now if I say topic A - 1. So what does this mean? This means that there is a one comet before J which is basically I. Now if if I want to say topic A - 2 which says that what is the next commit before this? So here it's H. Similarly if topic A - 3. So this points out to the commit G. So similarly in this given command that we have all over here we are trying to map it to the general pattern. So basically what is happening here that when we are applying this given command get rebase hyphen onto then we are using the same concept. First of all we are adding the new base then the upstream and the branch. So here this denotes your given base. This is your upstream and this is your given branch name. And finally it is going to return something like this. So basically what has happened all over here we have taken all the commits that are on topic A but not reachable from topic A - 3. Okay. So which is basically after G. So basically it is going to replay on the top of topic A- 5 which is basically your E and the commits that are after G which are basically hig. So these are the one which are getting replayed. So effectively get skips over F and G and it starts from E. It replays HIG onto E and finally you get H prime, I prime and J prime. Now this is pretty interesting trick. So let's say if you are rewriting the history to cut out some commits from the middle then you can use this. Now let's assume that conflicts happen in rebase. So here what you are going to see that git is going to replay the commits one by one onto the new base and if the commitment doesn't apply cleanly because the same lines were changed differently in the new base then get stops and says there is a conflict and at that point g pauses the rebase then it files with conflict and you are going to check the file which has the conflict and basically git will also Mark it like I showed you earlier. So you're going to see something like this. So guys, here you are going to see something like this. So basically you are going to see a head. So here it means that what exist on the current base when you are trying to rebase onto and this is a given separator. Let's say here you someone else has added any other code let's say from your team. So basically the changes that are applied in the commit. Now you have to manually open the file and decide it what is the final version and how it should look like. Maybe you can keep developer one's code. Maybe you can keep developers two code or you can have a mix of both of their code. After fixing the file you tell the git that I have resolved the file. So basically what you do is you are going to type get add file name. Now once all the conflicting files are resolved it is added to your given thing and you tell the git to continue the rebase. So basically you type get rebase hyphen continue. Now if any other conflict happens and the same process repeats you have to do the same thing. Now let's say you have changed your mind then you can also type get rebase hyphen abort. So guys sometime while rebasing you realize that it has gone too missy and let's say for example you chose the wrong base and you don't want to continue that operation. So guys in that case you can cancel the rebase. So get rebase hyphen abot. So it is going to stop the rebase completely. It is going to reset your branch back to the state it was in before the rebase started. Now all the partially applied changes from the rebase are thrown away. So guys hyphen abort is like forget I ever tried to rebase put everything back as it was. Now I hope so till here you would have got a very clear idea what are the given scenarios you can face. Now let us also try to understand the mode options. So these are the special rebates commands that only work while rebase is happening during conflict or pause. Now you can always think rebase as like when you're watching a movie. So rebase works as like you have paused the given movie. So that is the operation which get rebase is doing. Now these are some of the mode options. So basically they help you to add some new functionality. Now when you are trying to apply hyphen continue so it means that let's say like you are watching a movie and you want to continue the movie then you can try this given command. Let's say if you want to skip a given scene you can use hyphen skip. Let's say if you want to stop the movie then all over here you can do the avoid operation. Let's say you want to restart the movie so you can use hyphen quit command. Let's say if you want to edit this script so so you can use this given thing. Now let us try to understand bit about this given command. So basically it says that stop the rebase but don't reset anything. Leave my files exactly as they are right now. Now what's the difference between abort and quit? Basically abort is going to reset the head back to the original branch but it does not move head. It discards all the staged or unstaged changes and it is also going to keep all your changes as it is. It is going to clean the rebase metadata. It is also going to clean the metadata only which you have given. Now all over here what it means that everything goes back to the state before the rebase and also your current work is preserved. So basically you can use this when you want to stop the rebase process but you want to keep editing the code manually. And also when you want to inspect the current state without the changes being disappeared. Now if you look at this given command get-edit all over here then there is todo. So it basically says let me modify the list of commits in the to-do list during an interactive rebase. So this only works in interactive rebase. For example like get rebase you give hyphen i then you can give hit five. So guys, this works only in the interactive rebase. For example, get rebase hyphen i then head five. So get opens a file which is basically called todo. It could do some commit all over here. Then it does another commit. So with the help of using hyphen edit in the todo file, you can reopen the list at any time and change the given thing. So you can also edit, drop or squash. Now guys let us explore some of more options. So first one as you can see over here it says hyphen onto new base. Normally the base is a upstream branch where you are rebasing against like its origin or master. But with hyphen onto you can specify a new starting point for the rebase. Now when you want to use this guys when you actually want to change the starting point of your rebase not just the default upstream and also you need to change the place where the branch should be released without using the default branch like master or main. Now let me explain you with an example. Let's say you want to rebase feature from master but not from the upstream like origin or master. You want to use other branch as the base. So you can type get rebase hyphen onto and the other branch name and then the upstream and then you can give the feature. So this command will take the commits from the feature but rebase them onto the other branch instead of the default. So let's say if you have two branches all over here A and B. Okay. And these are kind of special branches and then you want to use their merge base. So you can use this given thing. So that is very much helpful in that scenario. Now let us explore the next command which is hyphen -y keep base. So what exactly it means? So actually this option keeps the original base of your branch instead of moving it to the latest commit in the upstream branch. Now let's imagine you're working on a feature branch but the upstream branch has moved. And also guys that you want to look into this that you don't want to keep rebasing on top of the latest commits from upstream as it might cause unnecessarily conflicts and also you want to keep the base commits to stay unchanged while keeping your changes. For example guys let's say for example let's imagine that we have this upstream branch and this is our given feature branch and these are the respective comments. Now the upstream has changed and you want to keep the base as it is as it was originally not the latest commit. Now with hyphen -y key base what you can do guys you can keep the base commit for feature branch avoiding unnecessary rebasing. So this is kind of very much interesting and you can also see this this given option is also equivalent to get rebase reapply cherry picks and also no fork point and hyphen upstream then you give feature then upstream feature so this is what the documentation says guys and I hope so you would have got the brief idea when to use keep now let us try to explore this given thing hyphen apply type. So guys, what does hyphen apply means? This command basically tells the git to use the apply strategy for rebasing. So instead of the merge strategy, you can use this. There are rare cases when you actually want to use git am okay and this is kind of an older strategy but there are very much chances that it might get deprecated and most of the time you will be not needing this option. Now let us explore hyphen empty. So actually guys this option controls what happens when a comet becomes empty after a rebase. So if a comet becomes empty it does not introduce any new changes compared to the new base and it might be a duplicate or a subset of upstream changes. So here you have three options which are drop meaning that it will automatically drop the empty commit. Then you can see we have this given option which is keep. So basically what keep is going to do it is going to keep the empty commit which is very useful for when you are actually doing intentional empty commits. And finally you can see we have stop option also. So what a stop is going to do it is going to pause the rebase and lets you decide what to do exactly. Now guys there is one question which you can ask like when to use these things. So for example let's say when you are rebasing and you're noticing some commits then don't make any changes anymore. So in that scenario what you want to do is you want to either skip them or keep them. So let's say if you are using hyphen interactive then you can also edit these commits during the rebase. For example guys, let us take one thing. So here you can see we have the master branch and these are our you can see the commits that we have and this is commit C which is already in master and you can see there is another commit D which is not in the master. Let's say the commit C has no changes because it's already in the base. So if you apply hyphen empty drop then commit C will be discarded automatically and you can see after this so you cannot see C anymore and D prime is directly connected to the master branch. Now guys let us explore this given command which is hyphen no keep empty. Basically what it does is it does not keep empty commits it removes them. So when to use this command? Let's say when you intentionally create empty commits like for example placeholders uh you know if for any future changes which you want to do. So when you give this command hyphen no keep empty. So you are actually automatically removing empty comments that are generated by external tools or any unnecessary comments. Now you can see all over here we have this next command which says hyphen reapply cherrypicks. Now what does this means? So guys, this option reapplies clean cherry picks from upstream commits that were previously applied to your branch. Normally when rebasing git will drop commits that are identical to the commits that is already there in your upstream branch. So we are calling or we are referring upstream branch as cherry. So with hyphen reapply cherrypicks, git won't drop those commit but reapplies them. Now when to use this actually when you want to reapply the commits that might have been cherrypicked but are still useful and it's kind of very useful when you are actually rebasing some of your commits which actually overlap with the upstream commits but it also should be kept. Now guys next up we have hyphen allow empty message. So basically what this is going to do so this option is going to allow commits with empty commit messages that needs to be replaced. So by default git will stop the rebase if the commit has empty message. Now when to use this? For example, let's say if you have commits that accidentally have empty messages. So guys in that scenarios while rebasing git will allow these empty message commits without stopping the process. Next up guys as you can see hyphen m or hyphen merge. So what does this mean guys? So basically this option tells git to use merge strategy for rebase. So by default git uses merge strategy during rebase but you can explicitly specify it. Now you'll be wondering when to use it. Let's say if you want to use merging strategies during rebase which is default for most of the use cases then what is going to happen is that git will apply changes from branch on top of to the new base while resolving conflicts. Next up guys, as you can see our given command is hyphen strategy and then equals to strategy or hyphen s strategy. Now what this exactly means? Basically this option allows you to choose a merge strategy. Normally git uses a default strategy. Okay, but you can specify others like recursive ours. Now when to use this? Actually when you want to control how conflicts are resolved during rebase. For example guys, hyphen hyphen strategy which equals to recursive. This is going to handle complex merges. Now next command which you can see all over here is mentioned hyphen rear and then auto update. So basically this is going to automatically update files with conflict resolution from here. Then you can also see all over here that we have no rear rear auto update. So basically this does not auto updates the resolved conflicts but it gives you a chance to review them. Now when to use this? So guys let's first talk about this. So let's say when you want get to remember how you solve conflicts you can use this and also let's say if you want to reuse those solutions automatically while if I talk about no rear auto update. So let's say if you want to manually check what Git has resolved, you can use this. Next up we have hyphen GPG- sign. Now what does this mean guys? This signs each comet with your GPG key which basically adds security and identity to the commits. Now when to use this? Let's say when you want commits to be GPG signed to verify the identity of the committer. Next up we have hyphen quiet. So what does this mean guys? Basically this option controls the output verbosity during the rebase. So quiet meaning it reduces the output showing less information and hyphen if I just tell you about verbose which basically shows more information including stats on what was changed. So basically as you can see all over here hyphen hyphen stat is going to show you the status. Okay. So basically it shows a status on what was changed on the offstream since the last rebase operation and basically hyphen no stat is not going to show you that. Next up let's try to understand hyphen no verify. So basically this command does what? It skips the pre-base hook like let's say where the script runs before a rebase operation. So there you can use this given command and also if I talk about hyphen - verify this means that you're going to run the pre-base hook which is kind of a default behavior. Now if I talk about no verify so let's say if you want to skip any custom hooks and just rebase it and if you want to use this verify command. So let's say like if you have this given scenario where you want to ensure any custom checks or hooks are run before the rebase. So there you can use this. So guys this was in short bit about some of other options that you can find in your GitHub based documentation. For more options explore this documentation. This is a very wide documentation guys. And I also hope that you would have enjoyed our today's tutorial on git rebase. Also guys if you have any doubt related to this given topic then please mention your doubt in the comment section below. And also guys, if you like these kind of videos, then do not forget to hit the subscribe button and click the bell icon so that you don't miss out any update from our end. Thank you guys for watching this video.