1. 安全拉取项目 (Clone)

很多新人入职第一天卡在这里：有权限但拉不下来代码。这通常是因为还在用 HTTPS 这种老旧方式。

场景模拟：入职第一天

组长给你发了一个仓库地址：git@gitlab.company.com:backend/api-service.git。
你直接复制去下载，结果报错：Permission denied (publickey)。

正确步骤：配置 SSH Key

这是为了让公司服务器认识你的电脑（相当于录入指纹），配置一次，永久有效。

# 1. 在终端输入生成命令 (一路回车即可) ssh-keygen -t ed25519 -C "your_email@company.com" # 2. 查看并复制生成的公钥 (Windows 使用 type, Mac 使用 cat) cat ~/.ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... (复制这一长串)

最后一步： 打开公司 GitLab/GitHub 网页 -> 点击头像 -> Settings -> SSH Keys -> 粘贴进去并保存。

现在，执行拉取

git clone git@gitlab.company.com:backend/api-service.git Cloning into 'api-service'... done.

2. 标准开发流程 (Daily Workflow)

场景模拟：修改登录页标题

任务：把 index.html 里的标题从 "Welcome" 改成 "Hello"。

Step 1: 检查状态

git status modified: index.html # 只要是红色的文件名，说明 Git 发现了修改但还没受理

Step 2: 加入暂存区 (Add)

git add index.html # 再次 git status 会变成绿色，说明已经放入“发货箱”

Step 3: 提交存档 (Commit)

git commit -m "feat: 更新首页标题文案" [main 2f3a1c] feat: 更新首页标题文案

3. 核心难点：Merge 还是 Rebase?

这是小白最容易混淆的地方。两者都是“合并代码”，但结果完全不同。

场景模拟

你在 feature 分支开发，同时同事在 main 分支提交了新代码。现在你需要更新你的分支，把同事的代码同步进来。

Method A: Git Merge

git merge main

特点：保留完整历史，但会生成一个额外的“合并节点”，导致历史线分叉、像渔网一样乱。

Method B: Git Rebase (变基)

git rebase main

特点：把你的提交“剪切”下来，“粘贴”到同事最新提交的后面。历史线是一条直线，非常干净。

⚠️ 黄金法则：
1. 在自己的私有分支上（别人不用的），为了保持整洁，尽量用 Rebase。
2. 在公共分支上（如 main/dev），绝对禁止使用 Rebase，必须用 Merge。

4. 手把手解决冲突

场景模拟

你和同事小李都修改了 config.js 的第 3 行。
小李改成了 timeout = 5000 并先推送了。
你改成了 timeout = 3000，拉取时报错：CONFLICT (content): Merge conflict in config.js。

Step 1: 打开代码编辑器

你会看到如下乱码，不要怕，这是 Git 在问你选哪个：

            <<<<<<< HEAD

            const timeout = 3000; // 你的代码

            =======

            const timeout = 5000; // 小李的代码 (Incoming)

            >>>>>>> 4a5b6c...

Step 2: 修改代码

直接删除那些 <<< === >>> 符号，保留你认为正确的数值（比如协商后决定用 5000）。

            const timeout = 5000;
        

Step 3: 告诉 Git 你修好了

git add config.js # 如果是 merge 产生的冲突： git commit -m "fix: 解决超时时间冲突" # 如果是 rebase 产生的冲突： git rebase --continue

5. 救命药丸：写错了怎么办？

场景 A: 只是写乱了，还没 add

“把文件还原成上次提交的样子，我刚写的都不要了。”

git checkout .

场景 B: 已经 add 了，但不想 commit

“哎呀，多添加了一个文件到暂存区。”

git reset HEAD file.txt

场景 C: 已经 commit 了，想撤销这次提交

“刚才提交的代码有 Bug，我要撤销这次提交，但保留代码让我再改改。”（最常用）

git reset --soft HEAD~1 # --soft 意思是：撤销提交记录，但保留文件修改在暂存区

6. 忽略文件配置 (.gitignore)

有些文件永远不应该上传到仓库，比如：密码文件、操作系统缓存、巨大的 node_modules、日志文件。

场景模拟：门卫机制

Git 有一个门卫叫 .gitignore。如果你把文件名写在里面，Git 就会假装看不见它们，git status 不会提示，git add 也不会添加。

如何配置？

在项目最外层新建一个名为 .gitignore 的文件（注意前面有个点），写入以下内容：

.gitignore TEXT

# 1. 忽略系统生成文件 .DS_Store Thumbs.db # 2. 忽略依赖包 (体积巨大，必须忽略) node_modules/ dist/ # 3. 忽略环境变量与密钥 (安全第一！) .env secret.key # 4. 忽略日志 *.log

⚠️ 救命：我忽略了，但它还是被上传了？

原因：文件在添加进 .gitignore 之前已经被 Git 追踪了。
解决办法：必须先从 Git 缓存中删除它。

git rm -r --cached . # 清除所有缓存 git add . # 重新添加，此时 .gitignore 才会生效 git commit -m "fix: 重置忽略规则"

7. 综合实战：开发者的一天

这里模拟从接到需求到代码上线的全过程。请按顺序执行。

09:00 AM

接到新需求

任务：开发“联系我们”页面 (contact.html)。
原则：永远不要在 main 分支直接写代码，第一件事是切新分支。

# 1. 确保主分支是最新的 git checkout main git pull # 2. 创建并切换到新分支 git checkout -b feat/contact-page

10:30 AM

沉浸式开发

你在项目中新建了 contact.html 并写完了代码。现在需要保存。

git status Untracked files: contact.html git add . git commit -m "feat: 新增联系我们页面"

11:00 AM

突发状况：主线变了

准备提交时，发现同事刚刚向 main 分支推送了公共组件更新。你需要把这些更新“同步”到你的分支里。

关键点此时使用 Rebase 让历史更干净。

# 1. 抓取远程最新变动 (不合并，只下载) git fetch origin main # 2. 变基：把你的提交“嫁接”到最新代码后面 git rebase origin/main Successfully rebased and updated refs/heads/feat/contact-page.

11:15 AM

提交上线

本地测试通过，代码是最新的，历史是干净的。发射！

git push origin feat/contact-page

之后去 GitLab/GitHub 网页上点击 "Create Merge Request" 即可。