Git高手必备：掌握这些指令，轻松玩转版本控制（三）

Git 分支管理

1.分支创建

git branch 查看所有分支及当前分支

git branch+分支名  创建一个分支

 git chekout +分支名  调到另一个分支

git checkout - 返回上一个分支

git checkout -b +分支名  创建该分支并调到该分支

 由此可见，箭头所指的括号也能看出当前分支是哪个

注意，在其中一个分支上例如添加一个文件到工作区，还记得ll -a命令吗，能够查看当前目录下的状态，那我们就会发现每一个分支都能看见这个分支上撰写的位于工作区文件，但是如果在这个分支上把这个文件提交了，那么这个文件在其他分支上就看不到了。如何能看到，可以使用下面的合并分支。

2.删除分支

不能删除自己所在的分支，例如当前分支为dev，会跳出如下提示

 可以删除一个合并后的或者不需要的分支，也可以跳转到master再删

正在使用中：如果分支正在被开发团队使用，例如正在开发新功能或者修复紧急bug，那么不能删除这个分支，以免影响正在进行的工作。

未合并的更改：如果分支上有未合并到主分支或者其他长期分支的更改，删除这个分支会导致这些更改丢失。

保护分支：在许多版本控制系统中，如Git，可以设置保护分支来防止意外修改或删除。如果分支被设置为保护状态，那么它不能被常规方式删除。

3.合并分支

我们把dev合并到master上

这个时候 hello.txt 是在 dev上

我们发现master上也有，这是因为hello.txt在dev上尚未提交

这时发现在master上和dev有关的文件都没了

 我们使用git merge +文件名  合并该分支

这时候发现原来消失的文件又出现了

4.分支的本质

master指向的是提交

HEAD是指向当前的分支，当前在哪个分支就指向哪个分支

以前我们一直在master上进行操作，HEAD指针就一直指向master

这次我们尝试着对dev分支进行操作。第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev

我们可以用cat  .git/HEAD命令查看当前HEAD指针的指向，master用cat HEAD

如果dev发生修改提交，dev的版本就会向后移动。

在master分支上如果合并就会出现下面的图

4.分支的冲突

如果两个分支同时对一个文件进行操作那么就会产生分支冲突

这时候我们使用cat命令查看hello.txt

<<<<<<<<<<<HEAD是当前分支指向的修改

>>>>>>>>>>> dev 明确告诉我们非当前分支dev的修改 

把想要修改的内容手动修改

我们可以通过图形来查看冲突的提交日志

这张图直观地表现了发生冲突到解决冲突 

Git stash

以下是两个应用场景

1.当正在dev分支上开发某个项目，这时项目中出现了一个bug，但是正在开发的内容只是完成一半，还不想提交，这时可以用 git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。

2.由于疏忽，本应该在dev分支开发的内容却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash命令将内容保存至堆栈之中，切回到dev分支后，再次恢复内容即可

总的来说 ，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复堆栈中的内容。这也就是说，stash中的内容不仅可以恢复到原先开发的分支，还可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中

注：

1. 分支管理：在现代的版本控制系统中（如Git），通常会使用多个分支来管理不同阶段的代码。主分支（通常是master或main）用于存放稳定、可发布的代码，而开发分支（如develop）用于集成新功能。

2. Hotfix分支：当在生产环境中发现了一个需要立即修复的严重bug时，会从主分支（master/main）上创建一个名为hotfix的分支。这个分支专门用于修复这个bug，而不影响其他正在开发中的功能。

我们在master里修改了hello.txt文件，想要切换回dev分支的时候出现了问题，提示我将这个修改提交或者先把修改的内容推入栈再切换。

这时我们用到git stash ，会把修改的内容先保存，然后我们就能够切换到其他分支

 

git stash list 

能看到上次保存的操作

我们同样可以再次修改文件去做stash ，保存记录＋1

如果要将堆栈中的文件恢复过来咋搞

git stash pop 

 

注意：假设你现在有两次stash，你想做两次pop，那么第二次pop得在第一次pop之后进行，否则会报错 

分支管理策略

         master：git默认主分支（这里不作操作）。

         stable：稳定分支，替代master，主要用来版本发布。

         develop：日常开发分支，该分支正常保存了开发的最新代码。

         feature：具体的功能开发分支，只与 develop 分支交互。

        release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。

         bugfix：线上 bug 修复分支。

1.主分支

        因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。

             stable分支：用来发布，管理着多个稳定的版本。

             develop分支：就是我们日常开发的分支。

       使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

2.辅助分支

       通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等。

 feature分支

       feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。

       比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。

release分支

       release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。

       为什么从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。

bugfix分支

        bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。