Pull Request ではじめてみる!GitHub ソーシャルコーディング

こんにちわ、就活の面接がいつの間にか雑談ぽくなりがちな cyokodog です。 普段できないプログラムの話とか、異業種の現場の話とか聞いたりできるのってすごい楽しいものですね!(お時間とらせてしまってすいません^^;)
今回はそんなコミニケーションを取りながら、皆でわいわい開発するのが当たり前の時代がきたらいいなぁ… そんな思いを込めて、ソーシャルコーディングを可能にする WEB サービス GitHub の利用方法についてまとめてみました。

GitHub アカウントの作成

GitHub を利用するにあたり、まずは https://github.com/ でアカウントを作成します。 ユーザ名、メールアドレス、パスワードを指定し [Sign up for GitHub] をクリックします。

github


[Finish sign up] をクリックします。

github


以下の画面になります。

github


“[GitHub] Please verify your email” というタイトルでメールがくるので、本文内のリンクをクリックします。

mail


[Confirm] をクリックすると GitHub を利用できるようになります。

github

Git のインストール

Git をインストールします。 https://code.google.com/p/msysgit/downloads/list にアクセス、 最新版 の Git-x.x.x.x-previewYYYYMMDD.exe をダウンロードし、インストールします。

git

Git コンソールの日本語文字化け対応

Git のコンソールにて ls コマンドでファイル一覧を表示した際、日本語ファイル名が文字化けしないよう設定します。 エクスプローラーを起動し、適当なフォルダを選択した状態で、右クリック→[Git Bash Here] で Git のコンソールを立ち上げます。

git


MINGW32 と表示されたタイトルバーの部分を右クリック、[プロパティ][フォント]タブを選択し、[フォント]をMSゴシック、[サイズ]に適当な値を指定し、[OK] をクリックします。

git


次にコンソール上で以下のコマンドを入力します。

  1. vi ~/.bashrc
  2. alias ls='ls --color=auto --show-control-chars'
  3. :wq

Bash の再起動で文字化けが解消されます。

commit コメントの日本語対応

git ではソースコードの変更を commit コマンドで確定しますが、その際入力する変更コメントは、初期設定のままでは日本語が入力できません。 core.editor に任意のテキストエディタを指定することで日本語コメントを入力できるようになります。 例えば秀丸エディタを割り当てる場合は以下のように設定します。

  1. git config --global core.editor "\"C:/soft/Hidemaru/Hidemaru.exe\""

SSH 認証キーの作成と登録

SSH 認証キーを作成します。コンソール上で以下のコマンドを入力します。

  1. mkdir ~/.ssh
  2. cd ~/.ssh
  3. ssh-keygen -t rsa -C "username@gmail.com" ←自分のメールアドレス

c:Users<Windowsアカウント名>.ssh フォルダに id_rsa.pub が生成されます。

https://github.com/settings/ssh で [Add SSH key] をクリックし SSH Key のタイトルとSSH Key の値を登録します。 SSH key の値は id_rsa.pub をテキストエディタで開き、その中身をそのままコピペします。

git

GitHub でソースコードを管理する

それでは GitHub でソースコードを管理してみます。 https://github.com/ で [New repository] をクリックします。

github


Repository name、Description それぞれにリポジトリ名(ソース置き場の名前、 ここでは “hello-pull-request” と入力します)と概要説明を入力、 [Initialize this repository with a README] をチェックし、[Create repository] をクリックします。

github


作成したリポジトリが表示されます。 次にこのリポジトリをローカルにコピーするため [HTTPS clone URL] のアイコンをクリックし、 クリップボードに URL をコピーします。

github


Git のコンソールでリポジトリをコピーしたいフォルダ(今回はc:\github)に移動し、 git clone と入力したらクリップボードの URL をペーストし以下のように入力します。

  1. cd /c/github
  2. git clone https://github.com/cyokodog-lab/hello-pull-request.git

リポジトリがコピーされ C:\github\hello-pull-request フォルダができあがります。

github

試しに hello-pull-request フォルダに以下 index.html を作成し、Git, GitHub に登録してみます。

  1. <!DOCTYPE>
  2. <html>
  3. <head>
  4. </head>
  5. <body>
  6. <h1>Hello GitHub</h1>
  7. </body>
  8. </html>


