在https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_peril
中建议在存储库公开时不要进行重新定位。
中的帖子建议不要在开发人员之间共享的分支上完成rebase。
我理解，因为开发人员可能首先合并代码，然后他决定重新设置代码，其他开发人员最终可能会创建多个重复提交，如重新定位的Perils中所述。
如果所有开发人员达成一项共识协议，即每个人都会总是将代码重新绑定而不是合并，那该怎么办？该建议是否仍适用？
P.S
所有这些答案让我感到困惑。我想我会再次重新提出这个问题。
我们假设有两个开发人员在两台不同的计算机上工作。有一个中央存储库。两位开发人员克隆并开始工作。
开发者1：
开发者2：
开发者1：
开发者2：
等等。始终是开发人员1＆amp; 2将使用origin / branch重新绑定其分支，然后将其更改推送到origin / branch
功能稳定后，最后
开发者1：
开发者2：
稍后循环再次继续。
这是对的吗？当两个开发人员在同一个分支上工作并且总是希望改变而不是合并时，这是正确的方法吗？
答案 0 :(得分：1)
让我们假设没有人进行交互式变基，改变历史，而只是做git fetch然后git rebase origin/branch。在那种情况下，你可以做一个推动，如果没有其他人推动他们最近的rebase，否则你会得到冲突，并且还要再次变基。重要的是，每个人都在努力进行变基，从不做push -f，因为这会给下游的每个人带来麻烦。
这个问题，是你想要这样做的原因。如果目标只是避免合并提交，那么最好使用这样的工作流程：
这样每个人总是将他们的工作作为线性提交提交到公共分支之上。
注意：保留原始回复，但根据更新的问题添加更多信息。
基本上，我的建议是，local/iss123工作的开发人员在通过git pull来回转换时，会继续合并彼此的更改。一旦iss123稳定，其中一个开发人员就会将其重新命名为master，即
git checkout iss123
git checkout -b rebase_iss123
git rebase -i master
// select first as edit (so you can change its commit message)
// and select the rest as fixup
git checkout master
git merge rebase_iss123
这将占用所有iss123并将其压缩到master的尾部的单个提交中。
现在，开发人员可以分支该主人的新问题工作。
答案 1 :(得分：0)
将代码推送到公共存储库后，不会对提交进行任何更改。但是当你在本地存储库上重新定位时，就会发现推送。 例： 我在功能分支上进行了更改。然后我从我的功能分支的父分支拉，通常开发分支。然后，我可以在开发时修改我的功能分支。然后我可以将我的开发分支推到原点。
因此，如果所有的开发人员都在他们的本地回购上进行变基，然后重新推出，那么就可以了。
重点是，一旦在公共回购中共享提交或分支，没有人可以更改做一个rebase或修改评论等。