FIXER Tech Blog - Development

GitHubの 超・超・超 基本的な使い方まとめ

Git コマンド 一覧

　次は実際にGit Bashに入力することになるコマンドについて紹介します。ここでは最低限しか紹介しないので詳しくは自分で調べてみてください。

■全体図
　以下にこれから紹介するコマンドと対象になる場所の関係を示します。今はわからなくても大丈夫です！

■branch
　git branchは、Gitのブランチ機能に関連するコマンドです。

git branchの使い方

1.ブランチの一覧表示：

　git branch

　現在のリポジトリにあるブランチの一覧が表示されます。
　現在のブランチの前には*が表示されます。

2.ブランチの削除：

git branch -d ＜削除するブランチ名＞

　指定したブランチが削除されます。
　ただし、削除するブランチにマージされていない変更がある場合は削除できません。
　強制的に削除する場合は-Dオプションを使用します。

3.ブランチの名前変更：

　git branch -m ＜古いブランチ名＞＜新しいブランチ名＞

　指定したブランチの名前が変更されます。

■switch
　git switchは、ブランチを切り替えるコマンドです。

git switchの使い方

1.既存のブランチに切り替える場合：

git switch ＜branch＞

2.新しいブランチを作成し、切り替える場合：

git switch -c ＜new-branch＞

・＜branch＞：切り替え先の既存のブランチ名を指定

・＜new-branch＞：新しく作成するブランチ名を指定

git switch -c は新しいブランチを作るときにめちゃくちゃ使います！

　ブランチを作成するときは現在のブランチの位置を確認しましょう！ 想定と異なるブランチから作らないように注意が必要です。

■status
　git status は、Gitにおいてリポジトリの現在の状態を確認するためのコマンドです。このコマンドを実行すると、現在のブランチ、ステージングエリアの状態、変更されたファイルの一覧などの情報が表示されます。

git status も頻繁に使うので覚えましょう！

■pull
　git pullは、リモートリポジトリの変更をローカルリポジトリに反映させるコマンドです。他の開発者が行った変更や、リモートリポジトリに追加された新しい変更を取得します。これにより、ローカルブランチが最新の状態になり、他の開発者の変更を反映することができます。

git pullの使い方

git pull ＜remote＞＜branch＞
・＜remote＞：プルする対象のリモートリポジトリの名前を指定
・＜branch＞：プルするリモートブランチの名前を指定

　例えば、

git pull origin main

　は、originと呼ばれるリモートリポジトリのmainブランチの変更を取得し、現在のローカルブランチにマージします。一番使うタイミングは自分のブランチが無事統合された後、ローカルリポジトリの構成をリモートリポジトリに合わせるときです。

　これを行わないと、「いま追加した機能が反映されてない！？なんで！？」っとなってしまいます。（僕はなりました）。

　この時に自分がmainブランチにいることを確認しましょう。そうしないと、「pullしたのに反映されててない！？なんで！？！？」っとなってしまいます（僕はなりました）。

　ブランチを移動するには git switch を使用してください。

■add
　git addは、変更されたファイルをインデックスに追加するためのコマンドです。
　インデックスは、次の変更を準備する場所であり、git addコマンドを使用してファイルをインデックスに追加します。

git addの使い方
1.特定の変更されたファイルを追加する場合：

git add ＜ファイルパス＞

2.複数の変更されたファイルを追加する場合：

git add ＜ファイルパス1＞＜ファイルパス2＞ ...

3.すべての変更されたファイルを追加する場合：

git add .

・＜ファイルパス＞：インデックスに追加するファイルのパスを指定。
・.：現在のディレクトリ以下のすべての変更されたファイルを指定。

　git addコマンドを実行した後、git statusコマンドを使用することで、インデックスの状態を確認することができます。

　git statusコマンドにより、インデックスに追加されたファイルや、まだ追加されていない変更されたファイルを確認できます。

インデックスに追加されたファイルは、git commitコマンドを使用してリポジトリの履歴に記録することができます。

■commit
　git commitは、変更内容をリポジトリに記録するためのコマンドです。コミットは、ファイルの変更をリポジトリに永続的に保存し、変更の内容を説明するメッセージを付けることができます。

git commitの使い方

git commit -m "コミットメッセージ"

・-m（オプション）：コミットメッセージを指定するために使用。
・"コミットメッセージ"：変更内容を説明する簡潔かつ明確なメッセージを指定。

