Laravel对接Coding仓库WebHooks实现自动部署 上下文环境都是基于宝塔的，因为Bash操作都使用的www用户，其他环境并不适用项目执行bash主要使用的是exec函数，项目跑在nginx上。nginx使用的用户为www，所以会有权限问题权限解决：vim /etc/sudoers # 文件内容如下 # www ALL=(ALL) NOPASSWD: /usr/bin/git # + # www ALL=(www) NOPASSWD: /www/server/php/81/bin/php /usr/local/bin/composer install # + 第一行配置：允许用户www以任何用户身份运行/usr/bin/git命令，而无需输入密码。 第二行配置：允许用户www以自身身份运行指定的composer install命令，而无需输入密码。路由：/** * 处理WebHook的请求 * 自动化部署 */ Route::post('webhook', [App\Http\Controllers\Deploy\WebHookController::class, 'handle']); 控制器：解释: 当发现仓库有push操作后，自动执行git pull拉取代码，然后执行composer install安装依赖class WebHookController extends Controller { /** * 监听Coding仓库代码更新操作 * 自动部署最新版项目 * @return \Illuminate\Http\JsonResponse|\Illuminate\Http\Resources\Json\JsonResource */ public function handle(Request $request) { Log::info('接收到Coding WebHook', [$request]); $hookEvent = $request->header('X-Coding-Event'); if (!\Str::contains($hookEvent, 'push')) return \Response::ok(); Log::info("开始执行自动部署任务"); // Git Pull exec('cd .. && sudo git pull' . ' 2>&1', $output, $status); if ($status != 0) { Log::error('拉取代码失败', [$output, $status]); \Response::fail('拉取代码失败', ResponseCodeEnum::SYSTEM_ERROR); } Log::info("拉取代码成功", [$output, $status]); // Composer Install exec('cd .. && /www/server/php/81/bin/php /usr/local/bin/composer install' . ' 2>&1', $output, $status); if ($status != 0) { Log::error('composer安装失败', [$output, $status]); \Response::fail('composer安装失败', ResponseCodeEnum::SYSTEM_ERROR); } Log::info("composer安装成功", [$output, $status]); // 后端完成部署 Log::info("自动部署任务执行完毕"); return \Response::ok(); } }模拟：Coding公司的项目使用腾讯旗下的Coding来管理项目，也是有WebHook的功能引用1.Coding WebHook:https://coding.net/help/docs/project-settings/open/webhook.html2.如何实现Git Push之后自动部署到服务器？:https://blog.csdn.net/ll15982534415/article/details/136669152

Git 之 提交代码时的默认提交规则标签简单说明整理 feat/fix/doc/styles/revert/test/build等 Git 之 提交代码时的默认提交规则标签简单说明整理 feat/fix/doc/styles/revert/test/build等一、简单介绍Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。 [1] Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。本节介绍，Git 之 reset --hard 回退/回滚到之前的版本代码后，可能又由于冲动，可能需要恢复回退/回滚版本，这里简单整理回退的方法，如果有不足之处，欢迎指出，或者你有更好的方法，欢迎留言。二、常用的代码提交默认前缀标签规则1、feat: 新功能（feature）2、fix: 修补bug3、docs: 文档（documentation）4、style: 格式（不影响代码运行的变动）5、refactor: 重构（即不是新增功能，也不是修改bug的代码变动）6、chore: 构建过程或辅助工具的变动7、revert: 撤销，版本回退8、perf: 性能优化9、test：测试10、improvement: 改进11、build: 打包12、ci: 持续集成13、update:更新

服务器无法通过SSH连接Clone项目 给仓库部署了服务器上的SSH之后仍然无法Clone项目如下命令测试:ssh -T [email protected]也无法正常响应可能22端口出问题了，然后进入~/.ssh/目录下修改config文件，建议直接在终端中输入vim ~/.ssh/config，使用vim编辑器打开此文件，一般是为空，然后加上以下代码：# Default github user self Host github.com port 443 # 默认是22端口 HostName ssh.github.com IdentityFile ~/.ssh/id_rsa这样的话，github22端口超时的问题就解决了，证明ssh连接是没有问题的，这样github的项目可以正常的push和pull了。引用1."ssh:connect to host github.com port 22: Connection timed out"问题的解决:https://blog.csdn.net/qq_38330148/article/details/109371362

