Git Workflow 视频脚本：RevieU Git 协作工作流详解

9 min read Updated

Video Script: RevieU Git Collaboration Workflow

  • 预计时长：4 - 5 分钟

  • 适用场景：新员工入职培训、团队技术分享

  • 讲者状态：自信、清晰、专业

第一部分：开场与核心理念 (Intro & Core Philosophy)

时间画面内容 (Visual)口播台词 (Spoken Script)
0:00[全屏标题]



Git Workflow & Branching Model



副标题：Clean History, Stable Release		大家好，欢迎来到 RevieU 的技术培训。今天我们要讲的是团队协作中最基础，但也最重要的一环——Git 工作流规范。
0:12[痛点展示]



背景出现一个杂乱的 Git 提交树（多条线交叉），打上红色大叉。



出现关键词：Conflict (冲突), Unstable (不稳定)。		在多人协作的项目里，大家可能都遇到过这些头疼的问题：代码冲突不断、提交历史乱得像毛线团，甚至不小心把测试代码发布到了生产环境。
0:25[核心架构图]



画面中间出现两条粗壮的平行线。



上方红色：main (Production)



下方蓝色：dev (Staging)



两条线旁边都加一把“锁”图标。		为了解决这些问题，我们制定了一套标准流程。



首先，请大家记住，我们的仓库里有两条永久存在的“生命线”：



第一条是 main，它对应生产环境。这是我们的门面，代码必须时刻保持稳定，神圣不可侵犯。



第二条是 dev，它是我们的开发主干。
0:48[CI/CD 流程动画]



1. 代码块并入 dev -> 屏幕显示 “Deploying to Test Env”。



2. 代码块并入 main -> 屏幕显示 “Deploying to Production”。		为什么要这么分呢？这就好比是一个安全网。

如果我们直接合并新代码到 main 分支，那么会直接触发 main 分支的 CICD 流程，新代码总是不可避免的会存在一些隐藏 bug，而 main 分支的内容是已经发布在服务器正在运行的，一旦触发 CICD 自动部署，有未知 bug 的代码一定会影响到正在运行的服务。此外 main 分支应该最大程度保持整洁，因为涉及到多人合作开发，而 main 分支就是合作的 baseline，如果 main 分支随意合并随意提交，那么 git conflict 将会不可避免的多次出现，经常用 git 合作的小伙伴一定不想看到莫名的 conflict 吧

所以，大家日常写的新代码，都是先合并到 dev 分支。这时候，CI/CD 会自动把代码部署到测试环境。



你们可以在这里尽情地测试、折腾。



只有当团队确信 dev 上的代码已经足够稳定了，我们才会把它合并到 main，发布给真实用户。
1:10[分支策略图]



从 dev 伸出三个分支：feat, fix, refactor。



从 main 伸出红色分支：hotfix。		在这两条主线之外，我们所有的开发工作都必须在临时分支上进行。

如果你要开发新功能，请开 feat 分支；



修 Bug，用 fix 分支；



重构代码，用 refactor 分支。



这里有一个特例，就是 hotfix。只有当生产环境出现严重故障需要紧急修复时，我们才从 main 切出 hotfix 分支。修复完后，记得要同时合并回 main 和 dev，防止这个 Bug 在下个版本又冒出来。

第二部分：命名与提交规范 (Naming & Commit Standards)

时间画面内容 (Visual)口播台词 (Spoken Script)
1:45[分支命名演示]



屏幕显示公式：



type / issue-id - description



此时弹出一个 GitHub Issue 截图，ID 为 #42。		接下来讲讲规矩。为了让代码可追溯，分支命名必须遵循一个公式：



类型，斜杠，Issue ID，再加简短描述。



比如，你领到了一个 ID 为 42 的登录页需求，那你的分支名就必须是：feat/42-user-login。



加上这个 ID 非常关键，这样 GitHub 就会自动把你的代码和需求单关联起来，不管是做 Code Review 还是以后查问题，都能一键跳转。
2:15[Commit Message 对比]



