Git Commands Cheat Sheet: The 20 Commands You Actually Use — txt1.ai

3時のプロダクション危機がGitに対する私の考え方を変えた

私たちのデプロイメントパイプラインが夜中の3時に壊れた夜を忘れることはできません。私はフィンテックのスタートアップでシニアDevOpsエンジニアを務めていて、キャリアは5年目で、誰かがmainに強制プッシュして4つの異なるチームから3日分の作業を消してしまったためにページを受け取りました。私の手は震え、ターミナルを見つめながら、毎秒が重要であることを知っていました—規制の締切、怒った利害関係者、そして私がこれを修正するのを待っている疲れた開発者たちがいるのです。

その時、私は重要なことに気付きました：私はGitを5年使っていましたが、実際に知っていたコマンドは約20個だけでした。その他は雑音でした。Gitのドキュメントには160以上のコマンドがリストされていますが、その危機の瞬間に、私は何千回も使ってきた同じ数個のツールに手を伸ばしました。そして、どうですか？それで十分でした。その夜、私たちはそれによって救われました。

それ以降、私は3社で200人以上の開発者と働き、数えきれないコードレビューを行い、数えられないほどのリポジトリを救いました。過去2年間、シェル履歴分析を使用して実際のGitの使用状況を追跡しましたが、そのデータは衝撃的です：私のGitのやり取りの94%はたった20個のコマンドに関わっています。残りの6%は、四半期に1回使うかもしれない数十の不明瞭な操作に分かれています。

この記事は、ブックマークして読まない別の詳細なGitリファレンスではありません。これは、あなたの日常業務の99%を処理するための戦闘でテストされた、実績のあるコマンドのリストです。私は各コマンドの使い方、実際に重要なフラグ、そして何百回ものマージコンフリクトやデプロイメントの緊急時に私を冷静に保ってくれたメンタルモデルを正確にお見せします。

基礎: 毎日使うコマンド

絶対的な必需品から始めましょう—私が頻繁に使うコマンドで、意識的に考えなくても指が自然に打つものです。これらの5つのコマンドは、すべてのGitワークフローのバックボーンを形成しており、他のことをマスターしなくても、これをマスターしてください。

私のチームの2年間のシェル履歴を分析した結果、直感に反することを発見しました：Gitコマンドをあまり知らない開発者は、しばしばより生産的でした。彼らは必須の20を完全に習得し、考えずにそれらを実行できる一方、マニュアル全体を暗記した人々は、重要な瞬間に似たオプションの間で貴重な秒を悩んでいました。

git statusは私の常にそばにいる友です。私はおそらくこれを1日50回は実行しますが、誇張ではありません。すべてのコミットの前、すべてのプルの後、何が起きているのか混乱しているとき—git statusは私の最初の手段です。これにより、どのファイルがステージされているか、どのファイルが変更されたが未ステージか、どのファイルが追跡されていないかが示されます。出力は色分けされていて非常に読みやすいです。私はジュニア開発者がgit statusを実行していればすぐに明らかだったGitの問題に数時間苦しむのを見てきました。

私のワークフローはこうです：私はgit statusを頻繁に使用するため、シェル設定で"gs"にエイリアスを作成しています。コンテキストを切り替えたり、会議から戻ったりするたびに、git statusは私が何をしていたかを思い出す方法です。それはあなたの現在の状態のブックマークのようなものです。

git addはコミットのために変更をステージする方法です。最も一般的なパターンはgit add .で、現在のディレクトリ内のすべてをステージしますが、私はこれを盲目的に使用しないことをお勧めします。代わりに、私は約60%のコミットでgit add -p（パッチモード）を使用しています。これにより、各変更を対話的に確認し、必要なハンクだけをステージできます。これは遅いですが、デバッグコード、APIキー、恥ずかしいconsole.logステートメントをコミットしてしまうのを防いでくれました。

素早い作業には、git add filenameが特定のファイルをステージします。私は、自分が何をコミットしているかを確信しているときにこれを使用します。ここでの重要な洞察は、ステージングはコミットとは別であるということです—ファイルを徐々にステージし、git statusで確認し、準備ができたらコミットできます。

git commitはステージされた変更のスナップショットを作成します。私は小さく明白な変更に対してgit commit -m "message"を使用しますが、重要なものについてはgit commitと入力してエディターを開いてもらいます。これは、適切なコミットメッセージを作成することを強制します。良いコミットメッセージは、未来の自分へのドキュメンテーションです。私は変更が行われた理由を理解しようと、git履歴を掘り下げるのに無数の時間を費やしてきましたが、詳細なコミットメッセージはその価値があります。

私のコミットメッセージのテンプレート: 最初の行は簡潔な要約（50文字以内）、次に空白の行、それから何が変更され、なぜ変更されたのかの詳細な説明です。「なぜ」が重要です—diffは何が変更されたかを示しますが、理由を説明できるのはあなただけです。

git pushは、あなたのコミットをリモートリポジトリに送信します。ほとんどの場合、git pushが必要なすべてです。新しいブランチを初めてプッシュする場合は、git push -u origin branch-nameが必要です。-uフラグ（--set-upstreamの略）は、今後のプッシュおよびプルがこのブランチでリモートとブランチ名を指定する必要がなくなることを意味します。

知っておくべき重要なフラグの1つはgit push --force-with-leaseです。絶対にリモート履歴を上書きしたいという自信がない限り、git push --forceを使用しないでください。--force-with-leaseバリアントは、他の誰かがあなたのローカルに持っていないコミットをプッシュした場合に失敗するため、安全です。私は--forceがチーム全体の作業を消し去るのを見てきました。そんな人にならないでください。

git pullは、リモートから変更をフェッチして現在のブランチにマージします。私はこれを毎朝仕事を始める前とプッシュする前に実行します。デフォルトの動作はほとんどの場合良好ですが、私はgit pull --rebaseが好みです。これは、不必要なマージコミットを避けて履歴をクリーンに保つためです。私はこれをデフォルトとしてgit config --global pull.rebase trueに設定しています。

ブランチング: あなたのパラレルユニバースツールキット

ブランチはGitの真の力がある場所です。これは、メインコードベースに影響を与えることなく、機能、実験、修正に取り組むことを可能にします。私はおそらく週に10〜15のブランチを作成し、これらのコマンドがそのワークフローをシームレスにします。

git branchはすべてのローカルブランチをリストアップします。現在のブランチはアスタリスクでマークされています。私はgit branch -aを使用してリモートブランチも確認し、git branch -d branch-nameで完了したブランチを削除します。-dフラグは安全です—マージされていない変更のあるブランチは削除できません。削除を絶対に確信している場合（おそらく失敗した実験かもしれません）、git branch -D branch-nameを使用します。

古いブランチを宗教的に整理します。50の古いブランチを持つリポジトリは混乱を招き、探しているものを見つけるのが難しくなります。毎週金曜日に、git branch --mergedを実行して、メインにマージされたブランチを確認し、それを削除します。それはあなたのデスクを掃除するようなものです—ただ良い気分になるのです。

git checkoutは切り替えを行いますが、