GitHubの超超超基本的なつかいかた | cloud.config Tech Blog

本記事はFIXER Advent Calendar 2024（ FIXER Advent Calendar 2024 ～ルーキー編〜）12月2日の記事です。

はじめに

この記事ではGitHubの基本的な使い方について紹介していきます。

僕は高専を卒業後、新卒でFIXERに入社しましたが、これまでGitHubを触ったことがなく非常に苦労しました。

その際、自分用にメモしていた内容がまとまってきたため、今回記事として公開することにしました。

なお、本記事の作成には生成AI（GaiXer）を使用しています。

この記事は長いですが、僕が伝えたいことは以下です。

恥ずかしがらずに先輩・同僚に聞く

また、記事の中で太字にしている部分が重要なポイントです。

少しでも皆さんの理解の助けになればと思います。

この記事ではかわいいフリー素材集いらすとや (irasutoya.com)の画像を使用しています。

それでは早速始めましょう！

GitHub とは

GaiXerに聞いてみました。

場所

Gitを利用するにあたって最初に理解しておくべきポイントは「場所」です。

これを理解しておかないと、

「思ってたのと違うところにマージしちゃった！」
「ほかの人のファイルを統合しちゃった！！」

などのインシデントを起こしてしまうので気を付けましょう。

もし、上記のようなことが起こった場合は、

自己判断で修正を試みるのではなく、すぐに上司やリーダーに報告してください。

操作によっては変更を元に戻せない場合もあるため、慌てずに必ず報告するようにしましょう。

前置きが長くなりましたが、Gitにおける「場所」について説明します。

全体図

初めに「場所」についての全体図を記載しておきます。

今はわからないと思いますが、この記事を読み終わったらな～んとなくわかるようになると思います。

Repository（リポジトリ）

Gitにおけて、プロジェクトファイルの保存場所を「リポジトリ」と言います。

リポジトリは次のような役割を持っています。

バージョン管理：
各ファイルの変更履歴を追跡します。
過去のバージョンに戻ったり、変更内容を比較したりすることができます。
共同作業：
リポジトリは、複数の開発者が作業するための中央の場所として機能します。
各開発者はリポジトリを自分のローカル環境にコピーし、変更を加え、
完了したらリモートリポジトリにプッシュして、他の開発者と変更内容を共有できます。
バックアップ：
リモートリポジトリにプッシュすることで、ローカル環境だけでなく、
別の場所にもプロジェクトのコピーが保存されます。
これによりデータ損失のリスクを軽減できます。

また、リポジトリは２種類あります。

それはローカルリポジトリとリモートリポジトリです。

ローカルリポジトリ：自身のPC上のファイルの保存場所

リモートリポジトリ：インターネット上のファイルの保存場所

Workspace（ワークスペース）

実際に作業をする場所のことを「ワークスペース」と呼びます。

リモートリポジトリをクローン（複製）したローカルコピーのことです。

開発では、ワークスペースでファイルを直接変更しし、機能の追加・編集・削除を行います。

ワークスペースには「Working Tree」や「Working Directory」、「Local Copy」など様々な呼び方がありますが、全て同じ意味なので混乱しないでください。

Index（インデックス）

ワークスペースで変更を加えた後、変更を反映させる前に変更内容を追加・記録する必要があります。

この変更点を追加する場所を「インデックス」と呼びます。

インデックスに変更を追加することで、変更内容をリモートリポジトリへ反映させられるようになります。

インデックスのことを「ステージングエリア」とも言い、変更内容を追加することを「ステージ」といいます。

以上が場所に関しての説明になります。

次はGitHubで最も重要な概念である「ブランチ」についてです。

ブランチ

メインの開発ラインから独立された開発ラインを「ブランチ」と言います。

ブランチは以下のような機能があります。

独立性：
各ブランチは、他のブランチと独立しており、変更内容が他ブランチに影響を与えません。
これにより新機能の開発やバグ修正を安全に行うことができます。
並行開発：
複数の開発者が同時に異なる機能開発やバグ修正を行うことができます。
各開発者が自分のブランチで作業することで開発のスピードアップと効率が向上します。
実験的な変更：
実験的な変更や新しいアイデアを試すことができます。
実験が成功した場合は、メインブランチにマージし、
失敗した場合は、ブランチを削除するだけで済みます。
コードレビューとコラボレーション：
プルリクエスト（Pull Request）を作成し、他の開発者からのレビューやフィードバックを受け取れます。
これにより、コードの品質向上とチームのコラボレーションが促進されます。

