Sometimes I see at articles command:
git pull -p
Before fetching, remove any remote-tracking references that no longer exist on the remote.
Perhaps this should be a second question now:
But I do not understand how git-pull corporate with git-fetch? How I can figure out how and which git options fall through one command to another?
(I think you mean "co-operate"1 rather than "corporate" here.)
git pull command used to be a shell script. In the script, it's easy to tell which options are passed to
git fetch, which are passed to
git merge or
git rebase, and which are consumed directly.
As of Git version 2.6.0, the pull command was rewritten in C. It's still possible to tell which options are which, but it's now somewhat more difficult since you must look further down to find the text spellings of each option. (This second link may decay over time as it has GitHub look up the current version of the source file, and the line numbers may change.)
I myself recommend avoiding
git pull: run
git fetch, then inspect the result, then choose
git rebase (usually) or
git merge (sometimes) as needed. I also keep an alias,
git mff, that expands to
git merge --ff-only, and I tend to run
git fetch && git mff: if the fast-forward fails, I probably want to rebase, unless I want to merge, and this sequence (fetch and merge-if-fast-forwardable) either succeeds (in which case rebase vs merge makes no difference and we're done) or fails (in which case it's time to inspect).
(It might be worth adding an alias
git fff that runs
git fetch && git mff... :-) )
1This can be written as "cooperate", without the hyphen, or even as "coöperate", with a diaeresis above the second o. The diaeresis was common in English text in fine printing (and The New Yorker still uses it!), but with typewriters unable to produce it, began to be less common in the early to mid 1900s. Now that computers have Unicode and umlauts—which are technically different, but symbolically identical—I think we should restore the diaeresis to preëminence. :-)