主にGitのメリットや、Gitに関連した用語の意味・それぞれの関係性など、私なりに調べ整理し、忘れないようにいつでも思い出せるようにアウトプットした記事です。

＜Gitを理解しよう＞

Git とは？

Gitとは分散型バージョン管理システムの一つ。ソースコードを効果的に管理できる。

Gitはチーム開発のときに役に立つ

独学など実際に１人でやるときは、Gitのメリットをあまり感じられないかもしれない（現に私がそうです...）。ですが複数人などで行うチーム開発の時に役に立つ。

いつ誰が、どのファイルを作成・編集・修正したのかがわかやすい

Gitでファイルを管理すると、更新履歴が自動で保存される。

他人の編集したファイルの上書きを防ぐことができる

「同一のファイルを編集・上書きをしてしまって、先に編集した人の変更内容が消えてしまった！」を防ぐことができる。Gitではこうなった場合に、警告が出る。

Gitに存在するリポジトリ

Gitには、ファイルやディレクトリ（Gitの管理下）の変更履歴を記録・保管しておく入れ物”リポジトリ”というものがある。リポジトリには「ローカルリポジトリ」と「リモートリポジトリ」の２つがある。

ローカルリポジトリ

自分のPC上に置くリポジトリ。自分のPC上にあるファイルやディレクトリのバージョン管理を行いたいときに使う。

リモートリポジトリ

外部サーバーなどのネットワーク上に置くリポジトリ。後に説明するGithubがこれにあたる。

リモートリポジトリ上（ネットワーク）にあるデータやファイルをローカルリポジトリ上（自分のPC）へ取得し、データの編集を行う。編集したデータをリモートリポジトリへ同期・反映するというのが、ざっくりとした流れ。

インデックス

バージョンを記録するためにファイルを一時的に登録する場所。インデックスに登録されているファイル群の変更が記録されます。

＜Githubは、「Git」の仕組みを使ったサービス＞

Githubはバージョン管理システム「Git」の仕組みを使って、世界中のプログラマーが自分の作品を保存し、公開することができるようにしたサービス。もう少し専門的に言えば、"オープンソースソフトウェアのホスティングサービス"。

”チーム開発”という観点で説明すると、「自分が作ったプログラムを公開し、チーム全員で管理する”リモート環境（リモートリポジトリ）”」が必要であると言えば良いか。
”オープンソース”ということで、世界中の超天才プログラマーたちが作った「大変便利な機能」を無料で閲覧・利用することができる（良い時代になったものですね...）。

Github Desktopは、「Github」を利用した開発を簡単にするためのプログラム

Githubとのやりとりは、ターミナル上で操作する必要がある。
だがしかし！、Github Desktopがあれば、わざわざ記述せずとも、ワンポチでできる！さらに目視で状況がわかる！（言葉だと響かないと思うので、実際にGithub Desktopがない時とある時で比較してみてください。）

Github Desktopの流れ

実際に１つ１つの操作名ややっていることの羅列だけではどうしても忘れてしまう。（人間だもの、忘れてナンボ）
なのでプロトコルという形で実際に「どういう手順で、かつここではどんなことをしているのか」を説明します。

①クローン

リモートリポジトリを複製してローカルリポジトリを作成すること。
クローンを行うとリモートリポジトリの内容をそのままダウンロードすることが出来る。

②ブランチ作成

クローンができたら、トピックブランチを作成する。ブランチ名は、「どんなことをしたのか」がわかるようにすること。

（インデックス　※実際の手順には含まれないが、大事な用語）

コミットするファイルを登録するための場所。ファイルをコミットすると、インデックスに登録されているファイル群の変更が記録される。
インデックスに登録したファイル単位が一つのコミットとなるために、どのファイルをインデックスに登録するかを決める必要がある。一度に多くのファイルを変更した際に、どのファイル単位でコミットするかを選択するためにインデックスを使用する。

④コミット

ファイルやディレクトリの追加・変更を、リポジトリに記録するための操作。コミットメッセージ作成し、コミットをするという流れ。
【重要！】１機能１コミットメッセージしてコミットすること。
　（理由）ファイルを元に戻すときはコミットごとでしか戻せないため。
　　　　　コミットをする前に、前述のインデックスのことを考えよう。

⑤プッシュ

ローカルリポジトリ上の内容を、リモートリポジトリ上（Github）に反映・同期する。

⑥プルリクエスト

masterブランチにマージをする前に、チームの仲間に確認をもらう。
「何を作成・変更したのか (# Whtat)と、なぜそうしたのか(# Why)」を明確にしょう。

⑦LGTMをもらう

「Looks Good To Me」の略。プルリクエストした内容が問題なければ「LGTM」とコメントをもらう。IT界の合言葉。

⑧マージ

作成したトピックブランチとその変更内容を、masterブランチへ統合（マージ）する。マージしたらトピックブランチは削除しよう。

⑨プル

リモートリポジトリにおいて変更が更新された内容を、ローカルリポジトリ上に取得する。

＜終わりと参考URL＞

　とまあ、こんな感じに書いてはみました。始めたばかりでまだ荒い部分はあります。実際使うと様々なトラブルもあれば、もっと奥深く使えるみたいですね。下記の参考URLを大分受け売りしている記事ですが...第一歩として更なる飛躍を目指します。
　経験豊富な方、「これは違うんじゃないの？」「これも知っておくといいよ」といった知見があれば、ぜひコメントをお願いします。

＜参考URL＞
https://backlog.com/ja/git-tutorial/intro/01/