こんにちは、コーディング課3回生のguuです。
RiG++でよく使われているGithubとは何なのかについて、今回の記事から説明していこうと思います。

今回の記事では、使い方は説明していません。

GitHubの使い方については次回以降の記事を参照してください。

「Githubとは？」、「プッシュって何？」みたいな基礎的な部分や用語の解説を行います。

GitHubの辞書代わりに使ってください。

GitHub概要

複数人で同じプロジェクトを開発する際に、

自分の変更が他の人の変更で上書きされてる

やらかした、変更を元に戻したい

といった問題がよく発生します。

そんな時に便利なのがGitHubです。

GitHubを使えば、チームのプロジェクトをあたかも自分専用のプロジェクトのように扱い、必要な変更だけをチームのプロジェクトに反映することができます。

さらに、バージョン管理が可能なため、チームのプロジェクトを過去の状態に戻すことも簡単に行えます。

ちなみに、この機能はもともとコマンド入力で操作していましたが、GitHubの登場により、オンライン上でマウス操作を使って直感的に使えるようになりました。

GitHub用語解説

よく使う用語だけ解説します。

リポジトリ(repository)

リポジトリは、チーム(または自分)のプロジェクトのことです。

もうちょっと具体的に言うと、プロジェクトのファイルやディレクトリ、そしてそれらの変更履歴を管理する場所のことです。

ローカルリポジトリ

自分のパソコン上のリポジトリ(プロジェクト)のことです。

使うことができるのは自分だけです。

リモートリポジトリ

インターネット上のリポジトリ(プロジェクト)のことです。

チームメンバーみんなが使えます。

クローン(clone)

リモートリポジトリ(オンライン上のプロジェクト)を自分のPCにコピーすることです。

フォーク(fork)

他の人のリモートリポジトリ（オンライン上のプロジェクト）を自分のGitHubアカウント下にコピーすることです。

フォークしたリポジトリは、自分のアカウントで独立して管理されるため、元のリポジトリの変更の影響を受けず、また自分の変更も元のリポジトリには影響を与えません。

ブランチ(branch)

現在のプロジェクトを枝分かれさせて作成する、独立した作業空間のことです。

イメージ的には、チームのプロジェクトを自分だけのプロジェクトにして、好き勝手出来るようにするみたいな感じです。

よくやるのは、新しい機能を追加するときに、最新のプロジェクトからブランチを作成（ブランチを切る）し、その上で開発を進めます。

この変更は後から、元のプロジェクトに統合できます。

マスターブランチ(master branch)

プロジェクトの主要なブランチであり、最終的に製品としてリリースされるブランチです。

このブランチは、常にバグがない状態であることが理想です。

なので、基本的には、直接操作せず、機能追加や修正は別のブランチで行い、変更が完成したらこのブランチに統合したほうが良いです。

ローカルブランチ

自分のPC上に存在するブランチです。

変更を加えても、他のチームメンバーには影響しません。

リモートブランチ

リモートリポジトリ(オンライン上のプロジェクト)に存在するブランチです。

チームメンバーがこのブランチを閲覧、変更できます。

たいていの場合は、ローカルブランチとリモートブランチは同期(変更を共有)させておきます。

チェックアウト(check out)

ブランチを切り替える操作のことです。

他のブランチで作業したいときに行います。

スタッシュ(stash)

作業中の変更を一時的に退避させることです。

ブランチを切り替えるときに、現在触っている変更が影響を受けないようにするために使います。

コミット(commit)

ローカルブランチの変更をローカルリポジトリ(自分のPC上のプロジェクト)に反映する操作です。

リセット(reset)

コミットした変更を取り消します。

ミスしてコミットした際に行います。

リバート(revert)

コミットした変更を取り消します。

リセットとの違いは、取り消す変更を残すかどうかで、リバートの場合は取り消す変更が残ります。

コミットした変更を取り消す変更をコミットするイメージです。

★プッシュ(push)

ローカルリポジトリ(自分のPC上のプロジェクト)で作業した内容をリモートリポジトリ(インターネット上のプロジェクト)に反映する操作です。

自分が作成した機能や変更をチームメンバーと共有するみたいなイメージです。

★プル(pull)

リモートリポジトリ（インターネット上のプロジェクト）の内容をローカルリポジトリ（自分のPC上のプロジェクト）に反映する操作です。

ローカルリポジトリを最新の状態に更新するみたいなイメージです。

フェッチ(fetch)

リモートリポジトリ（インターネット上のプロジェクト）の内容をローカルリポジトリ（自分のPC上のプロジェクト）に取得する操作です。

プルと違い、反映まで行わないので、やりたく変更やあると困る機能を事前に取り除くことができます。

★マージ(merge)

ブランチ(自分の作業空間)の変更を別のブランチに統合する操作です。

よくやるのは、自分のブランチで作成した新しい機能をマスターブランチにマージして、プロジェクトに実装することです。

プルリクエスト(pull request)

自分の変更をリモートリポジトリに反映してもらうように依頼することです。

よくある使い方として、機能を実装した後に、その変更をマスターブランチにマージしてもらうためにプルリクエストを送り、プロジェクトのリーダーや他のメンバーが、このプルリクエストを確認し、変更を本当にマージしていいか確認します。

コンフリクト(conflict)

複数人が同じファイルの同じ部分を変更したときに発生するエラーです。

GitHubでは、どの変更を反映させるかを選択することでコンフリクトを解消できます。

GitHubの特有ファイル

gitignore

.gitignoreファイルに指定されたファイルやフォルダは、Gitでの管理対象から除外され、マージ時にも無視されます。

例えば、UnityのLibraryフォルダには、実行ログなどが含まれていますが、このログは人によって違います。

もし、Libraryフォルダをマージしてしまうとコンフリだらけになるので、.gitignoreに登録し、他の開発者との間で無用な変更がマージされないようにします。

gitattribute

.gitattributesファイルでは、特定のファイルに対するルールや設定を決めることができます。

例えば、改行コードを統一する設定をすることで、異なる環境で作業する際に改行コードがバラバラになることを防ぐことができます。

editorconfig

.editorconfigファイルでは、テキストエディタに対してコードスタイルやフォーマットのルールを設定します。

例えば、MacとWindowsでは文字コードが異なる場合がありますが、このファイルで文字コードを統一する設定をしておけば、文字化けを事前に防ぐことができます。

README

READMEファイルでは、リリースしたプログラムの説明が書かれています。

もし、GitHubでなにかアセットなどを配布する場合は、このREADMEに説明を書いておきましょう。

おわりに

以上、GitHubの基本的な用語解説を行いました。

次回は、主に企画リーダー向けの解説で、実際にリポジトリを作成していきます。