【编程导航】我在工作中是如何使用git的？

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励。

前言：网上有个段子，新入职的员工因为不会使用git，第二天就被开除了。想起东东吖曾经刚入行那会儿也被这简简单单的几个命令困惑过。怎么合并代码呀？怎么解决冲突呀？怎么回滚代码呀？

接下来就讲讲我在工作中怎么使用git的吧，如果你是单人开发，随你怎么玩，几乎不会出现上面的问题，但是如果是多协同开发，那你就得注意啦。

使用git我一般注意两点：

①一定要自己新建一个分支，不要和别人共用分支开发，然后把自己写的功能提交到这个分支，并推送到远程。

②做好第一点之后，远程仓库就有了你的代码，只要你不再推送到远程，本地随便你怎么玩，如果玩到中途哪一步卡住了或者懵逼了，大不了，删掉项目，再从远程重新拉。

以下是我在工作中使用git的一些场景和相关基本操作。

场景一：入职一家新公司一周了，项目也熟悉得差不多了，leader给你安排了一期需求，需求评审一周完成。

如果公司的项目以develop分支为测试环境分支，并设置了权限，合并到此分支必须申请合并。（每个公司情况不同，视情况而定）

①我一般在远程仓库上新建一个分支xxx-feature,xxx一般命名为相关功能或者你的名字，这里我是以master为源分支（稳定版本，和线上版本一致）,稳定分支一定要和线上版本保存一致，并设有权限，不然在我看来，版本控制就是有问题的，至少来说是不规范的，存在风险的。这里xxx以我的名字命名，为什么要新建分支，后面会讲。

②拉取指定分支： git clone -b xxx-feature(分支名) xxx.git

当显示100%则为拉取代码成功：

然后下载相关依赖包，把项目跑起来，做相关功能需求。一天过去了，当你准备下班时，就可以提交代码了。提交之前，你可以利用vscode的源代码管理，对比所改文件以及具体代码，确认没有问题之后，准备提交代码。假如你当天添加了两个文件aaa.vue，bbb.vue，修改了文件xxx.vue,你只想提交新增的aaa.vue和修改xxx.vue文件，不想提交bbb.vue文件。

②查看变更的文件的状态： git status（此时变更的文件是红色的）

③把文件添加到暂存区，再次查看变更文件的状态：（如果只想提交部分文件就需要切换到对应文件目录执行命令，分别提交，如何想把全部改动的文件提交，在项目根目录执行命令即可，此时被提交到暂存区的文件是绿色的，未被提交到暂存区的文件还是红色）

git add .
git status

⑥将暂存区的内容添加到本地仓库： git commit -m "备注信息"

⑦将本地分支版本上传到远程并合并： git push

显示100%即为推送到远程仓库成功：

我们还可以到远程仓库去验证一下：

场景二：一周时间到了，你的需求也做完了，需要把当前分支请求合并到dev分支打包到测试环境，让测试工程师测试相关功能是否存在bug。当你正准备请求合并分支的时候，发现你自己的分支比要合并的分支落后提交了。这是由于同事也在合并代码到develop分支，导致你有多次落后提交，你肯定不能直接合并，这样可能会把同事的代码冲刷掉，这也是为啥在develop分支就要开始设置权限的原因之一，而且还可能产生冲突，你需要把develop先拉到本地，进行合并，然后再提交推送到当前分支的远程仓库，让当前分支的远程仓库去请求合并分支develop分支。

①先切换到develop分支（我们公司develop分支命名为DVE，具体以公司实际为准） git checkout DEV

②拉取最新的develop代码 git pull

③ 切换到当前分支 git checkout xxx-feature

有没有切换成功，可以通过VScode左下角查看：

如何你在切换分支的过程中，忘记了分支的名字，或者你没有在vscode里面执行命令，你还可以用git branch -a 查看本地所有分支和当前分支，绿色为当前分支。

④把develop分支合并到当前分支 git merge DEV

tips：前面我说过为啥要先建一个分支，原因就在这儿，如果你和别人共用一个分支，那么你在合并代码的时候也需要在本地建一个临时分支，然后用git merge合并，不建议直接用git pull合并，git pull 有可能会把自己的代码冲刷掉。而且你每次推送都要合并，比较麻烦，还会涉及上线排期，版本控制等问题。如果你们共用一个分支，多次合并过代码提交，那就只能共进退了。而每个人一个分支，可以独立上线，灵活排期。

⑤解决冲突：这个时候有可能产生冲突，没有产生冲突就不用管，如果产生了冲突，也不要慌，冲突产生的原因是同一行代码，被同时更改了，这个时候找到对应的修改人，相互讨论。它可以保留传入修改，也可以保留当前修改，还可以保留双方修改，然后手动解决冲突。这点迷惑的同学可以自己去模拟冲突哦，我最初在这也很迷惑，自己主动解决两次就知道怎么回事了，到真正有冲突的时候就不用怕了。

