企业官网建设流程全解析

git.exe 这东西，很多刚开始用 Windows 做开发的朋友第一次见到它，往往不是在 Git Bash 里，而是在某个 IDE 或者工具链的日志窗口中，比如热词里那个 "running command: c:\espressif\tools\idf-git\2.44.0\cmd\git.exe -c ..."。当时你可能一脸懵：我明明没装 Git 啊？这 exe 是从哪冒出来的？

其实 git.exe 就是 Git 版本控制系统的 Windows 命令行可执行文件，是整个 Git 在 Windows 平台上的“本体”。你平时输入的 git init、git add、git commit，本质上都是让这个 exe 去干活。它就好比一把瑞士军刀，既可以独立在命令行里使用，也会被集成到 IDE、自动化脚本、嵌入式工具链（比如 ESP-IDF）里，作为底层的代码管理引擎被反复调用。

这篇文章，我会从 git.exe 的来历讲起，把 Git 的命令行入门知识、Windows 下的常见坑、以及日常提代码的标准流程完整梳理一遍。无论你是刚装好 Git 不知道下一步干什么的新手，还是在 IDE 和命令行之间反复切换、经常踩到“git 无法识别”这类问题的老折腾，这篇都适合你。内容全部基于我这些年在本机环境里实际跑过的命令、掉过的头发和查过的文档，可以直接照着操作，不用再东翻西找。

1. Git命令行到底是什么——先弄懂git.exe这个文件

1.1 git.exe在系统里扮演什么角色

Git 本身是一个开源的分布式版本控制系统，诞生于 Linux 生态，所以它的原生界面其实是命令行。为了让 Windows 用户也能用，官方发布了 Windows 移植版，核心就是那个 git.exe。

你可以把它理解成“翻译官加执行者”：当你敲下git status，命令行工具会找到 PATH 环境变量里的 git.exe，把这个命令连同参数传给它，git.exe 再去读取当前目录下的 .git 文件夹，把仓库状态翻译成人能读懂的文本返回给你。

在没有图形界面时，git.exe 是唯一直接和仓库数据打交道的程序。像 TortoiseGit（俗称小乌龟）、VS Code 的源代码管理面板、JetBrains 系列 IDE 内置的 Git 插件，本质上都是通过调用 git.exe 来完成操作的，只是把输出结果包装成了按钮和对话框。

所以你会发现一个现象：电脑上明明没装那个绿色的 Git Bash，但某些软件仍然能执行 Git 操作，因为程序里内置了特定版本的 git.exe，或者安装了便携版（Portable Git）并注册到了特定路径。热词里的 ESP-IDF 就属于这种情况，它会自带一套 idf-git。

1.2 为什么很多工具会直接调用git.exe

这里要补充一个很多新手容易忽略的点：工具链直接调用 git.exe 时，常常会附带一堆“看起来很怪”的参数。

比如这条：

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

我来拆一下这些参数的含义：

• -c dff.mnemonicprefix=false：覆盖配置项，让diff输出不显示奇怪的前缀，兼容某些工具。
• -c core.quotepath=false：让中文文件名正常显示，而不是转成八进制转义序列。
• --no-optional-locks：告诉 Git 在执行只读命令时不要加锁，避免和其他 Git 进程互相等待。

这些参数平时在命令行里很少人手动敲，但 IDE 每次操作都会带上。理解了这一点，以后再在日志里看到类似的长命令就不会慌了，反而能一眼看出工具在用什么配置、做了什么操作。

我个人建议新手不要自己手动复制这种长命令去跑，容易因为路径引号问题出岔子。日常使用只要掌握后面要讲的几个基础命令，就已经覆盖了九成以上的场景。

2. 环境准备：Git安装、配置与命令行识别

2.1 下载安装时最容易踩的坑

去 Git 官网下载 Windows 版本，安装包里其实包含三个主要组件：git.exe（核心命令）、Git Bash（类 Linux 的终端环境）、Git GUI（简易图形界面）。大多数教程会让你一路默认下一步，但我建议在安装到“Adjusting your PATH environment”这一步时，务必选择中间那个选项：

推荐选项：Git from the command line and also from 3rd-party software

这个选择决定了你之后能不能在 CMD、PowerShell 里直接敲 git 命令。如果你选了“只从 Git Bash 里使用 Git”，那么打开普通 CMD 会提示“git 无法识别”，还得手动去配环境变量，白给自己找事。

