Are you familiar with Git? If not, Git is used amongst Software Developers and is software for tracking changes in any set of files. Most developers use Git for version control. It can be used directly from the command line, or dedicated software can be used for creating new branches, new commits, and pushing code to the remote location.  
But are you using everything Git has to offer? In this blog, I would like to talk about a more advanced git technique that you should really start using if you aren't already. 

GIT rebase 

Have you ever had a situation where you committed your changes for a feature you're working on but find out some code is not quite right, or the design changes and a button that was initially colored red now needs to be blue? Now you can make the changes, create a new commit and call it a day. You can revisit a previous commit, make changes, and literally rewrite history with rebase. The change will be on top of the original commit, so the history stays clean and only reflects changes that actually need to happen. 
Because you become a time wizard while rebasing, and you will literally rewrite history, it's advised only to use rebase when you're the only person working in the branch you want to rebase. If someone makes some changes while you rebase, the branch Git will lose track of the history, resulting in some nasty conflicts that might be difficult to solve. It's a powerful tool but also one to be careful with. Also, always make sure you have your branch on remote before rebasing so you can easily discard all changes and go back to the remote status of your branch. 
In what situations should you rebase? 
Rebase can be used to change the history of your working branch. After you're done rebasing, you will need to force push the changes to the repository, and the history will also be replaced on the remote branch.  
Another use-case for rebase is to get changes that were merged into the develop branch into your feature branch. Say someone finishes a feature, merges it to develop, and you have some dependencies on it in your own feature. One way to receive these changes would be to merge the developed branch into your own branch, but this will add a merge commit and causes your branch's history not to stay very clean. My preference in this situation would be to use rebase and rebase your branch on top of the developed branch. This way, you will get all the changes in your feature branch, and your history will stay clean. Of course, now you will need to do a force push.  
Other use-cases for rebase include: 
    Combining multiple commits into one. 
    Rewriting a commit message. 
    Removing entire commits and their changes. 
If you don't use rebase already, master your Git game and add rebase to your toolset today. 
How to use rebase 
Most Git software supports Git rebase, or it can be used directly from the command line using the following command: 
git rebase -i <branch> 
The branch is the branch you want to rebase on, and you always rebase your current working branch. With the -i option, you enter interactive mode. You will see an overview of the commits, and in front of each commit, it says 'pick'. For each commit, you can specify which action you want to perform. For example, replacing 'pick' with 'e' or 'edit' will give you the ability to make changes to that specific commit. 'r' or 'reword' will give you the ability to change the commit message, and 's' or 'squash' will combine the changes of the commit with the previous commit making it one commit. There are some other options. Please take a look at the list that has a description for all of them. 
Blog asset
After you’ve made the changes in interactive mode for a specific commit, you can add the changes by running: 
git add <changed files> 
Then you will need to tell Git you want to move to the next commit with: 
git rebase --continue 
This will move on to the next commit or finish rebasing. If all is finished, you will need to force push your changes: 
git push --force 
It’s also possible to omit the -i flag, and rebasing will happen automatically. This is useful if you only want to receive changes of the branch you rebase on into your own branch. You might still enter interactive mode to a specific commit if there are merge conflicts and you will need the commands above to navigate further.  
Git has a lot to offer and I hope you have learned more about how to work with Git to the fullest. If you are curious about more Git techniques, keep an eye out for my next blog.  
    Author's experience: Tijmen Helder, Senior Frontend developer
Are you using everything Git has to offer?
At Rebels, we have many highly-skilled international employees interested in the Dutch language...
Recently, we had a tech talk with Ingmar van Busschbach about Unreal Engine 5. Today, we will be diving deeper into the topic.
Our new colleague Ivanna shares about her unique onboarding experience at Rebels.