分布式版本控制系统(git分支管理)

1,分支管理

分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,立刻提交,由于代码还没有写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的风险。
现在有了分支,就不能怕了,你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,在一次性合并到原来的分支上,这样,既安全,又不影响别人工作。

Git的分支与其他版本控制系统不同,无论创建,切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。

2,创建与合并分支

在版本回退里,我们已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支(master分支),HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。

① 一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD执行maser,就能确定当前分支,以及当前分支的提交点,每次提交,master分支都会向前一步:

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

可以看到,Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化。

③ 不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:

④ 假如我们在dev上的工作完成了,就可以把dev合并到master上。Git合并很简单,就是把master指向dev的当前提交,就完成了合并:

所以Git合并分支也很快,就改改指针,工作区内容不变。

⑤ 合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,我们就剩下了一条master分支:

下面开始进行实践:
首先,我们创建dev分支,然后切换到dev分支:

[[email protected] mygit]$ git checkout  -b dev
Switched to a new branch ‘dev‘
#git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
$ git branch dev
$ git checkout dev

然后,用git branch命令查看当前分支:

[[email protected] mygit]$ git branch
* dev
  master
#git branch命令会列出所有分支,当前分支前面会标一个*符号

然后,我们就可以在dev分支上正常提交,比如对test.txt文件做修改:

[[email protected] mygit]$ echo "create a new brach" >> text.txt
[[email protected] mygit]$ cat text.txt
# this is jonson first repo
create a new brach
然后提交:
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "branch test"
[dev e2d7f2d] branch test
 1 file changed, 1 insertion(+)

现在,dev分支的工作完成,我们就可以切换回master分支:

[[email protected] mygit]$ git checkout master
Switched to branch ‘master‘
[[email protected] mygit]$ git branch
  dev
* master
[[email protected] mygit]$ cat text.txt
# this is jonson first repo

切换回master分支后,在查看刚刚修改的文件,刚才添加的内容不见了。原因是那个提交是在dev分支上,而master分支此刻的提交点并没有变:

合并分支:
现在,我们把dev分支的工作成果合并到master分支上:

[[email protected] mygit]$ git merge dev
Updating 7646ab6..e2d7f2d
Fast-forward
 text.txt | 1 +
 1 file changed, 1 insertion(+)
[[email protected] mygit]$ cat text.txt
# this is jonson first repo
create a new brach

git merge命令用于合并指定分支到当前分支。合并后,再查看文件的内容,就可以看到,和dev分支的最新提交是完全一样的。

注意:上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master执行dev的当前提交,所以合并速度非常快,当然,也不是每次合并都是Fast-forward,后面会讲其他方式的合并。

#合并完成后,如果需要删除dev分支,可以执行以下命令:

[[email protected] mygit]$ git branch -d dev
Deleted branch dev (was e2d7f2d).
[[email protected] mygit]$ git branch
* master
#删除后,查看branch,就只剩下master分支了。

小结
Git鼓励大量使用分支:

查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>

3,解决冲突

人生不如意之事十有八九,合并分支往往也不是一帆风顺的。
1)准备新的分支(feature1)

[[email protected] mygit]$ git checkout -b feature1
Switched to a new branch ‘feature1‘

修改test.txt文件并提交:

[[email protected] mygit]$ echo "create two branch" >> text.txt
[[email protected] mygit]$ cat text.txt
# this is jonson first repo
create a new brach
create two branch
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "two branch"
[feature1 78292e2] two branch
 1 file changed, 1 insertion(+)

切换到master分支:

[[email protected] mygit]$ git checkout master
Switched to branch ‘master‘
Your branch is ahead of ‘origin/master‘ by 1 commit.
  (use "git push" to publish your local commits)
#git提示我们当前master分支比远程的master分支超前1个提交。

接下来,在master分支上也进行修改并提交:

[[email protected] mygit]$ echo "create a three branch" >> text.txt
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "three branch"
[master e27d699] three branch
 1 file changed, 1 insertion(+)

现在,master分支和feature1分支各自都分别有新的提交,变成了这样:

这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:

[[email protected] mygit]$ git merge feature1
Auto-merging text.txt
CONFLICT (content): Merge conflict in text.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了,Git告诉我们,test.txt文件存在冲突,必须手动解决冲突后再提交。git status可以告诉我们冲突的文件:

[[email protected] mygit]$ git status
# On branch master
# Your branch is ahead of ‘origin/master‘ by 2 commits.
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看test.txt的内容:

