我和我的朋友提交了，然后我推送了我的更改，他也尝试了推送，但 GitLab 拒绝了，这很好，
但他随后提取了更改，并且图表中显示了“分支出”和“分支入”。这是一种避免这种现象并迫使他重新调整他的更改的方法吗？
dev-3 在GitLab 中受到保护。
【问题讨论】：
这里有几个不同的问题...
如果您希望您的长期历史看起来“线性”（即没有分支/合并），那么正如您所注意到的，您将使用 rebase。在这种情况下，如果您正在拉动以便能够推送，则需要拉动来重新设置基准而不是合并更改。你可以通过git pull -r 做到这一点。 （也可以将本地 repo 配置为默认执行此操作，但如果您想考虑这一点，请参阅 git config 文档；它被认为是一个潜在的风险配置。）
您还询问是否可以“强制”其他开发人员重新调整他们的更改。作为一般规则，我会重新考虑“强制”一种行为或另一种行为的心态，但无论如何，如果团队想要强制执行 rebase-only，可以在远程仓库中完成。一般来说，使用 git 你会使用一个 pre-receive 钩子，它会拒绝不“遵守规则”的推送。对于托管存储库（github、gitlab 等），您可能无法直接访问服务器端挂钩，因此您必须参考这些服务的文档。
（请注意，“当开发人员尝试推送时”是一个很晚的时间来发现问题，因为开发人员可能不小心违反了规则并基于错误进行了大量工作。为了缓解这种情况，本地 repo可以配置一个预提交钩子，在提交时强制执行相同的规则。但是客户端钩子配置不能“强制”，这就是你从服务器端钩子开始的原因。）
另一个考虑因素是这是否真的是正确的优先事项。重新定位是有成本的。许多人/团队确实认为历史越线性越重要，但这至少是团队应该考虑的事情。 （最大的代价是，如果你经常 rebae 工作，除非你在 rebase 之后重新测试每个提交，否则你不能假设每个提交都经过测试/通过。）
【讨论】：
我之前在 2015 年 5 月用“Can “git pull” automatically stash and pop pending changes?”记录了如何在本地配置您的 Git 以使 git pull 变基：
git config --global pull.rebase true
git config --global rebase.autoStash true
这意味着它是客户端的本地配置，而不是服务器端的 GitLab 设置。
这将在origin/dev3 之上重放（使用简单的git pull）他们自己的#123 提交。
【讨论】：