企业官网建设流程全解析

在 IntelliJ IDEA 里用 Git，真正省心的地方不是少敲几条命令，而是把版本控制变成了可视化动作：改完代码在 Commit 窗口里勾选文件，冲突时用三窗格合并，切分支像点书签一样快。很多人第一次接触 IDEA、Git 时，会误以为必须先把 Git 命令背熟，其实日常开发里八成操作都能在 IDE 内完成，剩下两成交给终端补充即可。这份详细教学面向刚装好 IDEA 和 Git 的新手，也适合长期用命令行但想把日常操作搬到 IDE 的老手。内容围绕 IDEA 中使用 Git 的完整链路展开，从安装后的可执行文件配置、SSH 密钥、第一次提交，到分支合并、冲突解决、amend、reset、reflog、团队协作规范和常见报错排查。使用官方渠道获取 IDEA 和 Git，社区版和正常订阅版本对 Git 的支持都很完整，后续升级与排查也会少很多麻烦。

1. 把 Git 塞进 IDEA 之前，先把基础环境理顺

1.1 Git 安装与版本选择：命令行和图形界面并不冲突

Windows 上最省事的做法是安装 Git for Windows，它会同时带来 Git Bash、Git GUI 和命令行工具。安装时有一个容易被忽略的选项：Adjust your PATH environment。建议选择 Git from the command line and also from 3rd-party software，这样 IDEA 的终端、PowerShell、CMD 都能直接调用 git 命令。另一个选项是换行符处理，默认 Checkout Windows-style, commit Unix-style line endings 适合大多数 Windows 单人项目，但跨平台团队更推荐后续用 .gitattributes 统一管理。安装路径尽量不要带中文和空格，比如放在 C:\Develop\Git 下，能避免一部分工具调用时出现奇怪错误。macOS 可以用 Homebrew 安装，或者直接下载官方安装包；Linux 用系统包管理器即可。装完先打开终端执行 git --version，能输出版本号就说明命令行层面没问题。我一般还会顺手执行 git config --global --list，看看有没有历史遗留配置，尤其是换行符和默认分支名。Git 2.28 之后可以用 init.defaultBranch 指定默认分支，避免每次新建仓库都叫 master，团队如果统一用 main，这一步越早设置越好。TortoiseGit 这类图形工具可以装，但不是必需，IDEA 自身的 Git 集成已经覆盖了大部分场景，装太多反而容易在文件状态刷新时互相干扰。

1.2 在 IDEA 里指定 Git 可执行文件：路径、测试与终端设置

装好 Git 后，打开 IDEA，进入 File > Settings > Version Control > Git，Windows 下通常会自动识别，如果没有，就手动选择 git.exe 的完整路径，例如 C:\Develop\Git\cmd\git.exe 或 C:\Develop\Git\bin\git.exe。这两个路径有区别：cmd 下的 git.exe 更偏向命令行调用，bin 下的更偏向 Unix 工具链，一般选 cmd 下的更稳。选完点击 Test，IDEA 会显示 Git version，看到版本号才算真正打通。如果这里报错，先检查路径是否存在、环境变量是否生效，再重启 IDEA。终端方面，可以在 Settings > Tools > Terminal 里把 Shell path 设为 Git Bash，这样在 IDEA 底部的 Terminal 里既能用 ls、cat 这类命令，也能直接执行 git status。很多新手遇到“IDEA 里 Git 菜单是灰的”或者“Terminal 里 git 不是内部命令”，根源都在这里。还有一个细节：如果项目目录本身不在 Git 仓库里，IDEA 不会显示 Commit 窗口，需要先启用版本控制或克隆仓库。我个人的习惯是安装完 Git 后先不急着配 IDEA，而是在系统终端里跑通 git --version、git config --global user.name 这两步，再回到 IDEA 里点 Test，排查链路会清楚很多。

1.3 全局配置和身份信息：一次设置，长期省心

Git 提交必须带作者信息，否则提交会失败或者显示成默认机器名。推荐在终端执行下面两组命令，把名字和邮箱换成你自己的常用信息。邮箱最好和远程仓库账号一致，这样提交记录里能正确关联到你的头像和账号。

git config --global user.name "你的名字" git config --global user.email "你的邮箱@example.com" git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath false git config --global diff.mnemonicprefix true

