What LasseV. Karlsen said is all right. Since he rebased the branch, you can't really pull it and remerge everything.
If you have no more "new" commits, just remove the branch you're trying to pull and pull it. Since all your changeset are present, just reset your branch to be exactly like the one on the server and continue from there. If you have new commits then it will be a bit harder.
First create a copy of your branch:
git checkout [branch]
git checkout -b branchCopy
Delete the branch (use -f if it doesn't want to delete it because of unmerged)
git checkout -d branch
Fetch what's on the server (origin could be a different remote) and recreate the branch with what's on the server
git fetch [origin]
git checkout origin/branch
git checkout -b branch
Now you'll have
Using git log, check which commits you want to add to your branch. and use
cherry-pick to add them
git checkout branch
git cherry-pick "commit"
Once all the unmerged commits are added, just push to the server. and delete the "branchCopy"
If you have a lot of diverging changesets between branchCopy and branch. I guess there is a way to rebase a set of commits from
branch but If you just rebase it. It will add every changes because copied commits have a different hash.
So yes, don't rebase unless you know what you're doing. If you want to rebase and work with many people. The best thing to do is to make sure everyone is aware that you're rebasing.
I guess the first rule for any good time traveler is "Don't change history"
Here's a tip to make time traveling safer than ever. At work, I used that flow:
Work on my feature branch and merge in master when its done.
When you're working on your branch, it almost assure you that you won't rebase commits that are present on the master branch. When done, you have to choices. You can merge your branch in master or rebase your branch on master.
If you're rebasing your branch, you'll have to fetch the last master commit and rebase on it and push it as fast as you can. When people will pull it, it should be still fast forward because you didn't change the history of master but the history of your branch.
But to be honest, after using bitbucket, (can't say much about github). I worked with pull requests. It does a merge commit even though the branches are fastforward it might be just easier to just avoid rebasing most of the time. Pullrequest is a wonderful creation that should be used if you use a system that has it.
It might create a merge commit, but it leaves an history of the commits that were merged, by who and you can comment them. People can work on features to be merged and someone may used the pull request to review code when needed and merge the code into master.