记录我学github的路程(二)

2015-12-09 更新

1,现在,本地有了一个库,你可能会想到GitHub创建一个库,并且关联起来。这样,远程的库既可以当作备份,又可以让其他人通过该仓库来协作。

2,步骤:

(1)登录GitHub,应该会有提示,(我还没创建过远程库,很容易看到这个界面)

记录我学github的路程(二)

(2)点击那个 Create a respository:

记录我学github的路程(二)

 

(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 

记录我学github的路程(二)

本地内容推送到远程,用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,先创建一个库,和上面的方法有点不一样

记录我学github的路程(二)

 

2,这样创建好之后,这个库会有一个README.md文件。这样就有了一个远程库,

3,打开git bash,输入命令

$ git clone git@github.com:yourname/yourname.git 

这样,就把一个远程库克隆到本地了,就像这样子

记录我学github的路程(二)

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,这样就能确定当前的分支,以及当前分支的提交点:

记录我学github的路程(二)

就这样,每次提交后,master分支就会向前移动一步,随着不断提交,master分支的线就越来越长。(在没有创建新的分支时)

(3)当我们创建新的分支,比如dev时,Git新建了一个指针叫dev,指向master相同的提交。再把HEAD指向dev,就表示当前分支在dev上:

  记录我学github的路程(二)

就像上图一样,仅仅是多了一个dev指针,再改变HEAD的指向,工作区的文件没有任何变化。(HEAD始终指向当前分支,在这里就是dev)

从现在开始,对工作区的修改和提交就是针对dev分支了,每次提交HEAD会往前,而master指针不变。

(4)当dev的工作做完了,要怎样和master合并呢。最简单的方法就是:用master指向dev的当前提交。就像这样,改改指针,工作区的内容不变。

记录我学github的路程(二)

合并完分支以后,就可以删除dev指针了。这时候就只剩一条master分支了。

 

3,开始操刀实战了:

(1)创建 dev分支,然后切换到dev分支

$ git checkout -b dev

git checkout 加上 -b参数表示创建并切换,相当于下面两条命令 :

$ git branch dev

$ git checkout dev

然后,可以查看一下当前分支 ,git branch会列出所有分支,当前分支前面会标*号

记录我学github的路程(二)

接下来在dev修改提交,并切换回master分支

记录我学github的路程(二)

接下来合并,并且删除dev指针,就可以看到刚刚在dev所做的修改了

记录我学github的路程(二)

 

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 查看冲突的文件

记录我学github的路程(二)

 这时候运行 $ cat readme.txt  可以查看文件内容,如下图,只截部分内容

记录我学github的路程(二)

Git用 <<<<<<<,=======,>>>>>>> 标记不同分支的内容。

现在master分支和feature1分支变成了下图所示:

 

记录我学github的路程(二)

使用下面命令可以看到分支的合并情况:

记录我学github的路程(二)

小结: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

记录我学github的路程(二)

不用fast forward模式,merge之后就像这样

记录我学github的路程(二)

(4)分支策略:实际开发中应该按照几个原则进行分支管理

首先,master分支应该是非常稳定的, 平时不能在这干活。在master分支上发布。

干活都在dev分支上,每个人都在dev分支上干活,每个人都有自己的分支,时不时的合并就可以了。

所以团队合作的分支就是这样子:

记录我学github的路程(二)

  小结:合并分支时加上 --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即可!

 

上一篇:《程序员的自我修养》第三章学习笔记


下一篇:编译到底做了什么(***.c -> ***.o的过程)