0


你好! Git——分支管理

git 分支管理(3)

在Git里,master分支也叫主分支。
HEAD 严格来说不是指向提交,⽽是指向master,master才是指向提交的,所以,HEAD 指向的就是当前分⽀。
在这里插入图片描述
每次提交,master分⽀都会向前移动⼀ 步,这样,随着你不断提交,master分⽀的线也越来越⻓,而HEAD只要⼀ 直指向master分⽀即可指向当前分⽀。

一、创建、切换、合并、删除分支

创建分支并切换的指令:

git checkout -b dev1

1.1 创建分支

HEAD指向的分支就是我们当前工作的分支

查看当前所有分支指令:

git branch

创建分支指令:

git branch dev//创建dev分支

在这里插入图片描述
*代表的是当前指向的分支

1.2 切换分支

切换分支指令:

git checkout dev

在这里插入图片描述

在当前分支对文件进行add ,commit操作,HEAD指向了当前最新的提交,别的分支并没有这个提交,如果切换到别的分支,是看不到这个提交得。

1.2 合并分支

切换当前分支然后合并掉需要合并的分支。
合并分支的指令:

git merge 被合并分支的名字

在这里插入图片描述

git merge命令⽤于合并指定分⽀到当前分⽀。合并后,master 就能看到dev 分⽀提交的内容了。Fast-forward 代表“快进模式” ,也就是直接把master指向dev的当前提交,所以合并速度⾮常快。 当然,也不是每次合并都能 Fast-forward,我们后⾯会讲其他⽅式的合并。

1.2 删除分支

删除分支指令:

git branch -D 删除的分支名字

在这里插入图片描述

如图可知,使用git branch -D dev 指令后,dev分支就被删掉了

二、合并冲突

创建分支并切换的指令:

git checkout -b dev1

2.1 合并分支

  1. 这是dev1分支在这里插入图片描述
  2. 这是master分支在这里插入图片描述
  3. 合并分支 合并分支的指令:
git merge 分支名

merge冲突需要手动去解决,解决冲突后,需要进行一次add,commit提交操作。

在这里插入图片描述

合并分支,产生了合并冲突,我们需要进入文件,手动修改冲突。

在这里插入图片描述

手动解决冲突后,我们需要把改动的信息再次add、commit一下,然后查看在上次提交后有没有修改。

2.2 合并模式

  1. 我们可以用图形化的方式查看分支情况
git log --graph --pretty=oneline --abbrev-commit

在这里插入图片描述
2. 合并有两种模式
通常合并分⽀时,如果可能,Git 会采⽤ Fast forward模式(合并后需要进行修改信息提交)。
删除分⽀后,查看分⽀历史时,会丢掉分⽀信息,看不出来最新提交到底是 merge 进来的还是正常提交的。
在这里插入图片描述
非 Fast forward模式(不需要进行提交)
指令是:

git merge --no-ff -m "描述修改文件的信息" 被合并的分支名

在这里插入图片描述

三、分支管理策略

3.1 分支策略

⾸先,master分⽀应该是⾮常稳定的,也就是仅⽤来发布新版本,平时不能在上⾯⼲活;那在哪⼲活呢?⼲活都在dev分⽀上,也就是说,dev分⽀是不稳定的,到某个时候,⽐如1.0版本发布时,再把dev分⽀合并到master上,在master分⽀发布1.0版本;你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活,每个⼈都有⾃⼰的分⽀ ,时不时地往dev分⽀上合并就可以了。

团队合作的分⽀看起来就像这样:
在这里插入图片描述

3.2 bug分支

假如我们现在正在dev2分⽀上进⾏开发,开发到⼀ 半,突然发现 master 分⽀上⾯有 bug,需要解决。 在Git中,每个 bug 都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀ ,然后将临时分⽀删除。

  1. dev2的代码在⼯作区中开发了⼀ 半,还⽆法提交,怎么办? Git 提供了git stash命令,可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。(前提条件是工作区的信息,一开始就被git跟踪控制了,如果是新文件,没有add,commit进行提交,那么这个文件不能被控制,也就是说,git stash不能将工作区的信息进行存储)
  2. 创建一个新的分支,用来处理bug(git checkout -b fix_bug),bug修复完毕后,需要add commit 操作。
  3. 切换到master分支上,我们可以进行分支合并了(修复好bug的分支)git merge --no-ff -m"merge fix_bug branch" fix_bug,最后删除fix_bug分支。
  4. bug 的修复⼯作已经做完了,我们还要继续回到dev2分⽀进⾏开发,怎么恢复工作区信息

1.刚才的⼯作现场存到哪去了?用git stash list命令看看
2.git stash pop命令可以恢复工作现场,恢复的同时会把stash也删掉。
3.恢复现场也可以采⽤git stash apply恢复,但是恢复后,stash内容并不删除,你要⽤ git stash drop 来删除。
4.可以多次使用stash来进行恢复,先用git stash list查看,恢复的时候可以指定stash,⽤命令git stash apply stash@{0}

  1. 恢复完代码之后我们便可以继续完成开发,开发完成后便可以进⾏add,commit提交。
  2. 因为master分⽀⽬前最新的提交,是要领先于新建 dev2 时基于的master分⽀的提交的,所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。如何解决?

解决这个问题的⼀个好的建议就是:最好在⾃⼰的分⽀上(dev2)合并一下master分支,再让master分支去合并dev2,这样做的⽬的是有冲突可以在本地分⽀(dev2)解决并进⾏测试,而不影响master分支。

3.3 删除临时分支

如果我们开发一个功能开发到一半(每个功能都是不同分支),突然就不需要开发了,这时候feature分支必须销毁,传统的命令删除分支指令是不行得(git branch -d feature),我们需要用到强制删除分支的指令(git branch -D feature)。
在这里插入图片描述

创建分支并切换到feature分支,在该分支下写一个功能
在这里插入图片描述

假如我们功能写到一半,然后突然不需要这个功能了,这时候要删除这个功能
1.打印这个功能代码,让我们知道这里面有数据
2.这个些数据,我们已经提交一部分到版本库里了(已经被git版本库跟踪)
3.查看本地仓库有几个分支
4.切换分支到master
5.删除分支,我们发现删除不了分支
6.这时候我们用强制删除分支指令
7.查看本地仓库有多少分支,发现feature分支已经被强制删除了。

四、小结

分⽀在实际中有什么⽤呢? 假设你准备开发⼀个新功能,但是需要两周才能完成,第⼀周你写了50% 的代码,如果⽴刻提交,由于代码还没写完,不完整的代码库会导致别⼈不能⼲活了。 如果等代码全 部写完再⼀次提交,⼜存在丢失每天进度的巨⼤⻛险。
现在有了分⽀ ,就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀ ,别⼈看不到,还继续在原来的分⽀上正常⼯作,⽽你在⾃⼰的分⽀上⼲活,想提交就提交,直到开发完毕后,再⼀次性合并到原来的分⽀上,这样,既安全,⼜不影响别⼈⼯作。
并且Git ⽆论创建、切换和删除分⽀,Git在1秒钟之内就能完成!⽆论你的版本库是1个⽂件还是1万个⽂件。


本文转载自: https://blog.csdn.net/plj521/article/details/140575201
版权归原作者 一个小脑袋 所有, 如有侵权,请联系我们删除。

“你好! Git——分支管理”的评论:

还没有评论