「GitHub」って何がそんなに便利なの? (中編)

Linuxは世界中の開発者が手分けして作っているのは知っていマスよね。世界各地に分散した開発者に向かって、編集のワークフローを決めたり、誰かが集中的に権限を与えタリすることはまず不可能デス。仮にそんなルールを作って守ろうとシテいたら、開発は全く進みまセンね。それ以前に、安定したネットワークが利用デキルとも限りまセンよね。集中型はサーバにアクセスできなければ、何にも始まりまセンから。

プロジェクトといえば皆で集まって作業するイメージしかなかったけど、そう言われてみればそうだな。

Gitは、世界中に分散した開発者が安定して快適に使えるバージョン管理システムを作りタイ、という思想で設計されているんデス。

「皆のために」生まれたシステムってことね。

「分散型」を例えると、「自分のキャビネットに皆のキャビネットの書類のコピーを入れておく」というイメージでしょうカ。新しく参加したメンバーは、ほかのキャビネットの書類をまるごとコピー（クローン）して始めマス。そして、ほかの皆のキャビネットにコピーを渡したり（プッシュ）、変更されている書類を手元にコピー（プル）したりしマス。

変更したら中央のキャビネットに入れて知らんぷり、じゃなくて積極的に皆でやり取りするわけか。コミュニケーションは大事だからな！

そうそう、そうすることで、誰が中心という訳でなく、常に誰もが手元に全ての書類を置いてある状態になるんデス。変更したらすぐにプッシュして配付することで、全てのキャビネットが最新の状態に維持されマス。

好きなタイミングでプッシュすればいいんだな。よくできてるなー。

と言っても、実際の運用では全員宛にプッシュするのは手間ですヨネ。そこで、サーバのような位置付けのGitを「リモートノード」として立てることがほとんどデス。Gitにサーバやクライアントの概念はないんデスが、皆がリモートに向けてプッシュしたり、リモートからプルしたりすることで、全員の書類を同期することになりマス。

でも、結局マージの手間はかかるわけよね?

そうなんデス。同時に修正されたファイル（コンフリクト）は、手作業でマージする必要がありマス。厄介なことにGitのプッシュでコンフリクトが発生すると、プッシュする人がマージ作業をする必要があります。でもいろんな人がそれぞれ勝手にマージ作業をしてしまうと、ソースコードがめちゃくちゃになってしまいますよネ。

そうよね。「管理者がいたほうがまだマシだった」ってことになりそう。

なので、Linuxカーネルの開発では、「責任者であるリーナス・トーバルズ氏宛に『変更を取り込んでください（＝プル）』というリクエストをメーリングリストに流すこと」というルールが出来マシタ。それを見て、トーバルズ氏が依頼者のリポジトリからコードをコピー（プル）して、カーネルにマージするんデス。

皆が好き勝手に更新していくわけじゃなくて、責任者にリクエストすることでちゃんと交通整理されるのね。

これが「プルリクエスト（Pull Request）」と呼ばれる仕組みデス。ちなみに日本では、プルリクエストのことを「プルリク」と略して呼ぶことが多いですネ。

じゃあ、もしAさんがプルリクした後に、同じあたりを修正したBさんがプルリクしてきたらどうなるんだ?

プルリクを実行する際には、まず自分のリポジトリをリモートと同期するんデス。すると、Aさんの分のマージが入ったコードが届くから、Bさんの手元では競合するでショ? なので、Bさんが最新のコードと自分のコードをマージしてから、プルリクエストを出すわけデス。

でも、プルリクは皆が好きなタイミングで出すんだから、Bさんのプルリクが、Aさんのプルリクが反映される前に送られるケースだってあるわよね?

ケースバイケースなんデスが、多分「今ちょうど同じとこ直してるから、ちょっと待て」ってリジェクトされるでしょうネ。

へー、意外と人間味のある対応なのね!

それができるのが、この仕組みのいいところなんデス。マージやコミットの権限を持つ人は、オープンソース開発の世界では「コミッター(Committer)」と呼ばれてとても尊敬されているんデスよ。通常の開発チームでは、技術面での開発リーダーが務めることが多いデスネ。

オレも尊敬されたい……！ コミッター目指そうかなあ。

でも担当したら大変デスよ? メンバーからひっきりなしにプルリクが飛んでくるので、相当な激務デス。場合によってはリーダーの生活が昼夜逆転している現場もありマス。

確かに開発者の立場なら、普通に開発してたら夕方帰る前にプルリクエストしてすっきりしてから帰りたいわよね。そうなると、責任感の強いリーダーなら朝までにコードレビューして、マージを完了させておきたくなるでしょうね。

それをやられると、大抵のリーダーは根を上げてしまいマス。大量の修正コードを含んだ大きなプルリクは、マージの負荷がとても大きいんデスよ。なのでGitベースの開発では、開発者は「できるだけ細かく」プルリクエストするのがマナーになっていマス。小さなプルリクは、レビューもマージもとても軽くて、日中の本業の合間にどんどんこなしていけるんデスよ。

なるほど、自分のことだけ考えてちゃうまくいかないってことだな。

メーリングリストでは、「サイズが大きすぎるから、分割してプルリクし直せ!」なんてメッセージがよく飛び交ってマス。リクエストはわりと簡単に却下されるんですが、そのおかげでコードの書き方とかテストの細かさとか、いろいろ整っていくという効果も大きいんデス。

単なるバージョン管理じゃなくて、プロジェクト自体が統制されていくのね！

そう、メンバー全員に思想が行き渡るんデス。ポイントは、プロジェクトの作業計画を立てるときに、できるだけ細かい単位でタスク分割しておくことになりマス。そしてもちろん、成功の最大の秘訣は、お互いの尊重デス!

「Gitを使う」ってことは、ある意味、「開発チームの文化を変える」ってことにつながるんだ。そんな仕組みを考え出したリーナスさんってすごいわ。

Gitについては、だいたいわかりましたよネ。では、そろそろ本題のGitHubの話に進みまショウ。