ブランチはなにがいいの？

ブランチにを使用する利点について紹介しましたが、

次は具体的な事例を交えて説明します。

事例：オンラインショッピングサイトの開発

ブランチを利用していない場合

開発者AとBが同じメインブランチで作業を行っています。
開発者Aは新しい決済機能を実装し、開発者Bはユーザープロフィールの編集機能を実装しています。
開発者Aが決済機能を実装している途中で、バグが発生しました。
このバグはメインブランチに取り込まれてしまいます。
開発者Bは、ユーザープロフィール編集機能を実装するために、
バグを含むメインブランチを元に作業を行わなければなりません。
バグの修正とユーザープロフィール編集機能の実装が混在し、開発が混乱します。
メインブランチに不安定な状態のコードがコミットされるため、リリースが遅れる可能性があります。

ブランチを利用した場合

開発者Aは決済機能用のブランチ（payment-feature）を作成し、
開発者Bはユーザープロフィール編集機能用のブランチ（profile-edit-feature）を作成します。
開発者Aは決済機能を実装し、開発者Bはユーザープロフィール編集機能を実装します。
それぞれのブランチで独立して作業を進めます。
開発者Aが決済機能を実装している途中で、バグが発生しました。
このバグは決済機能用のブランチ内にとどまり、他ブランチには影響しません。
開発者Bは、ユーザープロフィール編集機能の実装を問題なく進めることができます。
開発者Aは、バグを修正し、決済機能の実装を完了します。
ユーザープロフィール編集機能用のブランチは、レビューとテストを経て、
メインブランチにマージされます。
決済機能用のブランチも、レビューとテストを経て、メインブランチにマージされます。
メインブランチは常に安定した状態を保たれ、リリースを予定通りに行うことができました。

Git コマンド一覧

次は実際にGit Bashに入力することになるコマンドについて紹介します。

ここでは最低限しか紹介しないので詳しくは自分で調べてみてください。

全体図

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

branch

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

`git branch`の使い方

ブランチの一覧表示：
```
git branch
```
現在のリポジトリにあるブランチの一覧が表示されます。
現在のブランチの前には*が表示されます。
ブランチの削除：
```
git branch -d <削除するブランチ名>
```
指定したブランチが削除されます。
ただし、削除するブランチにマージされていない変更がある場合は削除できません。
強制的に削除する場合は-Dオプションを使用します。
ブランチの名前変更：
```
git branch -m <古いブランチ名> <新しいブランチ名>
```
指定したブランチの名前が変更されます。

switch

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

`git switch`の使い方

既存のブランチに切り替える場合：
```
git switch <branch>
```
新しいブランチを作成し、切り替える場合：
```
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`の使い方

特定の変更されたファイルを追加する場合：
```
git add <ファイルパス>
```
複数の変更されたファイルを追加する場合：
```
git add <ファイルパス1> <ファイルパス2> ...
```
すべての変更されたファイルを追加する場合：
```
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コマンドを使用すると、ワークスペースとインデックスの変更を保存し、

ワークスペースを最新のコミット状態に戻すことができます。

作業中の変更を一時的に退避させる：
- 現在の作業を中断して、別のタスクに切り替える必要がある場合に使用します。
- git stashコマンドを実行することで、現在の変更を退避させ、ワークディレクトリを整理することができます。
ブランチを切り替える前に変更を保存する：
- 現在のブランチで作業中の変更があるが、別のブランチに切り替える必要がある場合に使用します。
- 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`が表示する情報

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

`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`の使い方

移動先のブランチに切り替えます:
```
git switch <branch-name>
```
移動したいコミットのハッシュ値（git log で確認できます！）を指定して
git cherry-pickコマンドを実行します:
```
git cherry-pick <commit-hash>
```
コミットが適用されたことを確認します:
```
git log
```
複数のコミットを一度に移動する場合は、コミットのハッシュ値をスペースで区切って指定します:
```
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`の動作

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

