merge工作流可以提出this problem，因此我们正在考虑使用rebase工作流程。
一个问题是远程存储库上的rebase会导致重写历史记录。但我认为这可以通过
tag（可以是名称branch_rebaseXXXXXXXX，其中XXXXXXXX是时间戳）tag rebase Git可能会阻止您在远程执行rebase，即使您按照上述步骤保留历史记录也是如此。而不是git push --force黑客，我们可以做
branch_new branch
branch branch_new重命名为branch 应用此方法并且从开始时仅严格使用rebase而非merge，虽然生成的提交历史记录不是线性的，但由于没有合并，它将有效地形成树 - 如图，其中每个叶节点是活动分支的尖端，或由标记标记。我个人称这些标签为“墓碑”。
由于上述方法尚未在实践中使用，这种方法的优缺点是什么？特别是，如果某人检查了一个分支，正在处理它，然后另一个人在该分支上标记了墓碑，会发生什么？
答案 0 :(得分：1)
我最近有一种情况，有人因为push --force而拒绝整个历史记录，所以我不热衷于你的解决方法。
好的，对于whatever reason，您希望您的官方历史记录是线性的。但是你仍然希望对一些工作分支机构有充分的了解。
您需要pu分支。
A＆＃34;待更新＆＃34;分支机构不断重新进行重新设置，你进入远程配置，这个分支将永远被强制推送。在服务器上，如果不是快进推送，您可以选择添加脚本来创建引用（也许标签可能既不是标签也不是分支）。每个用户（或组）都需要自己的pu分支。
主分支仅通过快进进行更新，并且仅使用普通提交，不进行合并。
有人（待定）在请求时接受提交，并将它们（樱桃选择＆＃39; d？）添加到主分支上。这个人不进行合并，合并（实际上它将修复rebase）发生在pu分支上，而不是在这里。
某人也可以做其他事情...... 测试。他们将补丁添加到他们自己的＆＃34;测试＆＃34;如果测试成功，则分支快速转发。如果测试失败，测试分支将被分成两部分，并在重新测试之前将错误的补丁（或补丁）返回给发件人。
关于自动创建的引用，git确实可以很好地处理大量的引用，但这些（对我来说）看起来似乎有一个很短的到期时间。只需打开服务器上的reflog即可。 OTOH如果你想永远保留它们merge -s ours到work-history分支，那将会令人印象深刻log --graph而不需要其他参考。
您可能觉得自己想要只使用服务器脚本并让用户使用rebase master。我的问题在于你需要一个固定点，某种方式可以说'＃34;现在在官方历史中，你不能改变它＆＃34;。没有它，您的开发人员可能最终会更改已经离开您控制权的提交（转到生产或客户）。掌握的是那个标记。