すべての Git コマンドを覚えている人はいませんし、覚える必要もありません。この Git コマンド チートシート は、日常の作業のほぼすべてをカバーする小さなセットに焦点を当てており、実行しようとしているジョブごとにグループ化されています。

Git for Windows を使用して、使い捨てのデモ リポジトリでローカル コマンドをテストしました。表示されている出力は、その実行からのものであり、行末の警告は削除されています。コミットハッシュは異なります。リモート コマンドにはサーバーが必要なので、それらは実行しませんでした。バージョン管理は初めてですか? 初心者向けの Git チュートリアルから始めてください。

Git の考え方: 3 つの領域

変更箇所がわかれば、ほとんどの混乱は解消されます。

プロジェクトのセットアップと開始

作業内容を保存する

新しいファイルが移動するにつれて、短いステータス ビューがどのように変化するかを次に示します。

$ echo "hello" > app.txt
$ git status --short
?? app.txt

$ git add app.txt
$ git status --short
A  app.txt

$ git commit -m "Add app file"

?? は追跡されていないことを意味し、A はステージングに追加されたことを意味します。 2 列形式では、左の列はステージング領域、右の列は作業ディレクトリです。 git commit -am では新しいファイルがスキップされるため、最初にそれらを明示的に追加する必要があることに注意してください。

支店

最初から最後までの小さな機能ブランチを次に示します。

$ git switch -c feature/login
$ echo "login" >> app.txt
$ git commit -am "Add login"
$ git switch main
$ git merge --no-edit feature/login
$ git log --oneline --graph
* d0450b6 Add login
* 676b684 Add app file

$ git branch -d feature/login
Deleted branch feature/login (was d0450b6).

main が移動していないため、履歴は直線になっています。そのため、Git は早送りマージを実行しました。古いガイドにはまだ git checkout が表示されます。それは機能しますが、新しい switch および restore コマンドは、その多くのジョブをより明確なジョブに分割します。マージとリベースのどちらを選択するかについては、Git マージとリベースを参照してください。

リモコンの操作

fetch はファイルを変更しないため、常に安全です。リベース後にブランチを上書きする必要がある場合は、同僚の新しいコミットを消去することを拒否するため、プレーン --force よりも --force-with-lease を選択してください。

隠し場所: 仕事を脇に置きます

Stash は、タスクを切り替える必要があるがコミットする準備ができていない場合に役立ちます。

$ echo "wip" >> app.txt
$ git stash
$ git status --short
                       # clean, the change is put away
$ git stash pop
$ git status --short
 M app.txt

履歴を見る

間違いを元に戻す:「…したいのですが」

これはほとんどの人が調べる部分です。自分の状況を見つけてください:

リセット、復帰、復元

これら 3 つの名前は多くの混乱を引き起こしますが、まったく異なることを行います。

私たちのデモでは、間違った行をコミットし、それを元に戻しました。ファイルは以前の内容に戻りましたが、間違いは履歴としてログに表示されたままでした。

$ echo "oops" >> app.txt
$ git commit -am "Bad change"
$ git revert --no-edit HEAD
$ cat app.txt
hello
login

その後、git reset --soft HEAD~1 は最後のコミットを削除しましたが、その変更はステージングされたままであり、git status --short では M app.txt として示されていました。

タグ

GitHub Actions CI/CD ガイド で説明されているように、タグはリリース パイプラインをトリガーすることがよくあります。

シンプルな日常ワークフロー

git switch main
git pull
git switch -c feature/search
# edit files
git status
git add -p
git commit -m "Add search by product name"
git push -u origin feature/search
# open a pull request, get a review, then merge

「ログイン リダイレクトを修正する」など、命令文の変更を説明するコミット メッセージを作成します。 6 か月後にこのログを読んだとき、あなたは自分自身に感謝するでしょう。

よくある間違い

• シークレットのコミット。 後のコミットでファイルを削除しても、そのファイルは履歴から削除されません。すぐにシークレットをローテーションし、.gitignore を使用します。
• 共有履歴の書き換え。 他の人が既にプルしたコミットをリセットまたはリベースしないでください。
• git add . を盲目的に使用します。 最初に git status をチェックして、ビルド ファイルとログが残らないようにします。
• プレーン --force を使用します。 --force-with-lease を使用します。
• 大規模なコミットを行う。 小さいコミットの方が、レビュー、取り消し、分割が簡単です。

まとめ

3 つの領域と 12 のコマンドを学習すれば、Git は怖いものではなくなります。元に戻すテーブルを手元に置いて、git status と git reflog がセーフティ ネットであることを忘れないでください。自信を築くには、使い捨てのリポジトリを作成し、意図的に壊して修復します。そこが間違いを犯しやすい場所だからです。

よくある質問

学び続ける