`git revert`を使用する状況

特定のコミットの変更を取り消す：
過去のコミットで行われた変更を取り消すことができます。
これは、バグの修正や機能の削除などの場合に便利です。
リモートリポジトリにプッシュ済みのコミットを取り消す：
リモートリポジトリにプッシュ済みのコミットを取り消すための安全な方法です。
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さんが同じファイルの同じ行（１０行目）を同時に編集しようとしています。

ここで、Aさんがプッシュしたあと、遅れてBさんがプッシュすると、

Aさんは問題なくマージされますが、Bさんはコンフリクトが発生します。

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

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

コンフリクトの発生例

コンフリクトは次のような状況で発生します。

事例1: 同じ行を同時に変更した場合

開発者Aが file.txt の10行目を This is a new line. に変更し、コミットしました。
同時に、開発者Bも file.txt の10行目を This is another line. に変更し、コミットしました。
開発者Aがプッシュを実行すると、成功します。
開発者Bがプッシュを実行すると、コンフリクトが発生します。

事例2: 同じファイルの異なる行を変更した場合

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

事例3: ファイルの削除と変更が競合した場合

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

事例4: マージ中にコンフリクトが発生した場合

開発者Aが feature ブランチを作成し、 file.txt を変更してコミットしました。
同時に、開発者Bが main ブランチで file.txt を変更し、コミットしました。
開発者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)

この画面でコンフリの解消を行います。

一番上に選択肢が書かれており左から、

Accept Current Change（現在の変更を受け入れる）:
ローカルリポジトリの変更が採用され、リモートリポジトリからの変更は破棄されます。
つまり、「=======」より上の内容が保持され、下の内容が削除されます。
Accept Incoming Change（受信した変更を受け入れる）:
リモートリポジトリからの変更が採用され、ローカルリポジトリの変更は破棄されます。
つまり、「=======」より下の内容が保持され、上の内容が削除されます。
Accept Both Changes（両方の変更を受け入れる）:
ローカルリポジトリとリモートリポジトリの両方の変更が保持されます。
コンフリクトマーカー（<<<<<<と=======と>>>>>>）は削除されますが、
両方の変更が順番に残ります。必要に応じて手動で変更を調整する必要があります。
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
```
コミットのプッシュする。

おわりに

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

......とまぁ長々と書きましたが、一番大切なことは

恥ずかしがらずに先輩・同僚に聞く

です。この記事を書いている最中でも３回くらいやらかしたので詳しい方に見てもらってました（笑）

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

僕も頑張るので皆さんも頑張りましょう！！！！！！

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

はじめに

GitHub とは

場所

全体図

Repository（リポジトリ）

Workspace（ワークスペース）

Index（インデックス）

ブランチ

ブランチはなにがいいの？

事例：オンラインショッピングサイトの開発

ブランチを利用していない場合

ブランチを利用した場合

Git コマンド 一覧

全体図

branch

git branchの使い方

switch

git switchの使い方

status

pull

git pullの使い方

add

git addの使い方

commit

git commitの使い方

push

git pushの使い方

stash

git stashの使い方

log

git logが表示する情報

git logの使い方

reflog

cherry-pick

git cherry-pickの使い方

revert

git revertの使い方

git revertの動作

git revertを使用する状況

プルリクエスト とは

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

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

Gitmoji

コンフリクト とは

コンフリクトの発生例

事例1: 同じ行を同時に変更した場合

事例2: 同じファイルの異なる行を変更した場合

事例3: ファイルの削除と変更が競合した場合

事例4: マージ中にコンフリクトが発生した場合

コンフリクトの対処方法

使用例（チートシート）

新しくブランチを作る

変更結果をプッシュする

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

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

おわりに

Git コマンド一覧

`git branch`の使い方

`git switch`の使い方

`git pull`の使い方

`git add`の使い方

`git commit`の使い方

`git push`の使い方

`git stash`の使い方

`git log`が表示する情報

`git log`の使い方

`git cherry-pick`の使い方

`git revert`の使い方

`git revert`の動作

`git revert`を使用する状況

プルリクエストとは

コンフリクトとは