企业官网建设流程全解析

用 IDEA 写代码的人不少，但真正把 Git 这层用明白的不多。我见过太多同事，命令行敲得飞起，一切到图形界面就只会点那个绿色的 Commit 按钮，结果把.idea目录、target编译产物、本地调试配置一锅端推上去，被 reviewer 追着骂。反过来也有另一批人，命令行只记得住git status和git log，每次遇到冲突就头皮发麻，宁可把改过的文件复制出来、删掉本地仓库重新克隆。这两种状态本质上是同一个问题：没搞清楚 Git 的数据模型，也没搞清楚 IDEA 把 Git 的每个动作映射到了界面上的哪个角落。

IDEA 集成 Git 的价值，不是"把命令行搬到鼠标上"，而是把 diff 对比、blame 追溯、三方合并、历史拓扑这些原本要在多个终端窗口之间来回切换的事情，压缩进同一个工作区里。你在编辑器里改完一行代码，左边 gutter 会立刻变色；你点开一个文件的历史，能看到它从创建到现在的每一次变更；你合并分支遇到冲突，IDEA 会直接给你一个三栏的可视化编辑器，而不是让你在文件里找那一堆<<<<<<<标记。

这篇内容写给两类人：一类是刚装好 IDEA、第一次听说版本控制的新手，需要一条从零到能正常提交推送的完整路径；另一类是用了几年代码、但只把 IDEA 当编辑器用、Git 全靠命令行的开发者，需要把图形化这套流程补齐。我会按环境准备 → 概念映射 → 日常主流程 → 进阶操作 → 冲突排查 → 工具链整合的顺序走一遍，每一步都说清楚为什么这么做，以及坑在哪里。

1. 开工前的环境准备：Git 与 IDEA 怎么装、怎么绑

环境这一层看起来最简单，实际上后面 80% 的诡异问题都出在这里。我排过好几次"IDEA 里提交不了"的故障，最后发现是 Git 装的时候 PATH 没配、或者 IDEA 指向了一个残留的旧版本 git.exe。所以这一节别跳。

1.1 Git 安装：安装向导里那些选项到底该选什么

Windows 用户去官网下载 Standalone Installer，别下 Portable 版本。Portable 版虽然不用安装，但它不会写入注册表和 PATH，IDEA 在自动探测 Git 路径时会找不到，你得手动指路径，反而更麻烦。

安装向导里选项很多，我按经验给一份推荐值：

macOS 上更简单，xcode-select --install会装一份命令行工具自带的 Git，或者用 Homebrewbrew install git装更新的版本。Linux 用发行版包管理器即可。

装完必须做两件事。第一件是验证版本：

git --version

第二件是配置身份。Git 每次提交都会写入作者信息，没配的话提交会直接报错：

git config --global user.name "你的名字" git config --global user.email "你的邮箱@example.com" git config --global --list

注意：这里的邮箱最好和你托管平台账号绑定的邮箱一致，否则平台无法把你的提交关联到你的头像和贡献图上。

1.2 IDEA 装哪个版本，以及第一次打开该配什么

IDEA 分社区版和旗舰版两条线。社区版永久免费，支持 Java、Kotlin、Android、Maven、Gradle 和完整的 Git 集成；旗舰版多了 Spring 全家桶、数据库工具、JavaScript/TypeScript 深度支持、远程开发等功能。做纯后端 Java 或者刷题、练手，社区版完全够用。旗舰版有官方 30 天试用，在校学生可以通过官方教育渠道申请免费授权，企业用户走采购流程。不要从任何非官方渠道下载安装包或者使用来路不明的授权文件，这类包体被植入挖矿脚本、窃取环境变量的案例我见过不止一次，省下的那点钱远远不够赔。

首次打开 IDEA 的向导里有几个设置值得花两分钟：