其中 core.quotepath false 能让中文文件名正常显示，不然 git status 会把中文转义成八进制，看着很难受。diff.mnemonicprefix 会让 diff 输出里用 i/、w/、c/ 等前缀区分索引、工作区和提交，IDEA 在调用 Git 做 diff 时经常会带上类似git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks这样的参数，你不需要手动管它，这是 IDE 为了保证解析结果而临时覆盖配置。core.autocrlf 在 Windows 上可以设为 true，在 macOS 和 Linux 上设为 input，但真正跨平台团队最好再用 .gitattributes 固定文本文件类型。全局配置只影响当前用户，不会污染项目；如果某个项目需要单独覆盖，可以在项目目录里执行不带 --global 的命令。配置完成后用 git config --global --list 检查一遍，后面遇到“提交作者不对”“中文乱码”“换行符警告”时，先回到这里看配置。

1.4 远程仓库密钥准备：HTTPS 和 SSH 怎么选

连接 Gitee、GitHub、GitLab 这类远程仓库有两条路：HTTPS 和 SSH。HTTPS 的好处是简单，输入账号密码或令牌就能用，适合临时克隆公开仓库；缺点是每次推送可能都要认证，虽然 IDEA 可以调用系统凭据管理器记住，但令牌过期后还是会弹窗。SSH 更适合长期开发，一次配置公钥，后续免密推送。生成密钥的命令如下：

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

一路回车即可，默认生成在用户目录的 .ssh 下，id_ed25519 是私钥，id_ed25519.pub 是公钥。把公钥内容复制到远程仓库的 SSH Keys 设置里，然后在终端执行ssh -T git@gitgitee.com或对应平台的测试命令，看到欢迎信息就说明成功。如果公司内网用 GitLab，也类似。多账号场景可以在 .ssh/config 里给不同 Host 配置不同密钥，避免默认密钥冲突。IDEA 里克隆时选择 SSH URL，就能直接走这套密钥。注意私钥绝对不能提交到仓库，也不要发到聊天群里；一旦泄露，立刻去平台删除旧公钥并重新生成。团队里如果统一用 HTTPS，记得用访问令牌而不是登录密码，很多平台已经不支持密码推送。

2. 从零开始：在 IDEA 里完成第一个 Git 项目

2.1 新建项目并初始化仓库：Enable Version Control Integration

如果你已经有一个普通 Java、Python、前端或其他项目，想在 IDEA 里把它变成 Git 仓库，最直接的方式是顶部菜单 VCS > Enable Version Control Integration，选择 Git，确认后项目根目录会出现 .git 文件夹，IDEA 底部也会出现 Git 工具窗口。这个动作等价于在项目根目录执行 git init。初始化之后，IDEA 会把项目里的文件标成红色，表示未跟踪；你可以在 Commit 窗口里勾选要提交的文件，写提交信息，点击 Commit。新手常问“为什么我的文件全是红的”，其实就是还没有 git add。也可以在 IDEA 的 Terminal 里执行 git init、git status 观察状态。初始化时要注意目录层级：一定要在项目根目录执行，不要在某个子模块里误初始化。如果项目里包含多个独立仓库，IDEA 会显示多个根，设置里可以分别管理。初始化完成后建议先创建 .gitignore，再提交第一批文件，否则很容易把 target、build、node_modules、.idea 里的本地配置一起提交进去。第一次提交前用 git status 看一眼，确认没有大文件、密钥文件、数据库文件，这个动作能省掉后面清理历史的很多麻烦。

2.2 克隆远程仓库到本地：Get from VCS 的正确姿势

从远程拉项目，在 IDEA 欢迎界面点击 Get from VCS，或者在已有窗口里选择 File > New > Project from Version Control。粘贴仓库 URL，选择本地目录，点击 Clone。IDEA 会自动调用 Git 克隆，并询问是否信任项目。克隆完成后，IDEA 会识别 Maven、Gradle、npm 等构建工具，自动导入依赖。如果仓库很大，克隆时可能卡在 Receiving objects，这时候不要强退，可以看底部进度条；网络中断后重新 Clone 通常能续传。克隆 SSH 地址需要提前配好密钥，HTTPS 地址则需要账号和令牌。克隆后第一件事是看当前分支是不是预期分支，IDEA 右下角会显示分支名。如果是多模块项目，注意根目录的 .git 和子模块 .git 的关系，子模块需要用 Git 工具窗口里的 Submodules 单独更新。克隆到本地后，不要急着改代码，先执行一次 git status 和 git log --oneline -5，确认工作区干净、历史正常。若发现文件权限全部变成 modified，可能是换行符或文件模式问题，先解决再开发，否则后续 diff 会非常吵。

