gitって難しいのかなー
いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください）
前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。
それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもいい。
githubを使えば、面倒な設定とかいらないしお手軽だし、無料だし、ちまたには情報があふれていて便利だ。そのようなエコシステムがあるというのは初学者に取っては大変なメリットになる。ぐぐればなんとかなるから。
チームのレポジトリをgithubにおくのは驚くほど簡単だ。
github.com に行ってアカウントを作って、gitの設定をして、レポジトリを作り、READMEを書いて、LICENSEを決めて、公開する。あとはソーシャルにコーディングをする。
githubに公開したリポジトリをまづローカルのディレクトリにコピーする。
$ git clone https://github.com/hyoshiok/git-example.git
あとは、ごにょごにょ変更して、変更したファイルをaddしてcommitして、githubにpushする。一人で開発しているのなら、それだけだ。変更してcommitして、pushする。それを延々繰り返す。
複数人で開発をしていることを前提にすると、もう少し複雑になる。
レポジトリを変更するのは、基本的には、新しい機能を追加、変更する場合と、バグを修正する場合がある。その他の場合もあるかもしれないが簡単のために、そう考えるとする。
バグを修正する場合、誰かがなんらかの方法でバグを発見して、バグDBとかに報告されたとしよう。たまたま使っている時に発見したでもかまわないけど。ともかくバグが発見されたとする。
ワークフローは、１）バグ修正用のブランチを作る。２）そのブランチ上で、バグを修正する。３）テストをして、修正によってバグがなおっていることを確認する。４）commitする。５）master ブランチにマージする。６）githubにpushする。
自分のローカルのレポジトリにアクセスするのは、自分だけなので、バグ修正用のブランチでの作業は、自分にしかみえない。githubにpushした時点で初めて他のメンバーから見れるようになる。６の時点でpushが失敗する場合もある。そのときは、githubからfetchしてmergeしてコンフリクトを解消し、テストしてcommitして、またmasterにマージしてgithubにpushするというプロセスを繰り返す。
コマンドモードなので煩雑にみえるかもしれないが、それほど複雑な話ではないと思う。
何か変更をする場合は、ブランチを作って、その上で作業し、テストをしてcommitしてmergeしてpushというフローになる。commitのログには、どのバグを直したか（issueの番号などを記しておくと後々便利）などを書いておく。
新しい機能の追加や変更も流れは一緒だ。ただし、大きな機能の実装になると、そのブランチをさらに誰かがforkして修正するようになるかもしれない。
またgithub上にプロジェクトの共有レポジトリを置くとして、各人のローカルのレポジトリのコピーを置いておけば、誰からも最新版のソースコードを見れるようになって共同作業が加速する。
各人の変更についてはgithubの自分のレポジトリにpushして、共有レポジトリのオーナーにそこからpullしてもらうようにする。それが、ソースコードレビューそのものになる。
共有レポジトリのmasterブランチを安定したバージョンに保っておくことを、このようなワークフローで実現する。
masterブランチにマージする前に様々な機能を追加修正するというようなワークフローは個人のレポジトリのブランチに対するpullリクエストなどで行える。
確かにgitのコマンド体系はお世辞にも分かり易いとは言いがたいが、概念そのものは単純で明快だ。ローカルで作業してリモートに反映する。それを延々繰り返す。どちらが主というよりもピアツーピアであり、対等な関係となっている。
大規模分散開発のベストプラクティスだと思う。
