问题描述
前端需要打包发布的代码,commit,pull,push和npm run build的顺序是怎样?
问题出现的环境背景及自己尝试过哪些方法
前端的代码需要打包发布到测试机,之前一直是先commit,然后pull,再run build,最后push的
补充
目前条件不允许我去做在测试机上自动打包或者启动自动构建等操作(我没这个权限)
前端需要打包发布的代码,commit,pull,push和npm run build的顺序是怎样?
前端的代码需要打包发布到测试机,之前一直是先commit,然后pull,再run build,最后push的
目前条件不允许我去做在测试机上自动打包或者启动自动构建等操作(我没这个权限)
感觉这流程没啥问题啊,我也是这样,不过在pull
的时候加上了--rebase
让我新提交的代码保持在commit
记录最先。为了打包不漏掉别人更新的代码肯定是要先拉取才build
的,构建完了再提交到自己仓库给项目主分支提个PR
合并,最后是用项目主分支上的代码发布。具体流程还是看项目成员怎么配合。
打包的内容应该再.gitihnore
里面。用另外的方法把打包的内容推到测试机,或者在测试机上打包,或者写一个构建流(打包 -> 发布的脚本),在打包机(任意机器)上打包。
10 回答11.1k 阅读
6 回答3k 阅读
5 回答4.8k 阅读✓ 已解决
4 回答3.1k 阅读✓ 已解决
2 回答2.6k 阅读✓ 已解决
4 回答2.4k 阅读✓ 已解决
3 回答1.4k 阅读✓ 已解决
两者的区别:
1本地不先run build直接push,则需要测试机pull到代码后,还需要build一下。
如果中间有专门打包的机器,build过程则在中间机器上,然后推送到测试机,一般可以自动化实现。
2本地先run build再push,意味着测试机可以pull到build好的资源,用于发布。