文章目录

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

git checkout your-feature-branch

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

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

git fetch origin
git merge origin/dev

⚠️ 这一步非常重要！
目的是：拿到别人已经提交的最新代码，本地合并后解决冲突，保证你提交的不是“旧代码”。

3. 解决冲突（如有）

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

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

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

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

5. 提交到本地仓库

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

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

git fetch origin
git merge origin/dev

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

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：切换到你的分支

git checkout your-feature-branch

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

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

git fetch origin
git merge origin/dev

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

为什么要这步？
确保你的代码和别人最新代码合到一起，避免冲突。

步骤 3：解决冲突

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

CONFLICT (content): Merge conflict in your_file.java

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

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

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

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

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

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

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

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

git fetch origin
git merge origin/dev

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

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

git push origin your-feature-branch

4. 总结

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