2024年大数据最全Git 指令深入浅出【2】—— 分支管理，2024年最新目前最稳定和高效的UI适配方案

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

git checkout

![image.png](https://img-blog.csdnimg.cn/img_convert/ba3285bab0d9cf7af085165f0effa070.png)


**切换工作分支后**，在未合并分支之前，分支之间不会影响

新分支提交

git add
git commit -m “test new branch”
git log --graph

![image.png](https://img-blog.csdnimg.cn/img_convert/6d1873d9ed0a86c60d128fc1756587bb.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/50cbff1737c2a3f3d49c088f85d5aa2c.png)

删除分支（强制 与 非强制）

git branch -d
git branch -D # 强制删除 可以通过 git branch --help 自行查看

删除远程分支

git branch -d -r /

![image.png](https://img-blog.csdnimg.cn/img_convert/834325d1d95220c5f387cc4753655cac.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/b7448fa07b21c289cfcb3f9b5041dff8.png)


强制删除会带来什么结果呢？上方已经给出提示了“分支`dev`没有完全合并”，这就意味着在分支上新创建的文件都不会被保留下来，自然也不会有提交记录了。**写完代码之后直接就删除分支肯定是不合理的，需要合并到**`**master**`**之后再删除无用分支才正确。**

ls
git log --graph

![image.png](https://img-blog.csdnimg.cn/img_convert/9b63ad9a350f35217a4599dfab620fe3.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/24466cf17814ad1e9d16e18e037b4764.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/b8dcb106de48bb6e1f0bf9e74d81901f.png)

显示关于远程仓库的信息，包括分支是否跟踪

git remote show origin # origin 是远程仓库名

![image.png](https://img-blog.csdnimg.cn/img_convert/8de33068e682ec764f0bfd1ece4fce59.png)

移除本地仓库中远程仓库已删除的分支

git remote prune

### 2. 合并分支

git branch dev # 创建新分支
git checkout dev # 切换至新分支
#-------------------------------------
git checkout -b # 创建并切换到新分支（上两条指令 2合1）

在 新分支 下创建文件并提交

touch file7
git add file7
git commit -m “merge and delete file7”

![image.png](https://img-blog.csdnimg.cn/img_convert/e979e2ab5ad2478994c635e15714f7f7.png)

合并分支

git checkout master
git merge dev
git branch -d dev

请注意看下方的两个部分。第一次，笔者尝试在`dev`分支上合并`master`分支，然后再删除`dev`分支。但很明显这是错的，如何刚刚把代码合并到`dev`分支，又马上删除`dev`那这样的合并还有什么意义呢？所以，正确的做法是：


* 切换到 要 **“合并到”**的分支。此处我们要**合并到**`master`**分支上**
* 合并分支
* 删除无用分支


![image.png](https://img-blog.csdnimg.cn/img_convert/b9fa38dbc843936a3594da9b95488e1f.png)![image.png](https://img-blog.csdnimg.cn/img_convert/fd0a1b37e1f1b78d54410d9f6b137eb7.png)



#### 合并冲突


因为是多人协作，合并冲突的发生几乎是不可避免的。但是为什么会产生冲突呢？**因为开发人员修改了同一份文件**，但 Git 不知道以谁的文件为标准保留，因此就将这个冲突交给开发人员来解决。我们举一个现实中的例子：`master`分支的代码出现线上Bug，于是开发人员修改之后把修改的代码提交上去，此时的代码是最新最安全的；而其他开发人员在开发之初，拉取的是原本有Bug的`master`分支，这是就很有可能发生冲突。  
下面的图可以很直观的反应冲突现场：  
![image.png](https://img-blog.csdnimg.cn/img_convert/985100c12c850a0f9983480b53dde776.png)

冲突现场准备

git checkout -b dev
ls
vim file7 # 随便写点东西保存
git add file7
git commit -m “dev-file7”

git checkout master
vim file7 # 随便写点东西保存
git add file7
git commit -m “master-file7”

![image.png](https://img-blog.csdnimg.cn/img_convert/a1481ece4aac95845941ba2e5a18f5b3.png)

发生冲突

要 “合并到”master分支，所以是在 master分支 上合并 dev分支

git merge dev
cat file7

![image.png](https://img-blog.csdnimg.cn/img_convert/a3dc55987e69067b34b5023052135c46.png)  
直接看下图，我们很好理解发生冲突之后的变化。最后，**我们只要确保文件上的内容是我们想保存的即可。**  
![image.png](https://img-blog.csdnimg.cn/img_convert/6eaae98d0210382980c3bbfa40bac9a8.png)

解决冲突

vim file7
cat file7 # 这是笔者想保留的内容（即 两个分支都增加的内容）
git add file7
git commit -m “解决file7的分支冲突”
git merge dev

需要注意的是：**在手动解决冲突之后，需要再次提交文件**  
![image.png](https://img-blog.csdnimg.cn/img_convert/7d0393c5efe6677ac3417de1aefb9ac6.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/5259dc36255af746281b05605f2ff52c.png)



##### 合并模式


在正式讨论合并模式之前，我们先看看之前我们实验过的图。如果只看上面那张，我们可以很清晰的感受到，最新的代码是由`dev`分支合并而来的。  
![image.png](https://img-blog.csdnimg.cn/img_convert/31cd6a81d90820872f8b588e4704f621.png)  
但是，我们用`git log --graph`打印出来的图却没有这样色彩分明的线条，这时我们**怎么区分最新的代码是**`master`**分支修复后的结果？还是**`dev`**分支合并后的结果呢？**  
![image.png](https://img-blog.csdnimg.cn/img_convert/1174f896a569592df9e484ebd15475f7.png)


这就要讲到**合并模式**相关的知识了。我们上方所用的**合并模式是**`ff -- Faster Forward`**快速合并模式**。这种模式是无法看到最新的提交时是`commit`得来还是`merge`得来。如果想要区分，可以**使用**`no-ff`**即 非快速合并模式。**

git merge --no-ff -m “merge dev” dev

![image.png](https://img-blog.csdnimg.cn/img_convert/b14cf47bbca86786a2c9a6841c185382.png)  
![image.png](https://img-blog.csdnimg.cn/img_convert/d0b9518f81a44df7ab894ab4603299b5.png)



### 3. 实战演习


演习内容：在开发过程中遇到紧急Bug需要处理，需要保存当前开发分支内容去修复Bug，修复完成后完成开发，最后合并到主分支上。

保存工作区内容

git checkout dev
ls
vim file8
cat file8
git add file8
git stash # 未commit，将工作区的内容保存

![image.png](https://img-blog.csdnimg.cn/img_convert/dc37ec135570e624ff03e3eeb2b37e4f.png)  
使用`git stash` 保存的内容是可以在`.git`中看到的

查看保存内容

cd .git/refs
cat stash
git cat-file -p ‘序列化ID’

![image.png](https://img-blog.csdnimg.cn/img_convert/3415e5ff0d7da2a217aa9d8776801891.png)

修复master分支Bug

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

91950536)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！