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时，可能是以下三种模式中的某一种9 m& _7 c% N) j( B. M3 m

5 p6 U4 G0 N* s" L3 F# I

1.Fast forward

   当待合并的2个branch最近的commit是线性关系时' C& V: Y- n+ p  n+ B+ v# R

   或者说，某个branch自上次更新后没有commit信息时

   git则直接移动指针即可，并没有真正的merge操作，也没有对应的merge commit信息

# S7 O' l" R, r3 R1 Z

2.Merge made by recursive% N$ X7 o' {" ]% N0 z2 g# q

   当要合并的2个branch的最近的commit对应的直接祖先不同时  p. Z4 W  s- l/ O

   git就无法通过简单的移动指针来进行合并

   只能以2个branch的最新commit和他们的共同祖先进行一次merge: l+ D& R5 z4 _* P, z  h, \

   并对应有一个merge commit信息3 G1 _+ Q! W) a- v) N8 S

3.Conflict

   当2个branch都修改了同一个文件的同一部分时4 ~5 H) g) p' y8 I* ?6 p1 J! J

   这时，就会发生冲突，git的自动合并就会失败

   这时，使用git status会看到- F# r+ [- g1 j. m. _% Z- P# d! r4 H6 ; l7 w# M3 E! Y8 U2  ^/ V" D* E5 k

   需要手工合并冲突后，git add一下，表明冲突修改完了

   然后，再git commit即可!