the correct way of git rebase

for make a rebase normaly I make

$ git checkout branchA
$ git rebase master 
$ git checkout master 
$ git merge branchA

ok.

my problem is with my fork from other repo, I add three commits and when I make

git pull --rebase otherRepo master 

get otherRepo commits and my commits go to HEAD of log, but when I try push

 ! [rejected]        HEAD -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:juanpabloaj/homebrew.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

with

 $ git push --force 

I can pu开发者_开发知识库sh my commits to my remote repo, but every time of pull is same thing,

which is the correct way to do it?

git fetch otherRepo master
gitk --all

Do this and you'll be able to see the exact state of otherRepo/master. This will help you figure out what's going on. git fetch updates your view of otherRepo/master (so you can see its most recent state) but doesn't merge it with anything.

Your problem is here:

git pull --rebase otherRepo master 

When you use git pull --rebase, your local commits on master are replayed on top of the new commits in the otherRepo's master. As a consequence of this, when you push to your origin, this becomes a non-fast-forward push (see here for an explaination of fast-forward merges). And so git disallows this by default.

The solution is simple, don't use --rebase with git pull when pulling from otherRepo:

git pull otherRepo master

If you pull from a repo, then immediately try to push, and it fails with "non-fast-forward", then something else is going on. Maybe somebody else has pushed commits, or else maybe you're not pulling/pushing what you think you are. By forcing the push to proceed, you're destroying history, and unless you're perfectly clear about what you're doing, you might be losing work without realizing it.