Git 2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/14(火) 21:38:18◆前スレ
git スレッド
http://hibari.2ch.net/test/read.cgi/linux/1197798039/
◆関連サイト
Git入門
http://www8.atwiki.jp/git_jp/
0083デフォルトの名無しさん
2010/09/28(火) 01:27:04返答ありがとうございます。
>>81
基本的に、各ユーザは自分の作りたいものに対するプログラムを書く予定です。
なので、本来は別々のリポジトリに分けた方がよいのかと思うのですが、
・ユーザが増えるたびにいちいちリポジトリを作るのが面倒
・利用者が自分でリポジトリ作るというのも避けたい（権限的な問題）
と考えてます。
なので、一つ全体的なリモートリポジトリを作っておき、その下にあるユーザ毎の
ディレクトリに対してローカルリポジトリをコミットできれば良いかと思いました。
そもそもめんどくさがるなという話なんですかね、これは。
>>82
Bazaarはディレクトリごとに管理してるんですね。
こっちならこのようにできそうな気が・・・。
少し調べてみます。
0084デフォルトの名無しさん
2010/09/28(火) 01:29:36日本人と言っても在米１５年以上の在米邦人だ。
現在はGoogle社員。
0085デフォルトの名無しさん
2010/09/28(火) 02:27:47Gitosisみたいなのでホスティングすればそういうのできるよ。
>>84
どっかのプロフィールではTwin Sun所属ってことになってたと思うんだけど、
ヘッドハントされたのかな。
0086デフォルトの名無しさん
2010/09/28(火) 04:50:46これはsvnのブランチがtrunk,tags,branchesを想定したものだと思います。
ところが、Subversionの自由にブランチをディレクトリに割り当てられるためか、
branches/hoge や branches/foobar のようなブラン構成ではなく、
branches/fuck/hoge や branches/fuck/foobar、branches/sine/piyo や branches/sine/piyopiyo
という2段構成のブランチになってしました。
これを --stdlayoutで引っ張ってくると、もってきたgitリポジトリの履歴がかなりメチャクチャになってしまうのですが、
上手く持ってくるような方法はないでしょうか？
0087デフォルトの名無しさん
2010/09/28(火) 04:55:24>>85 じゃないけど、github使う(privateや容量増は有料だけど)のもいいね
githubはユーザーごとに簡単にリモートリポジトリもてて
管理用のユーザーかリポジトリ作っておけば、そっちにも成果をマージできるでしょ
あとは、どこかのサーバーに中央リポジトリ用意して、
各個人ごとにリモートブランチきって突っ込むとかｗ
0088デフォルトの名無しさん
2010/09/29(水) 01:53:460089デフォルトの名無しさん
2010/09/29(水) 02:38:58git tag
0090デフォルトの名無しさん
2010/09/29(水) 12:16:25SSHの秘密鍵生成には確率的素数判定法を使っているはず:-)
0091デフォルトの名無しさん
2010/09/30(木) 13:27:410092デフォルトの名無しさん
2010/10/02(土) 18:29:39お互い徒歩通学で家まで１時間ぐらいかかるんだわ。
昨日からその子のことを下心でしか見てない自分が悲しい
0093デフォルトの名無しさん
2010/10/02(土) 18:30:38すいません
0094デフォルトの名無しさん
2010/10/02(土) 18:45:040095デフォルトの名無しさん
2010/10/02(土) 18:52:070096デフォルトの名無しさん
2010/10/02(土) 19:07:47絶対に許さない
0097デフォルトの名無しさん
2010/10/02(土) 20:14:110098デフォルトの名無しさん
2010/10/02(土) 21:16:070099デフォルトの名無しさん
2010/10/02(土) 22:06:470100デフォルトの名無しさん
2010/10/02(土) 22:13:070101デフォルトの名無しさん
2010/10/03(日) 13:49:290102デフォルトの名無しさん
2010/10/07(木) 14:21:35git 運用において、パッチはあくまでも機能単位であるべきなのだろうか?
たとえば "100ファイルに相互依存しない同様の変更を施したモノ"は
パッチ100本にすべきなのか、パッチ1本にすべきなのか迷う。
つかまとめあげたパッチを強制的にファイル単位にバラす方法知らん?
0103デフォルトの名無しさん
2010/10/07(木) 20:08:27同様の変更ってことはある単一の意図でやったことだろうから
100個に分割するんじゃなく1個にまとめるべきなんでは
0104デフォルトの名無しさん
2010/10/07(木) 21:46:08俺の場合、コミットログがバラバラになる場合はコミットはまとめないけど、
それでもまとめない場合はブランチ名つけておけばいいんちゃうのかな
0105デフォルトの名無しさん
2010/10/07(木) 21:58:37例えばそれが「インデントまとめて変更」とかだったら100ファイル一発でも
良いと思うが、100個のバグ修正だったら絶対に分けるべきだと思う。
俺の考えでは、誰かが分離したくなるかもしれない単位、で
世に出すのが良いのではないかと思う。
0106102
2010/10/08(金) 09:03:57100個のバグ修正ともいえるな。
0107デフォルトの名無しさん
2010/10/08(金) 11:54:56普通共通のファイルを一個作ってincludeなりなんなりするだろ
0108デフォルトの名無しさん
2010/10/08(金) 13:05:290109デフォルトの名無しさん
2010/10/08(金) 13:31:46スレ違い
0110デフォルトの名無しさん
2010/10/08(金) 14:01:22>>109
他人のテストスクリプトに対してそういうケチを付ける気にはならないな、自分は。
0111デフォルトの名無しさん
2010/10/08(金) 14:02:250112デフォルトの名無しさん
2010/10/10(日) 17:17:16どういう事なの・・・
0113デフォルトの名無しさん
2010/10/10(日) 17:22:580114デフォルトの名無しさん
2010/10/10(日) 17:44:510115デフォルトの名無しさん
2010/10/10(日) 18:57:14！！あった！！
ありがとう！
0116デフォルトの名無しさん
2010/10/10(日) 22:39:25ふつーは reflog でちまちま探すなんだけど、rebase する前にあらかじめ
git checkout -b b4rebase rebased みたいにくさびブランチを打っておくとよいぞ。
つか rebase がもっと柔軟にならんかね。って欲張りな悩みよね。
0117デフォルトの名無しさん
2010/10/10(日) 22:41:39master->foo-bar->baz->qux みたいなブランチを、一気に直線 rebase するような感じの。
0118デフォルトの名無しさん
2010/10/10(日) 22:50:43rebase -i はけっこう柔軟だと思う。
>>117
普通に git rebase master qux じゃダメなん？
0119デフォルトの名無しさん
2010/10/11(月) 12:15:53git checkout foo; git rebase master
git checkout bar; git rebase foo
git checkout baz; git rebase bar
git checkout qux; git rebase baz
と同じ結果にならないよね?
各ブランチがレビュー待ちのパッチを含んでいると想像してくれ。
0120デフォルトの名無しさん
2010/10/11(月) 16:12:030121デフォルトの名無しさん
2010/10/11(月) 16:32:54それをコマンド一発でやりたいってこと？
branch.name.mergeを元にして動くスクリプトを書いても良いと思うけど、
mergeと違って、元がrebaseしてる場合はコンフリクトする可能性大だから、
複数ブランチを一気にrebaseかけるのは怖いな。
手動でやったほうが良いんじゃないかね。
foo、bar、baz、quxはそれぞれテスト等も済んでるだろうから、
無理にrebaseするよりも、masterからfooにmergeしたほうが良いと思うな。
各ブランチがmasterの新機能を前提として必要になったのなら仕方がないけども。
濱野さんの入門Gitには、そのように書いてあった。
なかなか上流に取り込んでもらえないと、rebaseでキレイに並べて
おきたい気持ちは分かるんだけど…
0122デフォルトの名無しさん
2010/10/12(火) 19:48:420123デフォルトの名無しさん
2010/10/12(火) 19:56:42git pullなら省略できる（適切に設定されてれば）
0124デフォルトの名無しさん
2010/10/12(火) 20:46:28git push するたびに master について叱られるのだ。
master じゃほとんど作業しないし。
すまんこ
0125デフォルトの名無しさん
2010/10/12(火) 23:54:220126デフォルトの名無しさん
2010/10/15(金) 10:32:34試しにSettingsでプロキシを有効にするよう設定してみましたが無理でした
Putty Fatal Error
Network error: Connection timed out
0127デフォルトの名無しさん
2010/10/15(金) 16:18:440128デフォルトの名無しさん
2010/10/16(土) 01:11:54外してるかも
0129デフォルトの名無しさん
2010/10/20(水) 09:00:470130デフォルトの名無しさん
2010/10/23(土) 13:47:490131デフォルトの名無しさん
2010/10/23(土) 13:49:33します＞＜
0132デフォルトの名無しさん
2010/10/23(土) 13:54:480133デフォルトの名無しさん
2010/10/25(月) 14:27:04TortoiseGit1.5.8.0とGit1.7.3.1で使っているけど、ときどき失敗する。
しかもGit Command Progressのダイアログでは、ログメッセージに日本語が入っていると文字化けして表示される。
0134デフォルトの名無しさん
2010/10/25(月) 14:32:37svn側でしか変更してないはずなのにコンフリクトするんだけど、
もしかしてリモートブランチはマージ履歴持ってなかったりする？
git svn fetch #リモートブランチを更新
git merge --squash --no-commit git-svn #リモートの更新をmasterにマージ
# ここでコンフリクト
0135デフォルトの名無しさん
2010/10/25(月) 15:21:51今のところSVNでgitのマージコミットを表現することはできないから、
dcommitする予定のブランチではmergeしちゃダメだよ。
まず今のブランチをgit svn rebaseでSVNに追随させないといけない、んだけど
うまくrebaseできなそう。。。
git checkout -b mergetest git-svn してcherry-pickで整形し直したほうが
良いかもしれない。
0136デフォルトの名無しさん
2010/10/25(月) 23:53:01いや、svn側の変更をgitで追いかけているだけなんで、dcommitする予定はないんだ。
手元にはsvn fetchしているだけのリモートブランチ(デフォルト名のままgit-svn)と、
ローカルの変更込みのmasterがあるだけ。
cherry-pickしたほうがいいのかなあ。ありがとう。
0137デフォルトの名無しさん
2010/10/26(火) 03:20:570138デフォルトの名無しさん
2010/10/26(火) 04:48:400139デフォルトの名無しさん
2010/10/26(火) 07:04:26>>134をよく見たら --squash してるけど、前回もそうしてた？
それならコンフリクトするのも分かるよ。
squashで別のコミットとして作り直してるから、次にマージする時には
また同じコミットが対象になってしまう。コンテンツの内容が近いなら
うまい具合にマージ出来るかもしれないが、失敗する可能性も高い。
これはgit-svnに限らないgitの話。
git log master..git-svn で見ると既にマージ済みのが出てくるんじゃないかな。
0140デフォルトの名無しさん
2010/10/26(火) 07:38:43確かにgit log master..git-svnしたらsvn側の履歴が全部出てきた……。
svn側の複数の変更を、masterではひとつにまとめたかったんだけどなあ。
やってることはリモートブランチがsvnなだけでhttp://progit.org/book/ja/ch6-7.htmlと変わらないと思ってたんだけどなあ。
0141デフォルトの名無しさん
2010/10/26(火) 08:02:41そもそもgitで三点マージを行うのがrebaseか……。
どうせsvn側でしか変更はないんだから-Xtheirsでも付けるかな……。
0142デフォルトの名無しさん
2010/10/26(火) 20:44:21＞やってることはリモートブランチがsvnなだけでhttp://progit.org/book/ja/ch6-7.htmlと変わらないと思ってたんだけどなあ。
その例はsubtreeマージで１方向なので、2ツリーマージでもうまくいくんだと思う。
>>141
＞どうせsvn側でしか変更はないんだから-Xtheirsでも付けるかな……。
一方的なコピーでいいのかな。それなら merge -s subtree でもいけそう。
＞そもそもgitで三点マージを行うのがrebaseか……。
rebaseも普通のmergeも、共通の祖先が見つからない(2ツリーマージ)場合は
ファイル単位でぶつかると手動マージになる可能性が高いね。
＞前回merge --squashしたところからの三点マージができればいいんだけど、
無理矢理やるとしたら…
git read-tree -u -m 前回squashしたコミット HEAD git-svn
とかで3wayいけるけど、ファイル同士がぶつかるとunmergedになってしまうので
自分でどうにかするとか、git merge-index他の配管コマンドでどうにかしたりする必要あり。
0143デフォルトの名無しさん
2010/10/27(水) 02:47:530144デフォルトの名無しさん
2010/11/02(火) 15:12:03git svn rebase
git checkout master
git merge --no-ff a
git svn dcommit
したら「Merge branch 'a'」というたった1つのコミットになっていた件。
なんなんだこれは…
0145デフォルトの名無しさん
2010/11/02(火) 17:36:48>>135
0146デフォルトの名無しさん
2010/11/04(木) 05:36:07手元には元のソースは残っていません
復旧は不可能ですか？
0147デフォルトの名無しさん
2010/11/04(木) 06:20:02まず手元のリポジトリで git reflog してみる。それで見つかるかも知れない。
手元に無くても、分散してるどこかにあるかも知れない。
最悪のケースとして、pushした先のリポジトリにしか無かったという場合、
まずその.git（bareリポジトリならそのディレクトリそのもの）をバックアップ。
git fsck --lost-found を実行すると .git/lost-found/commit が出来るので、
そこから探す。
あまりあり得ないと思うけど、空pushした後に git gc が実行されていると
ポインタだけじゃなくてオブジェクトも消えているので、もうダメぽ。
0148デフォルトの名無しさん
2010/11/06(土) 01:24:46あれ、いつの間にか日本語対応しました？
0149デフォルトの名無しさん
2010/11/06(土) 13:56:340150デフォルトの名無しさん
2010/11/06(土) 23:49:36現在のHEADを１番目のコミットにしてしまいたいのです。
単純に.gitディレクトリを削除してinitし直せばいいのかな？
0151デフォルトの名無しさん
2010/11/07(日) 00:36:17ほんとに綺麗さっぱりなら.gitを消してinitしなおすのが簡単だね。
微妙に残すのなら、git checkout --orphanというのがあるので
これを利用すればrootコミットから作れる。
0152デフォルトの名無しさん
2010/11/07(日) 03:02:04gitの思想によるものなのか、それとも単に分散バージョン管理に慣れていないからなのか、たまに分からなくなる。
特に、分散なんだからそれぐらいできてもよさそうじゃん、ってのができないとき…。
0153デフォルトの名無しさん
2010/11/07(日) 03:31:14逆引き的なドキュメントが少ないという話であれば
ProGit一通りよむとかなり解決するが
http://progit.org/book/ja/
0154デフォルトの名無しさん
2010/11/07(日) 03:38:18Subversion使っていてこういう機能欲しかったんだ、というのがあったり
TortoiseSVNからコマンドラインに移行したのも理由だと思うが
ただ、>>152がいうのもわからなくはなくて、〇〇はrebaseでできる、といった場合に、
何故○○というコマンドじゃないのか？と思ったり、
もちろん基本的なコマンドは用意しとくから、各個人勝手にaliasしろや、
という一貫したなげやり感もUNIX的にはわからんでもないし、
出来る事多いからコマンドかなり増えるだろうし。
Bazaarは確か標準のaliasもあるしかなりコマンドあったはず。
どっちがいいかという話だな。GUIがメインならコマンド多くても気にならないんだけどね。
0155デフォルトの名無しさん
2010/11/07(日) 03:59:41何もできなかっただろう、という気はする
0156デフォルトの名無しさん
2010/11/07(日) 04:25:12それはわかってるんだけど、
どうも Mercurial から移行できない。
0157デフォルトの名無しさん
2010/11/07(日) 04:25:500158デフォルトの名無しさん
2010/11/07(日) 05:02:34git は便利な分だけ覚えなきゃなんないことがある。ちょっと感じが違うよね。
# Bazaar は Mercurial に近い上ロケールとかしっかり作ってあるけど遅そう。
Mercurial でいいや。とか思ってたんだけど、このスレ見てると、やっぱ git が気になってw
0159デフォルトの名無しさん
2010/11/07(日) 05:08:520160デフォルトの名無しさん
2010/11/07(日) 08:42:55hgとgitは概念的にはかなり似ているけど、決定的に違うのがブランチの考え方。
hgの名前付きブランチがgitに無い。
0161デフォルトの名無しさん
2010/11/07(日) 11:59:47名前付きブランチってどういう感じのもの？
0162デフォルトの名無しさん
2010/11/07(日) 12:30:21> 名前付きブランチってどういう感じのもの？
１つ１つのブランチにリビジョンの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0163デフォルトの名無しさん
2010/11/07(日) 12:35:01誤）
１つ１つのブランチにリビジョンの名前が埋め込まれている。
正）
１つ１つのリビジョンにブランチの名前が埋め込まれている。
> >>160
> 名前付きブランチってどういう感じのもの？
１つ１つのリビジョンにブランチの名前が埋め込まれている。
だから、マージしても元のブランチが分かる。
gitのブランチは特定のリビジョンに対するポインタだから、マージしてブランチを消すと
どっちのブランチなのか分からなくなる。
0164デフォルトの名無しさん
2010/11/07(日) 12:51:30なるほど、なんか分かった。確かにGitはブランチの名前自体には意味を持たないので、
最初使い始めの頃はそこに戸惑った気がする。この変更ってどこから（どのブランチから）
来たんだろ？って思った時によく分からないんだよね。
マージコミットのログメッセージにブランチ名が書かれるから、gitkとかで視覚的に見れば
なんとなく分かるけど、それでもFast-forwardだったりすると完全に統合されちゃうから、
masterでやった作業なんだかtopicでやった作業なんだか、一見分からない。
0165デフォルトの名無しさん
2010/11/07(日) 12:55:13慣れてるからってのもあるが開発に全く無駄が入らない。
コミットを綺麗に整形したい時はgitを使う。
0166デフォルトの名無しさん
2010/11/07(日) 17:25:470167デフォルトの名無しさん
2010/11/08(月) 03:02:41gitだと下手に直せるからつい気になるわ
>>164
履歴をフラットにしたくて気軽にrebaseすると、rebase前のブランチなくなって焦るわｗ
仕様上、当たり前なんだが
cherry-pickするか別のブランチ名つけろ、というのはそうなんだけど
0168デフォルトの名無しさん
2010/11/08(月) 09:46:43そこで git merge --no-ff
0169デフォルトの名無しさん
2010/11/08(月) 10:46:330170デフォルトの名無しさん
2010/11/08(月) 17:11:03>$ git merge hotfix
>Updating f42c576..3a0874c
>Fast forward
>README | 1 -
>1 files changed, 0 insertions(+), 1 deletions(-)
>このマージ処理で 『Fast forward』 というフレーズが登場したのにお気づきでしょうか。マージ
>先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に
>進めたのです。言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットを
>マージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。マージ対象が分岐し
>ているわけではないからです。この処理のことを 『fast forward』 と言います。
0171デフォルトの名無しさん
2010/11/09(火) 00:15:29fast forward＝ブランチのポインタをずらすだけ
分岐してなければ、これでいけることが多い
分岐しててfast forwardしたければ、rebaseしてコミットを直線にして分岐なくせばfast forwardできるが、
以前のブランチなくなるから注意。
これ防ぐには別のブランチ名つけておけばよかったはず。
そういえばpush(git svn dcommit)したあとに間違えてgit commit --amendしてしまっていて、
fast forwardなmergeができずあとから気づいてあせったことある。
rebaseだと駄目で、cherry-pickでamendした分を飛ばして解決したが他にいい方法合ったのか
0172デフォルトの名無しさん
2010/11/09(火) 02:47:58ブランチの方に進んだだけの状態と、
ブランチの方に進んで一方masterの方も進んでいる状態の
2パターンでmasterにマージしてみたら前者だけがfast-forwardって出たわ。
前者は別にマージする必要というか絶対コンフリクトしないから
ただポインタをブランチの先頭だったところにずらしました、ってことだな
0173デフォルトの名無しさん
2010/11/10(水) 17:09:04git checkout dir/ とやってみたらディレクトリに反応して俺すげー
とおもってマニュアル見たら git checkout -- dir とすりゃよかったのな
0174デフォルトの名無しさん
2010/11/11(木) 09:40:29fast-forward mergeとそうでないmergeは、gitk --allでマージ前とマージ後を見ながら視覚的に確認するとわかりやすいよ
0175デフォルトの名無しさん
2010/11/11(木) 10:28:02枝がはちゃめちゃに混線しててワロタ
0176デフォルトの名無しさん
2010/11/12(金) 11:44:13githubで公開されてるライブラリがあるのです
で、そのライブラリのバグを直そうと思いました
でも、バグ近辺関連のテストが全然ない上に、この訂正の適用前後で微妙に動作が変わります
・訂正前のメソッド動作はこういう単体テストを満たすものでした（を自作で追加する）
・訂正前と訂正後でこのように動作が変わりますつまりこの訂正コードは正当です
・訂正後のメソッド全体の単体テストです
の3種類のテストが、少なくともpullリクエストでの説得に必要な気がするのです
うまいまとめ方ないでしょうか
訂正後のメソッドについてのテストだけだと、
「この動作は以前のコードではどうだったの？」という情報がなくて困りそうで
0177デフォルトの名無しさん
2010/11/12(金) 11:58:45ブランチに対してリクエストを出して、その後、そのブランチにコミットを追加すると、pullリクエストも伸びていく。
だから、pullリクエストはブランチ単位で分けた方が良いのでは？
マージするかどうかは、そのリクエスト先が判断すれば良い気がする。
0178デフォルトの名無しさん
2010/11/12(金) 12:07:11だから普通に「○○を改善するブランチ」を作って、
訂正前コードに対するテストをコミットして(a)、
比較対照テストをコミットして(b)、
比較対照テストの部分を極力編集しないように訂正後のコードに対するテストをコミット(c)すればいいのでは
まぁすたぁはおそらく
「コミットすべてを見て納得して、(a)と(c)だけ受け入れ、適当にCHANGELOGを書く」
ということをするはず
…慣れてればな
…慣れてればね
慣れてないと「こんな大きいの無理です入りませんいやっやめてっ」とか返事が返ってくる
0179デフォルトの名無しさん
2010/11/12(金) 20:18:51他者と関わりあっていかなければならないソフトウェアなのにさ
0180デフォルトの名無しさん
2010/11/14(日) 09:59:04いろいろなソフトをひとまとめにできるルールなんて作れない
0181デフォルトの名無しさん
2010/11/15(月) 10:33:41"New Gist"でPublic Gistを作ると
無関係のランダムな既存のgistからforkしたみたいになる
Privateだと起こらなかった。昨日から使い始めたんだか元々こうなの？
0182デフォルトの名無しさん
2010/11/15(月) 10:52:46■ このスレッドは過去ログ倉庫に格納されています