MiNiKou的博客

提交信息小原则#

• 一次提交只做一件事：不要把”修复bug”和”新增功能”混在一次提交里，方便日后回溯和 revert。

1
git commit -m "feat: 新增文章评论功能" -m "支持二级回复、点赞和举报功能，评论内容做了敏感词过滤"

第一个 -m 是标题，第二个 -m 是正文详细说明，git log 里会分行显示。

1
# 查看提交历史
2
git log
3
git log --oneline  # 简洁版历史记录

场景 A：开源贡献（个人修复文档错误）#

角色：外部贡献者（你） 目标：修复 awesome-project 项目中的拼写错误。 流程：Fork 独立 -> 推送到个人远程 -> 提交 PR -> 对话修正

1. 准备工作：克隆与绑定上游 你需要拥有自己的副本，同时关联原项目以保持同步。

   1
   # 1. 克隆你 Fork 的仓库到本地
   2
   git clone https://github.com/你的用户名/awesome-project.git
   3
   cd awesome-project
   4
   
   5
   # 2. 绑定原作者的仓库为 upstream（上游）
   6
   git remote add upstream https://github.com/原作者/awesome-project.git

2. 同步与分支：确保基线最新 在开始修改前，务必同步原作者的最新代码，避免因代码过旧导致冲突。

   1
   # 1. 拉取原作者的最新提交
   2
   git fetch upstream
   3
   
   4
   # 2. 切换到主分支并合并上游代码
   5
   git checkout main
   6
   git merge upstream/main
   7
   
   8
   # 3. 创建专门的修复分支 (遵循 fix/ 或 docs/ 命名规范)
   9
   git checkout -b docs/fix-readme-typo

   问题1：明明前面已经clone了项目，为什么还要fetch upstream？ 你克隆（clone）的只是“你 Fork 的副本”，而不是“原作者的仓库”。 git clone 和 git fetch upstream 获取的数据来源是完全不同的。

   问题2：为什么此处是fetch,而不是pull? 因为我们不想直接合并到当前分支, 只是想获取最新的代码
   问题3：那这样看git pull与fetch + merge结果上没什么区别呀？ 在执行过程、安全性和掌控力上，这两者有着天壤之别。我们可以把 git pull 看作是一个“黑盒”，而 fetch + merge 则是把这个黑盒拆开，让你能看清里面的每一步。

3. 修改与提交：精准提交 修正 README.md 中的拼写错误（recieve -> receive）。

   1
   # 1. 将修改加入暂存区
   2
   git add README.md
   3
   
   4
   # 2. 提交修改 (规范的提交信息)
   5
   git commit -m "docs: fix typo in README (recieve -> receive)"

4. 推送与发起 PR 将你的分支推送到你的 Fork 仓库，并在 GitHub 上发起 Pull Request。

   1
   # 推送到你的远程仓库
   2
   git push origin docs/fix-readme-typo

   操作： 去 GitHub 页面，选择 Base: main (原作者仓库) 与 Compare: docs/fix-readme-typo (你的分支)，点击 Create pull request。

5. 应对审查：修正提交 如果维护者要求修改 Commit Message，你不需要关闭 PR，只需在本地修正并强制推送（针对个人分支是安全的）：

   1
   # 修正上一次的提交信息
   2
   git commit --amend -m "docs: fix typo in README (recieve -> receive) [Corrected message]"
   3
   
   4
   # 强制推送到你的分支 (PR 会自动更新)
   5
   git push origin docs/fix-readme-typo --force

场景 B：团队协作（新增登录功能）#

角色：核心开发成员 目标：在公司项目 awesome-project 中开发新功能。 流程：共享仓库 -> 功能分支开发 -> 推送远程 -> 内部审查 -> 合并清理

1. 拉取最新代码 每天开始工作前，确保本地 main 分支与团队最新进度一致。

   1
   git checkout main   # 切换到主分支
   2
   git pull origin main  # 拉取远程仓库的最新代码 (团队协作通常不需要 upstream，直接 pull origin)

2. 创建功能分支 基于最新的 main 分支，创建一个独立的开发环境。

   1
   git checkout -b feature/login  # 创建并切换到新分支

3. 本地开发与多次提交 在这个分支上进行完整的功能开发，保持提交粒度清晰。

   1
   # 第一次提交：完成页面 UI
   2
   git add src/pages/Login.vue
   3
   git commit -m "feat: add login page UI components"
   4
   
   5
   # 第二次提交：配置路由
   6
   git add src/router/index.js
   7
   git commit -m "feat: configure login page route"

4. 推送分支 将本地功能分支推送到共享的远程仓库，以便同事审查。

   1
   git push origin feature/login

   操作： 在 GitHub/GitLab 上，系统通常会提示“Your branch has been pushed…”，点击 Compare & pull request。

5. 代码审查与迭代 同事在 PR 中指出代码问题（如样式错误）。你无需重新开 PR，只需在本地继续修改并推送。

   1
   # 修改代码后，再次提交
   2
   git add src/pages/Login.vue
   3
   git commit -m "fix: update login button color to use theme variable"
   4
   git push origin feature/login  # 推送到同一分支，PR 自动更新

6. 合并与清理 审查通过后，点击 Merge pull request。合并完成后，务必删除远程分支，并清理本地分支。

   1
   # 1. 切换回主分支
   2
   git checkout main
   3
   
   4
   # 2. 拉取最新的合并记录
   5
   git pull origin main
   6
   
   7
   # 3. 删除本地已合并的分支
   8
   git branch -d feature/login