UI DESIGN LAB
  • 首页
  • 社区
  • 资源库
  • 知识库
  • 文档
EN登录

文档文章

平台与维护
网站概述功能开发与版本更新记录关于协作
Template 库
Prompt 看板Style 看板
Agent 工作流
Agent 深度解析项目创作页与 Agent 工作流Agent 输出链路Prompt Agent EvalsDesign System PanelsKnowledge Base GuideDeepSeek Agent 故障复盘
UI DESIGN LAB文档中心

公开阅读 Markdown 文档，管理员可进入编辑页维护。

关于协作

关于协作

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

返回文档中心

章节预览

核心原则一个好的分工方式日常开发流程Pull Request 应该写什么Rebase 是什么Merge 和 Rebase 怎么选冲突怎么处理合并后的清理推荐工作节奏

关于协作

这篇文档说明 UI DESIGN 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 多几步，但它能让网站长期保持稳定，也能让每次协作都留下清楚记录。