　-mオプションを使用しないと、実行した際、別ウィンドウが開いてそっちにコメントを書き込んで......っと手間が増えるだけなので、基本的にコミットを出す場合は -m を付けましょう！

■push
　git pushは、ローカルリポジトリの変更をリモートリポジトリに送信するためのコマンドです。git pushコマンドを使用することで、ローカルリポジトリで行った変更をリモートリポジトリに反映させることができます。

git pushの使い方

git push ＜リモート名＞＜ブランチ名＞ git push -u origin HEAD // ブランチ作成後初めてのプッシュはこれ！！！
・＜リモート名＞：プッシュ先のリモートリポジトリの名前を指定。
・＜ブランチ名＞：プッシュするブランチの名前を指定。

　例えば、

git push origin main

は、ローカルリポジトリのmainブランチの変更をリモートリポジトリのmainブランチにプッシュします。

■stash
　git stashは、現在の変更を一時的に退避させるためのコマンドです。git stashコマンドを使用すると、ワークスペースとインデックスの変更を保存し、ワークスペースを最新のコミット状態に戻すことができます。

1.作業中の変更を一時的に退避させる：
・現在の作業を中断して、別のタスクに切り替える必要がある場合に使用します。
・git stashコマンドを実行することで、現在の変更を退避させ、ワークディレクトリを整理することができます。

2.ブランチを切り替える前に変更を保存する：
・現在のブランチで作業中の変更があるが、別のブランチに切り替える必要がある場合に使用します。
・git stashコマンドを使用して変更を退避させてから、ブランチを切り替えることができます。

git stashの使い方
・変更を退避させる：

　git stash

・コメント付きで退避させる(save)：

　git stash save "コメント"

・退避させた変更を確認する(list)：

　git stash list

・退避させた変更を適用し、stashリストから削除する(pop)：

　git stash pop

・未追跡（addされたことがない）ファイルも退避する(-u)：

　git stash -u

・無視された（.gitignore）ファイルも退避する(-a)：

　git stash -a

　git stashコマンドを実行すると、現在の変更が退避され、インデックスは最新のコミット状態に戻ります。

　退避された変更は、git stash listコマンドで確認することができます。退避された変更を再度適用するには、git stash applyコマンドを使用します。これにより、退避された変更がワークディレクトリに適用されます。git stash popコマンドを使用すると、退避された変更を適用し、同時にstashリストから削除することができます。

　これを使う状況は、
「よ～しPRだしたから今のうちに別のところ進めるぞ～」
（PRが通って無事マージ後...）
「マージされたからpullするぞ～」
↑これです。

　おそらく、git switch でブランチを移動するときに「変更内容をコミットして！」と言われます。この、コミットしていない変更内容を一時的に退避できるのがstashです。
（基本的に作業内容別にブランチは切りましょう）

■log
　git logは、Gitリポジトリのコミット履歴を表示するためのコマンドです。git logコマンドを実行すると、リポジトリ内の過去のコミットの情報を確認することができます。

git logが表示する情報

1.コミットハッシュ：各コミットを一意に識別するための英数字の文字列。
2.コミットの作者：コミットを作成した人の名前とメールアドレス。
3.コミットの日時：コミットが作成された日時。
4.コミットメッセージ：コミットの内容を説明するメッセージ。

git logの使い方

　git log

　このコマンドを実行すると、リポジトリのコミット履歴が新しいコミットから古いコミットの順に表示されます。各コミットの情報は、コミットハッシュ、作者、日時、コミットメッセージの順に表示されます。

　git logコマンドには、様々なオプションやフォーマット指定が用意されています。よく使用されるオプションの一部を紹介します。

・git log --oneline：各コミットを1行で簡潔に表示。
・git log --graph：コミット履歴をグラフ形式で表示。
・git log --decorate：ブランチやタグ情報を表示。
・git log --author=""：特定の作者のコミットのみを表示。
・git log --since=""：指定した日付以降のコミットを表示。
・git log --until=""：指定した日付以前のコミットを表示。
・git log --grep=""：コミットメッセージに特定のパターンを含むコミットを表示。

 
　これらのオプションを組み合わせることで、コミット履歴の表示をカスタマイズすることができます。

　例えば、

git log --oneline --graph --decorate

