克隆本身不会产生冲突，所谓“克隆冲突”实为克隆后立即执行git pull或merge时触发的合并冲突，或因目录残留未清理导致的拉取失败。
克隆本身不会产生冲突——git clone 是单向、干净的初始化操作，不存在“克隆冲突”这种说法。你真正遇到的问题，大概率是克隆后立即执行 git pull 或 git merge 时触发的合并冲突，或是本地已有未提交修改却强行拉取导致的失败。
为什么 clone 后立刻 pull 会报 conflict？
这不是克隆的问题，而是你克隆前目录里已有同名文件或未初始化的 Git 仓库残留。Git 在 git pull 时尝试把远程内容合并进当前分支，但发现工作区有未跟踪/未暂存的文件（比如 README.md、.gitignore），且和远程同名文件内容不同，就会拒绝自动合并并提示 “error: Your local changes to the following files would be overwritten by merge”。
- 典型现象：
git clone成功，但紧接着git pull origin main报错，提示 “Please commit your changes or stash them before you merge” - 根本原因：当前目录不是空的，或已存在一个没删干净的
.git目录（哪怕只是隐藏子目录） - 验证方法：运行
ls -la看是否有残留.git；运行git status看是否报 “not a git repository” 或 “detached HEAD” 异常状态 - 解决动作：直接删掉整个目录重来，或用
rm -rf .git彻底清理再git init && git remote add origin && git pull
git pull --rebase 失败并卡在 conflict 怎么办？
使用 --rebase 拉取时，Git 不是做 merge，而是把你的本地提交“重放”到远程最新提交之后。一旦重放过程中某次提交修改了和远程新提交相同的文件区域，就会中断并停在冲突状态——此时你不在 merge，而在 rebase 中间态。
- 关键区别：
git status显示 “REBASING” 而非 “MERGING”，且git log看不到你自己的提交出现在远程提交之后 - 不能用
git commit结束，必须用git add <file></file>标记解决后执行git rebase --continue - 如果改错了想退回重来：
git rebase --abort（它会完全撤销整个 rebase 过程，回到 pull 前状态） - 慎用
--skip：跳过当前提交可能丢逻辑，只在确认该提交纯属误操作时才用
remote rejected: non-fast-forward 是同步失败还是冲突？
这是推送（git push）被拒，和克隆、拉取无关，也**不是代码冲突**，而是 Git 拒绝覆盖远程历史——说明你本地分支落后于远程，但你试图用强制覆盖方式推送（比如刚硬重置过 git reset --hard）。
- 错误信息典型长这样：
! [rejected] main -> main (non-fast-forward) - 真实含义：你的本地
main提交历史不包含远程main的最新提交（即不是它的直接后代） - 正确做法不是强行 push，而是先
git fetch origin && git merge origin/main或git pull --rebase拉平差异 - 只有在明确知道后果且团队允许时，才用
git push --force-with-lease（比--force安全）
最易被忽略的一点：所有看似“同步故障”的表象，背后几乎都藏着一个被忽视的状态检查动作——git status 和 git log --oneline --graph --all 应该成为你敲任何同步命令前的肌肉记忆。没有这两条输出，你其实并不知道自己站在哪条分支、有没有未提交变更、当前 HEAD 指向哪里。盲目操作只会让问题从“可修复”滑向“需重克隆”。
