git多人协作依赖本地仓库、远程仓库与明确分支契约联动，缺乏统一分支规则和推送/拉取节奏会导致冲突或覆盖；直接push到main易因非快进被拒，应先pull整合；推荐fetch+merge或pull--rebase；feature分支需语义化命名并及时清理。
Git多人协作不是靠“同步文件”实现的，而是靠「本地仓库 + 远程仓库 + 明确分支契约」三者联动完成的。没有统一的分支规则和推送/拉取节奏，git push 和 git pull 就会变成互相覆盖或频繁冲突的源头。
为什么直接 git push origin main 容易出问题
多人同时向同一分支（比如 main）推送时，Git 会拒绝非快进（non-fast-forward）更新——也就是你本地的 main 已经落后于远程，却还想用旧提交覆盖远程新提交。这不是 Git 故意为难，而是它在强制你先整合远端变更。
- 典型报错：
! [rejected] main -> main (non-fast-forward) - 根本原因：你的本地
main分支没包含别人刚push上去的提交 - 错误做法：强行
git push --force—— 会抹掉他人提交，破坏协作可信度 - 正确做法：先
git pull origin main拉取并合并，再推
git pull 和 git fetch + git merge 的区别在哪
git pull 是 git fetch 加 git merge 的组合命令，但默认行为容易掩盖关键细节：它会自动触发 merge，而 merge 提交可能污染历史，尤其当多人频繁提交时。
alfred-github-backup
下载
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
-
git fetch origin只下载远程引用（如origin/main），不改动你本地任何分支 -
git merge origin/main才真正把远端变更合入当前分支；此时若存在分歧，Git 会提示 conflict 并暂停，等你手动解决 - 推荐显式拆开用：先
git fetch看清远程状态（比如用git log --oneline --graph origin/main ^main查差多少提交），再决定是merge还是rebase - 注意：
git pull --rebase会把你的本地提交“重放”到远程最新基础上，避免无意义的 merge 提交，但要求你没把本地分支推过远程（否则会制造重复提交）
feature 分支怎么起名才不容易撞车又便于追踪
分支名不是随便打几个字的事，它是团队协作的“路标”。名字含糊（如 fix、new）会导致 git branch -a 列出一堆无法分辨的分支，也增加 PR 审查成本。
- 必须带语义前缀：
feature/、fix/、chore/、docs/—— 让人一眼知道用途 - 关联任务编号（如有）：
feature/JIRA-123-login-ui或fix/GH-45-null-pointer - 避免空格和大写；用短横线分隔单词，不用下划线（部分 CI 工具对下划线敏感）
- 创建后立即推送到远程：
git push -u origin feature/login-ui，让队友能基于它协作或 review - 切记：不要长期保留已合并的 feature 分支——它会持续漂浮在
git branch -a输出里，干扰判断
PR 合并后，本地 feature 分支要不要删
要删，而且建议立刻删。不删的后果不是报错，而是认知污染：你下次 git checkout feature/login-ui，发现代码还是老的，但远程分支早已被删除，甚至同名新分支可能是别人建的。
- 合并 PR 成功后，远程
feature/login-ui通常已被平台自动删除（取决于仓库设置） - 执行
git branch -d feature/login-ui删除本地分支（-d是安全删除，拒绝未合并的分支） - 如果误删了还没合并的分支，可从 reflog 恢复：
git reflog找到 commit hash，再git checkout -b feature/xxx <hash></hash> - 更稳妥的做法：合并后顺手运行
git fetch --prune，清理所有已不存在的远程跟踪分支（如origin/feature/xxx）
真正卡住协作的，从来不是命令记不牢，而是分支生命周期没人管、feature 分支没人清理、冲突解决后不验证是否真跑得通。这些事不会报错，但会让团队越协作越慢。
