
Gitのシェア、3年で6倍に 54
ストーリー by hylom
たまにSubversionを使うとコマンドを忘れてて困る 部門より
たまにSubversionを使うとコマンドを忘れてて困る 部門より
danceman 曰く、
Gitのシェアが3年で6倍になっているとのこと(本家/.、Developer World記事)。
Eclipseがオープンソース開発に関して行ったコミュニティ調査によれば、2009年には2%しかなかったGitを利用したプロジェクトが、今年は13%にまで伸びているという。IDCのアナリストAl Hilwa氏は、勢いのついたGitを「一世を風靡したみたいだった」とコメントし、急速に広がりを見せた理由に「分散型構造」を挙げている。Gitを開発したLinus Torvalds氏は「Gitのような分散型モデルから生み出されるものを一度本当理解してしまったら、集中型モデルには二度と戻れなくなるよ」と話している。
今後、Gitはますます勢いを増し、そのうちSubversionやMercurialを押さえて業界のスタンダードとなるのかもしれない。
Eclipseではどうですか? (スコア:2)
EclipseでSubversionのときは、Subclipseを使ってました(最近はSubversiveがメジャーなのかな?)。
Eclipse 3.5でEGitでGitを利用していますが、いまいち使えないような気がします。ここでEclipse+Gitの環境でお使いの方は、どんな環境でお使いですか?
-- gonta --
"May Macintosh be with you"
Re: (スコア:0, オフトピック)
オープンソース界隈ではGitが人気だけれど、一極集中大好きなシステム屋はSubversion使うよね。
Eclipse 3.7 Indigo では Gitが統合されたけれど、なんでSubversionは統合しなかったのかな。
# SubversiveとSubclipseどっちにするか考えるのが面倒。
Subversiveは3.4で統合 (スコア:0)
え?Subversiveは確か3.4からEclipse公式アップデートサイトからインストールできるようになってるけど・・・これ統合されてるって言うんじゃないの?
公式ページ [eclipse.org]もEclipseのサイトにあるし。
昔はライセンス的な問題で、一部プラグインを別途インストールしないといけなかったけど、今はそれも自動で入るようになったし、すっかり統合済みに見えますよ?
Re:Subversiveは3.4で統合 (スコア:1)
あ、ごめんなさい。勘違いしました。
アップデートからインストールできるのはEGitもSubversiveも対等の統合レベルでしたね。
Re: (スコア:0)
一極集中にしたければ中央リポジトリ作るだけでは?
Subversionの方が知名度高くてノウハウ揃ってるだけだと思いますよ。
Re:Eclipseではどうですか? (スコア:1)
Re: (スコア:0)
ハウツー本がわさわさ出て来たら状況は変わると思う。
Re: (スコア:0)
EGitとCygwinのgitを併用してます。
単純にcommit・diff・blame・checkoutならEGitは楽ですが、少しでもそれより複雑になるとzsh+gitでやっちゃうほうが便利です。
SVNKitくらいまでJGitが到達するのはいつになることやら。
gitかMercurialか迷う (スコア:1)
でもgitでもそれくらいできそうな気はする
H.264後継規格(H.265/HVC) (スコア:1)
H.264後継規格(H.265/HVC)の参照ソフトウェアのソース管理はsvnで行われてますが、
gitでもミラーリングされてもいます。
ソフトを組む人はsvnを使いたいけど、そのソフトで研究したい人の希望ではgitも無視できない、
という情勢なんでしょうかね。
まだ誰も言っていないな (スコア:1)
Re:まだ誰も言っていないな (スコア:1, オフトピック)
gifとかもそうですけど発音揺れますよね。
僕はぎっとって読んでて、まわりもわりとそうなんですが、
じっとって呼んでる人いるんでしょうか?
Re: (スコア:0)
初めて触る人とかはじっとって読みますねぇ。周りの人とかもそんな感じ。
JITと読み方被るからって言って、地道にぎっとに誘導してます。
Re: (スコア:0, フレームのもと)
ネタ成立のためには事実を犠牲にする必要があるのです。
自分はSubversion利用 (スコア:0)
Gitってそんなに便利なの?
Gitは分散型だから良いとよく聞くが個人で利用するのには管理を集中させて楽できる集中型のSubversionの方がいいのかな?
サーバにメイン開発環境と外に持ち出す用のノートPCのソースをSubversionで管理してコミットと更新をするだけだし。
こんな感じで一人で二つの開発環境だとGitってなんかめんどくさそう。
GitってGUIの便利なフロントエンドというか定番のフロントエンドってあるの?
現状自分は個人の開発環境でのバージョン管理はSubversionで
サーバ側はUSVN
クライアント側はTortoiseSVN and Eclipse+Subversive
を利用している。
Re:自分はSubversion利用 (スコア:4, 参考になる)
最近SVNから移行しかけましたが、もう少しで挫折するギリ手前で留まっている状態だったりします。
こういうのは普段のワークスタイルに合うか合わないかだと思うので
決してGITを貶めるつもりはないのですが、私のスタイルには以下がマッチしませんでした。
* Windowsでは使いにくい。特にTortoiseSVNを常用していた身にすれば。
* msysGit, tortoiseGit はまだ日本語ファイル名に対応していないはず。
* UTF-8のCygwinだと日本語ファイル名が通るんだけど、Macに渡すと微妙。
* Win7 64bit + Cygwin の組み合わせだとよくエラーになる。特に巨大バイナリ。
* バイナリの扱いはやっぱりSVNが充実してますよねえ。MS-Office系のDIFFとか慣れると便利。
とは言え「書きかけのファイルをコミット」という安心・手戻りフリーさを体験してしまうと
なかなか分散系も捨てがたいのが正直なところ。
今後の洗練に期待しつつ、当分はSVNと併用です、私の場合。
Re:自分はSubversion利用 (スコア:1, 参考になる)
同じく、先月GitやHGへの移行をチャレンジしましたが、挫折してSVNに戻りました。
自分がいまいちだと感じたのは、
あたりでした。後者なんかは、SVNじゃないんだしApacheとかいちいち連携させなくていいんだ、ということなんでしょうし、SVNの設定だって今は慣れたものの別に簡単じゃなかった気はしますが・・・。
とはいえ、わざわざ学習コストを支払ってまで現時点で移行するメリットはないかなぁと。
# そもそも自宅の一人作業用環境なんで、SVNでもあまり困ってないという点が大きいですが(汗
# でも後発である以上、文字コード周りのトラブルは解消してて欲しいなぁ。SVNで解決したのになんで今更orz
Re:自分はSubversion利用 (スコア:1)
厳しいひとにいわせると、svnでも解決はしていない、そうですよ。
ファイル名やログをUnicodeで保存していたとしても、Unicode仕様がプラットフォームによって異なる(正規化の違いとか)ので、まだ完全とはいえない、みたいな。
Re:自分はSubversion利用 (スコア:1)
でも、git の真価は「良い差分を書こう」とするソフトウェア開発に対する哲学の変化だと思う。もし単にバックアップの様に subversion 使ってるなら、git の良さは理解出来ない。subversion の運用にはそういう哲学がないから。
Re: (スコア:0)
という人はもともと少ないんじゃないかな。
>「良い差分を書こう」とするソフトウェア開発に対する哲学の変化
普通にバージョン管理を使っていれば、差分を意識することにはなると思うけど、
そういうことではない?
Re:自分はSubversion利用 (スコア:1)
Git は履歴書き換えの機能が豊富で、ローカルでどんどん作業してコミットを積み重ねたものを後で見返して、順番を並べ替えたりコミットをまとめたり分割したりして、綺麗なヒストリになるほうに書き換えてから push、ということができます。場当たり的なコミットよりは、論理的な単位に区切られるようによく考えられた小さなコミットの積み重ねの方がレビューもしやすいし、あとからバグを追いかけるのも楽になります。
一方、Subversion だとコミットしたものは変更不可能なので、ある程度先を見通しながら作業をするときに手戻りなどでどうしても無駄なコミットが生じがちです。
Re: (スコア:0)
多分それは良し悪しではなく、そもそも管理するものが違うんだと思う。svnからgitに移行して、最初はgitをsvn/cvs/rcs/sccsのように使おうとして、なんか妙に複雑な気がして馴染めなかった。考え方を切り替えたら、すっと馴染んだ。
svnまでのは「バージョン管理」であって、履歴をす完全に、安全に保存するのが目的。たとえ間違えたコミットがあってもそれもまた履歴の一部だし、そこを敢えて取り出そうとしなければいいだけだから気にしない。「この時点に戻りたい」っていうところに戻れるのが重要。
gitは「パッチ管理」。小分けにされた、それ自体
Re:自分はSubversion利用 (スコア:1, 興味深い)
ある履歴を異なる履歴にくっつけたり(merge)、ある履歴を別の履歴のある時点にくっつけたり(rebase)、どこかの履歴にある一つの差分だけを抜いてきたり(cherry-pick)、etc。こういうがsvnにない便利なことかな?
あと、誰がどの差分を書いたのかがいつまでも追跡可能。単に diff を順番に突っ込むんじゃなく、誰が書いた差分なのかを管理してる。あ、これは一人で使ってる分にはいらないか…?でも他人の全然関係ない異なるソフトウェアのリポジトリから特定の差分抜いてきたりもできるんだよね。履歴としては、その差分をcommitしたのはあくまでも元リポジトリの作者。
あと、ちょっと実験的なコードを書こうとして、一旦今まで書いたものをcommitせずにどっかに置いといて(stash)、別のブランチ切ってどんどん書いてみたりとか?
Re: (スコア:0)
> ある履歴を異なる履歴にくっつけたり(merge)、ある履歴を別の履歴のある時点にくっつけたり(rebase)、どこかの履歴にある一つの差分だけを抜いてきたり(cherry-pick)、etc。こういうがsvnにない便利なことかな?
gitでは歴史捏造できるん?
そうなら便利というか危険なかおりが...
Re: (スコア:0)
今は亡きsvkを使っていたならgitの価値が分かると思います。
Re: (スコア:0)
Re: (スコア:0)
Mercurialだと、たまーに本体ぶっ壊すからなぁ…
Re: (スコア:0)
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project [joelonsoftware.com]
Lenus Torvalds (スコア:0)
Re:Lenus Torvalds (スコア:1)
今更ながら修正しました。ご指摘 thx。
Hiroki (REO) Kashiwazaki
Re: (スコア:0)
Re: (スコア:0)
俺は評価する
プロジェクトの規模なのかな? (スコア:0)
>スタンダードとなるのかもしれない。
Linuxの規模だと、Gitが必要だと理解すればいいんですかね。
改めて関連ストーリーを読み返してみたら、
>ぼくの CVS への憎悪が意味するのは、ぼくが Subversion のことを史上最大の無意味な
>プロジェクトだと見ているということだ。Subversion がしばらくの間スローガンにして
>いたのに、「ちゃんとした CVS」みたいなのがあったよね。そんなスローガンでスタート
>したら、もうどこにも行くところがない。CVS をちゃんとすることなんて不可能だからだ。
>「CVS が好きな人は精神病院に行ったほうがいい」
などなど、かなり強烈な発言が。『Linus曰く「Subversionは史上最も無意味なプロジェクト」』
僕のところではちゃんと役に立ってくれてるし評価もしてる。だから拗ねるなよ。 > CVS
Mercurialのほうが良くね? (スコア:0)
gitの高速性が必要なプロジェクトがどれくらいあるのやら・・・
Re: (スコア:0)
高速性というか・・・
Xcodeで対応されたりEclipseの対応状況を見るとGit優勢ですね・・・
# 日本語ファイル名だけは何とかして欲しいんですが・・・
Re: (スコア:0)
MercurialのEclipse対応ってそんなによろしくないんでしょうかね?
CVSやらSVNから移った身としては全然違和感ないというか、むしろ使いやすいんですが。
まぁGitは入れたことないので比較はしてないんですが…
MercurialのEclipse対応 (スコア:0)
先日ちらっと比較検討してみましたけど、MercurialのEclipseプラグインはそもそも日本語ファイル名のファイルがコミットできない(バージョン管理の対象として認識されない)ので、驚きました。
Eclipseプラグインに限った話ではなく、他のGUIクライアントでも似たような感じのようでしたが。
Gitも日本語ファイル名はいろいろ問題を抱えていますが、コミットすらできないというのはちょっと予想外だった。
Gifのシェア、3年で6倍に (スコア:0)
そんなもん調べてんのかよ、と想わず突っこみかけた。
空のディレクトリは? (スコア:0)
という点でbzr一択。
Re: (スコア:0)
開発環境は Windows が中心のため、 Windows 用クライアントの使いやすさを重視して bzr・hg (TortoiseHg)・git (TortoiseGit) を比較した結果、 Windows の UI との親和性は bzr が最も高く、空ディレクトリの扱いに加えて
・日本語ファイル名の扱い
・Subversion との連携
といったところが他よりも良いと感じました。
(だいぶ前に調べたことなので、最近は状況が変わってきているかもしれません。)
TortoiseGit は、 msysGit が bash とかをインストールするせいで make コマンドが正常に動かなくなったりするので、業務での使用には堪えないと思われます。
Re: (スコア:0)
オフトピ気味ですが。私もBazzarを検討しています。
チームでSubversionを使用しており、ようやく慣れてきたところです。
先日一部Git推進派メンバーの布教活動を受け、個人的には分散型に転びました。
が、メンバ全員にgit(というか分散型)を理解し使ってもらうには敷居が高いのではと思っています。(ここの皆さんには信じられないでしょうが)
それで、集中型(チェックアウト)と分散型(ローカルリポジトリ)両方の使い方ができるBazaarが選択肢にあるのですが、良さそうな割に話題にならないので、なにか問題あるのかと心配しています。(単に後発だから?) 個人で使う分には快適なんですが。
実際開発でBazaar使っている人います?
Re: (スコア:0)
bzrのいいところ
1. svnからの移行が容易
gitほど細かい制御は出来ないけど、その分コマンド体系は学習しやすい。
2. Windows用クライアントが素直
インストールも容易。TortoiseBzrは使ってないので分からん。
3. ブランチがファイルシステムと一致する
gitのbranchより学習難易度は低い
bzrのいけてないところ
1. Eclipseのプラグインの質があまり良くない
ファイルの状態の更新でもたつく。設定でどうにか出来るのかもしれないけど。
総括すると、subversion + ローカルコミットな要求にはbzrの方が良いです。
学習も楽だし。
ただ、分散バージョン管理に慣れてくると、gitいいなあと思うようになります。
プロキシに難有り (スコア:0)
http_proxy越しだとチェックアウトできないんですよ。
ある人の好意で、別の場所に http:// でクローンを立ててもらって凌いでいるところ。
Re:プロキシに難有り (スコア:2)
winな人はsvn好きっぽい (スコア:0)
Lenus Torvalds? (スコア:0, 既出)
誰?
Git違い (スコア:0)
Re: (スコア:0)
中央集権的なバージョン管理としてSVN使って (スコア:0)
gitといえば (スコア:0)
TortoiseGitの日本語言語ファイルってその後どうなったん?hylomの人。