[[email protected] mygit]$ cat text.txt
# this is jonson first repo
create a new brach
<<<<<<< HEAD
create a three branch
=======
create two branch
>>>>>>> feature1

git用‘<<<<<<<’,’=======’, ‘>>>>>>>’标记出不同分支的内容,我们修改如下后保存:

[[email protected] mygit]$ cat text.txt
# this is jonson first repo
create a new brach
<<<<<<< HEAD
create two branch
=======
create two branch
>>>>>>> feature1

再提交:

[[email protected] mygit]$ git commit -m "new branch"
[master 966dd22] new branch

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

工作完成后,删除feature1分支:

[[email protected] mygit]$ git branch -d feature1
Deleted branch feature1 (was 78292e2).

小结:
当Git无法自动合并分支时,就必须解决冲突。解决冲突后,再提交,最后合并完成。

4,分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。下面来进行实践:
1)首先,仍然创建并切换dev分支:

 [[email protected] mygit]$ git checkout -b dev
Switched to a new branch ‘dev‘
[[email protected] mygit]$ git branch
* dev
  master

修改test.txt文件,并提交一个新的commit:

[[email protected] mygit]$ echo "create four branch" >> text.txt
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "add merge"
[dev e730d1b] add merge
 1 file changed, 1 insertion(+)

现在我们切换回master:

[[email protected] mygit]$ git checkout master
Switched to branch ‘master‘

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward

[[email protected] mygit]$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the ‘recursive‘ strategy.
 text.txt | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。合并后,我们用git log 看看分支历史:

可以看到,不使用Fast forward模式,merge后就像这样:

小结:
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。

5,Bug分支

软件开发中,必定会有bug。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。

当你接到一个修复一个代码101的bug的任务时,很自然的,你想创建一个临时分支来修复它, 但是,当前正在dev上进行的工作还没有提交:

[[email protected] mygit]$ echo "create five branch" >> text.txt
[[email protected] mygit]$ git status
# On branch dev
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   text.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   new-repo/
no changes added to commit (use "git add" and/or "git commit -a")

此时,问题出现了,工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:

[[email protected] mygit]$ git stash
Saved working directory and index state WIP on dev: e730d1b add merge
HEAD is now at e730d1b add merge


现在,可以查看工作区,可以看到就是干净的了,因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支(issue-101):

[[email protected] mygit]$ git checkout master
Switched to branch ‘master‘
Your branch is ahead of ‘origin/master‘ by 2 commits.
  (use "git push" to publish your local commits)
[[email protected] mygit]$ git checkout -b issue-101
Switched to a new branch ‘issue-101‘

现在修复bug,就假如需要把“create four branch”改成“create five branch”,然后提交:

[[email protected] mygit]$ sed -i ‘s/four/five/‘ text.txt
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "fix bug 101"
[issue-101 6484832] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后,切换到master分支,并完成合并,最后再删除这个临时分支:

[[email protected] mygit]$ git checkout master
[[email protected] mygit]$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the ‘recursive‘ strategy.
 text.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[[email protected] mygit]$ git branch -d issue-101
Deleted branch issue-101 (was 6484832).

这下问题解决了,原计划两个小时的bug修复只花了5分钟!现在,又可以接着回到dev分支干活了:

[[email protected] mygit]$ git checkout dev
Switched to branch ‘dev‘
[[email protected] mygit]$ git status
# On branch dev
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   new-repo/
nothing added to commit but untracked files present (use "git add" to track)

工作区此时是干净的,因为刚才的工作现场我们用git stash储藏起来了,可以用git stash list 命令看看:

[[email protected] mygit]$ git stash list
[email protected]{0}: WIP on dev: e730d1b add merge

所以现在我们需要恢复一下,有两种方式:
一种是用git stash apply 恢复,但是回复后,stash内容并删除,你还需要用git stash drop来删除。
另一种是用git starh pop,恢复的同时把stash内容也删了(所以一般采用这种方法):

再用git stash list 查看,就看不到stash内容了,并且也恢复到之前的工作状态:

#当你多次stash时,如果你要恢复指定的stash,用以下命令:
git stash apply [email protected]{0}

小结:
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除。
当手头工作没有完成时,先把工作现场git stash储藏起来,然后去修复bug,再git stash pop,删除stash内容,并恢复到工作现场。

6,多人协作

当你从远程库克隆时,实际上Git自动把本地master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。

#要查看远程库的详细信息,用`git remote -v`:
[[email protected] mygit]$ git remote -v
origin  [email protected]:sqm-sys/jonson-repo.git (fetch)
origin  [email protected]:sqm-sys/jonson-repo.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。

推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:

