GitHub実践入門を読んでGitとかGitHubについて考えた
みんなでGitHubを勉強するにゃんっ！に参加するのでいろいろGitとかGitHubについて再勉強ちう。
そしたらGitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
目次をみるとなかなかよさげだったので、期待しながら読んだ。素晴らしい。
http://gihyo.jp/magazine/wdpress/plus/978-4-7741-6366-6/0001
第1章GitHubの世界へようこそ
第2章Gitの導入
第3章GitHubを利用するための準備
第4章Gitを操作しながら学ぶ
第5章GitHubの機能を徹底解説
第6章はじめてのPull Request
第7章Pull Requestが送られてきたら
第8章GitHubと連携するツールとサービス
第9章GitHubを利用した開発フロー
第10章会社でGitHubを使おう
Appendix A、GitHubをサポートするGUIクライアント
Appendix B、Gistで手軽にコードを共有
本書の特徴はGitの基本的なコマンドなどの説明などは可能な限り省略して、GitHubを利用したワークフローに焦点をあてているところである。
Gitが難しいという人は多い。わたしはそんなことはないと考えているのだけど、なんで難しいと感じるのかな？id:hyoshiok:20140201:p1 id:hyoshiok:20140205:p1
Gitの利用の基本はブランチを作ってそこで何かの作業をしてコミットする。そしてリモートのレポジトリへプッシュなりプルリクエストをする。
集中型のバージョンコントロールシステム（VCS）との通常での作業の違いは、ブランチを手軽に作ってそのブランチ上で作業を行うというところかと思う。最初のVCSがgitから入った人は、ブランチを作ってそこで作業をするというのが当たり前だと感じるが古来の集中型に慣れている人はそこにとまどうのかもしれない。
これからバージョン管理のスキルを身に付ける場合、一見シンプルである集中型を身に付けてから分散型を学ぶべきと考える人がいます。ですが、今後集中型を使うケースが少ないため、わざわざ遠回りをする必要はないと著者は考えています。21ページ
コードを変更するのは、１）新機能の実装、２）既存機能の変更拡張、３）バグ修正などになるが、ブランチを切るという作業は、自分の中で意識して、上記のどれかをやるということを明示的に宣言することに他ならない。単にワーキングディレクトリでなんとなくごにょごにょやって、一区切りがついたからコミットでもするかということではない。
集中型の場合、ブランチを手軽に作って、ずんずんそこにコミットして開発の歴史を作っていくということはマージのコストが高いので推奨はされない。というか、お手軽にそのようなことは出来ない。
Gitの場合、ブランチを作るときに上記のどの作業をやるのかということをブランチ名で分かるようにして行う。コミットログも明示的にそれを宣言する。例えばFix bug-1234とかAdd feature-Xとか。
本書はgitおよびGitHubの基本的な操作について５章までで解説し、５章でGitHubの主な機能について詳細に解説している。
そして、６章、７章でPull Requestの送り方、受け取り方を説明している。この６章、７章は本書の白眉だと思う。下記のGitHubのレポジトリを用意して、読者が実際にPull requestを試せるようにしている。
https://github.com/github-book/first-pr
わたしも早速、本書を読んで発見した誤植をpull requestしてみた。
https://github.com/github-book/first-pr/pull/2
なにこれすごい。紙の本とのコラボレーション企画。GitHubを利用してGitHubの機能を学ぶ。従来の本でも掲示板などを作って、そこで著者とやりとりできるというのはなくもなかったが、本書ではGitHubを利用して、その機能の実際をためせるようになっている。イノベーションだと思う。
９章のGitHubを利用したワークフローの解説もわかりやすい。非常に具体的だ。gitの使い方は知っているのだけど、どうも仕事でうまく使いこなせていないと感じている人は、この９章をじっくり読むことをおすすめする。GitHub FlowとGit Flowは名前が似ているが別のワークフローである。前者の方がシンプルなワークフローだ。
GitやGitHubを利用する人にはおすすめの一冊になっている。
とりあえづ、本書を読んだ後に、マニュアルや実用Git
LinusがGitについてなんか言っている
彼はCVSやその改良版のSubversionを頭おかしいんじゃないのというような感じで批判していて、まあ、もうちょっと穏便な言い方もあるんじゃないかと思うのだけど、基本的には、大規模で開発する場合は、分散型しかあり得ないと断言している。
分散型であれば、常にインターネットに接続していなくてもいいし、仮に接続していたとしても超高速のネットワークを必要としないで、どんどん各自が独立して作業ができ、しかも信頼性は高いし、高速である。
何らかの作業をするということはブランチを作ることにほかならなくて、何らかの作業はブランチの上で行われる。それは原理的には分散開発でしかあり得なくて、大規模な開発の場合、分散型のツールに必然的にならざるを得ない。
対等なコピーがインターネット上のどこかに存在するので、信頼性も高い。誰かが悪意を持ってコードを改ざんしようにもそれをすることは難しい（事実上不可能）。従来のファイルをもととしたバージョン管理システムだと、ソースコードが破壊されていても自動的に検出されないが、gitの場合、ハッシュ値によって保証する。
そのほか、あれやこれや2007年ころの映像なので、gitを利用してLinuxのソースコードを管理し始めて2年くらいの経験を語っているので、実に興味深い。あわせて見てみるといいと思う。
