企业官网建设流程全解析

命令行里git status、git add -p、git rebase -i用得飞起的人，第一次在 PyCharm 里点开右下角那个分支名字时，往往会愣一下：这些操作在图形界面里到底对应哪条命令？点下去会不会出事？反过来，一直用 PyCharm 图形化版本控制、分支管理的人，切回命令行又常常心里没底，觉得自己是在"盲操作"。这中间的落差，其实不是能力问题，而是没人把界面元素和 Git 底层命令的对应关系讲清楚。

这篇内容就干这一件事：把 PyCharm 的 Git 版本控制与分支管理拆成可对照、可复现的操作链路。从仓库初始化、忽略规则、拆块提交，到分支创建切换、Merge 与 Rebase 的取舍、三窗格冲突解决，再到历史追溯和误操作救火，每一步我都会说明它在命令行里等价于什么、为什么这么设计、什么时候会翻车。适合两类人看：一类是刚开始用 IDE 做团队协作的新手，另一类是命令行熟手但想搞清楚 PyCharm 到底在背后干了什么的老兵。全程基于常见实践补充细节，你手上的版本如果界面有差异，以自己 IDE 的实际显示为准。

1. 图形化 Git 不是黑箱：面板与命令的对应关系

1.1 先搞明白 PyCharm 只是 Git 的一层壳

很多人对 IDE 里的 Git 有天然的不信任感，觉得"看不见命令就不可控"。实际情况恰好相反：PyCharm 本身不实现版本控制逻辑，它只是调用你系统上安装的 Git 可执行文件，然后把命令输出解析成界面。你在 Commit 面板里勾选几个代码块点提交，它在背后执行的就是一条带路径参数的git commit；你在分支弹窗里点 Rebase，它执行的就是git rebase。理解了这一层，界面上任何一个按钮你都能反推出它的命令，风险也就变得可评估了。

验证方法很简单：打开 Git 工具窗口里的 Console 标签页，你在图形界面做的每一次操作，都能在这里看到对应的命令和输出。我习惯在处理复杂合并之前先把这个 Console 面板开着，操作完回头扫一眼执行了什么。这个习惯救过我两次，一次是发现某个"撤销"按钮实际执行的是硬回退，一次是发现提交时 IDE 自动加了签名参数导致钩子行为不同。

配置入口在 Settings 里的 Version Control 分组，第一项 Git 会显示当前检测到的可执行文件路径和版本号。如果这里显示"Git not found"，说明系统 PATH 没配好，手动指定安装目录下的可执行文件即可。版本上有一点值得注意：Git 2.23 之后git checkout被拆成了git switch和git restore，较新的 IDE 版本在切换分支时调用的已经是git switch，如果你机器上的 Git 版本太老，某些操作会静默失败或者报错信息很奇怪。团队统一环境的时候，把 Git 版本也纳入约定范围，能省掉很多莫名其妙的排查。

1.2 三个入口各管什么，别混着用

PyCharm 里跟 Git 相关的界面主要分布在三个地方，职责其实分得很清楚，混用会让人抓狂。

底部状态栏还有几个容易被忽略的信息：当前分支名、是否有未推送提交（向上的箭头数字）、是否有未拉取提交（向下的箭头数字）。我见过不少人只看提交按钮不看状态栏，结果在落后远端十几个提交的分支上继续写代码，最后合并时冲突爆炸。养成一个习惯：动手写代码前扫一眼状态栏的箭头，向下的数字不为零就先更新。

编辑器里的文件名颜色也是信息源。默认配色下，未纳入版本控制的文件是红色，新加且已暂存的是绿色，修改过的是蓝色，被忽略的是灰褐色。这套颜色可以在 Settings 的 Version Control 下的 File Status Colors 里改，团队里如果有人用深色主题有人用浅色主题，统一一下配色方案能减少沟通成本。至于每个文件具体改了哪几行，看行号右侧的变更标记条就够了：绿色竖条是新增行，蓝色是修改行，灰色小三角是删除位置，点一下能看到该行的原始内容。

1.3 为什么建议先在 IDE 里熟悉再回命令行

