GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
- 技術評論社 (2014年3月20日発売)


- Amazon.co.jp ・本 (304ページ)
- / ISBN・EAN: 9784774163666
作品紹介・あらすじ
良いコードを迅速に生み出す快適な共同開発。手を動かして身に付ける、実用的なワークフロー。
感想・レビュー・書評
-
チームで開発することがプラグラミング、ひいてはその周辺の便利なツールを使いこなせるようになる一番の近道ではないかと思った。
情報は沢山あっても先述した環境はそうそうないのかも...詳細をみるコメント0件をすべて表示 -
「Pull Requestの送り方」について書かれた記事や書籍は良く見かけるのですが、受け取った後にすべきこと(例えば拒否したい場合など)についてちゃんと書かれたものは意外に少ないように思います。この本では、Pull Requestを受け取る準備からコードレビューを経てマージするところまで、丁寧に解説されています。
タイトル通り、単純なリファレンスだけでなく実例に沿った解説が多くとても参考になりました。GitHubをこれから使う方、またはすでに使っているけどもう少し実践的な使い方を学びたい人におすすめの一冊です。 -
・良書だが、「エンジニアのためのGitの教科書」を読んでいればそちらでほぼ充足する内容である為、あえて追加で購入する必要は無い様に感じた。
・P52:トピックブランチとは、読んで字のごとく、1つのトピック(テーマ)に集中して、ほかの作業は一切行わないブランチのことです。
・P136:開発中のPull Requestは誤ってマージされないためにも、図6.7のようにタイトルの先頭に[WIP(Work In Progress)]と挿入するのが一般的です。
・P137:Githubで相手のコードをもとに修正をするときには、自分のリポジトリとしてForkしてから修正してPull Requestを送信します(リポジトリに対する権限が無い場合)。
・P247:hotfixブランチは計画的に予定されて利用されているブランチではありません。現在リリースされているバージョンに対してバグや脆弱性が発見され、次期の製品リリースまで待つことができず、すぐに解決しなければならないときに緊急対処として利用するものです。
・P254:ソフトウェアのバージョンの振り方を定めたバージョニングポリシーは、シンプルで理解しやすくすることをお勧めします。たとえばx.y.zの3種類の数字でバージョンを管理したい場合のルールは、
- xは大きな機能変更や下位互換性のない場合インクリメント、yとzの数字を0にする
- yは新しい機能の追加や既存機能の削除などでインクリメント、zの数字を0にする
- zは内部的な変更のみの場合にインクリメント
となります。 -
まさに「実践」入門です。
GitHubを中心にした共同開発について学べました。
ただ、右も左も分からない初心者だと分かりづらい部分もあるかなと思います。 -
2014年初版なので少し古い部分もあるが、Githubの基本的なの機能の部分は変わっていないので問題なく読めた。
Gitの操作はコマンドベースなので、手を動かしながら読むか実前に他の本で軽く概念を勉強しておいた方が良さそう。Jenkinsなどの関連ツールについても触れてくれているので、より具体的に業務での使用イメージができた。
Github Flow と Git Flow それぞれをページを割いて説明してくれていたりと、全体的に満足。 -
ITエンジニア本大賞より (https://www.shoeisha.co.jp/campaign/award)
-
図書館にて借りた。
Gitを覚えてきたので、GitHubはどんなものなのかを知るために読んだ。触っていないので深いことは言えないが、また異なる次元のものであると理解した。とは言え、実際にGitHubを使う必要性に迫られてないので、サラッと読んで終了。 -
GIt Hub flowとGit flowの使い分けや
Gitの基本的な使い方を学ぶことができた。
また、どの単位でコミットを行えばいいかであったり、
こういうケースによく出くわすから気をつけて的なことも書いてあったので今後の参考にしたい -
出た当初ぐらいに買って読んではいたのだが、
やっとのことで手を動かして実践できた。
Pull requestはぼんやりとしかわかっていなかったけど、Git(Hub)とどう繋がっているのか、触ってみることでやっと理解できたと思う。
コマンドは丁寧に書かれているものの、GitHubのWeb画面は結構ざっくりで、これのことかな?って疑問に思いながら勧めたところも多かった。
(これは発行からしばらく経っているのが要因かもしれない。) -
だいたいわかった。
git と GitHub の違いがあることすらもわかってなかったのだから…
誰かと開発する時、最後の方をもう一度読み返せば良さそう
大塚弘記の作品





