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即可! |