2

I found an article talking about git's workflow here, And tried to apply it to my own hg project, seems that it's kind of mess when I create a branch for each feature, cause in git, the branch could be deleted, and in hg, it can only be closed. so this will lead to a huge amount of closed branches in the repo, and that's what I don't want to see.

later, I googled another article which talks about a Hg workflow here I tried it, and it seems good when I am the only developer of the project, but when I tried to add another developer, the history became a little complicated.

I tested this with three repos

1, Base
2, devA   ---> stands for developer A's repo
3, devB   ---> stands for developer B's repo

first I worked on devA, making changes on devA's default branch, and bugfix's on devA's stable branch. After that, I push devA to Base.

devA's graph:

devA's graph

in case the image broken, the text based graph is here:

@    summary:     Merge with stable
|\   tag:         tip
| |  parent:      4:d2973e149720
| |  parent:      5:3788143e99fc
| |  date:        Mon Jul 30 13:17:44 2012 +0800
| |  
| |
| o  changeset:   5:3788143e99fc
| |  branch:      stable
| |  parent:      3:4a955d01ea44
| |  date:        Mon Jul 30 13:17:19 2012 +0800
| |  summary:     fix a bug in featureA
| |
o |  changeset:   4:d2973e149720
| |  parent:      2:8e106fcfa9bf
| |  date:        Mon Jul 30 13:16:46 2012 +0800
| |  summary:     finish featureA advance
| |
| o  changeset:   3:4a955d01ea44
|/|  branch:      stable
| |  parent:      1:7b81b986d485
| |  parent:      2:8e106fcfa9bf
| |  date:        Mon Jul 30 13:16:01 2012 +0800
| |  summary:     Merge with default
| |
o |  changeset:   2:8e106fcfa9bf
| |  parent:      0:7d7dc422ec7c
| |  date:        Mon Jul 30 13:15:43 2012 +0800
| |  summary:     finish feature A
| |
| o  changeset:   1:7b81b986d485
|/   branch:      stable
|    date:        Mon Jul 30 13:14:49 2012 +0800
|    summary:     Create stable branch
|
o  changeset:   0:7d7dc422ec7c
   date:        Mon Jul 30 13:14:21 2012 +0800
   summary:     Init commit

and then I switched to devB, because I want to emulate a parallel work, so I did not pull from Base, instead I begin to work on devB's default branch, and do bugfix on devB's stable branch.

devB's graph is similar with devA's graph

Here comes the problem, when I try to push devB's changes to Base, it said there is a conflict, and I need to merge it locally, I pulled the changes and then my history graph in devB became kind of messy because I got devA's default and stable so in devB there is now two default branches and two stable branches.

what confused me is how real projects use this kind of workflow, mecurial's branch graph is here. It seems pretty clean, but how did they do this?

4

2 回答 2

1

不要将存储库拆分为“开发人员分支”，而是分支“功能分支”。每个分支都应该有相当少量的提交，全部用于实现特定功能。在每个构建/发布时，您选择准备部署的分支并将它们合并为默认值。

于 2012-07-30T05:38:54.027 回答
0

最新的hgflow（0.9.5，尚未正式发布，但效果很好）实际上允许您完全删除功能分支。摘自其维基：

为完成操作添加了 --erase。使用此选项，您可以在分支成功完成后擦除（即从存储库中完全删除）分支。最终效果就像分支中的所有更改都被折叠，然后作为单个更改集提交到分支合并到的目标分支。查看 hg flow help @finish 了解更多详细信息。

于 2012-10-26T20:10:15.260 回答