记录我学github的路程（二）
2015-12-09 更新
1，现在，本地有了一个库，你可能会想到GitHub创建一个库，并且关联起来。这样，远程的库既可以当作备份，又可以让其他人通过该仓库来协作。
2，步骤：
（1）登录GitHub，应该会有提示，（我还没创建过远程库，很容易看到这个界面）
（2）点击那个 Create a respository:
（3）这就创建好了一个库，这时候库还是空的，GitHub告诉我们可以从这个仓库克隆出新的仓库。也可以把一个已有的本地仓库与之关联。
（4）本地仓库与之关联：
打开Git Bash： 输入
$ git remote add origin git@github.com:yourname/yourname.git
注意：把yourname换成你自己的账户名和库名
若你关联了别人的 ，你是推送不上去的，因为你的SSH Key公钥不在别人的账户列表中
添加后，远程库的名字就是origin，这是Git默认叫法，可以改成别的
下一步，就可以把本地库的东西推送到远程库中了
$ git push -u origin master
本地内容推送到远程，用git push 命令，其实就是把当前分支master推送到远程
由于这时远程库是空的，第一次推送master时，加上-u参数，Git不但把本地分支推送给了远程新的master分支，还会把本地的master分支和远程的master分支关联起来，以后推送或拉取就可以简化命令。
推送成功后，再GitHub页面中可以看到远程库的内容和本地已经一样了
3，从现在起，只有本地做了修改，就可以用下面的命令
$ git push origin master
把本地master分支的最新修改推送到GitHub。
4，小结：
关联一个远程库： $ git remote add origin git@github.com:yourname/yourname.git
第一次推送到远程库： $ git push -u origin master
后面再提交： $ git push origin master
----- 分割线 -----
从远程库克隆
1，先创建一个库，和上面的方法有点不一样
2，这样创建好之后，这个库会有一个README.md文件。这样就有了一个远程库，
3，打开git bash，输入命令
$ git clone git@github.com:yourname/yourname.git
这样，就把一个远程库克隆到本地了，就像这样子
4，小结：
要克隆一个库，就必须要知道仓库的地址，然后用git clone 命令克隆。
2015-12-10 20:14:09
1，分支管理：可以创建一个属于自己的分支，别人看不到，别人还继续在原来的分支上工作，而你自己在自己的分支上干活，想提交就提交，开完完毕后，再一起合并到原来的分支上，安全又不影响别人工作。
2，创建与合并分支
（1）在版本回退里，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。目前为止，只有一条时间线，在Git里，这个分支叫做主分支（master分支 ）。
HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以HEAD指向的就是当前分支。（这个有点拗口）
（2）开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，这样就能确定当前的分支，以及当前分支的提交点：
就这样，每次提交后，master分支就会向前移动一步，随着不断提交，master分支的线就越来越长。（在没有创建新的分支时）
（3）当我们创建新的分支，比如dev时，Git新建了一个指针叫dev，指向master相同的提交。再把HEAD指向dev，就表示当前分支在dev上：
就像上图一样，仅仅是多了一个dev指针，再改变HEAD的指向，工作区的文件没有任何变化。（HEAD始终指向当前分支，在这里就是dev）
从现在开始，对工作区的修改和提交就是针对dev分支了，每次提交HEAD会往前，而master指针不变。
（4）当dev的工作做完了，要怎样和master合并呢。最简单的方法就是：用master指向dev的当前提交。就像这样，改改指针，工作区的内容不变。
合并完分支以后，就可以删除dev指针了。这时候就只剩一条master分支了。
3，开始操刀实战了：
（1）创建 dev分支，然后切换到dev分支
$ git checkout -b dev
git checkout 加上 -b参数表示创建并切换，相当于下面两条命令 ：
$ git branch dev
$ git checkout dev
然后，可以查看一下当前分支 ，git branch会列出所有分支，当前分支前面会标*号
接下来在dev修改提交，并切换回master分支
接下来合并，并且删除dev指针，就可以看到刚刚在dev所做的修改了
4，小结：
查看分支： git branch // 带*的表示当前分支
创建分支： git branch **name
切换分支： git checkout **name
创建+切换分支： git checkout -b **name
合并某分支到当前分支： git merge **name
删除分支： git branch -d **name
2015-12-21 更新
最近都挺忙的，公司项目好多bug，真是艰难。哈哈哈
1，解决冲突
现在假设如下场景：
$ git checkout -b feature1 // 创建并切换到新分支
然后对readme.txt进行修改，并提交
再切换回master分支 $ git checkout master
在master分支对readme.txt进行修改提交
这时候再把master和feature1分支进行合并 $ git merge feature1
这时候就会有冲突 ，Git告诉我们 readme.txt文件存在冲突，必须手动解决冲突再提交。可以用$ git status 查看冲突的文件
这时候运行 $ cat readme.txt 可以查看文件内容，如下图，只截部分内容
Git用 <<<<<<<，=======，>>>>>>> 标记不同分支的内容。
现在master分支和feature1分支变成了下图所示：
使用下面命令可以看到分支的合并情况：
小结：Git无法自动合并分支时，就要先解决冲突，这样才可以提交。
$ git log --graph 可以看到分支合并图
2，分支管理策略
（1）通常，合并分支时 ，如果可能，Git会用“Fast forward”模式。（这样删除分支后，会丢掉分支信息）
（2）要强制禁用“Fast forward”模式，Git会在merge时生成一个新的commit，这样从分支历史就可以看出分支信息
（3）实例：
$ git checkout -b dev // 后面对readme.txt修改，原谅我写注释习惯了这样，虽然我也知道这样不正确，哈哈哈
$ git add readme.txt
$ git commit -m "add merge" // 截图从这里开始
$ git checkout master
$ git merge --no-ff -m "merge with np-ff" dev // --no-ff 禁用“Fast forward”
// 因为本次合并要创建一个新的commit ，所以加上 -m，把commi描述写进去，合并后，再 查看分支历史
$ git log --graph --pertty=oneline --abbrev-commit
不用fast forward模式，merge之后就像这样
（4）分支策略：实际开发中应该按照几个原则进行分支管理
首先，master分支应该是非常稳定的， 平时不能在这干活。在master分支上发布。
干活都在dev分支上，每个人都在dev分支上干活，每个人都有自己的分支，时不时的合并就可以了。
所以团队合作的分支就是这样子：
小结：合并分支时加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支。能看出来做过合并
而fast foward合并就看不出来曾经合并过。
注：.Fast forward模式介绍。 参考：http://bbs.scmlife.com/thread-22570-1-1.html
在使用git merge时，可能是以下三种模式中的某一种
1.Fast forward
当待合并的2个branch最近的commit是线性关系时
或者说，某个branch自上次更新后没有commit信息时
git则直接移动指针即可，并没有真正的merge操作，也没有对应的merge commit信息
2.Merge made by recursive
当要合并的2个branch的最近的commit对应的直接祖先不同时
git就无法通过简单的移动指针来进行合并
只能以2个branch的最新commit和他们的共同祖先进行一次merge
并对应有一个merge commit信息
3.Conflict
当2个branch都修改了同一个文件的同一部分时
这时，就会发生冲突，git的自动合并就会失败
这时，使用git status会看到
需要手工合并冲突后，git add一下，表明冲突修改完了
然后，再git commit即可!