merge前必须确认当前在目标分支上，Git只作用于HEAD所在分支；误在feature/login执行git merge main会反向合并；应先git branch确认*标记，再git switch main；建议用--no-ff保留合并意图；冲突时需手动解决并git add标记；merge后须git push origin main确保正确推送。
merge 前必须确认当前在目标分支上
Git 不会自动把变更合并到你“以为”的分支，它只作用于当前 HEAD 所在分支。比如你想把 feature/login 合并进 main，却误操作时还在 feature/login 分支上执行 git merge main，结果是把 main 的提交拉进功能分支——这通常不是你想要的同步方向。
实操建议：
- 先用
git branch确认星号（*）标记的是目标分支（如main） - 不确定时，显式切换：
git checkout main或git switch main - 别依赖记忆，每次 merge 前都查一次
git status，看提示里的当前分支名
fast-forward 合并 vs. 三方合并（--no-ff）
当目标分支自上次分叉后没新增提交，Git 默认做 fast-forward：只是移动 main 的指针，不产生新 commit。这种同步干净，但会丢失“这次合并是有明确意图的”这一信息。
如果你希望保留合并动作的可追溯性（比如上线前合入测试分支），强制创建合并 commit：
git摸鱼周报自动化
下载
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
git merge --no-ff feature/login- 编辑默认合并信息时，建议写明目的，例如：
merge feature/login for QA testing - CI/CD 流水线或 code review 工具常依赖合并 commit 判断集成点，
--no-ff能让这些流程更可靠
遇到冲突时，不要直接 git merge --abort 就跑
冲突不是失败，是 Git 在说：“这两处修改我没法自动选一个，得你来定”。常见错误是看到红色提示就慌着中止，结果重做一遍还是撞上同样冲突。
正确做法：
- 用
git status查看哪些文件冲突（标为Unmerged paths） - 打开冲突文件，找到
<<<<<< HEAD和>>>>>> feature/login之间的区块，手动删掉不需要的版本，保留最终内容 - 改完后
git add <file>标记已解决，再git commit完成合并 - 如果真想放弃，
git merge --abort是安全的，但它不会撤销你已add的文件，记得git reset清理残留状态
merge 后记得推送到远程，且注意推送目标
本地 merge 完成只是第一步。如果忘了 git push，别人从远程拉不到你的合并结果；更隐蔽的问题是：你可能在 main 上 merge 完，却执行了 git push origin feature/login —— 这会把合并后的 main 提交错误地推到功能分支远端。
安全习惯：
- merge 后立刻执行
git push origin main（显式指定远程分支） - 配置
push.default为upstream或current可减少误推，但别依赖配置代替明确命令 - 团队协作中，建议 merge 后立刻在 CI 页面确认构建是否通过，避免“以为推了其实没推”导致后续集成断裂
