Git的杀手级特性--分支
1.几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线。与许多其它版本控制系统不同,Git 鼓励在工作流程中频繁地使用分支与合并,哪怕一天之内进行许多次。 理解和精通这一特性,你便会意识到 Git 是如此的强大而又独特,并且从此真正改变你的开发方式。
创建新分支:$ git branch testing
切换新分支:$ git checkout testing
提交新分支:git commit -a -m 'made other changes' 加上注视
运行 git log --oneline --decorate --graph --all ,它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件,所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符),如此的简单能不快吗?这与过去大多数版本控制系统形成了鲜明的对比,它们在创建分支时,将所有的项目文件都复制一遍,并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟,有时甚至需要好几分钟。所需时间的长短,完全决于项目的规模。而在 Git 中,任何规模的项目都能在瞬间创建新分支。 同时,由于每次提交都会记录父对象,所以寻找恰当的合并基础(译注:即共同祖先)也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。每次提交都会记录父对象,即保存一次快照,便于之后将不同分支进行合并。
2.一个分支的使用例子:
让我们来看一个简单的分支新建与分支合并的例子,实际工作中你可能会用到类似的工作流。 你将经历如下步骤:
1. 开发某个网站。
2. 为实现某个新的需求,创建一个分支。3. 在这个分支上开展工作。正在此时,你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理:1. 切换到你的线上分支(production branch)。2. 为这个紧急任务新建一个分支,并在其中修复它。3. 在测试通过之后,切换回线上分支,然后合并这个修补分支,最后将改动推送到线上分支。4. 切换回你最初工作的分支上,继续工作。
你已经决定要解决你的公司使用的问题追踪系统中的 #53 问题。 想要新建一个分支并同时切换到那个分
支上,你可以运行一个带有 -b 参数的 git checkout 命令: git checkout -b iss53 #创建新分支并切换到该分支,它是下面两条命令的简写:$ git branch iss53
$ git checkout iss53
现在你接到那个电话,有个紧急问题等待你来解决。 有了 Git 的帮助,你不必把这个紧急问题和 iss53 的修改混在一起,你也不需要花大力气来还原关于 53# 问题的修改,然后再添加关于这个紧急问题的修改,最后将这个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。但是,在你这么做之前,要留意你的工作目录和暂存区里那些还没有被提交的修改,它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是,在你切换分支之前,保持好一个干净的状态。 有一些方法可以绕过这个问题(即,保存进度(stashing) 和 修补提交(commit amending)),(目前的理解是进行commit保存在本地,以便于以后再check回来)。我们会在储藏与清理 中看到关于这两个命令的介绍。 现在,我们假设你已经把你的修改全部提交了,这时你可以切换回master 分支了:
$ git checkout master
Switched to branch 'master'可以在master分支上新建一个分支hotfix来解决这个紧急问题,然后再切换到master分支将hotfix分支merge到master分支,此时master分支和hotfix分支指向同一个版本快照,此时可以删除hotfix分支了
删除分支
然后回到之前的iss53分支,可以把修复了hotfix问题的master分支merge到iss53分支里,
远程分支:远程引用是对远程仓库的引用,包括分支,标签等。
origin与master一样并无特殊含义,只是克隆时系统默认的名字,可以在克隆时进行更改。
这段可以看数来理解,更连贯一些
clone
fetch
fetch
fetch之后不会生成一个新的serverfix分支,只会有一个不可修改的origin/serverfix指针,想要将这些工作合并到新的分支,可以运行 git merge origin/serverfix 如果想要在自己的
serverfix 分支上工作,可以将其建立在远程跟踪分支之上:(即在本地新建一个基于远程此分支的新分支)$ git checkout -b serverfix origin/serverfix
然后就可以用他的代码在本地进行开发了。
push
推送本地的 serverfix 分支,将其作为远程仓库的 serverfix 分支” 可以通过这种格式来推送本地分支
到一个命名不相同的远程分支。 如果并不想让远程仓库上的分支叫做 serverfix,可以运行 git pushorigin serverfix:awesomebranch 来将本地的 serverfix 分支推送到远程仓库上的 awesomebranch分支。
前三章看完了,来实际操作练习练习。