Git 工作流程（完整指南）

Git 工作流程：从零开始掌握协作开发的核心

在现代软件开发中，版本控制已经不是“加分项”，而是“生存必需”。Git 作为目前最主流的分布式版本控制系统，其核心价值不仅在于记录代码变更，更在于构建一套清晰、可复用的 Git 工作流程。无论你是独自开发的小项目，还是参与大型团队协作，掌握一套标准的 Git 工作流程，都能让你事半功倍，避免“代码混乱”“提交混乱”“合并冲突”等常见痛点。

本文将带你从零开始，系统梳理 Git 工作流程的核心要素。我们将以真实开发场景为背景，通过逐步演示，让你不仅“知道怎么做”，更“理解为什么这么做”。

为什么需要 Git 工作流程？

想象一下：你和三位同事在一个项目上工作。你改了用户登录逻辑，同事 A 修改了首页样式，同事 B 增加了支付功能，而同事 C 优化了数据库查询。如果没有统一的 Git 工作流程，大家直接往 main 分支提交代码，会发生什么？

你的代码可能被覆盖
他人的修改可能破坏你的逻辑
合并时出现大量冲突，需要耗费数小时手动解决

这就是混乱的根源。而 Git 工作流程的本质，就是为团队协作建立一套“规则”与“秩序”。它不是限制你自由，而是帮你避免“自由带来的灾难”。

核心分支模型：主干与功能分离

在 Git 工作流程中，最基础也是最重要的概念是分支模型。一个经典的模型是 Git Flow，但对大多数中小型项目来说，我们推荐更简洁的 GitHub Flow 模型，其核心原则是：

每个功能或修复都创建独立的分支，完成后再合并到主分支。

主分支：`main` 分支

main 分支代表项目当前可部署的稳定版本。它应该始终处于“可发布”状态。任何直接提交到 main 的行为，都应视为高风险操作。

功能分支：`feature/` 或 `bugfix/`

当你需要开发一个新功能（如“用户头像上传”）或修复一个 Bug（如“登录页闪退”），都应该创建一个独立的分支：

git checkout -b feature/user-avatar-upload

✅ 命令解释：git checkout -b 表示创建并切换到新分支。feature/user-avatar-upload 是一个语义清晰的分支名，便于团队识别。

此时，你的工作完全在独立分支中进行，不会影响 main 分支的稳定性。

实战案例：实现“用户头像上传”功能

我们来通过一个完整流程，演示 Git 工作流程的实际应用。

1. 创建并切换到功能分支

git fetch origin

git checkout main
git pull origin main

git checkout -b feature/user-avatar-upload

📌 注意：始终从 main 分支拉取最新代码，再创建新分支，避免后续合并冲突。

2. 开发代码并提交

// src/components/AvatarUploader.vue
<template>
  <div class="avatar-uploader">
    <input type="file" @change="handleFileChange" accept="image/*" />
    <img v-if="previewUrl" :src="previewUrl" alt="头像预览" />
  </div>
</template>

<script setup>
import { ref } from 'vue'

// 定义响应式变量
const previewUrl = ref('') // 用于显示图片预览
const file = ref(null)    // 存储用户选择的文件

// 文件选择事件处理
const handleFileChange = (event) => {
  const selectedFile = event.target.files[0]
  if (!selectedFile) return

  // 限制文件类型与大小
  if (!selectedFile.type.startsWith('image/')) {
    alert('请上传图片文件')
    return
  }

  if (selectedFile.size > 5 * 1024 * 1024) { // 5MB 限制
    alert('图片大小不能超过 5MB')
    return
  }

  // 创建文件读取器，生成预览 URL
  const reader = new FileReader()
  reader.onload = (e) => {
    previewUrl.value = e.target.result // 将文件内容转为 base64
  }
  reader.readAsDataURL(selectedFile)

  file.value = selectedFile // 保存文件对象
}
</script>

✅ 代码注释：

使用 ref 声明响应式变量，确保页面能实时更新

FileReader 是浏览器内置 API，用于读取本地文件

readAsDataURL 方法将文件转为 base64 编码字符串，可直接用于 <img> 标签显示

添加了文件类型和大小校验，提升用户体验

3. 提交代码

git add src/components/AvatarUploader.vue

git commit -m "feat: add user avatar upload component with preview"

📌 提交信息规范建议：

使用动词开头（如 feat:、fix:、docs:）

简洁明了，说明做了什么

便于后续生成变更日志（changelog）

合并请求（Pull Request）与代码审查

当功能开发完成，你不能直接把代码合并到 main。正确的做法是发起一个 Pull Request（PR），邀请团队成员审查你的代码。

1. 推送分支到远程仓库

git push origin feature/user-avatar-upload

2. 在 GitHub/GitLab 上创建 Pull Request

打开你的代码托管平台（如 GitHub），系统会提示你“创建 PR”。填写标题和描述，例如：

标题：feat: 用户头像上传功能
描述：
- 实现了图片上传、预览与校验功能
- 支持 JPG/PNG 格式，最大 5MB
- 代码已通过 ESLint 检查，单元测试通过

✅ 代码审查的意义：避免“提交了但没用”的代码，防止引入潜在 Bug，也促进团队知识共享。

3. 回应审查意见

假设审查人提出：

“请增加文件上传的 loading 状态，避免用户误操作。”

你只需在代码中补充状态变量：

const isUploading = ref(false)

const handleFileChange = (event) => {
  const selectedFile = event.target.files[0]
  if (!selectedFile) return

  // 开始上传状态
  isUploading.value = true

  // ... 其他逻辑
  // 上传完成后设为 false
  setTimeout(() => {
    isUploading.value = false
  }, 1000)
}

然后提交新提交：

git add src/components/AvatarUploader.vue
git commit -m "fix: add loading state for avatar upload"
git push origin feature/user-avatar-upload

PR 会自动更新，审查人看到新提交后，即可批准合并。

合并与清理

当 PR 被批准，你可以选择“合并”或“squash and merge”。

合并方式选择建议：

方式	优点	适用场景
Merge commit	保留完整历史，清晰展示分支合并点	团队协作，需要追溯分支演化
Squash and merge	合并为一条提交，历史更简洁	功能小、提交多、逻辑集中

✅ 推荐：对于功能分支，使用 Squash and merge，保持 main 分支整洁。

合并完成后，本地清理无用分支：

git branch -d feature/user-avatar-upload

git push origin --delete feature/user-avatar-upload

Git 工作流程总结与最佳实践

通过上述流程，我们可以提炼出 Git 工作流程的五大黄金准则：

永远从 main 分支创建新分支
每个功能/修复使用独立分支
提交信息清晰、规范
合并前必须发起 Pull Request 并通过审查
合并后及时清理本地与远程分支

这些规则看似繁琐，实则是在为项目“建防火墙”——防止错误蔓延，确保代码质量。就像建筑工地必须戴安全帽，Git 工作流程是开发团队的“安全规范”。

结语

掌握 Git 工作流程，不等于掌握 Git 命令，而是掌握一种协作思维。它不是束缚，而是让每个人都能在清晰的规则下高效工作。当你不再为合并冲突焦头烂额，不再为“谁改了哪里”而困惑，你就真正进入了专业开发的门槛。

记住：好的流程，不是让人“更累”，而是让人“更轻松”。从今天开始，让 Git 工作流程成为你开发习惯的一部分。