Git踩坑

文章目录

前言
- - ❓问题分析：为什么你的提交会"覆盖"别人的代码？
  - [✅ 正确的代码提交流程（结合你原文的说明）](#✅ 正确的代码提交流程（结合你原文的说明）)
  - - [**1. 确认自己在正确的分支上**](#1. 确认自己在正确的分支上)
    - [**2. 从主开发分支（如 dev）拉取最新代码并合并**](#2. 从主开发分支（如 dev）拉取最新代码并合并)
    - [**3. 解决冲突（如有）**](#3. 解决冲突（如有）)
    - [**4. 自己测试通过，确保功能正常**](#4. 自己测试通过，确保功能正常)
    - [**5. 提交到本地仓库**](#5. 提交到本地仓库)
    - [**6. 再次从远程拉一次（防止别人刚好也提交了）**](#6. 再次从远程拉一次（防止别人刚好也提交了）)
    - [**7. 最后，推送代码到远程**](#7. 最后，推送代码到远程)
  - ❗一定要注意的点：
  - 🚫常见误区
  - 📌你提到的分支说明，再理一遍（加理解）：
  - [✅ 总结一句话：](#✅ 总结一句话：)
- [1. **为什么会覆盖别人的代码？**](#1. 为什么会覆盖别人的代码？)
- [2. **详细举例说明**](#2. 详细举例说明)
- [3. **标准提交流程**](#3. 标准提交流程)
- - [步骤 1：切换到你的分支](#步骤 1：切换到你的分支)
  - [步骤 2：拉取远程最新 `dev` 代码，合并到你的分支](#步骤 2：拉取远程最新 dev 代码，合并到你的分支)
  - [步骤 3：解决冲突](#步骤 3：解决冲突)
  - [步骤 4：确认合并后测试代码](#步骤 4：确认合并后测试代码)
  - [步骤 5：提交合并后的代码](#步骤 5：提交合并后的代码)
  - [步骤 6：再次拉远程代码，防止别人这时又提交了代码](#步骤 6：再次拉远程代码，防止别人这时又提交了代码)
  - [步骤 7：推送你的代码到远程分支](#步骤 7：推送你的代码到远程分支)
- [4. **总结**](#4. 总结)
- [5. **如果跳过这几个步骤，结果会怎样？**](#5. 如果跳过这几个步骤，结果会怎样？)
- [6. **分支说明**](#6. 分支说明)

前言

想不明白，为啥我提代码会把别人的代码覆盖掉呢？注意注意：仓库提交代码，必须通过测试之后，没问题之后再提交！！！

记录：提交前--->git选自己的分支--->checkout --->merge拉取--->然后有冲突解决冲突，合并代码，注意注意注意！！！要查看自己的提交和别人的代码，不要修改别人的代码 --->commit--->提交到local仓库 --->再次拉取新的远程仓库merge，以防commit之后，还有人提交 --->push--->提交到远程仓库

关于自己的分支和dev,master,test,feat分支区别：自己的分支一般是从dev分支上merge过去，merge到自己的分支 dev分支--->开发主分支,提交前慎重,开发自测完要code review之后，还有提测完才能和master合并，注意注意！！！ test分支--->测试分支，一般是junit单元测试分支 master--->业务上线版本分支,一般没事儿别在这上面提交代码！！！ feat--->未来的新功能开发分支，后面也要往dev上合并！！！

这段话的核心是想理清一个问题：为什么你提交代码时，会把别人的代码"覆盖"掉？

❓问题分析：为什么你的提交会"覆盖"别人的代码？

这是因为 你本地代码不是最新的远程代码 ，你在提交时忽略了别人最近的提交或没有处理好合并冲突，导致：

你提交的内容把别人后来提交的内容"冲掉了"。

✅ 正确的代码提交流程（结合你原文的说明）

我帮你理一理标准操作顺序，并解释每一步原因：

1. 确认自己在正确的分支上

bash 复制代码

git checkout your-feature-branch

你的开发工作应当在你自己的分支上做，比如 feature/xxx，而不是在 dev、master 这种主分支上。

2. 从主开发分支（如 dev）拉取最新代码并合并

bash 复制代码

git fetch origin
git merge origin/dev

⚠️ 这一步非常重要！

目的是：拿到别人已经提交的最新代码，本地合并后解决冲突，保证你提交的不是"旧代码"。

3. 解决冲突（如有）

如果有冲突一定要认真处理，不能直接删掉或忽视别人加的代码，你可以：

对比冲突内容，看哪部分需要保留
用工具辅助，如 VS Code 的 Merge 工具

4. 自己测试通过，确保功能正常

不测试就提交很容易出错！

5. 提交到本地仓库

bash 复制代码

git add .
git commit -m "你的提交说明"

6. 再次从远程拉一次（防止别人刚好也提交了）

bash 复制代码

git fetch origin
git merge origin/dev

7. 最后，推送代码到远程

bash 复制代码

git push origin your-feature-branch

❗一定要注意的点：

合并前一定要看一下别人改了什么，不能无脑合并、无脑覆盖。
不要直接改别人的分支、不要直接改 master/test/dev 等主分支，你只能 PR 合并到主分支。
merge 有冲突就要认真解决，不是删掉冲突就完事，冲掉别人代码后果很严重。
每次 push 前都要再拉一次远程，确保你本地是最新的。

🚫常见误区

错误行为	后果
不拉远程直接提交	覆盖别人最新代码
合并时不看冲突内容	删掉别人写的逻辑
在 dev/master 直接写代码	很可能引起线上事故或冲突混乱
提交前不测试	上线后出 Bug

📌你提到的分支说明，再理一遍（加理解）：

your-feature-branch：你自己的开发分支
dev：开发主分支，最终所有人代码都要合到这
master：上线分支，必须经过测试才合并
test：测试验证的分支，一般运行 CI / 单元测试
feat：未来功能实验分支，开发结束后合并到 dev

✅ 总结一句话：

提交代码前一定要保证你本地是最新的远程代码，并且认真处理合并冲突、保留他人代码逻辑，不要直接覆盖。

好的，我给你详细具体地解释，为什么你"提代码会覆盖别人的代码"，以及怎么避免。过程会尽量通俗易懂。

1. 为什么会覆盖别人的代码？

Git 是一个分布式版本控制系统，大家的代码是并行提交的。当你提交时，实际上是用你本地的代码去"替换"远程仓库里对应分支的代码。

问题根源在于：

你本地代码和远程仓库的代码不一致（你本地是旧的，远程已经有人提交了新代码）。
你直接把本地代码推上去（push），会把远程的内容"替换"为你的本地代码。
但你的本地代码没有包含远程最新代码，就把别人改的代码"覆盖"了。

2. 详细举例说明

假设：

远程 dev 分支上，Alice 提交了一段代码A
你本地还是旧代码，没有拉取到Alice的改动

如果你直接 git push，你的旧代码会把包含代码A的远程代码覆盖，代码A就丢了。

3. 标准提交流程

步骤 1：切换到你的分支

bash 复制代码

git checkout your-feature-branch

你在自己分支上开发，不直接在主分支开发。

步骤 2：拉取远程最新 `dev` 代码，合并到你的分支

bash 复制代码

git fetch origin
git merge origin/dev

git fetch origin 会拉取远程仓库所有分支最新代码，但不合并。
git merge origin/dev 是把远程 dev 最新代码合并进你的分支。

为什么要这步？

确保你的代码和别人最新代码合到一起，避免冲突。

步骤 3：解决冲突

如果两边代码改了同一部分，Git 会告诉你有冲突：

bash 复制代码

CONFLICT (content): Merge conflict in your_file.java

你要手动打开冲突文件，Git 会标记冲突内容，比如：

text 复制代码

<<<<<<< HEAD
你这边的代码
=======
远程dev的代码（别人改的）
>>>>>>> origin/dev

你要仔细合并，保留你和别人都需要的代码，去掉标记。

步骤 4：确认合并后测试代码

确保你的功能没问题，别人代码也没被破坏。

步骤 5：提交合并后的代码

bash 复制代码

git add .
git commit -m "合并dev最新代码，解决冲突"

步骤 6：再次拉远程代码，防止别人这时又提交了代码

bash 复制代码

git fetch origin
git merge origin/dev

如果没有新提交，这步不会改东西；如果有，重复解决冲突流程。

步骤 7：推送你的代码到远程分支

bash 复制代码

git push origin your-feature-branch

4. 总结

操作	作用
`git fetch origin`	获取远程最新代码，不修改本地
`git merge origin/dev`	把远程最新代码合并到当前分支
解决冲突	确保合并代码没有错误，保留双方代码
测试	保证代码正确
`git push`	把本地最新代码上传远程

5. 如果跳过这几个步骤，结果会怎样？

你没拉取远程最新代码，push 时就直接覆盖远程代码，别人最新改动丢失。
合并时没认真解决冲突，可能删了别人重要代码。
直接在 dev 或 master 分支开发，风险高，容易破坏稳定代码。

6. 分支说明

你的分支（feature 分支）：自己开发用，不直接推到主分支
dev 分支：开发主线，功能合并汇总后，才推到这里
master 分支：上线分支，必须稳定，不随意改动
test 分支：测试用的，做自动测试等
feat 分支：未来新功能开发，合并到 dev

文章目录

前言

❓问题分析：为什么你的提交会"覆盖"别人的代码？

✅ 正确的代码提交流程（结合你原文的说明）

1. 确认自己在正确的分支上

2. 从主开发分支（如 dev）拉取最新代码并合并

3. 解决冲突（如有）

4. 自己测试通过，确保功能正常

5. 提交到本地仓库

6. 再次从远程拉一次（防止别人刚好也提交了）

7. 最后，推送代码到远程

❗一定要注意的点：

🚫常见误区

📌你提到的分支说明，再理一遍（加理解）：

✅ 总结一句话：

1. 为什么会覆盖别人的代码？

2. 详细举例说明

3. 标准提交流程

步骤 1：切换到你的分支

步骤 2：拉取远程最新 dev 代码，合并到你的分支

步骤 3：解决冲突

步骤 4：确认合并后测试代码

步骤 5：提交合并后的代码

步骤 6：再次拉远程代码，防止别人这时又提交了代码

步骤 7：推送你的代码到远程分支

4. 总结

5. 如果跳过这几个步骤，结果会怎样？

6. 分支说明

步骤 2：拉取远程最新 `dev` 代码，合并到你的分支