Gitコマンドジェネレーター — 毎日同じコマンドをGoogle検索するのをやめよう

以前、gitドキュメントへのブラウザタブを常時開いていました。gitを知らないのではなく——何年も使ってきましたが——たまにしかやらないことの正確な構文を忘れ続けていたからです。変更を失わずにアンステージしたい場合はgit reset --softかgit reset --cachedのどちらだったか？git stash applyはスタッシュを削除するか残すか？アップストリームを設定するフラグは-uか--set-upstreamか？

私が知っているすべての開発者がこの経験の一形態を持っています。gitは数週間以内に日常的なコマンドが反射的になりますが、中程度の頻度のコマンド——数日に一度または週一で使うもの——はなかなか定着しません。学んで、忘れて、また学んで、また忘れる。

ToolBox HubのGitコマンドジェネレーターはまさにそのような瞬間のために存在します。ドキュメントにタブを切り替える代わりに、カテゴリーでフィルタリングし、やりたいことで検索し、ブランチ名やコミットハッシュを入力して、完全なコマンドをコピーできます。ハンティングも、間違ったフラグのデバッグも不要です。

ツールの仕組み

Gitコマンドジェネレーターを開くと、検索バーとカテゴリーボタンの行が見えます：Basic（基本）、Branching（ブランチ）、Remote（リモート）、Undo（取り消し）、Stash（スタッシュ）、Advanced（高度）。

コマンドカードにはそれぞれ、等幅コードブロック内のコマンド、何をするかの平易な説明、コピーボタンが表示されます。パラメータが必要なコマンド——ブランチ名、ファイルパス、コミットハッシュ——にはカードの下にテキスト入力があります。入力したものがリアルタイムでコマンドテンプレートに代入されるので、コピーボタンは常に実行可能なバージョンをコピーします。

例えば、「新しいブランチを作成して切り替える」カードをクリックしてブランチ名フィールドにfeature/paymentsと入力すると、コマンドブロックは即座にgit checkout -b feature/paymentsに更新され、それがクリップボードにコピーされます。

検索バーはコマンド名と説明の両方でフィルタリングするため、「undo」と入力すると関連するすべてのコマンドが表示され、「stash」と入力すると完全なスタッシュワークフローが一緒に表示されます。

実際に使うコマンド

40以上のコマンドをアルファベット順に説明するのではなく、実際の作業日に現れる順序でカテゴリーを見ていきましょう。

セットアップと日常の基本

Basicカテゴリーのコマンドは、最初の1ヶ月以内に筋肉記憶が引き継ぐものです。git statusはおそらく最も実行されるgitコマンドで——ステージされているもの、されていないもの、追跡されていないものを教えてくれます。git add .は現在のディレクトリにあるすべてをステージします。git commit -m "メッセージ"はコミットを作成します。

このカテゴリーで開発者が使いこなせていない2つはgit diffとgit diff --stagedです。何も追加する前にgit diffを実行すると、前回のコミット以降の作業ツリーで正確に何が変更されたかを確認できます。追加後にgit diff --stagedを実行すると、次のコミットに実際に入るものが表示されます。すべてのコミット前にこれらを確認する習慣をつけると、デバッグログ、コメントアウトされたコードブロック、誤ったファイルの包含が驚くほど多く見つかります。

git log --onelineも過小評価されている日常ツールです。デフォルトのgit log出力はざっと見るには冗長すぎます。--onelineバージョンは各コミットを1行に圧縮します：ハッシュの最初の7文字とコミットメッセージの件名。探しているコミットを見つけるのがずっと速くなります。

ブランチ戦略

Branchingカテゴリーはブランチの作成からマージ、タグ付けまでカバーします。

git checkout -b <ブランチ>（または新しいgit switch -c <ブランチ>）がほとんどのフィーチャー作業の開始方法です。名前を付けて、切り替えて、構築します。作業が完了したら、プルリクエストを開くかマージして戻ります。標準的なフローです。

人々が曖昧になるコマンドはgit merge対git rebaseです。どちらも一方のブランチから別のブランチに変更を統合しますが、方法が異なります。

git mergeはマージコミットを作成します。ブランチの履歴とターゲットブランチの履歴の両方が保持され、マージコミットはそれらが結合した場所を示します。gitグラフを見ると、マージコミットはひし形を作ります。これは実際に起きたことに忠実——2つの並行した作業ストリームが収束した——であり、チームワークフローの安全なデフォルトです。

git rebaseはコミットを取り込み、ブランチポインターをターゲットブランチの先端まで巻き戻し、コミットをその上に再生します。結果はマージのひし形がない真っ直ぐなコミットの行です。利点は読みやすさで、git logが追いやすくなります。欠点は、リベースがコミットハッシュを書き換えることで、他の人がそれらのコミットをプルしている場合に問題が発生します。ルール：個人またはローカルブランチではリベース、共有ブランチではマージ。

