不能直接在main或develop上写代码，因二者是团队协作主干道，main代表线上代码、develop是集成基线，未经审查提交易导致流水线故障；需通过feature/hotfix分支规范开发与修复流程。
为什么不能直接在 main 或 develop 上写代码
因为这两个分支是团队协作的“交通主干道”，不是你的个人工作台。main 代表线上正在跑的代码，develop 是下一个版本的集成基线——任何未经审查、未测试的提交，都可能让整条流水线卡住甚至崩掉。git push origin main 这种操作在有分支保护的仓库里根本通不过，但更危险的是：有人绕过保护、本地误操作、或用 git push --force 强推，直接污染历史。
feature 分支必须从 develop 拉取，且命名要带上下文
不是随便 git checkout -b my-feature 就完事。正确做法是先同步最新状态：git checkout develop && git pull origin develop，再创建分支：git checkout -b feature/user-login-2026q3。这样做的关键原因有三个：
- 避免基于过时的 develop 合并，导致大量“幽灵冲突”（即冲突内容其实早已被别人解决过）
- 分支名含业务语义（如
user-login）和时间/迭代标识（如2026q3），方便 CI/CD 自动识别打包环境、PR 描述自动归类、GitLab/GitHub 过滤统计 - 如果项目用了模块化开发（比如 Java 的 user-service 和 order-service），建议加前缀：
feature/user-service-password-reset，避免多人同时起名feature/reset造成混淆
合并前必须 rebase develop，而不是 merge develop
很多人习惯在 feature 分支里执行 git merge develop 来同步更新，结果会把 develop 的一堆提交“拖进”自己的分支历史，让 PR diff 失真、CI 日志膨胀、回滚定位困难。正确姿势是：git rebase develop（确保当前在 feature 分支），它把你的 commit “重放”到最新 develop 顶端，保持线性历史。
但要注意两个坑：
- rebase 后如果已推送过远程分支，必须用
git push --force-with-lease origin feature/user-login-2026q3，不能用--force，否则可能覆盖别人刚 push 的提交 - 如果 feature 分支已有多个 collaborator 共同提交，不要 rebase —— 此时应改用
git merge --no-ff并写清楚 merge message，避免打乱他人本地历史
hotfix 分支必须从 main 切出，并反向同步到 develop
线上炸了，你得修，但不能跳过流程。第一步永远是：git checkout main && git pull origin main，然后创建 hotfix：git checkout -b hotfix/login-token-expiry-20260723。修复提交后，按顺序合并：
-
git checkout main && git merge --no-ff hotfix/login-token-expiry-20260723→ 确保线上立刻可用 -
git checkout develop && git merge --no-ff hotfix/login-token-expiry-20260723→ 防止下次发版漏掉这个修复 - 最后打 tag：
git tag -a v2.4.1 -m "fix: login token expiry bug"，并git push origin v2.4.1
漏掉第二步，等于埋了个雷：下个 release 分支从 develop 切出时，这个 hotfix 就不会包含进去，等上线才发现问题复现。
