Git 部分场景下的应对办法-CSDN博客

前言

本文是在阅读小册 Git 原理详解及实用指南后简略总结，大家如果想要学习具体的原理，可以自行购买小册阅读。

正文开始前，首先声明一下：

本文的大部分案例都是基于 Feature Branching 工作流 的基础上
所使用的命令行工具为组合到VSCode内的 Git Bash

关于 Feature Branching 工作流，大致意思为，当项目需要添加新功能或者改 bug 的时候，在主分支 master 上创建一个新的分支 feature_a_branch 来进行编码，编码完成后将新分支合并到主分支上，最后删掉之前刚创建的 feature_a_brancn 分支

正文

案例一：

问题：

到公司之后，你匆匆吃了早餐，产品告诉你今天有一个新的功能要写完。接着，你熟练的在主分支 master 上创建了一个新分支

git checkout -b feature_a_branch
复制代码

开始了新一天的欢（keng）乐（die）编码~

touch feature_a_branch.js
//省略编码过程
复制代码

写着写着，你突然想起一件事，原来昨晚同事 xxx 告诉过你 master 分支上的 test 文件有个bug。。。想到这里，你不得不停止编码，因为新功能是基于 master 分支而开发的，所以必须先改好 master 分支的 bug 才能开发新功能。但是，目前的情况是你已经在 feature_a_branch 分支上开发了一大半新功能了，总不能把新功能的代码全删了，然后回到 master 分支上改完 bug 再重新创建一个 feature_a_branch 分支后从头开发吧？

解决办法：

首先，存一下新写的代码（其实有更方便的存储办法， git stash 了解一下）

git add feature_a_branch.js
git commit -m "临时存一下，回头再来开发"
复制代码

然后，切换到master分支，改 bug （其实这个算违规操作，改bug理应再开一分支，但是这里为了节约时间所以在master上直接改代码）

git checkout master
//省略更改过程
git add test.txt
git commit -m "修复 啥啥啥 bug"
复制代码

两张图中，图上是模拟bug修改前，下图是模拟bug修改后。 后面显示的 从磁盘中删除 这是 VSCode 里面的显示效果。产生的原因是：切换回 master 分支后，feature_a_branch.js文件就不见了，因为这个文件是在其他分支上创建的， master 分支上并没有该文件的记录信息，所以呈现了图中的效果

接着，我们切换到 feature_a_branch 分支上，给它一个 rebase（它的中文名：变基） 操作

git checkout feature_a_branch
git rebase master //变基变基，就是改变它的基（ji）点（you），原本是跟着旧的 master ，现在跟新的 master 了
复制代码

最后，我们打开这两个文件，发现已经完成了我们要解决的问题

案例二：

问题：

饭点到了，你终于把新功能的代码全部完成，同时已经完成了add操作，准备commit操作过后去吃个午饭然后小睡一会，在commit操作按下回车键之后，你才记起来代码里面的console.log(...)忘记去掉了，因为这点小问题再commit一次，会不会被人说自己太粗心了，不行，我必须赶紧想个办法！

解决办法：

很简单，改完代码后看下面的灰色框框

git add feature_a_branch.js
git commit --amend --no-edit
复制代码

修改后查看 git log 你会发现，还是同样的配方，还是同样的 commit 信（wei）息（dao），根本没人发现你是一个粗心的人~ （此话纯属开玩笑，写代码还是细致一点比较好。。。）

案例三：

问题：

不知不觉又到了下班的时候，把代码 merge 到 master 分支后就可以完工了

git checkout master
git pull //操作 master 前先 pull 一下，养成好习惯
git merge feature_a_branch
复制代码

接着，你像往常那样删除开发新功能时创建的分支

git branch -d feature_a_branch //删除本地分支
复制代码

刚打算 git push 的时候又想起一个事，xxx说，明天要看我新分支上次的提交情况，糟糕，咋恢复啊。。。

解决办法：

首先，查看一下仓库的整体操作记录

git reflog
复制代码

红色标记的地方之前的操作是 feature_a_branch 分支上的提交记录，标记的地方是移动分支的操作，再往后就发生了合并两个分支的操作记录...

现在我们找到了 feature_a_branch 分支上的最后一次操作记录后，我们可以通过 checkout 这个神奇的指令，使代码还原到当时的情况

git checkout 357d05d
git checkout -b feature_a_branch
复制代码

此刻查看 commit 信息，我们会发现先前被删除的分支还原回来了

git log
复制代码

在这里想提一下， git reflog 不一定能把每一次的操作记录都能找到，因为 Git 存在回收机制，如果删除的时间已经过了很久，很有可能找不到对应的 commit 记录。

总结

其实还有很多很多 git 操作相关的小（sao）技(cao)巧(zuo)，正如小册里面说的， Git 真的是一个易上手，难精通的工具。想要用好除了理解好常用命令的真正含义外，还需要自己的动手实践，在多人协作的项目里， Git 永远是一个无法回避的技术栈。