[[email protected] mygit]$ git push origin master
推送其他分支:
[[email protected] mygit]$ git push origin dev

但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?

  • master分支是主分支,因此需要时刻与远程同步;
  • dev 分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
  • bug分支只用于在本地修复bug,就没必要推到远程了,除非领导要看看你每周到底修复了几个bug;

抓取分支
多人协作时,大家都会往master和dev分支上推送各自的修改。

现在,模拟一个你的同事,可以在另一台电脑(注意要把SSH key添加得到GitHub)下克隆:

[[email protected] ~]$ git  clone [email protected]:sqm-sys/jonson-repo.git
Cloning into ‘jonson-repo‘...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 26 (delta 5), reused 25 (delta 4), pack-reused 0
Receiving objects: 100% (26/26), done.
Resolving deltas: 100% (5/5), done.

需要的注意的是,你的同事从远程库clone时,默认情况下,只能看到本地的master分支,而看不到其他分支:

[[email protected] ~]$ cd jonson-repo/
[[email protected] jonson-repo]$ git branch
* master

现在,你的同事要在dev分支上开发,就必须创建远程origin的dev分支到本地(可以执行以下命令):

[[email protected] jonson-repo]$ git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch ‘dev‘

此时,他就可以在dev上分支上进行修改了,然后,时不时的把dev分支push到远程:

[[email protected] jonson-repo]$ echo "create six branch" >> text.txt
[[email protected] jonson-repo]$ git add text.txt
[[email protected] jonson-repo]$ git commit -m  "add six branch"
[dev f50cefa] add six branch
 1 file changed, 1 insertion(+)
[[email protected] jonson-repo]$ git push origin dev
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 287 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To [email protected]:sqm-sys/jonson-repo.git
   c7d965a..f50cefa  dev -> dev

你的同事已经向origin/dev分支推送了他的提交,而此时你也对同样的文件作了修改,并试图推送:

[[email protected] mygit]$ git branch
* dev
  master
[[email protected] mygit]$ echo "ha ha ha " >> text.txt
[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "this is haha"
[dev 94c4cde] this is haha
 1 file changed, 1 insertion(+)
[[email protected] mygit]$ git push origin dev   #进行推送
To [email protected]:sqm-sys/jonson-repo.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to ‘[email protected]:sqm-sys/jonson-repo.git‘
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: ‘git pull‘) before pushing again.
hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.

推送失败,原因是你的同事的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们:先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:

可以看到git pull失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:

[[email protected] mygit]$ git branch --set-upstream-to=origin/dev
Branch dev set up to track remote branch dev from origin.

创建链接后,在执行pull:

[[email protected] mygit]$ git pull
Auto-merging text.txt
CONFLICT (content): Merge conflict in text.txt
Automatic merge failed; fix conflicts and then commit the result.

这回git pull成功,但是合并有冲突,需要手动解决,解决的方法之前的解决冲突完全一样(将冲突的内容进行修改)。解决后,提交,再push:

[[email protected] mygit]$ git add text.txt
[[email protected] mygit]$ git commit -m "merge & six branch"
[dev 4ba822d] merge & six branch
[[email protected] mygit]$ git push origin dev
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 616 bytes | 0 bytes/s, done.
Total 6 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To [email protected]:sqm-sys/jonson-repo.git
   f50cefa..4ba822d  dev -> dev

push成功,因此,多人协作的工作模式通常是这样:

1)首先,可以试图用‘git push origin <branch-name>‘ 推送自己的修改;
2)如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
3)如果合并冲突,则解决冲突,并在本地提交;
4) 没有冲突或者解决掉冲突后,再用‘git push origin <branch-name>‘ 推送就能成功;
如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令‘git branch --set-upstream-to=origin/<branch-name> ‘。
这就是多人协作的工作模式。。。

原文地址:https://blog.51cto.com/13972012/2485046

时间: 2024-10-10 04:11:57

分布式版本控制系统(git分支管理)的相关文章

[.net 面向对象程序设计进阶] (26) 团队开发利器(五)分布式版本控制系统Git——图形化Git客户端工具TortoiseGit

[.net 面向对象程序设计进阶] (26) 团队开发利器(五)分布式版本控制系统Git——图形化Git客户端工具TortoiseGit 读前必备: 接上篇: 分布式版本控制系统Git——使用GitStack+TortoiseGit 图形界面搭建Git环境 http://www.cnblogs.com/yubinfeng/p/5182271.html 本篇导读: 上篇介绍了一款Windows环境下的Git服务器工具GitStack ,搭建了最简单的Windows下的Git服务器,需要再次提醒的是