Git分支命名规范 Git分支命名规范一、git分支命名规范git分支分为集成分支，功能分支、和修复分支。分别命名为develop，feature和hotfix，均为单数。不可使用features、future、hotfixes、hotfixs 等错误名称。分支名描述master / main主分支，永远是可用的稳定版本，不能直接在该分支上开发develop开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做合并操作，不能直接在该分支上进行开发feature-xxx功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支feature-xxx-fix功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支进行修复，之后合并回develop分支hotfix-xxx紧急bug修改分支，在master分支上创建，修复完成后合并到masterbugfix短期从develop创建release短期从develop创建PS：1.feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug2.一个分支尽量开发一个功能模块。不要多个功能模块在一个分支上开发3.feature分支在申请合并之前，最好是先pull一下主分支develop，看一下有没有冲突，如果有，先解决冲突后再申请合并二、Branch功能详解master 负责记录上线版本的迭代，该分支代码与线上代码是完全一致的主分支。develop负责记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建开发分支feature用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成后并自测，自测通过之后，需要合并到develop分支，之后删除该分支。bugfix用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测，pass之后合并到develop分支后删除该分支release用于代码上线准备，该分支从develop分支创建，创建之后由测试人员发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完成后，在上线之前，需要合并该release分支到master分支和develop分支。hotfix该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支紧急bug修复分支。三、Branch命名规范分支名格式例子功能分支feature/功能名称feature/loginbug修复分支bugfix/bug名称bugfix/add-user紧急bug修复分支hotfix/bug名称hotfix/delete预发布分支release/预发布版本名称release/add-user四、分支用途详解我们刚刚熟悉了git中常用的分支，那么这些分支有什么意义呢？这么说吧，如果你是一个人开发，那么这确实没什么用，当你在一个团队时就发挥了很大的作用。一般作用下，master分支和线上版本是保持一致的，那么我们需要对它非常重视。一切开发任务都不能在这里进行。因为在开发过程中如果出现bug就会弄脏master分支。如果我们在develop分支上开发，不管出什么错误都不怕，因为master是干净的，实在不行可以从master重新拉取没有问题的项目。这个就是分支其中一个作用。现在是这样的情况：我们在develop分支上完成了项目，那么之后对各个分支是怎么处理呢？过程大概是这样的：将我们的develop分支合并到release分支，这个是一个预发布分支，这个预发布分支是交给测试的人员。测试人员在release分支上拉取完整项目进行测试，在测试过程中发现了一个bug。测试人员找到了开发人员，开发人员在release分支上修改好问题，所有问题都解决了，这时release分支合并到master分支和develop分支。这时开发人员的develop是最新的，master分支也是最新的。另外一种情况是这样的：线上产品使用过程中突然出现了一个bug，这时非常紧急的情况，这时需要处理的步骤大致如下：创建一个紧急bug分支名为hotfix，将master分支拉取到hotfix分支。紧急修改完bug之后将hotfix同步到master分支和develop分支，再删除hotfix分支。世界就恢复平静了。总之，分支会让你在更安全的环境下开发，git里面什么后悔药都有的。引用1.Git分支命名规范 : [https://blog.51cto.com/u_15057832/3527964](

Git代码Commit规范 <type>(<scope>): <subject>规范git commit到底有哪些好处呢？便于程序员对提交历史进行追溯，了解发生了什么情况。一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。格式化的commit message才可以用于自动化输出Change log。type(必须)用于说明git commit的类别，只允许使用下面的标识。typedescfeat新功能（feature）fix/to修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。fix：产生diff并自动修复此问题。适合于一次提交直接修复问题。to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fixdocs文档（documentation）style格式(不影响代码运行的变动)refactor重构（即不是新增功能，也不是修改bug的代码变动）。perf优化相关，比如提升性能、体验。test增加测试。chore构建过程或辅助工具的变动。revert回滚到上一个版本。merge代码合并。sync同步主线或分支的Bug。scope(可选)scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。subject(必须)subject是commit目的的简短描述，不超过50个字符。建议使用中文（感觉中国人用中文描述问题能更清楚一些）。结尾不加句号或其他标点符号。根据以上规范git commit message将是如下的格式：fix(DAO):用户查询缺少username属性 feat(Controller):用户查询接口开发