　は、コミット履歴を1行で表示し、グラフ形式でブランチやタグ情報を含めて表示します。qを押すとログから脱出できます！

■reflog

　git reflogは、ローカルリポジトリでのコマンド操作を一覧で表示するコマンドです。これは単純に自分が行った操作を確認したいときや間違った操作を取り消したいとき、間違って削除したコミットを復元するときに役に立ちます。

■cherry-pick
　git cherry-pickは、ある特定のコミットを現在のブランチに適用するためのコマンドです。これは機能開発が完了し、別のブランチにマージする前に、複数のコミットを整理したい場合に使用されます。

git cherry-pickの使い方

1.移動先のブランチに切り替えます:

　git switch ＜branch-name＞

2.移動したいコミットのハッシュ値（git log で確認できます！）を指定してgit cherry-pickコマンドを実行します:

　git cherry-pick ＜commit-hash＞

3.コミットが適用されたことを確認します:

　git log

4.複数のコミットを一度に移動する場合は、コミットのハッシュ値をスペースで区切って指定します:

　git cherry-pick ＜commit-hash1＞＜commit-hash2＞ ＜commit-hash3＞

　git cherry-pickコマンドを使用する際は、コミットの適用順序に注意してください。コミットの適用順序が変わると、コンフリクトが発生する可能性があります。また、git cherry-pickコマンドは、コミットを完全に複製するため、コミットのハッシュ値が変更されます。これにより、コミット履歴が変更されることになるので、注意が必要です。

■revert
　git revertは、特定のコミットを取り消すためのコマンドです。
git revertコマンドは、指定したコミットの変更を元に戻すために、新しいコミットを作成します。

git revertの使い方

　git revert ＜commit＞

＜commit＞：取り消したいコミットのハッシュ値を主に指定。

git revertの動作
1.指定したコミットの変更を元に戻すための新しいコミットが作成されます。
2.新しいコミットには、元のコミットを取り消すためのメッセージが自動的に追加されます。
3.取り消しのコミットがリポジトリに追加され、現在のブランチが更新されます。

git revertを使用する状況

1.特定のコミットの変更を取り消す：
　過去のコミットで行われた変更を取り消すことができます。これは、バグの修正や機能の削除などの場合に便利です。

2.リモートリポジトリにプッシュ済みのコミットを取り消す：
　リモートリポジトリにプッシュ済みのコミットを取り消すための安全な方法です。git resetコマンドとは異なり、git revertコマンドは既存の履歴を変更せず、新しいコミットを作成するため、他の開発者との競合を避けることができます。

プルリクエストとは

　さて、これまでの説明を聞いた段階ではプッシュした変更点はすぐにリモートリポジトリにマージされると思ってる方もいると思います。実際にはそうではなく、Pull Request（プルリクエスト）を作成する必要があります。

　プルリクエスト（以下、PR）は自身のコードの変更点をチームメンバーにレビューしてもらい、コードの品質やバグの有無、改善点などをチェックしてもらう機能になります。以下は初めてブランチを作成しプッシュを行った時のGit Bashの画像です。

　PRするとたくさん文字が出てきましたが、注目してもらいたいところは赤枠の部分です。「Create a pull request for ...」と書いてあってその下にURLがあります。このURLをクリックすることでPRの作成画面に飛ぶことが出来ます！

　ちなみに、web上のGitHubでもPullRequestタブをクリックすると上のほうに

　と出てくるのでここからでもPRを作ることが出来ます。

プルリクエストの作成画面

　重要な部分を紹介します。

・title（タイトル）：
　後述するGitmojiとPRの内容をチームメンバーが見たときに理解しやすいように書きましょう。

・description（説明）：
　変更内容について細かく・わかりやすく書きましょう。チーム・会社によってテンプレートが設定されている場合もあるのでそれにそって書くとよいです。

・Reviewers（レビュアー）：
　レビューしてほしい人のGitアカウントを追加しましょう。PRが作成されるとここに追加された人に通知が飛びます。slackなどと連携している場合はそちらにも通知が飛びます。ここに追加した人から承認がもらえればマージすることが出来ます。

・Assignees：
　レビューを受ける人（主に自分）のGitアカウントを追加しましょう。自分を追加する場合は「Assigness」の右下、「assign yourself」をクリックしてください。記入した内容に間違いがなければ緑のボタン「Create pull request」をクリックしてPRを作成してください！

