Our workflow is such. We have a branch called
dev which I can reach at
origin/dev. When we do changes, we create a branch off dev:
git checkout -b FixForBug origin/dev
Now I have a branch called
FixForBug which is tracking (I think that's the right word)
origin/dev. Thus, if I do a
git pull it'll bring in new changes from
origin/dev which is great. Now, when I'm finished with my fix, I push to a remote branch called the same thing.
First I pull down any changes from
origin/dev and do a rebase:
git pull --rebase
Then I push the changes to a remote branch of the same name:
git push origin FixForBug
Now, there's a branch on the remote server and I can create a pull request for that change to be approved and merged back in to the dev branch. I don't ever push anything to
origin/dev myself. I'm guessing this is as pretty common workflow.
The first time I do a
git push, it works fine and creates the remote branch. However, if I push a second time (let's say during code-review, someone points out a problem), I get the following error:
error: failed to push some refs to 'https://github.limeade.info/Limeade/product.git'
hint: Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.
See the 'Note about fast-forwards' in 'git push --help' for details.
However, if I do a
git status it says I'm ahead of
origin/dev by 1 commit (which makes sense) and if I follow the hint and run
git pull, it says everything is up to date. I think this is because I'm pushing to a different branch than my upstream branch. I can fix this issue by running:
git push -f origin FixForBug
In that case, it'll push the changes to the remote branch, saying (forced update) and everything appears to be good on the remote branch.
-f required in this scenario? Usually when you're forcing something, it's because you were doing something wrong or at least against standard practice. Am I ok doing this, or will it mess up something in the remote branch or create a hassle for whoever has to eventually merge my stuff into dev?
This question is tagged with
~ Asked on 2016-09-08 20:37:58
-f is actually required because of the rebase. Whenever you do a rebase you would need to do a force push because the remote branch cannot be fast-forwarded to your commit. You'd always want to make sure that you do a pull before pushing, but if you don't like to force push to master or dev for that matter, you can create a new branch to push to and then merge or make a PR.
~ Answered on 2016-09-08 21:47:01
the tip of your current branch is behind its remote counterpart means that there have been changes on the remote branch that you don’t have locally. and git tells you import new changes from
REMOTE and merge it with your code and then
push it to remote.
You can use this command to force changes to server with local repo ().
git push -f origin master
-f tag you will override
Remote Brach code with your code.
~ Answered on 2020-06-26 22:11:21