CodeIgniter 项目应使用 Git 管理代码而非框架本身，克隆项目、规范分支（master/develop/hotfix）、提交迁移文件、严格忽略 vendor/writable/.env，并在 GitCode PR 中注明影响范围、配套迁移及环境配置变更。
CodeIgniter 本身不提供 Git 版本控制系统，Git 是独立的分布式 VCS；所谓“在 CodeIgniter 中使用 Git”，实际是指用 Git 管理 CodeIgniter 项目代码，并配合 GitCode 托管平台完成团队协作。
克隆 CodeIgniter 项目到本地（不是安装框架）
很多人误以为要“在 CodeIgniter 框架里装 Git”，其实 Git 操作完全在项目根目录外层进行。你管理的是整个 app/、public/、app/Config/ 等文件组成的项目仓库，而非框架源码本身（除非你参与 CI 开发）。
- 从 GitCode 克隆你的团队项目（不是官方 CI 仓库）：
git clone https://gitcode.com/your-org/your-ci4-project.git - 不要直接修改
vendor/codeigniter4/framework目录——那是 Composer 安装的依赖，应通过composer.json控制版本 - 确保
.gitignore已排除vendor/、writable/、env、phpunit.xml等敏感或生成文件
分支策略必须匹配 CodeIgniter 团队规范
CodeIgniter 官方仓库用 Git-Flow，你的项目也该照做，否则 PR 合并会混乱。关键不是“能不能用”，而是“是否和团队约定一致”。
-
master分支只接受已测试的生产就绪代码，禁止直接git push，必须走 Pull Request - 新功能一律从
develop拉出feature/login-api分支，完成后合并回develop，不直连master - 紧急线上修复走
hotfix/xxx：从master创建 → 修复 → 同时合并回master和develop - 执行前确认远程分支保护规则：GitCode 项目设置中需开启
master和develop的「强制 PR 审核」和「禁止强制推送」
数据库迁移文件必须进 Git，且命名不能手改
CodeIgniter4 的 app/Database/Migrations/ 下所有 *_create_users_table.php 类文件，是数据库的“可执行版本快照”。漏提交 = 其他人 php spark migrate 必报错。
- 创建迁移必须用 CLI：
php spark make:migration AddEmailToUsers—— 时间戳前缀由系统生成，不可手动删改 - 迁移文件内不得写死开发环境数据（如
INSERT INTO users），这类逻辑应放进app/Database/Seeds/的 Seeder - 团队中有人运行了
migrate:refresh，其他人必须同步删除本地writable/database/并重跑，否则migrations表状态错乱 - 若多人同时写迁移，务必沟通顺序；两个同时间戳的迁移文件会导致执行失败，GitCode 提交时会提示冲突
GitCode 上 PR 描述要带 CodeIgniter 上下文
在 GitCode 发起 Pull Request 时，空泛写“修复 bug”毫无意义。CI 项目有其典型模式，PR 描述需包含可验证信息。
- 必写：影响的控制器/模型名，例如「修改了
App\Controllers\User::update()中的验证逻辑」 - 附带：对应迁移文件名（如有），例如「配套迁移
20260510123456_add_status_to_posts.php」 - 说明：是否需要运行
php spark db:seed或清缓存，例如「需运行php spark cache:clear生效」 - 截图或日志片段比文字更有效：比如贴出
php spark migrate:status输出，证明迁移已登记
最常被忽略的一点：CodeIgniter 的 writable/ 目录权限、.env 文件内容、以及数据库连接配置，这些永远不该进 Git，但团队成员必须在 PR 评论里明确写出「本次变更是否要求修改 .env 中的 database.default.hostname」——否则部署时静默失败。
