GitHub Flow コマンドチートシート
この記事のまとめ：
- GitHub Flow を実行するための Git コマンドをまとめています。
背景
Git を使わない期間が長くなると Git コマンドを忘れがちなのと、最近小規模のチームで GitHub Flow でソフトウェア開発をしていくことになったのですが、意外と Git コマンドで流れを説明している記事が見当たらなかったため、GitHub Flow を実施するための Git コマンドをまとめてみました。もし誤りなどあればご指摘ください。
Git のブランチ戦略
Git の代表的なブランチ戦略として、下記の３つが挙げられます。
- Git Flow … 柔軟なブランチ構成が取れるものの複雑
- GitHub Flow … master ブランチはデプロイ可能な状態を維持するための最小構成
- GitLab Flow … 開発、ステージング、本番環境など商用展開を意識
それぞれ一長一短があり、プロジェクトの規模や目的に応じてどういったブランチ戦略を選択するべきかは検討すべきです。
私の場合は、最低限 master ブランチを汚さないように運用できればよく、シンプルに Git でリポジトリーを運用すればよかったので GitHub Flow を選びました。Git 自体も勉強中のところもあり、 GitHub Flow で使用するコマンドについてまとめましたので紹介していきます。
GitHub Flow について
GitHub Flow の基本的な原則や開発の流れは下記の記事によくまとまっていたので、こちらを参照されるのがよいと思います。
また、GitHub Flow といっても、もちろん GitLab や Backlog などの Git リポジトリーでも同様に使うことができます。
今回説明するコマンドの流れ
トップ画像で示したような GitHub Flow の一般的な流れをコマンドとともに説明していきます。
- ローカルリポジトリーを作成する
- リモートリポジトリーの複製をローカルに作成する
git clone - 新規でローカルリポジトリーを作成する
git init
- リモートリポジトリーの複製をローカルに作成する
- ローカルリポジトリーに新しいブランチを作る
git checkout -borgit switch -c - コミットする準備をする
git add- ワーキングツリーの状態を表示する
git status - ワーキングツリーと HEAD との差分を表示する
git diff - インデックスからファイルを取り消す
git resetorgit restore - リポジトリーからファイルを取り消す
git rm
- ワーキングツリーの状態を表示する
- コミットする
git commit - リモートリポジトリーの更新内容をローカルリポジトリーに反映する
git pull - 更新したローカルリポジトリーをリモートリポジトリーに反映する
git push - 更新内容をリモートリポジトリーの master ブランチに反映する (pull/merge request)
- タグをつける
git tag
また、文末にここで出てくる用語の説明を載せています。
ローカルリポジトリーを作成する
まずはローカルリポジトリーを作成することが Git の第一歩目です。ローカルリポジトリーを作成する方法として、リモートリポジトリーのクローンをローカルに作成する方法と、まっさらな状態からローカルリポジトリーを作成するする方法があります。
リモートリポジトリーの複製をローカルに作成する
リモートリポジトリーにすでに何かのファイルがあり、ローカルに何もファイルがないときにこの方法を使います。上記の例だと次のようなコマンドでローカルに複製（クローン）ができます。
git clone コマンドはリポジトリーを新しいディレクトリーに複製するコマンドです。git@git.example.com はリモートリポジトリーの URL です。それに続いてローカルリポジトリーを作成するディレクトリーを指定することもできます。
git clone コマンドでよく使うオプションとして、特定のブランチから開始する場合に -b <branch> があります。
新規でローカルリポジトリーを作成する
リモートリポジトリーが空の状態か、すでにローカルに何かファイルがあるときにこの方法を使います。まずは、カレントディレクトリー配下を新規のローカルリポジトリーを作成するためにコマンドを入力します。
git init コマンドは空の Git リポジトリーを作成や、初期化するコマンドです。
またこの場合、リモートリポジトリーは登録されていませんので、リモートリポジトリーを登録しておきます。
git remote コマンドはリモートリポジトリーの追加や削除するなどリモートリポジトリーを管理するためのコマンドです。
上記コマンド例の origin というのはリモートリポジトリーを識別するための名前（一般的にデフォルトのリモートリポジトリーには origin の名前を付けます）です。git@git.example.com はリモートリポジトリーの URL です。一般的には http 、 https 、 git 、 ssh ではじまる URL です。
なお、リモートリポジトリーを登録しただけではリモートリポジトリーには何の作用も与えません。
ローカルリポジトリーに新しいブランチを作成する
GitHub Flow では master ブランチで直接変更する（コミットして HEAD を進める）ことは基本的には行わず、新しい機能の開発するたびに新しいブランチを作ってそのブランチで開発を進めます。上記の例だと次のようなコマンドで feature-x という新しいブランチを作成できます。
git checkout コマンドはブランチの切り替えと、ファイルをリストアする用途で使うコマンドであります。 -b オプションは新しいブランチを作成してそのブランチに切り替える際に使うオプションです。
なお、 git checkout コマンドは上記の２つの機能を包含してしまっておりわかりずらいです。そのためそれを分割するために、Git 2.23 以降ではExperimental な機能として git switch コマンドと git restore コマンドが追加されています。今回の場合では下記のコマンドでも同じことができます。
git switch コマンドは特定のブランチに切り替えるコマンドです。-c オプションは新しいブランチを作成して、そのブランチに切り替える際に使うオプションです。
コミットする準備をする
Git ではローカルリポジトリーを更新する手順として、作業中のディレクトリーにあるファイル（ワーキングツリーという）のうち、編集したファイルの変更履歴をリポジトリーに記録する（コミットする）ためには、インデックスというものにコミットする前にファイルの更新内容を記録します。そして、そのインデックスに記録された内容をコミットしてリポジトリーに記録するという手順を取ります。
その手順の中ではじめに行うことは次のコマンドです。
git add コマンドはファイルをインデックスに追加するためのコマンドです。上記では README.md ファイルをインデックスに追加する例ですが、ファイルやディレクトリーを記載すればよいです。ワイルドカード * を使うこともできます。また、複数のファイルを後ろに並べることもできます。
このインデックスを編集する際によく利用するコマンドとして、下記のようなコマンドがありますので合わせて紹介します。
git status：ワーキングツリーの状態を表示するgit diff：ワーキングツリーと HEAD との差分を表示するgit resetorgit restore--staged：インデックスからファイルを取り消すgit rm：リポジトリーファイルを取り消す
ワーキングツリーの状態を表示する
前回のコミットからどのファイルを更新したか、インデックスに追加したかなどを確認するためのコマンドとして下記のコマンドを利用します。
git status コマンドはワーキングツリーのうち、HEAD とインデックスに差分があるファイルを表示するコマンドです。差分は次の３つで表現されます。
- Changes to be committed: インデックスに追加され、コミットする準備ができているファイル (
git addされたファイル) - Changes not staged for commit: HEAD から変更があるファイル
- Untracked files: リポジトリーに含まれていないファイル
ワーキングツリーと HEAD との差分を表示する
git add する前に最終コミット時からの編集内容を確認するコマンドは下記の通りです。
git diff コマンドはコミットとワーキングツリー間の変更内容を表示するコマンドです。git add によってインデックスにファイルを追加した後にそのファイルの HEAD からの変更を表示する場合には --cached オプションを付けます。
インデックスからファイルを取り消す
git add コマンドによってインデックスに追加したファイルをインデックスから取り消す場合は下記のコマンドを使います。
git reset コマンドは現在のブランチ HEAD を指定された状態にリセットするために使用するコマンドです。上記のコマンドでは <paths> で指定するファイルを HEAD の状態にリセットするという意味合いになります。
もしくは、上で紹介した新しいコマンドである git restore を使って下記でも同じことができます。
git restore コマンドはワーキングツリーの中の指定したファイルをリストアするソースからリストアするためのコマンドです。--staged オプションは、インデックスの中からファイルを（デフォルトでは HEAD の状態に）リストアするオプションです（インデックスをリストアするだけでワーキングツリーのファイルはリストアされません）。ワーキングツリーのファイルもリストアする場合にはさらに --worktree オプションを追加します。
リポジトリーからファイルを取り消す
ファイルあるいはディレクトリーをリポジトリーから取り消す場合のコマンドは下記の通りです。
git rm コマンドは、ワーキングツリーとインデックスからファイルを削除するためのコマンドです。上記のコマンドの場合、対象のファイルはリポジトリーだけでなく、ワーキングツリーからも削除します（ファイルが削除される）。ワーキングツリーにはファイルを残したい場合は、--cached オプションを付けます。
コミットする
ローカルリポジトリーを更新するための手続きがコミットすることです。
git commit コマンドはリポジトリーに変更を記録するためのコマンドです。コミットする際、どういう更新をしたのかの説明のメッセージを残します。そのために使うオプションとして２つあります。
-m: コミットに対するメッセージを引数として ``` もしくは"で囲ってコマンド上に書き込みます。-v: エディターを開き、エディター上で差分を表示してくれますので、文頭に直接メッセージを書き込みます。
-m の方が手軽ではありますが、何を編集したのか確認するために -v オプション使う方が安全です。
コミットは下のように何度行っても構いません。すべての履歴がリポジトリーに記録されていきます。
リモートリポジトリーの更新内容をローカルリポジトリーに反映する
ローカルでの作業中に、他の作業者によってリモートリポジトリーの master ブランチが更新されることもあります。最終的にローカルで作業している内容をリモートリポジトリーの master ブランチにマージする予定があるのであれば、ローカルリポジトリーの現在作業しているブランチをリモートリポジトリーのマージ先のブランチの最新状態を反映している状況にしなければなりません（GitHub Flow では基本的にはマージ先はリモートリポジトリーの master ブランチになりますが、その他のブランチにマージする場合もマージ先の最新状態を反映させなければマージはできません）。
そのためのコマンドは次のコマンドです。
git pull コマンドは、ほかのリポジトリーから更新内容を取得し、ローカルリポジトリーに統合するためのコマンドです。上記の例では origin というデフォルトのリモートリポジトリーから master ブランチから更新内容を取得し、統合するということです（実は説明を省略しています。詳細を知りたい方はまずはこちらをご覧になるとよいです。
もし、リモートの更新内容とローカルの更新内容がコンフリクトする場合には、対象のファイルがコンフリクトした内容がわかるように変更されています。リモートリポジトリーにマージするためには、コンフリクトした部分をリモートの内容に上書きするか、ローカルの内容に上書きして、コンフリクトがなくなるように修正します。
更新したローカルリポジトリーの内容をリモートリポジトリーに反映する
ローカルリポジトリーの更新内容をリモートリポジトリーに反映させます。これによって、ローカルリポジトリーでコミットした内容がリモートに反映されることになります。そのために使うコマンドは次のコマンドです。
git push コマンドは、関連するオブジェクトと一緒にリモートリポジトリーを更新するためのコマンドです。上記のコマンド例は、ローカルリポジトリーのブランチ feature-x をリモートリポジトリー origin にあるローカルと同名のブランチを更新するという意味になります。
更新内容をリモートリポジトリーの master ブランチに反映する (pull/merge request)
リモートリポジトリーの master ブランチに開発したブランチをマージする作業はすべてリモートリポジトリー上で行うためここではローカルからのコマンドは使いません。Git ホスティングサービスごとに UI は異なるもののその作業はすべてウェブ上で行います。その名前はサービスごとに若干異なり、GitHub や Backlog では Pull Request 、GitLab では Merge Request といいます。Pull / Merge Request を作成する際、その Request の承認者などを選択します。その指定した承認者が要求を承認すれば無事に開発したブランチが master ブランチにマージされます。
参考までに、GitHub と GitLab のウェブ UI を載せておきます。GitHub ではリモートリポジトリーに新しいブランチを作ると “Compare & pull request” というボタンが現れます。
GitLab でも同様に新しいブランチを作ると “Create merge request” というボタンが現れます。
タグを付ける
タグとは git commit コマンドではアップデートされない識別子で、特定のコミットを参照しやすいようにするための印です。例えば、リリースバージョンを示すためにタグを付けたりします。
リリースバージョンを示すタグを付ける場合、一般的に master ブランチのコミットに対して付けることになります。ここまでの作業でローカルリポジトリーは開発ブランチにいますので、一度最新の master ブランチまで戻ります。
ローカルリポジトリーで最新の master ブランチに戻る場合には、まずはブランチを master に切り替えます。
切り替えは既に紹介した通り、git switch コマンドでもよいです。
そして、最新のリモートリポジトリーの内容をローカルリポジトリーに反映します。
これでローカルリポジトリーも最新の master ブランチになりました。
引き続いて、タグを付けていきます。
タグを付けるコマンドは次の通りです。
git tag コマンドはタグを作成、表示、削除、検証するためのコマンドです。上記では、-a オプションに続く v1.0.0 というタグ名でタグを作り、-m オプションに続くメッセージも併せて付与します。
ここまでではまだローカルリポジトリーにしかタグが付いていませんので、リモートリポジトリーにも反映させます。そのためのコマンドは git push コマンドを使います。ブランチを指定したときの git push コマンドではタグの情報は反映されないため、タグを反映させたいときはタグを指定してプッシュする必要があります。
用語説明
Git のマニュアルなどを読む際に最低限存在を理解しておかないと紛らわしい Git の用語を説明しておきます。
- リポジトリー (repository): リポジトリーとは、プロジェクトに関連するファイルやフォルダーのすべての集合と、各ファイルの変更履歴を指します。GitHub などのサービスはネットワーク上にリポジトリーを作成し、共同で管理できるようにするサービスを提供します。このとき、ネットワーク上のリポジトリーをリモートリポジトリー、ローカルで作業するリポジトリーをローカルリポジトリーといいます。
- ブランチ (branch): 並列開発を行うための機能です。デフォルトのブランチを “master” ブランチといい、並列開発を行うときには “master” ブランチから別のブランチを作成して、そのブランチ上で開発を行います。
-
HEAD: 現在のブランチ、もしくは現在のブランチの先端にあるコミットを指すポインターです。
-
コミット (commit): コミットには名詞の意味合いと、動詞の意味合いがあります。 名詞の意味合いでは、Git の履歴内のある１点のことを指します。 動詞の意味合いでは、ファイルやフォルダー状態の新しい履歴を作成する操作のことを指します。コミットすることで、リポジトリーに新しいコミットを作成し、 HEAD をその新しいコミットを指すように進めます。
- ワーキングツリー (working tree): ローカルでの作業中のディレクトリーにあるファイルのことを Git ではワーキングツリーといいます。ワーキングツリーは HEAD とまだコミットしていないローカルの変更とを合わせた内容に等しいです。
- インデックス (index): インデックスとは、ワーキングツリーの中身のスナップショットのことです。インデックスとして記録されたローカルでの変更内容は、コミットする前のステージング状態であるという意味合いになります。コミットすることでインデックスは新しいコミットとしてリポジトリーに記録されます。
参考資料
公式ドキュメント類はこちらを参考にするとよいです。
今回は以上です。 最後まで読んでいただき、ありがとうございます。
コメント
コメントを投稿