从个人项目到团队协作，Git 的使用方式确实会发生很大变化。别担心，这套流程一旦熟悉了，你会发现它能极大地提升团队的开发效率和代码质量。
这份文档为你量身打造，旨在让你快速从 “Git 单人玩家” 进阶为 “Git 团队高手”。内容会从核心理念讲起，覆盖日常工作流、分支管理、合并与冲突解决。
Git 团队协作快速上手指南
欢迎来到团队开发！把这份文档当成你的 “Git 副驾驶”，在你需要的时候提供指引。
一、 核心理念：为什么团队要用分支？
在个人项目中，你可能习惯于直接在 main (或 master) 分支上开发。但在团队中，这是绝对禁止的。
分支（Branch） 就像是项目在某个时间点的一个平行宇宙。你可以在自己的平行宇宙（你的功能分支）里随意修改、实验，而不会影响到主宇宙（main 或 develop 分支）。
这么做的好处：
-
隔离开发：你在开发新功能 A，你的同事在修复 Bug B，你们在各自的分支上工作，互不干扰。
-
代码评审（Code Review）：你的功能完成后，不会直接合并到主线。你会创建一个 “合并请求”（Pull Request / Merge Request），让同事们检查你的代码，提出建议，确保代码质量。
-
保持主干稳定：
main和develop这样的主干分支永远是稳定的、可运行的。
二、 日常开发工作流（The Happy Path）
这是你每天 90% 的时间会用到的流程，我们称之为 “快乐路径”（因为一切顺利，没有冲突）。
假设团队的主要开发分支是 develop，稳定发布分支是 main。
第 1 步：开始新任务前，先同步代码
永远确保你的本地代码库是最新的。
# 1. 切换到主开发分支 (可能是 develop 或 main，请与你的团队确认)
git switch develop
# 2. 从远程服务器拉取最新的代码
git pull origin develop
第 2 步：为你的任务创建新分支
为每个新功能或 Bug 修复创建一个独立的分支。分支命名最好有规范，比如 feature/user-login 或 fix/bug-123。
# 从最新的 develop 分支上，创建并切换到一个名为 feature/user-login 的新分支
git switch -c feature/user-login
# 上面的命令是下面两个命令的简写：
# git branch feature/user-login (创建分支)
# git switch feature/user-login (切换分支)
第 3 步：尽情编码和提交
现在你在自己的分支上了，可以安全地进行修改。
# 1. 写你的代码...
# 2. 将修改的文件添加到暂存区
git add . # "." 代表所有修改的文件，也可以指定具体文件 git add src/components/Login.vue
# 3. 提交你的修改，并写下清晰的提交信息
git commit -m "feat: 完成用户登录页面静态布局"
# 好的 commit message 很重要，通常格式是 "类型: 简短描述"，如 feat, fix, docs, style 等
小技巧：养成 “小步快跑” 的习惯，完成一个小功能点就 commit一次，而不是完成全部功能再 commit。
第 4 步：将你的分支推送到远程仓库
当你准备好让同事看到你的代码时（比如今天下班前），把你的分支推送到服务器。
# 第一次推送这个新分支时，需要设置上游 (upstream)
git push --set-upstream origin feature/user-login
# 之后再推送这个分支，直接使用
git push
第 5 步：创建合并请求（Pull Request / PR）
推送后，去公司的 Git 平台（如 GitHub, GitLab, Gitee）上，你会看到一个提示，让你为刚刚推送的分支创建一个 Pull Request。
点击创建，填写标题和描述，指定你的同事为评审人（Reviewer）。然后，你的团队就可以开始 Code Review 了。
三、 分支合并与更新
在你的 PR 被批准后，通常会有两种方式将你的代码合并到 develop 分支：
-
Merge Commit: 这是默认方式。它会把你的分支上的所有提交打包成一个新的合并提交，然后加到
develop分支上。历史记录清晰，能看出分支的合并轨迹。 -
Squash and Merge: 将你的分支上的所有提交 “压扁” 成一个提交，然后加到
develop上。这能让develop的历史记录非常干净整洁。
通常，你不需要在本地执行合并，这些操作会在 PR 被批准后，由负责人或你在 Git 网页端完成。
重要：如何让你的分支保持最新？
在你开发功能的过程中，develop 分支可能已经被其他同事更新了。你需要将这些最新的代码同步到你自己的分支，以避免最后的冲突。
方法一：使用 merge（推荐给新手）
这会把 develop 分支的最新变更合并到你当前的分支。
# 1. 先确保你本地的 develop 是最新的
git switch develop
git pull
# 2. 切换回你的功能分支
git switch feature/user-login
# 3. 将最新的 develop 合并到你的分支
git merge develop
方法二：使用 rebase（更整洁，但更复杂）
rebase 会将你的分支的提交“变基”到 develop 的最新提交之后，使提交历史成为一条直线，非常清晰。
# 1. 确保 develop 最新
git switch develop
git pull
# 2. 切换回你的功能分支
git switch feature/user-login
# 3. Rebase 你的分支
git rebase develop
Rebase 黄金法则：永远不要 rebase 已经推送到远程的公共分支（如 develop, main）。只在你自己的私人分支上使用 rebase。
四、 核心技能：解决冲突
冲突并不可怕，这是团队协作的正常现象。当你和同事修改了同一个文件的同一行代码时，Git 就不知道该听谁的了，于是它会把决定权交给你。
场景：当你执行 git pull, git merge 或 git rebase 时，终端提示 “CONFLICT”。
解决步骤：
1. 找到冲突文件
执行 git status，Git 会明确告诉你哪个文件冲突了（marked as unmerged）。
2. 打开冲突文件
你会看到类似下面的内容，被 <<<<<<<, =======, >>>>>>> 包裹。
<<<<<<< HEAD (Current Change)
// 这是你当前分支（HEAD）上的代码
const name = "Alice";
=======
// 这是你要合并进来的分支的代码
const name = "Bob";
>>>>>>> develop (Incoming Change)
-
<<<<<<< HEAD到=======之间是 你的修改。 -
=======到>>>>>>> [branch-name]之间是 别人的修改。
3. 做出你的决定
你需要手动编辑这个文件，决定最终要保留哪部分代码。
-
保留你的：删除
=======到>>>>>>>的内容，并删除标记线。 -
保留别人的：删除
<<<<<<<到=======的内容，并删除标记线。 -
两者都保留或进行整合：根据逻辑，手动修改代码，然后删除所有标记线。
例如，你决定保留 “Bob”，那么修改后的文件内容应该是：
const name = "Bob";
4. 标记为已解决
在你解决了所有文件的所有冲突后：
# 将你手动修改好的文件添加到暂存区，告诉 Git “这个文件我搞定了”
git add <conflicted-file-name>
5. 完成合并/变基
- 如果你之前在执行
git merge，现在只需：
git commit # Git 会自动生成一个合并提交信息，你直接保存退出即可
- 如果你之前在执行
git rebase，现在只需：
git rebase --continue
“救命”命令：如果你把事情搞砸了，想回到冲突前的状态：
-
Merge 时用:
git merge --abort -
Rebase 时用:
git rebase --abort
五、 常用“救急”命令
-
git status你的好朋友。随时运行它，看看当前工作区的状态。 -
git log --oneline --graph用简洁的单行和图形化方式查看提交历史。 -
git stash当你正在一个分支上写代码，但还没写完（不想 commit），突然需要切换到另一个分支去改紧急 Bug 时：
# 1. 将当前未提交的修改暂存起来
git stash
# 2. 现在你的工作区是干净的，可以切换分支了
git switch hotfix/urgent-bug
# ...修复 bug ...
# 3. 回到原来的分支
git switch feature/user-login
# 4. 将之前暂存的修改恢复回来
git stash pop
总结：团队协作最佳实践
-
先拉后推：开始新任务或推送代码前，记得
git pull。 -
分支驱动：为每一个独立的任务创建分支。
-
勤于同步：经常将主干分支 (
develop) 的更新同步到你的功能分支。 -
清晰提交：编写有意义的
commit信息。 -
拥抱PR：使用 Pull Request 进行代码评审，这是保证质量和知识共享的关键。
-
多沟通：如果不确定，或者将要进行大的改动，先和你的同事或主管沟通。
把这份文档放在手边，初期多对照练习，很快你就会对这套流程了如指掌。祝你在新公司工作顺利，编码愉快！