mirror of
https://github.com/Syngnat/GoNavi.git
synced 2026-05-06 20:03:05 +08:00
ed1f40e04a
- 优化新建连接、主题设置、侧边栏工具区与 SQL 日志的界面表现 - 调整分页、筛选、透明模式与弹窗样式，统一整体交互层次 - 收口外观参数生效逻辑并补齐多组件适配 - 删除 sync-main-to-dev 工作流并同步维护者手动回灌说明
3.6 KiB
3.6 KiB
贡献指南
感谢你对本项目的贡献。
本项目采用“发布优先（main 为默认分支）+ release/* 分支发版”的协作模型。为减少分支漂移与 PR 处理成本，请在提交贡献前先阅读本指南。
分支模型
main：稳定发布分支，也是仓库默认分支dev：日常开发集成分支，主要供维护者使用release/*：发布准备分支，主要供维护者使用- 外部贡献者建议使用以下分支命名：
fix/*：问题修复feature/*：功能新增或增强
维护者发布流转如下：
feature/* / fix/* -> dev -> release/* -> main -> tag(vX.Y.Z)
外部贡献者如何提 Pull Request
无论是 fix/* 还是 feature/*，外部贡献者统一直接向 main 发起 Pull Request。
这样做的原因：
main是默认分支，PR 入口更直观- 合并后贡献会直接体现在默认分支
- 便于维护者统一做后续同步与发版整理
建议流程：
- Fork 本仓库
- 从你自己的仓库创建分支（建议命名为
fix/*或feature/*） - 完成代码修改，并进行必要自检
- 推送到你的远程分支
- 向本仓库的
main分支发起 Pull Request
Pull Request 要求
请尽量保证 PR 单一、清晰、可审核。
建议遵循以下要求：
- 一个 PR 只解决一类问题，避免混入无关改动
- 标题清晰说明改动目的
- 描述中说明：
- 背景与问题
- 变更点
- 影响范围
- 验证方式
- 如涉及 UI 调整，建议附截图或录屏
- 如涉及兼容性、数据变更或构建链路调整，请明确说明风险和回滚方式
PR 合并策略（维护者）
main 分支上的 PR 建议使用 Squash and merge。
原因：
- 保持
main历史干净、线性 - 每个 PR 在
main上对应一个清晰提交 - 降低发布排查与回滚成本
维护者同步规则
由于外部 PR 会直接合入 main，维护者必须及时将 main 的变更同步到开发与发布分支，避免分支漂移。
1. main → dev 同步（必做）
仓库已移除 GitHub Actions 自动回灌 workflow。
当前统一采用手动方式将 main 同步回 dev：
git checkout dev
git pull
git merge main
git push
2. 发版前从 dev 切 release/*
发布前由维护者基于 dev 创建发布分支，例如：
git checkout dev
git pull
git checkout -b release/v0.6.0
git push -u origin release/v0.6.0
3. release/* → main 发版
发布准备完成后，将 release/* 合并回 main，并打标签发布：
git checkout main
git pull
git merge release/v0.6.0
git push
git tag v0.6.0
git push origin v0.6.0
4. main 回流到 dev（发版后必做）
发布完成后，仍沿用同一套自动化流程；如有需要，也可以手动触发 workflow_dispatch，或执行以下兜底命令，确保开发线与发布线一致：
git checkout dev
git pull
git merge main
git push
提交建议
建议保持提交信息简洁、明确，便于维护者审查与后续追踪。
推荐格式：
emoji type(scope): 中文描述
示例：
🔧 fix(ci): 修复 Windows AMD64 下 DuckDB 驱动构建工具链
✨ feat(redis): 新增 Stream 类型数据浏览支持
♻️ refactor(datagrid): 优化大表横向滚动与渲染结构
其他说明
- 文档、构建链路、驱动兼容性相关改动，请尽量附带验证结果
- 若改动较大，建议先提 Issue 或 Draft PR，先对齐方案再实施
- 如提交内容与项目当前架构方向冲突，维护者可能要求收敛范围后再合并
感谢你的贡献。