在 Mercurial 中对一组提交进行分组？
我正在开发一个新功能分支。有必要保留所有历史记录，但对于以后搜索历史记录的人来说，其中大部分都过于冗长。
例如，我可能有 5 次提交，完成添加新数据库表、其业务逻辑、验证和一些我改变主意的实验等步骤。但对于共同开发人员来说，他们可能需要知道的是“这个已修复的错误 X”。
是否可以以某种方式对一组提交进行分组，以便在日志中显示概述，但仍然能够查看所有历史记录。不仅是我的本地存储库，还有远程存储库。
我猜我可以有单独的子分支，并在进行过程中将它们合并。但我只知道我想回顾性地对一组提交进行分组。所以我认为这不是一条好路线，因为我必须不断地来回走动。
我可以看到有一个群组扩展，但它没有维护。我对未维护插件的经验意味着我通常会采取错误的方式，并且可能有更好的技术。
是否有实现此类目标的最佳实践？
I'm working on a new feature branch. It's necessary to keep all the history, but for someone scouring over the history at a later date, much of it is over verbose.
For example I may have 5 commits taking through the steps of adding a new database table, its business logic, its validation and some experiments that I change my mind about etc etc. But for a co-developer all they might need to know is "this fixed bug X".
Is it possible to somehow group a set of commits, so that an overview is shown in the log but still being able to view all the history. Not only only my local repo, but the remote repo as well.
I'm guessing that I could have separate sub-branches and merge them as I go along. But I'll only know that I want to group a set of commit retrospectively. So I don't think that is a good route, as I'll have to keep going back and forth.
I can see that there is a group extension but it's unmaintained. And my experience with unmaintained plugins means that usually I'm going the wrong way about it and that there is a perhaps a better technique.
Is there any best practice around achieving this sort of thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论如何，当您说要保留所有历史记录时，我认为您走的是正确的路线。您可以使用MQ扩展将变更集折叠到单个提交中，但是 - 尽管这会给你一个“干净”的提交 - 你会失去所有有趣的细节。
我处理这个问题的方法是在分支或单独的克隆中进行开发，当它进入生产时，我在合并的提交消息中描述整组更改，即不要只使用“合并”进行提交信息 ：）。
我理解您关于只知道是否需要回顾性分组的观点，但我认为只要您对开发/测试/发布过程有一定的严格性，那么这不应该成为太大的限制。
For what it's worth, I think you're going down the correct route when you say you want to keep all of your history available. You could use the MQ extension to collapse your changesets into a single commit, but - although this would give you a 'clean' commit - you would lose all that juicy detail.
My way of handling this is to develop on a branch or in a separate clone, and when it's going into Production I describe the whole group of changes in the commit message of the merge, i.e. don't just use "Merge" for the commit message :).
I understand your point about only knowing if you need to group retrospectively, but I think as long as you have some rigour around your dev/test/release process then this shouldn't be too much of a limitation.
您需要 collapse 扩展。
You want the collapse extension.