另一个容易忽略的选项是行结束符处理（Line Ending Conversion）。Windows 用 CRLF，Linux/macOS 用 LF，Git 默认会帮你把仓库里的文件转成 LF、检出到工作区时转成 CRLF。如果你主要做前端、Python 这类跨平台项目，保持默认的Checkout Windows-style, commit Unix-style line endings就行。但如果你的团队有人用 macOS 或 Linux，且经常出现“明明没改过代码却一堆文件显示修改”的诡异情况，那就得统一改成提交时也保留 LF，或者在仓库里加一个.gitattributes文件来固定规则。

安装完成后，验证方式很简单，打开 CMD 或 PowerShell，输入：

git --version

能输出版本号，说明 git.exe 已经成功接入系统 PATH，安装环节搞定。

2.2 装完 Git 之后必须先做的三件事

很多人装完 Git 就急着 clone 项目，结果提交代码时报错提示Please tell me who you are。这是因为 Git 需要知道你是谁，才能给每次提交盖上“身份印章”。这一步没有配置的话，commit 会直接失败。

配置用户信息，两行命令搞定：

git config --global user.name "Your Name" git config --global user.email "you@example.com"

注意两点：第一，邮箱最好和你的代码托管平台（GitHub、GitLab、Gitee 等）注册邮箱一致，这样提交记录才能正确关联到你的头像和账号。第二，你还可以配置默认编辑器，因为某些场景（比如写 merge 提交信息）会弹出编辑器让你输入内容，不设置的话默认是 Vim，新手经常卡在不知道怎么保存退出。

git config --global core.editor "code --wait"

如果你装了 VS Code，可以像上面这样把默认编辑器设置成它，这样以后需要输入提交信息时，会自动打开 VS Code，写完保存关闭窗口即可。

还有第三件事，配置别名（alias），这能大幅提升日常效率。我常用的几个：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg "log --oneline --graph --all --decorate"

配完之后，git st就等于git status，git lg能输出分支树状的提交历史。命令行看起来更短，使用频率直接拉高。

2.3 命令行识别不了git，错误信息为什么各不相同

这是最经典的新手拦路虎。当你打开某个终端输入 git 却报错，按终端类型不同，报错文案也不一样：

问题本质都是同一个：系统在 PATH 环境变量里找不到 git.exe。解决步骤按顺序来：

1. 确认 git.exe 实际安装位置，多半在C:\Program Files\Git\cmd\git.exe或C:\Program Files\Git\bin\git.exe。
2. 在“此电脑”右键 -> 属性 -> 高级系统设置 -> 环境变量，找到 Path 变量，把上面的 cmd 目录加进去。
3. 重新打开一个终端，执行git --version验证。

我实测下来，很多人的问题不是没配置 PATH，而是配置完之后没有“重新打开终端”。环境变量的修改不会实时刷新到已运行的终端进程里，必须新开一个窗口才生效。这是新手最容易忽略的细节。

如果你用的是 VS Code 的内置终端，改完环境变量后需要完全关闭 VS Code 再重新打开，只关终端面板是不够的。

3. 日常使用Git命令的核心操作

3.1 本地仓库的初始化与提交

我们从一个常见场景出发：你刚拿到一个需求，要在本地新建一个项目，并用 Git 管理起来。操作步骤非常简单：

mkdir my-project cd my-project git init

git init会在当前目录生成一个 .git 隐藏文件夹，这个文件夹就是仓库的全部核心数据。从此以后，这个目录下的文件变动都会被 Git 追踪（前提是你还没有添加 .gitignore 忽略规则）。

接下来创建或修改一些文件后，想把这个状态“拍照”存下来，要执行两段式操作：

git add . git commit -m "初始提交：添加项目基础结构"

git add .是把所有改动从工作区添加到暂存区，相当于选中要拍照的内容；git commit才是真正按下快门，生成一条不可变的提交记录。为什么要分两步？因为有时候你改了一批文件，但只想把其中一部分纳入某次提交，保持提交历史的语义清晰。这种“用 add 选定范围再 commit 固化”的思路是 Git 的核心设计哲学之一。

提交之后想看看当前状态，用：

git status

这个命令会告诉你：哪些文件改了但没 add，哪些 add 了但没 commit，当前在哪个分支。我几乎每执行几步操作就会跑一次 status，用它确认自己没有搞错状态。

