GIT pull with rebase
It’s been a while that I’m asking myself if doing
git pull --rebase is dangerous. Doing so will avoid git creating a new « merge » commit and put your change on the top of new received commits.
I read a lot of threads on the net (eg: StackOverflow, …) where people are saying a wisdom sentence:
« None should rebase on GIT (unless you know what you’re not knowing) »
After refreshing my mind, I decided to dive in the subject. A lot of people are confusing
git rebase ... with
git pull --rebase. The important thing is that you’re not changing the history unless you really need it. This will need to be communicated to all people that are working on the branch that need to be rebase. So if you’re rebasing the origin/master or origin/develop branch and if 25 developers are pushing on it, you’ll need to ask then to stop doing so. Then you should be in the latest head/state. Rebase what you want, push force and tell you’re team that they will need to
git pull --rebase. As you can see, it is needed to lock the current state of the repository ! Also, there is a hudge risk to break/delete the history of your commits !
In the other hand,
git pull --rebase is not dangerous AT ALL ! One should add the global git option to avoid typing
--rebase all the time.
$ git config --global branch.autosetuprebase always
The only situation that can confuse you is when you just merged your branch into the main branch. Then doing
git pull --rebase will tell git to replay the story. The effect would be that each commit will be added one by one instead of seing a proper merge commit. Hence, instead having a correct tree where you would see that branch merge form your branch to the main one, you’ll directly see the commits. This is because GIT is smart enough to get back or « rewind » and make a fast-forward.
People are discussing on that point and some like to see this little merge commit message telling that it was from a branch. While other don’t care and consider this as noise.