我们的工作流程如下。我们有一个名为dev
的分支,在origin/dev
处可以访问它。当我们进行更改时,我们会从dev创建一个分支:
git checkout -b FixForBug origin/dev
现在我有一个名为FixForBug
的分支,它正在跟踪(我认为这是正确的词语)origin/dev
。 因此,如果我执行git pull
,它将从origin/dev
引入新的更改,非常棒。 现在,当我完成我的修复后,我将其推送到同名的远程分支。
首先,我从origin/dev
下载任何更改,并进行变基:
git pull --rebase
然后我将更改推送到同名的远程分支:
git push origin FixForBug
现在,远程服务器上有一个分支,我可以创建一个拉取请求来批准并合并该更改到dev分支中。我从不自己推送任何东西到
origin/dev
。我猜这是一个很常见的工作流程。第一次进行
git push
时,它能够正常工作并创建远程分支。但是,如果我第二次推送(比如在代码审核期间,有人指出了问题),我会收到以下错误信息:“error: failed to push some refs to 'https://github.mydomain.info/Product/product.git' Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. git pull ...) before pushing again. See the 'Note about fast-forwards' in 'git push --help' for details.”
但是,如果我运行
git status
,它说我比origin/dev
多了1个提交(这是有道理的),如果我遵循提示并运行git pull
,它会说一切都是最新的。 我认为这是因为我将更改推送到与上游分支不同的分支。 我可以通过运行以下命令来解决此问题:
git push -f origin FixForBug
在这种情况下,它会将更改推送到远程分支,显示(forced update),并且在远程分支上一切似乎都很好。我的问题是:在这种情况下,为什么需要使用
-f
?通常情况下,当您强制某些内容时,是因为您做错了事情或者至少是违反标准惯例。 这样做是否正确,或者它会搞乱远程分支中的某些东西,或者为最终将我的东西合并到dev中的人创建麻烦?
git pull origin FixForBug
对吗?好的,这很有道理。你可以将其作为一个答案添加! - Mike Christensen