はじめに

皆さん、こんにちは。
今回は、Gitと、GitHubを使う上で、最低限必要な知識について、話をさせていただこうと思います。

Gitと、GitHubとは何ぞや？

皆さんは、GitHubをご存知でしょうか？
使っているでしょうか？
最近のITエンジニア全般においては、活用されている方が多いかと思います。

ご存知でない方向けに説明をさせていただきます。
Gitは、プログラムのソースコードを、管理する仕組みとなります。
GitHubは、ソースコードの管理場所を、提供するWEBサービスとなります。
Gitの仕組みに則って管理されたソースコードを、WEBサービスであるGitHub上にアップロードして、自分以外の方とソースコードを共有する形となります。

実際に使用する際の流れ

Git／GitHubの使い方については、例えば、以下の流れとなります。

【１】
GitHub（WEBサービス上）にて、リポジトリと呼ばれる、ソースコード管理のための箱を作る

【２】
リポジトリを作ると、そのリポジトリにアドレスが割り当てられるので、そのアドレスをコピーする

【３】
コピーしたアドレスとGitとを用いて、local（自分のパソコン）上に、リポジトリをcloneする
（※ cloneは、GitHub上にあるリポジトリとの結び付きを記録しつつ、local上にリポジトリをcopy兼downloadする操作のことを言います）

【４】
localにて、cloneしたリポジトリに、ソースコード追加／変更等の更新を加える

【５】
ひとしきりの更新が完了したら、localでの内容確定として、commitをする
（※ commitは、ある時点におけるソースコードを、版として確定し、積み上げる操作のことを言います）

【６】
localにて、リポジトリ更新内容のcommitを行った後、その更新内容をpushする
（※ pushは、GitHub上のリポジトリに、localでのcommitをuploadする捜査のことを言います）

以上。

上記が、リポジトリ変更を行う一連の流れとなります。
時系列で表記すると、以下となります。

尚、【２】のcloneは、リポジトリが公開されていれば、自分以外の方が作成／更新したリポジトリを、拝借する形でcloneすることもできます。
例えば、Google／Facebook／Microsoftなどが公開しているソースコードなども、拝借することができ、大変勉強になります。

GitHubの管理／更新には、SourceTreeを使うのが便利

先程紹介したclone／commit／pushが、GitHubにて行う最も基本的な動作となります。
慣れていない人にしたら、割と複雑なオペレーションだなぁ、と感じるかもしれません。

もし、そう思ったとしたら、Git／GitHubの操作を、GUIでコントロールすることができるソフトウェアをオススメします。
中でも、私のオススメは、SourceTreeです。
使い勝手が良く、私事ですが、7〜8年前にオススメされてから、ずっと使っています。
SourceTreeを使うと、GUIにて、とても簡単にGit／GitHubの操作が行なえます。

SourceTreeは、以下の公式ページから、インストールすることができます。

インストール手順は、以下のページが分かりやすいかと思います。

インストールが完了したら、早速、SourceTreeを使ってみましょう。
使い方の説明は、以下のページが分かりやすいかと思います。

ブランチとマージ

GitHubを使い慣れてきたら、基本動作に加えて、ブランチとマージというテクニックを、知っておくと良いかと思います。

ブランチとは、ソースコード管理の仕分けに用いられる、枝のことです。
GitHubにリポジトリを作成した際、まず最初には、masterと呼ばれるブランチにソースコードが所属されます。

基本は、masterブランチが、そのリポジトリの正式版となります。
WEBブラウザを通して、GitHub.com上でリポジトリを参照する際にも、defaultで開示される状態がmasterブランチです。
例えば、以下はmicrosoftが発行しているリポジトリですが、左真ん中上辺りに、masterと書かれているのが見えるかと思います。
これが、defaultで表示されるGitHub.com上のリポジトリページとなります。

もし、masterブランチ以外の内容を見たい場合は、左真ん中辺りにて、masterと書かれているトグルボタンを、別のブランチ名に変更すれば、そのブランチ の内容を確認することができます。

尚、リポジトリに変更を加えた際、何も考えずにpushすると、その変更はmasterブランチに反映されます。

ここで、例えば、暫定的な修正を行いたい場合、一旦は正式版のmasterブランチを更新したくないとします。
仮修正のための流れというか、一連を、別で管理したいとします。

そういう時に、masterでない任意のブランチを作成して対応します。
仮に、ブランチ名をhogeとしましょう。

masterブランチは更新されず、masterブランチをコピーして作られたhogeブランチが更新される形です。