C:\github\hello-pull-request フォルダに移動し、以下コマンドを入力します。

  1. cd /c/github/hello-pull-request
  2. git add .
  3. git commit


テキストエディタが表示されるので、commit コメントを入力したらエディタを閉じます。

github


これでローカルの Git にファイルが追加されます。

github


次に push コマンドで GitHub にこの変更を反映させてみます。

  1. git push

github

GitHub のアカウント、パスワードをお求められます。入力すると GitHub にファイルが追加されます。


GitHub のリポジトリに index.html が登録されてることが確認できます。

github

GitHub から変更差分を取り込む

例えば職場PCにてソースを修正し GitHub に push したり、 直接 GitHub の web ページ上でソースを修正した場合、 ローカルの Git で管理してるソースと変更差分が生じます。 この変更差分を取り込むには pull コマンドを使います。

実際に web 上で修正した内容を取り込んでみます。 先ほど登録した index.html を GitHub 上で選択し、鉛筆のアイコンをクリックします。

github


編集可能状態になるので以下一行を追加し保存します。

  1. <p class="lead">Study Pull Request Programming</p>

github


ローカルの Git で pull します。

  1. git pull

github


テキストエディタで開くと web 上で行った変更が取り込まれてることが確認できます。

github

Pull Request ベースのソースコード変更

前置きが長くなりましたがここからが本番です。 Git で管理されるファイルはブランチと呼ばれる領域に保存されます。 初期状態では master という名前のブランチが1つあるのみです。

コードを修正する場合は、修正用のブランチを作成しその領域でコードの修正/テストを実施した後、 オリジナルのブランチに変更内容を反映します。

まず checkout コマンドで修正用のブランチを作成します。 今回は style タグの追記を行うので、ブランチ名を “add-style” とします。

  1. git checkout -b add-style

“Switched to a new branch ‘add-style'” と表示され、 新しいブランチが作成されファイルがコピーされます。

branch コマンドで存在するブランチとカレントのブランチが確認できます。

  1. git branch

github

add-style と master という名前のブランチがあり、* のついてる add-style がカレントブランチだということが分かります。

では index.html を以下のように修正します。

  1. <!DOCTYPE>
  2. <html>
  3. <head>
  4. <style>
  5. h1{
  6. font-size: 20px;
  7. }
  8. </style>
  9. </head>
  10. <body>
  11. <h1>Hello GitHub</h1>
  12. <p class="lead">Study Pull Request Programming</p>
  13. </body>
  14. </html>


add, commit をします。commit は -m でコメントを指定できます(日本語は不可)。

  1. git add .
  2. git commit -m 'add style'


以下 push コマンドにて GitHub 上に add-style ブランチを作成しつつ push を行います。 origin は GitHub のリモートリポジトリ名です。

  1. git push origin add-style


GitHub 上に add-style ブランチが生成されます。 [Compare & pull request] ボタンをクリックすることで、「add-style ブランチの変更差分を master ブランチへ取り込んでください」というリクエスト(Pull Request)の作成が行えます。

github


タイトルと概要を入力し、[Create pull request] をクリックし、pull request を作成します。

github


コミットログ、diffなどが表示され、コメントの入力が可能な状態になります。 この変更リクエストを master ブランチに取り込む場合は [Merge pull request] をクリックします。

github


GitHub 上で master ブランチに変更内容を取り込んだとしても、 ローカルの Git は add-style ブランチがカレントで且つ、master ブランチのソースコードは古いままです。

checkout コマンドで master ブランチに切り替え、pull することで最新の状態にすることができます。

  1. git checkout master
  2. git pull

WIP Pull Request

自分一人で開発してる場合、ソースコードを修正し push する時点でテストが終わっているのであれば、 前述の Pull Request ベースの変更フローは変更を取り込むことが前提のアクションとなるので、無駄に冗長な作業をしているという印象を受けます。

そこで開発を着手した時点で Pull Request を送る WIP Pull Request(Work In Progress Pull Request)という手法を使用し、 効果的に Pull Request を利用してみます。