3.2 分支管理与合并——请务必养成这个习惯

分支是 Git 最强大的功能，也是让很多新手觉得“绕”的地方。你可以把它理解为平行宇宙：在 main 主线上稳定运行，在 feature/xxx 分支上开发新功能，两边互不打扰，等新功能测试通过再合并回来。

创建并切换分支的快捷命令：

git checkout -b feature/login

等价于两条命令：

git branch feature/login git checkout feature/login

在分支上完成开发后，提交代码，再切回主分支合并：

git checkout main git merge feature/login

合并时如果两边修改了同一个文件的同一处地方，Git 就会报冲突（CONFLICT），提示你手动解决。冲突发生时，文件里会出现类似这样的标记：

<<<<<<< HEAD 这是主干上的内容 ======= 这是分支上的内容 >>>>>>> feature/login

你需要手工编辑文件，决定保留哪部分，删掉<<<<<<<、=======、>>>>>>>这些标记行，然后再 add、commit。这是 Git 使用中最需要耐心的一环，但不可怕，多处理几次就有经验了。

如果你在工作中经常需要“临时去主干修个 Bug，但又不想把当前分支的半成品带过去”，可以先把改动暂存起来：

git stash

修完 Bug 切回来再取回：

git stash pop

这个命令组合在节奏紧张的开发日里堪称救命的，强烈建议上手练熟。

3.3 与远程仓库的交互

本地仓库讲完，下面说远程。这是团队协作的关键，核心命令不再是 init，而是 clone、push、pull。

最常见的开局方式，是从代码托管平台拉取一个已有项目：

git clone https://github.com/xxx/my-project.git

这个命令会自动创建以项目名命名的文件夹，初始化本地仓库，并设置好远程仓库地址（origin）。克隆之后，你就能在本地愉快地改代码了。

每天开始工作前，先拉取最新代码：

git pull

这个命令等价于git fetch加git merge，把远程的更新合并到当前分支。我个人的习惯是每次开工前先 pull 一次，避免本地分支和远程差太远，到提交时冲突成一片。

如果你是在本地初始化了一个仓库，想推到托管平台，需要先关联远程地址：

git remote add origin https://github.com/xxx/my-project.git git branch -M main git push -u origin main

这里解释一下：

• git remote add是给远程地址起了一个名字叫 origin，这是约定俗成的默认名称。
• git branch -M main是把当前分支重命名为 main，并强制覆盖同名分支（如果存在的话）。
• git push -u origin main是把 main 分支推到远程，并设置上游关联，以后可以直接用git push代替完整命令。

3.4 提代码的标准流程实操

我在团队里给新人演示提代码时，会推荐一个“三步走”的标准流程，这个流程能最大程度减少冲突和误操作。

第一步，拉取远程最新代码到当前分支：

git pull

如果你本地改了几个文件，pull 的时候偶尔会遇到“本地修改会被覆盖”的提示，说明远程也有人改了同一个文件。解决办法是先 stash 再 pull 再 pop。这个坑后面详说。

第二步，检查当前改动和准备提交：

git status git diff

git diff会逐行展示你改了哪些内容。这一步非常重要，很多人在最后提交时才发现自己把调试日志、临时配置文件也加了进来，全是因为没检查 diff。

第三步，添加、提交、推送：

git add . git commit -m "feat: 完成登录功能" git push

这三行是日常出现频率最高的组合。关于提交信息，请尽量写得具体、面向项目实际内容，比如“修复统计模块在空数据下的报错”就比“Update code”有价值得多，回看历史时能帮你省下大量时间。

4. Windows命令行场景下的Git使用技巧

4.1 在 CMD 和 PowerShell 里按分隔符输出、删除文件夹

Git 不是孤立存在的，它经常要和 Windows 原生命令一起工作。我在命令行里常用到几个融合场景，可以分享给同样在 Windows 下做开发的朋友。

比如你需要查看当前目录下所有文件名，并按某种分割方式逐行输出。PowerShell 下用dir /b（CMD 风格）或者Get-ChildItem（PowerShell 命令）都能实现：

Get-ChildItem | Select-Object -ExpandProperty Name

如果想把当前目录下的文件清单输出到文本，再逐个处理：

dir /b > filelist.txt for /f %i in (filelist.txt) do echo %i

在批处理文件里，变量前的百分号要写成两个，即%%i。这是 Windows 命令行最容易踩的格式坑。