尚、ブランチの作成は、localで行います。
そして、ブランチの作成も含めたlocal上での変更全てを、GitHubへとpushする形となります。
（上記図は、ちょっと怪しいのですが、良きに汲んでいただけたらと……。🙇💦）

また、暫定的なブランチの修正を、正式版へと合流させたくなったとします。
例えば、暫定的なブランチで行っていた修正が、「お、この修正はイケてるぞ」となった場合です。
その合流を実現することを、マージといいます。

尚、マージは、個人でリポジトリ開発をしている場合には、気軽に実行して問題ないと思いますが、複数人で開発などを行っている場合には、マージの承認申請を行うことが一般的です。
「この変更内容を、マージしてはどうか？」という具合です。
その承認申請のことを、pull requestといいます。

複数人でリポジトリ開発を行う際は、メンバーがmasterブランチから修正用のブランチを作成する形が一般的です。
そして、修正用のブランチにて修正を行い、その内容をcommit／pushして、pull requestを投げる、という流れになります。
そしてそして、masterブランチの更新権限を持つリポジトリの管理者に、修正内容を精査してもらい、承認してもらえれば、修正がマージしてもらえる形です。

尚、OSS的な話でいくと、GitHub上にpublicに開示されているリポジトリの管理者に対して、pull requestを送る形となります。
その際には、masterブランチの更新権限は勿論、任意のブランチをpushすることもできないことが一般的です。
でないと、見知らぬ人が任意のブランチをガンガンpushしてきてしまう為です。
その際は、forkというGitの機能を使用します。
この辺りはややこしいので、詳細な説明を割愛しようと思いますが、もし、OSSリポジトリの改修を行いたいと思った場合は、以下の記事などを参考に進めてみると良いかと思います。

その他、初心者の方向けのコツ

以上、説明した内容を理解していただけたら、とりあえずは開発チームに参画しても問題ないかと思います。
後は、習うより慣れろ、ですね。

尚、初心者の方が、先ず、GitHubに触れる上では、以下の３点についても注意をすると、より良い感じにGitHub Lifeを送れるかと思いますので、僭越ながら紹介させていただきます。

【１】
先ず、commitについてですが、1 commit 1 changeが良いと言われています。
pull requestを受けた人が、変更内容を追いやすい為です。
変更内容のレビューというのは、なかなか大変な作業ですので、1 commit 1 changeなどの気配りは大変貴重です。
ただ、いざ実践しようとすると、「どこまでが、1 changeなのか？」という点で悩むかと思います。
細かすぎても冗長ですし、色々含めすぎてもレビューがしづらい…。
悩んだ際は、厳密な意味にはこだわらず、如何にしてレビュアーに分かりやすくcommitするか、という気遣いを心掛けてみて下さい。
（私自身も、なかなか実践できていないのですが、心掛けることが先ず大事かと思います…。）

【２】
次に、localへのリポジトリのcloneですが、個人的には、修正が一段落ついたところで、その度にcloneすることをオススメします。
cloneは、幾ら数多く行っても問題ありません。
むしろ、都度都度、新たにcloneする方の気持ちになって
作業をしていく中で、localリポジトリに余計なファイルなどが蓄積してしまい、リポジトリフォルダに本来管理されているべきものが、分かりづらくなってしまう為です。
区切りが着いたら、心機一転、新たにcloneをし直すことで、リポジトリの整理が捗るかと思います。
是非、自分以外の方が、初めてcloneした時を想定して、リポジトリを整理してみて下さい。

【３】
最後にですが、READMEを誰にでも分かりやすいように、丁寧に書くことをオススメします。
GitHubのリポジトリについては、READMEと呼ばれるmarkdown形式のテキストファイルにて、説明や使い方などを記載するのが一般的です。
GitHubリポジトリをWEBブラウザ上で確認する際にも、表示されるのがREADMEです。

あなたが作ったリポジトリを誰かが使う場合や、誰かが作ったリポジトリをあなたが使う場合に、READMEにて事細かに説明がされていると、お互いにとって凄く助けになります。
リポジトリ利用者にとっては言うまでもありませんが、リポジトリ作成者にとっても、説明にかかるコストを恒久的に省くことができます。
或いは、使い勝手に関して見直す良い機会になります。
是非、丁寧にREADMEを作成するように、心掛けてみて下さい。

おわりに

以上で、Gitと、GitHubを、最低限使いこなすための知識に関する記事を終えます。
ここまで読んでくださった方、本当にありがとうございました。🙇