git - Git rebase 到远程分支并保留历史记录

Question

我们有这个问题可能由merge工作流引发，因此我们正在考虑使用rebase工作流。

一个问题是rebase远程存储库会导致历史记录的重写。但我认为这可以通过

1. 在要变基的分支上标记一个tag（可以是时间戳的名称）branch_rebaseXXXXXXXXXXXXXXXX
2. 推tag
3. 申请rebase
4. 推

Git 可能会阻止您rebase远程操作，即使您按照上述方法保存历史记录也是如此。除了git push --forcehack，我们可以做

1. branch_new在上面创建一个新分支branch
2. 如上标记一个标签
3. 重新设置新分支
4. 推送新分支和标签
5. 删除旧的本地和远程branch
6. 重命名branch_new为branch
7. 推送分支名称变更

当应用这种方法并且rebase不merge严格从一开始就使用时，虽然生成的提交历史不会是线性的，但由于不会有合并，它将有效地形成一个树状图，其中每个叶节点都是活动节点的尖端分支，或由标签标记。就个人而言，我将这些标签称为“墓碑”。

由于上述方法尚未在实践中使用，这种方法的优缺点是什么？特别是，如果有人检查了一个分支，在它上面工作，然后另一个人在那个分支上标记了一块墓碑，会发生什么？

Answer 1

我最近遇到了一种情况，有人以不好的方式放弃了整个历史记录，push --force所以我不热衷于您的解决方法。

好的，无论出于何种原因，您都希望您的官方历史是线性的。但是您仍然希望某些工作分支具有完全的可见性。

你想要一个pu分支。

“待更新”分支会不断地重新调整基础，您在远程配置中输入该分支将始终被强制推送。在服务器上，如果不是快进推送，您可以选择添加脚本来创建引用（可能标签可能既不是标签也不是分支）。每个用户（或组）都需要自己的pu分支。

主分支仅使用快进更新，并且仅使用普通提交，没有合并。

有人（待定）在请求时接受提交，并将它们（樱桃采摘？）添加到主分支上。此人不进行合并，合并（实际上它将修复变基）发生在pu不在此处的分支上。

有人也可以做其他事情……测试。如果测试成功，他们会将补丁添加到他们自己的“测试”分支中，master 将被快速转发。如果测试失败，则测试分支被一分为二，并且在重新测试之前将坏补丁（或补丁）返回给发件人。

关于自动创建的引用，git 确实可以很好地处理大量引用，但是（对我而言）这些引用确实有很短的到期时间。只需打开服务器上的 reflog 就足够了。OTOH，如果您确实想将它们永远保留merge -s ours在分支上，那么无需其他参考即可work-history令人印象深刻。log --graph

您可能会觉得您只想摆脱服务器脚本并让用户重新设置主控。我的问题是你需要一个固定点，以某种方式说“现在在官方历史中，你不能改变它”。没有它，您的开发人员最终可能会更改已离开您控制的提交（转到生产或客户）。推动掌握就是那个标志。