再比如“命令行删除文件夹”，我经常在清理临时目录时用到：

rmdir /s /q node_modules

解释一下参数：/s是删除目录及其所有子目录和文件，/q是安静模式，不逐项确认。在 PowerShell 里更习惯用：

Remove-Item -Recurse -Force node_modules

这个命令经常出现在前端项目的依赖重装操作中。注意，删除操作不可恢复，执行前务必确认当前路径。我建议先pwd或者cd到明确路径下再执行，不要在自己都不确定在哪的目录里敲rmdir /s /q，那是灾难的开始。

还有一个高频场景：想快速删除一个目录，但目录名称里带了空格，比如git clone出来的项目叫my project。直接写rmdir my project会被识别成两个参数，正确写法是用引号包起来：

rmdir /s /q "my project"

4.2 命令行过长、隐藏窗口等特殊问题

在 Windows 上运行 Git 相关命令时，偶尔会遇到两个代表性报错。

一个是“运行 startapplication 时出错。命令行过长。”这类问题经常出现在把超长参数传给某些启动器时，比如执行带很多文件路径的 Maven 命令、Android 构建命令等。Windows 命令行的最大长度限制通常为 8191 个字符，超过后就会报错。解决办法通常是把命令拆短、通过配置文件传递参数，或者把工作目录切换到更浅的路径（路径越短，拼接出来的命令越短）。如果你在用 IDEA 或 Android Studio 这类 IDE，它们在启动打包任务时也会构造长命令行，遇到这个问题时先检查一下项目路径是不是嵌得太深了。

另一个是“运行 bat + 命令行 + 隐藏窗口”。有人希望用 Git 命令自动执行一些批处理，但不想弹出黑色命令行窗口。这个可以用 VBS 脚本来启动 bat：

Set shell = CreateObject("WScript.Shell") shell.Run "C:\path\to\your-script.bat", 0, False

0表示隐藏窗口，False表示不等待脚本执行完毕。保存为 .vbs 文件，双击执行就不会出现黑窗口。这个技巧在做定时备份、自动化部署脚本时特别有用。缺点是要多打包一个 vbs 文件，属于“能用但不够优雅”的方案。

4.3 Qt命令行、FFmpeg命令行等其他热词场景的启示

热词里还出现了“qt命令行”和“ffmpeg命令行精准裁掉片尾”，这些其实和 Git 没有直接关系，但它们的底层逻辑是一样的：命令行工具通过参数传递指令，工具本身把结果输出到标准输出流。

以 FFmpeg 为例，想要精准裁掉片尾，符合直觉但实际上是初学者的一个常见错误写法是简单地用-t指定总时长，比如原视频 10 分钟，你想裁掉最后 30 秒：

ffmpeg -i input.mp4 -t 09:30 -c copy output.mp4

这样出来的文件时长确实缩短了，但问题是时间基准不同。严谨的做法是先用-i查看总时长，再用-ss配合-to或者用-t精确计算，参数顺序也很讲究。这些细节和 Git 命令行里参数顺序影响结果一样，都是“差之毫厘，谬以千里”的典型。

命令行工具的学习曲线其实都是相通的：先搞懂“我输入的命令会被程序拆成哪几部分”，再理解“每个参数控制的逻辑”，最后在实践中不断调试。Git 命令行入门之后，再去学 FFmpeg、7z 这类命令行工具，都会快很多。

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

5.1 “git 无法识别”的排查顺序

这个报错前面已经说过，但我会把完整的排查顺序整理成清单，方便你对照处理：

1. 先确认是否真的装了 Git。打开“控制面板->程序->程序和功能”，搜 Git。
2. 确认 git.exe 路径。默认在C:\Program Files\Git\cmd\git.exe，注意是cmd目录而不是bin目录，两者都行，但cmd下的 git.exe 优先级更高。
3. 确认 PATH 环境变量里有没有对应路径。
4. 重新打开终端。重点排查点是，不要用之前开着的终端窗口，一定要新开。
5. 如果你在 IDE 里遇到这个错，确认 IDE 内置 Git 路径是否正确，以 VS Code 为例，在设置里搜git.path可以指定 git.exe 的绝对路径。
6. 如果以上都解决不了，再考虑克隆安装包进行修复安装。

