Git Rebase - How I struggled using it for the first time

I was taught to use git rebase from now on before making a pull request. Honestly, the command it self was confusing. This is how I understood git rebase

1. You are rebasing the master branch. The command for git rebase is git rebase -i master. -i represents interactive, which allows you to choose commits to include as you rebase your master branch.

After using the command, you face a message like the image below;

Using the commands explained, you can choose which commits to use. If you are going to use all the commands, you just have to leave the top commit as pick, and choose the rest as s, or squash so that all the commits can be squashed together.

2. Conflicts may occur in every step. Forgot to take a screenshot of it, but I faced 3 conflicts while rebasing 7 different commits. You have to be careful as you resolve the conflicts.

So then, why do you have to use git rebase when you can simply just git add and then git commit?

git rebase ensures that the orders of commits do not get messed up. When you make a pull request the master/develop branch pulls each commit based on the time that it was made. Therefore, it is difficult to track down the history of each commit. And it gets worse if you have to revert your commit since commits from different feature branches are all mixed together.

By using git rebase, you need to take more time before making a pull request, but you can prevent the master branch from having mixed-up history of commits from different branches.