• UI 主题选 Darcula 或者新版浅色主题，看你眼睛习惯，别硬撑。
• 中文界面：Settings → Plugins → Marketplace搜索 Chinese，装官方语言包插件，重启后生效。语言包只影响菜单文字，不影响功能。
• 内存：Help → Change Memory Settings，默认 2048MB，跑大型多模块项目建议调到 4096MB 或更高。内存不足是 IDEA 卡顿、索引失败、甚至自动退出的头号原因，热搜里那个"idea自动关闭"的问题，九成是堆内存不够。
• 编码：Settings → Editor → File Encodings，三处都设成 UTF-8，勾选Transparent native-to-ASCII conversion之外的默认项。项目里如果有 GBK 编码的老文件，单独针对该文件改，别全局改。

1.3 让 IDEA 找到 Git：路径绑定与三个经典坑

打开Settings → Version Control → Git，看Path to Git executable这一栏。正常情况下 IDEA 会自动填好，点右边的Test按钮，弹出 Git 版本号就说明通了。

如果这里显示红色、Test 报错，通常是下面三个原因：

还有一个隐蔽的坑：机器上装过多个 Git（比如系统一份、某 IDE 自带一份、某工具又带一份），IDEA 探测到的是旧版本。判断方法是看Test弹窗里的版本号跟你命令行git --version是否一致。不一致就手动把路径改到命令行那一份。

2. 四个区的概念：为什么必须先搞懂再动手

很多人用 IDEA 的 Git 出问题，根因不是不会点按钮，而是脑子里没有"四个区"的模型。这一节我用类比讲清楚，然后再告诉你这四个区在 IDEA 界面上分别对应什么。

2.1 工作区、暂存区、本地仓库、远程仓库

把 Git 想成一个寄快递的流程：

工作区是你的书桌，你在上面改代码，改成什么样它都不管你，随你怎么乱。暂存区是那个待寄的纸箱，你从桌上挑出这次要寄的东西放进去，挑的过程就是add。本地仓库是你家里的档案柜，箱子封好（commit）之后存进去，从此有了编号和时间戳，可以随时翻出来对比。远程仓库是公司的共享资料室，你把档案柜里的某一箱搬过去（push），同事也能搬他们的箱子过来（fetch）。

这套模型解释了三个新手最容易困惑的问题。第一，为什么改了代码还要"确认一次"才能提交？因为工作区和暂存区是两回事，不挑就直接提交等于把桌上所有东西一股脑装箱。第二，为什么提交之后本地有记录、同事却看不到？因为只到了本地仓库，没推远程。第三，为什么"撤回"这么复杂？因为你站在哪个区往回退，动作完全不一样，这个我在第 4 节展开。

2.2 IDEA 界面里，这些区都在哪

IDEA 没有把"暂存区"这个概念做成一个独立面板，而是用**变更列表（Changelist）**近似替代。理解这个差异很关键。

打开Commit工具窗口（默认快捷键Ctrl+K，Mac 是Cmd+K），你看到的是一个文件列表，每个文件前面有个复选框。复选框选中 = 进暂存区，取消选中 = 从暂存区拿出来。IDEA 在执行提交时，只会把你勾选的文件纳入这次 commit。

再往深一层，IDEA 支持多个变更列表。在 Commit 窗口左下角能看到一个+号，可以新建一个 Changelist，比如叫"紧急修复"和"重构实验"，把不相关的改动分到不同列表里。这样你在审查时不会把实验性代码误提交，切换任务时也能整体搁置。这个功能命令行用户几乎没有对应概念，是图形化 IDE 的独有优势。

其余界面元素对照如下：

2.3 全局配置：几条一定要改的项

IDEA 内部调用 Git 时会带上一些隐藏参数，这也是为什么你在 IDEA 的 Console 里会看到那种特别长的命令：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status

拆开看：-c是临时覆盖单项配置，只在本次命令生效；diff.mnemonicprefix=false让 diff 输出用标准的a/b/前缀，方便 IDE 解析和展示；core.quotepath=false让含中文的文件名按原样输出，而不是变成\346\226\207这样的八进制转义；--no-optional-locks是告诉 Git 不要写那些可选的状态锁文件，避免和 IDE 的文件监听机制打架。你如果在命令行里遇到中文文件名乱码，加core.quotepath false就是这个原因。