有个观点我想说清楚：图形化版本控制不是"新手拐杖"，它是降低认知负荷的工具。分支合并这类操作，冲突文件可能几十个，在命令行里你要反复git status看还剩哪些没解决；在 IDE 里左侧列着所有冲突文件，解决一个划掉一个，进度一目了然。再比如拆块提交，命令行的git add -p要一个个 chunk 交互式回答 y/n，PyCharm 里直接勾复选框，视觉上还带着 diff 高亮。

但反过来说，完全依赖界面也有代价。有几种情况命令行明显更顺手：批量操作（比如给二十个文件同时打补丁）、复杂的交互式变基、需要精确控制提交时间的场景、以及排查"为什么 IDE 显示的状态和实际不一致"这类疑难杂症。我的建议是把界面当主力，把命令行 Console 当兜底，遇到界面做不到的事直接在 IDE 内置终端里敲命令，两边共用同一个工作区，互不冲突。

2. 从零接入：仓库初始化、忽略规则与第一次提交

2.1 两种接入路径：新建仓库还是克隆已有仓库

新项目的起步方式取决于代码在哪。如果是本地已经有一堆文件、想纳入版本控制，走 VCS 菜单里的"Enable Version Control Integration"，选择 Git，它会在项目根目录执行git init。注意这一步只是创建了.git目录，还没有任何提交，此时所有文件都是未跟踪状态。如果代码已经在远端仓库里，走"Get from VCS"，填仓库地址，选择本地目录，它会执行git clone并自动把项目配置好，这是团队协作里最常见的路径。

一个容易踩的细节：初始化仓库的位置。如果你只有某个子目录需要版本控制，而项目根目录是另一个更大的目录，一定要在正确的层级执行初始化。我见过有人在用户主目录下误执行了初始化，结果一个git add .把整个家目录的东西都想加进去，.git目录膨胀到几个 G。所以初始化之后第一件事永远是确认根目录对不对，看一眼 IDE 里显示的项目根和.git目录是否在同一层。

克隆路径上还有个凭证问题。用 HTTPS 地址克隆时，第一次推送会让你输入账号密码或者令牌；用 SSH 地址则需要提前配好密钥对，把公钥上传到远端。IDE 在 Settings 的 Version Control 下的 Git 配置里可以指定 SSH 可执行文件，Windows 上尤其要注意这一点：系统自带的和 Git 安装包里带的那份可能不是同一个，选错了会出现"命令行能推、IDE 推不了"的怪现象。

2.2 忽略规则要在第一次提交前写好

.gitignore这个东西，最理想的创建时机是第一次提交之前。事后再补不是不行，但已经进了历史的文件不会因为加了忽略规则就消失，你还得额外执行一次从索引里移除的操作，多绕一圈。PyCharm 新建.gitignore文件时可以选模板，Python 项目选 Python 模板会带上一堆常见产物目录，另外还有专门针对 IDE 配置目录的模板可以叠加使用。

关于.idea目录到底要不要提交，这是团队协作里争论最多的话题之一，我的实践结论是拆开看，不要一刀切。整个目录要么全提交要么全忽略，这两种极端做法都有问题。

