企业官网建设流程全解析

1. 先搞清楚 IDEA 与 Git 到底是什么关系

刚上手的人经常把 IDEA 和 Git 混成一件事，觉得"我在 IDEA 里点了提交，就等于代码安全了"。其实这俩完全是两个层面的东西，想清楚这一层，后面所有的操作才不会做错。IDEA 是写代码的地方，Git 是管代码版本的地方，IDEA 只是给 Git 套了一层图形外壳。你在图形界面里点的每一个按钮，背后都会翻译成一条或者几条 Git 命令，理解这句话，是本文所有内容的地基。

举个最常见的场景：你在 IDEA 里改了三个文件，点了 Commit，然后发现提交信息写错了想改，结果发现 IDE 界面里找不到入口，就开始慌。这种慌张的根源，就是你只知道按钮，不知道按钮对应的是git commit -m "xxx"。我写这篇东西的目的很简单，就是把 IDEA 里那些看起来很方便、但一遇到异常就没法处理的操作，全部还原到 Git 本身去讲，让你既可以用图形界面偷懒，也能在图形界面失灵的时候用命令行救场。

1.1 两个工具各管什么，职责不要搞混

Git 负责的是版本本身，也就是文件在不同时间点上的快照、分支的指针、远程仓库的同步状态。它是一套独立的命令行工具，装在操作系统层面，跟 IDEA 没有任何绑定关系，你完全可以在纯终端里用它管理任何一个文件夹。IDEA 负责的是把 Git 的命令翻译成可视化的界面，比如用颜色标记文件状态、用窗口展示 diff、用按钮触发提交和推送。

搞清职责之后，很多困惑就自动消失了。比如"我在 IDEA 里改的东西 Git 有没有记录"，答案是：只要文件被 IDEA 自动保存，你去看 Git 工具窗口，它就会立刻把改动识别成未暂存的修改。再比如"我把 IDEA 卸了，代码历史会不会丢"，答案是绝对不会，历史都存在项目根目录那个隐藏的.git文件夹里，跟 IDE 一点关系都没有。

注意：不要用 IDEA 的"关闭项目"或"删除项目"来代替代码备份。真正能保证代码安全的是提交并推送到远程仓库，而不是 IDE 里项目列表还在不在。

1.2 为什么建议在 IDEA 里用 Git，而不是纯命令行

有人会说命令行更纯粹，用 IDE 是偷懒。我不同意这个说法。日常开发里，改动文件、看 diff、写提交信息这三件事发生得极其频繁，命令行每次都要git status看一下、git add选文件、git diff核对，效率确实不如 IDE 直接点两下。IDEA 在编辑器左边栏会直接显示这一行是新增还是修改，这个功能命令行是给不了的，它能让你在改代码的过程中就意识到自己动了哪些位置，而不是等提交的时候再回过头去看。

命令行的优势在于处理复杂情况，比如 rebase 出问题、detached HEAD、需要精细挑拣提交。我的实际习惯是：日常提交、拉取、推送、看历史全部在 IDEA 里完成，遇到图形界面表达不了的复杂场景再切命令行。两者不是二选一，是配合关系，一个负责效率，一个负责兜底。

2. 从零把环境搭起来：Git 安装与 IDEA 关联配置

环境这一步看着简单，但它是新手翻车最多的地方。Git 装错版本、安装选项选错、IDEA 找不到 Git 路径、换行符把整个文件标成改动、中文文件名显示成一堆转义字符，这些问题全都出在这一步。把这些坑一次填平，后面的操作会顺畅得多。

2.1 Git 安装时那几个选项到底该怎么选

Windows 上装 Git 会弹出一长串选项，很多人一路点 Next，结果埋下隐患。以下几个地方我建议停一下。

编辑器的选择，默认给的是 Vim，对不熟悉的人很不友好，提交信息一旦进入 Vim 编辑界面就不知道怎么退出来。我一般直接选 "Use Visual Studio Code as Git's default editor"，或者干脆保持默认但记住:wq和:q!这两条命令。换行符处理选项，建议选 "Checkout Windows-style, commit Unix-style line endings"，也就是默认那项，它在检出时转成 CRLF、提交时转成 LF，能避免团队里 Windows 和 Mac 混用时整个文件被判定为全量改动。

PATH 环境变量的选项，选 "Git from the command line and also from 3rd-party software"，这样 IDEA 这类第三方工具才能自动找到 Git。如果选了只从 Git Bash 使用，后面 IDEA 里就会出现检测不到 Git 的情况。凭证管理器保持默认的 "Git Credential Manager" 就行，它能在你推送时弹窗让你登录，省去手动敲密码。

