Mercurial 版本管理简单介绍。

1. Mercurial 版本管理工具介绍 By 杨小勇

3. 访问仓库是受到控制的

4. 所有的改变都必须提交到这个仓库里

5. 所有的接收的改变都是来自该仓库

6. 应用场所：要求仓库能受到控制

7. 软件：CVS, SVN 等

9. 任何人可以接受来自任何人的补丁

10. 任何人可以发送自己的补丁给任何人

11. 适用于多个功能并行开发的项目

12. 软件：Git，Mercurial，bzr

13. 分布式版本管理的图形模式

15. 谁在使用 Mercurial？

16. － Python.org，Mozilla，OpenOffice …

17. 项目托管网站

18. — bitbucket，google code，sourceForge …

19. 跨平台支持：Linux/Mac/Win

20. GUI工具支持： Linux – hgk, Win – TortiseHG

22. 不依赖网络

23. 能直接访问本地仓库

24. Merge是核心操作

26. 必须要有活动的网络

27. 通过网络访问慢

28. 避免merge操作

29. 只有一个地方放代码。

31. 做pull和push操作时必须先约定仓库位置

32. 没有简单的方法只检出仓库里某一部分代码

33. 只能追踪文件，所有空目录不会进入仓库

35. 每一个人都知道仓库在哪里

36. 检出仓库里的某一部分代码很容易

37. 允许空目录

38. Subversion是CVS里的领导者

40. 自带一个快速的http服务，在使用http传输上有更好的效率

41. 跨平台没的说

43. 命令参数有150多个选项，复杂

44. 使用http传输效率不高

45. 对于windows支持不好

46. 以修改历史记录为荣

48. － hg init

49. 加入新的文件

50. － hg add [FILE …]

51. 将文件移出版本库

52. － hg remove [FILE …]

53. 改名

55. － hg status [FILE...]

56. 查看文件变更

57. － hg diff [FILE...]

58. 查看更新记录

59. － hg log

60. － hg glog （图形化查看）

62. － hg commit [FILE …]

63. 取消修改

64. － hg revert [FILE …]

65. 返回最后一个版本（不可逆，危险操作！！！）

66. － hg rollback [FILE …]

68. － hg branch BRANCH_NAME

69. 在分支中切换

70. － hg update -r BRANCH_NAME

71. － 默认分支为 default

72. 列出所有的分支

73. － hg branches

75. － hg tag TAG_NAME

76. 在分支中切换

77. － hg update -r TAG_NAME

78. 列出标签

79. － hg tags

80. 版本库里的标签信息都保存在 .hgtags

81. 有一个特殊的标签 'tip'， 这个标签是浮动的，永远标识最新的版本

83. － hg serve

84. 克隆一个仓库

85. － hg clone EXISTS_REPO project

86. EXISTS_REPO的格式

87. － http[s]://server/project

88. － svn://server/path/to/project

89. － [ file://]/path/to/project

90. 推送你的修改

91. － hg push REMOTE

92. 取得别人的修改

93. － hg pull REMOTE

94. 更新当前的工作目录（同步仓库）

95. － hg checkout

96. Mericurial的版本命名规则

98. 根节点没有父节点

99. 一个改变集合里没有子节点就是 " 头 "

100. 一般的提交只有一个父节点

101. Merge 就会有二个父节点

102. 分支的名字是被它的父节点所决定的

103. Merge 只发生在你自己本地的仓库里

104. Merge 合并 合并前

105. 合并中 执行 hg pull 后，本地的版本里多出一个 head 6:d2b5

106. 合并后

108. － vimdiff, kdiff3,

109. 在自己的 .hgrc 里配置

110. － merge = vimdiff

114. 每个开发者pull和push到origin，但除了中心化的push-pull关系外，每个开发者还可以从其他开发者那pull changes

116. － master

117. － develop

118. origin/master 作为主要分支

119. origin/develop 上的代码是为下一次的代码发布准备的

120. 当 develop 分支达到了一个稳定状态并准备发布时，所有的改变都要合并到 master 分支，并标上版本号

122. 这些分支是有时间限定的，因为它们最终会被删除

123. 会使用到的分支

124. － Feature branches

125. － Release branches

126. － Hotfix branches

128. 合并分支：develop

129. 命名规范：除了master,develop,release-,hotfix-

130. Feature branches是用来开发新特性的(短期，远期都可以)。当开始开发新特性时，很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到develop，当然如果开发失败，就可以抛弃。

132. 合并分支：develop 和 master

133. 命名规范：release-*

134. Release branch 是为新的production release准备的(相当于RC版)，可以有一些小的bug，并为发布准备一些元数据(版本号，构建日期等等)。把所有的这些工作都放到 Release branch，develop branch就能更清晰地知道下一个版本要开发哪些特性。

135. 从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版本号。

137. 合并分支：develop 和 master

138. 命名规范：hotfix-*

139. Hotfix branch和Release branch有几分相似，都是为了新的production release而准备的。比如运行过程中发现了bug，就必须快速解决，这时就可以创建一个Hotfix branch，解决完后合并到master分支上。好处是开发人员可以继续工作，有专人来负责搞定这个bug。