实际操作上，可以在.gitignore里先写.idea/*全忽略，再用取反规则把需要共享的子目录放出来，类似.idea/codeStyles前面加感叹号。这套写法新手容易写错顺序，记住一条：取反规则必须写在忽略规则之后，且父目录被忽略时子目录的取反往往失效，稳妥做法是把父目录写成.idea/*（带星号）而不是.idea/（不带星号）。

临时想忽略某个已跟踪文件的改动，别去改.gitignore，用git update-index --skip-worktree这类索引级手段，或者干脆用 IDE 的 Shelve 把改动收起来。改忽略规则影响的是所有人，索引标记只影响你自己。

2.3 第一次提交前必须过的三个检查

第一次提交的坑最集中，因为这时候项目结构和团队约定都还没定型。我在带人的时候会强制要求走完这三步。

第一步，看一眼完整的变更列表。打开提交工具窗口，确认列出来的文件都是你想提交的。这里最容易出错的是那些自动生成的东西：虚拟环境目录、编译产物、本地配置文件、日志文件、数据库文件。有一次一个同事把本地调试用的 SQLite 数据库文件提交上去了，后面每次跑测试都会产生变更，天天在变更列表里碍眼，追了两周才彻底清理干净。

第二步，检查换行符。这是跨平台协作的第一大坑，Windows 上默认换行是 CRLF，Linux 和 macOS 上是 LF。如果团队里有人用 Windows 有人用 Mac，不加约束的话，一个文件可能因为换行符不同被整篇标记为修改，diff 根本没法看。解决方式有两条路：一是在 Git 配置里设core.autocrlf，Windows 设true（提交时转 LF，检出时转 CRLF），macOS 和 Linux 设input（提交时转 LF，检出时不变）；二是更推荐的做法，在仓库根目录加一个.gitattributes文件，显式声明各类文件的换行符策略，让规则跟着仓库走而不是跟着每个人的机器走。PyCharm 的设置里也有单独的换行符选项，位置在编辑器代码风格那一栏，但它影响的是新建文件，历史文件的换行符还是得靠 Git 层配置来统一。

第三步，确认提交身份。提交信息里的作者名和邮箱来自 Git 全局配置，如果这台机器是共用的，或者你之前配过别的身份，提交记录上就会挂错名字。在 IDE 的终端里执行git config user.name和git config user.email确认一下，需要改就在仓库级别重新设一遍，仓库级配置优先级高于全局。

3. 提交面板的精细化操作：拆块提交、改历史与提交前检查

3.1 部分提交：把一次改动拆成几个干净的提交

有条经验值得反复强调：提交的粒度决定了他日排查问题的成本。一次提交里塞进三个不相关的改动，将来要回退其中一个，你就得手工拆。PyCharm 的提交面板在这一点上给的能力比命令行直观得多。

在提交工具窗口里，每个文件左边有复选框，展开文件后能看到具体的变更块（chunk），每个块左边也有复选框，甚至单行都能勾。你勾选哪些，提交时就只包含哪些，剩下的留在工作区。这个操作背后等价于git add -p加git commit，但省掉了交互式回答的繁琐。

具体流程我一般这么走：先写代码，写完打开提交面板，从上往下过一遍，把属于同一个逻辑变更的块勾上，写一条对应的提交信息，提交。然后剩下的块继续分组。举个常见的场景：你在实现一个新功能的过程中顺手修了一个拼写错误、又调整了一处配置。这应该是三个提交，而不是一个。功能性改动、修正性改动、配置类改动，混在一起提交，将来做二分查找定位问题时，那个大提交就是个黑盒。

有个细节要注意：同一行既有功能改动又有格式调整时，行级勾选做不到拆分，只能拆到块级。这种时候我的做法是先格式化再写功能，或者反过来分开两次提交，别硬拆。

3.2 提交信息、检查项与"提交并推送"

提交信息输入框上方的几个复选框，价值比很多人以为的大。默认可能有"优化导入""重排代码""运行代码分析"之类的选项，勾上之后提交前会自动跑一遍对应动作，有问题会在提交对话框里提示。团队里如果有统一的代码规范，把"重排代码"和"优化导入"勾上，能避免"格式化产生的 diff"混进功能提交里。

提交信息本身也值得规范一下。最基础的要求是首行简明扼要、不超过五六十个字符，需要详细说明的话空一行再写正文。更进一步的，可以在 Settings 的 Version Control 下的 Commit 配置里开启提交信息检查，用正则约束格式，比如要求以特定前缀开头。这个功能对小团队特别有用，因为它在你点提交的那一刻就拦住不合规的信息，比事后让人改历史容易一万倍。

右下角的"提交并推送"是个双刃剑。它省了一步操作，但也让"提交"和"推送"这两个语义不同的动作耦合在一起。我个人的习惯是：本地提交随便做，改错了还能撤；推送一定要单独确认，因为推上去的东西可能已经被别人拉走了。团队如果开了保护分支，推送到受保护分支会直接被拒，这时候还得回头处理，不如一开始就分两步走。

3.3 提交写错了怎么改：Amend、Undo Commit 与交互式变基

三种情况，三种处理方式。

刚提交完发现漏了一个文件或者提交信息写错了，这时候用 Amend。在提交面板勾上要补的文件，然后从提交按钮的下拉菜单里选"修改提交"，它会把新内容并入上一次提交，同时允许你改提交信息。背后执行的是git commit --amend。有个前提必须确认：上一次提交还没推送到远端。如果已经推了，改完之后本地和远端历史就不一致，再推就得强制覆盖，风险很大。

提交本身想整个撤销退回工作区，用 Undo Commit。快捷键是 Ctrl+Alt+Z（Windows/Linux），效果等价于git reset --soft HEAD~1，提交没了，改动原样留在工作区，文件状态回到已暂存。这个操作我几乎每天都在用，尤其是在提交之后立刻发现"这不该单独成一个提交"的时候。

如果是连续好几个提交都写乱了，想合并、重排、改信息，那就得用交互式变基。在 Git 工具窗口的 Log 面板里选中某个提交，右键选"从这里开始交互式变基"，弹出的表格里每一行是一个提交，可以拖拽排序、标记为 squash（合并到上一个）、reword（改信息）、drop（丢弃）。这是 PyCharm 里少数几个比命令行更直观的操作，因为命令行里rebase -i打开的是一个文本编辑器，顺序和操作的对应关系全靠想象。

提示：交互式变基会重写提交哈希，只对本地未推送的提交使用。已经推送到公共分支的提交，用 Revert 生成反向提交，不要动历史。

4. 分支的创建、切换与合并：右下角弹窗能做的和不能做的

4.1 分支操作的完整清单与执行时机

右下角的分支名点开，是一个覆盖了绝大多数分支操作的面板。新建分支时它会问你要从哪个提交起头，默认是当前 HEAD，也可以手动指定某个历史提交。这里有个实用选项：勾选"检出"表示创建后立即切过去，不勾就只是创建。我倾向于勾上，因为创建分支的目的通常就是要马上在上面干活。

切换分支时最大的风险是工作区有未提交的改动。Git 会尝试把这些改动带过去，如果目标分支上相同文件有冲突，切换就会失败。PyCharm 在这种情况下会弹提示，给你几个选择：搁置改动（Shelve）、强制切换（Smart Checkout）、或者取消。Smart Checkout 的背后逻辑是把本地改动先 stash 起来，切完再 pop 回去，多数情况下能成功，但如果 pop 时冲突，你还得再解决一次。我的做法是，切换分支前要么提交要么搁置，别指望自动搬运。

重命名和删除这两个操作看着简单，其实有讲究。重命名只改本地分支名，远端的旧名字还在，需要单独推一次删除再推一次新分支，或者在推送时留意提示。删除分支时，未合并的分支会被拒绝删除，IDE 会提示你该分支还有未合并的提交，这时候要用强制删除。如果手滑删了一个还有用的分支，别慌，用 Reflog 能找回来，这一点在第 6 节详细说。

4.2 Merge 还是 Rebase：在 IDE 里怎么选、怎么执行

这个选择题的答案取决于分支性质，不是个人偏好。我按场景给结论：

执行 Merge 的入口在分支面板里：先切到目标分支，然后在面板里选中要合进来的分支，选"合并到当前分支"。如果遇到冲突，IDE 会弹出冲突解决界面，处理完再提交。

执行 Rebase 的入口在同一个面板里，选中要变基到的分支，选"将当前分支变基到"。变基过程中如果每个提交都有冲突，会一段段停下来让你处理，处理完点继续。这个过程比合并累人，所以我一般建议在功能分支上频繁地做小规模变基，别等积累了三十个提交再一次性变基，那时候冲突会一层套一层，非常难受。

还有个常被忽略的配置：更新项目时默认用合并还是变基。这个可以在 Settings 的 Version Control 下的 Git 配置里设，对应到快捷键 Ctrl+T 的更新动作。团队里如果约定功能分支用变基、主分支用合并，把这个默认值配好，能省掉每次手动选择的麻烦。配错的表现是：你明明想变基，点了更新却发现多出一个合并提交。

4.3 分支面板做不到的事

不是所有分支操作都有界面入口。比如删除远端分支，面板里虽然有入口，但操作完远端引用不会立刻刷新，需要手动执行一次拉取或者清理才能看到变化。再比如给分支设置上游追踪，面板里能做但藏得比较深，我通常直接在终端敲git branch --set-upstream-to。

另一个盲区是多个工作区并行。Git 支持git worktree，可以同时检出多个分支到不同目录，这在需要一边跑测试一边改代码时特别有用。PyCharm 对 worktree 的支持是通过打开不同目录实现的，不算真正的集成，但能用。

5. 冲突现场：三窗格合并工具的逐行处理与验证

5.1 冲突到底在冲突什么

先把原理说透，后面操作才有依据。合并两个分支时，Git 会找到它们的共同祖先提交，然后比较"祖先到当前分支改了什么"和"祖先到目标分支改了什么"。如果两边改的是同一块区域的同一批行，或者一边改了一边删了，Git 就不知道该听谁的，把这块标成冲突，两边的内容都塞进文件里，用一串尖括号和等号分隔开，等人工裁决。

明白了这个模型，你就知道冲突不是"文件不同"，而是"同一位置的改动无法自动调和"。两个分支都改了同一个文件的不同位置，Git 是能自动合并的，压根不会找你。所以冲突文件数量多，往往说明两个分支分叉的时间太长，改动面重叠严重。减少冲突的根本办法是短分支、勤同步，而不是冲突出现后处理得多快。

冲突标记的样子是：一排左尖括号标记当前分支版本，一排等号分隔，一排右尖括号标记合进来的版本。这三段在 PyCharm 里被渲染成可视化界面，不用直接看这些符号。

5.2 三窗格编辑器怎么读、怎么点

双击冲突文件，或者从冲突文件列表里点进去，会打开合并编辑器。界面布局是三块：左边是本地版本，右边是外部版本，中间是合并结果，底部还有一个共同祖先版本。四个区域各有用处，缺一不可。

底部的祖先版本经常被忽略，但它才是判断该保留谁的依据。比如左右两边都改了一行，你需要知道原来是什么样，才能判断哪边的改动是修正、哪边的改动是覆盖。没有祖先视图，你只能靠猜。

中间的结果面板上方有三个按钮，分别对应"接受左侧""接受右侧""接受合并结果"。这里的措辞不同版本略有差异，语义是：全采用本地、全采用外部、采用你手工编辑后的内容。对于明显的场景，直接点前两个就够了；对于两边改动都要保留的情况，就得在中间手动编辑，把两段内容拼成想要的样子。

自动解决按钮也值得一用，它会对所有没有实质冲突的变更块批量应用合并，只留下真正需要判断的块。几十个冲突文件的时候，先用自动解决清掉简单的，剩下的手工处理，效率能差一倍。

有些冲突涉及整段方法的删除和新增，嵌套层级很深，肉眼看容易晕。这时候把编辑器的折叠和差异高亮都用上：折叠掉不相关的代码块，只留冲突区域展开，视野会清爽很多。

5.3 解决完之后的三道验证

冲突处理完不等于事情结束，实际翻车往往发生在"以为处理完了"之后。

第一道验证是标记已解决。在合并编辑器里点应用之后，文件会从冲突列表里消失，进入待提交状态。如果你直接在编辑器里手动删了冲突标记、保存关掉，但没有走"标记为已解决"这一步，Git 仍然认为这个文件处于冲突状态，后续提交会报错提示还有未合并的路径。这个坑非常常见，尤其是在编辑器里顺手改的时候。

第二道验证是全文搜索冲突标记。冲突块处理不干净、残留半截标记的情况时有发生，尤其是文件很大的时候。用全局搜索搜左尖括号连续七个字符，正常应该零结果。这一步我每次解决完冲突都会做，比事后测试报语法错误再回头找快得多。

第三道验证是跑一遍构建或测试。有些冲突表现为代码能编译但逻辑错了，比如两边各加了一个初始化调用，合并后变成调用两次。这种问题只有跑起来才能发现。合并完成后先本地跑一遍测试，再提交，这个顺序别颠倒。真要是合并提交推上去之后才发现问题，回退一个合并提交比回退普通提交麻烦得多。

注意：合并冲突期间不要执行拉取操作。Git 在合并未完成的状态下拒绝新的合并，提示信息通常很含糊，容易让人误以为是网络问题。

6. 追溯与救火：Log、Annotate、回退与误操作兜底

6.1 Log 面板不只是看提交记录

Git 工具窗口的 Log 标签页很多人只用来扫一眼提交列表，其实它是信息密度最高的面板。顶部的过滤框支持按作者、日期、提交信息、路径组合过滤，语法跟命令行参数类似。想查"某个文件在最近三个月内被谁改过"，把文件从项目视图拖进去或者直接输入路径前缀就行。

分支图那一栏值得展开说。勾选显示所有分支之后，你会看到彩色的线条交缠在一起，每个圆点是一个提交，线条分叉表示分支创建，线条汇合表示合并。看多了能一眼认出"这个分支是从三个月前的老提交拉出来的，一直没同步过主分支"，这类分支合并起来必然痛苦，提前预警。

右键菜单里的操作才是重点：Cherry-Pick 把某个提交摘到当前分支；Revert Commit 生成一个反向提交抵消某次改动；Reset Current Branch to Here 把当前分支指针移到选中的提交；还有前面提过的交互式变基。这些操作的入口都在右键里，用熟了比在命令行拼参数快。

6.2 Annotate：定位某行代码是谁在什么时候改的

编辑器左边行号区域右键，选"使用 Git 追溯注释"（有的版本叫 Annotate），每一行左边会显示最后一次修改它的提交信息和作者。把鼠标悬停在某个注释上，能看到完整的提交信息、时间、以及那次提交对这个文件的所有改动。

这个功能在排查问题时的价值极高。举个例子：某段逻辑突然开始报错，你怀疑是参数变了，用 Annotate 一查，发现这行是上周某个提交改的，点进去看那次提交的完整 diff，发现连带改了别的地方，问题一目了然。整个过程五分钟，比满仓库翻代码快太多。

进阶用法是"追溯上一次修改"。如果发现某行的改动是在做格式化，没有实质变化，可以继续往前追溯，一直追到真正改了逻辑的那次提交。多次追溯能画出这个文件的修改脉络，对于理解一段历史悠久的祖传代码特别有用。

再看一眼状态栏和编辑器提示：Annotate 视图是可以关掉的，右键选"隐藏注释"就回到正常编辑。有些人不小心打开之后不知道怎么关，一直带着一堆灰色小字写代码，体验很差。

6.3 三种回退方式的区别与选用

这是最容易出事的地方，因为三个操作的界面看起来差不多，后果差别巨大。

Reset 又分三种模式，IDE 在弹窗里会让你选：软重置只移指针，改动留在工作区；混合重置移指针并清空暂存区，改动留在工作区；硬重置移指针并丢弃所有改动，工作区回到目标提交的状态。硬重置是唯一一个会真正删掉你代码的操作，做之前务必确认目标提交选对了，且当前改动没有价值。

什么时候用哪个，我给个简单判断：只要这个提交别人可能已经拉走了，就只能用 Revert，绝不能用 Reset。判断依据很简单，看分支是不是公共分支，看提交有没有推送。拿不准的时候，先建一个临时分支指向当前位置，再操作，出问题还能切回去。

6.4 手滑之后的两层兜底

第一层兜底是 Reflog。Git 会记录每一次 HEAD 的移动，即使你硬重置到一个老提交、或者删掉了一个分支，那些提交对象在一段时间内仍然存在，只是没有分支指向它们。在 Git 工具窗口的 Log 面板里，分支下拉菜单里可以找到查看 Reflog 的入口，也可以在终端执行git reflog。找到误操作之前的那条记录，右键重置到那个位置，或者新建一个分支指向它，代码就回来了。

第二层兜底是 IDE 的本地历史。这个功能跟 Git 完全无关，是编辑器自己定期给文件拍快照，记录在项目配置目录里。哪怕文件从来没提交过、哪怕 Git 仓库被整个删了，本地历史依然能找回某天某个时刻的文件内容。入口在编辑器或项目视图的右键菜单里，选"本地历史"下的"显示历史"。我遇到过最离谱的一次事故是有人把整个源码目录清空了，Git 那边也没提交过，最后靠本地历史恢复的。这个功能建议所有人都知道它在哪，并且别把项目配置目录加进忽略规则之外的清理脚本里。

最后说个小技巧。团队协作里，提交信息和分支命名其实是低成本的沟通工具。分支名写成"fix/订单列表分页错乱"和写成"dev2"，三个月后你自己都想不起来 dev2 是干什么的。我现在的习惯是分支名带上类型前缀和一句短语，提交信息首行写清楚"做了什么"，正文写"为什么这么做"。这套习惯坚持下来，回头看 Log 面板的时候，它就不只是一堆哈希，而是一份能读的变更说明书。

我在实际使用中最大的体会是，PyCharm 的版本控制功能真正的价值不在于省掉几个命令，而在于把"状态"可视化了。哪些文件改了、哪些提交没推、哪些冲突没解、当前在哪个分支，这些信息在命令行里需要反复敲命令确认，在界面里一眼就能看到。把这份可见性用好，比记住多少个快捷键重要得多。