Gitと、GitHubを、最低限使いこなすための知識
はじめに
皆さん、こんにちは。
今回は、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を、最低限使いこなすための知識に関する記事を終えます。
ここまで読んでくださった方、本当にありがとうございました。🙇