结论：禁止在main等公共分支直接开发，必须通过feature分支+pull request流程。因公共分支是团队基准线，直接提交会破坏他人同步基础，引发非预期merge、历史混乱或线上回退，且强制推送会覆盖他人提交。
直接说结论：不要在公共分支（如 main、dev）上直接开发或提交，这是冲突频发的根源。所有修改必须走独立功能分支 + Pull Request 流程，否则早晚遇到 ! [rejected] main -> main (fetch first) 或更糟的“合并后版本回退”。
为什么不能在 main 分支上改代码？
公共分支是团队共识的“基准线”，不是临时草稿纸。一旦有人直接在 main 上 commit 并 push，就会立刻破坏其他人的本地同步基础——别人 git pull 时可能触发 merge，生成非预期的 merge commit；更危险的是，若本地有未提交修改，git pull 可能自动 merge 进错误逻辑，导致上线后行为异常。
常见错误现象包括：
-
git push origin main被拒绝，提示! [rejected] main -> main (non-fast-forward) - 强行
git push --force后，同事git pull出现大量重复提交或丢失历史 - 某次
git merge后，线上功能倒退回旧版本（因 merge 时误选了--ours或冲突解决不彻底）
git pull 和 git fetch + git rebase 的实际差异
很多团队要求“每天上班先 git pull”，但这恰恰埋下隐患：git pull 默认执行 git merge，只要远程有新提交，就会产生一条 merge 记录。长期下来，main 历史变成毛线团，排查问题极难。
推荐做法是用 git fetch + git rebase 替代：
-
git fetch origin main：只拉取远程main的最新 commit ID，不改动本地任何内容 -
git rebase origin/main（在你的 feature 分支上执行）：把你本地的提交“重放”到远程main最新基础上，保持线性历史 - 如果 rebase 过程中出现冲突，必须手动解决后
git add+git rebase --continue，不能跳过
注意：git rebase 会改写提交哈希，所以仅限尚未 push 的本地分支使用；已推送到远程的 feature 分支，需确认队友没基于它继续开发，再决定是否 force push。
功能分支命名与生命周期管理
分支名不是随便起的，它直接影响协作效率和自动化识别（比如 CI/CD 触发、权限控制）。规范如下：
- 前缀明确用途：
feature/xxx、fix/xxx、hotfix/xxx，避免用dev-123或mywork这类模糊名称 - 名称含简要语义：
feature/user-login-token-refresh比feature/login更易定位 - 合并进
main后，必须立即删除远程分支：git push origin --delete feature/xxx；本地分支也建议清理，防止误操作 - 长期存活的分支（如
release/v2.3）需专人维护，禁止多人直接 push
一个容易被忽略的细节：GitHub/Gitee 的 PR 设置里，勾选 “Delete head branch when merged” 可自动清理，但前提是团队成员不依赖该分支做后续开发——否则删掉后，别人 git checkout 会失败。
冲突发生时，谁该负责解决？
原则就一条：最后执行 git push 失败的人，负责解决冲突。不是“谁改的文件多”或“谁资历老”，而是“谁的操作触发了服务器拒绝”。
实操要点：
- 看到
! [rejected]提示，第一反应不是git pull，而是git fetch origin main查看远程最新状态 - 若你正在 feature 分支上，运行
git rebase origin/main；若已在main上（违规操作），先git stash保存修改，再git reset --hard origin/main回滚，最后git stash pop - 冲突文件里出现
标记时，别靠猜——打开 Git GUI 或 VS Code 的合并编辑器，对比两侧变更意图，必要时直接找另一方当面确认 - 解决完必须跑通本地测试，再
git add+git rebase --continue（rebase 场景）或git commit（merge 场景）
真正麻烦的从来不是冲突本身，而是团队里有人把 git push --force 当成万能解药——它能解决推送失败，但会覆盖别人刚 push 的提交，且无法追溯。这种操作在公共分支上等同于删库跑路。
