Git Flow charts

Note : git checkout arrow should be same as the git merge arrow

Therefore: ==> git checkout my_branch vs. git checkout origin/my_branch

Fetch all remote branches

git fetch origin

What Is Git Merge and Git Rebase?
git rebasedoes the same job as a git mergethat is merging the changes from one branch to another branch. The difference is that they do it very differently.
Consider you are working on one of the features of an application in the featurebranch and the git commit history has the following structure.
before git merge master
How to Merge the Master Branch to the Feature Branch Using git merge?
git checkout feature
git merge master
The above merge process will create a new merge commit in the feature branch which will have a history of both branches.
after git merge master
Every time you want to add changes from the master branch to the feature branch a merge commit will be created in the feature branch. In the above git commit diagram, c3 and c4 commits from the master are merged to the feature branch using a merge commit *c8. Also, it is safe as the branches do not change in any way.
How to Rebase the Feature Branch Onto the Master Branch Using git rebase?
Now consider the below commit history diagram:
before git rebase master
And we want to rebase the feature branch onto the master branch which can be done using the below two commands.
git checkout feature
git rebase master
The rebasing process moves the base of the feature branch to the beginning of the master branch incorporating all of the new commits in the master branch.
Instead of creating a merge commit in the feature branch, rebasing re-writes the commit history by creating brand new commits for each commit in the feature branch.
after git rebase master
In the above git commit history *c5 ,*c6 and *c7 are brand new commits in the feature branch.
As you can see in the above git history structure, the commits are linear and we can backtrace any commit from the start of the tip of the feature branch to the first commit in the master branch. The git rebasing process doesn’t create unnecessary merge commits. And hence the project’s git commits history will be much cleaner and easy to understand by other developers.
Note: You should not rebase a public branch onto your feature branch because this will create different master branches, one for yourself which you are referring to, and the other is, all the developers are working on. See the below structure to understand this:
Before rebasing the master onto the feature branch:
Before rebasing the master onto the feature branch
2. After rebasing master onto your feature branch:
After rebasing master onto your feature branch
Now you are referring to a new master branch and everybody else’s referring to the old master branch.
You can synchronize these two different masters, then you have to merge these two masters into one, and hence it will result in duplicate commits(one from your master branch and the other from the old master branch). It will make it very messy to understand the history of the master branch. Hence it is advised not to perform git rebase onto public branches.