2.3 第一次提交：暂存、提交信息、推送

IDEA 的 Commit 窗口一般在左侧或底部，快捷键 Ctrl+K 可以打开。窗口里会列出变更文件，勾选要提交的内容，填写 Commit Message，然后点击 Commit 或 Commit and Push。勾选动作相当于 git add，Commit 相当于 git commit，Commit and Push 相当于 commit 之后 push。第一次推送时，如果远程还没有对应分支，IDEA 会提示 Push 并设置上游，确认即可。提交信息不要只写“修改”“更新”，建议写清楚模块和意图，比如“用户模块：修复登录 token 过期未刷新问题”。如果一次改动包含多个不相关主题，最好拆成多次提交，IDEA 支持在 Commit 窗口里按文件勾选，也支持在 Diff 视图里按代码块暂存，这个功能对保持历史清晰非常有用。推送前先 Pull 一次，尤其是多人协作分支，避免 non-fast-forward。第一次推送后，去远程仓库页面确认分支和提交是否出现。若推送失败，先看报错是认证失败、权限不足还是远程有更新，再分别处理。认证失败就检查 SSH 密钥或 HTTPS 令牌，远程有更新就先 Update Project 再 Push。

2.4 .gitignore 的正确打开方式：别把垃圾文件当宝贝

.gitignore 是 Git 项目里最重要的配置文件之一。它告诉 Git 哪些文件不需要跟踪，比如编译产物 target、build、dist，依赖目录 node_modules，日志文件 *.log，本地环境文件 .env.local，IDE 的个人配置 .idea/workspace.xml、.idea/usage.statistics.xml 等。IDEA 提供了 .gitignore 插件，安装后新建文件时可以选模板，也能在右键菜单里把文件加入忽略。但要注意：.gitignore 只对未跟踪文件生效，如果某个文件已经被提交过，再加入忽略规则不会自动移除。正确做法是执行git rm --cached 文件名，保留本地文件但从版本控制里删除，然后提交这次删除。团队项目里 .idea 目录要不要提交一直有争议，我的建议是提交 .idea 下的代码风格、编码配置等共享文件，忽略 workspace.xml、shelf、httpRequests 等个人文件。前端项目还要注意 dist 和缓存目录。全局忽略可以用git config --global core.excludesfile指定一个用户级 ignore 文件，把操作系统生成的 .DS_Store、Thumbs.db 放进去，避免每个项目重复写。每次新建项目，先写 .gitignore 再写业务代码，能避免大量无意义文件进入历史。

3. 日常循环：提交、拉取、推送、看历史

3.1 看懂 IDEA 的 Git 状态颜色和工具窗口

IDEA 用颜色表达文件状态：红色通常表示未跟踪，绿色表示新增已暂存，蓝色表示已修改，灰色表示被忽略，橄榄色可能表示已合并但有冲突。这些颜色不是随便定的，它们对应 Git 的索引和工作区状态。底部 Git 工具窗口有 Log、Console、Local Changes 等标签。Log 里能看到提交历史、分支图、作者和时间；Console 里能看到 IDEA 实际执行的 Git 命令，排查问题时非常有用。比如你点了一次 Update Project，Console 里会显示git pull --rebase或git merge，这样你就知道 IDEA 到底做了什么。右键文件或目录，可以看到 Git 子菜单：Add、Commit File、Show History、Annotate、Rollback 等。Annotate 就是 blame，每一行前面显示最后修改人和提交。熟练之后，你甚至可以不打开终端完成大部分操作。我建议新手先刻意观察颜色变化：新建文件是红色，Add 后变绿，Commit 后颜色消失，修改后变蓝，忽略后变灰。把颜色和 Git 状态对应起来，比死记命令更直观。

3.2 提交前的代码审查：Diff 和 Local Changes

