Mercurial的使用心得

蚊子前端博客
发布于 2015-01-22 07:00
这篇文章主要是本人在使用Mercurial时的心得和总结,对自己这段时间的使用做个梳理,同时也希望文章中的某个点能解开你的疑惑

1. 本人接触版本控制的历史

在很久很久以前,我们是怎么进行版本控制的呢,当我们工作到某个阶段后,就把此时的项目存为一个文件夹(A),然后再从这儿复制出一份(B)接着修改,而存储的那个文件夹(A)就是我们打的版本号,当我们把B改动到某个阶段后再打一个版本,然后从这个版本里衍生出一个C,一直衍生下去......。如果我们在某个版本改坏了的话,我们再从上个版本复制出一份接着修改。

本人小蚊当时在学校的时候对版本控制了解的不深,就是用的这种方式进行版本控制的,这种手动进行版本控制的一个坏处就是:我们不知道每两个版本的差异在哪儿,都修改了哪些文件,只能说是这个版本比上个版本多了几个功能,可是文件的差异在哪儿,就不好对比了。不过后来在工作中遇到了SVN,这种情况就改善了很多。

当时小蚊使用SVN时,每次我要对某个项目的代码进行改动时,都先从服务器上down下一份代码来,然后开始修改。因为本地的代码已经很老了,如果其他人也提交了代码的话,我再用我本地的老代码进行提交,就可能出现代码覆盖或文件冲突的情况。刚开始使用时都没有写改动信息,后来发现同事会在项目里弄一个changelog.txt来保存每次的修改,然后我也跟着学。可是后来发现原来SVN本身就有记录改动日志的功能,从这儿之后才算是开始步入正轨,真正地接触到了版本控制系统。

当我开始接触github时,慢慢地使用上了git这个版本控制系统,可是因为是项目只有自己在改,也没有学习到很多。

后来换了新工作之后,新公司使用的是mercurial作为版本控制系统,在工作中学习到了很多分布式版本控制系统的知识。

2. mercurial的使用

hg和git有着无数的相似之处,都是分布式版本控制,都是有分支。git我只是在提交自己的项目时使用,很多的东西还没用到,不过工作中使用的是hg,每天都在多人合作代码,常会遇到合并分支时出现文件冲突、推代码时出现多个相同的分支。

什么是分支,分支是干什么用的? 像以前传统时的那种版本控制系统,整个项目都是集中一个服务器上,任何的修改都是要先从整个服务器上拉取代码,修改完成后再上传上去,若在修改的期间,其他人也提交了代码,最后自己提交的时候可能会覆盖掉上一个人的改动;现在分布式版本控制系统的优势就是,一个分支就是一个代码库,你在该分支上进行的任何操作都不会影响到其他分支,如果把整个分支整坏了,或者想放弃这个分支,那么直接切回到default分支重新新建即可,在那个分支上所有的改动都被保留在了那个分支上。

3. hg常用命令

hg clone rep 从rep的地址拉取代码 hg status 查看当前仓库中的文件改动状态:

  • M: 内容已改动;

  • !(感叹号):版本库还在跟踪该文件,可是本地仓库已经丢失该文件

  • R:该文件从版本库中删除;

  • ?(问号):本地仓库中新添加的文件,版本库里还没有该文件,需要使用hg add 文件名 添加到版本库中

  • A:该文件是新添加的

hg remove 文件名 版本系统不再跟踪该文件 hg revert 文件名 恢复该文件

状态是!(感叹号)的,需要进行二选一了,是该文件真需要删除了,还是被误删了;若真的需要删除,则使用hg remove 文件名,若被误删了则使用hg revert恢复该文件

hg add . 将所有没有在版本控制系统的文件添加到控制系统中, hg add 文件名 是将某个文件添加到控制系统中 hg log 查看提交的历史信息 hg commit 将本地的改动进行提交 hg push 将改动推到远程的分支上 hg merge 分支名 将其他分支的代码合并过来 hg diff 查看改动,hg diff 文件名 查看该文件的改动

