Your SlideShare is downloading. ×
0
Mercurial  版本管理工具介绍 By  杨小勇
版本管理的类型-集中式 <ul><li>只有一个仓库
访问仓库是受到控制的
所有的改变都必须提交到这个仓库里
所有的接收的改变都是来自该仓库
应用场所:要求仓库能受到控制
软件:CVS, SVN 等 </li></ul>
版本管理的类型-分布式 <ul><li>每一个检出都是完整的仓库
任何人可以接受来自任何人的补丁
任何人可以发送自己的补丁给任何人
适用于多个功能并行开发的项目
软件:Git,Mercurial,bzr </li></ul>
分布式版本管理的图形模式
Mercurial Hg 汞 <ul><li>Mercurial 最初也是为了linux内核而开发
谁在使用 Mercurial?
- Python.org,Mozilla,OpenOffice …
项目托管网站
— bitbucket,google code,sourceForge …
跨平台支持:Linux/Mac/Win
GUI工具支持: Linux – hgk, Win – TortiseHG </li></ul>
和Subversion的比较1 Mercurial 优点 <ul><li>拥有自己的本地仓库
不依赖网络
能直接访问本地仓库
Merge是核心操作
每一个checkout都是一个冗余的拷贝 </li></ul>Subversion 的缺点 <ul><li>必须要共享一个仓库
必须要有活动的网络
通过网络访问慢
避免merge操作
Upcoming SlideShare
Loading in...5
×

Mecurial hg

1,749

Published on