装完之后验证一下，打开任意终端：

git --version git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两条 config 一定要设，否则提交记录里的作者信息是乱的，团队协作时别人根本不知道这个提交是谁做的。

提示：user.email最好和你远程仓库账号绑定的邮箱保持一致，很多平台就是靠邮箱把提交和账号关联起来的，不一致的话贡献图里不会显示你的头像。

2.2 在 IDEA 里绑定 Git 路径的正确做法

打开 IDEA，进入File → Settings → Version Control → Git，在 "Path to Git executable" 里会自动填入检测到的 git 路径。如果这一栏是空的或者飘红，说明 IDEA 没找到，手动点后面那个文件夹图标，定位到 Git 安装目录下的bin\git.exe就行。

填好之后点右边的 "Test" 按钮，弹出 Git 版本号就说明通了。这一步特别重要，很多新手在终端里git --version一切正常，但 IDEA 里就是不识别，八成就是路径没配。绑定成功后，回到项目，进入VCS → Enable Version Control Integration，选择 Git，IDEA 就会把当前项目初始化为一个 Git 仓库。

从远程克隆进来的项目一般不需要这一步，IDEA 打开时就已经识别到.git目录了。判断方法很简单：看底部有没有 "Git" 这个工具窗口标签，以及编辑器行号旁边有没有颜色标记，有就说明已经接上了。

2.3 全局忽略文件和编码这两个隐藏坑

.gitignore是必须提前处理的，不然后面提交时你会被target、.idea、*.iml、node_modules这类目录烦到崩溃。IDEA 里创建方式是在项目根目录右键New → File，命名.gitignore，然后填入规则。比如一个 Java 项目常见的内容：

target/ *.class *.log .idea/ *.iml out/

编码问题也常被忽略。中文文件名在 Git 里默认会被转义显示成一串八进制数字，看着很难受。加一条全局配置就能解决：

git config --global core.quotepath false

这条配置的作用是让 Git 在输出时按原本字符显示路径，IDEA 文件树和提交记录里就能正常看到中文名。很多人搜到的命令里还有-c diff.mnemonicprefix=false -c core.quotepath=false这一长串，其实那是 IDEA 调用 Git 时自动拼的参数，你不用手动敲，它的作用就是关掉 diff 的前缀缩写、保证中文路径正常显示。

3. IDEA 中 Git 的核心操作面板拆解

界面认不清，操作就容易点错。IDEA 把 Git 的能力分散在三个地方：底部的 Git 工具窗口、提交时的 Commit 窗口、以及编辑器左侧的行标记。把这三个地方各自负责什么搞清楚，你就能预判每个动作的结果。

3.1 三个界面区域各自负责什么

底部 Git 工具窗口（快捷键Alt + 9）主要用来看历史、看分支、看本地与远程的差异。它有三个标签页：Log 显示提交历史，Console 显示 IDE 实际执行的 Git 命令，Local Changes 显示当前未提交的改动。我特别推荐你多看看 Console，你在界面上点的每一步都会在这留下真实的命令行，想学命令的话这是最好的教材。

编辑器左侧的行标记是最直观的，绿色代表新增行，蓝色代表修改行，灰色代表删除位置。点一下这个标记就能弹出该行的历史，选择 "Show Diff" 可以看到这一行上一次是谁改的。这个功能在排查"代码怎么变成这样了"的时候极其好用。

Commit 窗口（快捷键Ctrl + K）是提交的核心，上半部分列文件，中间显示选中文件的 diff，下半部分写提交信息。它把git add和git commit两步合并在一个界面里完成，勾选哪个文件就相当于add哪个文件。

3.2 一次标准的提交与推送流程

假设你修了一个 bug，改了三个文件。流程是这样的：先Ctrl + K打开提交窗口，逐个检查每个文件的 diff，确认没有把调试用的System.out.println或者临时路径带进去。这一步千万别省，我就见过有人把数据库密码直接提交上去的。

确认完之后，勾选要提交的文件，写提交信息。提交信息的规范我建议就按最常见的格式来：第一行简短描述做了什么，空一行，下面写为什么这么做。比如：

fix: 修复订单金额计算时小数精度丢失 改为使用 BigDecimal 进行运算，避免 double 在累加时产生 0.0000001 这类误差导致对账不平。

