Interface Lab
登录
关于协作

关于协作

面向 GitHub 初学者，说明分支、PR、rebase、冲突处理和网站开发分工方式。

关于协作

这篇文档说明 Interface Lab 网站开发时，团队如何用 GitHub 分工、同步、检查和合并代码。它面向 GitHub 基础还不多的协作者，重点是把日常流程讲清楚，而不是一次塞进所有 Git 命令。

核心原则

  • main 是稳定主线，尽量保持随时可以构建和发布。
  • 每个任务开一个新分支，不直接在 main 上开发。
  • 一个分支只做一件清楚的事，比如修改菜单样式、修复登录、增加一个文档页面。
  • 每次合并前开 Pull Request，让别人能看到改了什么、如何验证、有没有风险。
  • 尽量避免多人同时大改同一个文件，尤其是 src/app/globals.css 这种全局样式文件。

一个好的分工方式

网站开发可以按责任区域来分，而不是所有人都一起改所有东西。

  • 产品与验收：决定功能优先级、页面内容、最终是否可以合并。
  • UI 与交互：负责视觉样式、组件状态、响应式体验和页面细节。
  • 数据与后台：负责 Supabase、权限、API、登录和数据结构。
  • 文档与内容：负责文档中心、模板说明、更新日志和教程沉淀。
  • Codex：负责检查分支、解释 diff、修冲突、跑构建、辅助 code review。

这样分工的好处是每个人知道自己主要负责哪里，也能减少冲突。

日常开发流程

开始一个新任务前，先回到最新的 main：

git switch main
git pull origin main

然后创建自己的任务分支：

git switch -c shuyang/menu-purple

分支名建议用“名字/任务”的形式，比如：

shuyang/menu-purple
wang/docs-collaboration
codex/fix-auth-redirect

开发完成后，先在本地验证：

npm run typecheck
npm run build

然后提交并推送到 GitHub：

git add .
git commit -m "Update selected menu color"
git push -u origin shuyang/menu-purple

推送后在 GitHub 上创建 Pull Request，目标分支选择 main。

Pull Request 应该写什么

PR 不需要写得很复杂，但要让别人快速判断能不能合并。

推荐格式：

做了什么：
- 修改社区菜单选中态颜色

怎么验证：
- npm run typecheck
- npm run build

需要注意：
- 只改了 CSS，没有改业务逻辑

如果改动比较大，可以补充截图、录屏或页面链接。

Rebase 是什么

rebase 可以理解成：把你的分支挪到最新的 main 后面，再重新播放你自己的改动。

假设一开始是这样：

main:      A - B - C
你的分支:  A - X

你的分支还停在 A，但 main 已经走到了 C。执行 rebase 后会变成：

main:      A - B - C
你的分支:          X'

也就是说，你先拿到别人已经合并进 main 的更新，再把自己的改动接上去。

常用命令：

git switch shuyang/menu-purple
git fetch origin
git rebase origin/main

如果出现冲突，先打开冲突文件，保留正确内容，然后继续：

git add 冲突文件
git rebase --continue

如果这个分支之前已经推送到 GitHub，rebase 后通常需要：

git push --force-with-lease

--force-with-lease 只适合用在自己的功能分支上，不要对多人共用分支随便使用。

Merge 和 Rebase 怎么选

日常建议：

  • 自己的功能分支同步最新 main 时，用 rebase。
  • Pull Request 最终合进 main 时，用 GitHub 上的 merge 或 squash merge。
  • 不要在 main 上 rebase。
  • 不要强推 main。

简单记法：自己的分支可以整理，主线只向前走。

冲突怎么处理

冲突不是错误，只是 Git 不知道应该保留哪一版。

处理方式：

  • 先看冲突文件里两边分别改了什么。
  • 如果是同一个功能区域，和协作者确认最终应该保留哪种行为。
  • 如果是样式冲突，优先保留最新设计意图，并确认页面没有视觉破损。
  • 改完后运行 npm run typecheck 和 npm run build。
  • 不确定时，把冲突交给 Codex 或另一个协作者一起看。

合并后的清理

PR 合并后，本地可以清理已经完成的分支：

git switch main
git pull origin main
git branch -d shuyang/menu-purple

如果 GitHub 上的远端分支也不需要了，可以在 GitHub PR 页面删除，或者用命令：

git push origin --delete shuyang/menu-purple

推荐工作节奏

一个小任务的完整节奏可以是：

1. 从最新 main 开分支
2. 完成一个小改动
3. 本地跑 typecheck 和 build
4. push 到 GitHub
5. 开 PR
6. 让同伴或 Codex 检查
7. 合并到 main
8. 清理本地分支

这个流程比直接改 main 多几步，但它能让网站长期保持稳定，也能让每次协作都留下清楚记录。