Mecurial hg
Upcoming SlideShare
Loading in...5
×
 

Mecurial hg

on

  • 1,964 views

Mercurial 版本管理简单介绍。

Mercurial 版本管理简单介绍。

Statistics

Views

Total Views
1,964
Slideshare-icon Views on SlideShare
1,964
Embed Views
0

Actions

Likes
1
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 为什么Subversion对于merge的支持很糟糕 #1 : 当有冲突时,你会被强制合并到一个未保存的工作目录的拷贝下 #2:当没有冲突发生时,你不能强制merge

Mecurial hg Mecurial hg Presentation Transcript

  • Mercurial 版本管理工具介绍 By 杨小勇
  • 版本管理的类型-集中式
    • 只有一个仓库
    • 访问仓库是受到控制的
    • 所有的改变都必须提交到这个仓库里
    • 所有的接收的改变都是来自该仓库
    • 应用场所:要求仓库能受到控制
    • 软件:CVS, SVN 等
  • 版本管理的类型-分布式
    • 每一个检出都是完整的仓库
    • 任何人可以接受来自任何人的补丁
    • 任何人可以发送自己的补丁给任何人
    • 适用于多个功能并行开发的项目
    • 软件:Git,Mercurial,bzr
  • 分布式版本管理的图形模式
  • Mercurial Hg 汞
    • Mercurial 最初也是为了linux内核而开发
    • 谁在使用 Mercurial?
    • - Python.org,Mozilla,OpenOffice …
    • 项目托管网站
    • — bitbucket,google code,sourceForge …
    • 跨平台支持:Linux/Mac/Win
    • GUI工具支持: Linux – hgk, Win – TortiseHG
  • 和Subversion的比较1 Mercurial 优点
    • 拥有自己的本地仓库
    • 不依赖网络
    • 能直接访问本地仓库
    • Merge是核心操作
    • 每一个checkout都是一个冗余的拷贝
    Subversion 的缺点
    • 必须要共享一个仓库
    • 必须要有活动的网络
    • 通过网络访问慢
    • 避免merge操作
    • 只有一个地方放代码。
  • Mercurial 和 Subversion的比较2 Mercruial的不足
    • 没有为二进制文件做优化
    • 做pull和push操作时必须先约定仓库位置
    • 没有简单的方法只检出仓库里某一部分代码
    • 只能追踪文件,所有空目录不会进入仓库
    • 在 DVS里总有人争论git和hg谁是王者
    Subversion的优点
    • 适合大量的二进制文件
    • 每一个人都知道仓库在哪里
    • 检出仓库里的某一部分代码很容易
    • 允许空目录
    • Subversion是CVS里的领导者
  • Mercurial 和 Git 的比较 Mercurial
    • 简单的本地版本数字
    • 自带一个快速的http服务,在使用http传输上有更好的效率
    • 跨平台没的说
    • 不能修改历史记录
    Git
    • 使用hash做为版本号码,复杂
    • 命令参数有150多个选项,复杂
    • 使用http传输效率不高
    • 对于windows支持不好
    • 以修改历史记录为荣
  • Mercurial基本命令
      文件管理
    • 新建一个版本库
    • - hg init
    • 加入新的文件
    • - hg add [FILE …]
    • 将文件移出版本库
    • - hg remove [FILE …]
    • 改名
    • - hg rename OLD NEW
      检查修改状态
    • 显示当前的更新状态
    • - hg status [FILE...]
    • 查看文件变更
    • - hg diff [FILE...]
    • 查看更新记录
    • - hg log
    • - hg glog (图形化查看)
  • 提交修改
    • 提交代码
    • - hg commit [FILE …]
    • 取消修改
    • - hg revert [FILE …]
    • 返回最后一个版本(不可逆,危险操作!!!)
    • - hg rollback [FILE …]
  • 分支 (Branch)
    • 建立新的分支
    • - hg branch BRANCH_NAME
    • 在分支中切换
    • - hg update -r BRANCH_NAME
    • - 默认分支为 default
    • 列出所有的分支
    • - hg branches
  • 标签
    • 新建一个标签
    • - hg tag TAG_NAME
    • 在分支中切换
    • - hg update -r TAG_NAME
    • 列出标签
    • - hg tags
    • 版本库里的标签信息都保存在 .hgtags
    • 有一个特殊的标签 'tip', 这个标签是浮动的,永远标识最新的版本
    • 公开自己的仓库
    • - hg serve
    • 克隆一个仓库
    • - hg clone EXISTS_REPO project
    • EXISTS_REPO的格式
    • - http[s]://server/project
    • - svn://server/path/to/project
    • - [ file://]/path/to/project
    • 推送你的修改
    • - hg push REMOTE
    • 取得别人的修改
    • - hg pull REMOTE
    • 更新当前的工作目录(同步仓库)
    • - hg checkout
  • Mericurial的版本命名规则
  • 一些术语和约定
    • 修改的集合以节点的形式保存在一个直线非循环的图形( Direct acylic graph )
    • 根节点没有父节点
    • 一个改变集合里没有子节点就是 " 头 "
    • 一般的提交只有一个父节点
    • Merge 就会有二个父节点
    • 分支的名字是被它的父节点所决定的
    • Merge 只发生在你自己本地的仓库里
  • Merge 合并 合并前
  • 合并中 执行 hg pull 后,本地的版本里多出一个 head 6:d2b5
  • 合并后
  • 合并的冲突解决
    • 合并冲突需要利用其它工具
    • - vimdiff, kdiff3,
    • 在自己的 .hgrc 里配置
    • - merge = vimdiff
  • 分支的使用策略和发布管理
    • 选择开发模型
  •  
  • 分布式,但集中化
    • 有一个“中心仓库”
    • 每个开发者pull和push到origin,但除了中心化的push-pull关系外,每个开发者还可以从其他开发者那pull changes
  • main分支
    • 中心仓库里有二个分支
    • - master
    • - develop
    • origin/master 作为主要分支
    • origin/develop 上的代码是为下一次的代码发布准备的
    • 当 develop 分支达到了一个稳定状态并准备发布时,所有的改变都要合并到 master 分支,并标上版本号
  • 支持(Supporting)分支
    • 方便开发小组之间的并行开发
    • 这些分支是有时间限定的,因为它们最终会被删除
    • 会使用到的分支
    • - Feature branches
    • - Release branches
    • - Hotfix branches
  • Feature branches
    • 继承分支: develop
    • 合并分支:develop
    • 命名规范:除了master,develop,release-,hotfix-
    • Feature branches是用来开发新特性的(短期,远期都可以)。当开始开发新特性时,很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到develop,当然如果开发失败,就可以抛弃。
  • Release branch
    • 继承分支: develop
    • 合并分支:develop 和 master
    • 命名规范:release-*
    • Release branch 是为新的production release准备的(相当于RC版),可以有一些小的bug,并为发布准备一些元数据(版本号,构建日期等等)。把所有的这些工作都放到 Release branch,develop branch就能更清晰地知道下一个版本要开发哪些特性。
    • 从develop分支合并到release分支的关键因素是:develop分支达到了release分支所要求的状态。至少所有针对该release的特性要被合并。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版本号。
  • Hotfix branch
    • 继承分支: master
    • 合并分支:develop 和 master
    • 命名规范:hotfix-*
    • Hotfix branch和Release branch有几分相似,都是为了新的production release而准备的。比如运行过程中发现了bug,就必须快速解决,这时就可以创建一个Hotfix branch,解决完后合并到master分支上。好处是开发人员可以继续工作,有专人来负责搞定这个bug。
    • Questions ?