3、Git工作流：初始化Git仓库，配置.gitignore，建立分支管理策略（Git Flow）

好，咱们开始聊Git。说实话，Git这东西，很多同学都会用，但真正用得好的不多。我见过太多项目，master分支上直接改代码，或者.gitignore里啥都没配，结果node_modules都提交上去了。嗯，这期咱们就把这些坑填上。

3.1 初始化Git仓库

新建一个项目，第一件事就是初始化Git。我个人习惯用命令行，简单直接：

cd your-project
git init

这就创建了一个本地仓库。但光有本地还不够，你得有个远程仓库。我一般用GitHub或GitLab，看团队习惯。创建好远程仓库后，把本地关联上去：

git remote add origin git@github.com:yourname/your-project.git

这里有个小细节——我建议用SSH协议而不是HTTPS。为什么？因为SSH不用每次输密码，省心。我之前有个项目用HTTPS，每次push都要输账号密码，烦得很。后来统一改成SSH，世界清静了。

3.2 配置.gitignore

接下来是.gitignore。这文件看似简单，但坑不少。说白了，它的作用就是告诉Git：哪些文件不要管。

一个Vue项目，至少得忽略这些：

# 依赖目录
node_modules/

# 构建产物
dist/
build/

# 环境变量文件（可能包含敏感信息）
.env.local
.env.*.local

# IDE配置
.vscode/
.idea/
*.swp
*.swo

# 系统文件
.DS_Store
Thumbs.db

# 日志
*.log
npm-debug.log*

# 测试覆盖率
coverage/

这里我要特别强调一下环境变量文件。我曾经见过一个项目，.env文件被提交到了仓库里，里面赫然写着数据库密码和API密钥。嗯，那场面，相当尴尬。所以记住：.env文件可以提交（里面放公共配置），但.env.local、.env.development.local这些带local后缀的，一定要忽略。

还有一个容易忽略的点——IDE配置。每个人的编辑器偏好不同，.vscode或.idea目录里的设置文件，不应该强制别人使用。所以，忽略它们。

3.3 建立分支管理策略（Git Flow）

好了，仓库初始化了，忽略文件配好了。接下来是最关键的部分——分支策略。

我个人强烈推荐Git Flow。虽然有人觉得它有点重，但对于中大型项目来说，这套流程真的能救命。我经历过没有分支策略的团队，大家直接在master上开发，结果发布前乱成一锅粥。从那以后，我再也不敢不用Git Flow了。

3.3.1 Git Flow的核心分支

分支类型	命名规则	用途
master	master	生产环境代码，只接受合并，不接受直接提交
develop	develop	开发主分支，所有功能分支都从这里拉出
feature	feature/xxx	开发新功能，完成后合并到develop
release	release/x.x.x	发布前准备，只修bug，不添新功能
hotfix	hotfix/x.x.x	紧急修复生产环境bug，从master拉出，修复后合并回master和develop

你想想看，这五个分支各司其职，是不是很清晰？

3.3.2 实际操作流程

咱们走一遍实际流程。假设你接到一个新功能——用户登录模块。

第一步：从develop拉出feature分支

git checkout develop
git pull origin develop
git checkout -b feature/user-login

第二步：在feature分支上开发

该写代码写代码，该提交提交。记住一点：频繁提交，但提交信息要规范。我一般用这种格式：

feat: 添加用户登录功能
fix: 修复登录按钮点击无响应的问题
refactor: 重构登录表单验证逻辑

第三步：开发完成，合并到develop

git checkout develop
git pull origin develop
git merge --no-ff feature/user-login
git branch -d feature/user-login

这里有个关键参数——--no-ff。它的作用是禁用快进合并，保留分支历史。说白了，就是让你能清楚地看到哪些提交是属于这个功能的。我建议你养成这个习惯。

3.3.3 发布流程

当develop上的功能积累到一定程度，准备发布时：

git checkout develop
git pull origin develop
git checkout -b release/1.0.0

在release分支上，只修bug，不添新功能。修完后：

git checkout master
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "版本1.0.0发布"

git checkout develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

打tag这个习惯，我建议你一定要养成。为什么？因为以后出问题了，你可以快速回滚到某个版本。我曾经在一个项目里，没有打tag，结果要回滚时只能靠猜。那感觉，别提多难受了。

3.3.4 紧急修复流程

生产环境出了bug，怎么办？别慌，走hotfix流程：

git checkout master
git pull origin master
git checkout -b hotfix/1.0.1

修复完成后：

git checkout master
git merge --no-ff hotfix/1.0.1
git tag -a v1.0.1 -m "紧急修复1.0.1"

git checkout develop
git merge --no-ff hotfix/1.0.1
git branch -d hotfix/1.0.1

3.4 总结一下

嗯，这一章的内容其实就三件事：

• 初始化仓库——用SSH，别用HTTPS
• 配置.gitignore——别忘了环境变量和IDE配置
• 建立Git Flow——master、develop、feature、release、hotfix，各司其职

这套流程我用了好几年，从最初的手忙脚乱到现在的行云流水，说白了就是熟能生巧。你刚开始可能会觉得麻烦，但坚持下来，你会发现它真的能帮你省掉很多不必要的麻烦。

下一章，咱们聊聊项目目录结构的设计。这个也是个大话题，到时候见。