00:00:00大家好，我是 Scott，GitButler 的首席执行官。
00:00:02今天我将带大家了解 GitButler 的一些酷炫功能，
00:00:05并简要概述这款 Git 客户端的功能。
00:00:07我这里有一个示例项目，一个模仿 Twitter（或 X）的小应用，我叫它 Y。
00:00:12接下来我会添加一些预先做好的修改，然后我们一起看看
00:00:16如何创建提交（commit）、创建分支、创建并行分支，以及
00:00:20如何创建堆叠分支（stacked branches）。如果我编辑一些文件，你会看到
00:00:25类似于 Git status 的输出，显示工作目录中哪些文件被修改了。
00:00:30你想怎么处理这些文件？如何提交它们？在这里我们可以检查它们。
00:00:34我可以查看 application.css、sidebar、index，对吧？我做了一些小改动。
00:00:39我想做的是创建一个新分支，并将这些更改提交到该分支。
00:00:45这里有几种不同的操作方法。我可以点击这个“提交到新分支”，
00:00:49或者在这里明确地创建一个新分支，我要创建一个独立的分支，
00:00:54而不是依赖分支。我们一会儿再聊堆叠分支。
00:00:57给它起个名字，创建分支，现在你可以做几件不同的事情。
00:01:03你可以直接提交一些东西，比如我可以只提交这个 application.css 文件，
00:01:08方法是把它拖到泳道（lane）里创建提交，或者直接从这里开始提交。
00:01:15你可以在这个小框里写简短的提交消息，也可以把它展开，
00:01:19在这里写一段内容丰富的长消息。我们先简单点。另一件可以做的事是，
00:01:27我可以决定哪些内容进入这次提交。侧边栏这里有三个文件。我不但可以说
00:01:34我不需要某个特定的文件，还可以进入文件并选择只要特定的几行，对吧？
00:01:39不过现在，让我们提交所有的更改。或者，我们干脆分两次提交。
00:01:44我不想在这次提交里处理侧边栏，所以这次叫“前端修复”，
00:01:48然后我再做一次“侧边栏修复”的提交。现在这个新分支有两个提交了。
00:01:55我有点偷懒，所以我要用 Claude Code 来帮我干活。我要把主题
00:01:59从蓝色改成红色，然后看看如何添加一个独立于前端修复的
00:02:04新分支。看起来完成了。这是网站之前的样子，
00:02:09有点像 Twitter。如果我现在应用这些更改，整个色调就变成了红色，
00:02:14我的前端更改也完成了。你可以看到这些其实是独立的分支。
00:02:18如果我说取消应用“前端修复”堆栈，虽然它还是红色的，但我这里有了这个。
00:02:25这就是我刚才的操作。我可以把它放回去，现在它不见了。或者同理，
00:02:34我可以取消应用红色主题，现在它就不红了。我们把它放回去。现在我们有两个不同的分支。
00:02:43酷的地方在于，如果我把这些推送到 GitHub，
00:02:48这些更改是相互分离的，但它们又是同时被应用的。
00:02:52这就像 Git 分支，不同的是你可以同时处理多个分支。
00:02:57如果我继续在侧边栏做些工作，就会在这里看到。我可以
00:03:04做很多操作。我可以把它拖进这里来修正（amend）这个提交。
00:03:10我也能把它作为该分支上的一个新提交。现在我们有了这两个并行的分支。
00:03:14让我们看另一种操作方式。假设红色主题
00:03:18依赖于我们在前端所做的更改。所以我真的
00:03:24想先合并前端内容，然后再处理红色主题，或者把它们全部合并。
00:03:29我们撤销这次提交。我们取消提交，改为使用堆叠分支。
00:03:37取消提交，取消应用堆栈。现在我们要在这里添加一个新的依赖分支。
00:03:42点击“创建新分支”，添加依赖分支。你也可以这样做：
00:03:47点击“在此处创建依赖分支”，并添加堆叠的“前端修复”，命名为
00:03:51sc_red_theme。现在你可以看到这些分支是堆叠在一起的。我可以把这个
00:03:58提交到这里。现在如果你有了这些堆叠分支，你可以推送到 GitHub。
00:04:06推送这些非常容易。如果你设置了 GitHub 集成，你还可以
00:04:11创建拉取请求（PR）。如果我创建一个名为“红色主题”的 PR，
00:04:16因为这是一个堆叠分支，它会在 PR 描述中注入一个页脚，说明
00:04:20此分支实际上依赖于它所指向的另一个分支。你需要
00:04:25要么一起合并，要么在红色主题之前先合并前端修复。但这是
00:04:30处理这类堆叠分支的一种非常优雅的方式。如果我现在看这个 PR，它会
00:04:34将这两个链接在一个堆栈中。这是堆栈的第二部分，那是第一部分，
00:04:39它们相互依赖。另一件很酷的事情是，你可以进行
00:04:43所谓的“分配到分支”。在这个例子中，我有两个泳道，三个分支。其中两个
00:04:48是堆叠的，一个是独立的。当我开始进行更改时，我可以分配
00:04:54代码块（hunks）。我可以将更改分配给特定的分支并继续工作。这就像是
00:05:00每个泳道都有自己独立的暂存区（staging area）。如果你运行 git add 并在 Git 中
00:05:05暂存更改，这与之类似，只不过你可以拥有多个独立的暂存区。
00:05:09我们来试一下。我要添加一个新功能，在管理页面添加一个小版块。
00:05:14我再次在同一个工作目录中把它放在自己的分支里，
00:05:19这是一个独立的分支，不属于堆栈，我可以专门为这些更改开启一个 PR。
00:05:24好的，这是之前的管理仪表板。我做了一些改动，加入了一些最近的
00:05:31注册信息。我有这两个更改，我想做的是把它们分配到
00:05:37这个泳道。如果我接着做更多改动，如果它无法识别，它会把改动放入“未分配”。
00:05:43如果属于同一个代码块，它会自动将其保留在分配好的
00:05:47泳道中。我们在 admin 控制器里做些修改。只是个无聊的注释，但
00:05:55来看看效果。我们可以看到，既然 admin 控制器已经分配到了这个泳道，
00:06:00我就不需要一直手动暂存。它会自动识别：这其实也是该更改的一部分，
00:06:05并把它放进去。好，让我们为此创建一个新提交。我再次
00:06:10开始提交。我也可以展开它，写一段很棒的提交消息。我还可以使用 AI 来
00:06:15生成提交消息，如果你需要一个起点并可以在此基础上进行编辑的话。
00:06:19它会根据你所做的差异分析，至少给你一个起点。好，
00:06:23现在我们在新注册管理页面有一个提交了。侧边栏这里有
00:06:27那个堆叠分支，我同样可以独立推送并为此创建一个 PR。如果
00:06:31我这么做了，然后去查看这个 PR，我们会发现，尽管所有这些更改
00:06:37都同时存在于我的工作目录中，但它已将它们分成了不同的
00:06:42分支。所以我可以点进去只看这个管理页面的改动。显然它只编辑了
00:06:48管理页面，并将其保留在自己的分支和提交中，而没有与
00:06:55我工作目录中的其他工作混合在一起。那些都被保存在独立的分支里。
00:06:58这就是在 GitButler 中使用并行分支和堆叠分支的好处。
00:07:02好了，有很多在普通 Git 中很难实现的操作，在这里都非常简单，
00:07:06我给你们展示几个。首先，我们可以在分支之间移动提交。
00:07:11如果我想把这个“新注册”提交移动到红色主题
00:07:15提交中，我只需要拖放它，然后就可以删掉这个堆栈。现在我的
00:07:20提交就在这边了。如果我想压缩（squash）提交，我可以拖动这个提交，
00:07:26不仅可以拖到它下面的一个，还可以拖到堆栈中的任何其他提交上。所以我可以
00:07:30把这个管理页面的内容往下拖，放进侧边栏修复里，或者直接移动位置，对吧？
00:07:36我可以把它移到堆栈的更深处，或者把它压缩进另一个提交。现在你可以看到
00:07:41管理页面的内容也包含在侧边栏修复中了。我们也可以反过来，拆分一个提交。
00:07:47方法是添加一个空提交，然后将更改移动到该提交中。
00:07:52这样做的话，我可以在堆栈的任何位置添加空提交，这里我加在下面。我可以
00:07:58现在写提交消息，也可以先把文件移进去。让我们看看所有这些文件。
00:08:02这里有管理控制器和侧边栏的东西。我们把这个 admin index 拖到
00:08:08中间这个提交里。现在这个提交只有 admin index，侧边栏修复里
00:08:13仍然有其他文件。管理控制器和侧边栏。我也可以只移动
00:08:20代码块。现在这个提交包含一部分侧边栏修复，而另一个提交包含
00:08:30侧边栏修复的其余部分。之后如果我想的话，我可以修改提交消息。
00:08:34这引出了另一件事，就是编辑提交消息非常容易，对吧？除了
00:08:41调整顺序、压缩或拆分提交，我还可以随时回来，
00:08:46比如把它改成“第二部分”。它会自动变基（rebase）其上的所有提交。
00:08:53另一个有趣的功能是原地编辑提交，我们有几种快速的方法可以做到这一点。
00:08:57假设有人给我反馈，说不要把上边距设为 0，而是要设为 10 像素之类的。
00:09:01那么，如何编辑一个不仅是四个提交之前、而且还在另一个堆栈中的提交呢？
00:09:06事实证明，使用 GitButler 这非常非常容易。让我们去实际操作一下。
00:09:13好的，它在这里，我们把它改成 10 像素。内联 CSS 是最棒的。这是我在这儿
00:09:16做的更改。它被锁定了，因为我们正在编辑一个已经被编辑过的代码块，所以它必须
00:09:23进入这个分支的某个位置。我们不能把它放在单独的并行分支里，这就是
00:09:28我们判断的方法。但该怎么做呢？最简单的方法就是直接选中这个文件，
00:09:32然后把它拖进这个提交里。现在如果我们看这个提交，里面已经有 10 像素的改动了，
00:09:39我们修改了它，并将剩下的提交都在此基础上重新变基。另一种方法
00:09:46我们当然已经见过了，就是先把它提交到一个临时提交里，
00:09:51然后直接把它压缩到目标提交中。这基本上达到了
00:09:55同样的效果。如果我们再次查看，边距现在是 10 像素了。
00:10:02最后一种有趣的方法是使用“编辑模式”。假设我们刚才什么都没做，
00:10:07这里还是 0 像素，我们想编辑它。我们可以直接进入具体的提交，
00:10:12然后点击“编辑提交”。点击“编辑提交”后，会发生一件很有趣的事情。
00:10:20这有点像 Git 执行“分离头指针检出”（detached head checkout），如果你操作过的话。
00:10:25它本质上是在那个状态检出该提交。你可以随心所欲地编辑它，当你退出
00:10:30该状态时，它会再次在其上变基所有其他内容。我们进去再次修改。
00:10:36它会显示文件已修改，你改动了这个文件，然后我们保存并退出。现在它再次
00:10:39变基了所有内容。我们可以看到，更改已经保存进去了。所以你可以
00:10:46直接编辑提交。你可以进行更改并修正提交，也可以进行更改、创建一个提交
00:10:52然后压缩提交。有许多不同的方法可以操作 GitButler 提交中的更改。
00:10:57最后我要给你们展示的是“操作历史”（operations history）。
00:11:01如果你用过 Git 的 reflog 之类的东西，就会知道这在 Git 中非常难处理。
00:11:05我觉得大家都有点怕那个，但在 GitButler 中你做的每件事都会保存在操作日志中，
00:11:10你可以查看时间线并回到过去的任何时间点。就是这个按钮，我们可以看到
00:11:15本次会话中所做的所有不同操作。我可以回到
00:11:21过去的绝对任何一点。如果我想回到我开始做
00:11:26这个 10 像素改动之前，我可以回到这里，看看这个，我能看到
00:11:30在我做那件事之前所做的更改。我甚至可以
00:11:37回到我们这次会话的最开始。它不能撤销的是
00:11:42推送到 GitHub 的内容。在这里我可以看到推送到 GitHub 的提交，它们被列为
00:11:47上游提交，但我正在回到我提交任何内容之前的状态。我甚至可以
00:11:52删掉这个分支并从头开始，但不管你做什么都没关系，甚至连那个撤销我都能撤销。
00:11:56如果我来到这里，还原那个还原快照，我们就回到了之前的状态。我们可以
00:12:01随时回到任何时间点。所以这很棒，你永远不必害怕做任何这些操作。
00:12:05如果你进入了某种奇怪的状态，或者你只是想回到 10 分钟前的样子，
00:12:11只需打开时间线，往回找，点击还原，就搞定了。好了，这就是
00:12:16GitButler 变基器、提交编辑器、并行分支以及堆叠分支的快速概览，
00:12:22所有这些都不需要其他工具就能轻松实现。去下载试试吧，在 Discord 告诉我们
00:12:26你的想法，祝使用愉快。
00:12:32这就是 GitButler 变基器、提交编辑器、并行分支以及堆叠分支的快速概览，
00:12:36所有这些都不需要其他工具就能轻松实现。去下载试试吧，在 Discord 告诉我们
00:12:41你的想法，祝使用愉快。