除了 IDEA 自带的这两个，我建议把下面几条写进全局配置：

git config --global core.quotepath false git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8 git config --global init.defaultBranch main git config --global pull.rebase false git config --global core.filemode false

三条编码相关的不用多说，解决中文乱码。init.defaultBranch main让新仓库默认分支名跟托管平台一致。pull.rebase false把默认拉取策略定为 merge，简单且不易出错，后面第 3.3 节会详细讲两种策略的取舍。core.filemode false只对 Windows 有意义 —— Windows 文件系统不区分可执行位，Git 有时会把权限变化误判成内容修改，导致一堆文件莫名显示成已改动，关掉这个检测就干净了。

3. 日常开发主流程：从克隆仓库到推送代码

概念讲完了，这一节进入真正的操作。我按一个新人入职后第一天的顺序来：先克隆项目，改代码，提交，推上去。

3.1 克隆项目：三个入口，用哪个都行

IDEA 提供了三个克隆入口，功能一样，看你手头状态：

• 启动欢迎页：Get from VCS，适合还没打开任何项目的时候。
• 菜单栏：File → New → Project from Version Control。
• 已有项目里：Git → Clone，适合你已经开着一个项目、想再拉一个仓库进来。

URL 填 HTTPS 或 SSH 都行。HTTPS 需要账号密码（Git Credential Manager 会帮你记住），SSH 需要提前配好密钥，第 6.2 节会讲。

Directory这一栏是新手踩坑重灾区：路径里不要出现中文、空格和特殊字符。Git 本身能处理，但 Maven、Gradle、某些构建脚本对这类路径的兼容性参差不齐，会报出各种莫名其妙的 "Cannot find module" 错误。

克隆完成后，IDEA 会问你是否打开。打开之后如果项目结构没被识别（比如左边项目树里只有几个散文件），去Maven或Gradle面板点一下Reload，让它重新导入即可。多模块项目在File → Project Structure → Modules里检查一下模块有没有全部加上。

3.2 改代码、暂存、提交：把一次提交做干净

改完几个文件之后，编辑器左侧 gutter 会出现颜色条：绿色是新加的行，蓝色是修改过的行，灰色三角表示这块区域被折叠。这是 IDEA 的变更标记，鼠标悬停能看到本地版本和当前版本的对比。

按Ctrl+K打开 Commit 窗口，你会看到所有改动文件列在那里。这里有一个关键动作：逐个看一遍每个文件的 diff。左侧点开文件，右边会自动联动显示出差异。我个人的习惯是Ctrl+Alt+Shift+↑/↓在文件之间快速跳，每个都扫一眼再决定勾不勾。

心得：全选提交是最容易出事的操作。只要你本地跑过一次程序，target、build、.log、.iml这类文件就可能冒出来。养成扫 diff 的习惯，能省掉后面无数次git rm --cached。

提交信息（Commit Message）别写 "update"、"fix bug" 这种。推荐用约定式提交格式：

feat(user): 新增手机号登录入口 fix(order): 修复订单金额为负数时计算异常 docs(readme): 补充本地启动步骤 refactor(utils): 抽离重复的日期格式化方法

格式是类型(模块): 描述。类型常见的有 feat（新功能）、fix（修复）、docs（文档）、refactor（重构）、test（测试）、chore（杂项）。好处是后面用工具生成变更日志时能自动分类，Code Review 时别人一眼知道这次改动的性质。

Commit 窗口右下角有两个按钮：Commit和Commit and Push。前者只进本地仓库，后者提交完直接推远程。单人在特性分支上工作时用后者更省事，主干分支上建议分开做，给自己留一个检查的机会。

3.3 Pull 与 Push：两种拉取策略怎么选