プルリクエストとレビューの流れ

　PRが作成されると以下のような画面になります。ここでレビュアーとのコミュニケーションを行いコードの最適化を行います。

Gitmoji

　PR名やコミット名にはGitmojiを使用することを心がけましょう！ 絵文字の種類については以下のホームページを参照してください。

gitmoji | An emoji guide for your commit messages

　ここでは使用できるGitmoijとその用途について説明されています。変更内容に応じて絵文字を使い分けましょう！

　使い方はとても簡単で、記入欄に「:」から始まる単語を入力すると候補が出てくるので用途にあったものを選択してください！

　Gitmoijを使用して作業の透明化・効率化を図りましょう！

コンフリクト とは

　度々「コンフリクト」という単語が出てきて戸惑っている方もいると思います。コンフリクト（衝突）とは、同じファイルの同じ部分を複数の人が同時に変更したときに発生する状態のことです。次の図を見てください。

　この図ではAさんとBさんが同じファイルの同じ行（10行目）を同時に編集しようとしています。ここで、Aさんがプッシュしたあと、遅れてBさんがプッシュすると、Aさんは問題なくマージされますが、Bさんはコンフリクトが発生します。

　具体的な説明をすると、以下のようになります。

1.AさんとBさんはそれぞれのローカルリポジトリで異なる編集をしました。
2.ここでそれぞれpushすると異なる内容のコミットが記録されます。
3.Aさんが先にプッシュするとリモートリポジトリにはAさんの変更内容が反映されます。
4.Bさんが後からプッシュすると、GitはリモートリポジトリとBさんのローカルリポジトリの変更内容の比較をします。
5.ここで変更内容の競合があることが検知されます。

■コンフリクトの発生例
　コンフリクトは次のような状況で発生します。
事例1: 同じ行を同時に変更した場合
1.開発者Aが file.txt の10行目を This is a new line. に変更し、コミットしました。
2.同時に、開発者Bも file.txt の10行目を This is another line. に変更し、コミットしました。
3.開発者Aがプッシュを実行すると、成功します。
4.開発者Bがプッシュを実行すると、コンフリクトが発生します。

事例2: 同じファイルの異なる行を変更した場合
1.開発者Aが file.txt の5行目を This is a new line. に変更し、コミットしました。
2.同時に、開発者Bが file.txt の10行目を This is another line. に変更し、コミットしました。
3.開発者Aがプッシュを実行すると、成功します。
4.開発者Bがプルを実行すると、コンフリクトは発生しません。
　ただし、開発者Bが file.txt を開くと、開発者Aの変更と開発者Bの変更が両方含まれています。

事例3: ファイルの削除と変更が競合した場合
1.開発者Aが file.txt を削除し、コミットしました。
2.同時に、開発者Bが file.txt の内容を変更し、コミットしました。
3.開発者Aがプッシュを実行すると、成功します。
4.開発者Bがプルを実行すると、コンフリクトが発生します。
　Gitは、ファイルが削除されたことと変更されたことの両方を検知します。

事例4: マージ中にコンフリクトが発生した場合
1.開発者Aが feature ブランチを作成し、 file.txt を変更してコミットしました。
2.同時に、開発者Bが main ブランチで file.txt を変更し、コミットしました。
3.開発者Aが feature ブランチの変更を main ブランチにマージしようとすると、コンフリクトが発生します。

■コンフリクトの対処方法
　コンフリクトが発生したことはGitHubのPR画面から確認できます。下にスクロールすると以下の記載があります。

【通常】

【コンフリ発生時】

　上記のように表示されていた場合、コンフリが発生しています。内容を見ると、

"This branch has conflict that must be resolved" 
（訳：このブランチには解決する必要があるコンフリがあります。） 
Conflicting files ＜コンフリしたファイルのパス＞

と親切にコンフリした場所まで書いてあります。ではエディターで実際にそのファイルを見てみましょう。まずブランチを切り替えます。 git switch でコンフリが発生したブランチに切り替えてください。

git switch ＜ブランチ名＞

　次にローカルリポジトリにリモートリポジトリの変更点を反映させましょう。

git pull --rebase origin ＜マージ先のブランチ＞

　すると、次のような画面が開くと思います。（VSCodeの場合）

Accept Current Change | Accept Incoming Change | Accept Both Changes | Compare Changes ＜＜＜＜＜＜HEAD (Current Change)

