Git踩坑
文章目录
- 前言
- ❓问题分析：为什么你的提交会“覆盖”别人的代码？
- ✅ 正确的代码提交流程（结合你原文的说明）
- **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 | 把本地最新代码上传远程 |
5. 如果跳过这几个步骤，结果会怎样？
- 你没拉取远程最新代码，push 时就直接覆盖远程代码，别人最新改动丢失。
- 合并时没认真解决冲突，可能删了别人重要代码。
- 直接在
dev或master分支开发，风险高，容易破坏稳定代码。
6. 分支说明
- 你的分支（feature 分支）：自己开发用，不直接推到主分支
- dev 分支：开发主线，功能合并汇总后，才推到这里
- master 分支：上线分支，必须稳定，不随意改动
- test 分支：测试用的，做自动测试等
- feat 分支：未来新功能开发，合并到 dev