前阵子帮一个做了十来年 .NET 的朋友搭开发环境他之前用的是 SVN右键菜单里那套小乌龟图标覆盖、提交对话框、日志视图用得闭着眼都不会错。换到 Git 之后硬着头皮敲了两天命令行实在受不了又重新装回 TortoiseGit。结果安装包点下去不到三分钟就卡在一行红字上configure git.exe 无法识别到 git.exe path。后面还有更离谱的——中文语言包装了界面还是英文密钥生成了推代码还是提示没权限。折腾到凌晨一点他才意识到问题根本不在 TortoiseGit 本身而在于大多数人把它当成一个独立软件来装没搞清楚它其实只是长在 Windows 资源管理器上的一层外壳。这篇就把 TortoiseGit 从安装、配置到日常使用的完整链条拆开讲一遍重点是那些官方文档一笔带过、但实际一定会绊你一脚的地方安装顺序、git.exe路径识别、语言包版本匹配、SSH 密钥到底用 PuTTY 格式还是 OpenSSH 格式、提交与推送为什么是两步、切换分支时那个对话框的选项各代表什么以及图标覆盖层为什么就是不显示。适合刚接触 Git 的 Windows 用户也适合用了几年 SVN 正准备转过来、想找一个可视化过渡方案的人。看完之后你应该能独立把整套环境跑通并且知道每一步背后的原因而不只是照着点下一步。1. 搞清楚 TortoiseGit 到底是什么能省掉一半的排错时间很多人第一次装 TortoiseGit 时的心理预期是装一个 Git 客户端就像装一个编辑器或者一个压缩软件那样。这个预期一旦建立后面所有的困惑几乎都从这里衍生出来。真实情况是TortoiseGit 本体里几乎不包含 Git 的核心逻辑它是一个Windows Shell Extension外壳扩展附加在资源管理器的右键菜单、文件图标、属性页上真正干活的是背后的git.exe。1.1 它只是一层壳真正的 Git 在命令行那边理解这一点非常关键。你右键点Git Commit - masterTortoiseGit 做的事其实是拼一条git commit命令调用系统的git.exe执行再把返回结果解析成图形界面上的文字。合并、变基、克隆这些操作也是一样的逻辑。也就是说TortoiseGit 是一层翻译把你在界面上的点击翻译成命令把命令的输出翻译成图形。这就解释了那个让无数人卡住的报错——configure git.exe 无法识别到 git.exe path。因为它找不到那台发动机界面再漂亮也跑不起来。同理你在 TortoiseGit 里做的所有配置最终都会落到 Git 自己的配置文件里全局配置写到用户目录下的.gitconfig仓库级配置写到仓库里的.git/config。你在 TortoiseGit 设置里改的user.name和你在命令行敲git config --global user.name改的是同一个东西。认识到这层关系很多为什么这里改了那里没变的疑问就自动消失了。1.2 什么场景该用图形界面什么时候该回到命令行我不太赞成图形界面是菜鸟、命令行才是高手这种说法这属于把工具当身份。更实际的判断标准是操作是否高频、是否可视化收益大。看日志、比对差异、看某一行代码是谁在哪次提交里改的、解决冲突——这些操作图形界面优势巨大TortoiseGit 的日志视图和 TortoiseGitMerge 冲突编辑器用起来比命令行的git log --graph和手改冲突标记舒服太多。但像批量重写历史、复杂的 cherry-pick 序列、脚本化的自动化流程命令行反而更快更可控。我自己的习惯是日常提交切换分支用右键菜单一旦涉及多个仓库的批量操作或者要看清楚每一步发生了什么就切回命令行两边共用同一套配置和同一个仓库切换零成本。1.3 顺带说清楚版本号这件事TortoiseGit 的版本号是跟着 Git 的节奏走的比如 2.15 系列、2.16 系列。这里的坑在于主程序版本和语言包版本必须严格一致2.15.0 的主程序配 2.15.0 的语言包差一个小版本都可能出现语言包装上了但界面还是英文的情况。这一点后面第 3 节会展开但你在下载页面就该先记住这个规则主程序和语言包从同一个发布页面下载别去别处单独找语言包。2. 安装顺序和那个 git.exe 报错是新手的第一道坎先把结论放在最前面永远先装 Git for Windows再装 TortoiseGit。顺序反过来TortoiseGit 在安装时会去探测系统里的git.exe探测不到就会卡在配置页面让你手动指路即便你后来补装了 Git某些情况下 TortoiseGit 也不会自动重新识别需要你手动去设置里改。2.1 正确的安装顺序以及每一步该注意什么先到 Git 官网下载 Git for Windows 的安装包装的时候有个选项叫Adjusting your PATH environment选默认的Git from the command line and also from 3rd-party software这一步会让git.exe进入系统 PATHTortoiseGit 才能顺藤摸瓜找到它。装完 Git 之后打开命令行敲git --version能打印出版本号才说明 PATH 配好了。这一步别跳过这是后面所有问题的分水岭。再装 TortoiseGit 主程序。安装过程中它会自动探测git.exe路径正常情况下你什么都不用填一路下一步即可。如果它探测到了并且显示了路径说明前面的顺序对了。最后装语言包如果需要中文界面。注意语言包是独立的一个 MSI 安装包装完之后还要在设置里手动切一次语言不会自动生效。我用一个表格把这几步的常见失误列出来方便对照步骤常见失误后果装 Git for Windows安装时选了 Use Git from Git Bash onlygit.exe不进 PATHTortoiseGit 找不到验证git --version跳过这步直接装 TortoiseGit报错后不知道是 Git 的问题还是 TortoiseGit 的问题装 TortoiseGit路径指向 Git Bash 内部的 sh.exe 而不是 git.exe无法识别装语言包语言包版本和主程序不一致界面仍是英文2.2 git.exe 报错出现后我是这样一步步定位的假设你已经踩坑了右键弹出 TortoiseGit 的对话框里面写着configure git.exe 无法识别到 git.exe path。别急着重装按下面这条链路走一遍基本都能解决。第一步先确认系统里到底有没有git.exe。打开命令行敲git --version。如果能打印版本号说明 Git 装了、PATH 也配了问题在 TortoiseGit 这边的探测环节如果提示不是内部或外部命令那就是 Git 本身没装好或者 PATH 没配上得先解决这个。第二步打开 TortoiseGit 的设置。路径是在任意空白处右键 -TortoiseGit-Settings左侧选General右侧有个Git.exe Path的输入框。正常情况下这里应该是空的表示走 PATH 探测如果它被你之前填过什么奇奇怪怪的路径先清空。点一下旁边的Check now按钮让它重新探测成功的话会显示检测到的 Git 版本号。第三步如果自动探测还是失败就手动指路。在 Git 安装目录下找cmd\git.exe或者bin\git.exe注意别选到usr\bin\git.exe那个是 Git Bash 内部用的路径TortoiseGit 不一定认。常见的路径长这样C:\Program Files\Git\cmd\git.exe。第四步如果路径都对上了还是不行检查一下是不是装了两份 Git比如既通过安装包装了一次又通过某个包管理器装了一次两个版本互相打架。这种情况在where git命令下会同时列出两个路径需要清理掉其中一个。提示设置对话框里的Git.exe Path建议保持为空让它走系统 PATH。只有在你确实装了多份 Git、需要指定某一个特定版本时才手动填写绝对路径。手动写死路径的坏处是以后升级 Git 换了目录又得重新改一遍。2.3 32 位和 64 位这个隐藏变量还有一个不太容易注意到的点TortoiseGit 和 Git for Windows 的位数最好保持一致。现在基本都是 64 位了但如果你从某个老旧的软件站下载了一个 32 位的 TortoiseGit而系统里装的是 64 位的 Git探测环节偶尔会出问题。下载时认准官网正版页面选对 64-bit 版本这是最省事的做法。另外从非官方渠道下载的安装包可能被塞了额外的推广组件装完之后资源管理器里多出一堆图标覆盖层反而会把 TortoiseGit 的状态图标挤掉——这个在第 7 节讲图标覆盖时会再提到。3. 中文包装了界面还是英文几乎都是版本号在捣乱这个问题在搜索里的热度一直很高我遇到的案例里九成以上都是语言包和主程序版本不一致导致的。TortoiseGit 的语言包不是那种一个包通用所有版本的翻译文件它是按主程序版本单独打包的字符串资源里对得上号才行。差一个小版本界面上就会出现一半中文一半英文甚至完全没反应。3.1 版本号必须严格对齐判断方法很简单打开TortoiseGit-About或者在资源管理器右键菜单里找看主程序的完整版本号比如2.16.0.0。然后去看语言包文件名比如TortoiseGit-LanguagePack-2.16.0.0-64bit-zh_CN.msi。这两个数字必须一模一样2.16.0.0就得配2.16.0.0不能配2.15.0.0。如果你手上已经主程序是 2.16但只找到了 2.15 的语言包那要么升级/降级主程序到匹配的版本要么继续用英文界面等新版语言包发布。不要抱着试一下说不定能用的心态硬装装上去的后果是界面语言混乱还得卸载重来。3.2 语言装好之后还要手动切一次这是第二个让人误以为语言包不生效的原因语言包安装完成后TortoiseGit 的界面语言不会自动变需要手动切换。操作路径是在桌面或文件夹空白处右键 -TortoiseGit-Settings。左侧选General。右侧找到Language下拉框选择中文(简体)或者Chinese (Simplified)。点Apply再点OK。切完语言之后有些菜单项要等你下一次右键才会刷新别以为没生效就重复切换。如果切换下拉框里根本找不到中文选项那说明语言包没装成功回到 3.1 检查版本号。3.3 切换了还是不生效的几种情况装到了错误的用户目录语言包默认装在 TortoiseGit 的主目录下如果你当初把 TortoiseGit 装到了一个非默认路径语言包可能装到了默认路径两边对不上。卸载语言包重新指定同一个目录安装即可。权限不足导致资源没写入某些受限账户下安装 MSI 时没有管理员权限文件写了一半。用管理员身份重新运行安装包。系统里有多份 TortoiseGit和 Git 的情况一样装了两份右键菜单指向的是另一份没有语言包的实例。检查控制面板的程序列表卸载多余的。注意语言包只管界面显示不影响 Git 的任何行为。你切换语言的时候仓库里的提交记录、分支名、配置文件一点都不会变所以放心切。4. 第一次克隆之前这几个配置必须先定下来装好之后很多人第一件事就是 clone结果遇到各种权限和身份问题。其实在克隆之前有四个配置项应该先确认它们决定了后面每一次提交和推送能不能顺利进行。4.1 用户名和邮箱全局和仓库两级Git 的每一次提交都会记录作者信息这个信息来自user.name和user.email两个配置。它们分两级全局对所有仓库生效存在用户目录的.gitconfig和仓库级只对当前仓库生效存在仓库里的.git/config。TortoiseGit 的设置界面里Git这一栏下就能直接改这两个值。在设置界面里你会看到一个Local和Global的切换选项。建议的做法是先把 Global 设成你个人的常用身份然后在公司项目这种需要区分工作邮箱的仓库里单独设一次 Local 覆盖它。# 命令行里对应的两条命令效果和界面里改完全一样 git config --global user.name 你的名字 git config --global user.email youexample.com # 在某个仓库里单独设置覆盖全局 git config user.name 公司用的名字 git config user.email youcompany.com写完 commit message 之后提交记录里作者是谁就由这个决定。如果设错了提交记录里就会挂着一个错误的名字改起来很麻烦需要重写历史所以第一次配的时候务必仔细。4.2 SSH 密钥PuTTYgen 格式和 OpenSSH 格式别混这是 TortoiseGit 相比纯命令行最特殊、也最容易搞混的一点。Git for Windows 自带的是 OpenSSH密钥默认放在C:\Users\你的用户名\.ssh\下面比如id_rsa私钥和id_rsa.pub公钥。而 TortoiseGit 默认使用的是 PuTTY 那一套工具密钥格式是.ppk两者不通用。你有两条路可以走路线一全程用 TortoiseGit 自带的 PuTTYgen 生成 .ppk 密钥。在开始菜单里找到TortoiseGit文件夹下的PuTTYgen点Generate然后在窗口里不停晃动鼠标产生随机数生成完成后把公钥文本复制出来贴到代码托管平台的 SSH Keys 设置里再点Save private key保存成.ppk文件。然后在 TortoiseGit 的Settings-Network里指定这个私钥文件。路线二沿用命令行的 OpenSSH 密钥让 TortoiseGit 也用 OpenSSH。在Settings-Network里把SSH client那一栏指向 Git for Windows 自带的ssh.exe常见路径是C:\Program Files\Git\usr\bin\ssh.exe。这样 TortoiseGit 就会用和命令行一样的密钥和配置两边行为完全一致。我个人推荐第二条路。理由是现在大多数平台上ssh-keygen生成密钥的教程都是 OpenSSH 格式一致起来省得维护两套密钥。而且如果你同时在用命令行和 TortoiseGit两套密钥意味着两个公钥都要往平台上贴很容易搞混哪把是哪把。对比项PuTTY 路线.ppkOpenSSH 路线密钥生成工具PuTTYgenssh-keygen私钥格式.ppkid_rsa 等TortoiseGit 配置Network 里指定 ppk 文件Network 里指定 ssh.exe 路径与命令行一致性低两套密钥高共用一套4.3 凭据缓存HTTPS 方式下的密码保存如果你用的是 HTTPS 地址克隆地址以https://开头每次推送都会问你用户名密码。TortoiseGit 会调用 Windows 凭据管理器来缓存但有时候会出问题比如公司改过一次密码旧凭据还缓存在里面推送就一直失败但也不提示让你重新输入。这时候打开 Windows 的凭据管理器在开始菜单搜索即可找到Windows 凭据那一栏把和代码托管平台相关的条目删掉下次推送时会重新弹窗让你输入。这一步很多人不知道白白卡在认证失败上半天。4.4 换行符和大小写跨平台协作的两个隐形雷如果你的项目有 Mac 或 Linux 的同事一起开发换行符的问题几乎躲不掉。Windows 用 CRLF 换行Linux 和 Mac 用 LFGit 如果不做处理就会出现我只改了一行diff 却显示整个文件都变了的诡异现象。TortoiseGit 的Settings-Git里有一个AutoCrlf的选项建议团队统一约定一般跨平台项目推荐true或者用仓库里的.gitattributes文件统一指定。这个不展开讲但你要知道它存在遇到全文件 diff 时先怀疑它。大小写是另一个雷。Windows 的文件系统默认不区分大小写Git 默认也是不区分的。如果你把一个文件从Utils.js改名为utils.js在 Windows 上可能看起来文件没变Git 也不认为有改动但推送到只识别大小写的服务器上就会出问题。设置里把core.ignorecase关掉可以规避。5. 克隆、提交、推送右键菜单到底该点哪一项界面上菜单位置看着多其实日常高频的就这么几个。把这一节的手感练熟你就已经能完成 90% 的日常工作。5.1 克隆仓库地址和目录两处最容易错右键菜单里找Git Clone...弹出的对话框里两个字段最关键URL和Directory。URL 就是仓库地址SSH 或 HTTPS 都行前面密钥配好了用 SSH 更省事Directory 是本地存放目录注意 TortoiseGit 会在你选的目录下面再建一层以仓库名命名的文件夹如果你选的目录本身就带仓库名就会出现套娃目录。对话框里还有几个选项Depth是浅克隆深度一般留空做完整克隆Branch可以指定克隆后检出哪个分支留空就是默认分支。克隆大仓库时如果你只想要最新的一次提交、不需要完整历史可以填Depth 1能省下大量时间和磁盘空间代价是看不到历史记录、也不能直接切到很久以前的分支。5.2 提交和推送是两步不是一步这是从 SVN 转过来的人最容易困惑的地方。SVN 的提交是一步到位直接推到服务器。Git 是分布式Commit先把改动记录到本地仓库Push才把本地的提交上传到远程。中间隔着这一步好处是你可以离线提交很多次、整理好之后一次性推送坏处是新手经常以为自己提交了其实只是本地记了一下。日常流程一般是改完文件右键 -Git Commit - 当前分支名...。弹出的窗口上半部分是文件列表勾选你要提交的文件不勾的就不会进这次提交。下半部分写提交说明写清楚这次改了什么、为什么改。点Commit改动进入本地仓库。再右键 -TortoiseGit-Push...选择目标远程和分支点确定上传到服务器。提示提交说明不要写修改更新fix这种没信息量的词。半年后你自己回头看 log 的时候会感谢现在写清楚的自己。5.3 拉取Pull 还是 Fetch MergePull其实是Fetch Merge的组合一步到位把远程最新代码拿下来并合入当前分支。方便但有风险如果你的本地改动和远程冲突Pull 会直接进入冲突状态你可能一脸懵。更稳妥的做法是分两步先Fetch在 TortoiseGit 菜单里或者右键 -TortoiseGit-Fetch它只把远程的最新状态拉到本地的远程跟踪分支不动你当前的工作区。然后打开日志视图看看远程比本地多了哪些提交判断能不能直接合。确认没问题再Merge或者Pull。多花十秒钟看一眼能避掉很多这次合并到底合了什么的焦虑。5.4 日志和差异定位我到底改了什么右键 -TortoiseGit-Show Log打开的就是日志视图。这个界面是 TortoiseGit 最值钱的部分几件事都能在这里做上半部分是提交列表选中某一条下半部分显示这次提交涉及的文件。双击某个文件直接和上一版本对比差异改了什么一目了然。在提交列表里右键某一条可以Revert撤销这次提交、Cherry Pick把这一个提交摘到当前分支等。最上面有分支筛选和搜索框可以按作者、按提交说明搜索。找这个函数是哪次提交引入的这类问题时特别好用。工作区里还没提交的改动直接右键文件 -TortoiseGit-Diff就能看。如果装了第三方 diff 工具比如 Beyond Compare可以在设置里挂上比内置的更好用。6. 分支切换、合并、冲突热搜里问得最多的三个动作分支是 Git 的核心也是从 SVN 转过来的人最不适应的地方。好消息是 TortoiseGit 把这块做得相当直观只要理解对话框里每个选项的含义操作起来很稳。6.1 Switch/Checkout 对话框里的选项到底是什么意思右键 -TortoiseGit-Switch/Checkout...弹出的对话框有几个关键区域Branch下拉框列出本地已有分支选一个就是切过去。Create New Branch的勾选框勾上并填名字表示创建新分支并立刻切过去。Base On区域创建新分支时基于哪个起点。可以是当前 HEAD也可以是某个远程分支、某个 tag、某个具体的提交。这个起点选错了新分支就会带着一堆你不想带的提交。Orphan / Only display this branch之类的选项一般用不到除非你要创建一个完全独立历史的分支。新手最常犯的错是在有未提交改动的时候切换分支。Git 允许你在某些情况下带过去但一旦两边冲突就会切换失败。稳妥的做法是切换之前先把当前工作区要么提交要么暂存Git Commit窗口里有个 stash 相关的入口或者用TortoiseGit-Stash。养成切分支前先看一眼有没有未提交的东西的习惯能省掉很多麻烦。6.2 合并和变基什么时候用哪个Merge和Rebase是两个会让新手纠结的操作。简单说Merge 保留分叉的历史Rebase 把你的提交搬到目标分支的顶端历史变成一条直线。团队协作里如果分支已经推送出去了、别人可能基于它工作就不要 rebase因为它会改写提交哈希。个人的本地特性分支想整理出一条干净的历史rebase 是合适的。TortoiseGit 里Merge的操作路径是先切到目标分支比如你要把 feature 合进 master就先切到 master然后右键 -TortoiseGit-Merge...在弹出的对话框里选要合进来的那个 feature 分支。Rebase类似注意方向是把我当前分支的提交搬到另一个分支上面别搞反了。6.3 冲突解决的完整链路别怕按这个顺序来冲突是每个人都会遇到的它只是说明两个分支改了同一个文件的同一个位置Git 不敢替你决定保留哪个需要人来判断。解决流程如下合并或拉取后如果冲突TortoiseGit 会弹窗提示并在文件列表里把冲突文件标红。右键冲突文件 -TortoiseGit-Edit Conflicts打开 TortoiseGitMerge 工具。工具界面分几栏一边是本地的版本一边是远程的版本中间是合并结果。有冲突的地方会高亮你要选择保留哪一边、或者两边都保留并手动调整。逐处解决完保存文件关闭工具。回到资源管理器右键那个文件 -TortoiseGit-Resolved告诉 Git 这个文件冲突已解决。全部冲突文件都标记 Resolved 之后正常提交一次合并提交就完成了。注意解决冲突的时候别顺手把、、这些标记符号也提交上去。如果你的代码里出现了这些符号导致编译报错就是漏删了冲突标记。浏览器里搜一下这三个符号能快速定位。如果冲突解决到一半发现搞错了想回到合并之前的状态右键 -TortoiseGit-Merge里有一个 abort 相关的选项或者直接在日志视图里做 reset具体看你的情况。养成解决冲突前先确认自己在哪个分支、合并的是什么的习惯比出事后再补救轻松得多。7. 图标不显示、大文件误提交、分支删错这些坑我替你踩过了前面都是正常情况下的使用而实际项目里真正耗时间的往往是这些边角问题。这一节挑三个最典型的讲透。7.1 图标覆盖层不显示多半是被别的软件挤掉了你可能会遇到这个现象装了 TortoiseGit右键菜单有但文件图标上那些绿色对勾、红色感叹号就是不出来。这不是 TortoiseGit 坏了而是 Windows 的一个历史遗留限制系统最多只支持 15 个图标覆盖层Icon Overlay先注册的先占坑。如果你装了网盘客户端、云同步工具、压缩软件等它们也会注册覆盖层把名额用光了TortoiseGit 的图标就被排到后面显示不出来。解决办法有两个方向。一个是减少竞争者卸载或关闭那些不需要图标覆盖的软件很多软件在设置里可以关掉自己的覆盖层。另一个是调整优先级通过修改注册表里HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers下的项顺序在名字前面加空格可以让它排前面把 TortoiseGit 相关的项往前排。改注册表前记得先备份改完重启资源管理器任务管理器里重启explorer.exe才生效。顺带说一个观察这个问题在某些云盘同步目录里尤其明显因为同步软件的图标和 Git 的图标会互相打架同一个文件到底显不显状态、显哪个状态取决于谁占了坑。项目目录尽量不要放在这类同步盘里除了图标问题还有文件被同步过程锁住导致的 Git 操作失败。7.2 大文件或者密钥被提交进去了怎么救这个坑我踩过不止一次。场景通常是调试的时候往仓库里塞了个几百兆的数据文件或者不小心把.env、私钥这种敏感文件提交了。等推送的时候 TortoiseGit 报错说文件太大或者推送被拒绝你才发现。先说预防项目根目录放一个.gitignore文件把*.log、node_modules/、*.key、.env这一类通通写进去。TortoiseGit 的提交窗口里右键某个文件有加入忽略列表的选项碰到不想提交的文件直接加比手动编辑.gitignore还方便。再说补救。如果只是刚 commit 还没 push改起来简单在日志里右键那次提交 -Reset选 soft 模式保留改动回到暂存区把那个文件从暂存里取消掉重新提交一次。但如果已经 push 上去了就要用git filter-repo这类工具重写历史操作复杂且会影响所有协作者得提前沟通。# 从 Git 历史中彻底移除某个大文件需要在所有协作者都同步之后操作 # git filter-repo 需要单独安装比老的 filter-branch 快很多也安全很多 git filter-repo --path path/to/big-file.zip --invert-paths提示密钥一旦提交并推送过最稳妥的做法不是重写历史而是立刻去平台上把这个密钥作废、重新生成一把。历史里可能已经有别人的克隆副本了重写你也收不回来。安全问题上不要抱侥幸心理。7.3 分支删错了、提交丢了的找回方法分支删了不代表提交消失了。Git 里有个reflog它记录了 HEAD 的移动历史只要那次提交还在对象库里一般 30 天内都不会被真正清理就能找回来。TortoiseGit 的日志视图里可以切换到显示所有引用包括那些已经不在任何分支上的提交找到你要的那条右键基于它建个新分支就行。命令行下更方便git reflog会列出所有 HEAD 的移动记录找到你要的那一条记下它的哈希git checkout -b 恢复的分支名 哈希就回来了。TortoiseGit 的图形界面也能看 reflog在日志视图有个显示所有引用的开关只是不如命令行直观。我个人养成了一个习惯任何稍微危险的操作reset、rebase、删分支之前先记一下当前 HEAD 的哈希或者顺手建一个临时分支兜底。花五秒钟,省得事后翻 reflog 找半天。8. 一个能直接抄的日常节奏把上面的东西串起来用讲了这么多分散的点最后给你一个我每天都在用的操作节奏你照着走两三次就能形成肌肉记忆。每天开始工作前先Fetch一下看看远程有没有新提交如果有Pull 下来对齐。然后基于最新的主线创建一个特性分支命名上带个日期或者简短描述比如feature/login-0415。这一步是 TortoiseGit 里Switch/Checkout对话框勾选Create New Branch完成的。写代码过程中每完成一个小逻辑就提交一次提交说明写清楚这次做了什么。不用怕提交得碎本地提交不要钱后面推之前可以用 rebase 把碎提交合成有意义的几个。准备推送之前再 Fetch 一次如果主线有更新把自己的分支 rebase 到主线最新前提是这个分支只有你自己在用解决可能的冲突。然后 Push 到远程。如果团队用 Pull Request 流程在平台上发起合并请求等人 review。合并完成之后切回主线Pull 一下拿到合并后的代码把本地已经合过的特性分支删掉。删分支的时候别心疼前面说过 reflog 能救而且真正重要的是刚才那个合并请求里记录的内容不是本地那个分支名。我这套节奏用下来最深的体会是Git 的复杂度其实不在于命令本身而在于你要在脑子里维护一个本地、远程、当前分支、其他分支的状态图而 TortoiseGit 的日志视图恰好把这个状态图画出来了。多用日志视图少凭记忆猜当前处于什么状态出错的概率会降一大截。另外一点是别把图形界面和命令行对立起来它们操作的是同一个仓库、同一套配置你在哪边顺手就用哪边切换没有任何代价——真正要花时间掌握的是分支、提交、远程这三个概念之间的关系理解了它们用什么工具都是顺水推舟。
