Git综合实战：从零搭建项目、团队协作、自动化流程、发布管理全流程
说实话，很多同学学完Git的基本操作后，最困惑的就是——这些命令到底怎么串起来用？
我见过太多人，单独问「git merge怎么用」答得头头是道，一放到真实项目里就手忙脚乱。今天咱们就拿一个完整的项目来走一遍，从零开始，一直到发布上线。你跟着我走完这一趟，以后自己带项目心里就有底了。
一、项目初始化：从零开始
假设我们现在要做一个「在线任务看板」系统。团队5个人，我作为技术负责人来搭这个架子。
第一步：创建远程仓库
我个人习惯用GitHub，当然GitLab、Gitee都行。在网页上点「New repository」，名字叫task-board，选私有仓库。
然后回到本地，开始干活：
mkdir task-board
cd task-board
git init
echo "# 任务看板系统" > README.md
git add .
git commit -m "chore: 初始化项目，添加README"嗯，这里有个小细节——我习惯在commit message里加前缀。chore:表示杂务，feat:表示新功能，fix:表示修bug。这个习惯帮我省了不少事，后面你就知道了。
git remote add origin git@github.com:yourname/task-board.git
git push -u origin main为什么要加-u？说白了就是告诉Git：「以后我直接敲git push就推到这个分支，不用每次都指定」。我刚开始学的时候老忘加，每次都要多打几个字，烦得很。
二、分支策略：团队协作的基石
团队协作最怕什么？最怕大家在同一根绳子上改代码，改着改着就打架了。
我推荐的分支模型是这样的：
| 分支名称 | 用途 | 谁可以推 |
|---|---|---|
main |
生产就绪代码，永远可部署 | 只有通过PR合并 |
develop |
日常开发集成分支 | 开发者通过PR合并 |
feature/* |
具体功能开发 | 个人推送 |
hotfix/* |
紧急修复 | 维护者推送 |
举个例子，小张要开发「拖拽排序」功能：
git checkout -b feature/drag-sort develop
# 写代码...
git add .
git commit -m "feat: 实现任务卡片拖拽排序"
git push origin feature/drag-sort然后他在GitHub上发起Pull Request，目标分支选develop。我来做Code Review，没问题就合并。
我的个人经验：PR的描述里一定要写清楚「改了啥、为什么改、怎么测试」。我曾经因为PR描述写得太简单，同事看不懂，来回问了5次才合并——浪费了整整一下午。
三、自动化流程：让机器干机器的活
人总会犯错，但机器不会。所以我们要把重复的事情交给CI/CD。
我在项目根目录下创建.github/workflows/ci.yml：
name: CI Pipeline
on:
push:
branches: [ develop, main ]
pull_request:
branches: [ develop, main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: 安装依赖
run: npm ci
- name: 运行测试
run: npm test
- name: 代码风格检查
run: npm run lint这个配置的意思是：只要有人往develop或main推代码，或者发起PR，就自动跑测试和代码检查。
为什么会这样？因为有一次我合并了一个PR，结果发现测试没通过——原来提交者忘了跑测试。从那以后，我就把「自动跑测试」写进了CI，不通过就不让合并。
注意：CI配置里一定要加npm ci而不是npm install。npm ci会严格按照package-lock.json安装，不会偷偷升级依赖版本。我曾经因为npm install自动升级了小版本，导致生产环境出了个诡异的bug，查了两天才找到原因。
四、发布管理：版本号的艺术
项目开发了一段时间，功能攒够了，准备发第一个正式版本。
我遵循语义化版本规范：主版本.次版本.修订号。
- 修bug：递增修订号，比如
1.0.0→1.0.1 - 加功能（向后兼容）：递增次版本，比如
1.0.0→1.1.0 - 大改（不兼容）：递增主版本，比如
1.0.0→2.0.0
发布流程是这样的：
# 从develop创建发布分支
git checkout -b release/1.0.0 develop
# 更新版本号
npm version 1.0.0
# 生成变更日志
git log --oneline --no-decorate develop..release/1.0.0 > CHANGELOG.md
# 合并到main
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "版本1.0.0：初始发布"
git push origin main --tags
# 合并回develop
git checkout develop
git merge --no-ff release/1.0.0这里我用了--no-ff，也就是禁止快进合并。为什么？因为我想保留分支历史，一眼就能看出「哦，这个commit是从release分支合并进来的」。你想想看，如果用了快进合并，所有commit就变成一条直线，根本分不清哪个是发布节点。
五、知识体系总览
下面这张图，是我对这个全流程的理解。你看一遍，心里就有谱了：
六、避坑指南：我踩过的那些坑
最后分享几个我亲身经历的血泪教训：
坑1：直接在main上改代码
我曾经有一次觉得「就改一行配置，不用走流程了」，直接在main上改了然后推送。结果那行配置写错了，导致整个生产环境挂了20分钟。从那以后，我立了规矩：main分支必须保护，任何人都不能直接推。
坑2：合并冲突处理不当
有次小张和小李同时改了同一个文件的不同部分，合并时产生了冲突。小张没仔细看，直接把冲突标记删了就提交了——结果把小李的代码全删了。我的建议是：遇到冲突别慌，用git mergetool或者IDE的对比工具，逐行确认。
坑3：忘记打tag
项目上线后，客户反馈有个bug。我查了半天才发现——线上跑的代码跟最新的main不一样，因为上次发布后忘了打tag，后来有人又合并了其他代码。现在我的习惯是：每次发布必须打tag，而且tag名必须跟版本号一致。
好了，这一整套流程走下来，你应该能感受到Git在真实项目中的用法了。说白了，Git本身不难，难的是怎么把它用对、用好。你按照这个流程去实践，遇到问题再回来翻翻，慢慢就熟练了。