Tomo's IT Blog

技術的な調査メモ

初めてのGitHub: Hello World

GitHubにアカウントを作成して、トップページにある"Read the guide"からたどれるHello Worldチュートリアルを実施してみましょう!

そもそもGit(ギット)とは?

いまさらですが、そもそもGitとはソフトウェア開発やその他のバージョン管理タスクを実施するためのバージョン管理システムです。Linux開発者の Linus Torvaldsが2005年にLinuxカーネル開発のために作成したものです。

TEDのインタビューで、Git誕生の理由が語られています。数千人レベルの開発者がLinuxカーネルの開発に携わり、それぞれがちょっとずつコードを変更しており、そのような状況で2~3カ月に一度にリリースを実施していたため、コード管理だけで一つのプロジェクトになってしまっていたようです。そうした状況を変えるべくGitを開発したそうです。GitはLinus氏の2番目に大きなプロジェクトですが、もともとは1番目の大きなプロジェクトであるLinuxを維持管理する目的で作成したということです。なおCVSは大嫌いだそう!

www.ted.com

GitHubとは?

GitHubは、WebベースのGitリポジトリを提供しているサービスです。インターネット上でコードのバージョン管理や開発者同士でコラボレーションできるコード管理プラットフォームを提供しています。有料のPrivateリポジトリか無料のパブリックなリポジトリの2つのプランを提供しています。後者の方は、OSSプロジェクトで良く利用されていたり、個人で作成したコードを公開する手段として良く利用されています。2016年4月時点で、1,400万人のユーザーと3,500万以上のリポジトリを有している*1そうです。
自分は恥ずかしながら、コードを公開するといった習慣が無かったのでこれを機に検証などで利用したコードなんかを公開していきたいなと思っております。

Hello Worldチュートリアル

GitHubのトップページからたどれるHelloWorldチュートリアルでは、Gitの基本要素であるリポジトリ、ブランチ、commit/pullリクエストなどを学ぶことができます。HelloWorldリポジトリを作成してPullリクエストを実行したり、基本的な変更箇所のレビューやブランチへのマージ方法を実践できます。

Hello World · GitHub Guides

Step1: リポジトリを作成する

リポジトリは、通常単一のプロジェクトごとに作成します。リポジトリにはプロジェクトに必要なファイルやディレクトリを含めます。プロジェクトの説明を記述したREADMEを含めることが推奨されています。

リポジトリを作成してみよう!

1. 右上の+ボタンからNew Repositoryを選択します。

f:id:tmnj:20161201133150p:plain


2. Repository Nameにhello-worldと入力、その他は以下のように入力して"Create repository"ボタンを押す

f:id:tmnj:20161201133458p:plain


これで、Repositoryが完成!簡単!

Step2: ブランチを作成してみよう!

ブランチとは、同じリポジトリ上で同時に複数の異なるバージョンを管理するための仕組みです。デフォルトでは"master"という名前のブランチが一つあり、最終的にはこのmasterブランチに全ての変更がマージされます。
"master"からブランチを作成するとその時点での"master"のスナップショットが作成されます。ブランチで作業中に他の誰かがmasterに変更をマージした場合は、その変更を自分が作業中のブランチに取り込む(pull)こともできます。

以下は、masterブランチから新しいブランチを作成して変更→Pullリクエスト→マージまでのフローイメージです。


f:id:tmnj:20161201134306p:plain


開発者は、バグフィックスをしたり新機能を追加する際にmasterからブランチを作成します。開発が完了したら、そのブランチの変更をmasterブランチににマージします。

それでは実際にブランチを作成してみましょう!


1. 先ほど作成したhello-worldリポジトリに移動します。

2. 真ん中左端の"Branch:master"ドロップダウンをクリックして、"readme-edits"と入力して、Create branchをクリックします。


f:id:tmnj:20161201134805p:plain

これで、masterとreadme-editsの2つのブランチがリポジトリに存在するようになりました。

Step3: 変更してコミットしてみよう!

README.mdファイルをクリックして、f:id:tmnj:20161201135101p:plainをクリックして編集モードにします。
内容は何でも良いですがせっかくPublicな環境ですので、世界の人に向けたメッセージをREADMEに記述してみましょう!

f:id:tmnj:20161201135927p:plain