提交前一定要看 Diff。IDEA 的 Commit 窗口双击文件会打开对比视图，左边是当前版本，右边是上一次提交，改动行有颜色标记。你可以逐行检查，避免把调试用的 print、console.log、临时注释、测试账号密码提交上去。IDEA 还支持在 Diff 视图里只暂存部分代码块，比如一个文件里既有功能改动又有格式调整，你可以只勾选功能部分，格式调整留到下一次提交。这个能力叫部分暂存，命令行里对应 git add -p，但在 IDEA 里用鼠标点更直观。Commit 窗口右上角可以切换按目录分组、按模块分组，大项目里查找文件很方便。提交信息输入框旁边通常有提交模板和最近信息，团队有规范时可以配置模板。审查时还要注意文件权限变化，如果 Diff 显示整个文件被删除又新增，可能是换行符或编码变了。发现无关文件被勾选，及时取消。提交前跑一遍本地测试或者至少编译通过，避免把坏代码推到远程。审查这个动作看起来费时间，实际能显著降低回滚概率，尤其是多人共用分支时。

3.3 拉取与推送：先 pull 还是先 commit

日常循环可以概括为：改代码、看 Diff、Commit、Update Project、Push。顺序很重要。如果你本地有未提交改动，直接 Pull 可能触发冲突或覆盖提示。IDEA 的 Update Project 默认可能用 merge 或 rebase，可以在 Settings > Version Control > Git 里设置。团队规范如果要求线性历史，就选 Rebase；如果保留合并记录，就选 Merge。一般建议先 Commit 本地改动，再 Update Project，解决可能出现的冲突，最后 Push。Push 被拒绝最常见的原因是远程分支有你没有的提交，报错类似failed to push some refs或non-fast-forward。这时候不要强行 Force Push，先 Update Project，解决冲突后再推送。Force Push 会覆盖远程历史，只有在个人分支且确认没有别人使用时才考虑，并且更安全的做法是--force-with-lease。IDEA 的 Push 窗口里会显示即将推送的提交和文件，确认无误再点 Push。如果推送需要认证，检查凭据管理器里保存的账号是否过期。多人协作时，养成“小步提交、频繁拉取”的习惯，能大幅减少大冲突。

3.4 查看历史与追溯责任：Git log 和 Annotate

Git 工具窗口的 Log 标签是排查问题的入口。你可以看到提交图、分支线、标签、作者、时间。选中某个提交，右侧会显示这次提交涉及的文件和具体改动。如果只想看某个文件的历史，右键文件选择 Git > Show History。Annotate 能把每一行代码的最后修改提交显示出来，鼠标悬停可以看到提交信息和作者，点击可以跳转到那次提交。这个功能在排查“这行代码为什么这么写”时非常有用。IDEA 还支持在 Log 里搜索提交信息、按作者过滤、按路径过滤。如果项目历史很长，可以用git log --oneline --graph --all --decorate在终端里看简图。有时你会发现某个提交误删了代码，可以在 Log 里找到那次提交，右键选择 Revert Commit，IDEA 会生成一个反向提交，比手动改回去可靠。注意 Revert 和 Reset 不同，Revert 是新增一次提交来抵消旧提交，适合已经推送的历史；Reset 是移动分支指针，适合本地未推送的提交。理解这两者的区别，能避免团队协作中的灾难。

4. 分支合并与冲突：多人协作的重头戏

4.1 创建、切换、重命名、删除分支

IDEA 右下角显示当前分支，点击后可以 New Branch、Checkout、Merge into Current、Rename、Delete。新建分支时建议命名规范：feature/用户中心、bugfix/订单超时、hotfix/支付回调、release/1.2.0。分支名用英文和短横线，避免中文和空格，因为远程仓库和命令行对特殊字符支持不一致。切换分支前，最好先 Commit 或 Stash 当前改动，否则 IDEA 会提示冲突或自动携带未提交改动到新分支。Stash 功能在 Git 工具窗口里，相当于把改动临时存起来，切换后再 Unstash。删除本地分支前确认已经合并，未合并的分支 IDEA 会警告，如果确实要删，可以用命令行git branch -D，但删除后只能靠 reflog 找回。远程分支删除后，本地可能还显示旧分支，执行 Fetch 或 Prune 可以清理。团队里常见做法是主分支保护，开发在 feature 分支，完成后发 Pull Request 或 Merge Request，由代码评审后合并。IDEA 对 Pull Request 有插件支持，但核心还是本地分支管理要清晰。分支不要开太久，越久合并冲突越大。

