Mercurial 工作流程 - 什么时候可以变基，什么时候应该合并？
我们在工作中使用 Mercurial 已有几个月了。我们对工作流程进行了几次修改，最终得到以下结果：
>快照正在暂存，然后我们将其克隆到中央存储库，每个人都在本地克隆该快照。
- 当我们处理功能/错误修复时，我们总是从暂存更新到最新的默认值，以便从最新的生产副本开始。
- 然后，我们将功能分支推送到中央存储库进行备份，使其可供团队使用等。
- 我们继续使用 QA 系统，拉出功能分支并将其合并到那里。
- 如果 QA 签核了该功能，我们会将其合并到同一台机器上的稳定分支中。
- 然后，我们将稳定分支拉到暂存区，将其合并到那里并进行摘要测试。
- 如果一切顺利，我们会将所有内容自动复制到实时系统。
这已经对我们有用了一段时间，但仍然有一些困难让我们继续前进：“嗯，也许有更好的方法，它感觉不太自然”。
我们遇到的最大问题是，当我们的本地计算机上有一个功能分支变旧时。
示例：
- 我的系统上有分支 62_EpicNewFeature。
- 优先级被重新组织，EpicNewFeature 的工作停止了:(
- 6 个月后，我终于恢复了 EpicNewFeature 的工作
此时，该分支远远落后于当前的默认值。如果我完成它并尝试在 QA 上合并它 /em> 我会遇到很多冲突（对于这些冲突，你几乎总是保留现在 QA 上的内容。）
我们有时会采取一些措施来缓解这个问题，即将默认值合并回 EpicNewFeature 中，以便将其引入这简化了我们在 QA 上的合并，但它通常仍然是一个本地合并，
我读过有关 rebase 的内容，这应该有助于使下一次合并快进（据我所知）。理解）在中间注入历史记录，改变你自己的历史记录，
我读到的大多数关于 rebase 的地方都会警告你不要这样做，如果你已经推送了你的分支，并且如果有人可能已经拉取了你的更改，则绝对不要这样做。你如何确定我们经常推送到中央存储库进行备份，并且通常只是拉取所有内容，
您是否看到一些可以帮助我们改进当前工作流程的内容？更频繁地变基会对我们有帮助吗？
We've been using Mercurial at work for a couple of months now. We've modified our workflow a few time and ended up with this:
The initital snapshot was on staging, we then cloned that onto our central repository and everyone cloned that locally.
- When we work on feature/bugfix we always update to the latest default from staging so that we start from the latest production copy.
- We then push the feature branch to a central repository for backup, making it available to team, etc.
- We go on our QA system and pull the feature branch and merge it there.
- If the QA signoff on the feature, we merge it into the stable branch on the same machine.
- We then pull the stable branch onto staging, merge it there and do summary testing.
- If all is well we robocopy everything to the live system.
This has worked for us for a while, but there's still rough spot that make us go: "mmmmh, maybe there's a better way, it doesn't quite feel natural".
The biggest issue we have is when we have a feature branch that grows old on our local machine.
Example:
- I have branch 62_EpicNewFeature on my system.
- Priorities got re-organized, work on EpicNewFeature stops :(
- 6 months after, I finally resume work on EpicNewFeature
At this point, that branch is way behind the current default. If I finish it and try to merge it on QA I'll get so many conflicts (for which you pretty much always keep what's on QA now.)
What we sometime do to mitigate this problem is we merge default back into EpicNewFeature so as to bring it "up-to-speed". This simplifies our merge on QA but it's still usually one heck of a local merge.
I've read about rebasing which is suppose to help making the next merge a fast-forward since you (from what I understand) inject the history in the middle, altering your own history.
Most place I've read about rebase warn you not to do it if you've already pushed your branches though, and definitely not if someone might have pulled your changes already. How can you make sure of that? we push often to the central repository for backup and we usually just hg pull everything.
Do you see something that would help us improve our current workflow? Would rebasing more often help us?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您误解了 rebase 的作用。它的工作原理是简单地合并到存储库的顶部，然后删除原始链接。这与进行“差异”并将其应用到提示上的操作几乎相同。
您仍然会遇到您试图避免的所有相同的合并冲突。
通常，处理这些冲突的最简单方法是零敲碎打。不要试图一口气合并到尖端。
I think you've misunderstood what rebasing does. It works by simply merging to the tip of your repository and then cutting away the original links. It's pretty much the same action as taking a "diff" and applying that to the tip.
You'll still get all the same merge conflicts you're trying to avoid.
Usually the easiest way to deal with these conflicts is piecemeal. Don't try to to merge up to the tip all in one go.