点 Commit 完成本地提交，注意这只是提交到本地仓库，远程还没有。接着Ctrl + Shift + K打开推送窗口，确认要推的分支和目标远程，点 Push。到这一步，代码才真正进入远程仓库。

注意：Commit 和 Push 是两个动作，很多人以为点了 Commit 别人就能看到，其实不是。团队协作里养成"提交后立刻推送"的习惯，能避免本地堆一堆提交结果搞丢。

3.3 查看历史与代码溯源的正确姿势

看历史不要只会看列表。在 Git 工具窗口的 Log 标签里，右键某个提交可以做很多事：Compare with Local 看这次提交和当前工作区的差异，Cherry-Pick 把这个提交单独摘到当前分支，Revert 生成一个反向提交来撤销它。这几个操作我后面还会细讲。

代码溯源要用好 Annotate（在文件编辑区右键 → Git → Annotate with Git Blame）。它会在每一行左边显示最后一次修改这行的提交和作者。当你看到一段莫名其妙的代码想骂人的时候，先 Annotate 看看是谁、什么时候、为什么改的，点开那个提交的 diff，往往能立刻明白背景。这个功能可以说是接手老项目时最救命的一个。

4. 分支管理：从单人开发到多人协作

分支是 Git 最核心的能力，也是 IDEA 里最容易点错的地方。单人开发时你可能永远只用一条 main 分支，但一旦进入协作，分支策略没想清楚，合并冲突能让你怀疑人生。

4.1 分支的创建、切换与本地远程对应关系

在 IDEA 右下角有个分支显示区域，点开就能看到本地分支、远程分支，以及新建分支的入口。创建新分支时，IDEA 会问你是从当前分支切出去还是从指定分支切出去，这个选择要慎重，因为新分支的起点决定了它包含哪些提交。常见的做法是：从最新的 main 或 develop 切出功能分支，比如feature/order-export。

切换分支用一个快捷键Ctrl + Shift + \（不同版本可能略有差异），也可以在右下角点选。切换前要注意一件事：如果你的工作区有未提交的改动，切分支时这些改动会跟着过去，如果目标分支上这些文件本来就有差异，就可能冲突或者丢失。稳妥的做法是切换前要么提交，要么用 stash 暂存（后面会讲）。

本地分支和远程分支的对应关系很多人搞不清。简单说，本地分支是你机器上真实存在的，远程分支是远程仓库上的镜像。你git push时把本地分支推上去，如果远程还没有同名分支，IDEA 会提示你新建并推送，推上去之后本地分支就会自动跟踪这个远程分支。之后Ctrl + T（Update Project）拉取时，就会从这个跟踪的远程分支合并最新代码。

4.2 合并与 Rebase 该怎么选

合并有两种方式：Merge 和 Rebase。Merge 会在目标分支上生成一个新的合并提交，历史呈现分叉再汇合的形状；Rebase 会把你的提交逐个挪到目标分支的最新提交之上，历史变成一条直线，非常干净。

我的选择标准是这样的：如果你是在共享分支（比如 main、develop）上整合功能分支，用 Merge，因为它保留了真实的合并时间点，出问题好追溯。如果你是在自己的私有功能分支上，想同步主干的最新代码，用 Rebase，能让提交历史保持线性，方便 code review。

在 IDEA 里，Rebase 的操作是：切到你的功能分支，然后在 Git 工具的 Log 里点 main 分支，选择 "Rebase Current onto Selected" 或者右键你的分支选择 Rebase。操作前强烈建议先备份一下分支，或者确保你的代码已经推送过，因为 rebase 会重写提交历史，一旦出错回退会比较麻烦。

提示：Rebase 过的分支不要再拿去和别人共享。因为提交 hash 变了，别人拉取时会产生大量冲突。这是团队协作里最容易踩的雷之一。

4.3 冲突解决全流程实操

冲突是绕不过去的。当你在 IDEA 里 Pull 或 Merge 时，如果同一个文件的同一位置被两边都改过，IDEA 就会弹出 Merge 冲突解决工具，界面分成三块：左边是你的版本，右边是远程版本，中间是最终结果。

处理原则是逐块决定保留哪一边，或者两边都保留后手动调整。IDEA 每个冲突块都有箭头按钮，"Accept Left"、"Accept Right"、"Accept Both"，点完中间区域就会更新成合并结果。这里有个经验：冲突不要急着全按 Accept，一定要理解两边各自改了什么，尤其是当你不确定别人为什么这么改的时候，去 Annotate 一下那个位置，看看对应的提交说明。