[.net 面向对象程序设计进阶] (25) 团队开发利器(四)分布式版本控制系统Git——使用GitStack+TortoiseGit 图形界面搭建Git环境【转】

转自:http://www.cnblogs.com/yubinfeng/p/5182271.html 前面介绍了两款代码管理工具VSS和SVN,这两种管理工具在很长一段时间曾为我们的代码管理提供了便利,本篇介绍一款思维方式完全不同(也可以说不合常理)的版本控制系统——Git.可以说Git目前非常火,这与设计者剑指偏锋的设计思想有很大关系.Git采用发散的思维管理代码,最大的特点就是分布式,他可以让来自不同地区的开发者共同完成一个作品,让每个开发者都可以发挥个性,同时又可以由发起者(即项目管理者)

分布式版本控制系统GIT的使用

一.什么是Git Git是一个分布式版本控制系统,Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的具体差异(如CVS.Subversion等).而Git并不保存这些前后变化的差异数据.Git更像是把变化的文件作快照后记录在一个微型的文件系统中.每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引.若文件没有变化,Git不会再次保存,而只对上传保存的快照做一次连接,即若文件未变化则指向上

分布式版本控制系统---Git&amp;GitHub

 GIT的起源 Git是一个开源的分布式版本控制系统,用以有效.高速的处理从很小到非常大的项目版本管理.Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件. Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具.开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作,因此 Torvalds 决定着手研究许可

分布式版本控制系统 Git 教程

目录   简介  原理  安装  配置  命令  小结  资料 简介 Git 是什么? Git 是一个开源的分布式版本控制系统. 什么是版本控制? 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统. 什么是分布式版本控制系统? 介绍分布式版本控制系统前,有必要先了解一下传统的集中式版本控制系统. 集中化的版本控制系统,诸如 CVS,Subversion 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文

分布式版本控制系统Git——使用GitStack+TortoiseGit 图形界面搭建Git环境

本篇导读: 可以说Git目前非常火,这与设计者剑指偏锋的设计思想有很大关系.Git采用发散的思维管理代码,最大的特点就是分布式,他可以让来自不同地区的开发者共同完成一个作品,让每个开发者都可以发挥个性,同时又可以由发起者(即项目管理者)统一发布新版本.各个地区的开发者,还可以离线开发,这样版本管理系统之所以火,也和当今社会万众创新的氛围分不开.通过Git你可以尽情的发挥想象力,开源的春天已经到来,让我们启航吧!  1. Git简介 名称:Git (Git的读音为/g?t/,开源.免费.分布式的版

分布式版本控制系统--Git使用

前言 花了点时间,学习Git版本管理工具,以前用过SVN比较之后,确实Git比SVN好用,更强大.简单总结了一些Git使用命令,如果想弄明白Git请猛击底下推荐学习网站. 使用总结 创建版本库: 初始化一个Git 仓库,使用git int 命令 添加文件到Git仓库,分两步: 第一步,使用命令git add ,注意,可反复多次使用,添加多个文件: 第二步,使用命令git commit,完成. 查看内容 要随时掌握工作区的状态,使用git status命令. 如果git status告诉你有文件被

分布式版本控制系统Git(二):github

前言 但凡是喜欢研究技术,或者听大牛们说起过的,都应该至少是听过github这个东西.具体就不介绍了,不了解的可以去了解了解,最主要的功能当然是代码托管啦,上面有各种各样的大牛写的项目.另外这一章不仅仅是说明如果跟github关联操作,因为github是远程版本库,实际上在公司中,也只是先给你一个远程版本库的地址给你,你自己去克隆,然后开发,所以下面操作,可以跟公司远程版本库操作一致. 连接github 1. 当然是注册github账号了 https://github.com 2. 创建SSH密

分布式版本控制系统Git的安装与使用

业来源:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE1/homework/2103 远程仓库地址是:https://github.com/BinGuo666/git 1.下载安装配置用户名和邮箱. 2. 创建工作目录并通过git init命令把这个目录变成Git可以管理的仓库. ls -a 命令可以发现工作目录下多了一个.git的隐藏目录,该目录是Git用于跟踪管理版本库的,别手动修改.git里的文件,免得破坏了Git仓库. 3. 在工作目录下准备文

分布式版本控制系统Git------分支管理与合并(merge与rebase)

零.需要使用到的命令: git branch                                  查看当前分支. git branch <name>                    创建一个名为<name>的分支. git checkout <name>                切换到名字为<name>的分支. git checkout -b <nama>             创建一个名为<name>的分