修正したら、画面下の方の"Commit Change"ボタンをクリックします。

f:id:tmnj:20161201140007p:plain



この変更はreadme-editsのみに反映されており、このブランチはmasterブランチとは異なる内容となりました。

Step4: Pullリクエストをオープンする!

readme-editsブランチは、masterブランチと異なる内容なりましたので、Pullリクエストをオープンすることができます。Pullリクエストは、Githubでのチーム開発を行う際の重要な機能になります。
Pullリクエストをオープンすると、変更内容が他のメンバーに提示され、その内容を他のメンバーが作業中のブランチにマージするようリクエストします。Pullリクエストは両方のブランチからの内容の差異を示し、変更した内容、追加した内容、削除した内容が緑と赤で表示され差分を確認することができます。リクエストを受けたメンバーは、その内容を吟味し必要に応じてリクエスト送信者とコミュニケーションし、最終的にブランチにマージするか判断します。
今回は自分専用のリポジトリでPullリクエストをオープンしてmasterブランチにマージしてみることで、GitHubの重要なフローを理解しましょう。

READMEファイルの変更に対してPullリクエストをオープンしよう!


Pullリクエストタブをクリックします。

f:id:tmnj:20161201141631p:plain


緑色のNew pull requestボタンをクリックします。

f:id:tmnj:20161201141710p:plain



作成したブランチ(readme-edits)を選択して、オリジナルのmasterと比較します。

f:id:tmnj:20161201141844p:plain


変更部分を確認できます。

f:id:tmnj:20161201141928p:plain


確認してOKであれば、Create pull requestを押します。

f:id:tmnj:20161201142003p:plain


変更タイトルと変更内容を適当に記述して、Create pull requestを押します。

f:id:tmnj:20161201142152p:plain


Pullリクエストがオープンしました!

Step5: Pullリクエストをマージする

このステップでは、READMEファイルを変更したreadme-editsブランチとmasterブランチをマージします。


Merge pull requestボタンを押します。

f:id:tmnj:20161201142557p:plain


次に、Confirm mergeボタンを押します。

以下のように表示されて、マージが完了しました。変更は既にmasterに組み込まれたので、"Delete branch"ボタンでreadme-editsブランチを削除しましょう。

f:id:tmnj:20161201142723p:plain


masterブランチにREADMEの変更がマージされました!


f:id:tmnj:20161201142922p:plain


以上でHelloworldチュートリアルは終わりです。

まとめ

このチュートリアルではmasterブランチから新しいブランチを作成して、そのブランチに対して変更内容をコミットし、Pullリクエストを投げて、最終的に変更をmasterブランチにマージすると言うGitにおける重要な一連のフローを学ぶことができました。
GitはブランチとPullリクエストの仕組みにより、大人数のチーム開発を非常に効率的に実行できるわけです!
15年ほど前に開発現場にいた頃はCVSを使っており、リリース作業のたびにライブラリアンという役割の人が「一旦マージするので、コミットしばらくやめてくださいー」とかやっていました。かなり属人的で、きめ細やかな役割でしたが、今でもライブラリアンなんて役割の人は居るのだでしょうか?
Gitを利用すればリリース用ブランチをmasterから切れば開発プロセスを止めずにリリース作業ができますね。

なお、GitHubのPullリクエストに関しては、他のリポジトリをForkしてリポジトリのコピーを作成し、そこで変更した内容を元のリポジトリ管理者に反映してもらうためにPullリクエストを送る方法もあります。リポジトリを跨いだPullの仕組みです。GitHubの利用方法としては、こちらの方が多いのかもしれません。
Agile開発のように同時並列的に開発を進めていくプロジェクトでGitを利用する場合は、同一リポジトリ内でブランチを複数作成して、Pullリクエストによりお互いの変更をマージしたり、masterブランチにマージする利用方法が多いのかなと思います。
GitHubのドキュメント上では、前者を"Fork & Pull Model"と呼び、後者を"Shared Repository Model"と呼んでいます。


今回はWeb上ですべての操作を実施しましたが、通常コードは開発端末上にあり、ローカルで開発をしてその変更をGitHubに反映という流れになります。次回はClientからの操作方法、ローカルリポジトリやクローン、リモートリポジトリへのpushといった操作を実施してみたいと思います。