4.2 合并分支：merge 的两种场景

合并分两种：快进合并和普通合并。如果目标分支没有新提交，Git 默认直接移动指针，就是快进；如果两边都有新提交，就会产生一个合并提交。IDEA 的 Merge into Current 默认行为可以在设置里调整，有些团队要求--no-ff，强制产生合并提交，方便追溯功能边界。典型场景：你在 dev 分支开发完成，要合并到 test 分支。先 Checkout test，Update Project 确保最新，然后选择 dev 分支，Merge into Current。如果顺利，IDEA 会提示合并成功，然后 Push test。如果有冲突，会弹出冲突窗口。合并前最好先看两边差异，IDEA 的 Compare with Branch 可以对比两个分支的文件差异。合并后要跑测试，因为自动合并可能产生语义冲突，比如两个分支都改了同一个方法的不同部分，Git 能合并文本，但逻辑可能已经错了。合并完成后，删除已经无用的 feature 分支，保持分支列表干净。如果团队用 Rebase 流程，则在 feature 分支上 Rebase 到目标分支，再快进合并，历史更线性，但操作更需谨慎。

4.3 冲突解决：三窗格界面实操

冲突是多人协作绕不开的话题。IDEA 的冲突解决界面通常分三栏：左边是当前分支版本，右边是 incoming 版本，中间是合并结果。每个冲突块可以选择 Accept Left、Accept Right，也可以手动编辑中间栏。解决完一个文件后，点击 Mark as Resolved，所有文件处理完再 Commit。关键点：不要直接关闭冲突窗口，也不要在未解决完的情况下 Commit。冲突标记<<<<<<<、=======、>>>>>>>必须全部删除。如果某个文件不想合并，可以选择 Accept Yours 或 Accept Theirs，但要清楚后果。解决冲突后，最好在本地跑一遍编译和测试，因为冲突解决本质上是手工代码合并。常见坑是：解决完忘了 git add，直接 commit 发现还有冲突标记；或者只解决了部分文件，漏掉一个。IDEA 的 Local Changes 里会显示冲突文件，红色标记比较明显。如果冲突太复杂，可以 Abort Merge 回到合并前，重新分析。合并提交完成后推送前，再看一眼 Diff，确认没有把别人的代码覆盖掉。团队里遇到冲突不要慌，先沟通谁改了什么，再决定保留哪边。

4.4 Rebase 和 Cherry-Pick：什么时候用，什么时候别用

Rebase 的作用是把当前分支的提交“搬”到另一个分支的最新提交之后，让历史变成一条直线。适合个人 feature 分支同步主分支改动，比如git rebase main。IDEA 里可以在 Git 工具窗口选择分支，点击 Rebase Current onto Selected。Rebase 过程中可能反复冲突，解决一个后执行git rebase --continue，想放弃就git rebase --abort。重要原则：不要对已经推送到公共分支的提交做 Rebase，因为会改写历史，导致别人本地历史错乱。Cherry-Pick 是挑某一个提交应用到当前分支，适合把 hotfix 提交从 release 分支挑到 main。IDEA 的 Log 里右键提交，选择 Cherry-Pick。Cherry-Pick 会产生新的提交哈希，适合少量提交。交互式 Rebase 可以合并提交、修改提交信息、调整顺序，IDEA 也提供可视化界面，但新手建议先在个人分支练习。Rebase 和 Cherry-Pick 都是强大工具，用错场景比不会用更危险。我的经验是：公共分支用 Merge，个人分支整理用 Rebase，紧急补丁用 Cherry-Pick，并且每次操作前确认当前分支和远程状态。

5. 进阶回退与高频问题排查

5.1 撤销与回退：Undo Commit、Reset、Revert、Stash

