从0到1搭建VS Code代码片段：Git工作流 | 看完就会配

▌ 技术引导 我直接上手配置了 Git 工作流，用 VS Code 打造一个高效的本地开发和协作环境。在 2024 到 2026 年期间，很多团队开始用 Git 分支策略代替老式的 SVN，但很多人不知道如何从 0 到 1 搭建一个符合自己团队节奏的工作流。我见过最离谱的配置是连基本的分支命名规则都没有，导致每次合并都得手动清理垃圾代码。你知道吗？设置 `.gitignore` 是第一步，但接下来要配置 Git 的别名、预提交钩子、远程仓库、分支保护和权限控制才叫真本事。别小看这些，它们能让你的代码推送更安全，分支管理更清晰，代码合并更高效。如果你是刚开始接触 Git，或者你的项目已经有一段时间了，这篇内容会让你少走 80% 的弯路。 ▌ 技术参考 一 配置 Git 别名是提升效率的神技。默认的 `git status`、`git commit`、`git push` 命令太啰嗦了，我改成 `gstatus`、`gcommit`、`gpush`，这样敲键盘省力多了。别名设置在全局 `.gitconfig` 文件里，用 `git config --global alias.gstatus status` 这种方式，执行 `git gstatus` 就能看到状态。我见过很多人在别名设置后忘记更新本地配置，结果用着别名还卡在旧命令里。别名还不能只改命令，得加上别名的使用场景，比如 `git config --global alias.last "log -1"` 配合 `git last` 能快速查看最近一次提交。 二 预提交钩子配置能避免很多低级错误。我喜欢在 `.git/hooks` 目录下写一个 `pre-commit` 脚本，用来检查代码规范、格式、类型检查、单元测试覆盖率和静态分析。我用的是 `husky` 工具，它能自动安装钩子，配置起来特别方便。安装命令是 `npm install husky --save-dev`，然后 `npx husky install`，接着在 `package.json` 里写 `husky`: `{ "hooks": { "pre-commit": "lint-staged" } }`。这样每次提交前都会触发检查，如果出问题就直接阻止提交。我踩过坑，就是没配置这个，导致环境变量没写，代码提交后又得回滚，超级恼火。 三 远程仓库配置需要特别注意权限管理。我之前在配置 GitHub 远程仓库时，因为权限写错了，导致本地代码推不了。正确做法是用 `git remote add origin <仓库URL>`，然后检查 `git remote -v` 确认是否正确。权限部分，如果用 SSH 方式，得先生成密钥对，用 `ssh-keygen -t ed25519 -C "your_email@example.com"` 生成，然后把公钥粘贴到 GitHub 设置里。如果用 HTTPS，得配置 `git config --global url."https://github.com/.insteadOf git@github.com:`，这样就能统一用 HTTPS 地址，避免每次输入密码。我见过团队把远程仓库地址写在代码里，结果被安全扫描工具拦截，险些造成数据泄露。 四 分支策略是 Git 工作流的核心。我见过最多的是 `main`、`develop`、`feature`、`bugfix`、`release`、`hotfix` 这些分支命名方式。但不是所有团队都这么规范，有的直接用数字编号，有的用 `todo-...` 这种模糊命名，导致后来看不清是谁写的什么内容。正确的分支命名规则是：`feature/xxx` 表示新功能，`bugfix/xxx` 表示补丁，`release/xxx` 表示版本发布，`hotfix/xxx` 表示紧急修复，`main` 是主分支，`develop` 是开发分支。我之前用 `main` 当开发分支，结果线上部署撞上本地 `main` 代码，乱得要命。现在都统一用 `develop` 作为开发分支，用 `main` 作为生产分支。 五 分支保护必须在远程仓库设置。我之前没有设置分支保护，结果有人直接 push 到 `main`，导致生产环境代码被覆盖。现在我都是在 GitHub 或 GitLab 上配置分支保护规则，只允许 pull request 合并，禁止直接 push。配置方法是进入仓库设置，找到分支保护选项，开启 `require pull request before merging`，还可以设置 `required status checks`，比如 CI 测试必须通过才能合并。我见过团队用 `git push --force` 强行覆盖分支，结果引起代码冲突，甚至需要重写 commit 历史，非常鸡肋。 六 本地 Git 配置要合理，特别是提交信息格式。我之前用的是自由格式的提交信息，后来换成 `Conventional Commits` 标准，用 `feat: add new component` 或 `fix: bug in xyz` 这种结构，这样团队协作更清晰。设置方法是 `git config commit.template .gitmessage`，然后在 `.gitmessage` 文件里写好模板。我见过项目提交信息随意，导致代码审查时搞不清楚是谁改了什么，最后只能靠 `git blame` 去找人。现在有了标准提交信息，审代码效率直接翻倍。 七 使用 `git diff` 时要加 `--cached` 参数，这样能看到暂存区的改动，而不是工作区的。我之前经常忘记加这个参数，导致误删了还没提交的文件。`git diff --cached` 是个好习惯，用来确认暂存区和 HEAD 之间的差异。我发现很多人用 `git diff` 就是看所有改动，其实这样容易被误操作带偏。我配了别名 `gdiff --cached`，这样就能快速查看已暂存的代码变更，避免提交后发现问题还得回滚。 八 CI/CD 集成是 Git 工作流的关键部分。我用的是 GitHub Actions，首先在仓库根目录创建 `.github/workflows` 文件夹，然后写一个 `ci.yml` 文件，里面配置 `name: CI Pipeline`，定义 `on: push` 触发，用 `jobs` 定义测试任务。比如 `jobs: test: runs-on: ubuntu-latest: steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3: with: node-version: '18.x' - run: npm install - run: npm test`。我见过团队没有配置 CI，导致每次提交都得人工测试，效率极低。现在每次 push 都会自动运行测试，有问题直接拦截，省了很多时间。 九 GUI 工具推荐使用 VS Code 的 Source Control 面板，它能展示所有修改过的文件，支持 `git add`、`git commit`、`git push` 一键操作。我之前用的是命令行，后来发现 VS Code 的图形化界面更直观，特别是处理冲突时。配置方法是打开 Source Control 面板，点击 `+` 添加文件，然后 commit 前选择所有要提交的文件。我还用 `git log` 配合 `git reflog` 来查看历史提交记录，避免误删。我见过有人用 VS Code 但没开启 `git` 集成，结果每次只能用命令行操作，效率差很多。 十 使用 `git stash` 可以保存当前修改，等需要的时候再恢复。这个命令特别适合切换分支时临时保存代码。比如 `git stash save "work on xyz"`，然后 `git stash apply` 恢复。我之前没用过 `git stash`，结果切换分支时漏掉了很多未提交的代码，后来花了半天时间找。现在每次切换分支都先 `git stash`，再切换到目标分支，这样就不会丢失代码。你也可以在 VS Code 的终端里快速执行，不用每次都打开命令行。 十一 权限管理不能只靠远程仓库，还得本地配置 `git config credential.helper store`，这样登录凭据会保存在本地。但我之前用的是 `git config credential.helper cache`，导致凭据只存 15 分钟。现在都改成 `store`，这样每次 push 不用输入密码。不过要小心，一旦用了 `store`，密码会以明文形式存在 `.git-credentials` 文件里，这在某些环境下可能会有安全风险。我见过有人用 `store` 导致密码泄露，后来不得不手动删除 `.git-credentials` 文件，非常麻烦。 十二 代码合并时要避免 `git merge`，用 `git merge --no-ff`，这样能保留合并提交，方便追溯历史。我之前总用 `git merge`，结果分支合并后历史线太乱，查问题困难。现在都用 `--no-ff`，这样合并提交的记录更清晰。还有 `git rebase` 的用法，适合解决冲突时使用，但要用在 `develop` 之前。我见过有人用 `rebase` 合并 `main` 分支，结果提交历史被改乱，大家看不清是谁改的什么。 十三 标签管理不能随便打，得用语义化版本号。比如 `v1.0.0`、`v1.0.1`、`v1.1.0`，这样版本迭代更清晰。打标签的命令是 `git tag -a v1.0.0 -m "Initial release"`，然后 `git push origin --tags` 推送到远程。我之前随便打标签，导致版本混乱，后来用 `semantic-release` 自动打标签，效率高还规范。不过要小心别打到 `develop` 分支，标签应该只在 `main` 或 `release` 分支打。 十四 权限控制要考虑 `git push` 和 `git fetch` 的限制。我之前在团队协作中，让新人只能 `fetch`，不能 `push`，这样避免他们乱改代码。配置方法是用 `git config push.default simple`，这样他们在 `git push` 时只能推送到当前分支，不会覆盖别人的工作。我还用 `git config pull.rebase true`，这样 `git pull` 会用 `rebase` 而不是 `merge`，保持提交历史的线性。我踩过坑，就是没设置 `pull.rebase`，结果合并时出现冲突，合并提交变得难看。 十五 配置远程仓库镜像能加速同步。我之前用 `git remote add mirror `，然后 `git push --mirror` 同步所有分支。这样本地和远程的分支状态完全一致，特别适合团队协作。镜像仓库可以是另一个远程 Git 仓库，比如 GitLab 或 Bitbucket。我见过团队没有配置镜像，导致分支同步慢，每次 push 都得等很久。现在都用镜像远程仓库，提升不少效率。 十六 协作时要统一分支策略，比如 GitHub 的 `squash merge`。我之前没用这个，导致合并提交太多，看不清谁改了什么。现在都用 `squash merge` 把多个 commit 合并成一个，这样主分支历史更干净。在 GitHub 上设置方法是进入合并选项，选择 `Squash and merge`，然后自动合并所有 commit。我见过团队没用这个，导致合并后 commit 历史混乱，代码审查时需要分析多个提交，效率低。 十七 提交信息格式化工具推荐用 `commitlint`，配合 `husky` 和 `lint-staged` 使用。安装命令是 `npm install commitlint @commitlint/config-conventional --save-dev`，然后在 `package.json` 里配置 `commitlint`，设置 `extends` 为 `@commitlint/config-conventional`。这样每次提交都会自动校验格式，不符合就阻止提交。我之前没用这个，导致提交信息杂乱无章，后来用上之后，团队协作更顺畅，代码变更更清晰。 十八 使用 `git log` 时要加上 `--oneline` 参数，这样只显示提交摘要，更方便浏览。我之前没加这个，结果每次看日志都得翻很多行，效率低。还有 `git log --graph` 能画出分支图，帮助理解代码流向。我见过团队没有这些配置，导致每次查日志都费劲，后来都加上了这些参数，查问题更快了。 十九 分支策略要和团队沟通好，不能自己一套，别人一套。我之前用的是 `git flow`，后来发现大家都不习惯，改成了 `GitHub Flow`，这样更简单。`GitHub Flow` 的特点是所有开发都在 `main` 分支，通过 pull request 合并。我见过团队用 `Git Flow` 但没人知道怎么操作，导致分支混乱，合并困难。现在都统一用 `GitHub Flow`，简单高效。 二十 远程仓库同步可以使用 `git fetch --all` 或 `git pull --rebase` 来确保本地有最新的代码。我之前没用这些，导致合并冲突频繁，每次都要手动处理。现在都养成习惯，每次切换分支前先 `fetch --all`，确保代码是最新的。还有 `git pull --rebase`，这样能避免冲突，保持提交历史线性。我见过很多新手不知道这个命令，导致冲突多如牛毛，合并不顺利。