4. 使用过程中遇到的问题

  1. 当前分支拉取当前分支不用merge,直接hg pull -u

  2. 取消当前分支的修改回到最初状态时,hg update -C

  3. 切换到其他分支且不保留当前分支的修改时,hg update default -C

  4. 切换到其他分支且保留当前分支的修改时,hg update default

  5. 创建分支时要在default分支上进行创建,这样保证所有的分支没有瓜葛;若在其他的分支上直接创建分支时,则把上一个分支的修改保留了下来,不容易进行拆分;视情况而定

  6. 若第一次提交分支时,则使用hg push -b 当前分支名 --new-branch,若已经是第二次以上的提交了则使用hg push -b 当前分支名即可,当然,每次提交时都带着—new-branch也没错

  7. 多人合作时需要拉取别人的分支的代码,不要担心,别人的分支和default分支没有任何区别

    7.1 在default分支上拉取远程的代码并更新本地代码:

    COPYBASH

    hg pull -u(hg pull, hg update)

    7.2 在default分支上新建自己的分支:

    COPYBASH

    hg branch 自己的分支名

    7.3 合并他人的分支:

    COPYBASH

    hg merge 他人的分支名

    7.4 将合并的先提交一下,不然一会儿自己的改动和刚拉取的他人的代码混到一起了:

    COPYBASH

    hg commit -m 'merge from xiaoming'

    7.5 进行自己的改动,该修改的修改,该添加的添加,该删除的删除

    7.6 提交自己的修改:

    COPYBASH

    hg commit -m '改动原因或目的'

    7.7 再拉取下远程的代码,在改动的过程中说不定已经有人更新default分支了,不合并的话,会把别人的提交弄丢:

    COPYBASH

    hg pull -u hg merge default hg commit -m 'merge from default'(若merge default时需要提交)

    7.8 将自己的代码推送到远程代码库:

    COPYBASH

    hg push -b 自己的分支名 --new-branch
  8. 配置 .hg目录

    8.1 hgrc : hg的远程代码库地址 ,若远程地址改动了 ,不用从零开始在新的地址拉取,只需要在这个文件中可以修改地址即可

    COPYTEXT

    [paths] default = ssh://https://www.github.com/wenzi0github/test

    8.2 branch : 当前的分支 ,这个文件里存储着当前的分支名 8.3 last-message.txt : 最后一次提交的信息,hg commit -m 'message'

  9. 合并分支时出现冲突或出现推代码时出现多个相同的分支(多头),怎么办? 当我出现这个的状况时通常是使用sourceTree的这个可视化工具来解决的,sourceTree上安装kdiff3的插件,当合并时出现了冲突,能够很明显的看到文件的哪部分出现了冲突,然后应该选择哪个作为需要合并的部分;当出现多个相同的分支时,先使用hg up 分支切换到当前多个中,然后把其他相同的分支直接merge到这个分支上,然后再合并其他分支的代码。

  10. 如何在mac下配置kidff3? 配置kdiff3的地方主要由两个:控制台sourcetree。首先安装kdiff3,如果是直接打开的话,那么就直接把kidff3.app拖拽到应用程序的文件夹中。

10.1 控制台配置kdiff3  
hg在控制台配置kdiff3是相当的简单,打开你的`~/.hgrc`文件(如果不存在则创建一个),然后添加下面的代码:  

COPYBASH

[extdiff] cmd.kdiff3 = /Applications/kdiff3.app/Contents/MacOS/kdiff3 [merge-tools] kdiff3.args = $base $local $other -o $output
配置完成后,当你merge一个分支产生冲突时,kidff3会自动弹出,然后你就可以选择你需要的内容进行合并。  
  
10.2 sourcetree配置kidff3  

打开sourcetree->preferences->diff,然后在visual diff tool和merge tool中都选择kDiff3即可。  

当有文件产生冲突时,选择这个文件->右键选择resolve conflicts->launch external merge tool ,就会弹出kDiff3。

5. 总结

当然,这里也只是个人经历的总结而已,依然还有很多的东西没有总结到位。

标签:
阅读(359)

公众号:

qrcode

微信公众号:前端小茶馆

公众号:

qrcode

微信公众号:前端小茶馆