不能用git pull替代git fetch+git merge，因其默认自动merge会生成无关merge commit、污染历史，且本地有未提交变更时易报错或冲突；git fetch是只下载不改动的“安全探针”。
单兵作战时用 git commit + git push 就能闭环，但一进团队协作，直接沿用这套流程大概率会覆盖别人代码、触发不可控冲突、甚至误删分支——本质不是 Git 不好用，而是本地习惯没适配分布式协作的约束条件。
为什么 git pull 不能替代 git fetch + git merge
很多人在团队里还沿用单人模式下的 git pull，以为只是“拉最新代码”的快捷方式。但它默认执行的是 git fetch 后立刻 git merge，一旦远程有你本地没有的提交，就会自动产生一个合并提交（merge commit），而这个提交往往和你的开发意图无关，还会污染历史线。
- 真实场景：你正在
feature/login分支开发，同事刚把feature/api-refactor合并进main，你执行git pull origin main，结果本地main上多了一个“Merge branch 'main' of …”提交 - 更糟的是：如果本地有未提交变更，
git pull可能直接报错或触发冲突，而git fetch是只下载不改动工作区的“安全探针” - 建议动作：日常同步主干前，先
git fetch origin main，再git rebase origin/main（保持线性历史）或git merge origin/main（显式控制合并点）
git push 失败时，别急着 --force
单人项目里 git push --force 很常见，但在团队中这是高危操作——它会重写公共分支的历史，导致其他成员的本地分支与远程失同步，后续 pull 会出一堆“non-fast-forward”错误，甚至丢失他人提交。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 典型诱因：你做了
git rebase或git reset --hard后直接git push，远程拒绝，然后下意识加--force - 正确解法：先
git fetch origin拉取最新远程状态，对比git log --oneline HEAD...origin/your-branch看差异；如有他人新提交，应git rebase origin/your-branch或git merge origin/your-branch整合后再推 - 团队可配置
receive.denyNonFastForwards true（服务端）+push.default simple（客户端），从机制上拦住非快进推送
本地分支名和远程分支名不是一回事
新人常以为 git checkout -b feat/user 推上去就是远程的 feat/user，其实默认推送到 origin/HEAD 对应的上游分支（通常是 origin/main），除非显式指定。
- 后果：你本地叫
feat/user，但git push后远程可能只有main分支更新，而你的功能分支根本没上去 - 安全写法：
git push -u origin feat/user（-u建立追踪关系），之后git push和git pull才能自动关联 - 验证是否成功：运行
git branch -vv，看本地分支后面是否显示[origin/feat/user]；若显示[origin/HEAD]，说明追踪错了
切换到团队协作，真正难的不是命令记不住，而是要把“我改完就推”的确定性思维，换成“我改完得先看清别人在哪、改了啥、怎么接才不打断别人”。很多冲突和混乱，源头都卡在这一步观察动作没做实。
