gitとsvnの比較

gitとsubversionについて比較の記事を見つけたので、それの拙訳です。
訳は適当なので、元記事のリンクもつけるので正確なのはそちらへどうぞ。

# 「[Subversion vs. Git: Myths and Facts](https://svnvsgit.com/)」より

gitとsubversionにまつわる神話（都市伝説）と真実について、まとめられています。
[神話: 真偽]という形でそれらを以下に訳してみます。

## 1. Gitリポジトリは同じsubversionリポジトリに比べてデータ量はかなり小さい: ウソ

>Git repositories are significantly smaller than equivalent Subversion ones 

https://svnvsgit.com/#repository-size-myth

## 2. subversionのブランチのコストが高い: ウソ

> Branches are expensive in Subversion

https://svnvsgit.com/#branching-myth

## 3. subversionで2つのブランチをマージするには、リビジョンの範囲を手動で設定しなければいけない: ウソ、昔の話である

> It is required to manually specify the range of revisions when you merge two branches in Subversion 

https://svnvsgit.com/#merging-myth

## 4. subversionのワーキングコピーでは、フォルダごとに.svnディレクトリがある: ウソ、昔の話である

> There is an auxiliary .svn directory in each folder of Subversion working copy

https://svnvsgit.com/#auxiliary-directory-myth

## 5. subversionを使っている人などもはやいない: ウソ

> Nobody uses Subversion anymore

https://svnvsgit.com/#not-used-myth

## 6. 分散型バージョン管理システムは、subversionのような中央型のものより、本質的に優れている: ウソ。 あくまで部分的　

> Distributed version control systems are inherently superior to centralized ones such as Subversion 

https://svnvsgit.com/#dvcs-myth

## 7. Gitは大規模プロジェクトにも良く対応できる: ウソ。　いくつかのより小さいリポジトリに分割することで対応する

> Git scales well for larger projects

https://svnvsgit.com/#git-scalability-for-larger-project-myth

## 8. Gitは大人数チームにも良く対応できる: ワークフローに一定の制限がある

> Git scales well for larger teams 

https://svnvsgit.com/#git-scalability-for-larger-teams-myth

## 9. Subversionではマージ作業が常に辛い: 昔ながらの問題がある

> Merge operation is always painful in Subversion 

https://svnvsgit.com/#svn-merging

## 10. Gitは実装上の複雑さや制限が漏れているし、コマンドラインの形式がわかりづらい: 本当。 分散型VCSと、抽象化とコマンドの簡易化は相容れないため。

> Git has leaky abstraction and crazy command line syntax

https://svnvsgit.com/#git-leaky-abstraction

[Leaky abstraction](https://en.wikipedia.org/wiki/Leaky_abstraction)

## 11. Gitの履歴は安全ではない: 本当

> Git history is not safe

https://svnvsgit.com/#git-history-is-not-safe

## 12. Gitはリポジトリの一部へのリードアクセス権限を提供できない: 本当

> Git does not provide granular read access control

https://svnvsgit.com/#git-does-not-provide-granural-access-control

## 13. Gitはバイナリファイルと相性は良くない: 本当

> Git is not friendly to binary files 

https://svnvsgit.com/#git-is-not-for-binary-files

----

# svnに勝ったのはgitではなく、GitHub

[Git didn’t beat SVN, GitHub did.](https://blog.gitprime.com/git-didnt-beat-svn-github-did) という記事を見つけました。gitだけではsubversionのシェアをひっくり返すことはなかっただろうと、CTOの意見がまとめられています。

Git自体はsubversionの完全な上位互換ではないので、この記事はしっくりきました。
Gitが複数人数の開発、特に開発者の所属する組織や所在がばらばらのケースに向いていることと、そのケースを効率化するGitHubは、オープンソースプロジェクトでは特に有効だったように思えます。

# subversionからgitに切り替えるなら、GitHubのようなものも必要？

なんのために移行するかにもよるでしょうが、GitHubのようなものがないと、gitのメリットをいかしきれない可能性が高いです。開発フローも見直す必要があるでしょう。

移行の理由として

* 現状の開発体制の問題を解決したい
* 採用時にgitを使ってると言いたい
* オープンソースプロジェクトに関われる人材を育成したい
* CIなどの連携ツールを使えるようにしたい

などがあると思います。GitやGitHubの利用に切り替えることで、これらが達成できるかは見極めた方が良さそうです。

## subversionからgitへの移行

移行そのものは、ツールや手法はすでにだいぶあります。主なものは下記にまとめています。

[svnからgitへの移行関連の記事まとめ](http://qiita.com/n_slender/items/c55a5a11976c67936676)

## GitHubとそのalternative

費用や社内ネットワークにとどめるなどの理由で、GitHubをそのまま使うことでできないかもしれません。（後者の場場合は、Github Enterpriseでいけるかもしれません）

そんなときは、「Github alternative」でググると、求めるものが見つかるかもしれません。

* [Bitbucket](https://bitbucket.org)
* [Gitlab](https://about.gitlab.com/)
* [Gitblit](http://gitblit.com/)
* [Gitbucket](https://github.com/gitbucket/gitbucket)
* [devhub](https://www.fogcreek.com/fogbugz/devhub)
* [planio](https://plan.io/ja/)

### 参考サイト

* http://alternativeto.net/software/github/?license=opensource
* http://technologyadvice.com/blog/information-technology/github-alternatives/