Mercurial的使用心得

　　本文发表地址：http://www.xiabingbao.com/mercurial/2015/01/22/mercurial-understanding/

　　本人接触版本控制的历史

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

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

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

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

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

　　

　　mercurial的使用

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

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

　　

　　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 文件名 查看该文件的改动

　　

　　使用过程中遇到的问题

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分支上拉取远程的代码并更新本地代码:
   　　hg pull -u(hg pull, hg update)
   7.2 在default分支上新建自己的分支:
   　　hg branch 自己的分支名
   7.3 合并他人的分支:
        hg merge 他人的分支名
   7.4 将合并的先提交一下，不然一会儿自己的改动和刚拉取的他人的代码混到一起了:
        hg commit -m ‘merge from xiaoming’
   7.5 进行自己的改动，该修改的修改，该添加的添加，该删除的删除
   7.6 提交自己的修改: 
        hg commit -m ‘改动原因或目的’
   7.7 再拉取下远程的代码，在改动的过程中说不定已经有人更新default分支了，不合并的话，会把别人的提交弄丢:
        hg pull -u
        hg merge default
        hg commit -m ‘merge from default’(若merge default时需要提交)
   7.8 将自己的代码推送到远程代码库:
       hg push -b 自己的分支名 –new-branch

8. 配置 .hg目录 
    8.1 grc : hg的远程代码库地址 ，若远程地址改动了 ，不用从零开始在新的地址拉取，只需要在这个文件中可以修改地址即可　

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

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

　　9. 合并分支时出现冲突或出现推代码时出现多个相同的分支(多头)，怎么办？
当我出现这个的状况时通常是使用<a href=“”>sourceTree</a>的这个可视化工具来解决的，sourceTree上安装kdiff3的插件，当合并时出现了冲突，能够很明显的看到文件的哪部分出现了冲突，然后应该选择哪个作为需要合并的部分 当出现多个相同的分支时，把其他相同的分支直接merge到一个分支上，然后再推代码。

　　

　　总结

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