git branch -d <ブランチ>はマージ後にローカルブランチを削除します。gitはここで保守的で、ブランチにマージされていないコミットがある場合は削除を拒否します。マージされていないブランチを本当に破棄したい場合は-D（大文字）を使用します。ジェネレーターには安全なバージョンである-dが含まれています。

リモートとの連携

Remoteカテゴリーはサーバーに触れるコマンドをカバーします。

git fetch originはgit pullと微妙に異なります。fetchはリモートから新しいコミットとブランチをダウンロードするだけで、ローカルブランチには全く触れません。pullはfetchの後にマージが続きます。特にアクティブな共有ブランチでは、マージする前にfetchして何が変わったかを確認することを好みます。これは何度も予期しないコンフリクトから救ってくれた小さな習慣です。

git push -u origin <ブランチ>は新しいブランチの最初のプッシュです。-uフラグはアップストリームトラッキング関係を設定するため、この後は引数なしのgit pushとgit pullがそのブランチで自動的に機能します。最初のプッシュで-uを省略すると、後続のgit push呼び出しはアップストリームが設定されていないと不満を言います。

git remote -vは「私のセットアップは何か」コマンドです。慣れていないリポジトリでは、これを実行するとfetchとpushがどこに行くかがすぐにわかります。これが予期しない場所を指すリモートを表面化させることがどれほど多いか驚くでしょう。

git cherry-pick <ハッシュ>は言及に値します。履歴のどこからでも単一のコミットを現在のブランチにコピーします。典型的なユースケース：ホットフィックスがmainにマージされたが、そのフィックスも必要な長期実行のフィーチャーブランチで作業している。コミットハッシュをcherry-pickすると、mainの残りの変更なしにブランチに適用されます。

ミスの取り消し

これは人々が最も緊急に検索するカテゴリーです。何かがうまくいかず、状況を悪化させずに元に戻す必要があります。

git reset --soft HEAD~1は最も穏やかな取り消しです。ブランチポインターを1コミット戻しますが、すべての変更はステージされた状態のまま再コミットできます。早すぎてコミットして、変更を追加したりメッセージを書き直したりしたい場合に使用します。

git reset HEAD~1（デフォルトの「mixed」モード）はポインターを戻してステージを解除しますが、変更を作業ツリーに残します。再ステージする前に変更を再検討したい場合に使用します。

git reset --hard HEAD~1は核オプションです。ポインターを戻して変更を完全に破棄します。これに対する組み込みの取り消しはありません——変更は作業ツリーから消えます。それらの変更が必要ないと確信している場合にのみ使用してください。

**git revert <ハッシュ>**は取り消したいコミットがすでにプッシュされている場合の適切なツールです。revertは元の変更の逆を適用する新しいコミットを作成します。履歴は保持されます。プルしたチームメートの世界は混乱しません。

git restore <ファイル>は特定のファイルへの作業ツリーの変更を破棄します。git restore --staged <ファイル>は作業ツリーに触れずにファイルのステージを解除します。これらのコマンドはGit 2.23で過負荷のgit checkoutとgit resetのよりクリーンな代替として追加され、推論がずっと簡単になりました。

進行中の作業をスタッシュする

スタッシュは「今すぐコンテキストを切り替える必要があるがコミットする準備ができていない」脱出ハッチです。

git stashはコミットされていない変更（ステージされたものとそうでないもの両方）をスタックに保存し、作業ツリーを最後のコミットに戻します。これでブランチを切り替え、変更をプルし、バグを修正——必要なことを何でもできます。戻ってきたらgit stash popで変更を復元します。

git stash push -m "説明的なメッセージ"は、スタッシュエントリーが複数になった瞬間から裸のgit stashより使う価値があります。メッセージは後でgit stash listを実行したときにエントリーを特定するのがずっと簡単になります。WIP: 認証ミドルウェアのリファクタリングという名前のスタッシュエントリーはstash@{2}よりずっと便利です。

git stash apply stash@{1}はリストから削除せずに特定のエントリーを適用します。同じスタッシュを複数のブランチに適用したい場合や、まだポップする準備ができていない場合に便利です。

高度なコマンドとあまり使わないコマンド

Advancedカテゴリーは時々出てくるが覚えにくいコマンドをカバーします。

git log --oneline --graph --allは定期的にリポジトリで実行することをお勧めするお気に入りです。ASCIIブランチグラフはブランチがどのように関連しているかの視覚的な絵を提供します——どれが分岐したか、マージがどこで起きたか、タグがどこにあるか。抽象的なバージョン履歴を具体的にするコマンドの一つです。

