必须先检出目标分支，goland 不支持在功能分支上直接合并 main；正确流程是先切换到 main，再将功能分支合并进去，否则菜单不可用或报错。
合并分支前必须检出目标分支
GoLand 不允许直接在功能分支上“把 main 合并进来”，你得先切换到 main（或你要合并进去的那个分支），再执行合并操作。否则菜单里根本不会出现「将 feature-x 合并到当前分支」选项，也看不到 Git | 合并 菜单项。
常见错误是：人在 feature/login 分支上，右键点 main → 选「将 main 合并到 feature/login」——这个操作在 GoLand 里压根不支持，IDE 会静默忽略或报错 Cannot merge into current branch。
- 正确流程：先在分支窗口（
Git | 分支或快捷键Ctrl+Shift+G）中找到main，右键 →「检出」 - 确认底部状态栏显示分支名已变成
main，再右键点你的功能分支（如feature/login）→「将 feature/login 合并到 main」 - 或者用主菜单：
Git | 合并→ 在弹出对话框里选目标分支
合并时选错选项会导致历史污染或丢失提交信息
--no-ff 和 --squash 看似都是“强制生成新提交”，但语义完全不同：前者保留全部原始提交链（只是加一个 merge commit），后者把所有改动压成一个新 commit，原始提交哈希和作者信息全丢。
团队协作中误用 --squash 是高频事故——比如 PR 已被多人 review 过，commit message 里带 issue 编号、测试说明，一 squash 全没了，后续追溯困难。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 默认推荐用
--no-ff（GoLand 合并对话框里勾选「始终创建合并提交」） - 仅当你明确要清理历史（例如临时调试分支、本地小修小补）才用
--squash -
--ff-only适合 CI 流水线自动合并，但手动操作时容易失败（只要main有新提交就报错），不建议日常点按使用
冲突发生时别急着点「Accept Yours」
GoLand 把冲突块标红后，右键菜单里的「Accept Yours」/「Accept Theirs」是全局操作——它会整块替换，不管里面有没有你刚写的逻辑、有没有对方改的边界条件。尤其当冲突在函数内部、if 分支里，盲目接受极易引入 bug。
真实场景中，90% 的冲突不是“谁对谁错”，而是“两边都改了同一段逻辑，需要人工融合”。这时候得手动编辑中间的冲突标记区域： 和 <pre class="brush:php;toolbar:false;"> 之间的内容。</pre>
- 打开「提交工具窗口」（
Alt+0），冲突文件会出现在「合并冲突」节点下 - 双击打开冲突文件，光标会自动跳到第一个冲突处
- 删掉三行分隔符，保留需要的代码，补上缺失的变量或 return，再手动删掉冗余空行
- 改完后右键冲突块 →「标记为已解决」，别忘了
git add该文件（GoLand 通常会自动做，但网络卡顿或大文件时可能漏）
合并后记得检查日志和暂存区
合并成功不等于代码可用。GoLand 日志窗口（Alt+9）里能看到新生成的 merge commit，但如果你之前本地有未提交的修改，或者用了 --no-commit 选项，这个 commit 可能根本没产生——而 IDE 界面又没明显提示。
另一个坑是：合并后 main 分支确实更新了，但你顺手改了几行测试代码没 git add，结果 push 时只推了 merge commit，漏掉了那几行关键修复。
- 合并完立刻看「版本控制」工具窗口（
Alt+9）顶部标签页是否显示「Log」，确认最新提交是你刚做的 merge - 切到「Local Changes」标签页，检查有没有意外出现在「Other Changes」里的未跟踪文件，或「Unversioned Files」里混进来的临时日志
- 如果用了
--no-commit，务必手动git commit，否则git status会显示「all conflicts fixed but you are still merging」
