1.更新
git checkout main
git pull origin main
2.切换分支操作并提交
git checkout -b feature/sql-and-gitignore
git add sql/sky_take_out.sql .gitignore
git commit -m "feat: add database schema and update gitignore"
git push origin feature/sql-and-gitignore
注意：
-
区别于其他类型的分支：团队通常会约定多种前缀，例如：
-
feature/→ 新功能开发 -
bugfix/→ 修复某个 Bug -
hotfix/→ 紧急修复生产环境问题 -
release/→ 准备发布版本 -
docs/→ 仅文档修改
-
3.创建PR+描述
在 GitHub/GitLab 上创建 Pull Request
源分支：feature/sql-and-gitignore
目标分支：main
填写 PR 说明，描述你做了什么
4.测试+审查
5.合并
三种合并方式的区别
| 合并方式 | 操作说明 | 结果 | 优点 | 缺点 |
|---|---|---|---|---|
| 合并分支（Merge commit） | 执行标准 git merge，保留源分支的每一个 commit，并额外生成一个合并提交（Merge commit） |
master 历史中会看到两条分支线 + 一个合并节点 | 完整保留原始提交记录和分支结构，适合多人协作、追溯历史 | 历史可能显得杂乱（多条线） |
| 扁平化分支（Squash merge） | 把源分支的所有 commit 压缩成 一个 commit，然后追加到 master 上，不生成合并提交 | master 只增加一个 commit，内容包含所有改动 | 历史非常干净、线性 | 丢失中间提交的细节（如你两次提交分别做了什么） |
| 变基并合并（Rebase merge） | 相当于先在源分支上 git rebase master，然后 git checkout master 后 git merge（Fast-forward） |
master 历史线性，源分支的每个 commit 按顺序重演一遍 | 线性历史，保留每个 commit 信息 | 会改写 commit 哈希，如果多人协作可能引起冲突 |
你应该怎么选？（模拟企业开发流程）
推荐选择第一种：合并分支（Merge commit）
理由：
-
这是最标准、最安全的合并方式，大多数企业默认使用。
-
保留了你的两次提交的完整记录（可见你分别做了"添加 SQL 结构"和"补交 gitignore"），便于以后追溯。
-
生成的合并提交会包含 PR 编号，方便关联。
-
不会破坏任何历史，也没有 squash 的信息丢失问题。
扁平化 适用于"开发中很多小修小补，但最终只想记一个完整的功能提交"。你的两个提交已经很有意义，不需要 squash。
变基 适合追求线性历史的团队，但你的场景不必刻意追求。
6.接收PR
一、合并后删除提交分支
含义 ：
当 PR 被成功合并到目标分支（如 master）后，自动删除源分支 （即你发起 PR 时使用的分支，比如 feature/sql-and-gitignore）。
作用：
-
保持远程仓库的分支列表整洁，避免堆积大量已经合并过的旧分支。
-
减少混乱，让团队成员清楚哪些分支还在活跃开发中。
注意：
-
只删除远程仓库 的分支（创建 PR 后的：发起的PR；本地还有一个
feature/sql-and-gitignore），你本地的同名分支不会自动删除（需要手动git branch -d feature/xxx）。 -
如果还有其他人基于这个源分支进行开发，删除可能会带来问题。但通常 feature 分支只属于一个人，合并后即可删除。
建议 ：勾选（模拟企业开发中，合并后清理分支是良好实践）。
二、合并后关闭提到的 Issue
含义 ：
如果 PR 的描述（或评论）中包含了特定格式的 Issue 引用（如 #123、fix #456、close #789），合并时会自动将那些 Issue 的状态变为"已关闭"。
作用：
-
自动化关联：开发完成后自动关闭对应的 Issue，减少手动操作。
-
保持追踪清晰：例如 Issue 描述"实现用户登录功能"，对应的 PR 合并后自动关闭该 Issue，表示需求已完成。
触发格式示例（以 Gitee 为例，也兼容 GitHub 常用格式）：
-
#123→ 关闭编号为 123 的 Issue -
fix #456、close #456、resolve #456、closes #456等也会触发
注意：
-
只有被合并的 PR 才会触发自动关闭。如果 PR 被关闭而未合并，不会关闭 Issue。
-
如果 PR 描述中没有提到任何 Issue，勾选这个选项没有任何效果。
-
企业中常与项目管理工具（如 Jira、Trello）集成，但 Gitee 内置的 Issue 功能也支持。
建议 ：如果你没有在 PR 描述中写类似 #1 这样的引用，不勾选；如果有明确关联的 Issue，则可以勾选。
总结对比
| 选项 | 作用对象 | 何时有效 | 是否推荐勾选（本次模拟） |
|---|---|---|---|
| 合并后删除提交分支 | 源分支（远程） | 总是有效 | ✅ 推荐（保持整洁） |
| 合并后关闭提到的 Issue | 关联的 Issue | 仅当 PR 描述中有关键字如 #数字 |
❌ 不勾选（本次没有关联 Issue） |
结束
问题
我们搞完一个功能提交一次 PR？
✅ 是的，一个逻辑完整的小功能一个 PR，不是每个微小改动都 PR。
提交后需要重新
git checkout main && git pull origin main吗？
✅ 如果要开始下一个新功能，需要 （否则基于旧的 main 开发会有冲突风险）。
✅ 如果当天不再开发新功能，可以不拉，第二天开工时再拉。
我们搞完一个功能提交一次 PR？
还是说一天完成一个模块，搞好再提交?
两种方式都可行。
-
粒度细（多个 PR/天）：更符合持续集成、快速反馈，但分支切换频繁。
-
粒度粗（一个 PR/天）：切换次数少，但要注意及时拉取 main 减少冲突。