未来のいつか/hyoshiokの日記 このページをアンテナに追加 RSSフィード Twitter

2014-03-22

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)との通常での作業の違いは、ブランチを手軽に作ってそのブランチ上で作業を行うというところかと思う。最初VCSgitから入った人は、ブランチを作ってそこで作業をするというのが当たり前だと感じるが古来の集中型に慣れている人はそこにとまどうのかもしれない。

これからバージョン管理スキルを身に付ける場合一見シンプルである集中型を身に付けてから分散型を学ぶべきと考える人がいます。ですが、今後集中型を使うケースが少ないため、わざわざ遠回りをする必要はないと著者は考えています。21ページ

コードを変更するのは、1)新機能の実装、2)既存機能の変更拡張、3)バグ修正などになるが、ブランチを切るという作業は、自分の中で意識して、上記のどれかをやるということを明示的に宣言することに他ならない。単にワーキングディレクトリでなんとなくごにょごにょやって、一区切りがついたからコミットでもするかということではない。

集中型の場合、ブランチを手軽に作って、ずんずんそこにコミットして開発の歴史を作っていくということはマージコストが高いので推奨はされない。というか、お手軽にそのようなことは出来ない。

Git場合、ブランチを作るときに上記のどの作業をやるのかということをブランチ名で分かるようにして行う。コミットログも明示的にそれを宣言する。例えばFix bug-1234とかAdd feature-Xとか。

本書はgitおよびGitHub基本的操作について5章までで解説し、5章でGitHubの主な機能について詳細に解説している。

そして、6章、7章でPull Requestの送り方、受け取り方を説明している。この6章、7章は本書の白眉だと思う。下記のGitHubレポジトリを用意して、読者が実際にPull requestを試せるようにしている。

https://github.com/github-book/first-pr

わたしも早速、本書を読んで発見した誤植をpull requestしてみた。

https://github.com/github-book/first-pr/pull/2

なにこれすごい。紙の本とのコラボレーション企画。GitHubを利用してGitHub機能を学ぶ。従来の本でも掲示板などを作って、そこで著者とやりとりできるというのはなくもなかったが、本書ではGitHubを利用して、その機能の実際をためせるようになっている。イノベーションだと思う。

9章のGitHubを利用したワークフローの解説もわかりやすい。非常に具体的だ。gitの使い方は知っているのだけど、どうも仕事でうまく使いこなせていないと感じている人は、この9章をじっくり読むことをおすすめする。GitHub FlowGit Flow名前が似ているが別のワークフローである。前者の方がシンプルワークフローだ。

GitGitHubを利用する人にはおすすめの一冊になっている。

とりあえづ、本書を読んだ後に、マニュアル実用Git英語版は既に第二版が出ている)入門Gitを読むと理解が深まると思う。


LinusGitについてなんか言っている

D

彼はCVSやその改良版のSubversionを頭おかしいんじゃないのというような感じで批判していて、まあ、もうちょっと穏便な言い方もあるんじゃないかと思うのだけど、基本的には、大規模で開発する場合は、分散しかあり得ないと断言している。

分散型であれば、常にインターネット接続していなくてもいいし、仮に接続していたとしても超高速のネットワーク必要としないで、どんどん各自が独立して作業ができ、しか信頼性は高いし、高速である

何らかの作業をするということはブランチを作ることにほかならなくて、何らかの作業はブランチの上で行われる。それは原理的には分散開発でしかあり得なくて、大規模な開発の場合分散型のツールに必然的にならざるを得ない。

対等なコピーインターネット上のどこかに存在するので、信頼性も高い。誰かが悪意を持ってコード改ざんしようにもそれをすることは難しい(事実上不可能)。従来のファイルをもととしたバージョン管理システムだと、ソースコード破壊されていても自動的に検出されないが、git場合ハッシュ値によって保証する。

そのほか、あれやこれや2007年ころの映像なので、gitを利用してLinuxソースコード管理し始めて2年くらいの経験を語っているので、実に興味深い。あわせて見てみるといいと思う。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証