推送前先拉取，这是基本纪律。快捷键Ctrl+T打开Update Project对话框，里面有两条路线：

Merge（合并）：把远程的新提交合并到你本地。如果双方都有新提交，会产生一个 merge commit，历史图上出现一个分叉再汇合的节点。优点是安全、不改写任何已有提交；缺点是历史会有分叉，看起来不那么干净。

Rebase（变基）：把你本地还没推送的提交"摘下来"，等远程最新提交拉下来之后再"重新贴上去"。历史图是一条直线，非常整洁。代价是你本地那些提交的哈希值会全部改变，如果这些提交已经推给别人的分支共享了，会造成混乱。

我的选择标准很明确：只在自己独占的特性分支上，且提交还没推过，就用 Rebase；其他所有情况用 Merge。反过来只要记住一条：已经推送到共享分支的提交，永远不要 rebase。

对话框里还有一个Clean working tree选项，作用是在更新前先把你的未提交改动临时存起来（用 stash 或 shelve），更新完再恢复。这个功能在临时被叫去修 bug 时极其好用。

推送是Ctrl+Shift+K。被拒绝最常见的原因是远程有你没有的提交，IDEA 会弹窗提示Push Rejected，直接点Merge或Rebase再推就行。

3.4 分支：新建、切换、合并、删除

右下角状态栏显示当前分支名，点开就是一个完整的分支菜单。

新建分支：选New Branch，输入名字，勾选Checkout branch会新建后立刻切过去。分支命名我推荐类型/简短描述的格式，比如feature/phone-login、fix/order-amount、hotfix/20250301。前缀让人一眼看出分支用途，很多平台的 CI 也能根据前缀触发不同的流水线。

切换分支：在菜单里选目标分支 →Checkout。如果当前有未提交改动，IDEA 会问你带着走还是搁置。带着走（Smart Checkout）在大多数情况下没问题，但如果两个分支的同一个文件差异很大，会直接冲突，这时候选 stash 更稳。

合并分支：先切到目标分支（比如develop），然后在分支菜单里选源分支（比如feature/phone-login）→Merge into Current。合并成功会生成一条合并记录，失败则进入冲突解决流程，见第 5 节。

删除分支：分为删本地和删远程。本地删除在菜单里选Delete，IDEA 会检查该分支是否有未合并的提交，如果有会提示你确认 —— 这个提示一定要认真看，未合并就删等于丢掉那些提交（虽然还能通过 reflog 找回，但很麻烦）。远程删除选Remote Branches下的分支 →Delete。

为方便查阅，把常用操作和快捷键、对应命令列一下：

4. 进阶操作：撤销、改写与搬运

日常流程走顺之后，真正的功力体现在"出事了怎么办"。这一节是我觉得最值得花时间掌握的部分。

4.1 撤销分四个层级，用错工具等于自找麻烦

新手最常犯的错是：明明只想撤销一个文件的小改动，结果用了Reset Hard把一整天的工作全清了。记住这个层级表：

关于第三层再细说。Undo Commit的效果等同于git reset --soft HEAD~1：把提交撤掉，改动原封不动回到工作区，你重新整理后再提交。而 Log 里右键还有一项Reset Current Branch to Here，展开有三个档位：

• Soft：撤提交，改动保留在暂存区，等价于--soft。
• Mixed：撤提交，改动保留在工作区但不暂存，等价于--mixed，这是默认档。
• Hard：撤提交，改动直接丢弃，等价于--hard。这一项要慎用，IDEA 会弹二次确认，别手快。

注意：Hard执行后，未提交的改动没有任何地方能找回，未推送的提交还能通过git reflog捞出，但工作区里那些没提交过的代码是真的没了。

4.2 amend 与交互式 rebase：把历史整理干净

Amend用来修补最近一次提交。场景很常见：你刚提交完，发现漏了一个文件，或者 commit message 打错了一个字。在 Log 里右键最近那条提交 →Edit Commit Message，改完确认；或者在 Commit 窗口勾选右上角的Amend，把漏掉的文件补进去。

