00:00:00皆さん、こんにちは。GitButlerのCEO、スコットです。
00:00:02今日はGitButlerの魅力的な機能の数々をご紹介し、
00:00:05このGitクライアントで何ができるのか、全般的な概要を解説します。
00:00:07ここにサンプルプロジェクトがあります。Twitter（X）のクローンで、「Y」と呼んでいます。
00:00:12すでに行った変更をいくつか追加しながら、
00:00:16コミットやブランチの作成、並列ブランチ、そして
00:00:20スタックブランチ（積み上げブランチ）の作り方を見ていきましょう。ファイルを編集すると、
00:00:25「git status」の出力のように、ワーキングディレクトリで修正されたファイルが表示されます。
00:00:30それらをどうコミットしたいか、ここで確認できます。
00:00:34application.css、sidebar、indexなど、いくつか小さな変更を加えました。
00:00:39ここでやりたいのは、新しいブランチを作成して、これらの変更をコミットすることです。
00:00:45やり方はいくつかあります。「commit to new branch」を押すか、
00:00:49ここで明示的に新しいブランチを作成します。スタックについては後述しますが、
00:00:54まずは依存関係のない、独立したブランチを作成してみましょう。
00:00:57名前を入力してブランチを作成すると、いくつかのアクションが選べます。
00:01:03単にコミットすることもできます。例えば、このapplication.cssファイルを
00:01:08レーンにドラッグしてコミットを作成するか、ここから直接コミットを開始できます。
00:01:15この小さな枠で簡潔なメッセージを書くことも、展開して
00:01:19詳細なコミットメッセージを書くことも可能です。今はシンプルにしておきましょう。
00:01:27また、何を含めるかも自由に決められます。サイドに3つのファイルがありますが、
00:01:34特定のファイルを除外するだけでなく、ファイル内の特定の行だけを選ぶこともできます。
00:01:39今回は、すべての変更をコミットしてみましょう。いや、やはり
00:01:442つのコミットに分けましょう。サイドバーの修正はこのコミットには含めず、まず「フロントエンド修正」、
00:01:48次に「サイドバー修正」という別のコミットを作ります。これで新ブランチに2つのコミットができました。
00:01:55少し楽をしたいので、実際の作業にはClaudeを使います。テーマの色を
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これで2つの異なるブランチがあります。素晴らしいのは、これらをGitHubにプッシュしても、
00:02:48変更が分離された状態を保ちつつ、同時に適用されていることです。
00:02:52通常のGitブランチと同じですが、複数の作業を同時並行で進められるのが特徴です。
00:02:57サイドバーの作業を続ければ、ここに変更が表示されます。
00:03:04それをドラッグして、既存のコミットを修正（amend）することもできますし、
00:03:10そのブランチの新しいコミットとして追加することもできます。これで2つの並列ブランチができました。
00:03:14別のやり方も見てみましょう。例えば、赤いテーマが
00:03:18フロントエンドの変更に依存しているとします。その場合、赤いテーマを統合する前に、
00:03:24まずフロントエンドの変更をマージしたい、あるいはすべてまとめてマージしたいはずです。
00:03:29そこで、このコミットを一度取り消して（uncommit）、スタックブランチとして作り直しましょう。
00:03:37コミットを戻し、適用も解除します。そして、新しく依存ブランチを追加します。
00:03:42新規作成から「dependent branch」を選択します。または、
00:03:47ここで「create dependent branch」を選び、「front-end fixes」の上にスタックします。
00:03:51名前を「sc_red_theme」にします。これでブランチが積み重なった状態（スタック）になりました。
00:03:58これをコミットに含めます。スタックブランチが完成したら、GitHubにプッシュできます。
00:04:06プッシュも非常に簡単です。GitHub連携を設定していれば、
00:04:11プルリクエスト（PR）も作成できます。「red theme」のPRを作成すると、
00:04:16これがスタックブランチである場合、PRの説明欄のフッターに自動的に注釈が挿入されます。
00:04:20「このブランチは別のブランチに依存しています」といった内容です。これにより、
00:04:25一括マージするか、フロントエンド修正を先にマージする必要があることが分かります。
00:04:30スタックブランチを管理する非常にスマートな方法です。このPRを見ると、
00:04:34スタック内の両方のブランチがリンクされています。「スタックのパート2」「パート1」といった具合です。
00:04:39もう一つのクールな機能は、ブランチへの「割り当て（assigning）」です。
00:04:43現在、レーンが2つ、ブランチが3つあります。2つはスタック、1つは独立しています。
00:04:48作業を始めた際、特定の変更（ハング）を
00:04:54特定のブランチに割り当てて、作業を続けることができます。これは、
00:05:00各レーンがそれぞれ独立した「ステージング・エリア」を持っているようなものです。
00:05:05「git add」に近いですが、独立したステージングエリアを複数持てる点が異なります。
00:05:09やってみましょう。管理ページに新しいセクションを追加する新機能を作ります。
00:05:14同じディレクトリ内で作業していますが、これをスタックされていない独立した新ブランチに入れ、
00:05:19その変更だけを含むPRを開くことができます。
00:05:24こちらが以前の管理ダッシュボードです。最近のサインアップ情報を追加する変更を行いました。
00:05:31これらの2つの変更をこのレーンに割り当てます。
00:05:37さらに変更を加えた際、判別できなければ「unassigned（未割り当て）」に入りますが、
00:05:43同じコードの塊（ハング）内であれば、自動的に割り当て済みのレーンに維持されます。
00:05:47管理コントローラーに適当なコメントを追加して、
00:05:55どうなるか見てみましょう。すでにこのレーンに割り当てられていたファイルなので、
00:06:00改めてステージングし直す必要はありません。「これもその変更の一部だ」と判断され、
00:06:05自動的にそのレーンに入ります。では、これで新しいコミットを作成しましょう。
00:06:10ここでも詳細なメッセージを書けますし、AIを使って
00:06:15コミットメッセージの原案を生成することもできます。これをベースに編集すればいいのです。
00:06:19AIが変更内容を分析して、叩き台を作成してくれます。よし、
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ドラッグ＆ドロップするだけです。元のスタックは削除すればOK。コミットが移動しました。
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真ん中のコミットにドラッグします。すると、このコミットにはこのファイルだけが入り、
00:08:13「サイドバー修正」には残りのファイル（管理コントローラーとサイドバー）が残ります。
00:08:20ファイル単位だけでなく、コードの塊（ハング）単位での移動も可能です。
00:08:30これで一部をこちら、残りをあちらへ分離できました。必要に応じてコミットメッセージを書き換えます。
00:08:34コミットメッセージの編集も非常に簡単です。並び替えや
00:08:41統合、分割だけでなく、いつでも内容を編集できます。
00:08:46例えばこれを「パート2」に変更すると、その上のコミットはすべて自動的にリベースされます。
00:08:53また、コミットをその場で直接編集することもできます。素早く行う方法がいくつかあります。
00:08:57フィードバックを受けて、「マージンを0じゃなく10ピクセルにしてほしい」と言われたとしましょう。
00:09:014つ前の、しかも別のスタックにあるコミットをどう編集すればいいでしょうか？
00:09:06GitButlerなら驚くほど簡単です。実際に変更を加えてみましょう。
00:09:13ここですね、10ピクセルに変えます。「インラインCSSは最高」なんて思いながら（笑）。
00:09:16変更しました。すでに編集された箇所なのでロックされています。つまり、
00:09:23このブランチのどこかに入れる必要があります。別の並列ブランチには入れられません。
00:09:28それがルールの判別基準です。では、どう適用するか？
00:09:32一番簡単なのは、このファイルを
00:09:39対象のコミットにドラッグすることです。これだけでコミット内容が10ピクセルに更新され、
00:09:46それ以降のコミットもすべてリベースされました。別の方法は、
00:09:51すでにお見せした通り、一度テンポラリのコミットを作成し、
00:09:55それを対象のコミットに統合（squash）することです。これで実質的に同じ結果が得られます。
00:10:02確認すると、マージンは10ピクセルになっています。最後に
00:10:07もう一つの面白い方法、「編集モード」を紹介します。まだ何もしていない状態だと仮定して、
00:10:120ピクセルの箇所を直したいとします。対象のコミットを選択し、
00:10:20「edit commit」を押します。すると非常に興味深いことが起こります。
00:10:25Gitでいう「detached head checkout」のような状態になります。
00:10:30その時点のコミットの状態がチェックアウトされ、自由に編集できます。編集を終えてモードを抜ければ、
00:10:36残りのコミットが再びその上にリベースされます。変更を加えましょう。
00:10:39ファイルが修正されたことを検知しました。保存して終了します。すると、
00:10:46再びリベースが走ります。中身を見ると、変更がしっかり保存されています。
00:10:52コミットを直接編集する、変更してアメンド（amend）する、コミットを作って統合（squash）するなど、
00:10:57GitButlerでは変更内容を操作する方法が豊富に用意されています。
00:11:01そして最後にお見せするのが「オペレーション履歴（Operations History）」です。
00:11:05Gitの「reflog」を使ったことがある人なら、これがいかに困難か知っているでしょう。
00:11:10reflogは誰もが少し怖がるものですが、GitButlerで行うすべての操作は
00:11:15操作ログに保存されており、タイムラインから過去のどの時点にも戻ることができます。
00:11:21こちらのボタンから、セッション中に行ったすべての操作履歴が見られます。
00:11:26そして、完全にどの時点へも遡ることができます。
00:11:30例えば、あの「10ピクセル」の修正を始める前に戻りたいなら、
00:11:37ここを選択すれば、その作業を行う直前の状態を確認できます。
00:11:42あるいは、このセッションの本当に最初の時点まで
00:11:47戻ることも可能です。ただし、GitHubにプッシュ済みの内容は
00:11:52元に戻せません。これらは「アップストリームのコミット」として表示されていますが、
00:11:56ローカルでのコミットを一切行う前の状態まで戻れました。
00:12:01必要ならブランチごと消してゼロからやり直せます。さらに「元に戻した操作」すら
00:12:05元に戻せます（やり直しが可能）。スナップショットをリバート前の状態に戻せば、
00:12:11元の場所へ帰ってこれます。常にどの時点へも自由に行き来できるのです。
00:12:16これなら、どんな操作も恐れる必要はありません。万が一
00:12:22おかしな状態になっても、あるいは10分前の状態に戻したいと思ったときも、
00:12:26タイムラインを開いてリバート（Revert）するだけです。以上、
00:12:32GitButlerのリベース機能、コミットエディタ、並列およびスタックブランチの概要でした。
00:12:36これらすべてを、他のツールなしで簡単に行えます。ぜひダウンロードして、
00:12:41感想をDiscordで聞かせてください。では、楽しんで！