前言
很多刚入职的同学，在 VSCode 里 clone 下公司的代码后，对着键盘总是小心翼翼：“我在本地随便改代码，按了 Ctrl+S 会不会直接影响线上的代码？会不会把公司系统搞崩溃？”
答案是：绝对不会！
只要你没有敲下特定的 Git 上传命令，你在本地电脑上就算把代码全删光，云端的服务器连一根毫毛都不会少。今天，我们就来彻底理清 Git 协作的正确姿势，让你在 VSCode 里安心敲代码！

一、 核心概念：本地与云端是隔离的

我们可以把 Git 协作想象成玩单机游戏和云存档：

• git clone 就像是你第一次下载游戏客户端。从此以后，你的电脑和云端服务器就断开了。你在本地怎么折腾，都只是在修改本地的“单机文件”。
• 只有当你主动发起 push (推送) 时，你的本地存档才会同步到云端。

二、 新手日常开发的 6 步标准流程

为了保证多人协作时不打架，现代企业通常采用 “基于主干开发 (Trunk Based Development)” 模式。请严格按照以下 6 步进行日常开发：

第 1 步：拿到最新的“云存档”
每次开始写新功能前，先确保你的基础代码是最新的。

git checkout main      # 切换回主干道
git pull               # 下载云端最新的代码

第 2 步：创建你的“独立工作室”
🚨 核心红线：永远不要直接在 main 分支上写代码！

git checkout -b 你的名字拼音/日期  # 例如：git checkout -b zhangsan/0306

切出分支后，你就可以在 VSCode 里尽情施展才华了。

第 3 步：把修改“本地保存”
代码写完后，要把改动打包封箱。注意，此时云端依然不知道你做了什么。

# 1. 运行团队规定的检查命令，确保格式规范且无报错
# (注：不同项目命令不同，如 npm run lint 或 yarn check 等，请按你们团队规范来)
pnpm check:local	

# 2. 把改动添加到暂存区
git add .		

# 3. 提交说明
git commit -m "feat(模块名): 新增了xxx功能"  # 务必写清楚提交信息

第 4 步：排版理顺代码（防止合并冲突）
在你写代码的这几个小时里，同事可能已经提交了新代码。我们需要把他们的代码拉下来，完美地“垫”在你的代码下面。

git fetch origin              # 偷偷看一眼云端有没有变化
git rebase origin/main        # 把你的改动"重新排版"到最新主分支的顶部

第 5 步：把你的修改“发快递到云端”

git push origin zhangsan/0306 # 把你的专属分支推送到云端服务器

第 6 步：提交 PR (Pull Request) 审核
去 Github/Gitlab/Gitea 网页上，点击 New Pull Request。请同事审核你的代码，审核通过后，你的心血就会正式并入 main 主分支，完成部署！

三、 为什么企业严禁使用 git merge？

很多新手教程会教 git merge，但在企业实战中，我们通常推荐 git rebase（变基）。

• 如果用 merge： 多人交叉合并，Git 历史记录会变成一团乱麻的蜘蛛网。将来出了 Bug 很难回溯。
• 如果用 rebase： 它的意思是“把我的改动像接积木一样排在别人代码后面”。所有的提交记录会变成一条完美的直线，极其清晰。

总结

不要害怕弄坏什么。只要记住：不在 main 分支上直接写代码，不乱用 git merge 命令，你在自己的分支上就是绝对安全的！遇到报错或冲突不懂，放心大胆地去问同事。祝大家搬砖愉快！