常见冲突有哪些呢？一类是同一个方法两边都加了新逻辑，这类需要你把两段逻辑都保留并手动调整顺序；一类是配置文件两边都改了不同字段，这类一般 Accept Both 就行；还有一类是格式化导致的整文件冲突，比如一方全量重排了缩进，这类要先跟对方确认格式规范，否则每次合并都要打一次。

解决完所有冲突标记后，点 "Apply"，然后在提交窗口里把这次合并提交完成。记得合并提交信息不要写成默认的 "Merge branch 'xxx'"，最好补一句这次合并解决了什么，方便日后查。

5. 高频进阶操作：回退、暂存、挑拣与撤销

日常写代码总会手滑：提交信息写错、漏加文件、提交了不该提交的东西、想临时切分支又不想提交。这一组操作是真正区分熟练工和新手的地方，用好了能省下大量擦屁股时间。

5.1 Amend 修正最近一次提交

场景很典型：刚提交完发现少加了一个文件，或者提交信息有个错别字。正确做法是git commit --amend，在 IDEA 里对应的是 Commit 窗口底部那个 "Amend" 勾选框。勾上之后，你新勾选的文件会追加到上一次提交里，提交信息框里显示的是上一次的信息，可以顺带改掉。

用 Amend 有个前提：这次提交还没有推送。如果已经推送了再用 amend 修改，本地和远程的提交历史就不一致了，之后推送需要强推（force push），强推在共享分支上是危险操作，会覆盖别人的提交。所以养成习惯：推送前检查一遍提交信息，能 amend 就趁早 amend。

在 IDEA 里操作路径是：修改文件 →Ctrl + K→ 勾选修改的文件 → 勾选 "Amend" → 修改提交信息 → Commit。完成后 Git 工具窗口的 Log 里，那一次提交的 hash 会变，但历史里不会多出新的提交，看起来干干净净。

5.2 Stash：临时存档不提交的改动

你正在写的功能到一半，突然线上有个紧急 bug 要修，但当前代码又不适合提交（跑都跑不起来）。这时候就用 stash。在 IDEA 里，Git → Uncommitted Changes → Stash Changes（快捷键Ctrl + Shift + A里搜 stash 也能找到），输入一个备注，比如 "order-export-half-done"，改动就被暂存起来了，工作区变干净。

处理完紧急 bug 提交推送后，回到原分支，Git → Uncommitted Changes → Unstash Changes，选你之前存的那一条，改动就回来了。stash 支持多次，可以看成是栈结构，后进先出，但用备注区分清楚就不会乱。我个人习惯是每次 stash 都写清楚在做什么，不然过两天根本记不起来那堆改动是干嘛的。

这里有个坑要提醒：stash 里如果包含新创建但还没被 Git 跟踪的文件（untracked），默认不会存进去，需要勾选 "Include untracked files"。我吃过这个亏，一段新建的代码文件在 stash 时没被带上，恢复之后发现文件没了，整个人都懵了。

5.3 Cherry-Pick 与 Revert 的适用边界

Cherry-Pick 是把别的分支上的某一个提交单独摘到当前分支。典型场景：你在 develop 上修了一个 emergent 的 bug，这个修复也需要放到 release 分支上，但 release 分支上还不需要 develop 的其他改动。这时就在 Log 里选中那个提交，右键 "Cherry-Pick"。

用之前建议先切到目标分支，并且工作区保持干净。Cherry-Pick 遇到冲突时需要手动解决，跟普通合并一样。要注意的一点是，cherry-pick 出来的提交 hash 和原来的不一样，是复制了一个新的，所以两边历史里会有两个内容相同但 hash 不同的提交，这本身是正常的，只要你自己心里有数就行。

Revert 的作用是生成一个反向提交来抵消某次提交。它和 reset 不同，reset 是直接退回历史、把后面的提交砍掉，revert 是在历史末尾再加一笔反向修改，不改动已经推送的历史。所以共享分支上要撤销某次提交，正确做法是 revert，不是 reset。IDEA 里在 Log 选中提交右键 "Revert Commit" 就行，之后会生成一个新的待提交，检查无误后提交推送即可。

5.4 Reset 三种模式的差异一定要搞明白

Reset 有三个模式，是很多事故的源头，必须说清楚。

--hard是最危险的，它会直接把工作区里未提交的改动删掉。我有一次差点在--hard里丢掉两小时的活，还好 IDEA 会提示 "未提交的更改将被删除，确定吗"，那一刻是真吓出汗。所以用--hard前，务必先确认工作区没有要保留的东西，或者先 stash 一份。

