例如,如果我通过 ssh将存储库克隆A
到其他远程位置 ( ),在 中编辑,提交,然后执行B
B
git push A
当我回到 时A
,我看到它现在是最新推送的修订版,但它也有一些变化 -B
实际上与 中的提交直接相反。我通常通过使用来解决它
git checkout -f master
但是“-f”标志让我感到紧张——例如,可能会有一些有用的更改上演,我在执行此结帐时不小心丢弃了这些更改。
我究竟做错了什么?有没有更好的推送/更新方法?
例如,如果我通过 ssh将存储库克隆A
到其他远程位置 ( ),在 中编辑,提交,然后执行B
B
git push A
当我回到 时A
,我看到它现在是最新推送的修订版,但它也有一些变化 -B
实际上与 中的提交直接相反。我通常通过使用来解决它
git checkout -f master
但是“-f”标志让我感到紧张——例如,可能会有一些有用的更改上演,我在执行此结帐时不小心丢弃了这些更改。
我究竟做错了什么?有没有更好的推送/更新方法?
我认为根本问题是您正在git push
访问一个具有签出工作副本的非裸存储库。我很惊讶git
并没有为此抱怨,但也许你有一个旧版本git
或者你已经配置它不抱怨。git push
将更新远程存储库,但不会更新远程工作副本,因此当您再查看时A
,工作副本内容对应于以前的某个修订,而存储库已更新。显然,两者之间存在差异。在这种情况下git checkout -f
,可能是您最好的选择(或git reset --hard HEAD
),然后将您的A
存储库转换为裸存储库。
预期的命令将是“git pull”而不是“git checkout”
如果您有未提交的更改,您应该这样做。这将保存您所做的更改并获得新的更新。最后重新应用您最初保存的更改。
git stash
git pull
git stash pop
如果您有尚未推送的本地提交,您可以这样做。这将回退您的更改,应用推送的内容并重新应用提交。
git pull --rebase
您可以只对提交执行“git pull”,但这会添加一个合并提交,在我看来这会弄脏历史并可能导致一些问题。
由于您所说的原因,我通常不喜欢 -force 选项。你不想失去任何有用的东西。