这里还有一个安全相关的提醒：从网上下载 Git 安装包时，尽量认准官方镜像和知名镜像站。有些第三方文库或博客提供的“绿色版”链接已经失效，有些人会擅自打包上传，安全性无法保证。

5.2 登录失败：Login failed 类问题的处理思路

运行 Git 命令时提示 “login failed. check api token or gitlab version. log in via git if the version...” 这类问题，通常发生在 IDE 或者第三方 Git 客户端连接远程仓库时。

按我的经验，排查顺序是这样的：

第一，确认你是否用了 SSH 还是 HTTPS。如果用 HTTPS 且开启了二次验证（比如 GitHub 现在强制 token 登录），那密码框里填账号密码是必然报错的。你需要去托管平台生成一个 Personal Access Token，把它当作密码使用。

第二，确认远程地址是否正确。可以执行：

git remote -v

看看 origin 指向的地址是不是你想连的仓库。

第三，尝试在命令行直接执行git push，让 Git 自己弹出认证窗口。有时是 IDE 自带的认证组件和托管平台的新版本不兼容，绕到官方命令行反而能成功认证。

第四，如果你是自建 GitLab 且版本过旧，新生成的 token 算法可能不兼容，这种属于服务端版本问题，需要管理员升级 GitLab，客户端这边基本没有太好的绕过办法。

还有一个非常容易被忽略的原因：系统时间不正确。如果本机时间和真实时间相差太大，HTTPS 证书校验会失败，报错表现也是登录失败。遇到诡异的认证问题，先看一眼右下角时间对不对。

5.3 其他日常疑难杂症速查表

我把自己在多个项目里踩过、也被同事反复问过的问题整理成了速查表，方便你直接套用：

补充一点，关于“idea clone git 项目”报错的情况，很多时候是因为 IDE 里配置的 Git 路径不对，或者 IDE 自带的 JGit 实现与某个托管平台的协议差异导致的。绕开术很简单：在命令行里先 clone 成功，再用 IDE 打开项目即可。这样既避免 IDE 的网络栈问题，也方便你观察命令行输出的详细报错。

5.4 Git 免密配置与安全边界

热词里出现“git免密”，我建议优先使用 SSH 方式而不是把明文密码写进本地配置文件。

SSH 免密的核心思路是：生成一对密钥，公钥放到托管平台，私钥保留在本地。当你执行 Git 操作时，Git 会用私钥签名，托管平台用公钥验证，双方完成认证。

生成密钥的方式：

ssh-keygen -t ed25519 -C "you@example.com"

一路回车即可，默认会在~/.ssh/id_ed25519生成私钥，id_ed25519.pub是公钥。把公钥内容添加到 GitHub/GitLab 的 SSH Keys 设置里。之后 clone 时用 SSH 地址（git@github.com:xxx/xxx.git），就能实现免密操作。

这里特别提醒：SSH 私钥文件相当于你的数字身份，不要发给任何人，不要把它放进 Git 仓库里。如果你不小心把私钥提交到了公开仓库，请立刻在托管平台删除对应密钥并重新生成。这类事故造成的安全风险非常大，绝对不能轻视。

6. 从“会敲命令”到“理解这套体系”

学 Git 命令最忌讳的就是死记硬背。你会发现命令就那么几个，真正的难点在理解 Git 的数据模型：工作区、暂存区、本地仓库、远程仓库这四个概念是所有操作的地图。

• 工作区（Working Directory）：你当前能看到的、能编辑的文件。
• 暂存区（Index / Staging Area）：执行git add后文件进入的区域。
• 本地仓库（Local Repository）：执行git commit后记录生成的区域。
• 远程仓库（Remote Repository）：托管在平台上的共享版本。

大部分命令都可以映射到这四个区的流转上。git add是把工作区的东西搬进暂存区，git commit是把暂存区固化到本地仓库，git push是把本地仓库同步到远程，git pull则是反向拉取。有了这张地图，遇到git reset、git checkout这些命令就不会再懵了，因为它们本质上都是在不同区域之间移动内容。

我自己带新人时，通常先让他们对着这张地图反复操作 20 分钟：新建文件、add、commit、修改、再 add、再 commit、创建分支、回退、合并。不用背参数，操作一遍之后，肌肉记忆会帮你记住绝大部分。

另外一个值得养成的习惯是遇到不确定的命令先查帮助：

git help <命令> git <命令> -h

Git 的帮助文档本身写得非常清楚，特别是在 Windows 环境下，打开后是独立的帮助窗口，阅读体验比在线搜教程好很多。