これは開発に着手した時点での作業内容や TODO リストを記載する形で Pull Request を送り、 進捗にあわせこれら記載事項のアップデートと push を繰り返すことで、 Pull Request 自体を進捗管理や情報共有の場にしてしまおうという手法です。

では、新たにブランチを作って pull request してみたいと思います。

  1. git checkout master
  2. git checkout -b wip-re-design
  3. git commit --allow-empty -m 'wip'
  4. git push origin wip-re-design

ここではソースコードの変更がないので空コミットをするために –allow-empty を指定してます。


前述同様 GitHub にて pull request を作成します。 概要欄ではマークダウンが使用でき、以下のように記述するとチェックボックス付きの TODO リストを作ることができます。

  1. ## TODO
  2. - [ ] header, footer の追加
  3. - [ ] web font の適用

github


まず1つ目の TODO に従い [header, footer の追加] を行い Pull Request します。

  1. <!DOCTYPE>
  2. <html>
  3. <head>
  4. <style>
  5. h1{
  6. font-size: 20px;
  7. }
  8. </style>
  9. </head>
  10. <body>
  11. <div class="header">
  12. <h1>Hello GitHub</h1>
  13. <p class="lead">Study Pull Request Programming</p>
  14. </div>
  15. <div class="main">
  16. What's WIP Pull Request !?
  17. </div>
  18. <div class="footer">
  19. @cyokodog
  20. </div>
  21. </body>
  22. </html>


add, commit, push して、TODO のチェックボックスをチェックONにします。

github


差分も確認できます。

github


続いて2つ目の TODO である web font の適用を行います。

  1. <!DOCTYPE>
  2. <html>
  3. <head>
  4. <link href='http://fonts.googleapis.com/css?family=Raleway:300' rel='stylesheet' type='text/css'>
  5. <style>
  6. h1{
  7. font-family: Raleway;
  8. font-size: 20px;
  9. }
  10. </style>
  11. </head>
  12. <body>
  13. <div class="header">
  14. <h1>Hello GitHub</h1>
  15. <p class="lead">Study Pull Request Programming</p>
  16. </div>
  17. <div class="main">
  18. What's WIP Pull Request !?
  19. </div>
  20. <div class="footer">
  21. @cyokodog
  22. </div>
  23. </body>
  24. </html>


add, commit, push して、TODO をチェック、TODO が全て完了したのでマージします。

github


実際の運用では、全ての修正が済んだのでリリースという流れになるかと思います。 GitHub では gh-pages というブランチに index.html 等のファイルを置くと web サイトとして公開してくれる機能があるので、これをリリース先と見立ててみます。

  1. git checkout master
  2. git pull
  3. git checkout -b gh-pages
  4. git push origin gh-pages

10~20 分程度待って http://<ユーザ名>.github.io/<リポジトリ名> にアクセスすると登録した index.html が表示されます。

ブランチモデルと GitHub Flow

前述のようにブランチを作成し Pull Request で開発していくという手法は、 複数人で開発する場合、手軽にブランチを作成できる一方、ブランチが乱立し混乱をまねくという懸念があります。 そこで開発チーム内でブランチモデルという一定のルールを設け運用するのが良いとされています。

GitHub 社内でも採用されてるブランチモデルである GitHub Flow は以下のルールで運用します。

  • ブランチは master ブランチとトピックブランチのみを使用する
  • トピックブランチは開発用に使用し、ブランチ名は追加しようとしてる機能等を読み取りやすい名前にする
  • Pull Request は他の開発者にレビューしてもらいたいタイミングや、master ブランチに取り込んでもらう時に送る
  • master ブランチにマージされたらリリースする

GitHub Flow をベースに各プロジェクトに合わせたブランチモデルを定義するのが良いかと思います。

他の開発者から Pull Request を受信した場合

この記事を書いていたら、たまたま他の開発者の方から Pull Request を受け付けましたので、Pull Request を受けた時の対応手順についても書いておきます。

他の GitHub ユーザに Pull Request されると以下のようなメールが飛んでくるので、本文中のリンクをクリックします。

github


送信者のコメントが表示されるので内容を確認します。

github

送信者のコメント

