実践Git&GitHub - homebrewをフォークするためのGit&GitHub入門 後編(2/2)
homebrewをフォークするためのGit&GitHub入門 後編(1/2)の続きです。
※文字数制限に引っかかりました（汗
A.ブランチの削除
Formulaが無事に本家に取り込まれて、作業用ブランチが用済みになったからブランチを削除したい、という場合は以下のようにします。
$ git branch -D ghotscript-spike $ git push origin :ghostscript-spike
"-D"オプションは、ブランチを強制的に削除するオプションです。
pushするときに、:ブランチ名 とすると、リモート側のブランチを削除できます。
なお、ブランチを削除しても、そのブランチに紐づいていたGitオブジェクトが消えるわけではありません。
単にブランチポインタが消えるだけで、リポジトリ内にはオブジェクトが残っています。
B. Forkしたリポジトリの削除
いろいろと間違ってしまい、Forkしたリポジトリを削除したい場合は以下の手順を行います。
(1) 削除したいリポジトリのページを開き、"Admin"ボタンを押します。
(2) ページの下側にある"Delete this repository"を押します。
(3) 本当に消してもいいかを３分考えて、気持ちが変わらなかったら"I understand, delete this repository"を押しましょう。
C. コマンドのまとめ
後で（自分が）読み返すときのために、今回のGitコマンドと手順をまとめておきます。
Gitを使った感想
Gitを使ってみて思ったことをつらつらと書いてみます。駄文になってしまったので、暇な方以外はスキップ推奨。
Gitは率直にいって強力です。その強力さもさることながら、アーキテクチャが分かりやすく、トラブルへの対処がしやすいと感じました。
分散リポジトリであり、気兼ねなくコミットできる点は魅力です。CVSやSVNほど慎重にならなくてもいいので、修正作業において重要なポイントをコミットしておらず、訳のわからない状態になってしまった、なんてことが回避できそうです。開発スピードも上がりそうですよね。
またGitHubと組み合わせることでGitの恩恵が何倍にも跳ね上がります。ForkやPull Requestだけではなく、コミットされたソースコードに対してコメントが付けられます。レビューがとても楽になります。修正が確認できたらそのブランチを取り込めばいいのですから。
こういった機能は、（ソースを隠さないという意味で）オープンソースな文化が浸透している会社では、比較的採用しやすく、また成功しやすいと思います。
しかしながら、受諾開発系のプロジェクトでGitを採用するのはまだ敷居が高いと感じます。Windows環境で動かすにはCygwinが必要であったり日本語対応が怪しかったり、メンテナンスが面倒だったり等々問題があるようですが、今回Gitを使ってみて思ったのは、Gitの柔軟性が高いということです。柔軟性が高いというか、ある事を行うための手順の組み合わせがたくさんありすぎる、といったほうがいいでしょうか。良い意味でも悪い意味でも強力すぎるんです。
とりわけ技術者が流動的になりがちで、参加するメンバのレベルはまちまちで、さらに複数の会社からメンバが参画するような規模になるともう大変です。Gitを完全に浸透させるのは困難でしょう。他にも学ぶ必要のある技術がたくさんあるのですから、VCSの学習に貴重なリソースを潤沢には費やせません。スタートアップに掛かる費用は最小限に抑えたいわけです。（それに、Gitを勉強するためにこんだけお金と時間をいただきます、なんて相当理解のあるお客様でない限り通らないでしょう）
プロジェクトには確実に完遂できる仕組みが必要です。Gitの入門書を手渡すだけでは確実とは言えません。
たとえ開発者全員がGitを熟知しているという理想的な状況下であっても、Gitの採用にはリスクが付きまとうのです。分散リポジトリであり柔軟性が高いため、リポジトリの利用ルールやブランチの戦略を標準化しておかないと、マージ地獄に陥ってGitに振り回される状況になりかねません。
あと、何気に重要なのがバイナリファイルの扱いです。Gitにはファイルのロック機能が無いようです（あるのかな？）ので、Office系ファイルをリポジトリで管理しようと思ったら、これは手痛いですよね。
というわけで、
- Gitを習熟してもらうための仕組み
- リポジトリの利用ルール、ブランチ戦略等の標準化
- バイナリファイルの取扱い
がクリアできれば、パラダイスが待っていそうです。
1点目については、Gitの解説コンテンツが充実してきているので、社内向けの資料を作るのに必要な材料は揃っている気がします（著作権等を無視しちゃダメですが）。
2点目については、"A successful Git branching model"と"git-flow"が参考になりそうです。
3点目は、SVNを基幹リポジトリにしてしまう、とか。それでソースをいじるときはsvn-gitを使ってみるのがいいかもしれません。やはり設計資料とコードは同期されていることが望ましいです。設計資料とコードがバラバラに管理されていると、取り漏れていた機能が期日間近に見つかってあたふたする、なんてことがあったりするかもしれませんよね。
また、GitHubについても障壁がありそうです。ソースコードを最終的に納品しなければならない場合、GitHubに開発資産を預けるというのは、お客様の了解を取りにくいものです。GitHubとの秘密保持契約やサポート契約、情報が流出した場合の保証等々超えるべき壁は高そうです。GitHubを採用するなら、そういった面に対する対策を立てておかないといけないでしょう（GitHubのエンタープライズ契約の内容を読んでいないので、案外壁は低いかもしれませんが）。
他にもGitまわりのインフラ構築ノウハウ等々、挙げたらキリが無いですね。なんだか大変そうですが、バージョン管理はどのプロジェクトにも必ず付きまとう問題です。
結局SVNが基幹リポジトリということになってしまいましたが、コーディングやソフトウェアテストにおけるGitの魅力は変わりません。CVSやSVN等で勝ちパターンを構築済みの方もそうでない方も、ソフトウェア構成管理と合わせて、いま一度バージョン管理の方法を見なおしてみてはいかがでしょうか。
参考
nvie.com
A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/
見えないチカラ
A successful Git branching model を翻訳しました
http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html
hnwの日記
GitHubへpull requestする際のベストプラクティス
http://d.hatena.ne.jp/hnw/20110528
(DxD)∞
Gitのブランチで効率的に開発・運用・保守・管理する方法
http://dxd8.com/archives/218/
関連記事
homebrewをフォークするためのGit&GitHub入門
前編：Gitのセットアップ
中編 : Gitの仕組み
後編1：実践Git&GitHub (1/2)
後編2：実践Git&GitHub (2/2)