Amend 的本质是生成一个新的提交替换掉旧的，提交哈希会变。所以铁律是：已经推送到共享分支的提交，绝不 amend。你 amend 之后只能强推，强推会让同事的本地历史和远程对不上，他们下次 pull 会撞上一堆莫名其妙的冲突。

交互式 rebase是整理本地提交历史的利器。Log 里选中某个提交 →Interactively Rebase from Here，IDEA 会弹出一个列表，每个提交前面可以选动作：

• pick：保留原样
• reword：保留改动，改 message
• squash：把这条合并进上一条，两条 message 都保留，让你编辑合并后的内容
• fixup：合并进上一条，丢弃这条的 message
• drop：删除这条提交

我常用的场景是：本地写了一堆 "wip"、"临时保存"、"再修一下" 的提交，推之前用 squash 和 fixup 把它们压成一两条语义清晰的提交，这样 reviewer 看历史时不会被噪音干扰。

4.3 Stash 和 Shelve：临时存盘的两种流派

正在写功能 A，领导突然让你去修一个紧急 bug，这时候需要把手头的改动临时存起来。

Stash Changes（Git → Uncommitted Changes → Stash Changes）是 Git 原生能力，会把当前工作区和暂存区的改动打包存进.git目录，工作区变干净。修完 bug 回来，Unstash Changes恢复。Stash 是跟着仓库走的，换台机器、换个克隆目录就没了。

Shelve Changes是 IDEA 自研的机制，存在项目的.idea/shelf目录里。区别在于：Shelve 的内容可以作为文件被提交、被共享、被同步，而且它会把变更列表的名称一起记录下来。它的适用场景更偏向"我想保留一个长期搁置的改动快照"，而 Stash 更适合"几分钟到几小时的临时切换"。

我个人习惯是：几小时内的切换用 Stash，超过一天的搁置用 Shelve，并且给 Shelve 起个描述性名字，否则过一个月你根本不知道那堆东西是什么。

4.4 Cherry-pick 与 Revert：精准搬运与安全回退

Cherry-pick是把别的分支上的某一个提交单独搬到你当前分支。典型场景：你在develop上随手修了一个线上 bug，现在需要把这个修复也同步到release分支。切到release，在 Log 里找到那条提交，右键 →Cherry-Pick。IDEA 会把这个提交的改动复制过来生成一条新提交。

Cherry-pick 的坑在于它只搬改动，不搬上下文。如果这个提交依赖前面几个提交铺垫的代码结构，单独搬过来很可能编译不过或者逻辑不对。用之前先确认这个提交是自包含的。

Revert是"安全回退"的标准答案。它不删除历史，而是生成一条反向提交，把指定提交的改动抵消掉。因为历史完整保留，所以用在共享分支上是安全的，不需要强推。操作是在 Log 里选中提交 →Revert Commit，IDEA 会自动生成反向改动并放进 Commit 窗口，你确认后提交即可。

选择上很好记：个人分支上想彻底抹掉历史用 Reset，共享分支上想撤销某个改动用 Revert。

5. 冲突处理与高频问题排查实录

冲突是绝大多数人卡住的地方。其实冲突本身不可怕，可怕的是不知道自己在合并什么。

5.1 三方合并视图怎么读

合并冲突时 IDEA 会自动弹出Merge Conflicts对话框，点Merge进入三方编辑器。三栏的结构是：

• 左栏：当前分支的版本（我称之为"我的"）
• 中栏：合并结果，也就是最终要保存成什么样
• 右栏：被合并分支的版本（"他们的"）

顶部有一排彩色条，每一段差异对应一个色块。点击色块上的箭头按钮可以把左侧或右侧的内容放进中栏，也可以两边都要（Accept Both）。中栏是完全可以手动编辑的，大部分复杂的冲突我都是直接在中间手动改 —— 按左侧的逻辑主体、融入右侧的新增判断，比机械地选边靠谱得多。

