Git 分支与提交 · C++ 互动课

◎学完你会

git branch feat 建分支 → 改代码 → git commit → 切回主分支 git merge feat 合并。

git branch feature

git checkout feature

看一次分支开发与合并。

✅ 提交信息用约定式：feat:新功能、fix:修 bug、refactor:重构——历史可读、能自动生成 changelog。

冲突：两人改了同一处，merge 时 Git 无法自动合并，需手工改 <<<<<<< 标记区域后 commit。

提交规范：提交要小而聚焦（一次提交一件事），信息写清"为什么"；分支命名用类型+主题（feat/login）。

git checkout -b fix/login-bug // 建并切到修复分支 // …改代码… git add login.cpp git commit -m "fix: 修复登录时密码为空仍能提交" git checkout main git merge fix/login-bug

要点：冲突不可怕，可怕的是大提交（难 review/回滚）和乱信息。遵循"一功能一分支、一小提交、信息清楚"，协作就顺畅。

① 忘了 add 就 commit——新文件/改动没进暂存区，提交不包含。

② 在主分支直接改功能——应开分支隔离，避免互相污染。

③ 提交信息含糊——"update"看不出干了啥，规范提交更好。

④ 遇到冲突乱删标记——要先看懂两边改动再手工合并。

分支像工厂开多条平行生产线：一条产老款（main），一条产新款（feature），各改各的不互相干扰；新品验证好了再合并（merge）回主产线。冲突像"两条线抢用同一台设备（改了同一处代码）"，需要人工协调。

commit 像档案室按时间归档版本：每个 commit 是带标签的存档（信息+编号），随时能 log 翻历史、回滚。规范的提交信息 = 档案标签写清楚"这版改了啥"，多年后还能看懂。

把改动保存成 Git 版本，正确顺序是？

先 git add 把改动放入暂存区，再 git commit -m 保存版本。

多个功能并行开发、互不干扰，应使用？

分支隔离并行开发：一功能一分支，完成后 merge，避免互相污染。

Git merge 提示冲突时，正确的处理是？

冲突需手工理解并合并冲突标记内的两处改动，再 add + commit 完成合并。