git fetch is what syncs the remote changes to your local repo. . If you want to see these changes, they are referenced by so-called remote-tracking branches. To view them use:
git branch -r
Now, if your local branch (let's say its master) has not diverged from the remote branch to which it corresponds (typically origin/master), then it doesn't matter whether you use rebase or merge. In the case where your local master is a superset of the remote master, there are no new remote changes to incorporate. In the case where where your local master is a strict subset of the remote master, then either rebase or merge will perform a so-called "fast-forward" operation which basically just updates your local master to the same commit as the remote master.
However, if your local master has diverged from the remote master, then there is work to do:
Rebase will take all your new local commits, set them aside, reset your local master to the same commit as the remote master, then replay your commits one at a time. If there are conflicts, you will of course have to resolve them as you go.
Merge, on the other hand, will attempt to create a merge commit. A merge commit is one that has two parents. In this case, the parents are the tip of the remote master and the tip of the local master. Of course, here too there may be conflicts for you to resolve.
Regardless of whether you performed rebase or merge, when done, your local master is now a superset of the remote master and you can push out the change. (Unless of course, while you were rebasing/merging, someone else pushed their changes. In this case, wash, rinse, repeat…).
Now, as to whether to use merge or rebase… there is no right answer. It very much depends on the workflow.
Rebase will give you a "cleaner" history in the sense that the history remains linear which some folks prefer. A linear history is easier to understand and if you ever need to use "git bisect" to find where something broke, a linear history is much easier to deal with.
However, some folks prefer to see the true history of development in the sense of "when so-and-so started this work, on which commit was it originally based?". In that case, merge preserves that information (as long as it wasn't a fast-forward -- but you can always force a merge commit with "git merge --no-ff").
In some cases, it makes sense to use both rebase and merge -- rebase for simpler changes and merge to incorporate long-lived topic-branches.
It pains me that the git man pages are so awful. Patches welcome (it is unfortunate that newbies provide the best perspective on how awful the docs are, while simultaneously are the least likely to be able to contribute improvements to them). Ultimately, git is actually based on some fairly simple concepts and I happen to think that once you have a conceptual understanding of it, all the commands (more or less…) start to make sense. So I strongly advocate trying to understand what the heck is going on under the hood.
That said, the Pro Git book is a much better place to start learning git than the git man pages.
"Merge, on the other hand, will attempt to create a merge commit. A merge commit is one that has two parents. In this case, the parents are the tip of the remote master and the tip of the local master."
Now what I understand from that is that "merge" (that is pull without rebase) should not be worse in any way!
In both scenarios git doesn't have less information to begin with, it doesn't start with any false assumption, it's just that without --rebase the resulting local repo is supposed to contain a bit more information.
Then why in the world is "pull --rebase" again "easy" to make the result and why is plain "pull" something that's "hard" to do for a beginner?
Now I think it must be some side effect of one or another that makes the whole story relevant?
However, if your local master has diverged from the remote master, then there is work to do:
Rebase will take all your new local commits, set them aside, reset your local master to the same commit as the remote master, then replay your commits one at a time. If there are conflicts, you will of course have to resolve them as you go.
Merge, on the other hand, will attempt to create a merge commit. A merge commit is one that has two parents. In this case, the parents are the tip of the remote master and the tip of the local master. Of course, here too there may be conflicts for you to resolve.
Regardless of whether you performed rebase or merge, when done, your local master is now a superset of the remote master and you can push out the change. (Unless of course, while you were rebasing/merging, someone else pushed their changes. In this case, wash, rinse, repeat…).
Now, as to whether to use merge or rebase… there is no right answer. It very much depends on the workflow.
Rebase will give you a "cleaner" history in the sense that the history remains linear which some folks prefer. A linear history is easier to understand and if you ever need to use "git bisect" to find where something broke, a linear history is much easier to deal with.
However, some folks prefer to see the true history of development in the sense of "when so-and-so started this work, on which commit was it originally based?". In that case, merge preserves that information (as long as it wasn't a fast-forward -- but you can always force a merge commit with "git merge --no-ff").
In some cases, it makes sense to use both rebase and merge -- rebase for simpler changes and merge to incorporate long-lived topic-branches.
It pains me that the git man pages are so awful. Patches welcome (it is unfortunate that newbies provide the best perspective on how awful the docs are, while simultaneously are the least likely to be able to contribute improvements to them). Ultimately, git is actually based on some fairly simple concepts and I happen to think that once you have a conceptual understanding of it, all the commands (more or less…) start to make sense. So I strongly advocate trying to understand what the heck is going on under the hood.
That said, the Pro Git book is a much better place to start learning git than the git man pages.
Hope this helps.