When i should/shouldn't use git pull --rebase

Question

Already checked those questions:

When should I use git pull --rebase?

Git commits are duplicated in the same branch after doing a rebase

When will `git pull --rebase` get me in to trouble?

but what i don't understand is that some people say that you should always git pull --rebase and also others went to setting it as a default option when pulling and others said it's creating a problem.

I'm facing the duplicate commits issue in git log and i guess it's because of --rebasing in the wrong time where we should only pull, I know that the difference between git pull and git pull --rebase is that git pull is trying to merge both local and remote while git pull --rebase replicate the commits.

Scenarios:

1. when i start my work and before doing anything new i need to pull other developers changes, should i use git pull --rebase or only git pull ? and why?
2. when i work and commit and decide to push but then git asks me to pull first should i use git pull --rebase or git pull? and why?
3. when I work and commit, work and commit (loop) and then in the middle of my work i need someone's else changes before i continue my task should i git pull or git pull --rebase ? and why ?

Thanks

Answer 1

git pull does two things - a git fetch followed by git merge. If you use git pull --rebase, it instead does git fetch followed by git rebase. To answer your specific questions:

1. If you haven't committed any changes locally, it doesn't matter. The result will be the same. The implicit git merge will be a fast-forward.

2. Normally in this case you'd want to rebase; you'd prefer your changes to be linear history on top of what's going on with the remote.

3. Normally you'd rebase here too. Again, you want your local work to be added on top of the remote's history, not adding merge commits to it.

All of this mess can be avoided by just not working on the remote tracking branch.