自分が変更した内容が表示されています！
（例だとBさんの内容 "value = b"）

=======

リモートリポジトリで保存されている内容が表示されます！
（例だとAさんの内容 "value = a;"）
＞＞＞＞＞＞ e5f6g7h (Incoming Change)

　この画面でコンフリの解消を行います。一番上に選択肢が書かれており左から、

1.Accept Current Change（現在の変更を受け入れる）：
　ローカルリポジトリの変更が採用され、リモートリポジトリからの変更は破棄されます。つまり、「=======」より上の内容が保持され、下の内容が削除されます。

2.Accept Incoming Change（受信した変更を受け入れる）：
　リモートリポジトリからの変更が採用され、ローカルリポジトリの変更は破棄されます。つまり、「=======」より下の内容が保持され、上の内容が削除されます。

3.Accept Both Changes（両方の変更を受け入れる）：
　ローカルリポジトリとリモートリポジトリの両方の変更が保持されます。コンフリクトマーカー（＜＜＜＜＜＜と=======と＞＞＞＞＞＞）は削除されますが、両方の変更が順番に残ります。必要に応じて手動で変更を調整する必要があります。

4.Compare Changes（変更を比較する）：
　ローカルリポジトリとリモートリポジトリの変更を並べて比較することができます。VSCodeの差分ビューアが開き、両方の変更が表示されます。変更を比較して、最終的にどちらの変更を採用するか、または両方の変更をどのように組み合わせるかを決定できます。

となっているので、適切なものを選択してください！！

　コンフリが解消出来たらコミットを書き換えます。

git add ＜コンフリしたファイル＞
git rebase --continue

　最後にプッシュなんですが、ここでは普通にgit pushでは通りません。なぜなら、コミット履歴を変更しているからです。プッシュするには以下のようにします。

git push --force-with-lease

　これでコンフリクトを解消することが出来ました。（ｨｪｨ!）

使用例（チートシート）

　次は今紹介したコマンドの実際の使用例を紹介していきます。
■新しくブランチを作る

git switch main

　main相当のブランチへ移動する

git pull

　ローカルリポジトリを最新の状態に更新する

git switch ＜ブランチ名＞

　ブランチを作りたいブランチへ移動する

git switch -c ＜ブランチ名＞

　ブランチの作成する

■変更結果をプッシュする

git status

　現在の状態を確認する（変更したファイル名が赤色で表示されている）。

git add ＜変更したファイルのパス＞

　変更したファイルをステージする

git status

　ステージされているか確認する（文字の色が緑になっていればOK！）

git commit -m "変更点の内容"

　ステージされたファイルをコミットする

git status

　コミットできているか確認する

git push（初回は git push -u origin HEAD）

　コミットしたファイルをプッシュする

■ブランチがマージされた後変更点を退避させる

git status

　現在の状態を確認する（変更したファイル名が赤色で表示されている）

git stash -u

　変更したファイルを一時退避する。

git status

　現在の状態を確認する（赤色のファイルが消えていれば成功）

git switch main

　main相当のブランチへ移動する

git pull

　ローカルリポジトリを最新の状態に更新する

git switch ＜ブランチ名＞

　ブランチを作りたいブランチに移動する

git switch -c ＜ブランチ名＞

　新しくブランチを作成する

git stash pop

　退避させた内容を新しくブランチに配置する。

■コンフリクトが発生した場合

git pull --rebase origin main

　コンフリクトが起きたファイルを確認・修正する。

git add ＜変更したファイルのパス＞

　変更したファイルをステージする。

git rebase --continue

　コミットを変更する。問題ない場合は保存して閉じる

git push --force-with-lease

　コミットのプッシュする。

おわりに

お疲れさまでした！！！！

　......とまぁ長々と書きましたが、一番大切なことは恥ずかしがらずに先輩・同僚に聞くです。この記事を書いている最中でも3回くらいやらかしたので詳しい方に見てもらってました（笑）

　正直、一時恥ずかしい思いをするよりも、ミスを隠して重大なインシデントになるほうがしんどいですからね...... 僕も頑張るので皆さんも頑張りましょう！！！！！！

　それでは、お仕事頑張ってください～

江藤皓史／FIXER
有明高専卒24入社
チョコミント/TRPG/まーちゃんごめんね

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER