是否可以将各个变更集重新设置为历史上较早的时间点？
这是我们的树现在的样子：
@ branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
o branch: default
| bug fix C
|
|
o branch: default
| bug fix B
|
|
o branch: default
| new feature work
|
|
o branch: default
| bug fix A
|
|
o branch: default
| tag: ReleaseV1.0
|
|
... ancient history
这是我希望我们的树的样子：
@ branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
|
| o branch: V1.1Fixes
| | bug fix C
| |
| |
| o branch: V1.1Fixes
| | bug fix B
| |
| |
| |
| o branch: V1.1Fixes
| | bug fix A
| |
|/
o branch: default
| tag: ReleaseV1.0
|
|
... ancient history
这可能吗？
Here's what our tree looks like right now:
@ branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
o branch: default
| bug fix C
|
|
o branch: default
| bug fix B
|
|
o branch: default
| new feature work
|
|
o branch: default
| bug fix A
|
|
o branch: default
| tag: ReleaseV1.0
|
|
... ancient history
Here's what I'd like our tree to look like:
@ branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
o branch: default
| new feature work
|
|
|
| o branch: V1.1Fixes
| | bug fix C
| |
| |
| o branch: V1.1Fixes
| | bug fix B
| |
| |
| |
| o branch: V1.1Fixes
| | bug fix A
| |
|/
o branch: default
| tag: ReleaseV1.0
|
|
... ancient history
Is this possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在这种情况下，我将使用
transplant扩展。移植的变更集不会移入fixes分支，而是保留在开发（default）分支中。我不太猜测那些“新功能工作”提交是什么，但我闻到你正在尝试移植。如果不删除“新功能工作”提交，历史记录图将如下所示：
如果这些“新功能工作”提交只是虚拟标志提交以保留开发树中的更改，则您不再需要它们了
移植。我保留它们，就好像它们是一些开发后文档、变更日志更新……In this case, I would use the
transplantextension. Transplanted changesets don't move in thefixesbranch but also stay in the development (default) branch. I don't really guess what are those "new feature work" commits, but I smell that you are trying totransplant.Not removing your "new feature work" commits, the history graph would look like that:
If those "new feature work" commit are just dummy flag-commits to retain the changes in the development tree, you don't need them anymore if you
transplant. I kept them as if they were some after-development documentation, changelog update,...查看 RebaseProject 和 变基扩展。您还可以使用移植扩展将补丁从一个分支应用到一个或多个其他分支（以得到类似于 Django 历史记录的内容）。
Take a look at RebaseProject and Rebase Extension. You may also use Transplant Extension to apply a patch from a branch to one or more other braches (to get something similar to what Django history looks).
是的，这是可能的（只要新功能不依赖于错误修复变更集所做的更改），但不建议这样做。
通过在 MQ 中导入变更集，直至标记 ReleaseV1.0，然后在正确的分支上重新提交，可以很容易地实现这一点。
但是，请记住，这样做会更改历史记录，这意味着这些变更集的所有哈希都将被修改，这意味着您将搞砸所有已经拉取最新更改的用户。
Yes, it is possible (as long as the new features does not depends on changes made on bug fix changesets), but it is not recommended.
This can be quite easily achieved by importing your changesets in MQ, up to tag ReleaseV1.0 and then re-commit then on the correct branch.
However, keep in mind that doing so, you'll change the history, which means that all the hashes of these changesets will be modified, which means that you'll screw all the users that have already pulled your latest changes.