アカウント名:
パスワード:
Gitってそんなに便利なの?Gitは分散型だから良いとよく聞くが個人で利用するのには管理を集中させて楽できる集中型のSubversionの方がいいのかな?サーバにメイン開発環境と外に持ち出す用のノートPCのソースをSubversionで管理してコミットと更新をするだけだし。こんな感じで一人で二つの開発環境だとGitってなんかめんどくさそう。
GitってGUIの便利なフロントエンドというか定番のフロントエンドってあるの?現状自分は個人の開発環境でのバージョン管理はSubversionでサーバ側はUSVNクライアント側はTortoiseSVN and Eclipse+Subversiveを利用している。
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オプション付けてね」と言ってエラーを返されてしまいます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
自分はSubversion利用 (スコア:0)
Gitってそんなに便利なの?
Gitは分散型だから良いとよく聞くが個人で利用するのには管理を集中させて楽できる集中型のSubversionの方がいいのかな?
サーバにメイン開発環境と外に持ち出す用のノートPCのソースをSubversionで管理してコミットと更新をするだけだし。
こんな感じで一人で二つの開発環境だとGitってなんかめんどくさそう。
GitってGUIの便利なフロントエンドというか定番のフロントエンドってあるの?
現状自分は個人の開発環境でのバージョン管理はSubversionで
サーバ側はUSVN
クライアント側はTortoiseSVN and Eclipse+Subversive
を利用している。
Re: (スコア: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オプション付けてね」と言ってエラーを返されてしまいます。