提交错了怎么办？分情况。如果刚提交还没推送，IDEA 的 Log 里右键提交选择 Undo Commit，可以把提交撤回到暂存区，文件改动还在，修改后重新提交。这个动作相当于git reset --soft HEAD~1。如果想连暂存也撤销，用git reset HEAD~1；如果想彻底丢弃改动，用git reset --hard HEAD~1，但要非常小心，因为工作区改动会消失。已经推送的提交不要用 Reset 改写历史，应该用 Revert Commit，生成一个反向提交，再推送。Revert 是安全的，因为它不删除历史。Stash 适合临时保存未提交改动，比如突然要切分支修 bug，先 Stash，修完再 Unstash。IDEA 的 Git 工具窗口里有 Stash Changes 和 Unstash Changes，也可以查看 Stash 列表。如果误删了分支或提交，可以用git reflog查看 HEAD 移动记录，找到旧提交哈希后新建分支恢复。IDEA 的 Log 里也能看到 reflog 相关入口，但命令行更直接。记住一句话：未推送可以 Reset，已推送用 Revert，临时改动用 Stash，误删用 Reflog。

5.2 修改最后一次提交：commit --amend 实战

提交信息写错、漏了一个文件，这是常见场景。如果提交还没推送，可以用 Amend。IDEA 的 Commit 窗口右上角有 Amend 选项，勾选后提交会覆盖上一次提交，而不是新增提交。命令行对应git commit --amend，如果还要加入漏掉的文件，先git add 漏掉的文件，再git commit --amend --no-edit保留原信息，或者去掉 --no-edit 修改信息。Amend 会生成新的提交哈希，所以已经推送到公共分支的提交不要 Amend，否则别人拉取时会历史分叉。如果已经推送但必须修改，团队允许的情况下可以用git push --force-with-lease，但一定要确认没有其他人基于旧提交工作。更稳妥的做法是保留旧提交，新增一个修复提交，提交信息写清楚“补充遗漏文件”。IDEA 里 Amend 后 Push 会提示强制推送，看到这个提示要停下来想一想。我的习惯是：本地提交可以随便 Amend，推送前整理干净；一旦推送，就尽量不再改写历史。

5.3 换行符、文件权限、大小写问题

跨平台团队经常遇到换行符警告：LF will be replaced by CRLF。这是因为 Windows 和 Unix 的换行符不同。解决办法是在项目根目录添加 .gitattributes，内容例如* text=auto，对特定文件指定*.sh text eol=lf、*.bat text eol=crlf。然后执行git add --renormalize .重新规范化。core.autocrlf 是全局兜底，但项目级 .gitattributes 更可靠。文件权限问题常见于 Linux 和 Windows 之间，Windows 没有可执行位，Git 可能把文件标记为 mode changed。可以在仓库里设置git config core.filemode false，或者用 .gitattributes 忽略权限。大小写问题也很烦：Windows 文件系统不区分大小写，把 File.java 改成 file.java，Git 可能认为没变化。正确做法是用git mv File.java file.java，或者先改成临时名再改回来。IDEA 重构重命名时通常会调用 Git mv，但有时不会，提交前注意看状态。这些配置问题一旦出现，会影响所有 diff 的可读性，最好在项目初期就统一。

5.4 常见报错速查表：从现象到处理

下面这张表是我在实际项目里经常遇到的 Git 问题，按现象、原因、处理方式整理，方便快速定位。

这张表里的问题大多不是 Git 本身复杂，而是环境、配置和协作习惯造成的。遇到报错先看 IDEA 底部 Console 里实际执行的命令，再对照报错信息搜索，通常很快能定位。

6. 把 IDEA 和 Git 用成团队生产力

6.1 提交信息规范与分支策略

团队协作里，提交信息不是写给自己看的，而是给未来的同事和排查问题的人看的。推荐使用 Conventional Commits 风格：feat、fix、docs、style、refactor、test、chore，后面跟模块和描述，例如feat(order): 新增订单超时自动取消。这样可以直接从提交历史生成变更日志，也方便代码评审。分支策略方面，小团队可以用简化 Trunk Based，主分支保持可发布，功能分支短生命周期；中大型团队可以用 Git Flow 的变体，main、develop、release、feature、hotfix 各司其职。无论哪种策略，核心都是：主分支保护、合并前评审、提交粒度小、分支命名清晰。IDEA 里可以配置提交模板，在 Settings > Version Control > Commit 里设置 Commit Message 模板，减少每次手写格式。代码评审时，Reviewer 可以直接在 IDEA 里查看 Pull Request 的 Diff，按文件评论。分支合并到 test 环境前，最好先合并最新主分支，减少测试环境冲突。规范不是为了形式，而是为了降低沟通成本和回滚风险。