wrapper の指定が曖昧だったため、親を遡って明示するようにした。 CMS など自動生成される HTML 中で複数のノードを対象にする場合、メソッド実行を可能な限り簡潔にして冗長さを省きたいため、実行側で親が自動的に明示的にならないといけない。


[File changed] タブをクリックし変更されたファイル名、コードの変更箇所を確認します。

github

jquery.fit-sidebar.js([Fit Sidebar] レスポンシブ対応でサイドメニューを一定範囲で固定表示する jQuery プラグイン)に対する変更だということが分かります。

  1. c.wrapper = $(c.wrapper);

という記述を

  1. c.wrapper = $(c.target).parents(c.wrapper);

としてるようです。

jquery.fit-sidebar.js の処理仕様において c.wrapper は c.target の親もしくは先祖要素である必要があるので、 この変更は妥当であると判断できますが、変更されたソースコードのテストは必要ですので、このリポジトリをローカルに clone しテストします。

[command line] のリンクをクリックし、clone するためのコマンドを表示させます。

github

コピペしてリポジトリを clone します。

  1. git clone https://github.com/ginlime/jquery.sitekit.git


画面の Step 1 に当たる部分のコマンドラインをコピペし、修正の加えられているブランチを取得します。

  1. git checkout -b ginlime-glm-mod gh-pages
  2. git pull https://github.com/ginlime/jquery.sitekit.git glm-mod

テキストエディタでソースファイルを開き、修正されたソースコードを取得できてることを確認した後、テストを開始します。

テストした結果、問題がないようなら、必要に応じ GitHub 上でコメント等を登録し、[Merge pull request] をクリックしマージします。

github


リポジトリを見ると変更が反映されてることが確認できます。

github

他の開発者に Pull Request を送信する場合

次は Pull Request を他の開発者に送ってみます。 といってもよそ様のソースコードを修正しマージ依頼をするというのもなかなかの敷居の高さを感じます。

そこで24時間耐久マラソンも完走しちゃう尊敬する新人SEさんに Pull Request を送ってみたいと思います。 目ぼしいソースコードはないかなぁ、とリポジトリをながめていると・・ありました!

github

body タグが2つあります(ガーン)

ではまず該当リポジトリを Fork してみたいと思います。 Fork とは GitHub の機能で他の開発者のリポジトリを GitHub 上で clone することをいいます。 該当するリポジトリに移動し [Fork] をクリックします。

github


clone されて自分のリポジトリになりました。

github


ローカルの Git に clone し、ソースコードを修正します。

  1. git clone https://github.com/cyokodog/ohha-tommy.github.io.git


修正したら push します。

  1. cd ohha-tommy.github.io
  2. git add .
  3. git commit
  4. git push


GitHub に変更が反映されてることを確認し、[Pull Requests] をクリックします。

github


[New pull request] → [Create pull request] の順でクリックします。

github


タイトルと変更概要を入力して [Create pull request] をクリックします。

github


Pull Request を送信できました。 後はマージしてもらうのをわくわくしながら待つのみ!

github

・・・が、なかなかマージしてくれないので Facebook のメッセで催促してみました。

github

おお!返信きたっ スクショとるぞーとリポジトリを見てみると・・・マージされてません(笑)
やはり GitHub の敷居は低くはないようですね ^^;

翌日マージしたようで GitHub からメールが飛んできました。

github

リンクをクリック!

github

無事マージされてます!めでたしめでたし ^^)

最後に

自分の経験不足もありまだまだ敷居が高いという印象は否めませんが、 ソースコードを中心とした活発なコミュニケーションの姿を想像すると、なんかわくわくしてしまいますね。

jQuery の最大の功績は、非プログラマの人々を巻き込むかたちでプログラミングの楽しさを世に広めたことだと思っていて、 そこには作者のジョン・レッシグさんの「玄人好みの厳格さより、不慣れな人へ分かりやすさを優先した優しさ」のようなものがあったからこそ、と勝手に感じている今日この頃です。

GitHub でもそうした優しさに満ちたコミュニケーションが行われ、 プログラミングの楽しさがもっと世の中に伝わればいいなぁ、と思う次第です。