github分支管理

github分支管理

在git中，每当我们

commit

的时候，git将会把提交的时间串成一条线，这条线就是一个分支，也就是主分支，也叫

master

分支（默认情况下）。严格来说，

HEAD

并没有指向提交，而是指向了

master

，

master

指向的提交。每次提交的时候，

master

就会将当前提交时间串在时间线上，并且指向当前时间点，随着不断的提交，

master

分支也越来越长，当我们使用

git log

命令的时候，查看到的就是这条时间线。

当我们创建一个新的分支，比如叫

dev

，现在

dev

指向的提交就是

master

指向的提交，但是

HEAD

现在指向

dev

，现在我们再提交的时候就是提交在

dev

分支了，而

master

分支不变。当我们在

dev

分支上完成开发工作，检查无误后，就可以将

dev

分支

master

分支上了。

应用场景：当我们的软件开发完成1.0版本后，现在有了新的需求，要开发2.0版本。但不幸的是，在开发到一半的时候，1.0版本发现了几个bug，没办法，改吧，但是我们显然不能再现在的工程基础上修改，如果在现在工程上修改的话，1.0版本的软件将会带有部分2.0版本的特性或者功能，成了1.5版本。这时候，我们在完成1.0版本后，就可以新建一个分支，在新的分支上进行新的开发，在确认完成后，再合并到主分支。

操作如下：

1.创建并切换到新的分支

git checkout -b dev

-b

参数表示创建并切换到新的分支，相当于下面两条命令

git branch dev
git checkout dev

然后使用

git branch

命令查看所有的分支，在当前所在的分支上会有

*

提示，如下：



现在我们处于

dev

分支下，

Test.txt

文件里面没有任何内容，对

Test.txt

进行修改并提交。

git add Test.txt
git commit -m "branch test"

2. 合并分支

然后切换到

master

分支，再去查看

Test.txt

文件中的内容，发现是空白的。这是因为我们提交的内容在

dev

分支上，

master

分支并没有做什么改变。效果如下图：



然后对两个分支进行合并,合并完成后删除

dev

分支

git merge dev
git branch -d dev

合并完成后发现

Test.txt

文件内容与

dev

分支下的完全相同

3. 合并时的冲突

不幸的是，没有什么是一帆风顺的，合并时遇到了冲突怎么办？系统给出了这么个提示

D:\GitRepositorys [master]> git merge dev
warning: Cannot merge binary files: Test.txt (HEAD vs
Auto-merging Test.txt
CONFLICT (content): Merge conflict in Test.txt
Automatic merge failed; fix conflicts and then commit
D:\GitRepositorys [master +0 ~0 -0 !1 | +0 ~0 -0 !1]>

这个冲突貌似只能手动修改，打开冲突的文件，查看冲突提示，手动修改完成后再提交、合并

（其实我也不大懂，只是建议不要在两个分支上同时修改同一个文件）

4 分支管理策略

4.1 分支合并模式

通常情况下，git在合并分支的时候会用

Fast forward

模式，但是在这种模式下，删除分支后，会丢掉分支信息，也就是分支提交的信息，如果强制禁用

Fast forward

模式，git在葛冰分支的时候会生成一个新的

commit

，语法格式如下（将dev分支合并到master分支上）：

git merge --no-ff -m "禁用Fast forward 模式合并分支" dev

4.2 分支策略

首先，

master

分支是非常稳定的，也就是仅仅用来发布新的版本。

其次，从

master

分支上创建一个新的分支（dev），每个开发人员都有自己的分支（从dev分支上创建的），推送代码时只要将自己的分支和dev分支合并就可以了，

最后，当药发布新版本时，只需要将dev分支合并到master分支就可以了

4.3 bug分支

当你正在进行开发时，突然间发现了以前的一个bug，需要立刻修复，但是你现在的开发工作还没有完成，没有办法提交，git提供了一个

stash

功能，可以把当前场景保存起来，等以后可以恢复现场：

git stash

，现在用

git status

查看工作区，是干净的了，可以创建一个新的分支（首先要确定从哪个分支上修复bug），修复完成后，合并并删除bug分支。

现在我们需要恢复现场，使用

git stash list

命令来查看保存了哪些现场，恢复现场有两种方式，一是用

git stash apply stash@{NUM}

或者是用

git stash pop

，区别是前者不会删除stash，恢复现场后需要收到执行

git stash drop

来删除。当然，也可以多次stash然后使用

git stash apply stash@{num}

来恢复指定的现场。

5. 多人协作

5.1 克隆仓库

当你从远程仓库克隆时，实际上Git自动把本地的

master

分支和远程的

master

分支对应起来了，并且，远程仓库的默认名称是

origin

。

要查看远程库的信息，用g

it remote：

$ git remote
origin

或者，用

git remote -v

显示更详细的信息：

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

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

5.2 推送分支

推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

5.3 抓取分支

多人协作时，大家都会往

master

和

dev

分支上推送各自的修改。当我们从远程仓库克隆的时候，我们只能看到本地

master

分支，如果我们要在其他分支上开发，就必须创建

origin

的其他分支到本地，或者说建立远程分支和本地分支的关联:

git checkout -b dev origin/dev

,然后，我们就可以在

dev

分支上继续修改，然后将修改后的项目推送到远程

6. 标签管理

6.1 创建标签

首先切换到需要打标签的分支上，

git checkout branch-name

,

然后使用命令

git tag <name>

就可以了，默认标签是打在最新提交上的，如果我们想要打在以前的提交上，可以使用

git log

查看以前提交的commit id，然后使用

git tag <name> <commit id>

就可以了。可以使用命令

git tag

查看标签，但是标签不是按照时间顺序排序的，而是按照字母顺序排序。在打标签的时候可以带有说明，语法格式如下：

git tag -a <tag-name> -m "comment" <commit id>

使用命令

git show <tag-name>

可以查看详细信息。

6.2 删除标签

如果标签打错了，可以使用

git tag -d <tag-name>

来删除指定的标签，默认情况下，标签不会自动推送到远程。如果想把某个标签推送到远程，可以使用

git push origin <tag-name>

，或者一次性推送所有本地的标签:

git push origin --tags

,如果标签已经推送的远程仓库，想要删除远程仓库的标签需要如下两步:

首先删除本地标签

git tag -d  <tag-name>

然后从远程删除

git push origin :refs/tags/<tag-name>