[Todo] Git & 版本控制学习

下面这篇写的很是好。git分支介绍，有图。好好看这一篇，就懂了：

http://www.open-open.com/lib/view/open1328069889514.html

该系列还有很多文章，在页面下面的列表里，有时间能够看看（Todo）。

 

 下面是一些笔记：

经过此语法，你能够把本地分支推送到某个命名不一样的远程分支：若想把远程分支叫做awesomebranch，
能够用 git push origin serverfix:awesomebranch 来推送数据 （本地serverfix，远程awesomebranch）。

好比某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在本身的一个分支里进行开发，当准备向主项目提交补丁的时候，
根据最新的origin/master 进行一次衍合操做而后再提交，这样维护者就不须要作任何整合工做
（译注：其实是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），
（主干维护者）只需根据你提供的仓库地址做一次快进合并，或者直接采纳你提交的补丁。

呃，奇妙的衍合也并不是天衣无缝，要用它得遵照一条准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操做。
若是你遵循这条金科玉律，就不会出差错。不然，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。

在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些相似但不一样的新的提交对象。若是你把原来分支中的提交对象发布出去，
而且其余人更新下载后在其基础上开展工做，而稍后你又用 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，
你的合做者就不得不从新合并他们的工做，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
git rebase

若是把衍合当成一种在推送以前清理提交历史的手段，并且仅仅衍合那些还没有公开的提交对象，就没问题。
若是衍合那些已经公开的提交对象，而且已经有人基于这些提交对象开展了后续开发工做的话，就会出现叫人沮丧的麻烦。

下面是一些从文中摘录出的可以帮助理解的图：

 

几个注意点：

1. 修改了文件的时候，必需要 git add，不add的话commit提交的文件就不对。git add 和 git stage是一个意思，是把文件提交到中间的stage区（注：git文件有三个区：working, stage, repository）.

能够用 git diff --cached 或 git diff --staged 来查看stage中的文件diff，两个命令同一个意思。

 

2. 这篇文章讲了比较详细的和远程repository冲突的问题。

http://www.cnblogs.com/cj2014/p/5557654.html

当没有对本地进行 git fetch 或 git pull的时候（git pull = git fetch + merge to local，而git fetch指的是同步到本地repository，而不是working directory），若是远端有改动，本地也有改动，就会发生冲突，就要进行冲突解决。

通常来说，都是须要人为解决的。

解决的方法就是 git pull, add, commit, mergetool等命令的组合。

1). git pull: 提示冲突

    2). 提交(git add --all; git commit)

    3). git pull

    4). git mergetool

    5). git pull
    6). git commit 
         [216-fixed-area-walk d228a46] Merge branch '216-fixed-area-walk' of 192.168.1.51:IGV/IGV01-SW into 216-fixed-area-walk

    7). git add --all
    8). git commit
    9). git push origin 216-fixed-area-walk

 

再复习一下普通的提交到远端的方式（注意不要忘了git add）

1. git pull

2. git add --all

3. git commit

4. git push origin 216-fixed-area-walk

 

下面这篇文章写的不错：

http://blog.csdn.net/kesenhoo/article/details/7654351

分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，诸如Git，Mercurial，Bazaar 还有 Darcs 等，
客户端并不仅提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。

文章列表在这里：

http://blog.csdn.net/kesenhoo/article/category/1165624

 

git分支的介绍(可是图不清楚)，其实复制了第一篇文章，能够忽略：

http://blog.csdn.net/wh_19910525/article/details/7470964

里面提到：Git 又是如何建立一个新的分支的呢？答案很简单，建立一个新的分支指针。

在 Git 中，它是一个指向你正在工做中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。

 

关于fast-forward, no-ff, squash等的解释，下面写的不错

http://blog.csdn.net/chen930724/article/details/50174657

fast-forward方式就是当条件容许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种状况若是删除分支，则会丢失分支信息。
由于在这个过程当中没有建立commit

squash 是用来把一些没必要要commit进行压缩，好比说，你的feature在开发的时候写的commit很乱，那么咱们合并的时候不但愿把这些历史commit带过来，
因而使用--squash进行合并，此时文件已经同合并后同样了，但不移动HEAD，不提交。须要进行一次额外的commit来“总结”一下，而后完成最终的合并。

--no-ff指的是强行关闭fast-forward方式。