Git 3

1 名前：デフォルトの名無しさん mailto:sage [2011/07/12(火) 01:53:58.45 ] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System git-scm.com/ ◆前スレ Git 2 hibari.2ch.net/test/read.cgi/tech/1284467898/ ◆関連サイト Pro Git - Table of Contents progit.org/book/ja/ Git入門 www8.atwiki.jp/git_jp/ 348 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:19:01.27 ] >>346 ここはまんこスレだから 349 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:35:31.42 ] うんこすれですよ 350 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:36:58.20 ] >>335当たり前のことだが、リモートに全く接続しないわけでなく、リモートに接続する頻度が減るだけだからな。 351 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:38:50.88 ] じゃあお前ら#if #elseで処理を有効/無効化したりコメント化したりせずに わざわざ現状をローカルコミットして処理を消して書き直したりしてんの？ コードに残しときゃすぐ分かるのにバカじゃね 352 名前：デフォルトの名無しさん [2011/10/12(水) 15:48:55.65 ] >>351 Linuxカーネルでは#ifは禁止。 コミットログに書いて十分なものを、コメントに書くのは馬鹿。 コメントはメンテされていないことがほとんど。信用できない。 353 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:56:09.42 ] 別にLinuxカーネル作ってるわけじゃねーしｗ ローカルコミットの内容だって信用できないものなのに大事に保管しとく意味ねーだろ 354 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 15:59:07.30 ] >>353 svnのコミットは信用できるのか？ 355 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 16:21:18.26 ] もはやVCSそのものを否定してるレベルだな なんでsvn使ってるんだ？ 356 名前： 忍法帖【Lv=40,xxxPT】 mailto:sage [2011/10/12(水) 16:24:46.00 ] >>351 そんな意味のないプリプロセッサ付けんな! ソースが汚くなって見辛いし、ほんとに大事なものが見えなくなる。 357 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 16:31:32.11 ] >>351 ファイルが無駄にでかくなるし、そもそも修正履歴が追えないだろ 358 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 17:09:35.70 ] >>355 うんこなソースの肥溜め 359 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 17:40:10.63 ] #if がどっさりうまったうんこコードを書く小学生がいるスレはここですか？ 360 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 18:28:06.34 ] 試行錯誤の段階の話だろうが 最後は綺麗にしてコミットするに決まってるだろ 日本語もまともに読めないカスどもが２重管理地獄で悶絶して市ね 361 名前：デフォルトの名無しさん [2011/10/12(水) 18:33:01.30 ] >>360 試行錯誤でも#if使うのはうんこ 362 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 18:35:38.48 ] >>360 その「最後は綺麗にしてコミット」するのが圧倒的に楽なのよ。 Gitで>>342のやり方をすれば。 363 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 19:08:45.38 ] ブランチの概念を教えたほうがいいかもしれない 364 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:01:29.80 ] どんだけ大規模な試行錯誤してんの？ #if #else自体もほとんど使う機会ないんだけど ローカルでそんな大規模な修正してて中央にコミットするときに競合した場合に ものすごく面倒臭いんじゃないの？競合相手も大規模な試行錯誤してんだろう？ 365 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:07:09.87 ] 試行錯誤がフィーチャーブランチだったら公開した方がみんなのためだろう svnはブランチがうんこだからできないけど 366 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:18:54.24 ] コーディング規約で過去コードをコメントや#ifで残すようにとか決まってるんじゃないの？ そういう時にはチーム内管理用のコードと正式コミット用のコードをブランチで分けるんだよ で、邪魔なコメント過去コードは正式コミット用コードにだけ残しておいて、 プロジェクトリーダーが週例前に内部用コードとマージして一括してコミットする。 367 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:32:11.21 ] ただ宗教戦争したいだけのヤツなんだからもういいかげん相手にするなよ・・・ 368 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:44:01.79 ] >>367 神聖なまんこスレからうんこは排除せねばならない 369 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 20:55:48.66 ] >>364 数行の修正×数箇所とか程度の簡単な修正でもGit使うと楽よ。 エディタでソース修正してローカルなコミットを作った後は、 動作確認して必要なコミットだけをまとめてコメント付け直してリモートに登録するとかを コマンド叩くだけでできるし。 #if#elseとかでやる場合は最後もエディタでソースを整形しなおすんでしょ？ その段階で修正間違えたりしたら目も当てられない。 370 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 21:25:50.32 ] たとえば、ファイル a, b, c の３つで、 #if によるコメントアウトを同時に行わないと、効果が無い場合。 a, b, c の修正を採用するか、不採用にするか、いずれにしても、３つのファイルから #if を最終的に掃除する作業を行うことになる。 a, b, c のへの修正を、仮に A とする。 git だと branch A として修正を行ったバージョンを実験できる。 それを採用するならば git merge A として master へ合流させればいいし、不採用なら採用しなければいい。 わざわざ #if を掃除する方法だと、掃除の段階でミスする可能性もある。 たとえば a, b の #if だけ掃除して c の #if を掃除し忘れるような心配も無い。 a,b,c とは別の流れで a, x, y の修正も必要な場合、 git なら a, x, y への修正を仮に B とし、採用なら git merge B すれば良い。 A, B での最終的な採用パターンは４つ。　両方採用、片方採用、両方不採用の４つ。 これを最終的に #if の掃除として行うとしたら面倒。 さらに A, B, C の修正を α 、A, X, Y の修正を β とするような規模になれば、ローカルで自由にcloneできることのメリットを享受できる。 大規模な修正 α, β のために、それぞれclone して独立して修正を行ってしまってもいい。 そして、両方採用（α,β）ならば、α内からβをpullすればいいし、片方採用ならそれをコミットすればいいし、両方不採用なら捨てればいい。 これらは全てローカルでの話。 こうして作ったパッチを最終的に中央へコミットすることになる。 gitには決まった使い方は無い。使い方を自由に工夫できる余地が残されている。 371 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 22:05:14.52 ] 機能A追加、機能Aを使う機能B追加、機能Bを使う機能C追加 のような3つのコミットをしたい時に、機能Cを作りながら機能A、Bもデバッグ して、きれいにして、最後に3つに分けるんだけど、後から分割するのって大変 なんだよね。そういうのは、gitやhgだとコミットを行ったり来たりしながら作 業できて便利。だから例えsvnでやれと言われても、手元でgitとか使っちゃう と思う。 372 名前：デフォルトの名無しさん mailto:sage [2011/10/12(水) 22:42:05.11 ] >>343 よかったな。リリースされたSVN1.7.0でも2重管理とやらの機能が強化されたぞ。 subversion.jp/index.php?option=com_content&view=article&id=50:subversion17enable-git-like-features&catid=25:subversion-article&Itemid=27 373 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 01:22:56.98 ] GitHub のデザイン変わった？ 374 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 11:37:34.43 ] gitはPerforceが高くて買えない貧乏人に最適 むしろgitの方が優れてるし つまり、全人類にとっての光明 375 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 12:40:01.95 ] 今度は買い物P4厨を呼び込むための撒き餌か!? 宗教戦争とか政治論争は別のスレでやろうや。 376 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 16:54:08.89 ] git 1.7.7 の msys版がでたけど、 msysGit-fullinstall-1.7.7-preview20111012.exe からだと 生成されるファイルのサイズが全然違うのはなんでだろうか。 --version の表示結果からして違うせいなのか、 デバッグ用の実行ファイルになってるのかな 377 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 19:55:32.92 ] >>372 それは誤読もいいところ。 そこに書いてあって1.7で実現されたgit的なものは .svnがひとつになったことぐらい。 これは無条件に良くなったと言える。 378 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 19:59:36.91 ] じゃあ相変わらず #if 使う日々が待ってんのか 大変だな 379 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 21:26:01.98 ] 1.7のリリースまでにはまとめられなかっただけだろ。 2重管理とやらをしてないのに。 380 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 21:29:40.03 ] 2重管理地獄の中で悶えて死ね 381 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 23:56:21.07 ] Git使ってると気持ち良くて悶えちゃう 382 名前：デフォルトの名無しさん mailto:sage [2011/10/13(木) 23:58:52.37 ] >>380 お前もローカルでは #if で手動管理してるんだろ？ まあ管理と呼ぶのもおこがましいが 383 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 02:20:43.90 ] 流れ読まずに横から質問…。 ローカルに好き勝手なタイミングでコミットしまくって出来上がった、うまく言語化できない成果物があるとして それをいわゆる中央リポジトリにキレイな履歴で送りつけたいとき、 みんなは具体的にはどうやって整理してるの？ もしやsvnとかとは、コミットの粒度がケタ違いに違う？ 384 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 02:47:30.64 ] >>383 分離すべきと思う単位で分割するかな。つまり機能毎に。 関数追加〜とかの単位だと意味が無いし、逆に複数の機能が単一のコミットに入っていると 一部だけ採用できない。 また、ビルドが通らないというのは論外だけど、例えば「新機能1」「新機能1のテストコード」 とかは同じコミットにすべきだし、単体で意味のあるバグ修正なんかは別のブランチに してマージしたい。俺は。 385 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 04:30:35.56 ] 公開リポジトリまたは他人のリポジトリには、基本、 「この機能いらないからこのコミットだけ却下」 ということができるようにローカルで調整してコミットしたブランチを送りつける いやもちろんプロジェクトのポリシー次第なのだが 単一の機能を実現するためにあちこちいじらないといけないときは説明的なコミット満載の単一のブランチにしたりもする あちらでsqashしてくれるんだろうと思ったらそのままブランチごと適用されてお茶吹いたりもするのであんまり勧めない 386 名前：デフォルトの名無しさん [2011/10/14(金) 06:33:17.19 ] >>379 svn1.7ではクライアントにsqliteを使うことで２重管理を実現しています subversion.jp/index.php?option=com_content&view=article&id=74:apachesubversion17-releasenote&catid=25:subversion-article&Itemid=27 387 名前：デフォルトの名無しさん [2011/10/14(金) 06:35:24.18 ] >>377 残念ながらsvn1.7ではsvnユーザが行っていた２重管理はできなくなりました。 > **警告**: SQLiteライブラリを通じてSQLiteにアクセスがある間に、SQLiteのファイルをコピーするのは安全ではありません。 > 結果として、 Subversionプロセスからアクセスされているワーキング・コピーの複製を作る事(tar, rsync, cpなどで)は、 > Subversion1.7ではサポートされません。それは壊れている可能性があります。(課題 #3596) 388 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 06:39:26.99 ] >>383 最終的には科学的な指標なんてなくて、美的センスの問題。 383の改行が、いうなれば、パッチ整理のようなもの。 １改行は、それぞれが強く関連する、小さな意味単位としての分割。 ２改行は、それらのグループ間での分割。 パッチの分割も３８３の文章と同じ要領。結局これは、最後は美的センスの問題になる。 機械的で具体的な数字には示し難い。 389 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 07:10:39.64 ] >>386-387 いいかげんウザい 馬鹿に付き合ってるお前も馬鹿に見えてるのに気付け 390 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 07:49:10.23 ] 今時VCSにSQLiteを使うのは馬鹿だな 391 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 10:41:29.00 ] >>390 どうちて？ 392 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 11:11:53.08 ] >>391 SQLiteはロック前提だから。 そんなことも分からないsvn開発者は馬鹿。 393 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 11:21:55.97 ] ありがとう。ちょうどsvnスレでその話挙がってるね。スレ違いすまんこ。 394 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 12:19:33.60 ] きにすんなちんこ 395 名前：デフォルトの名無しさん mailto:sage [2011/10/14(金) 16:17:42.57 ] BerkeleyDB依存からは脱却できたのに… 396 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 08:09:23.33 ] なにか要求をシリアライズしているプロセスをかませばいいのに それこそhttpdの何かとか 397 名前：デフォルトの名無しさん [2011/10/15(土) 15:27:30.20 ] gitの中にはファイルの所有者の情報を保存できないのでしょうか？ chownしてdiffしても何も変わっていないと言われてしまいます 398 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 16:20:05.56 ] >>397 できないよ。実行可能かどうかだけ。あとシンボリックリンクはだいじょうぶ。 399 名前：デフォルトの名無しさん mailto:sage [2011/10/15(土) 17:39:52.35 ] >>398 そうなのですか ありがとうございました 400 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 14:01:25.77 ] Git ってたまたまハッシュ値が衝突しちゃった場合ってどうするようになってるの？ 401 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 14:14:39.39 ] どうもしない 402 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 14:25:10.57 ] >>400 前スレの最初の方でやった 403 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 15:02:17.72 ] 変な動作でエラーになると思われる （やろうとした処理にもよるが、無言で上書きされて続行されるようなことにはならない、はず） まあ、エラーになったならそのとき手で修正すればいい 天文学的確率のさらに上をいく事象に事前対処することはリソースの関係上できね あと、これも前スレで言われてるが、ハッシュに日付とかユーザー名とかくっつけるのは衝突回避確率を強化しない 404 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 15:21:17.02 ] ttp://progit.org/book/ja/ch6-1.html > すでにリポジトリに存在するオブジェクトと同じ SHA-1 値を持つオブジェクトをコミットしてした場合、 > Git はすでにそのオブジェクトがデータベースに格納されているものと判断します。 > そのオブジェクトを後からどこかで取得しようとすると、 > 常に最初のオブジェクトのデータが手元にやってきます > (訳注: つまり、後からコミットした内容は存在しないことになってしまう)。 まったく調べずに嘘を書くのはどうかと 405 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 19:19:53.77 ] おまえみたいに調べて訂正してくれるやつがいるから ある意味 問題ないな 406 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 19:24:16.94 ] 俺の間違い push も訂正してほしい 407 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 20:36:16.79 ] うん？コミット時にはエラーでなくてあとで困るってこと？ それってまずくね 408 名前：デフォルトの名無しさん mailto:sage [2011/10/16(日) 20:40:22.26 ] その前にオオカミの心配しろよ 409 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 09:12:15.64 ] SHA1ハッシュが衝突したとしてもオブジェクトの種類が違ったら たぶんエラーになるから、さらに確率は下がるかな。 410 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 13:16:40.23 ] 悪意を持って衝突させる奴が出たらそんなこと言ってられない 411 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 13:22:32.50 ] 質問です。 git svn clone して以下のように作業しているんですが... 1. branch を作って作業 2. master にマージ 3. git svn dcommit このあと、 branch は要らなくなったので git branch -d すると 　　error: The branch '○△□' is not fully merged. 　　消したかったら -D で消せ と怒られます。 git svn dcommit すると、 commit のハッシュ値みたいなのも変わりますので 怒られるのは当たり前だとは思います。 ・・・が、 　　2. master にマージ 　　3. git svn dcommit の間に要らなくなったブランチを削除しておくのが普通なのでしょうか? 412 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 13:22:40.31 ] anonymousでpushできる世界の話？ 413 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 13:30:07.71 ] 2重管理で悶えてるじゃねーかｗ 414 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 18:39:45.51 ] >>322 415 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 22:43:50.41 ] 二重管理ってgit-svnのことだったのかよｗ 416 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 22:46:10.96 ] >>413 無駄だ 417 名前：デフォルトの名無しさん mailto:sage [2011/10/17(月) 23:54:08.81 ] >>410 意図的にSHA-１を衝突させるとか何者？ 418 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 00:00:29.53 ] >>410 できないできない絶対できない やれない気持ちの問題じゃない 419 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 00:02:40.58 ] できるできる絶対できる！ 420 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 00:11:19.82 ] たとえ将来、自由にハッシュを衝突させることができるようになったとしても 既存のリポジトリの内容を破壊できるわけでもなんでもないその行為になんの意味があるの？ 421 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 00:19:18.86 ] // コメントを外すと何故かコミットできない 422 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 01:19:44.68 ] >>411 master で dcommit したら topicブランチの方でも git svn rebase とか git rebase master とかすると、ハッシュ値が違う同じコミットが整理されて、 git branch -d で消せるようになるよ。 ＞2. master にマージ これって merge っていうか FastForward だよね？ あと dcommit する前にも git svn rebase するはず。 git svn じゃなくても rebase すると -D じゃないと消せない はぐれブランチが 出来る可能性はある。 423 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 06:14:39.87 ] >>411 俺はmerge時には--no-ffしてる。 424 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 08:05:41.70 ] 411です。 ありがとうございました。 今日もういちど しらべたりやってみたりしようと思います。 425 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 12:40:59.27 ] 質問です。 masterからtestブランチをつくってcoし、testブランチのほうであるファイルの内容を 変更しました。statusを見てみると、たしかにadd待ちになっています。 その状態でcoしてまたmasterに戻り、なんとなくstatusを見てみると、 ブランチで作業したファイルが、こちらでも変更されたことになっています・・・ ファイルの内容を確認すると、ブランチでの変更と同じものになってしまっています。 ここでまたcoしてtestブランチに戻り、addしてmasterに戻ると、 こちらでもaddされてcommit待ちになっています。 これはこういうもので、ブランチで作業した場合、 commitせずにmasterに戻るのは間違いということでしょうか。 まだgitを使い始めて日が浅いので、誤操作したのかもしれませんし、 正しく理解できていないところもたくさんあると思いますが、 ちょっと困惑してますので、ご教示ください。 426 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 12:48:01.10 ] 2重管理地獄の中で悶えて死ねｗ 427 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 13:09:33.26 ] >>322 428 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 13:15:06.14 ] >>425 addしていないファイルはどのブランチにも属さない 単に管理されていないから、どのブランチにいても「未管理ファイル」として表示される それだけ 429 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 13:18:41.03 ] あー、なんとなくわかってきました。 testのほうでadd/commitするとtestが新しくなり、 masterに切り替えると古い版が維持されてました。 最初からやりなおしてまたtestで修正し、今度はmasterに切り替えてこっちで add/commitすると、masterが新しくなり、testのほうが古いmasterの状態を 維持してました。 こういうものなんですね。co すると、そのブランチの （こっちが期待している元の）状態に全部きれいに切り替えてくれるものと 思ってましたし、ブランチでの修正をmasterでcommitできるとか 考えてもみませんでした。 たぶん私は「ブランチ」の概念から理解しなおさないとダメですね。 430 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 19:23:36.94 ] ブランチというか、ステージングの概念じゃない？ ワークツリーの変更を退避したければ git stash でできるよ でも、とりあえずコミットしておいてあとでコミットを編集・整理するのでも良いと思う 431 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 19:25:39.62 ] 概念がどうとかいうほどのもんかね？ 432 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 19:26:24.02 ] gitってうんこだな 433 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 19:32:13.07 ] >>431 いやだってbranchとは別物じゃない 434 名前：デフォルトの名無しさん [2011/10/18(火) 19:58:28.05 ] gitはbranchとstashの2重管理のうんこ 435 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 22:49:25.35 ] あれからあらためてman読んだり自分で考えたりして、それなりにわかりました。 gitにはようするに「コミットオブジェクト」みたいなものしかないわけですよね。 タグはもちろんブランチも、ユーザのための記号みたいなもの。 だからブランチをつくったばかりなら、両ブランチは対等というかおんなじもので、 どちらが親とか、そういう意味もない。コミットした時点で初めて、 新たな「コミットオブジェクト」がつくられる。 あるコミットオブジェクトがどのオブジェクトから派生したか、といった情報は、 オブジェクトがつくられるときに記録される。 こう考えるとすごくわかりやすくなりましたし、シンプルでいいな、と思いました。 こんな感じに理解しましたが、だいたい合ってますでしょうか？ 436 名前：デフォルトの名無しさん mailto:sage [2011/10/18(火) 23:35:29.83 ] だいたい合ってる しいていえばタグは特定のコミットをピンポイントで指すけど、ブランチはコミットの歴史（HEADの変遷）を指すってところかな 437 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 00:03:29.96 ] Git のタグは、軽量 (lightweight) 版と注釈付き (annotated) 版の2重管理のうんこ 438 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 00:30:05.82 ] バージョン管理システム界にカオスと混乱を招いたgitの罪は重い 439 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 00:45:54.69 ] >>436 ありがとうございます。 タグとブランチの違いについても考えてましたけど、おおむね間違ってなかったみたいです。 使いかたはまだまだ練習中ですが、いろいろわかってきたので面白いです。 440 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 08:05:53.27 ] gitを理解できない奴の頭の中がカオスになってるだけだろ。 自分の頭の悪さを罪だと思えｗ 441 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 08:30:20.91 ] 構うなベアード 442 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 08:58:52.72 ] >>435 シンプルでいいよね。そこに気づけばもう迷うことはないよ。 必要に応じてコマンド覚えていけばいいだけ。おめでとう。 443 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 15:48:27.96 ] 今一番使われているバージョン管理システムってgitなんすか 444 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 16:07:14.60 ] ちょっと調べてみて使い方がスっと入ってこない時点でうんこ 445 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 19:43:26.24 ] >>443 今一番使われてるのはSubversion オープンソース開発でGitが増えている 一般の開発でもGitが増えつつある。 svn→gitは便利になることもある反面失うものも多いから 単純に置き換えが進むというものではなくてずっと共存すると思う。 過去、cvs→svnはなにも失うものが無かったから一気に移行が進んだ 446 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 20:05:51.00 ] 失うものがないもっと良いやつ作れよ 何が分散型だよ中央とローカルで２つsvnリポジトリ持ってるのと一緒じゃねーかｗ 447 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 20:08:14.93 ] 失うもの "SVN厨" 448 名前：デフォルトの名無しさん mailto:sage [2011/10/19(水) 20:14:24.67 ] 何かを得れば何かを失う。人生とはそんなものだ。 状況に応じて使うか使わないかを決めるといい。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef