我一直遵循的规则是，一旦 git 历史记录被推送到远程存储库，就不再修改它。
但我想知道交互式变基到推送 --force-with-lease 是否绕过了这条规则？
如果强制租约成功，对其他用户来说是否完全安全？或者此策略有任何注意事项吗？
预先感谢您的任何意见。
我想描述一个看似合理的案例--force-with-lease并不能避免您覆盖同事的工作。
一切都从鲍勃开始
在签出最新的主分支时执行以下操作：
# Creating a new branch called feature/one
$ git checkout -b feature/one
# Do some changes and git add ...
$ git commit
# Push for the first time
$ git push --set-upstream origin feature/one
# Checkout another branch to work on something else
Bob 机器上的情况
...--F--G--H <-- master (HEAD)
\
o--o <-- feature/one
爱丽丝继续
Alice 接手了 feature/one 的工作，并在 Bob 的工作之上提交了一些内容，并推动了她的更改，这意味着
一些不相关的拉取请求被合并到主分支的时间。
Alice 的工作树是什么样子的
...--F--G--H--I--J <-- master (HEAD)
\
o--o--x--x <-- feature/one
鲍勃继续
Bob 的任务是在当前主分支上重新调整 Alice 的工作，并执行以下操作
-
git pull当他在 master 分支上时，这基本上是一个git fetch and a git merge此步骤的后果稍后很重要。
Bob机器上的情况：
...--F--G--H--I--J <-- master (HEAD)
\
o--o <-- feature/one
...--F--G--H--I--J <-- origin/master (HEAD)
\
o--o--x--x <-- origin/feature/one
Bob 的机器现在包含一个最新的遥控器，但 origin/feature/one 中的更改尚未合并到
特征/一。
鲍勃检查分支git checkout feature/one
- 鲍勃忘记做一个
git pull
-
Bob 在 master 上重新建立了他的本地分支git rebase -i origin/master
bobs 机器上的情况如下所示：
...--F--G--H--I--J <-- master (HEAD)
\
o--o <-- feature/one
-
鲍勃认为他成功地重新调整了他的分支并强制推送feature/one to origin/feature/one， 因为
鲍勃是个好人，他努力推动git push --force-with-lease origin feature/one并期望该选项--force-with-lease如果他要覆盖其他人的工作，将阻止他的推送操作。但这个选择并不能拯救他，如果我理解的话这篇博文 https://blog.developer.atlassian.com/force-with-lease/正确地，--force-with-lease没有看到
Bob 机器上的 origin/feature/one 与实际的 origin/feature/one 之间的差异，因此假设
如果强制推送到鲍勃的工作树，则不会覆盖遥控器上的任何内容。缺乏的原因
的区别在于隐式的执行git fetch作为...的一部分git pull早些时候（在此步骤 1 中
部分）在不同的分支上。
推送后，遥控器会是这样的
...--F--G--H--I--J <-- master (HEAD)
\
o--o <-- feature/one
代替
...--F--G--H--I--J <-- master (HEAD)
\
o--o--x--x <-- feature/one
这是上面链接的博客文章的相关部分：
提取将从远程提取对象和引用，但如果没有匹配的合并，则不会更新工作
树。这将使遥控器的工作副本看起来好像是最新的，而实际上却没有
包括新作，还有trick--force-with-lease覆盖远程分支
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