一个容易被忽略的点：冲突解决完之后，必须把文件标记为已解决。IDEA 里点Apply之后会自动做这一步，相当于git add。如果中途退出了合并，下次提交时这些文件还挂在Merge Conflicts节点下，得手动右键 →Mark as Resolved。

图片、PDF 这类二进制文件冲突时，IDEA 会给你两个版本让选一个，无法自动合并。这种情况通常要问清楚哪边是需要的，直接选一边覆盖。

5.2 高频报错速查表

下面这些是我和身边同事这些年反复遇到的报错，整理成表，遇到时对着查：

5.3 IDEA 特有的坑，以及怎么绕开

有几个问题只有 IDEA 用户会遇到，命令行用户根本碰不上，单独说一下。

File Cache Conflict 弹窗。IDEA 检测到某个文件在磁盘上被外部程序改过，同时你编辑器里也有未保存的改动，会弹窗问你要不要 Load File System Changes 还是 Keep Memory Changes。这时候如果选错，可能丢掉编辑器里的内容。习惯是按Ctrl+S手动保存，或者开启自动保存（Settings → Appearance & Behavior → System Settings → Save files automatically），能大幅减少这类弹窗。

索引与 Git 状态不同步。有时候你明明已经在命令行改过文件，IDEA 左侧还是显示旧的变更标记。这是 IDEA 的文件监听没捕获到。手动刷新：File → Reload All from Disk，或者点 Git 工具窗口左上角的刷新按钮。

.idea目录被提交。IDEA 的项目配置存在.idea目录里，有些内容（比如代码风格、运行配置）团队共享是好事，但workspace.xml、.idea/shelf、usage.statistics.xml这些是纯粹的个人状态，绝对不该提交。做法是在.gitignore里排除，第 6.1 节给模板。

长路径导致检出失败。Windows 有 260 字符路径限制，深层目录的项目克隆时会报 "Filename too long"。解决办法是开启长路径支持：

git config --global core.longpaths true

6. 工具链整合：把 Git 在 IDEA 里用得更顺

前面讲的是"能用"，这一节讲"好用"。这些配置和插件一次搞好，之后每天都能省时间。

6.1 .gitignore 的正确写法和 IDEA 的忽略入口

.gitignore的规则不复杂，但有个坑必须提前说：如果一个文件已经被提交进了仓库，后来才把它加进.gitignore，是不会生效的。因为 Git 只对未跟踪的文件应用忽略规则。正确做法是先让 Git 停止跟踪：

git rm --cached 文件名 git commit -m "chore: 停止跟踪本地配置文件"

一份 Java / Maven / IDEA 项目通用的模板长这样：

# 构建产物 target/ build/ out/ *.class *.jar *.war # IDEA .idea/workspace.xml .idea/usage.statistics.xml .idea/shelf/ .idea/dictionaries/ *.iml *.ipr *.iws # 日志与临时文件 *.log logs/ *.tmp *.bak # 系统文件 .DS_Store Thumbs.db desktop.ini # 本地配置 application-local.yml *.local.properties .env

团队共享的部分（比如 codeStyles、inspectionProfiles）可以从.idea里挑出来单独提交，但前提是团队约定好，别一个人默默提交一堆配置进去。

IDEA 提供了快捷入口：在项目树里右键任何一个文件 →Git → Add to .gitignore，它会自动帮你写进当前目录或根目录的.gitignore。省得手敲路径。

6.2 SSH 密钥配置与平台绑定

HTTPS 每次要输密码（虽然有凭据管理器），SSH 配一次就一劳永逸。生成命令：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车，密钥默认生成在~/.ssh/下，id_ed25519是私钥（绝对不能外传），id_ed25519.pub是公钥。用文本编辑器打开公钥文件，全选复制，粘贴到代码托管平台的 SSH 公钥设置页面。

验证连通性：

ssh -T git@gitee.com

看到欢迎信息就通了。