⑥合并完分支后，最好在本地跑一跑项目，看看有没有问题，之后需要重新提交代码(重复场景一的步骤，简洁版如下)

git add .

git commit -m "备注信息"

git push

⑦请求合并分支。（一般比较重要的分支，都会有权限，比较规范的就是从dev分支开始就要有权限，不能直接合并，你只能发起请求合并，待leader审核之同意合并后才能合并相关分支。在请求合并之前，你需要先看看自己的分支有没有落后提交。如果有落后提交，一定要先在本地合并，看看有没有冲突，千万不要直接合并，有可能会把同事的代码冲掉。）

场景三：测试过程中发现重大bug，且短时间内无法解决，但又不能影响其他同事的需求上线，需要回滚代码。有时上线后，发现重大bug或者其他突发事件，也需要回滚代码。

①查看提交的版本： git log

log之后会出现版本号，comit 后面即为版本号，下面是我模拟的几次提交，然后按q退出。

②回滚代码 git reset --hard 版本号

比如回滚到开发A功能之前

③git log验证一下，此时已经回滚到最初的版本，然后git push 推送到远程仓库

除了向前回滚，还可以向后回滚，比如两天后，后端工程师修复了重大这个bug，你又需要回滚到上一次开发好的版本。向后回滚和向前回滚类似。

①查看提交的版本： git reflog （此命令与git log 类似，都是查看版本号，但一个是向前查看版本，一个是向后查看版本）

②回滚代码 git reset --hard 版本号

③git log验证一下，然后git push 推送到远程仓库

场景四：开发一个功能时，由于太菜难免修修补补产生多次commit,都是同一个功能，提交多次commit没有必要，也不利于追溯，看着一长串提交记录显得更菜，提交记录杂乱无章，leader也只想看你做了啥功能，没有人愿意看你反复修复bug产生的多次commit,那么我们需要合并多个提交记录，让提交记录变得清爽。

以下是我模拟的多次提交记录，但这几次提交其实就只有一个目的，开发了A功能。其他提交记录是多余的，需要去掉。

① 查看提交的版本号 git log

②合并多次提交记录，比如我们需要合并"从开发了A功能"到"修复了mmm"等6提交记录为一次记录： git rebase -i HEAD~6

③此时会进入vim编辑器

④此时是禁止输入的，按i进入编辑状态，修改当前指令。pick的意思是执行这个commit, squash的意思是当前这个commit会被合并到前一个commit,但会保留备注信息，简写为q。fixup的意思是当前这个commit会被合并到前一个commit,并丢弃这个commit的log message,简写为f,我们只保留第一个pink,把后面的pick全改成s。

⑤编辑号之后，按esc退出编辑状态，再按":wq"退出，

⑥此时会进入这个页面，可以修改相关备注信息。

⑦按i进入编辑状态，我们全部删除，只保留第一次commit，为了方便验证，我们在第一次commit后面加上一句：“终于上线了”。

⑧然后按esc,:wq退出

⑨查看版本 git log，此时本地仓库已经达到了我们想要的效果，多次提交记录已经合并为了一次提交记录，干净清爽。

⑨推送到远程仓库

git push

what 报错了！！！

报错提示push之前先git pull 更新代码。

按提示走，git pull ,git push 成功了，我们在远程仓库验证一下，啊~怎么没有出现我们想要的效果呢，仔细一看记录，git pull 这个命令做了两件事，一：把远程代码拉到本地，二：自动进行合并，此时我们本地就有了线上那几次提交记录，再加上本地那一次提交记录，又把他推送到远程了。

那怎么办呢，回滚代码呀。我又回滚到我们想要的版本，可是此版本在本地，远程推送不上去，pull之后push又会产生提交记录。那现在怎么办呢，凡事不要慌。

此时我想到了再新建一个临时分支试一试，有时候你合并几个commit记录后，git会主动创建一个没有名字的临时分支，你就需要创建一个有名字的临时分支来接替此分支。

①创建临时分支fdd-temp： git checkout -b fdd-temp ；查看本地所有分支： git branch -a

②查看零食分支状态，其实就是和fdd-feature 分支复制的分支，和fdd-feature版本一摸一样

③然后我准备rebase这个分支:git rebase fdd-ture ,道路曲折，还是失败了。

④最后我想到了杀手锏，再次查看log记录，再次确认此分支版本是否是我想要的. ⑤强制推送仓库：git push -f

⑥到远程仓库去验证，漂亮，终于成功了。这就是我们想要的效果。

tip：此场景用到了两个命令，一个是git rebase 变基，一个是git push -f 强制推送，这两个命令一定不要在和别人共用的公共分支使用，只能在自己一个人的分支使用。要坑也只能坑自己，不能坑别人，惹祸了我可救不了你。中途可以使用命令git rebase --abart取消rebase。有冲突就解决冲突，然后git rebase --continue继续