アカウント名:
パスワード:
Gitってそんなに便利なの?Gitは分散型だから良いとよく聞くが個人で利用するのには管理を集中させて楽できる集中型のSubversionの方がいいのかな?サーバにメイン開発環境と外に持ち出す用のノートPCのソースをSubversionで管理してコミットと更新をするだけだし。こんな感じで一人で二つの開発環境だとGitってなんかめんどくさそう。
GitってGUIの便利なフロントエンドというか定番のフロントエンドってあるの?現状自分は個人の開発環境でのバージョン管理はSubversionでサーバ側はUSVNクライアント側はTortoiseSVN and Eclipse+Subversiveを利用している。
最近SVNから移行しかけましたが、もう少しで挫折するギリ手前で留まっている状態だったりします。こういうのは普段のワークスタイルに合うか合わないかだと思うので決してGITを貶めるつもりはないのですが、私のスタイルには以下がマッチしませんでした。
* Windowsでは使いにくい。特にTortoiseSVNを常用していた身にすれば。 * msysGit, tortoiseGit はまだ日本語ファイル名に対応していないはず。 * UTF-8のCygwinだと日本語ファイル名が通るんだけど、Macに渡すと微妙。 * Win7 64bit + Cygwin の組み合わせだとよくエラーになる。特に巨大バイナリ。 * バイナリの扱いはやっぱりSVNが充実してますよねえ。MS-Office系のDIFFとか慣れると便利。
とは言え「書きかけのファイルをコミット」という安心・手戻りフリーさを体験してしまうとなかなか分散系も捨てがたいのが正直なところ。今後の洗練に期待しつつ、当分はSVNと併用です、私の場合。
同じく、先月GitやHGへの移行をチャレンジしましたが、挫折してSVNに戻りました。 自分がいまいちだと感じたのは、
あたりでした。後者なんかは、SVNじゃないんだしApacheとかいちいち連携させなくていいんだ、ということなんでしょうし、SVNの設定だって今は慣れたものの別に簡単じゃなかった気はしますが・・・。 とはいえ、わざわざ学習コストを支払ってまで現時点で移行するメリットはないかなぁと。
# そもそも自宅の一人作業用環境なんで、SVNでもあまり困ってないという点が大きいですが(汗 # でも後発である以上、文字コード周りのトラブルは解消してて欲しいなぁ。SVNで解決したのになんで今更orz
# でも後発である以上、文字コード周りのトラブルは解消してて欲しいなぁ。SVNで解決したのになんで今更orz
厳しいひとにいわせると、svnでも解決はしていない、そうですよ。ファイル名やログをUnicodeで保存していたとしても、Unicode仕様がプラットフォームによって異なる(正規化の違いとか)ので、まだ完全とはいえない、みたいな。
Git は履歴書き換えの機能が豊富で、ローカルでどんどん作業してコミットを積み重ねたものを後で見返して、順番を並べ替えたりコミットをまとめたり分割したりして、綺麗なヒストリになるほうに書き換えてから push、ということができます。場当たり的なコミットよりは、論理的な単位に区切られるようによく考えられた小さなコミットの積み重ねの方がレビューもしやすいし、あとからバグを追いかけるのも楽になります。
一方、Subversion だとコミットしたものは変更不可能なので、ある程度先を見通しながら作業をするときに手戻りなどでどうしても無駄なコミットが生じがちです。
多分それは良し悪しではなく、そもそも管理するものが違うんだと思う。svnからgitに移行して、最初はgitをsvn/cvs/rcs/sccsのように使おうとして、なんか妙に複雑な気がして馴染めなかった。考え方を切り替えたら、すっと馴染んだ。
svnまでのは「バージョン管理」であって、履歴をす完全に、安全に保存するのが目的。たとえ間違えたコミットがあってもそれもまた履歴の一部だし、そこを敢えて取り出そうとしなければいいだけだから気にしない。「この時点に戻りたい」っていうところに戻れるのが重要。
gitは「パッチ管理」。小分けにされた、それ自体
ある履歴を異なる履歴にくっつけたり(merge)、ある履歴を別の履歴のある時点にくっつけたり(rebase)、どこかの履歴にある一つの差分だけを抜いてきたり(cherry-pick)、etc。こういうがsvnにない便利なことかな? あと、誰がどの差分を書いたのかがいつまでも追跡可能。単に diff を順番に突っ込むんじゃなく、誰が書いた差分なのかを管理してる。あ、これは一人で使ってる分にはいらないか…?でも他人の全然関係ない異なるソフトウェアのリポジトリから特定の差分抜いてきたりもできるんだよね。履歴としては、その差分をcommitしたのはあくまでも元リポジトリの作者。 あと、ちょっと実験的なコードを書こうとして、一旦今まで書いたものをcommitせずにどっかに置いといて(stash)、別のブランチ切ってどんどん書いてみたりとか?
> ある履歴を異なる履歴にくっつけたり(merge)、ある履歴を別の履歴のある時点にくっつけたり(rebase)、どこかの履歴にある一つの差分だけを抜いてきたり(cherry-pick)、etc。こういうがsvnにない便利なことかな?
gitでは歴史捏造できるん?そうなら便利というか危険なかおりが...
自分以外に公開するレポジトリ上での歴史改変は推奨されていないです、もちろん。やろうとすると「どうしてもやりたいなら-fオプション付けてね」と言ってエラーを返されてしまいます。
今は亡きsvkを使っていたならgitの価値が分かると思います。
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project [joelonsoftware.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
自分は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)
そういう「開発者以外に見せる」部分が多い日本の企業には、
そこだけSubversionにしておくのをお勧めします。
#まったくの二度手間ですけどね…
Re: (スコア:0)
git は歴史を捏造してるんじゃなくて、パラレルワールドを好きなだけ作れる(svnでもbranch切れるけどコストも敷居も高い)。
元の歴史が変わるんじゃなくて、そこから別の歴史が始まってる。単に他の歴史の一部を持ってくることも出来るだけ。
通常、公開サーバなどに push してある master branch の履歴は subversion の trunk のように単純に常に積み重なるようにメンテする(これはgitの仕様じゃなくて文化だけど)。別のブランチを個人で開発用、実験用、debug 用、リリース
Re: (スコア:0)
自分以外に公開するレポジトリ上での歴史改変は推奨されていないです、もちろん。やろうとすると「どうしてもやりたいなら-fオプション付けてね」と言ってエラーを返されてしまいます。
Re: (スコア:0)
今は亡きsvkを使っていたならgitの価値が分かると思います。
Re: (スコア:0)
Re: (スコア:0)
Mercurialだと、たまーに本体ぶっ壊すからなぁ…
Re: (スコア:0)
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project [joelonsoftware.com]