Mercurial 版本管理简单介绍。

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,749
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 为什么Subversion对于merge的支持很糟糕 #1 : 当有冲突时,你会被强制合并到一个未保存的工作目录的拷贝下 #2:当没有冲突发生时,你不能强制merge
  • Transcript of "Mecurial hg"

    1. 1. Mercurial 版本管理工具介绍 By 杨小勇
    2. 2. 版本管理的类型-集中式 <ul><li>只有一个仓库
    3. 3. 访问仓库是受到控制的
    4. 4. 所有的改变都必须提交到这个仓库里
    5. 5. 所有的接收的改变都是来自该仓库
    6. 6. 应用场所:要求仓库能受到控制
    7. 7. 软件:CVS, SVN 等 </li></ul>
    8. 8. 版本管理的类型-分布式 <ul><li>每一个检出都是完整的仓库
    9. 9. 任何人可以接受来自任何人的补丁
    10. 10. 任何人可以发送自己的补丁给任何人
    11. 11. 适用于多个功能并行开发的项目
    12. 12. 软件:Git,Mercurial,bzr </li></ul>
    13. 13. 分布式版本管理的图形模式
    14. 14. Mercurial Hg 汞 <ul><li>Mercurial 最初也是为了linux内核而开发
    15. 15. 谁在使用 Mercurial?
    16. 16. - Python.org,Mozilla,OpenOffice …
    17. 17. 项目托管网站
    18. 18. — bitbucket,google code,sourceForge …
    19. 19. 跨平台支持:Linux/Mac/Win
    20. 20. GUI工具支持: Linux – hgk, Win – TortiseHG </li></ul>
    21. 21. 和Subversion的比较1 Mercurial 优点 <ul><li>拥有自己的本地仓库
    22. 22. 不依赖网络
    23. 23. 能直接访问本地仓库
    24. 24. Merge是核心操作
    25. 25. 每一个checkout都是一个冗余的拷贝 </li></ul>Subversion 的缺点 <ul><li>必须要共享一个仓库
    26. 26. 必须要有活动的网络
    27. 27. 通过网络访问慢
    28. 28. 避免merge操作
    29. 29. 只有一个地方放代码。 </li></ul>
    30. 30. Mercurial 和 Subversion的比较2 Mercruial的不足 <ul><li>没有为二进制文件做优化
    31. 31. 做pull和push操作时必须先约定仓库位置
    32. 32. 没有简单的方法只检出仓库里某一部分代码
    33. 33. 只能追踪文件,所有空目录不会进入仓库
    34. 34. 在 DVS里总有人争论git和hg谁是王者 </li></ul>Subversion的优点 <ul><li>适合大量的二进制文件
    35. 35. 每一个人都知道仓库在哪里
    36. 36. 检出仓库里的某一部分代码很容易
    37. 37. 允许空目录
    38. 38. Subversion是CVS里的领导者 </li></ul>
    39. 39. Mercurial 和 Git 的比较 Mercurial <ul><li>简单的本地版本数字
    40. 40. 自带一个快速的http服务,在使用http传输上有更好的效率
    41. 41. 跨平台没的说
    42. 42. 不能修改历史记录 </li></ul>Git <ul><li>使用hash做为版本号码,复杂
    43. 43. 命令参数有150多个选项,复杂
    44. 44. 使用http传输效率不高
    45. 45. 对于windows支持不好
    46. 46. 以修改历史记录为荣 </li></ul>
    47. 47. Mercurial基本命令 <ul>文件管理 <li>新建一个版本库
    48. 48. - hg init
    49. 49. 加入新的文件
    50. 50. - hg add [FILE …]
    51. 51. 将文件移出版本库
    52. 52. - hg remove [FILE …]
    53. 53. 改名
    54. 54. - hg rename OLD NEW </li></ul><ul>检查修改状态 <li>显示当前的更新状态
    55. 55. - hg status [FILE...]
    56. 56. 查看文件变更
    57. 57. - hg diff [FILE...]
    58. 58. 查看更新记录
    59. 59. - hg log
    60. 60. - hg glog (图形化查看) </li></ul>
    61. 61. 提交修改 <ul><li>提交代码
    62. 62. - hg commit [FILE …]
    63. 63. 取消修改
    64. 64. - hg revert [FILE …]
    65. 65. 返回最后一个版本(不可逆,危险操作!!!)
    66. 66. - hg rollback [FILE …] </li></ul>
    67. 67. 分支 (Branch) <ul><li>建立新的分支
    68. 68. - hg branch BRANCH_NAME
    69. 69. 在分支中切换
    70. 70. - hg update -r BRANCH_NAME
    71. 71. - 默认分支为 default
    72. 72. 列出所有的分支
    73. 73. - hg branches </li></ul>
    74. 74. 标签 <ul><li>新建一个标签
    75. 75. - hg tag TAG_NAME
    76. 76. 在分支中切换
    77. 77. - hg update -r TAG_NAME
    78. 78. 列出标签
    79. 79. - hg tags
    80. 80. 版本库里的标签信息都保存在 .hgtags
    81. 81. 有一个特殊的标签 'tip', 这个标签是浮动的,永远标识最新的版本 </li></ul>
    82. 82. <ul><li>公开自己的仓库
    83. 83. - hg serve
    84. 84. 克隆一个仓库
    85. 85. - hg clone EXISTS_REPO project
    86. 86. EXISTS_REPO的格式
    87. 87. - http[s]://server/project
    88. 88. - svn://server/path/to/project
    89. 89. - [ file://]/path/to/project
    90. 90. 推送你的修改
    91. 91. - hg push REMOTE
    92. 92. 取得别人的修改
    93. 93. - hg pull REMOTE
    94. 94. 更新当前的工作目录(同步仓库)
    95. 95. - hg checkout </li></ul>
    96. 96. Mericurial的版本命名规则
    97. 97. 一些术语和约定 <ul><li>修改的集合以节点的形式保存在一个直线非循环的图形( Direct acylic graph )
    98. 98. 根节点没有父节点
    99. 99. 一个改变集合里没有子节点就是 &quot; 头 &quot;
    100. 100. 一般的提交只有一个父节点
    101. 101. Merge 就会有二个父节点
    102. 102. 分支的名字是被它的父节点所决定的
    103. 103. Merge 只发生在你自己本地的仓库里 </li></ul>
    104. 104. Merge 合并 合并前
    105. 105. 合并中 执行 hg pull 后,本地的版本里多出一个 head 6:d2b5
    106. 106. 合并后
    107. 107. 合并的冲突解决 <ul><li>合并冲突需要利用其它工具
    108. 108. - vimdiff, kdiff3,
    109. 109. 在自己的 .hgrc 里配置
    110. 110. - merge = vimdiff </li></ul>
    111. 111. 分支的使用策略和发布管理 <ul><li>选择开发模型 </li></ul>
    112. 113. 分布式,但集中化 <ul><li>有一个“中心仓库”
    113. 114. 每个开发者pull和push到origin,但除了中心化的push-pull关系外,每个开发者还可以从其他开发者那pull changes </li></ul>
    114. 115. main分支 <ul><li>中心仓库里有二个分支
    115. 116. - master
    116. 117. - develop
    117. 118. origin/master 作为主要分支
    118. 119. origin/develop 上的代码是为下一次的代码发布准备的
    119. 120. 当 develop 分支达到了一个稳定状态并准备发布时,所有的改变都要合并到 master 分支,并标上版本号 </li></ul>
    120. 121. 支持(Supporting)分支 <ul><li>方便开发小组之间的并行开发
    121. 122. 这些分支是有时间限定的,因为它们最终会被删除
    122. 123. 会使用到的分支
    123. 124. - Feature branches
    124. 125. - Release branches
    125. 126. - Hotfix branches </li></ul>
    126. 127. Feature branches <ul><li>继承分支: develop
    127. 128. 合并分支:develop
    128. 129. 命名规范:除了master,develop,release-,hotfix-
    129. 130. Feature branches是用来开发新特性的(短期,远期都可以)。当开始开发新特性时,很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到develop,当然如果开发失败,就可以抛弃。 </li></ul>
    130. 131. Release branch <ul><li>继承分支: develop
    131. 132. 合并分支:develop 和 master
    132. 133. 命名规范:release-*
    133. 134. Release branch 是为新的production release准备的(相当于RC版),可以有一些小的bug,并为发布准备一些元数据(版本号,构建日期等等)。把所有的这些工作都放到 Release branch,develop branch就能更清晰地知道下一个版本要开发哪些特性。
    134. 135. 从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版本号。 </li></ul>
    135. 136. Hotfix branch <ul><li>继承分支: master
    136. 137. 合并分支:develop 和 master
    137. 138. 命名规范:hotfix-*
    138. 139. Hotfix branch和Release branch有几分相似,都是为了新的production release而准备的。比如运行过程中发现了bug,就必须快速解决,这时就可以创建一个Hotfix branch,解决完后合并到master分支上。好处是开发人员可以继续工作,有专人来负责搞定这个bug。 </li></ul>
    139. 140. <ul>Questions ? </ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×