Git Commands Cheat Sheet: The 20 Commands You Actually Need — cod-ai.com

私がGitを教える方法を変えた午前3時のプロダクション危機

火曜日の午前3時17分、私の電話は通知で爆発しました。私たちの主要なプロダクションブランチが壊れ、デプロイが失敗し、何が間違っているのかわからない人はいませんでした。私は当番のシニアDevOpsエンジニアで、ノートパソコンにたどり着いた時、何が起こったのか正確にわかっていました — 誰かが自分たちが何をしているのか理解せずにメインに強制プッシュを行ったのです。

その事件は、4時間の停止中に約47,000ドルの利益を失うことになりました。しかし、もっと重要なのは、私にとって重要なことを教えてくれたことです: ほとんどの開発者は実際には200のGitコマンドを知る必要はありません。彼らが習得すべきは20のコマンド程度であり、致命的なミスを避けるためにそれらを十分に理解することです。

私はマーカス・チェンで、過去12年間、主に中規模から大規模なSaaS企業でDevOpsエンジニアおよびテクニカルリードとして働いてきました。150人以上の開発者をオンボードし、数千のプルリクエストをレビューし、覚えておきたくないほどのGitの災害を片付けてきました。私が学んだことは、Gitの習得はすべてのフラグやオプションを暗記することではなく、信頼できるメンタルモデルを持ち、特定の状況でどのコマンドを使用するか正確に知ることだということです。

このチートシートは、10年以上にわたる実際のGit使用から抽出された知恵を示しています。これは私がドキュメントで見つけた理論的なコマンドではありません。これらはほぼ毎日使用する20のコマンドであり、私はすべての新しいチームメンバーに教え、私のチームが数えきれない時間のフラストレーションを救ってきたコマンドです。ここにある各コマンドは、学問的な完全性ではなく、実際の必要性によってその地位を得ています。

始める前に、何かを明確にさせてください: これはGitの初心者向けの入門ではありません。バージョン管理が全く新しい場合は、他の場所で基礎から始める必要があります。このガイドは、Gitが存在し、それを使用したことがあるが、効率と自信を高めたい開発者のためのものです。あなたは同じコマンドを繰り返しGoogle検索するのに疲れています。プロフェッショナルが本番環境でGitを使用する方法を実際に反映した、キュレーションされた戦闘テスト済みのリファレンスが欲しいのです。

基礎: 毎日使うコマンド

絶対に必要なものから始めましょう — あなたの日常のGitワークフローの中核をなすコマンドです。私はこれらのコマンドを非常に頻繁に使用するので、ほぼ筋肉記憶になっています。任意の規模のチームで働く場合、これらのコマンドは少なくとも1日に1回は、しばしば複数回使用することになるでしょう。

"Gitの習得はすべてのフラグやオプションを暗記することではなく、信頼できるメンタルモデルを持ち、特定の状況でどのコマンドを使用すべきかを正確に知ることです。”

git status — これはあなたの状況認識コマンドです。私はこれを1日におそらく30-40回実行しています。誇張ではありません。コミットする前、コミットした後、何かがおかしいと感じたとき、タスク間をコンテキストスイッチしているとき — git statusはあなたの立場を正確に教えてくれます。どのファイルがステージされたか、どのファイルが修正されたがステージされていないか、どのファイルが追跡されていないかを表示します。これをあなたのGitコンパスとして考えてください。出力は色分けされており、非常に明確です。そのため、これは誰にでも最初に教えるコマンドです。

git add — これはあなたの変更をコミットのためにステージします。最も一般的な使用法はgit add .で、現在のディレクトリ内のすべてをステージしますが、私は実際にはもっと選択的であることをお勧めします。特定のファイルをステージするためにはgit add filenameを使用するか、個々の変更のチャンクをレビューしてステージ可能なインタラクティブステージングにはgit add -pを使用します。この詳細な制御は、関係のない変更を複数行ったときにそれらを別々にコミットする必要がある場合に、私を何度も救ってくれました。私の経験では、git addを無造作に使用する開発者は、デバッグやコードレビューをかなり難しくする混乱したコミット履歴を作成します。

git commit -m "message" — これはあなたのステージされた変更のスナップショットを作成します。-mフラグを使用すると、コミットメッセージをインラインで追加できます。さて、ここで私がたどり着いた貴重な教訓を共有します: あなたのコミットメッセージはあなたが思っているよりも遥かに重要です。私は特定の変更がなぜ行われたのか理解しようと何時間も費やした後、「fix stuff」や「updates」と書かれたコミットメッセージを見つけたことがあります。良いコミットメッセージは、この文を完成させるべきです: "適用された場合、このコミットは..." たとえば: "適用された場合、このコミットはログインエンドポイントにユーザー認証を追加します。" この規律により、コード考古学が私のチームにとって無限に簡単になりました。

git push — これはあなたのローカルコミットをリモートリポジトリにアップロードします。最も一般的に使用されるのはgit push origin branch-nameです。新しいブランチを初めてプッシュする際にはgit push -u origin branch-nameが必要です。-uフラグはトラッキングを設定し、将来のプッシュをgit pushにすることができます。これは非常に重要です: 実際に何をしているのかを完全に理解しており、チームとコミュニケーションをとっていない限り、共有ブランチに対してgit push --forceを決して使用しないでください。私が言及した午前3時の事件は、強制プッシュが間違った方向に進んだものでした。

git pull — これはリモートリポジトリから変更を取得し、それを現在のブランチにマージします。私は毎回の作業セッションをgit pullから始めて、最新のコードで作業していることを確認します。理解すべき重要なことは、git pullは実際には2つのコマンドを組み合わせたものであり、git fetchとgit mergeです。時には、もっとコントロールするためにこれらを別々に使用したい場合がありますので、それについては後で説明します。プルして衝突がある場合、Gitは正確にどのファイルに衝突があるかを示し、その後、続行する前に手動で解決する必要があります。

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

ブランチ作成はGitの真の力が現れる場所です。これにより、複数の開発者がそれぞれの機能に同時に取り組むことができ、お互いの足を引っ張ることなく作業できます。私の現在の23人の開発者からなるチームでは、通常、常に40-60のアクティブなブランチがあります。これらのブランチコマンドを習得することがカジュアルなGitユーザーと自信のあるプロフェッショナルを分けます。

git branch — 実行