6.2 IDEA 插件与快捷键：让日常操作快起来

IDEA 的 Git 集成已经很强，但几个插件能进一步提升效率。GitToolBox 可以在状态栏显示当前分支、未提交数量、最后提交信息，还能显示每行代码的作者；Git Commit Template 可以规范提交信息；.ignore 插件可以快速生成 .gitignore。安装插件时注意来源，只从官方插件市场安装。常用快捷键：Ctrl+K 打开提交窗口，Ctrl+Shift+K 推送，Ctrl+T 更新项目，Alt+9 打开 Git 工具窗口，Ctrl+Alt+Shift+D 查看变更。不同操作系统和键位方案可能略有差异，可以在 Keymap 里搜索 Git 查看。IDEA 还支持多仓库管理，一个大项目里如果有多个 Git 根，Git 工具窗口会分别显示。终端里可以用git status、git log --oneline --graph辅助查看。插件不要装太多，尤其是会频繁扫描仓库的插件，可能拖慢 IDE。我的搭配是 GitToolBox 加 .ignore，基本够用。如果团队用 Jira 等任务系统，可以配置提交信息模板带任务号，方便关联。

6.3 远程仓库与凭据管理：Gitee、GitHub、GitLab 的注意点

远程仓库选择上，公开项目常用 GitHub，国内项目常用 Gitee，企业内网常用 GitLab。不同平台的 SSH 配置略有差异，但原理一致：生成密钥、上传公钥、测试连接。多账号时，在 .ssh/config 里配置：

Host gitee-work HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_work

克隆时用git@gitee-work:用户名/仓库.git，就能自动匹配密钥。HTTPS 方式建议使用访问令牌，并保存在系统凭据管理器里，不要在 URL 里明文写密码。IDEA 的 Settings > Version Control > Git > Credentials 可以管理保存的凭据。推送大文件前注意平台限制，GitHub 单文件超过 100MB 会被拒绝，Gitee 也有类似限制，大文件应该用 Git LFS 或对象存储。仓库权限要最小化，生产密钥、数据库备份、客户数据绝对不能进仓库。如果误提交了敏感信息，第一动作是作废该密钥，第二是清理仓库历史，第三是通知团队所有人重新克隆或拉取。远程仓库的分支保护规则要打开，禁止直接向 main 推送，必须走合并请求。

6.4 版本管理与 Docker 镜像构建：提交后打标签的实践

在 IDEA 里开发后端项目时，经常需要把代码版本和 Docker 镜像标签对应起来。基本流程是：代码提交到 Git，打上版本标签，比如 v1.2.0，然后构建 Docker 镜像并打相同标签。IDEA 有 Docker 插件，可以连接本地或远程 Docker，编写 Dockerfile 后直接运行构建。Git 标签可以在 Git 工具窗口的 Log 里右键提交，选择 New Tag，输入标签名和说明，再 Push Tag。命令行对应git tag -a v1.2.0 -m "release 1.2.0"和git push origin v1.2.0。这样镜像标签和代码提交能对应，出问题时可以快速找到源码。构建镜像时不要把 .git 目录、测试文件、本地配置打进镜像，用 .dockerignore 排除。CI/CD 流水线里通常根据 Git 标签触发构建，IDEA 里本地验证通过后再推送标签。注意标签不要随意覆盖，远程标签被覆盖后别人本地很难同步。版本号建议遵循语义化版本：主版本、次版本、修订号。这个习惯一旦建立，发布和回滚都会清楚很多。

最后分享一个我常做的动作：每天开始写代码前，先 Update Project，再 Checkout 当天要开发的分支，然后打开 Git 工具窗口看一眼工作区是否干净。这个动作不到一分钟，却能避免“改了半天发现分支不对”“提交时把别人未提交的本地配置带上去”这类问题。踩过几次坑之后，我越来越觉得 IDEA 里的 Git 不是快捷键越多越好，而是把提交前审查、分支切换、冲突解决这三个动作练成肌肉记忆。工具只是放大器，真正让版本控制省心的，还是小步提交、写清楚信息、尊重公共历史。