Three sentences to test whether you understand git

A conversation between my colleagues and the team leader caused the author to think about git

Let's first introduce our small workshop-style git submission process, local packaging, deleting dist files, rebuilding dist files, git add . , git commit -m 'XX' , git push origin 分支名

Different from the traditional company's git submission, our company's packaging is local packaging, and the dist file is directly uploaded to the warehouse

accident phenomenon

After the colleague pushed the code up, the browser still accesses the original js and css.

The colleague said: Team leader, you need to delete the dist and pull the latest one from the warehouse again.

Team leader: Don't you replace the original dist after the git commit? What's the point of letting me delete the dist?

After wrangling for a while, the team leader deleted it and pulled it again. I didn’t expect it to be fine.

Team leader said: Your dist is up to date now, so it's fine now

I forgot what my colleague said in detail. I am generally defending the problem that git submission will not delete the original dist file, but he did not convince the team leader, nor did the team leader persuade him, anyway, it has been safely online and nothing is left.

I happened to hear it by the side, if two years ago, I might have been raising questions and participating in the debate, applying for assistance to my colleagues. But the author didn't move, not because he was afraid of PUA, but because his ability to express himself was too poor. The fundamental reason is that the author does not have a deep understanding of this knowledge, so I dare not speak out.

theoretical knowledge

According to theoretical knowledge, if you push the entire dist file, even if there is a dist in the remote warehouse, the entire dist folder will not be replaced, only the same data in it will be replaced, and because of the hash value, css and js are different. , so keep doing this, there will be more and more files in dist, and because there is only one index.html file, there will be no problem of replacing and referencing the previous file. If it occurs, clearing the browser's cache can solve it

Practical test

Because the process of publishing code in the production environment and the test environment is different, first configure the environment to be consistent.

What needs to be done is very simple, point nginx to the warehouse address, and then pull down the code from the remote end

First modify the configuration in nginx

 server {
    listen 7000;
    # root /usr/share/nginx/html/dist
    root /home/jingqb-web/dist
    ...
}

Check again if the nginx configuration is ok

 nginx -t

Then restart nginx

 nginx -s reload

Then submit the code to the remote warehouse, then go to the server and enter the /home/jingqb-web directory, git pull origin XX , enter the dist file, and view the packaged js

原js的hash值

We modified to print some logs in the project, indicating file changes, so that after build, js with different hashes will be printed

git push origin XX

再次提交后的代码

It is found that umi.b0f5511b.js has been deleted, and the newly generated umi.f8280c0e.js is a clean source file in dist, why is this?

After you build, delete the dist file first, and generate a clean dist, and then my operation is:

git add .
git commit -m 'XX'
git push origin 'XX branch'

There is no pull code in my operation, but direct push code, which means that dist is my local dist, not the merged one

Think about the disadvantage of this approach is that when multiple people develop, after pulling other people's code, they have to rebuild after the merge before they can be submitted again.

It's dangerous, but luckily I didn't become a hero

Prudence in words and deeds is a lifelong learning