7. 进阶话题：Git 与工具链结合的实战经验

回到开头那个 ESP-IDF 的例子。嵌入式开发工具链自动调用 git.exe，这件事其实揭示了 Git 在现代开发中的一个隐形身份：它不只是版本控制工具，更是大量自动化工具链的底层基础设施。比如：

• IDE 通过 git.exe 完成代码版本对比。
• 构建工具通过 git.exe 获取当前提交号，写进版本信息里（如git rev-parse --short HEAD）。
• 自动化部署脚本通过 git.exe 拉取指定 tag 的代码。
• 包管理工具用 git 协议直接安装 GitHub 上的依赖包。

这个视角很重要。当你把 Git 理解为“类似操作系统里文件系统那层的基础设施”时，就会明白为什么值得花时间把命令行用熟。图形界面工具在很多场景下很顺手，但到了自动化、批量操作、远程服务器登录后只能靠命令行的环境，Git 命令行是绕不开的。

在我自己的服务器管理工作中，几乎每次代码发布都会用到这几条：

git fetch --all git reset --hard origin/main git log -1 --oneline

先说git fetch --all，它会下载远程所有分支的最新提交信息，但不会改动你的工作区。然后git reset --hard origin/main把本地代码强制同步到远程 main 的最新状态。最后git log -1 --oneline确认当前部署的提交号。整个过程不用图形界面，在 SSH 终端里就能完成，速度极快，这也是命令行无法被替代的核心原因。

8. 常见报错场景：围绕“git.exe”的实测记录

为了让你更直观地理解 git.exe 在工作中的位置，我再录一段自己的实际排障经历。

有一次我用 VS Code 连接远程服务器调试代码，打开源代码管理面板，提示Git: not found。我第一反应是服务器上确实没装 Git，于是用 SSH 登录执行sudo apt install git装好。结果再次刷新 VS Code，还是报错。后来仔细看 VS Code 的 Remote-SSH 插件日志，发现它通过服务器上的某个路径找 git，但那个路径没在 $PATH 里。

解决方式是在服务器的~/.bashrc里加上：

export PATH=$PATH:/usr/bin/git

或者更通用的/usr/bin。然后重新连接 VS Code，问题消失。这个案例想说明，git.exe（Linux 上就是 git 可执行文件）能否被工具找到，很多情况下不是安装没装，而是“工具找它的路径”和“你默认的路径”不一致。

还有一次是 Windows 本机，我在 PowerShell 里执行 git 命令时突然每个命令都变慢，卡了几秒才出结果，报错提示访问某个网络位置超时。排查后发现是配置了网络驱动器映射，Git 在读取仓库时会扫描每个父级目录查找.git文件夹，如果网络驱动器路径不稳定，就会拖慢整个命令响应。解决办法是把仓库移到本地磁盘，或者在仓库内用git -C指定工作目录。这类问题在文档里很少被提到，属于实战才能碰到的坑。

9. 最后再分享一个提升效率的小技巧

如果你每天都要在 Git 命令行上花很多时间，我强烈建议你学习一下 PowerShell 的补全功能或安装一些开源终端增强工具。Windows 11 自带的 Windows Terminal 配合 PSReadLine，已经能实现不错的命令补全和路径提示。我自己日常的操作习惯是：

• 用 Windows Terminal 开一个标签页专门放仓库目录。
• 打开 Git Bash 作为默认 shell，因为它对 Linux 风格路径支持得最好，遇到文件路径里有空格的情况也不容易出错。
• 同时在 PowerShell 里配好git的别名和提示符，显示当前分支名，这样从终端一眼就能知道自己处在哪个分支，不会在多个分支之间切来切去时犯迷糊。

配置提示符显示当前分支，可以在$PROFILE里写一段简单的脚本，核心逻辑是执行git rev-parse --abbrev-ref HEAD获取分支名，再拼接到提示符上。初次配置会觉得麻烦，但配好之后便利性是实打实的。

在我个人多年的使用体会里，Git 命令行从来不是“落伍”的象征，恰恰相反，它是我在无数种开发环境里唯一确定存在、确定可用、确定行为一致的版本控制入口。你花在入门 Git 命令行上的那一两周时间，会在之后的使用中成百倍地赚回来。这次的 git.exe 之旅就分享到这里，希望对你能有一点实在的帮助。