IDEA 里 Reset 的入口在 Log 里右键某个提交 → "Reset Current Branch to Here"，然后让你选 Soft、Mixed、Hard。默认它会推荐 Soft，算是个比较稳妥的选择。记住一句话：只要那个提交已经推送过，就不要 reset，用 revert。

6. 远程仓库对接：Gitee 与 GitHub 的密钥配置

远程仓库才是代码真正的保险柜。本地仓库只能防手滑，防不了硬盘坏、换电脑、误删项目。把代码推到远程，才算真正上了锁。国内团队用 Gitee 的不少，开源项目多用 GitHub，配置方式基本一致。

6.1 生成 SSH 密钥并添加到平台

SSH 方式比 HTTPS 方便的地方在于不用每次输账号密码，配置一次长期有效。生成密钥的命令：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

一路回车默认存到用户目录下的.ssh文件夹里，会得到两个文件：id_rsa是私钥，绝对不能给别人；id_rsa.pub是公钥，是要贴到平台上的那个。查看公钥内容：

cat ~/.ssh/id_rsa.pub

Windows 下可以用记事本打开.ssh/id_rsa.pub，把整段内容复制下来。然后登录 Gitee 或 GitHub，进入设置里的 SSH 公钥页面，新建一个，粘贴进去保存。

验证是否配好：

ssh -T git@gitee.com

出现带 "successfully authenticated" 字样的提示就说明通过了。第一次连接会提示确认主机指纹，输入 yes 即可。

注意：公钥可以随便贴，私钥一定要守住。私钥一旦泄露，等于别人可以以你的身份推代码。看到误提交私钥的情况，要第一时间在平台上删掉旧公钥并重新生成。

6.2 在 IDEA 里绑定远程仓库与日常拉推

IDEA 里绑定远程的方式是Git → Manage Remotes，点加号，名字一般叫 origin，URL 填git@gitee.com:用户名/仓库名.git或者对应的 GitHub 地址，保存。之后 Push 时目标远程就会出现在下拉框里。

日常协作节奏我总结成一个固定动作：早上到工位先Ctrl + T（Update Project，相当于git pull）把大家的最新代码拉下来，再开始干活；写一段就提交一次，别攒着；提交完立刻推送。这个节奏能最大限度减少冲突，因为冲突的规模和你累积的改动量成正比，改动越少、拉取越勤，冲突就越小。

如果远程仓库还没建，IDEA 也支持直接把本地项目推上去：Git → GitHub → Share Project on GitHub（Gitee 有类似插件或入口），它会自动帮你创建远程仓库再推上去，省去先在网页上建仓库的步骤。

7. 常见问题与排查技巧实录

下面这些是我和身边人真踩过的坑，整理成速查表，遇到问题先对着找，能省下大量搜索时间。

排查问题时有个通用思路：打开 IDEA 的 Git Console，看看刚才那个操作实际执行了什么命令。很多"IDEA 出 bug 了"的情况，看一眼 Console 就明白了。比如你以为点了 pull，其实只是 fetch，没合并；你以为点了 revert，其实点的是 reset。Console 是真相所在。

另一个高频问题是大文件误提交导致仓库膨胀。如果你不小心提交了一个几百 MB 的 jar 或压缩包，直接 revert 是没用的，历史里还留着那个 blob。要用专门的历史清理手段，或者干脆重建仓库。预防的办法就是在项目开始时就写好.gitignore，把产物目录、依赖目录、本地配置全部排除。

还有一个细节，团队里不同人用不同操作系统时，建议在项目根目录放一个.gitattributes文件，统一指定文本文件的换行符处理方式：

* text=auto *.sh text eol=lf *.bat text eol=crlf

这样做的好处是，不管是 Windows 还是 macOS 检出，Git 都会按规则处理换行符，不会因为换行符差异把整个文件判定成改动。这个小文件在跨平台团队里能省掉很多无意义的冲突。

我个人用下来的体会是，IDEA 的 Git 集成已经足够覆盖九成场景，真正需要敲命令的时候，基本都是操作出了问题要救火。所以与其背命令，不如把 IDEA 每个按钮背后对应的命令搞明白，再顺手记几条关键命令做底牌。最后分享一个小习惯：动手做任何"不可逆"操作之前，先想着推一次，或者 stash 一次，留个后路。这条习惯帮我躲过的坑，比我看过的所有教程加起来都多。