git bisect startはバグを導入したコミットを見つけるための二分探索を開始します。git bisect good <ハッシュ>で既知の正常なコミット、git bisect bad <ハッシュ>で既知の問題のあるコミットをマークし、gitがテストする中間点のコミットをチェックアウトします。gitが問題を引き起こした正確なコミットを特定するまで、goodまたはbadのマーキングを続けます。コードを実行しないと再現困難なバグには、bisectが非常に貴重です。

**git blame <ファイル>**はファイルの各行を最後に変更した人とどのコミットかを表示します。名前は非難的に聞こえますが——実際には通常、コミットを調べてメッセージと差分を読むことで、コードの行がなぜそのようになっているのかを理解するために使用されます。良いチームはblameを文脈のために使用し、非難のためではありません。

git reflogはレスキューコマンドです。ハードリセット後でも、gitはHEADがいた場所の内部ログを保持します。必要なコミットを誤って破棄した場合、git reflogはgit reset --hard <回復したハッシュ>で回復するために必要なハッシュを表示します。これが何時間もの作業を救うのを見てきました。

スムーズなGitワークフローのためのプロのヒント

意味のある違いをもたらすいくつかの習慣：

コミットメッセージは命令形で書きます。 「認証ミドルウェアを追加した」や「認証ミドルウェアを追加している」ではなく「認証ミドルウェアを追加する」。この慣例は、gitが生成したメッセージ（マージコミット、リバート）が命令形を使用するためで、自分のメッセージが自然に統合されます。

小さく頻繁にコミットします。 アトミックコミット——コミットごとに1つの論理的な変更——はgit logを読みやすくし、コードレビューを簡単にし、git bisectを効果的にします。巨大な「進捗」メッセージで1日1回コミットすると、gitの価値のほとんどが失われます。

.gitignoreを積極的に使用します。 ビルド成果物、IDEメタデータ、環境ファイル——これらはリポジトリに絶対に含まれるべきではありません。git statusがコミットしないファイルで散乱している場合は、.gitignoreを修正してください。

--patchフラグを覚えましょう。 git add --patch（またはgit add -p）では、ステージするファイルのハンクをインタラクティブに選択できます。1つのファイルに2つの異なる目的のための変更がある場合、それらを別々のコミットに分割できます。これは実際の開発の混沌とした現実の中で作業しながら、クリーンで意味のあるコミット履歴を維持する方法です。

このツールと組み合わせる価値のあるツール

gitワークフローに時間を費やしているなら、サイトの他の2つのツールが直接関連します：

Cronパーサー — CI/CDパイプラインにはイベントトリガーのジョブと並んでスケジュールされたジョブがよくあります。デプロイパイプラインにcronスケジュールが含まれていて、cron式をデコードまたは構築する必要がある場合、このツールは即座に処理します。

URLエンコーダー — GitリモートURLには時々エンコードが必要な文字が含まれることがあります、特に認証資格情報やトークンがURLに埋め込まれている場合。リモートURLが正しく解析されない場合は、まずエンコーダーを通してみてください。

FAQ

git fetchとgit pullの違いは何ですか？ git fetchはリモートから新しいコミットとブランチをダウンロードしますが、ローカルブランチには触れません。git pullはfetchの後にマージが続きます。最初に確認したい場合はfetch、統合する準備ができている場合はpullを使います。

すでにプッシュしたコミットを取り消すにはどうすればよいですか？ git revert <コミットハッシュ>を使用して、履歴を書き換えずに変更を取り消す新しいコミットを作成します。git resetはまだプッシュされていないコミットに対してのみ安全です。

git stashは何のためにありますか？ stashはコミットされていない変更を一時的に退避させ、コンテキストを切り替えられるようにします——ブランチを切り替え、変更をプルし、ホットフィックスを適用——作業途中の作業をコミットせずに。戻ってきたらgit stash popで変更を復元します。

いつmergeではなくrebaseを使うべきですか？ mainにマージする前にクリーンな線形履歴が欲しい個人ブランチで。他の人がすでにプルしたコミットは絶対にリベースしないでください——ハッシュを書き換えてコンフリクトを引き起こします。

git reset --hard後にコミットを回復するにはどうすればよいですか？ git reflogを実行してHEAD位置の履歴を確認します。必要なコミットハッシュを見つけてgit reset --hard <そのハッシュ>を実行して回復します。

まとめ

gitは開発者のツールキットの中で他のほとんどのものよりも時間投資に報いるツールの一つです。不可解に感じるコマンドが自動的になり、かつてドキュメントタブが必要だったワークフローが第二の天性になります。

Gitコマンドジェネレーターは中間段階のためにあります——何をすべきかはわかっているが、正確な構文がなかなか思い出せないとき。ブックマークして、使って、十分に使えばコマンドを暗記してしまうでしょう。