IDEA 专属的坑：Settings → Version Control → Git → SSH executable这一项默认可能选的是Built-in。内置 SSH 客户端不读取~/.ssh/config里的自定义配置（比如多账号场景下给不同主机配不同密钥），会导致你明明配好了公钥却提示认证失败。有多账号需求时，把这一项改成Native，让它调用系统 SSH 客户端。

6.3 Log 视图与过滤语法：比命令行更好用的地方

Alt+9打开 Git 工具窗口，切到Log标签页。这是 IDEA 里我最喜欢的一块界面。它把所有分支的提交画成一张拓扑图，分叉、合并一目了然，每条提交左边还带着作者头像和分支标签。

它比命令行强的地方在于：直接点开某条提交，能看到完整的文件变更列表；再点某个文件，弹出左右对比视图；再点某一行，可以追溯这一行是哪个提交引入的。

搜索框支持一套过滤语法，非常实用：

排查线上问题时，我经常用file:加上文件路径，快速定位是哪个提交改动了那段逻辑。这个操作在命令行里要写git log --follow -- 路径，还得自己翻输出，效率差距明显。

6.4 值得装的几个 Git 相关插件

插件都从Settings → Plugins → Marketplace里装，只认官方市场，别装来路不明的 jar 包。下面几个是我用下来觉得确实提升效率的：

GitToolBox。它做两件很有用的事：一是在编辑器的每一行右侧显示这行代码最后一次是谁改的、什么时候改的（类似加强版 blame，但不用切窗口）；二是在状态栏显示本地分支落后远程多少个提交，一眼就能看出该不该 pull。

Git Commit Template。帮你按照模板填提交信息，把类型、模块、描述这些字段做成了表单，还能配置哪些类型必填。适合团队统一规范。

.ignore。专门用来编辑各类忽略文件，支持语法高亮，还能按模板生成（比如选 Java 就自动填 Java 相关内容）。比手动敲.gitignore舒服。

Git Flow Integration。如果团队用的是 Git Flow 那套分支模型（master、develop、feature、release、hotfix），这个插件把创建和收尾流程做成了按钮，省去一堆约定动作。

装插件的时候注意一点：插件装多了会拖慢 IDEA 启动和索引速度。我一般控制在 10 个以内，装完观察几天，用不上的就卸掉。

一些我踩过坑之后的固定习惯

写到这里，把几个多年养成的习惯摊开说说，这些没什么技术含量，但确实帮我省了很多返工。

第一，提交前一定逐个文件看 diff。这个动作平均花 20 秒，但能挡住几乎所有误提交。我看过太多次"把测试用的硬编码密码推上去了"这种事故，都是因为全选提交。

第二，拉取和推送分开做。哪怕现在很多工具都提供"一键同步"，我还是坚持先Ctrl+T看看来了什么、有没有冲突，再Ctrl+Shift+K推。中间那一眼，往往就能发现别人改了你正在改的同一个方法。

第三，本地分支命名永远带前缀。feature/、fix/、hotfix/这三个前缀覆盖了 95% 的场景，配合平台的自动化规则还能自动打标签、自动分配 reviewer。

第四，每天下班前把本地提交推上去。哪怕是推到一个临时的个人分支也行。代码只存在本地磁盘上的时候，一次硬盘故障、一次误操作Reset Hard，就可能白干一天。

第五，遇到不会的操作，先在测试仓库上试。新建一个空仓库，随便提交几次，把 Reset、Revert、Rebase、Cherry-pick 挨个跑一遍，看看历史图怎么变。花半小时把这几条命令的心理障碍跨过去，比在真实项目上试错便宜太多。

关于后续可以扩展的方向，一个是把 IDEA 的 Git 集成和 CI 流程串起来，比如用提交信息里的关键字自动触发流水线、或者提交时自动跑一遍代码格式检查；另一个是多人协作时的分支策略设计，什么时候该用特性分支、什么时候该用主干开发，这跟团队规模和发布节奏强相关，值得单独展开聊。