11/07/12 01:53:58.45
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
URLﾘﾝｸ(git-scm.com)
◆前スレ
Git 2
ｽﾚﾘﾝｸ(tech板)
◆関連サイト
Pro Git - Table of Contents
URLﾘﾝｸ(progit.org)
Git入門
URLﾘﾝｸ(www8.atwiki.jp)
2:デフォルトの名無しさん
11/07/12 01:54:43.65
◆過去スレ
git スレッド [Linux板]
ｽﾚﾘﾝｸ(linux板)
◆関連スレ
バージョン管理システムについて語るスレ8 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
CVS 1.3 [UNIX板]
ｽﾚﾘﾝｸ(unix板)
CVS導入スレ～ Rev.3 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
subversion バージョン管理【サブバージョン】 [Linux板]
ｽﾚﾘﾝｸ(linux板)
Subversion r13 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
【分散型バージョン管理】 Mercurial 【hg】 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
【bzr】Bazaarでバージョン管理 Rev 3 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
11/07/12 01:55:12.45
◆関連書籍
入門Git [濱野 純 著／秀和システム]
URLﾘﾝｸ(www.shuwasystem.co.jp)
入門git [Travis Swicegood 著、でびあんぐる 監訳／オーム社]
URLﾘﾝｸ(ssl.ohmsha.co.jp)
実用Git [Jon Loeliger 著、吉藤 英明 監訳、本間 雅洋、渡邉 健太郎、浜本 階生 訳／オライリー・ジャパン]
URLﾘﾝｸ(www.oreilly.co.jp)
4:デフォルトの名無しさん
11/07/12 17:29:28.17
１おつ
5:デフォルトの名無しさん
11/07/12 18:34:06.53
まんこまんこです。夏中には何かパッチ送ってみます。
6:デフォルトの名無しさん
11/07/13 07:30:17.19
リモート系のコマンドとブランチとheadとかがよくわかんない
7:デフォルトの名無しさん
11/07/13 12:12:01.18
みなさん CHANGELOG どうやって書いてますか
書かないわけにもいかないし…
8:デフォルトの名無しさん
11/07/13 12:20:50.21
ChangeLog は書式がいろいろあるからなあ
ぶっちゃけ気に入ったのをどっかから持ってきてバージョンごとにコピペして手作業で追記して使うというのがメジャーかと思う
git log --pretty=%s とかで git のログはまとまるので、適当にコピペして貼ったり切ったり
9:デフォルトの名無しさん
11/07/13 12:26:43.09
Git流の開発スタイルだと ChangeLog なんて綴ってられんよな?
10:デフォルトの名無しさん
11/07/13 12:28:07.75
連投スマンが、 ChangeLog(.txt) のコンフリクトを解消するのって本質的な作業じゃないよな。
11:デフォルトの名無しさん
11/07/13 13:16:39.40
>>9
コミットログとチェンジログは役割が違う
チェンジログはまとめ広報に近い
「今回のバージョンの変更点はgitのコミットログ見てくださいね^^v」というのは現状極めて不親切だ
…いや、まあ、不親切でもいいんだけど、不親切だという謗りは免れないだろう
コミットごとにコミットについての追加変更著者情報が書かれているのがコミットログで、
バージョンパッケージングごとにバージョン間の動作の変更点と注意が書かれているのがチェンジログだと思う
実際にいつ誰がツリーにコミットしてソース上の変更行がどこかなんてのはチェンジログには不要というか余分
12:デフォルトの名無しさん
11/07/13 13:29:02.57
redmineのチケットと連動させれば？
13:デフォルトの名無しさん
11/07/13 14:26:15.90
>>11
思うのは勝手だが一般的な流儀とはかけ離れてるなｗ
14:デフォルトの名無しさん
11/07/13 14:37:52.70
このへん、普段どんなプロジェクト追っ掛けてるかによってもけっこう違う気はする
ブランチと pull リクエストの散発的な日付のマージが連打してる git のコミットログから
前バージョンとの変更点を見つけるのは、ものによってはかなりめどい
ソース上どんな変更があったのかは自明だが、それが意味するのはナンデスカみたいな
15:デフォルトの名無しさん
11/07/13 14:46:55.71
>>11
> バージョンパッケージングごとにバージョン間の動作の変更点と注意が書かれているのがチェンジログだと思う
オレはそれはリリースノートだと思うなぁ
16:デフォルトの名無しさん
11/07/13 14:50:31.40
なんというか、「ここで変数 i に10を代入」的な1行コミットログを書く人がいると、なんかとてもめんどくさくなる感じ
ひとつひとつのコミットがきちんと有機的に構成されて説明が充分であれば、コミットログだけでなんとかなるんじゃないかと
でも普通はそんなコミットなんてしないよね
めんどくさいし、整合性も取りづらいというかむしろ全く取れない
「update README」 ではなく、README に何を書いたかきちんとコミットログに書いてる？
「merge branch xxxx」ではなく、そのブランチのマージによってソフトウェアに何が起こるかきちんと説明書いてる？
17:デフォルトの名無しさん
11/07/13 23:06:56.91
ひと山いくらで動いてる人ですら、書いているというのに…
18:デフォルトの名無しさん
11/07/14 06:32:00.47
あんま書いてない例のほうが多い気がす
せめて何がどう直ったのかくらいは書いて欲しい
19:デフォルトの名無しさん
11/07/14 12:09:00.50
GNU だと ChangeLog は開発者用で commit log message そのもの、
利用者向けには NEWS を用意することになってるね。
git だと GNU的な ChangeLog はいらんような気がする
20:デフォルトの名無しさん
11/07/18 23:42:24.33
883 デフォルトの名無しさん [sage] 2011/07/18(月) 21:51:31.64 ID: Be:
gitって、mq相当のことはひたすらローカルリポジトリ内でcommitを整形していく感じなんだな。
ローカルとは言えcommitしたのをいじくり回すってのは結構違和感がある。
ってなことをgitのスレに書くといろいろありそうなのでここに書く。
21:デフォルトの名無しさん
11/07/18 23:44:02.94
884 デフォルトの名無しさん [sage] 2011/07/18(月) 23:22:29.36 ID: Be:
同種ツールの一長一短、ポリシーの違いだからなぁ
使ったことないけどbazaarも同じようなことしようとするとmercurialとまったく同じにはならんのだろう
22:デフォルトの名無しさん
11/07/19 00:02:58.01
>>5
言っとくけど git.vger の Signed-off-by は実名限定だからな。
そのふざけたハンドルを2chで名乗ってるのが誰なのかバレるぜ。
23:デフォルトの名無しさん
11/07/19 02:05:05.44
よく知らないけど mq ってパッチ管理のはずだから
同じことをしたいのなら StGIT とか Guilt になるんじゃないかな
オレの感覚だと git でできるコミット整理ができないから
パッチ管理の mq でお茶を濁している感じ
何か意図するところがあってそういう設計にしているってことなのかもしれないけど
24:デフォルトの名無しさん
11/07/19 10:05:55.10
Advanced uses of Mercurial Queues
URLﾘﾝｸ(foozy.bitbucket.org)
25:デフォルトの名無しさん
11/07/19 12:12:20.37
>>22
2chで実名でカキコするワケねーだろ。
Junioに向かってまんこまんこを名乗るワケねーだろ。
26:デフォルトの名無しさん
11/07/19 12:23:38.38
1まんこタグに関する修正のコミットを実名つきでしたら、
このスレに1まんこ1まんこと書き込んでた人と紐づけされるという話だろう
…まあ、1まんこはただの1まんこで別に他の意味もないし、
1まんこという表現を使う人は（2chみたいなところでは）珍しくもないが
27:デフォルトの名無しさん
11/07/19 12:53:52.72
ちなみに10まんこタグ(ML上では 10k of refs)は遠い将来の課題にして、
さしあたってはスマートタグみたいなものを実現してみようと思う。
git-svn/.rev_map とか notes の情報を lightweight tag と同等に扱えるようにする感じ。
Git はともかく他のオプソも本業ではないので、進捗を急かさないでね。
まんこまんこ
ところで git-notes って活用されてる?
28:デフォルトの名無しさん
11/07/19 13:06:29.73
素で位取り間違えたが10kじゃなく100k
29:デフォルトの名無しさん
11/07/19 14:32:56.99
日本名でパッチ投げるのはそう居ないし、内容見たらバレバレだろｗ
職場でまんこさん呼ばわりされる日も近いｗ
30:デフォルトの名無しさん
11/07/19 19:52:38.13
質問させてください。
windows7 32bitにturtoisGitをインストールしたあと
右クリックのgit cloneを押すと
git have not installed が出てしまいます。
これはどのようにすれば解決するか教えてください。
31:デフォルトの名無しさん
11/07/19 20:06:09.09
msysgitなどをｲﾝｽ子しろとリリースノートに書いてなかった？
まんこまんこ
32:デフォルトの名無しさん
11/07/19 20:07:36.09
さらしあげ
33:デフォルトの名無しさん
11/07/19 20:16:46.76
Git-1.7.6-preview20110708.exe
は入っているのですが、git have not installedが出ます。
エラーの原因がわかりません。アドバイスをお願いいたします。
34:デフォルトの名無しさん
11/07/19 20:28:31.77
git.exe のpathを設定する場所が Settings... にない?
まんこまんこ自らあげ
35:デフォルトの名無しさん
11/07/19 21:07:29.34
ありがとうございます！
夕方から迷っていましたがやっと使えるようになりました！
まんこ紳士さん本当にありがとうございます！
36:デフォルトの名無しさん
11/07/19 21:38:43.29
まだ若いんだから中年のおっさんみたいなマネはやめろよ
37:デフォルトの名無しさん
11/07/19 23:05:37.81
まんこはホントに大好きだが君たちGitについて語ってくれ
Gitそのものをほげるのはもあべたー
38:デフォルトの名無しさん
11/07/20 00:00:21.28
俺だってまんこ大好きだしここはGitスレなんだからもちろん
Gitについて語りたいけど、無駄にまんこ連呼する奴と絡もうとは
思わないな。そういうヤツの相場はまあたいていアレだよ。。。
39:デフォルトの名無しさん
11/07/25 20:45:28.08
Macな知り合いにTower勧めようとしたんだけど、これって有償なのか。
もしかしてAll in Oneなパッケージなわけじゃなくて、ただのフロントエンド？
40:デフォルトの名無しさん
11/07/25 20:52:22.91
自分が使ってもないものを他人に勧めるのか・・・？
41:デフォルトの名無しさん
11/07/25 21:42:24.81
いや、自分WINなんですけど、Macだと簡単に操作できるアプリあったよな…
という記憶から引っ張り出してきまして。
42:デフォルトの名無しさん
11/07/25 21:56:25.64
>自分が使ってもないものを他人に勧めるのか・・・？
まんこのこと?
43:デフォルトの名無しさん
11/07/25 22:21:54.10
管卵
44:デフォルトの名無しさん
11/07/26 00:13:55.69
まんこを使わない奴らによってちんぽスレになりそうな悪寒
45:ななし。
11/07/27 15:49:03.17
カ オ ス ラ ウ ン ジ ゆ る せ な ぁ い ー
46:デフォルトの名無しさん
11/07/28 23:08:55.69
git svnで作ったリポジトリから簡単にsubversion向けのパッチを作れないですかね
exportしたzipファイルをsvnの作業コピーに上書きするのは面倒です
47:デフォルトの名無しさん
11/07/28 23:26:22.56
俺が参加してるsvnプロジェクトだと git diff のパッチ
それどころか git-format-patch ですら歓迎してくれるぞ。
(patch -p1 -N で食えることを皆知ってるからね)
つか SVN 専だったとしても patch -p0 じゃないの?
48:デフォルトの名無しさん
11/07/29 00:08:51.36
git で cvs udpate -D 2011-03-11 みたいなことをするには
どのようにすればよいですか？
49:デフォルトの名無しさん
11/07/29 01:55:26.69
svnコマンドもだいぶ忘れまくってるけど、cvsはもう完全に無理だな
何にも思い出せない
50:デフォルトの名無しさん
11/07/29 17:24:10.89
SVN向けのパッチ、なんてあるんだっけ？専用のフォーマット？
51:46
11/07/29 20:04:29.30
git diffで作ったパッチだとTortoiseMergeで開けないみたいなので
この２つを試しましたが、構文エラーが出て全く動きません！
URLﾘﾝｸ(mojodna.net)
URLﾘﾝｸ(abombss.com)
52:46
11/07/29 20:07:52.82
エラーメッセージはこんな漢字でした
URLﾘﾝｸ(mojodna.net)
\git-svn-diff\git-svn-diff.sh: line 14: conditional b
inary operator expected
\git-svn-diff\git-svn-diff.sh: line 14: syntax error
near `=~'
t\git-svn-diff\git-svn-diff.sh: line 14: `if [[ "$TRAC
KING_BRANCH" =~ URL.* ]]'
URLﾘﾝｸ(abombss.com)
Traceback (most recent call last):
File "\git-svn-utils/git-svn-diff", line 24, in <mo
dule>
svn_rev = get_output(['git-svn', 'find-rev', treeish]).read().strip()
File "\git-svn-utils/git-svn-diff", line 6, in get_
output
p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
File "c:\Python27\lib\subprocess.py", line 672, in __init__
errread, errwrite)
File "c:\Python27\lib\subprocess.py", line 882, in _execute_child
startupinfo)
WindowsError: [Error 2] 指定されたファイルが見つかりません。
53:デフォルトの名無しさん
11/07/30 15:38:41.67
Git GUIでファイルを右クリック→git historyで当該ファイルのみに絞った変更履歴が出せて便利なのですが、
これに相当する操作をコマンドラインのみで行えないでしょうか？
54:デフォルトの名無しさん
11/07/30 16:28:39.58
ブランチにコメントを付けるような機能ってないでしょうか？
ブランチ名だけだと何のためのブランチか忘れてしまうことがあって…
55: 忍法帖【Lv=30,xxxPT】
11/07/31 00:04:08.01
なんで、そんなに大量にブランチ作っているわけ？
作業したらマージしないの？
個人でのブランチは、plainテキストか、wikiで管理してればいいと
思うけど。 担当者名/hogehoge-feature とか fuga-fixとか他人から
見えるのは、変数名同様にちゃんと考えているのだろうか。
56:デフォルトの名無しさん
11/07/31 00:21:14.30
>>53
gitgui使わないから分かんないんだけど、普通に git log パス じゃダメなん？
57:デフォルトの名無しさん
11/07/31 07:04:46.54
>>55
git merge --no-ff とやって、担当者名/hogehoge-feature がログに残ることを義務付けている宗派がある
58:53
11/07/31 11:51:18.53
>>56
>>>53
>gitgui使わないから分かんないんだけど、普通に git log パス じゃダメなん？
変更履歴という書き方がわかりずらかったですね、すいません
当該ファイルのみのコミットログも見れるに越したことはないのですが、
一番見たいのは当該ファイルのみのリビジョン間のdiffなんです
59:デフォルトの名無しさん
11/07/31 13:22:00.86
??
60:デフォルトの名無しさん
11/07/31 16:43:03.52
>>58
git diff --help
61:デフォルトの名無しさん
11/07/31 17:16:37.48
>>58
git log -p パス
62:デフォルトの名無しさん
11/07/31 20:22:40.60
>>55
趣味で組んでるものなので、wiki使うほど大げさではないし、
下手すりゃ数か月後に続きを、みたいなことがあるので
ブランチ名見返してもよく思い出せないことが…
63:デフォルトの名無しさん
11/07/31 20:32:20.29
ブランチ名でログを表示させればいいんじゃないのかな？
そのブランチでやってる作業についてのログを読めば、
なんのブランチか思い出すんでは。
64:デフォルトの名無しさん
11/08/01 12:35:17.57
コミットログをちゃんと書いてれば
ブランチのコメントとか言い出さないと思うんだが。。。
65:デフォルトの名無しさん
11/08/01 17:56:12.27
素直にSourceForge使うことにしました…
66:デフォルトの名無しさん
11/08/09 18:52:10.49
SVNからGitへのリポジトリ移行を考えています。
git-svn clone でSVNのリポジトリをとってくると、SVN上のbranch/tagに代わる
git上のbranchが大量にできるのですが、
このbranchを全てpushする方法というのはあるのでしょうか？
67:デフォルトの名無しさん
11/08/09 19:26:28.91
ある
68:デフォルトの名無しさん
11/08/09 20:04:45.37
>>67
どうすれば良いのでしょう？
69:デフォルトの名無しさん
11/08/09 21:09:50.91
URLﾘﾝｸ(stackoverflow.com)
ですかね？でもリモートブランチを直接pushとかできるんでしょうか…？
70:デフォルトの名無しさん
11/08/10 11:31:39.72
githubで変換できますね。
URLﾘﾝｸ(help.github.com)
今回はこれで十分かも…
71:デフォルトの名無しさん
11/08/10 11:39:19.83
>>70
試してみたらgit svn cloneしてるだけでした…git2svnの説明と共にあったのでてっきりbrach/tagも同期してくれるものかと。
72:デフォルトの名無しさん
11/08/13 17:46:10.88
使い始め初心者です。
git add .とgit commitって、どっちも現在の状態を記録する的なイメージで、漠然としか理解していないのですが、
最終的にはcommitしないとgitとしてはセーブされないのですよね？
これらのコマンドが何をやってるのかをわかりやすく教えていただけないでしょうか？
73:デフォルトの名無しさん
11/08/13 17:58:06.14
add は新しいファイルをgitに登録する
commit は変更を記録する
74:デフォルトの名無しさん
11/08/13 18:01:00.91
stageでググるとaddが何してるかわかるかな
75:デフォルトの名無しさん
11/08/13 21:14:56.89
add .を連発するのは非推奨なのですね。
76:デフォルトの名無しさん
11/08/13 21:28:55.22
1ファイルであってもadd -pで変更箇所ごとにログを付けてはコミット。
77:デフォルトの名無しさん
11/08/14 00:52:54.20
HEADに^をつけると1つ前のバージョン、HEAD^^は二つ前のバージョンって理解でよろしいでしょうか。
78:デフォルトの名無しさん
11/08/14 03:06:16.02
>>77
HEAD^は1つめの親
HEAD^^は1つめの親の1つめの親
マージコミットの場合は複数の親があるので、2つめの親を指定するには
HEAD^2のようにする。
79:デフォルトの名無しさん
11/08/14 04:05:38.81
親ってのが何を指すのかが分からないのですが、
1つ前の親というのは、HEADの一つ前のコミットを指すのですか？
それとも、分かれたブランチの元にあるコミットを指すのですか。
80:デフォルトの名無しさん
11/08/14 05:23:04.50
GitHubに登録したのはいいけれど、インターフェイスが英語だ。
日本語表記にできるみたいなのでしたいのだがどうすればいいですか？
81:デフォルトの名無しさん
11/08/14 06:02:40.76
>>72
git commitといっても今の変更内容を全ていっぺんにコミットしたくない場合もある。
ある目的をもってコード書いてるときに別のちょっとしたバグを見つけて直してしまったり。
あとから問題が発生してこのコミットをとりやめなきゃならなくなったときに後者のバグも生き返ってしまう。
そんなときのために、まずgit addでコミット予定の変更を選択して個別にコミットするよう2段階の構成になってる。
詳しくはステージングでググれ。
良いコミットを。
82:デフォルトの名無しさん
11/08/14 06:05:18.89
>>79
git log --all --graph
して見えるグラフのコミットとコミットの間の線が親子関係。
83:デフォルトの名無しさん
11/08/14 07:56:56.50
>>80
日本語UIはこないだ廃止になった。超がんがれ。
84:デフォルトの名無しさん
11/08/14 14:11:25.61
>>79
とりあえず>>1のProGitとGit入門読んだらどうか。
>>83
あれなんで廃止になったんだろうね。
最近はGit本家もその辺前向きに進んでるのに。
85:デフォルトの名無しさん
11/08/15 01:24:22.39
>>82
1つめの親、2つめの親、というのはどうやって決まるんでしょうか
86:デフォルトの名無しさん
11/08/15 22:55:29.20
いつの間にかTortoiseGitの1.7.2.0が出てた
試してみよう
87:デフォルトの名無しさん
11/08/16 17:04:21.83
git reset --hard HEAD^すると、
More?
More?
fatal: ambiguous argument 'HEAD
': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
となるエラーは何が悪いのでしょうか？
88:デフォルトの名無しさん
11/08/16 17:15:23.42
あと、Win版のPortableGit-1.7.6-preview20110709は、git-bashを起動しても、
bash:tset:command not found
と出て動作が止まってしまうんだが、これって俺だけですか？
89:デフォルトの名無しさん
11/08/16 19:32:18.39
夏の勘違いの悪寒
90:デフォルトの名無しさん
11/08/16 20:06:56.84
HEAD^ の ^ がシェルで何かに解釈されてるんじゃないの?
やるなら git reset --hard 'HEAD^' とか。
> 88
古い UNIX マシンからそのままコピーしてきた .bashrc あたりが残ってるとか。
.bashrc あたりで test と tset を間違えてるとか。
91:デフォルトの名無しさん
11/08/16 20:18:03.34
>>87
^で複数行入力はcmd.exeの仕様。
""で囲めば行けるはず。
92:デフォルトの名無しさん
11/08/16 20:48:16.24
>>90本当だ。.bashrc消したらいけました。
>>90>>91
確かにコマンドプロンプトが解釈してました。
コマンドプロンプトはシングルクォートも通らなかったりして、使うのが鬱陶しいですね。
93:デフォルトの名無しさん
11/08/16 21:07:37.52
Win版のgit-bashで起動時のカレントディレクトリを変更するには、どこをどういじればいいでしょうか？
94:デフォルトの名無しさん
11/08/17 02:11:10.03
付属のGit Bash.vbsをいじって初期cdを変更しておきたいのですが。
95:デフォルトの名無しさん
11/08/20 10:41:56.52
gitをwebdavでってことで、bareを設置してなんとか使えてはいます。
pushできるユーザーにはwebdavへの権限を与えるわけですが、
これって、pushできるユーザーはwebdavに直接アクセスし、
bareのファイルを生で触ってリポジトリの破壊等ができてしまうようです。
ちょっとまずくないですか？
コミッターなんだから破壊権限までありますよ。
気をつけてつかいましょう、っていう思想なのでしょうか……。
96:デフォルトの名無しさん
11/08/20 11:01:30.51
ユーザは全員、リポジトリ全体のコピーを丸ごと clone して持ってるのだから、
破壊されても誰かのリポジトリからコピーし戻せばいいだけじゃね
97:95
11/08/20 13:06:07.35
>>96
davでの公開って、共有スペースにbareを置いてるだけなので
あまり期待できないっぽいですね。
pushを途中で切断したり、耐久テストしてたらやっぱり壊れました。
他にはdavのPUTできる場所を限定して、DELETEを禁止とかで
なんとか運用できないものかと考えてます。
98:デフォルトの名無しさん
11/08/20 13:32:54.37
Gitの仕組み上、pushを途中で切断して壊れるってのは無いと思うけどなー
99:95
11/08/20 16:15:35.83
>>98
davがLOCKしたままになってたようです。
timeoutを設定しました。
100:デフォルトの名無しさん
11/08/25 12:50:21.30
次期OSS標準はそろそろ決まって欲しい
今の勢力って git>hg>bzr なかんじ？
101:デフォルトの名無しさん
11/08/25 15:07:22.35
GoogleCodeがGit受け入れて、ほぼ趨勢は決したんじゃないかな
102:デフォルトの名無しさん
11/08/26 11:02:29.54
復活？
103:デフォルトの名無しさん
11/08/26 11:36:44.71
test
104:デフォルトの名無しさん
11/08/27 03:10:23.55
gitのややこしいコマンド体系、というか破綻してるコマンド体系を
なんとかしようという動きはないのかな。
105:デフォルトの名無しさん
11/08/27 11:04:02.99
慣れると気にならないからなぁ
106:デフォルトの名無しさん
11/08/27 15:08:42.70
慣れると、つーか、開発のスタイルをgitに合わせないといけなくて、
そのスタイルでやるとすんなり来る感じ。
gitのモデルとする開発スタイルは従来のバージョン管理システムとはわりと違う感じ。
107:デフォルトの名無しさん
11/08/27 16:56:18.65
そういう問題じゃなくてだなぁ、他の分散管理に比べてもコマンド体系がおかしいんだよ
信者もいるし、gitの気持ち悪さは暗黙の了解だけとも
108:デフォルトの名無しさん
11/08/27 17:12:14.06
>>104
EasyGit
URLﾘﾝｸ(people.gnome.org)
109:デフォルトの名無しさん
11/08/27 17:53:18.24
TortoiseGit
110:デフォルトの名無しさん
11/08/27 19:23:41.66
>>107
詳しく
111: 忍法帖【Lv=6,xxxP】
11/08/27 20:16:34.12
質問です
ファイアウォールのためネットワーク越しにgit cloneできない環境で
これと同等のことをしたいのですが、
.gitディレクトリ以下を丸ごと相手に渡せば大丈夫ですか？
また、この方法でまずい点はありませんか？
112:デフォルトの名無しさん
11/08/27 20:32:36.72
>>111
それで全データ渡せるけど、無駄なモノもけっこう含まれちゃうかも。
渡す前にgit gcしとけば多少は無駄が省けると思う。
113:111
11/08/27 20:48:04.37
>>112 分かりました
ありがとうございます
114:デフォルトの名無しさん
11/08/27 21:48:14.57
Gitのコマンド面倒くさ
GUI使えないのかな
115:デフォルトの名無しさん
11/08/27 21:49:54.27
TortoiseGit
116:デフォルトの名無しさん
11/08/27 22:17:31.40
>>107
多いのは信者じゃなくてアンチだろｗ
コマンドの数が多いとか難癖つけてさ。
おおかたウインドウズ大好きでC++信者なんだろうが、
頑張ってDISってる姿は滑稽だよ。
117:デフォルトの名無しさん
11/08/27 22:34:58.85
まさに信者だな
118:デフォルトの名無しさん
11/08/27 23:49:04.17
>>111
そういう時はgit bundle使うんじゃなかったっけ
119:デフォルトの名無しさん
11/08/28 01:01:55.19
preview20110708ベースのUTF-8ファイル名対応版 Gitで
日本語ファイルやディレクトリのaddやcommitはできるんだが、
日本語ディレクトリを含むパスでのinitができないのは俺だけ？
120:デフォルトの名無しさん
11/08/28 04:18:53.32
AAA 中のファイル：
*aaa.c *bbb.c ccc.c *Makefile a.out
（*は、commitされてるファイルだとして）
git clone AAA BBB で複製した場合
BBB 中のファイル：
*aaa.c *bbb.c *Makefile
cp AAA BBB -r で複製した場合
BBB 中のファイル
*aaa.c *bbb.c ccc.c *Makefile a.out
cp だと、コミット忘れしてる ccc.c も渡せて便利ｗ a.outのようなゴミも渡すけど。
121:111
11/08/28 08:40:26.10
>>118 man読みました
まさにこれがやりたかったんです
ありがとうございます
122:デフォルトの名無しさん
11/08/28 09:05:35.14
>>119の書き込み見てUTF-8対応版の最新版が来てたのを知った
㌧
123:デフォルトの名無しさん
11/08/29 22:43:10.78
>>120
いやコミットし忘れてるんならまずコミットしろよｗ
124:デフォルトの名無しさん
11/09/01 01:09:15.28
gitの管理を完全にやめるとき、あるいはリセットするとき、
.gitディレクトリを削除すればそれで完全にリセットできますか？
125:デフォルトの名無しさん
11/09/01 01:23:39.58
>>124
管理をやめるなら.gitを消せばいい。
リセットというのがどういう動作を指すのかわからんのだが、
仮にバージョン管理を始める前の状態に戻すという意味なら、
.gitを消すだけでは元に戻せない。
126:デフォルトの名無しさん
11/09/01 01:40:26.81
ありがとうございます。管理をやめるだけで、別にファイルは現状のままでいいので、
それで解決します。
127:デフォルトの名無しさん
11/09/01 12:01:29.02
error: SSL certificate problem, verify that the CA cert is OK. Details:!!!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing ＜URL＞
fatal: HTTP request failed
exit 128 "＜URL＞"
と出て、cloneできないんですけど、どうすればいいでしょうか？
128:デフォルトの名無しさん
11/09/01 15:19:15.22
>>127
cloneしなければいいよ
129:デフォルトの名無しさん
11/09/01 15:42:23.64
エスパーすると、githubにhttpsでアクセスしてる？
130:デフォルトの名無しさん
11/09/01 16:04:39.87
>>129
あ。してます。もしかしてGit Read-Onlyで出てくるアドレスの方を入力するべきなのか。
131:デフォルトの名無しさん
11/09/02 07:17:15.65
エスパーどころかエラー内容全部書いてるだろｗｗ
証明書が確認できないんだとさ、
取得できないならURLと権限を確認しろ
不一致か期限切れなら-fしてみろ
ついでに後者なら鯖管に報告しろ
132:デフォルトの名無しさん
11/09/02 07:19:30.44
エスパーしたのはgithubの部分か、
すまん早とちりだ
133:デフォルトの名無しさん
11/09/02 18:01:55.65
>>127
URLﾘﾝｸ(d.hatena.ne.jp)
134:デフォルトの名無しさん
11/09/02 18:35:14.59
>>133
おおこれは。ありがたいです。
135:デフォルトの名無しさん
11/09/04 14:46:51.52
git apply が当たらない
パッチ読んでもファイル読んでも絶対に適用できる自信がある小さなコミット由来なんだが、でも git apply -v でエラーが出る
…まあ、どうせどっかで間違えてるんだろうけど、ぜんぜん見えねえ
昼寝でもするか…
136:デフォルトの名無しさん
11/09/06 16:50:50.98
"main"と"test"というブランチがあるとして、
testで作業しててcommitやmergeしたら、じつはmainにいたので(略
みたいな事態を避けるために、
特定のブランチに対しては、特に明示しない限りcommitなどをさせない、
ようするに特定のブランチを保護しとくみたいな方法ってありますか？
まだgit自体使い始めでよくわかってないので、ヘンなこと書いてるかもしれませんが...
137:デフォルトの名無しさん
11/09/06 19:32:55.55
コミットをよそに晒してない限り reset も rebase もし放題だ。精一杯失敗しまくれ。
Gitではコミットはなかなか消えん。しばらくは git reflog がトモダチだな。
138:136
11/09/06 20:37:50.52
>>137
reflog でググりました
安心して失敗しまくることにします
139:デフォルトの名無しさん
11/09/06 21:07:40.73
俺はgit-completionでPS1書き換えてブランチ名出すようにしてるな。
140:デフォルトの名無しさん
11/09/06 22:08:09.03
pre-commitフックで拒否するとか。自分はマスターブランチへのコミットは全部弾いてる。
141:デフォルトの名無しさん
11/09/08 16:48:59.16
GitHubからのNotificationsが、メールアドレスにも転送されてくるのですが、これを停止する方法はありませんか？
142:デフォルトの名無しさん
11/09/08 17:24:43.02
あります。
143:デフォルトの名無しさん
11/09/08 19:10:09.91
教えていただきたいのですが。
144:デフォルトの名無しさん
11/09/08 19:36:24.39
設定画面を見れば一目瞭然だと思うのですが。
145:デフォルトの名無しさん
11/09/08 19:39:44.66
ああ。Notification Centerでしたか。
146:デフォルトの名無しさん
11/09/11 23:41:30.95
最近のCygwinはUTF-8だから日本語も問題が起きないんだよね？
てことはmsysがUTF-8になったらmsysGitでも日本語をUTF-8で使えるようになるの？
147:デフォルトの名無しさん
11/09/12 06:08:02.38
理屈はそうだが、msysはUTF-8にならないだろ。
VC++のランタイムをそのまま使うのがmingw、自前でPOSIX層を用意してるのがCygwinなんだから
148:デフォルトの名無しさん
11/09/13 02:53:48.52
gitにはclearcaseでいうmerge arrowという概念はある？
149:146
11/09/13 09:56:30.65
>>147
なるほど。そこらの仕組みがよくわかってなくて
Cygwinのパッケージが少ないのがmsys、ぐらいのイメージだった。
そうするとやっぱり日本語は望み薄だな…
150:デフォルトの名無しさん
11/09/13 10:31:53.47
システムロケール変更すりゃいいじゃん
151:デフォルトの名無しさん
11/09/13 22:03:46.41
今日git checkout .を誤爆して数時間の作業がパーになったんだけど、何とかして修復する方法はない?
152:デフォルトの名無しさん
11/09/13 23:10:59.72
>>151
そのファイルを一度もadd してなかったらどうしようもないな。
checkout もclean みたいに-f 必要だね…
153:デフォルトの名無しさん
11/09/14 08:58:57.49
>>151
-f がついてなかったら、未コミットファイルとの競合でチェックアウトは失敗すると思ったんだが…
checkout -f で上書きしちまったんだったら Git レベルでは修復の方法はない、ハズ。
まめに stash するんだなw そうすればオブジェクトは残る。
154:デフォルトの名無しさん
11/09/15 22:00:19.89
リポジトリに残っていないなら
復元ツールを使うとか
155:デフォルトの名無しさん
11/09/19 01:35:03.40
なんかずっとメンテ中になってるな、ダウンロードできん
156:デフォルトの名無しさん
11/09/19 08:10:47.08
>>155
Gitのソースコードのことなら、kernel.orgがハクられて落ちてる
こっちのミラーからダウソ推奨
URLﾘﾝｸ(ftp.iij.ad.jp)
157:デフォルトの名無しさん
11/09/19 09:53:36.00
kernel.orgはいつ復活するのかのぅ
いろんな所で影響出てる
158:デフォルトの名無しさん
11/09/20 11:31:20.00
まだ乗っ取られたままだったのか。
159:デフォルトの名無しさん
11/09/20 11:38:10.98
乗っとられたままというか、乗っとられていない状態に戻すのに時間かかってるのだろ
160:デフォルトの名無しさん
11/09/20 12:21:15.89
荒らされる前に戻すのが大変てことか
161:デフォルトの名無しさん
11/09/20 13:17:00.60
子供はじっとしてなさい
162:デフォルトの名無しさん
11/09/21 19:46:00.78
今までずっとCygwinでgit使ってきて、今日初めてLinux上でgit使ってみたら速すぎて吹きました。
Cygwin上での遅さ(リーナスが発狂するレベル)を改善するテクニックみたいなのがあれば教えてください。
163:デフォルトの名無しさん
11/09/21 20:05:09.32
Cygwinはファイル操作が致命的に遅いからねえ。
どうしようもないんじゃないのかな。
164:デフォルトの名無しさん
11/09/21 20:15:49.03
ボトルネックになる場所を特定してその部分だけでもcygwinをバイパスすればマシになるかもね
165:デフォルトの名無しさん
11/09/21 20:20:44.58
莫大なファイルを読み書きするところがネックだと思う
でもそこってメイン処理なんじゃ…
166:デフォルトの名無しさん
11/09/21 22:17:52.69
>>162
cygwin を窓から捨てろ
167:デフォルトの名無しさん
11/09/21 23:03:45.36
>>166
確かにhgの方がWindowsフレンドリーみたいですね…
168:デフォルトの名無しさん
11/09/21 23:46:03.85
Cygwinって、まだサポートされているのかよ？
穴だらけなんじゃね？
169:デフォルトの名無しさん
11/09/22 01:47:07.88
>>168
Cygwin使っている人いますか？ その20
ｽﾚﾘﾝｸ(unix板)
170:デフォルトの名無しさん
11/09/22 09:12:31.83
WindowsのForkがクソ重いんだっけ
171:デフォルトの名無しさん
11/09/22 10:03:15.11
forkよりstatの遅さの方が影響してるんでないかなぁ
172:デフォルトの名無しさん
11/09/22 11:20:51.56
ああ、そういえばgccもcolinux上で動かした方がCygwin/MSYSよか速かったなあ。
そっちでgit試してみます。
173:デフォルトの名無しさん
11/09/22 13:59:13.56
cygwinだとgit遅いのかー
というよりcygwinで開発とかすげーな
174:デフォルトの名無しさん
11/09/22 14:16:06.03
遅いと言ってもネイティブのSVNよりは早いと思った
175:デフォルトの名無しさん
11/09/22 15:16:08.05
Cygwin上で開発してるわけではないです。
Windows上で開発してるものをgitでバージョン管理している、というだけで。
(gccの件は過去の経験上、というだけで)
>>174
確かにそうですね。branchやcommitは即座に完了しますし。
ただgit使ってるとstashやらrebaseやら、
svnでは(機能自体無いので)使わなかった便利機能を使い出すと…という感じですね。
176:デフォルトの名無しさん
11/09/22 16:05:46.13
libgit2がWin32ネイティブ対応していてパスをUTF-8で扱うようになったから
いずれはまともに使えるようになるかもしれない
177:デフォルトの名無しさん
11/09/23 00:11:06.58
なに？なに？今度は期待していいの！？
178:デフォルトの名無しさん
11/09/23 01:33:44.94
現状はかなりカオス気味
VS2008以前でビルド通らないままだったり、
DLLは__stdcallなのにヘッダが__cdeclでリンク不能だったり
179:デフォルトの名無しさん
11/09/25 16:21:45.04
なんかtortoisegitである日から
fatal: bad config value for 'core.hidedotfiles' in ./config
ってメッセージが出てpushに失敗するようになった
なんにもしてないのに。
180:デフォルトの名無しさん
11/09/25 19:01:19.50
おまえ以外の誰かが何かしたんだろ
181:デフォルトの名無しさん
11/09/25 21:22:26.62
この部屋は俺以外いないはずだけど
hideDotFilesって何のパラメータ受け入れてくれるんだよ
182:デフォルトの名無しさん
11/10/01 23:15:32.00
1.7.7ｷﾀ━━(ﾟ∀ﾟ)━━!!
URLﾘﾝｸ(article.gmane.org)
> The latest feature release Git 1.7.7 is available.
> The release tarballs are found at:
> URLﾘﾝｸ(code.google.com)
> and their SHA-1 checksums are:
> bbf85bd767ca6b7e9caa1489bb4ba7ec64e0ab35 git-1.7.7.tar.gz
> 33183db94fd25e001bd8a9fd6696b992f61e28d8 git-htmldocs-1.7.7.tar.gz
> 75d3cceb46f7a46eeb825033dff76af5eb5ea3d9 git-manpages-1.7.7.tar.gz
183:デフォルトの名無しさん
11/10/01 23:18:07.55
今日1.7.6.4をソースからビルドしたばっかなのに・・・
184:デフォルトの名無しさん
11/10/01 23:19:08.62
何が新しくなったの？
185:デフォルトの名無しさん
11/10/02 21:21:14.29
あ…ありのまま 今 起こった事を話すぜ！
『newlibのcvsリポジトリをgit cvsimportしたら
1リビジョンだけで7時間もかかったあげくファイルが全部壊れてた』
な… 何を言ってるのか わからねーと思うが(ry
-rwxr-xr-x 1 user user 41349014 Oct 2 21:16 ChangeLog
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 Makefile.am
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 Makefile.in
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 NEWS
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 README
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 acinclude.m4
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 aclocal.m4
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure.host
-rw-r--r-- 1 user user 38711472 Oct 2 21:17 configure.in
何故全ファイルの中身が連結されてるの・・・
186:デフォルトの名無しさん
11/10/03 07:02:35.26
よく七時間も粘ったね
187:デフォルトの名無しさん
11/10/03 07:55:02.82
野良構築された newlib.git 探してみては?
188:デフォルトの名無しさん
11/10/03 19:32:50.04
>>186
調べるとあり得ないレベルで遅いって話は聞いてたからでかいリポジトリだしそんなもんだと思ってた
ところが40MB*1500ファイル=60GBも転送していたという(ローカルのcvsミラーだが)
>>187
探したけどリリースのtarballから作ったリポジトリしか見つからなかったんだ
自分の環境に合わせて修正するのが基本のソースだから簡単に見つかると思ったんだけど
189:デフォルトの名無しさん
11/10/03 22:24:08.99
git cvsimport はインポート後の履歴が変だったことがあったから使ってないな
代わりに cvs2git 使ってる。インクリメンタルインポートできないのが難点だが
190:デフォルトの名無しさん
11/10/04 22:14:45.01
え？BitBucketもGitに対応したの
Bitbucket now rocks Git ? Bitbucket blog URLﾘﾝｸ(blog.bitbucket.org)
191: 忍法帖【Lv=32,xxxPT】
11/10/04 22:15:59.59
対応したと聞いて昼過ぎに登録してきたｗｗ
192:デフォルトの名無しさん
11/10/05 00:58:00.16
GitHub と比較してどうなの？
193:デフォルトの名無しさん
11/10/05 05:11:58.79
最近 Github が人気になりすぎたのか重くてしょうがない。
Buildbot のソースに使うのもはばかられてきた。
194:やんやん ◆yanyan72E.
11/10/05 08:00:53.58
自分の鯖か知人の鯖でgitosisにするのが吉
195:デフォルトの名無しさん
11/10/05 09:55:55.19
gitosisって2年くらい前で更新止まってなかったか
ほぼ上位互換で更新も続いてるgitoliteのほうがいいだろ
196:デフォルトの名無しさん
11/10/05 19:47:52.13
gitolite なんてファイルサーバにレポジトリを直置きするのとあんま変わんないじゃん
Gitorious のほうがいいって
197:デフォルトの名無しさん
11/10/05 19:52:58.80
>>190
クエスチョンなんか付けてるからrumorかとおもた
198:190
11/10/05 21:49:32.90
>>197
ChromeのCreate Link拡張使ったらそうなった。
書きこむ前はついていなかったのに、-が?に変化した
199:デフォルトの名無しさん
11/10/05 23:02:01.15
ギトギトしたスレだなぁ
200:やんやん ◆yanyan72E.
11/10/06 11:00:38.55
ほんとだ。gitosisって相当古いのね。暇を見つけてGitoriousに移行します。
201:デフォルトの名無しさん
11/10/06 12:53:07.12
Gitorious のインストールは手間がかかるから
丸一日くらい費やされると思っといたほうがいい
202:デフォルトの名無しさん
11/10/07 20:11:12.58
ディレクトリ単位でプロジェクトを分けたい（一つのリポジトリに複数プロジェクトをいれたい）
のですが、そういうことはしない方がいいですか？
203:デフォルトの名無しさん
11/10/07 20:22:05.15
いいです
204:デフォルトの名無しさん
11/10/07 20:27:43.80
AというプロジェクトとBというプロジェクトとCというプロジェクトに関連性を持たせたいなあと考えたことはある
現行では素直にディレクトリ分ける以外に方法がないわけだが
205:デフォルトの名無しさん
11/10/07 20:40:43.82
そうですか
ありがとうございました
206:デフォルトの名無しさん
11/10/07 22:13:56.81
submodule?
207:デフォルトの名無しさん
11/10/08 13:04:33.00
すみません。とても基本的なことですが、
bashにて、git blame を実行すると、末尾に(END)が出てきて入力を受け付けず
抜けられない状態に陥ります。
ここから抜ける方法を教えてください。
208:デフォルトの名無しさん
11/10/08 13:23:25.75
PAGERがlessなのかね?
q
209:デフォルトの名無しさん
11/10/08 14:28:37.87
revertは変更をアンドゥしているのではなく、中身は以前の状態にしているけど履歴的にはさらに新しい
変更をした状態にするってことでしょうか？
210:デフォルトの名無しさん
11/10/08 14:46:40.72
>>209
だいたい合ってるけど、「中身を以前の状態に」はしない。
逆方向のパッチを当てるだけ。なのでrevertで指定した
コミットとHEADの間にコミットがある場合は「元に」は
戻らない。
211:デフォルトの名無しさん
11/10/08 16:18:45.58
>>210
結果的に同じ tree を指すことになるのが常。
212:デフォルトの名無しさん
11/10/09 00:07:56.19
>>211
半年前のコミットをrevertしたと考えてみよう
213:デフォルトの名無しさん
11/10/09 01:47:12.53
git push した先のサーバー内の、
ログやデータを一部削除するためのgitコマンドを教えろ
コピペしてすぐ使えるような具体的なコマンドで説明よろ
214:デフォルトの名無しさん
11/10/09 01:52:09.01
>>213
ねーよカス
ガキは糞して寝ろ
215:デフォルトの名無しさん
11/10/09 02:17:10.09
>>213
ssh rm -fr /
216:デフォルトの名無しさん
11/10/09 02:25:54.68
>>215
サンクス！
さっそくパクらせてもらうわ！ザマー！！！！ｗｗｗｗｗｗ
217:デフォルトの名無しさん
11/10/09 02:41:49.73
おやすみ
218:デフォルトの名無しさん
11/10/09 03:04:06.38
おまわりさんこいつです！
219:デフォルトの名無しさん
11/10/09 08:08:07.92
Gitで管理しているディレクトリを動かしても問題は起きませんか？
たとえばhome/mysite/以下のディレクトリを管理している状態で（home/mysite/.git/ディレクトリがある状態で）
mysite/以下をdoc/ディレクトリに移動させたり、
mysite/ディレクトリそのものをmysite8/にリネームしたりしても。
220:デフォルトの名無しさん
11/10/09 08:12:22.98
大丈夫
221:デフォルトの名無しさん
11/10/09 11:06:42.49
sudo を入れないとこが良心的? まあ sudoer のわけないか。
222:デフォルトの名無しさん
11/10/09 14:28:11.33
その前にホスト名
223:デフォルトの名無しさん
11/10/09 14:48:44.32
git cloneをしたところ、以下のエラーが出ました。
fatal: internal error: work tree has already been vital
Current worktree: /home/mysite2
New worktree: /home/mysite2/test/
このエラーは何が原因でどうすれば回避できますか？
224:デフォルトの名無しさん
11/10/09 14:50:17.90
間違い。以下でした。
fatal: internal error: work tree has already been set
Current worktree: /home/mysite2
New worktree: /home/mysite2/test/
225:デフォルトの名無しさん
11/10/09 16:08:17.20
すでにカレントディレクトリよりも上のディレクトリがgitの管理下になっているときには
下層のディレクトリをgit initすることはできないのですが、これはどうしてもそうなのでしょうか？
226:デフォルトの名無しさん
11/10/09 17:37:47.22
俺はホームディレクトリの .git でドットファイルを管理しつつ、
ホームディレクトリのなかにもいろいろ独立したgitリポジトリがあるんだが。
227:デフォルトの名無しさん
11/10/09 21:29:22.17
cvsとsvnは使ったことがあってgitは使ったこと無いんですが
gitに乗り換えた方が便利なんですかね
svnの次世代バージョンみたいな認識で合ってるんですかね
228:デフォルトの名無しさん
11/10/09 22:01:15.24
svnで何も困っていないなら無理に乗りかえなくてもいいと思う
229:デフォルトの名無しさん
11/10/09 22:23:14.54
とりあえず入門gitという本で一通り勉強してみたが
いまいちgitの良さが分かんないな
ステージという概念も単に冗長で面倒くさいだけとしか思えないし
分散バージョン管理システムと言いつつも結局複数人で開発するときは
リモートリポジトリ？を作って集中型のバージョン管理するわけだよね
リーナスという人の自己顕示欲を満たすためだけに作られた
ソフトウェアなんじゃないのと言ったら言いすぎだろうか
230:デフォルトの名無しさん
11/10/09 22:28:06.80
リポジトリ1本で全く困らないような開発体制＆思考体系なら集中型で過不足無いだろうし、
GUIから使うなら.svnが散らばっててもさほど困らないしステージングも冗長かもしれない。
231:デフォルトの名無しさん
11/10/09 22:35:25.93
GitHubを使えるのが大きな利点だと思うぞ。
232:デフォルトの名無しさん
11/10/09 22:53:11.19
svnで満足してるならsvn使ってればいいじゃないか
233:デフォルトの名無しさん
11/10/09 22:53:19.09
ある程度のプロジェクトの規模が大きくないと恩恵少ないかもね
ソースがプログラマ一人の脳みそで足る量を超えたあたりから便利になるかも
234:デフォルトの名無しさん
11/10/09 23:00:13.93
それはsvnでは駄目でgitでしか解決できないことなん
235:デフォルトの名無しさん
11/10/09 23:15:52.92
どうせ一回のコミットごとに申請書提出するような職場なんでしょ？
だったらsvnでいいよ
236:デフォルトの名無しさん
11/10/09 23:27:00.92
良く分からんがgitでリモートリポジトリにコミットするのと
svnでサーバーにコミットするのとは同じことじゃないの？
gitの方がコミット前にステージングという良く分からん手順が必要なだけで
237:デフォルトの名無しさん
11/10/10 00:17:55.94
add -p とか rebase -i とかやらないとgitのうれしさは分からん。
238:デフォルトの名無しさん
11/10/10 02:17:42.78
>>236
そのよく分からない部分を分かるようになるまで勉強するんだ
239:デフォルトの名無しさん
11/10/10 03:49:00.09
なんであるものxの良さがわからないと、
xなんて作ったやつの自己顕示だとかこき下ろしたりするんだ?
おまえがxのことを理解できなくても誰もバカになんかしてないぞ
240:デフォルトの名無しさん
11/10/10 04:07:53.26
ローカルにブランチが持ってこれるというのは俺にとって革命的だった
241:デフォルトの名無しさん
11/10/10 07:25:34.26
ローカルコミットできる便利さはよくわかるが
これによって発生する運用上の課題が
容易に容易に想像できるので気軽に
仕事で使う気にはなれないな。
手元のごみコミットを整理せずに
pushして中央の履歴がカオスとか、
ローカルコミットしただけで
push忘れて反映されないとか、
何週間もローカルで作業して
成果を見せない奴がててくるとか、
どうやって解決してるの？
全員がスキルの高いチームでしか使えない？
242:デフォルトの名無しさん
11/10/10 07:37:59.60
>>241
いい加減スレ違い。こっちでやれ。
バージョン管理システムについて語るスレ8 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
それは全てSVNでも言えること。
GitなどVCSはツールに過ぎない。
コミュニケーション手段は別。
243:デフォルトの名無しさん
11/10/10 07:39:12.71
git branch a
git checkout a
でコード修正作業用のブランチに移動する。
このブランチ内で、各ソースファイルを修正して、適当に数行～数十行修正する度に
git commit -a -m"適当な名前"
でコミットしてしまう。
この段階は試行錯誤の段階なので、数手前に戻りたい場合も出てくる、
その場合は
git log 修正してたファイル名 // 修正してたファイルの関連してるコミットの一覧を表示する
git diff 12345678 修正してたファイル名 > p // 戻りたい位置との差分パッチを得る。 12345678 はコミットIDの例
patch -R < p // パッチを充てて、ファイル状態を修正前に戻す
ひと通り、コード修正が終わったとして、そのコミットログはコメントも適当だし、試行錯誤の後も残ってて汚れてるので、
master との比較で最終結果を一つのパッチにまとめる。
git diff master > p
このパッチをmasterに充てる。
git checkout master
patch < p
git commit -a -m"正式なコミットコメント"
作業中の試行錯誤をgitを活用しながら進めることができ、最終的な修正結果は一つのパッチにまとめてコミットを綺麗な状態で行える。
もちろんパッチを綺麗にしようとしなければ、汚いログのままコミットしてもいいし、作業中の手戻りにgitを使わず古典的なバックアップファイルで行ってもいい。
ステージは、パッチを意味のあるまとまり毎に分けてコミットするためのもの。全部ひとまとめにコミットしてもいい場合は必要ない作業。
gitだと、修正範囲の狭いシンプルな複数のパッチが好まれる。様々な修正が含まれたごった煮パッチ１個にまとめてコミットすると嫌がられる。
244:デフォルトの名無しさん
11/10/10 08:14:21.35
>>まちがえたpushで中央の履歴がカオス
そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。
>>push忘れで反映されない
普通はコード修正が完了したら、まっさきにpushしたいと思うはず。
もたもたしてると他人の修正とのバッティングで面倒に成りかねない。
>>何週間もローカルで秘密的に作業する奴
作業量が増えて損をするだけ。
他の人は、この人の秘密作業の修正コードを知らずに、各自が勝手に作業を進めて、中央（的な役割と決められた場所）へとコミットしてしまう。
中央との差は、中央に公開してしまえば、他の人も、その差を無くすように作業してコミットするが、
中央に公開しないままならば、他の人は、その差を考慮せずにコミットしてしまう。
秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。
これは明らかに損。
ローカルで秘密的に作業する時間が長ければ長いほど、中央との差は広がり、差を埋める作業という労力が増す。
245:デフォルトの名無しさん
11/10/10 08:22:36.63
gitはsvnを面倒臭くした集中型バージョン管理システム
246:デフォルトの名無しさん
11/10/10 08:32:39.02
なんでこんなに中央を直接更新するのを恐れてるのか分からない
別にコミットミスしてもその旨をコミットメッセージに書いて元に戻せばいいだけじゃねえの
ローカルとリモートで２重管理して生産性落ちるだけじゃねえの
git使ったら開発期間が延びてコスト増大で会社が倒産するわｗ
247:デフォルトの名無しさん
11/10/10 08:36:45.47
君がsvnに慣れ親しみすぎて他に移りたくないという気持ちはよく分かった。
実際に日本の会社ではsvnを使ってるだけでも褒められるレベル。
VCSすら使ってない会社はごまんとある。
248:デフォルトの名無しさん
11/10/10 08:38:48.78
ごまんはねぇよ。
249:デフォルトの名無しさん
11/10/10 08:39:19.68
gitのスレでsvnの宣伝にきたのかこの人は
250:デフォルトの名無しさん
11/10/10 08:47:53.21
なんだ、最近はgitスレにまでドカタが湧いてんのか
251:デフォルトの名無しさん
11/10/10 08:50:21.16
>>246
君が想定/経験している規模の開発だとミスがそんなに大した問題にはならないのかもしれない。
ローカルとリモートで2重管理しているように感じる体制だと確かに面倒に感じるかもしれない。
252:デフォルトの名無しさん
11/10/10 09:05:23.07
>>242
視野の狭いやつだなw
253:デフォルトの名無しさん
11/10/10 09:17:48.90
>>243
patch 何て使わずに rebase -i でいいだろ
254:デフォルトの名無しさん
11/10/10 10:37:42.73
remoteに行く前のコミットはいじりまくって良いということに慣れないとな
255:デフォルトの名無しさん
11/10/10 10:47:07.29
むしろremoteにぐちゃぐちゃコミット送る人なんなのローカルの概念ないの
256:デフォルトの名無しさん
11/10/10 11:55:58.23
git reset --soft HEAD^は、なぜHEAD^なのでしょう？
今の状態をとりやめたいからHEADでいいんじゃないでしょうか？
257:デフォルトの名無しさん
11/10/10 11:58:51.44
>>246
試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
まあそう考えないということは履歴なんか見ないんだろうがね。
258:デフォルトの名無しさん
11/10/10 11:58:55.95
HEADから一つ戻すからHEAD^なんだろ
259:デフォルトの名無しさん
11/10/10 12:20:12.89
テスト済みのコードに変更を加えていく場合とかで、レビュー済みのもののみを
履歴に残す形式で開発する状態になるとgitのスタイルがしっくりくる。
テスト済みなのにぐちゃぐちゃ変な変更が入っていくようなことをやる会社は倒産する。
260:241
11/10/10 12:21:40.40
>>243-244 ありがとう
> 作業中の試行錯誤をgitを活用しながら進めることができ、最終的な修正結果は一つのパッチにまとめてコミットを綺麗な状態で行える。
> >>まちがえたpushで中央の履歴がカオス
> そうなる前との差分をコミットして、その段階までリセットしてやりなおせばいい。
「間違えたpush」ではなくて、「試行錯誤の途中経過を含んだコミット」を別のメンバーがpushしまくる。
で履歴にこだわる俺が「なんでこんなもんremoteにpushするんだよ。馬鹿なの死ぬの？」とイライラする絵が浮かぶ。
もちろん日に(svn基準)数10コミットはあるのでいちいち誰かが修正するのなんか無理。
> >>push忘れで反映されない
> 普通はコード修正が完了したら、まっさきにpushしたいと思うはず。
> もたもたしてると他人の修正とのバッティングで面倒に成りかねない。
なるほどね。この辺の心理はGitで共同作業してないからわからなかった。
導入時のガイドラインとして、svnで意味のある単位でのコミットができていれば、
svnのcommitとgitのcommit(同時にpush)を同じぐらいの粒度ですればいいのではないかと思った。
よく考えたら試行錯誤中のこまめなコミットなんかするわけないしな。
> >>何週間もローカルで秘密的に作業する奴
> 作業量が増えて損をするだけ。
> 秘密的に非公開で作業し続ければ、この差を修正する作業を、（本来各自に任せられてた作業をわざわざ）一人で請け負うことになる。
もちろんそのとおりなんだが、
こういうのは「マージに時間がかかって遅れました」と平気で人事にするからな・・・
これは明らかに人の問題だから啓蒙するしかないか。
261:デフォルトの名無しさん
11/10/10 12:26:56.93
結論としてはgitは不要ということだな
あれだろsvnと同じもの作ったらパクッたって言われるから
変な機能付けてオリジナルの画期的なソフトウェアができたとか主張してるんだろｗ
262:デフォルトの名無しさん
11/10/10 12:31:00.91
svnみたいなウンコで満足出来るならDVCSいらない
263:デフォルトの名無しさん
11/10/10 12:36:19.70
git reset --hard HEAD^で取り消したコミットに再び行き着くには、
git reflogでコミット一覧を表示して調べるしかありませんか？
264:デフォルトの名無しさん
11/10/10 12:44:02.79
svnとgitが同じに見えるならお前の目は不要だな
265:デフォルトの名無しさん
11/10/10 12:45:13.91
そんなにsvnが好きならalias使ってgitのコマンドをsvnライクにすればいいよ
266:デフォルトの名無しさん
11/10/10 12:45:30.33
>>263
だね。しかも--hardしてるってことは、addしてなかったファイルはもう手に入らない。。。
267:241
11/10/10 12:47:55.40
>>257
> 試行錯誤だらけのイミフな変更ばかりじゃ履歴見る価値が無いだろ。
> まあそう考えないということは履歴なんか見ないんだろうがね。
コミットを気軽にできるGitの方がむしろ「試行錯誤だらけのイミフな変更」が
remoteに入りやすいんじゃないの？
そうならないためにはpushする前にpushする人が整理しないといけないんだよね。
正直、机上で考えてるだけだといい解決策が思い浮かばない。
「いずれ公開されるから、後で整理するのが嫌なら中途半端なコミットはするな」
「gitの便利さを享受したければpushの前に整理しろ」
という運用ルールにすればいいのかな
268:デフォルトの名無しさん
11/10/10 12:51:45.59
中途半端なコミットなんかsvnでもgitでもありえるわけで
git使ったら解決されるわけでもないわけで
ステージングとかいうイミフな仕組みに工数とられるgitはうんこ
269:デフォルトの名無しさん
11/10/10 12:55:28.32
大体みんなで共有する中央リポジトリが存在する時点で集中型システムだろ
分散型とか言うから中央リポジトリなくてp2pみたいに開発者同士でネットワーク張ったりするのかと思ったのに
ただの面倒な２重管理だもんな糞ゲーだろ
270:デフォルトの名無しさん
11/10/10 13:01:20.54
>>267
Gitは「後で整理する」のが容易なようになってるから後で整理するのも良し、
add -p で最初から良い感じのコミット組み上げていっても良し。公開前は個人の裁量。
ただし、プロジェクトの運営ルールは柔軟に決めればいい。超々タイトなスケジュールを
複数人でやっつけるなら奇麗なコミット云々言ってられないだろうし、その状況では
頻繁な公開=中途半端なコミットのpushが必要になる。
その後のリリースの段階ではやはりそういう履歴は不要になるから、いったんsquashなり
するかも知れない。雑だけど有用な履歴だと判断したらそのままにするかも知れない。
271:デフォルトの名無しさん
11/10/10 13:04:47.64
>>269
「中央」リポジトリなどGitには無い。使う人がそう決めつけるだけだ。
無知でかわいそうなヤツ。
272:デフォルトの名無しさん
11/10/10 13:09:42.02
無くたって現実には作るだろうよ・・・頭の固いやつだな
273:デフォルトの名無しさん
11/10/10 13:15:35.77
中央リポジトリがないってことはリリース時はどこから成果物を取り出すの？
成果物を取り出してる場所が中央リポジトリじゃないの
274:デフォルトの名無しさん
11/10/10 13:23:09.04
「gitイラネsvnでいい」と個人的に思ってるならまだしも
まわりにそれを押し付けるバカの多いこと
275:デフォルトの名無しさん
11/10/10 13:25:33.66
じゃあgitの良いところを教えてくれよ良いものは取り入れたいんだよ
２４００円も出して入門git買ってきたのにうんこ掴まされたんじゃ愚痴も言いたくなるよ
276:デフォルトの名無しさん
11/10/10 13:28:48.27
>>273
分散型やるならまず概念を変えないと先には進めないぜ
成果物は好きに取り出せ
中央だと思う場所があるなら、そこがお前にとっての中央かもしれんね
277:デフォルトの名無しさん
11/10/10 13:29:12.09
「入門Git」がうんこの一言で片付けられたらどうやってGitのいいところを伝えればいいんだよ…
DVCSをいかにして使うかよくわかる名著なのに
278:デフォルトの名無しさん
11/10/10 13:31:02.33
入門gitにうんこついてたのか
交換してもらえよ
279:デフォルトの名無しさん
11/10/10 13:35:34.86
リビジョン番号も意味不明な文字列になってるし
過去のある時点にソフトウェアの状態を合わせたいときに
意思疎通しにくいだろ
280:デフォルトの名無しさん
11/10/10 13:38:35.42
リビジョン番号（笑）
分散してるのに採番とかしねーよ
281:デフォルトの名無しさん
11/10/10 13:39:31.58
svn信者はアホってことが良くわかるな
282:デフォルトの名無しさん
11/10/10 13:46:04.52
>>268
svnで中途半端なコミットなんかありえねーよ。
おめーtrunkのビルドこけさせたら死んで詫びろ。いいかわかったな
283:デフォルトの名無しさん
11/10/10 13:51:11.94
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりBazaarしようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ∥ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
284:デフォルトの名無しさん
11/10/10 14:25:09.84
結局、gitを使うと、svnで培ったオレ流を他の奴が守ってくれないかも
しれないから嫌だ。っていう文句しか言ってないのね。
どうせsvn使ったってオレ流を人に押しつけてるだけだから
うまくいかないのに、それをDVCSのせいにされてもねぇ。
svnでできることはgitでもできる。
gitでは他の便利なことや柔軟な運用もできる。
それでも最終的な成果物のコミットのポリシーをどうするかは
属人的な問題で人と人の意思の疎通でしか解決できない。
VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
いずれプロジェクトは滅茶苦茶になるさ。
それはDVCSのせいじゃない。
285:デフォルトの名無しさん
11/10/10 14:25:19.69
富士通ではVCSすら使ってなかったなあ
大きなプロジェクトはPerforce使ってたけど
git使ったら他には戻れないと個人的に思うなあ
286:デフォルトの名無しさん
11/10/10 14:27:08.02
ちょっと履歴を遡りたいときにはgit reset HEAD^^よりもgit commit HEAD^^の方がいいかな？
287:デフォルトの名無しさん
11/10/10 14:27:49.60
煽ってんじゃねえよてめえ
288:デフォルトの名無しさん
11/10/10 14:34:20.57
>>286
git checkoutだろ
289:デフォルトの名無しさん
11/10/10 14:36:12.50
そうだった。checkout
290:デフォルトの名無しさん
11/10/10 17:35:25.24
ギットギトのgit
291:デフォルトの名無しさん
11/10/10 19:06:37.78
>>256
よく分からんが今の状態を取りやめたいなら
git reset
でいいんじゃね？
292:デフォルトの名無しさん
11/10/10 19:21:26.54
ポインタにNULLを入れて
何回でもギットギトにしてやる
293:241
11/10/11 09:24:33.37
もしかして俺が煽られてるのかなw
>>284
>svnでできることはgitでもできる。
>gitでは他の便利なことや柔軟な運用もできる。
>それでも最終的な成果物のコミットのポリシーをどうするかは
>属人的な問題で人と人の意思の疎通でしか解決できない。
だからそのポリシーをどうすればsvnを使ってるチームが移行しやすいか、
という話なんだが。
運用上svnから劣化する点があれば対策を考えるよね。
運用ルールでなんとかできるのか、どうしようもないのか。
自由度が高いならなおさら「gitにしました。あとは好きにしろ」じゃ
回らないよね
>VCSの不便さを利用してようやくポリシーの統一を図ってるようじゃ
svn使ってたらsvn利用を前提にプロセスを最適化するのは当然だろ
294:デフォルトの名無しさん
11/10/11 09:28:46.16
>>293
> 運用上svnから劣化する点があれば対策を考えるよね。
？？？？？？？？？？？？
295:デフォルトの名無しさん
11/10/11 10:19:13.55
とりあえずオープンソースで今時svn使ってるプロジェクトはうんこ
パッチ書いて送ったら「tortoise diffじゃないとヤダヤダ」とかぬかすような連中ばっかり
296:デフォルトの名無しさん
11/10/11 10:21:50.23
パッチとか面倒なこと考えずに直接更新すればいいだろ
297:284
11/10/11 12:50:03.08
>>293
あなたを煽ったつもりはないです。
自分のプロジェクトはsvnが合ってるからsvnを使うよというだけの人を
どうこういうつもりはまったくないので。
VCS使わないって選択肢もありだと考えますし。
ただ、そのことをもって、
gitそのものをdisるキチガイが湧いていたので、
それに反論したのみです。
298:デフォルトの名無しさん
11/10/11 12:52:01.85
gitは無駄に２重管理する生産性の低いうんこだし
git使って開発してるやつはもっとうんこです
299:デフォルトの名無しさん
11/10/11 12:59:21.60
２重管理厨しつこい
300:デフォルトの名無しさん
11/10/11 13:01:49.61
かかってこいよ
301:デフォルトの名無しさん
11/10/11 13:04:10.15
何をやりたいのか分からないな。
svnを褒め称えてgitをdisればみんながgitを放棄してsvnへ流れてくれるとでも思っているのだろうか。
302:デフォルトの名無しさん
11/10/11 13:43:29.39
２重管理地獄の中で悶えて死ね！！！
303:デフォルトの名無しさん
11/10/11 17:40:00.81
2重管理したくないやつは、しなきゃいいんじゃね？
304:デフォルトの名無しさん
11/10/11 17:50:07.41
何が２重管理なのか理解できないのだが
305:デフォルトの名無しさん
11/10/11 19:31:02.34
2重管理って何?
306:デフォルトの名無しさん
11/10/11 19:41:48.17
派遣先用と自社用に２枚勤務管理表を書かないといけないだろ？
307:デフォルトの名無しさん
11/10/11 20:07:51.85
>>293
svnでの運用ルールが破綻してgitに乗り換えようとしたが
gitが難解でgitに八つ当たりしているのですね？
308:デフォルトの名無しさん
11/10/11 20:35:54.93
二重管理最高だろ。
svnのコミットするのに申請書が必要な環境では
ローカルリポジトリと共有フォルダ内work内のbareリポジトリで
実質的な管理をするもんなんだよ
309:デフォルトの名無しさん
11/10/11 20:56:01.10
２重管理求められる環境とか経験ないんだけど申請書？とか必要ない環境だったら２重管理のメリットなんか何もないってことだよね？
２重管理とかマージするときに競合が起きた場合の面倒臭さがより増大するだけじゃないの
310:デフォルトの名無しさん
11/10/11 21:00:21.90
なるほど、svnのマージを使ったことが無かったのか
311:デフォルトの名無しさん
11/10/11 21:04:23.49
むしろsvnしか使った事が無いから、必要以上に競合を恐れてるのでは？
312:デフォルトの名無しさん
11/10/11 21:49:49.44
マスターリポジトリと各開発者のローカルファイルがリアルタイムで同期していない以上、
svnもgitも多重管理していることに違いは無いと思うけど。その言い方を真似ると。
その上で、君はsvnでは多重管理している意識が無いと言っているわけだけど
同様にgit使ってる人も多重管理してる意識は無いよ。
ローカルコミットは自分の完全支配下にあるブランチ、とでも考えれば理解しやすい？
(あ、svnでブランチ切るのも多重管理だね。trunkしか使ってないってことはないよね？)
svnだと開発者の誰もが好き勝手ブランチ切ったりできないでしょ。不便じゃない？
313:デフォルトの名無しさん
11/10/11 21:49:55.07
使ったこと無いのに批判してるように見えるなあ
とりあえず社内がsvn使っててもローカルフォルダだけgitで運用する事もできるし
挫折しないで一通り試してみ
314:デフォルトの名無しさん
11/10/11 22:34:11.38
Linux開発向けに大人数でバザール的に作業すること目指してるのが
社内数人のチームで完全に設計してから実装するみたいな用途には
オーバーエンジニアリングに感じるのかも。
パッチ書こうとしてるOSSのリポジトリがsvnだとがっかりするけど
職場のリポジトリがsvnでも若干の不便しか感じない。
315:デフォルトの名無しさん
11/10/11 23:28:41.20
svn もまともに使えないのに git は無理だろう
と、思うことはある
バージョン管理は二の次だったりする所もあるからなあ
レベルは決して低くない所だが
316:284
11/10/11 23:49:37.35
>>293 はまともなsvn使いがgitへの移行を検討するに当たって
gitの実運用上の問題を挙げてるにすぎないんだから、
これ以上煽ってやるな、真面目っぽいからかわいそうだ。
317:デフォルトの名無しさん
11/10/12 00:04:26.67
いや、svnのコンフリクトを防ぐために運用ルールを定めているのであれば、それはツールに使われている。
欠陥ツールであるsvnを破棄してgitに移行すべきであろう。
318:デフォルトの名無しさん
11/10/12 00:05:01.21
俺には>>298とか>>309への反論に見えるな
素人考えでもマージするときの面倒さはsvnもgitも変わらないように思えるんだが
319:デフォルトの名無しさん
11/10/12 00:41:17.03
マージ作業自体の手間はかかるにしても一旦コミットしてからマージできるから
リモートにブランチつくったりローカルの変更を手で保存したりしなくても
変更が失われないってのは結構な利点じゃない？
320:デフォルトの名無しさん
11/10/12 08:00:56.75
gitはTortoiseGitとmsysgitの２重管理のうんこ
321:デフォルトの名無しさん
11/10/12 08:33:09.15
tortoisegit がうんこだったのは同意。ログ見るときと日本語で commit message 書くときくらいしか使ってなかった。
入れ替えるモチベーションなくしてんだが、最近のはどーなんだろ?
もう msysgit のコマンドラインで十分になっちゃってるしなー。
ところでロック厨がわいてくるだろうと蒸し返すw
322:デフォルトの名無しさん
11/10/12 08:54:23.81
>>320
2重管理という用語を使ってる君自身がその用語をちゃんと定義しきれていない気がするよ。
もうちょっと正確に言ってもらわないと、君が疑問に思っていることがあっても残念ながら中々答えてあげられない。
323:デフォルトの名無しさん
11/10/12 09:05:20.36
意味もわからない覚え立ての言葉を使いたい小学生なんだろ
324:デフォルトの名無しさん
11/10/12 09:26:45.65
すぐうんこ言うしな
325:デフォルトの名無しさん
11/10/12 11:13:59.02
ローカルにコミットするメリットがさっぱり分からん
326:デフォルトの名無しさん
11/10/12 11:20:47.64
>>325
ここgitのスレだからそういう一般的な話はこっちで聞いた方が良いよ。
バージョン管理システムについて語るスレ8
ｽﾚﾘﾝｸ(tech板)
327:デフォルトの名無しさん
11/10/12 11:51:08.17
いやローカルにコミットできることを分散型だと言ってgitの長所だと主張してんだろ？
そこは納得いく説明をしてくれないと
328:デフォルトの名無しさん
11/10/12 11:53:58.13
回線が切れてても大丈夫。
履歴を好き勝手編集しても大丈夫。
パスワードなどの個人情報を入れた状態でcomitするなどの事故を減らせる。
329:デフォルトの名無しさん
11/10/12 13:15:20.42
ローカルコミットの何が嬉しいの？って言う時点で分散型を
必要としてないよ。どうせマンドクセーってぎゃーぎゃー言うだけ。
330:デフォルトの名無しさん
11/10/12 13:20:25.71
回線が切れてても中央のリポジトリから最新版を取ってきたりコミットできるの
履歴を簡単に書き換えられて過去のある版を取り出したくなったときとか困らないの
事故を減らせる代わりに面倒臭くなってるよね
331:デフォルトの名無しさん
11/10/12 14:03:05.74
>>327
gitだけの特徴じゃないんだよ。
332:デフォルトの名無しさん
11/10/12 14:03:16.03
>>330
履歴の書き換えはローカルだけだから無問題
タグが何のためにあるのか考えよう
タグを見るためにいちいちsvn listコマンドなどを叩いてリモートに見に行く方ががよっぽど面倒
333:デフォルトの名無しさん
11/10/12 14:07:09.37
>>331
svk
334:デフォルトの名無しさん
11/10/12 14:32:19.88
回線が切れてたらさすがにリモートの最新版は取ってこれないが、log,diff,(ローカルに現存してるコミット間での)mergeなんかは使える
というかリモートリポジトリを必要とするpull/push以外の全機能が使えるしそういうコマンドはもともと通信しない
335:デフォルトの名無しさん
11/10/12 14:40:32.34
リモートを書き換えないなら何もしてないのと一緒じゃん
ローカルのものをいきなり成果物として客にリリースしたりするの
336:デフォルトの名無しさん
11/10/12 14:43:33.10
プログラミングにおいて一切の試行錯誤をしないのか？
ああ、与えられた仕様書をコードに起こすだけのコーダなのか
gitはそういうコーダのためのツールじゃないから
337:デフォルトの名無しさん
11/10/12 14:45:06.48
回線切れてるならsvnだろうがgitだろうが手旗信号でも使わないかぎりリモートと通信できるはずないだろｗ
338:デフォルトの名無しさん
11/10/12 14:46:05.37
ローカルでコミットなんかしなくても試行錯誤はできるだろ
339:デフォルトの名無しさん
11/10/12 14:48:00.16
試行錯誤をどうやって管理すんの？
log見たり複数の試行錯誤のdiffとったりmergeしたりせんの？
340:デフォルトの名無しさん
11/10/12 14:54:22.27
中央にコミットするまでのあるまとまった単位の修正だろ？
そんなもん#if 0 #else #endif とかコメントで十分だろ
341:デフォルトの名無しさん
11/10/12 14:57:03.11
え？svn使いってそんなことしてんの？いまどき？
それで十分ならマスターリポジトリもそうやって管理したら？
342:デフォルトの名無しさん
11/10/12 15:00:17.54
ローカルな試行錯誤を小刻みにコミットしながらできるのは便利だよ。
そして、その試行錯誤を1～複数のコミットに整理してから、管理されているリモートにpullしてやればいい。
管理されるのは、ごちゃごちゃな試行錯誤より、整理された試行錯誤のほうがいいよ。
343:デフォルトの名無しさん
11/10/12 15:00:29.63
実際それでうまくいってるし２重管理の必要性を感じない
マージするより#if #else でパッと見で分かる方が早いじゃん
344:デフォルトの名無しさん
11/10/12 15:05:21.76
Gitは漠然とした仕様の中手探りで開発するときに向いている。
自分でソフトウェアやプラグインを作るときは仕様の変更や試験的な実装がしょっちゅうあるだろ。
345:デフォルトの名無しさん
11/10/12 15:12:12.23
>>335
回線のつながってない客先にどうやって納品するの？
まさかzip？
それで客先で改変してカオスになるわけだ。
346:デフォルトの名無しさん
11/10/12 15:15:33.01
いつまで小学生構ってるんだよ・・・
347:デフォルトの名無しさん
11/10/12 15:16:49.69
>>337
bundle
348:デフォルトの名無しさん
11/10/12 15:19:01.27
>>346
ここはまんこスレだから
349:デフォルトの名無しさん
11/10/12 15:35:31.42
うんこすれですよ
350:デフォルトの名無しさん
11/10/12 15:36:58.20
>>335当たり前のことだが、リモートに全く接続しないわけでなく、リモートに接続する頻度が減るだけだからな。
351:デフォルトの名無しさん
11/10/12 15:38:50.88
じゃあお前ら#if #elseで処理を有効/無効化したりコメント化したりせずに
わざわざ現状をローカルコミットして処理を消して書き直したりしてんの？
コードに残しときゃすぐ分かるのにバカじゃね
352:デフォルトの名無しさん
11/10/12 15:48:55.65
>>351
Linuxカーネルでは#ifは禁止。
コミットログに書いて十分なものを、コメントに書くのは馬鹿。
コメントはメンテされていないことがほとんど。信用できない。
353:デフォルトの名無しさん
11/10/12 15:56:09.42
別にLinuxカーネル作ってるわけじゃねーしｗ
ローカルコミットの内容だって信用できないものなのに大事に保管しとく意味ねーだろ
354:デフォルトの名無しさん
11/10/12 15:59:07.30
>>353
svnのコミットは信用できるのか？
355:デフォルトの名無しさん
11/10/12 16:21:18.26
もはやVCSそのものを否定してるレベルだな
なんでsvn使ってるんだ？
356: 忍法帖【Lv=40,xxxPT】
11/10/12 16:24:46.00
>>351
そんな意味のないプリプロセッサ付けんな! ソースが汚くなって見辛いし、ほんとに大事なものが見えなくなる。
357:デフォルトの名無しさん
11/10/12 16:31:32.11
>>351
ファイルが無駄にでかくなるし、そもそも修正履歴が追えないだろ
358:デフォルトの名無しさん
11/10/12 17:09:35.70
>>355
うんこなソースの肥溜め
359:デフォルトの名無しさん
11/10/12 17:40:10.63
#if がどっさりうまったうんこコードを書く小学生がいるスレはここですか？
360:デフォルトの名無しさん
11/10/12 18:28:06.34
試行錯誤の段階の話だろうが
最後は綺麗にしてコミットするに決まってるだろ
日本語もまともに読めないカスどもが２重管理地獄で悶絶して市ね
361:デフォルトの名無しさん
11/10/12 18:33:01.30
>>360
試行錯誤でも#if使うのはうんこ
362:デフォルトの名無しさん
11/10/12 18:35:38.48
>>360
その「最後は綺麗にしてコミット」するのが圧倒的に楽なのよ。
Gitで>>342のやり方をすれば。
363:デフォルトの名無しさん
11/10/12 19:08:45.38
ブランチの概念を教えたほうがいいかもしれない
364:デフォルトの名無しさん
11/10/12 20:01:29.80
どんだけ大規模な試行錯誤してんの？
#if #else自体もほとんど使う機会ないんだけど
ローカルでそんな大規模な修正してて中央にコミットするときに競合した場合に
ものすごく面倒臭いんじゃないの？競合相手も大規模な試行錯誤してんだろう？
365:デフォルトの名無しさん
11/10/12 20:07:09.87
試行錯誤がフィーチャーブランチだったら公開した方がみんなのためだろう
svnはブランチがうんこだからできないけど
366:デフォルトの名無しさん
11/10/12 20:18:54.24
コーディング規約で過去コードをコメントや#ifで残すようにとか決まってるんじゃないの？
そういう時にはチーム内管理用のコードと正式コミット用のコードをブランチで分けるんだよ
で、邪魔なコメント過去コードは正式コミット用コードにだけ残しておいて、
プロジェクトリーダーが週例前に内部用コードとマージして一括してコミットする。
367:デフォルトの名無しさん
11/10/12 20:32:11.21
ただ宗教戦争したいだけのヤツなんだからもういいかげん相手にするなよ・・・
368:デフォルトの名無しさん
11/10/12 20:44:01.79
>>367
神聖なまんこスレからうんこは排除せねばならない
369:デフォルトの名無しさん
11/10/12 20:55:48.66
>>364
数行の修正×数箇所とか程度の簡単な修正でもGit使うと楽よ。
エディタでソース修正してローカルなコミットを作った後は、
動作確認して必要なコミットだけをまとめてコメント付け直してリモートに登録するとかを
コマンド叩くだけでできるし。
#if#elseとかでやる場合は最後もエディタでソースを整形しなおすんでしょ？
その段階で修正間違えたりしたら目も当てられない。
370:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/12 22:05:14.52
機能A追加、機能Aを使う機能B追加、機能Bを使う機能C追加
のような3つのコミットをしたい時に、機能Cを作りながら機能A、Bもデバッグ
して、きれいにして、最後に3つに分けるんだけど、後から分割するのって大変
なんだよね。そういうのは、gitやhgだとコミットを行ったり来たりしながら作
業できて便利。だから例えsvnでやれと言われても、手元でgitとか使っちゃう
と思う。
372:デフォルトの名無しさん
11/10/12 22:42:05.11
>>343
よかったな。リリースされたSVN1.7.0でも2重管理とやらの機能が強化されたぞ。
URLﾘﾝｸ(subversion.jp)
373:デフォルトの名無しさん
11/10/13 01:22:56.98
GitHub のデザイン変わった？
374:デフォルトの名無しさん
11/10/13 11:37:34.43
gitはPerforceが高くて買えない貧乏人に最適
むしろgitの方が優れてるし
つまり、全人類にとっての光明
375:デフォルトの名無しさん
11/10/13 12:40:01.95
今度は買い物P4厨を呼び込むための撒き餌か!?
宗教戦争とか政治論争は別のスレでやろうや。
376:デフォルトの名無しさん
11/10/13 16:54:08.89
git 1.7.7 の msys版がでたけど、
msysGit-fullinstall-1.7.7-preview20111012.exe からだと
生成されるファイルのサイズが全然違うのはなんでだろうか。
--version の表示結果からして違うせいなのか、
デバッグ用の実行ファイルになってるのかな
377:デフォルトの名無しさん
11/10/13 19:55:32.92
>>372
それは誤読もいいところ。
そこに書いてあって1.7で実現されたgit的なものは
.svnがひとつになったことぐらい。
これは無条件に良くなったと言える。
378:デフォルトの名無しさん
11/10/13 19:59:36.91
じゃあ相変わらず #if 使う日々が待ってんのか
大変だな
379:デフォルトの名無しさん
11/10/13 21:26:01.98
1.7のリリースまでにはまとめられなかっただけだろ。
2重管理とやらをしてないのに。
380:デフォルトの名無しさん
11/10/13 21:29:40.03
2重管理地獄の中で悶えて死ね
381:デフォルトの名無しさん
11/10/13 23:56:21.07
Git使ってると気持ち良くて悶えちゃう
382:デフォルトの名無しさん
11/10/13 23:58:52.37
>>380
お前もローカルでは #if で手動管理してるんだろ？
まあ管理と呼ぶのもおこがましいが
383:デフォルトの名無しさん
11/10/14 02:20:43.90
流れ読まずに横から質問…。
ローカルに好き勝手なタイミングでコミットしまくって出来上がった、うまく言語化できない成果物があるとして
それをいわゆる中央リポジトリにキレイな履歴で送りつけたいとき、
みんなは具体的にはどうやって整理してるの？
もしやsvnとかとは、コミットの粒度がケタ違いに違う？
384:デフォルトの名無しさん
11/10/14 02:47:30.64
>>383
分離すべきと思う単位で分割するかな。つまり機能毎に。
関数追加～とかの単位だと意味が無いし、逆に複数の機能が単一のコミットに入っていると
一部だけ採用できない。
また、ビルドが通らないというのは論外だけど、例えば「新機能1」「新機能1のテストコード」
とかは同じコミットにすべきだし、単体で意味のあるバグ修正なんかは別のブランチに
してマージしたい。俺は。
385:デフォルトの名無しさん
11/10/14 04:30:35.56
公開リポジトリまたは他人のリポジトリには、基本、
「この機能いらないからこのコミットだけ却下」
ということができるようにローカルで調整してコミットしたブランチを送りつける
いやもちろんプロジェクトのポリシー次第なのだが
単一の機能を実現するためにあちこちいじらないといけないときは説明的なコミット満載の単一のブランチにしたりもする
あちらでsqashしてくれるんだろうと思ったらそのままブランチごと適用されてお茶吹いたりもするのであんまり勧めない
386:デフォルトの名無しさん
11/10/14 06:33:17.19
>>379
svn1.7ではクライアントにsqliteを使うことで２重管理を実現しています
URLﾘﾝｸ(subversion.jp)
387:デフォルトの名無しさん
11/10/14 06:35:24.18
>>377
残念ながらsvn1.7ではsvnユーザが行っていた２重管理はできなくなりました。
> **警告**: SQLiteライブラリを通じてSQLiteにアクセスがある間に、SQLiteのファイルをコピーするのは安全ではありません。
> 結果として、 Subversionプロセスからアクセスされているワーキング・コピーの複製を作る事(tar, rsync, cpなどで)は、
> Subversion1.7ではサポートされません。それは壊れている可能性があります。(課題 #3596)
388:デフォルトの名無しさん
11/10/14 06:39:26.99
>>383
最終的には科学的な指標なんてなくて、美的センスの問題。
383の改行が、いうなれば、パッチ整理のようなもの。
１改行は、それぞれが強く関連する、小さな意味単位としての分割。
２改行は、それらのグループ間での分割。
パッチの分割も３８３の文章と同じ要領。結局これは、最後は美的センスの問題になる。
機械的で具体的な数字には示し難い。
389:デフォルトの名無しさん
11/10/14 07:10:39.64
>>386-387
いいかげんウザい
馬鹿に付き合ってるお前も馬鹿に見えてるのに気付け
390:デフォルトの名無しさん
11/10/14 07:49:10.23
今時VCSにSQLiteを使うのは馬鹿だな
391:デフォルトの名無しさん
11/10/14 10:41:29.00
>>390
どうちて？
392:デフォルトの名無しさん
11/10/14 11:11:53.08
>>391
SQLiteはロック前提だから。
そんなことも分からないsvn開発者は馬鹿。
393:デフォルトの名無しさん
11/10/14 11:21:55.97
ありがとう。ちょうどsvnスレでその話挙がってるね。スレ違いすまんこ。
394:デフォルトの名無しさん
11/10/14 12:19:33.60
きにすんなちんこ
395:デフォルトの名無しさん
11/10/14 16:17:42.57
BerkeleyDB依存からは脱却できたのに…
396:デフォルトの名無しさん
11/10/15 08:09:23.33
なにか要求をシリアライズしているプロセスをかませばいいのに
それこそhttpdの何かとか
397:デフォルトの名無しさん
11/10/15 15:27:30.20
gitの中にはファイルの所有者の情報を保存できないのでしょうか？
chownしてdiffしても何も変わっていないと言われてしまいます
398:デフォルトの名無しさん
11/10/15 16:20:05.56
>>397
できないよ。実行可能かどうかだけ。あとシンボリックリンクはだいじょうぶ。
399:デフォルトの名無しさん
11/10/15 17:39:52.35
>>398
そうなのですか
ありがとうございました
400:デフォルトの名無しさん
11/10/16 14:01:25.77
Git ってたまたまハッシュ値が衝突しちゃった場合ってどうするようになってるの？
401:デフォルトの名無しさん
11/10/16 14:14:39.39
どうもしない
402:デフォルトの名無しさん
11/10/16 14:25:10.57
>>400
前スレの最初の方でやった
403:デフォルトの名無しさん
11/10/16 15:02:17.72
変な動作でエラーになると思われる
（やろうとした処理にもよるが、無言で上書きされて続行されるようなことにはならない、はず）
まあ、エラーになったならそのとき手で修正すればいい
天文学的確率のさらに上をいく事象に事前対処することはリソースの関係上できね
あと、これも前スレで言われてるが、ハッシュに日付とかユーザー名とかくっつけるのは衝突回避確率を強化しない
404:デフォルトの名無しさん
11/10/16 15:21:17.02
URLﾘﾝｸ(progit.org)
> すでにリポジトリに存在するオブジェクトと同じ SHA-1 値を持つオブジェクトをコミットしてした場合、
> Git はすでにそのオブジェクトがデータベースに格納されているものと判断します。
> そのオブジェクトを後からどこかで取得しようとすると、
> 常に最初のオブジェクトのデータが手元にやってきます
> (訳注: つまり、後からコミットした内容は存在しないことになってしまう)。
まったく調べずに嘘を書くのはどうかと
405:デフォルトの名無しさん
11/10/16 19:19:53.77
おまえみたいに調べて訂正してくれるやつがいるから
ある意味 問題ないな
406:デフォルトの名無しさん
11/10/16 19:24:16.94
俺の間違い push も訂正してほしい
407:デフォルトの名無しさん
11/10/16 20:36:16.79
うん？コミット時にはエラーでなくてあとで困るってこと？
それってまずくね
408:デフォルトの名無しさん
11/10/16 20:40:22.26
その前にオオカミの心配しろよ
409:デフォルトの名無しさん
11/10/17 09:12:15.64
SHA1ハッシュが衝突したとしてもオブジェクトの種類が違ったら
たぶんエラーになるから、さらに確率は下がるかな。
410:デフォルトの名無しさん
11/10/17 13:16:40.23
悪意を持って衝突させる奴が出たらそんなこと言ってられない
411:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/17 13:22:40.31
anonymousでpushできる世界の話？
413:デフォルトの名無しさん
11/10/17 13:30:07.71
2重管理で悶えてるじゃねーかｗ
414:デフォルトの名無しさん
11/10/17 18:39:45.51
>>322
415:デフォルトの名無しさん
11/10/17 22:43:50.41
二重管理ってgit-svnのことだったのかよｗ
416:デフォルトの名無しさん
11/10/17 22:46:10.96
>>413
無駄だ
417:デフォルトの名無しさん
11/10/17 23:54:08.81
>>410
意図的にSHA-１を衝突させるとか何者？
418:デフォルトの名無しさん
11/10/18 00:00:29.53
>>410
できないできない絶対できない
やれない気持ちの問題じゃない
419:デフォルトの名無しさん
11/10/18 00:02:40.58
できるできる絶対できる！
420:デフォルトの名無しさん
11/10/18 00:11:19.82
たとえ将来、自由にハッシュを衝突させることができるようになったとしても
既存のリポジトリの内容を破壊できるわけでもなんでもないその行為になんの意味があるの？
421:デフォルトの名無しさん
11/10/18 00:19:18.86
// コメントを外すと何故かコミットできない
422:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/18 06:14:39.87
>>411
俺はmerge時には--no-ffしてる。
424:デフォルトの名無しさん
11/10/18 08:05:41.70
411です。
ありがとうございました。
今日もういちど
しらべたりやってみたりしようと思います。
425:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/10/18 12:48:01.10
2重管理地獄の中で悶えて死ねｗ
427:デフォルトの名無しさん
11/10/18 13:09:33.26
>>322
428:デフォルトの名無しさん
11/10/18 13:15:06.14
>>425
addしていないファイルはどのブランチにも属さない
単に管理されていないから、どのブランチにいても「未管理ファイル」として表示される
それだけ
429:デフォルトの名無しさん
11/10/18 13:18:41.03
あー、なんとなくわかってきました。
testのほうでadd/commitするとtestが新しくなり、
masterに切り替えると古い版が維持されてました。
最初からやりなおしてまたtestで修正し、今度はmasterに切り替えてこっちで
add/commitすると、masterが新しくなり、testのほうが古いmasterの状態を
維持してました。
こういうものなんですね。co すると、そのブランチの
（こっちが期待している元の）状態に全部きれいに切り替えてくれるものと
思ってましたし、ブランチでの修正をmasterでcommitできるとか
考えてもみませんでした。
たぶん私は「ブランチ」の概念から理解しなおさないとダメですね。
430:デフォルトの名無しさん
11/10/18 19:23:36.94
ブランチというか、ステージングの概念じゃない？
ワークツリーの変更を退避したければ git stash でできるよ
でも、とりあえずコミットしておいてあとでコミットを編集・整理するのでも良いと思う
431:デフォルトの名無しさん
11/10/18 19:25:39.62
概念がどうとかいうほどのもんかね？
432:デフォルトの名無しさん
11/10/18 19:26:24.02
gitってうんこだな
433:デフォルトの名無しさん
11/10/18 19:32:13.07
>>431
いやだってbranchとは別物じゃない
434:デフォルトの名無しさん
11/10/18 19:58:28.05
gitはbranchとstashの2重管理のうんこ
435:デフォルトの名無しさん
11/10/18 22:49:25.35
あれからあらためてman読んだり自分で考えたりして、それなりにわかりました。
gitにはようするに「コミットオブジェクト」みたいなものしかないわけですよね。
タグはもちろんブランチも、ユーザのための記号みたいなもの。
だからブランチをつくったばかりなら、両ブランチは対等というかおんなじもので、
どちらが親とか、そういう意味もない。コミットした時点で初めて、
新たな「コミットオブジェクト」がつくられる。
あるコミットオブジェクトがどのオブジェクトから派生したか、といった情報は、
オブジェクトがつくられるときに記録される。
こう考えるとすごくわかりやすくなりましたし、シンプルでいいな、と思いました。
こんな感じに理解しましたが、だいたい合ってますでしょうか？
436:デフォルトの名無しさん
11/10/18 23:35:29.83
だいたい合ってる
しいていえばタグは特定のコミットをピンポイントで指すけど、ブランチはコミットの歴史（HEADの変遷）を指すってところかな
437:デフォルトの名無しさん
11/10/19 00:03:29.96
Git のタグは、軽量 (lightweight) 版と注釈付き (annotated) 版の2重管理のうんこ
438:デフォルトの名無しさん
11/10/19 00:30:05.82
バージョン管理システム界にカオスと混乱を招いたgitの罪は重い
439:デフォルトの名無しさん
11/10/19 00:45:54.69
>>436
ありがとうございます。
タグとブランチの違いについても考えてましたけど、おおむね間違ってなかったみたいです。
使いかたはまだまだ練習中ですが、いろいろわかってきたので面白いです。
440:デフォルトの名無しさん
11/10/19 08:05:53.27
gitを理解できない奴の頭の中がカオスになってるだけだろ。
自分の頭の悪さを罪だと思えｗ
441:デフォルトの名無しさん
11/10/19 08:30:20.91
構うなベアード
442:デフォルトの名無しさん
11/10/19 08:58:52.72
>>435
シンプルでいいよね。そこに気づけばもう迷うことはないよ。
必要に応じてコマンド覚えていけばいいだけ。おめでとう。