GitHub Japan

http://news.mynavi.jp/news/2015/06/04/516/

GitHubが日本法人を設立したとな。

で、流行るかどうかは正直微妙な気がする。日本法人のサポートがあって悪いことはないだろうけど、そもそも今まで、大きな組織でバージョン管理システムを使いこなしているところを見たことがないんだよなぁ。

決して大企業の中の人にバージョン管理システムを使いこなす技量がないわけではないとは思うんだけど(技量がない人がいないわけでもないとも思うが)、方々からかき集めた技量にばらつきがある人を束ねようと思うと、どうしても最低限の機能しか使えないのだろう。経験的にはブランチを使っていればまだマシな方で、コミットする度に共有Excelファイルに変更内容を書かされるアホくさい現場もあったっけなぁ。そんな組織は分散型のバージョン管理システムなんて使いこなせないので、GitHubには食いつかないだろう。

レポジトリを社外に出すことに抵抗がある企業も多いと思う。下請けなんかだと、セキュリティ面で顧客に心配させることを嫌って、敬遠されそうな気がする。

結局のところ

「これからは、開発者やデザイナーに対してだけではなく、GitHubを使ったオープンスタイルな仕事の方法をさまざまな人たちに提案していき、よりハッピーになれるような仕事環境を実現していきたい」

この精神こそが、レガシーなロジックで回っている会社にはマッチしないのだろう。悲しいけど。

手元の作業コピーから.svnを除外してtar ballを作る

SVNのレポジトリにコミット済みのバージョンのtar ballを作りたければ、単純にsvn exportしたものをアーカイブするだけだ。が、未コミットな変更を含む手元の作業コピーを、ちょっと固めて渡したい場合はどうするか？ これまでは作業コピーのコピーを作ってから.svnを消して固めていたのだが、GNU tarには便利なオプションがあることに、今更気が付いた。

% tar zcvf foo.tar.gz --exclude-vcs working_copy

--exclude-vcsを付けるとバージョン管理システムのディレクトリを除外してくれるとのこと。ソースを見るとCVS, RCS, SCCS, SVN, git, Arch, Bazaar, Mercurial, darcsに対応しているようだ。

また又・SVN使いだがGitに乗り換えようと思う

レポジトリ間の連携の話。
今回は分散型ならではの話なので、Subversionとはの比較は無し。

まずは既存のレポジトリをgit cloneで複製して、各々が自分専用のレポジトリを作成する。

複製の複製も可能。

他のレポジトリの変更を自分のレポジトリにマージするにはgit pull。自分のレポジトリの変更を他のレポジトリにマージするにはgit push。

ただ、他のレポジトリを変更するgit pushは、そもそも許可されているとは限らない。そんなときはレポジトリの持ち主にpullしてもらう。
なお、pull/pushで変更するのはレポジトリ全体ではなくブランチ。

他のレポジトリのエイリアスを登録しておくと、操作の度にURLを入力しなくても済む。エイリアスの追加や削除等は、git remoteで管理できる。なお、git cloneで複製したレポジトリには、デフォルトで複製元のレポジトリにoriginという名前が付けられている。

続続・SVN使いだがGitに乗り換えようと思う

GitのブランチがSubversionのそれと違うなぁと思った点を3つ。

まず実装。そもそもSubversionのブランチは、運用でブランチとして扱っているだけの単なるサブディレクトリなので、明確にブランチ機能を備えたGitとはまるで違う。

次にブランチ作成の気軽さ。Subversionでブランチを作るということは、共有レポジトリに新たなサブディレクトリを作るということ。運用ルールにもよるけれど、ちょっとした実験用ブランチを作るのは気が引けてしまうことも多い。一方Gitなら、あくまで自分専用のレポジトリなので、実に気軽にブランチを作成できる。

最後にマージの厳格さ。コミットもブランチ作成も気軽なGitだけれど、マージに関してはSubversionよりGitの方が細かい。Subversionの場合、どの変更をマージしたかという情報(mergeinfo)が欠落している場合が結構ある。…というか、mergeコマンドを使わない(人|クライアント)が結構多い気がする。mergeinfo自体が後付けなので仕方ない気もするけれど、理由はどうあれ、何をマージしたのか分からなくなるのは非常に困る。
一方Gitは、マージも含めて適用してきた変更をきちんと把握しているので、mergeコマンドでは未適用の変更のみを正確に適用できる。もちろんGitでも、mergeコマンドを使わずに出所不明の変更としてcommitすることはできるけれど、そこは分散型の良いところ。自分専用のレポジトリなのだから、きちんとマージするというルールを自分だけが守っていれば、他人のいい加減なマージに振り回されることは無い。

他人のレポジトリと同期する話は後ほど。

続・SVN使いだがGitに乗り換えようと思う

超基本的な変更〜コミットの操作を比較してみよう。
まずはSubversion。

単純に作業コピーを変更したら、svn commitで変更をレポジトリに反映させる。commitする前であれば、svn revertで元に戻せる。

次にGit。

Gitの場合、単に変更しただけのファイルはコミット対象にならない。基本的には、明示的にgit addで変更内容を登録してから、git commitで登録しておいた変更内容をレポジトリに反映させる。まあ、面倒ならgit commit -aでaddしながらcommitもできるけど。
さて、注目すべきはgit resetで過去のバージョンへ戻れる点。Gitではcommitそのものを取り消すことが出来る。どうせ自分専用レポジトリだし、最悪でも取り消せるので、気軽にcommitできることが大きな特長のひとつとも言える。恥ずかしいtypoがずっと残ってしまうSubversionとは実に対照的。

しかし、改めて図示してみると複雑だなぁ。まだブランチも出て来てないのに。

SVN使いだがGitに乗り換えようと思う

SubversionからGitに乗り換えようとしているのだが、その過程をつらつら書いてみる。
まず、軽く使ってみてSubversionと違うと感じたことと、似てると思ったこと。

Subversionと最も異なる点は、何と言ってもGitが分散型であること。
Subversionでは、ある時点でのレポジトリの内容を手元に複製して作業をするのに対して、Gitではレポジトリそのものを手元に複製して作業する。これによって嬉しい点は

1. レポジトリの操作が速い
2. ネットワークに繋がっていなくてもレポジトリを操作できる
3. 気軽にレポジトリを変更できる

こんなところ。1と2は単純に手元にレポジトリがあるが故。分散型ならではの最大のメリットは、やはり3。Subversionは皆で1つの共通レポジトリ突っつくので、例え自分のブランチであっても、あまりいい加減なコミットはためらわれる。また、ブランチの粗製濫造にも抵抗がある。一方、手元に複製してきた自分専用のGitレポジトリなら、どんな駄コミットでも気軽にできるし、実験的なブランチも気兼ねなく作成できる。

バージョンの振られ方は似ているかな。どちらもコミットの単位は、レポジトリに対する何かしらの変更。レポジトリへの変更をコミットすると、全体のバージョンが進む感じ。まあ、細かいことを言えば異なる点は多々あるけれど、どちらもCVSのようにファイル毎に別々にバージョン管理しているわけではない。

実践的な話は明日以降に。