专栏首页xcywt记录我学github的路程(二)

记录我学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即可!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 记录我学github的路程(三)

    2015-12-22 更新 一、Bug分支 1,假设如下场景,你正在dev分支工作,突然接到一个修复代号为101的bug的任务时,dev的东西还没不能提交,但是...

    xcywt
  • 记录我开始学习 Git的路程

    工作半年多了,总觉得没学到什么东西,于是乎找了个Git学习一下,感觉还蛮厉害的样子。为此记录下我的路程 2015,11,26 更新   前面的路都挺艰难的,在官...

    xcywt
  • 程序员需要知道的十个操作系统的概念

    说明:我之前在网上看到这篇文章觉得非常好,于是把它翻译了下来。当然很多地方翻译的很渣,见笑了。温馨提示,文章有点长。

    xcywt
  • git常用操作--分支同步master 本地库提交到远程分支

    斑马
  • 分布式版本控制-Git(二)

    版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。

    奋飛
  • git进行版本控制管理

    1、获取远程最新代码后,则需要从本地master分支切换到开发分支。(此处我们以每个新功能为一个新的开发分支)

    李才哥
  • Git笔记

    可以在GitHub下载离线版的笔记,链接如下:https://github.com/FangYang970206/GitNote,觉得不错的话,欢迎fork和s...

    努力努力再努力F
  • Git -- 分支与合并 (命令行+可视化工具p4merge) Fast Forward 合并禁用 Fast Forward 合并自动合并解决合并的冲突

    基本命令 把所有的变化都放在master分支并不是最好的做法. 建议的做法是把变化放在分支里面. ? 至少应该准备一个feature分支之类的, 把变化都隔离开...

    solenovex
  • Git -- 分支与合并 (命令行+可视化工具p4merge)

    把所有的变化都放在master分支并不是最好的做法. 建议的做法是把变化放在分支里面.

    solenovex
  • GIT分支管理和常用命令

    master 分支 不能往master 分支上提交代码,只能在该分支上进行代码合并操作,例如将其它分支的代码合并到 Master 分支上。 develop ...

    黄小怪

扫码关注云+社区

领取腾讯云代金券