这是一种避免在git拉入时分支出分支的方法吗？

Question

我和我的朋友提交了意见，然后我推动了我的改变，他也尝试了推动，但GitLab拒绝了，这很好，

​

​

但他随后拉出了更改，并在图形中显示了“分支出”和“分支入”。这是避免这种现象并迫使他改变他的改变的一种方式吗？

dev-3在GitLab中受到保护。

​

​

​

​

Answer 1

这里有几个不同的问题。

如果你想让你的长期历史看起来是“线性的”(即没有分支/合并)，那么正如你所提到的，你可以使用rebase。在这种情况下，如果您为了能够推送而拉动，则需要拉动来重新建立基址，而不是合并更改。你可以用git pull -r做到这一点。(也可以在默认情况下将本地存储库配置为这样做，但如果您想要考虑这一点，请参考git配置文档；这被认为是一种潜在的风险配置。)

您还问到是否可以“强制”其他开发人员重新设置其更改的基数。作为一般规则，我会重新考虑“强制”这样或那样的行为的心态，但在任何情况下，如果团队只想执行rebase-only，可以在远程repo中完成。对于git，通常你会使用一个预接收钩子，它会拒绝不“遵循规则”的推送。用于托管回购(github、gitlab等)您可能无法直接访问服务器端挂钩，因此您必须参考这些服务的文档。

(请注意，“当开发人员尝试推送时”是一个相当晚的时间来发现问题，因为开发人员可能意外地违反了规则，并基于错误的一大堆工作。为了缓解这种情况，可以使用预提交钩子配置本地存储库，该钩子在提交时执行相同的规则。但是客户端钩子配置不能“强制”，这就是您从服务器端钩子开始的原因。)

另一个考虑因素是，这是否真的是正确的优先级。重新设定基数是有代价的。许多人/团队确实认为越线性的历史越重要，但这至少是团队应该考虑的问题。(最大的代价是，如果您经常重新备份工作，除非您在重新建立基础之后重新提交每个提交，否则您不能假设每个提交都经过测试/通过。)

Answer 2

我之前在2015年5月用"Can “git pull” automatically stash and pop pending changes?“记录了如何在本地配置你的Git，以便git拉到rebase：

git config --global pull.rebase true
git config --global rebase.autoStash true

这意味着它是客户端的本地配置，而不是服务器端的GitLab设置。

这将(用一个简单的git pull)在origin/dev3之上重放他们自己的#123提交。