共计 1753 个字符，预计需要花费 5 分钟才能阅读完成。
共事和组长的一番对话引起了笔者对 git 的思考
先介绍一下我司小工坊式的 git 提交流程，本地打包，删除 dist 文件，重建 dist 文件，git add .，git commit -m 'XX'，git push origin 分支名
和传统公司的 git 提交不同，我司打包是本地打包，而且是把 dist 文件间接上传到仓库
事变景象
共事把代码推上去后，浏览器拜访的还是原来的 js 和 css。
共事说：组长，须要你把 dist 删掉，从新再从仓库里拉一下最新的
组长：git 提交后不就把原来的 dist 替换了吗，你让我删 dist 有什么意义
扯皮了一会儿，组长还是删了而后从新拉，没想到好了
组长说：你的 dist 当初是最新的，所以当初就好了
共事具体说了什么笔者遗记了，大抵上在辩护 git 提交不会把原来的 dist 文件删除问题，不过他没压服组长，组长也没压服他，反正曾经平安上线而不了了之。
我正好在旁边听到了，要是两年前我兴许会始终提出问题参加答辩，申援共事。但笔者没动，不是怕 PUA，而是表达能力太差，即便是对的，也说不好。其根本原因是笔者对这块常识理解的不粗浅，所以不敢说大话
理论知识
依照理论知识，你 push 整个 dist 文件，即便近程仓库中有 dist，也不会把整个 dist 文件夹替换，只会替换其中雷同的数据，而因为打了 hash 值，所以 css 和 js 都是不同的，所以始终这样做，dist 中的文件会越来越多，而因为 index.html 文件只有一个，所以不会呈现替换了还援用之前文件的问题，如果呈现，革除下浏览器的缓存就能解决
实战测验
因为生产环境和测试环境公布代码流程不同，所以先要把环境配置成统一先
须要做的事件很简略，把 nginx 中指向仓库地址，到时候从远端拉下代码即可
先批改 nginx 中的配置
server {
listen 7000;
# root /usr/share/nginx/html/dist
root /home/jingqb-web/dist
...
}再检查一下 nginx 配置是否 ok
nginx -t接着重启 nginx
nginx -s reload 接着把代码提交到远端仓库，再上服务器进入 /home/jingqb-web 目录下，git pull origin XX，进入 dist 文件，查看打包后的 js
咱们批改在我的项目中打印一些日志，示意文件改变，这样 build 之后会打出不同 hash 的 js
git push origin XX
再次登录服务器，进入 /home/jingqb-web 目录，再拉代码 git pull origin xx
发现，umi.b0f5511b.js 被删掉了，新生成的 umi.f8280c0e.js 在其中，dist 中是洁净的源文件，这是为什么呢？
你 build 之后，是先删掉 dist 文件，生成的是一个洁净的 dist，而后我的操作是：
- git add .
- git commit -m ‘XX’
- git push origin ‘XX 分支 ’
我的操作中没有 pull 代码，而是间接 push 代码，这就意味着 dist 就是我本地的 dist，而非合并之后的
想想这种做法的毛病是多人开发时，pull 他人的代码后，merge 之后还要从新 build，能力再次提交
好险，还好没有逞英雄
谨言慎行是一辈子的学识
三句话测试你是否懂 git
这触发了笔者对 git 的新认知，联合平时教训，笔者感觉三个问题能测试他人对 git 的了解水平
-
你和共事基于同一 commit 开发，后续合并时，如何依照工夫程序显示提交记录
- git rebase master XX(分支)
- 取得更优雅的提交树
-
代码如何回滚
- git reset –hard XX
- 把以后代码指向另一个 commit 上
-
你开发代码，提交了好几个 commit，后续应用
git reset --hard xxxxx把代码指针指回原始 commit，并在这个 commit 上开发了一个性能，并提交了一个 commit，怎么找回之前提交的那好几个 commit-
首先应用
git reflog，它能展现你之前所有的 git 操作- 比拟 git log，它不仅包含了 git log 上的操作，而且它记录了被删除的 commit 记录和 reset 操作
-
git reset --hard XX- 将 git 指针指向回到原始代码前的那个 commit
-
git cherry-pick XX- 合并二次开发时的 commit
- cherry-pick 意为取出，将二次开发时的 commit 取出放入主分支上
-