左边（错误示范）：



❌ update



❌ fix bug



右边（正确示范）：



✅ feat(auth): add google oauth



✅ fix(ui): fix button alignment		同样严格的还有 Commit Message。



请大家千万不要再写什么 “update” 或者 “fix bug” 这种毫无意义的废话了。



我们强制遵循 Conventional Commits 规范。



格式是：type(scope): subject。



比如 feat(auth): add google oauth。



这不仅是为了好看，更是因为我们的发布系统会根据这些前缀，自动生成 Changelog。你写得规范，文档就自动生成了。

第三部分：实操演示 (The Workflow Demo)

时间画面内容 (Visual)口播台词 (Spoken Script)
2:45[终端录屏：同步]



输入命令：



git checkout dev



git pull origin dev		说了这么多理论，我们来实操演示一遍完整的流程。



假设我要做一个头像上传的功能，Issue ID 是 101。



第一步，永远是同步代码。



在开始工作前，必须先切回 dev 分支，并执行 git pull。这一步能帮你避免 90% 的冲突痛苦。
3:05[终端录屏：新建分支]



输入命令：



git checkout -b feat/101-upload-avatar		第二步，创建分支。



根据刚才说的规范，我输入 git checkout -b feat/101-upload-avatar。



好，现在我进入了一个隔离的开发环境，可以开始写代码了。
3:20[IDE 录屏：提交代码]



模拟写了一段代码。



输入命令：



git add .



git commit -m "feat(user): add avatar upload component"		第三步，提交。



功能写完了，我们提交代码。



注意看我的 Commit Message：feat(user): add avatar upload component。



类型清晰，描述准确。
3:35[终端录屏：推送]



输入命令：



git push -u origin feat/101-upload-avatar		第四步，推送。



把这个分支推送到远程仓库。
3:45[GitHub 网页端录屏：提 PR]



鼠标点击 “Compare & pull request”。



特写放大：Target Branch 选择 dev。



点击 “Create Pull Request”。		第五步，这也是最关键的一步：发起 Pull Request。



打开 GitHub，点击 “Compare & pull request”。



大家请务必注意：目标分支（Base）一定要选 dev，千万别直接合到 main 去了。



在这个页面，团队成员会会对你的代码进行 Code Review。
4:05[GitHub 网页端录屏：合并]



点击 “Squash and merge” 按钮。



显示分支被删除 (Deleted)。		最后一步，合并。



当 Review 通过后，我们推荐点击 Squash and merge。



这个按钮的作用是，把你开发过程中可能产生的十几个琐碎提交，压缩成一个干净的节点合并进 dev。



这样，我们的 dev 分支历史就是一条漂亮的直线，每个点代表一个完整功能。



合并完成后，别忘了顺手删除你的临时分支。

第四部分：结语 (Outro)

时间画面内容 (Visual)口播台词 (Spoken Script)
4:30[总结清单卡片]



1. Protect main & dev



2. Name: type/id-desc



3. Commit: type(scope): subject



4. PR -> Squash -> Dev		好了，总结一下今天的重点：



第一，敬畏 main 和 dev 分支；



第二，分支命名带上 Issue ID；



第三，写规范的 Commit Message；



第四，永远通过 PR 和 Squash 的方式合并代码。



这套流程可能刚开始会觉得繁琐，但它能保证我们的代码库像瑞士军刀一样精密、可靠。
4:55[片尾]



RevieU Logo



文字：Happy Coding!		详细的文档链接就在视频下方，有问题随时在群里提问。



感谢大家的时间，Happy Coding!

💡 给录制者的建议 (Tips for the Speaker)

  1. 语速：不要太快，特别是在念代码命令（如 git checkout -b）的时候，稍微停顿一下，给观众消化的时间。

  2. 重音：脚本中加粗的字（如 永久存在、Issue ID、dev）请重读，以起到强调作用。

  3. 语气：在批评错误示范（如 fix bug）时，可以用一种轻松调侃的语气，不要太严厉；在讲到 main 分支保护时，要严肃认真。