Git 15©2ch.net

2017/02/05(日) 05:22:15.65

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 13
http://echo.2ch.net/test/read.cgi/tech/1439563364/
Git 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/

VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured

2017/02/24(金) 15:11:29.62

想定はしてないでしょ、無理矢理衝突させたらリポジトリ壊れたって書いてるし
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 16:02:16.98

>>43
5桁でちぎって管理ってなんのこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 10:54:33.01

v2.12.0

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 11:32:01.15

>>46
何か面白い機能追加された？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 04:28:34.00

Linusの公式コメント
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 13:29:26.47

SHA1衝突なんか怖かねーぜバーカ！
ってこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 00:08:39.88

ファイル数が20万～30万個あるプロジェクトをgitで管理できる？
git statusすると20万～30万の全部のファイルの更新日チェックするの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 01:39:05.95

gitで管理できなかったら、他の何を使っても出来ないと思うｗ
管理せずにファイル置いとくだけならできるだろうけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 05:02:00.38

>>51
きも

**デフォルトの名無しさん** (ｵｯﾍﾟｹ) · 2017/03/01(水) 12:18:24.07

俺も思った

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/03/01(水) 12:52:10.72

>>50
それくらいなら全然大丈夫だよー

**デフォルトの名無しさん** (JP) · 2017/03/02(木) 19:24:50.56

>>50
人間よりは速い

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/02(木) 23:03:10.15

gitを使うのが目的になってる奴がいるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:06:07.56

gitを使うのが目的じゃないけど結果的にgitを使ってるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:30:35.54

gitを使ってるカッコいい俺

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:31:43.91

普通じゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:36:40.95

gitの使い方を覚えられないおっさんも世の中には居るんだ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:42:40.19

使える人が使わないなら、それはいいんだよ。

能力不足で使えない（＝無能すぎる）
会社のしがらみで使えない（＝かわいそう）

あと使って見てないやつもダメだな

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/03(金) 11:58:15.68

Gitが使えない外注イラネ

**デフォルトの名無しさん** (JP) · 2017/03/03(金) 12:30:04.87

篩に使うのはありか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/03(金) 21:00:59.00

なんでもいいから自分のソースくらい自分でコミットしろ。

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/03(金) 21:35:27.51

本当になんでもいいの？

2017/03/03(金) 23:39:23.71

masterにコミットしていいの？

2017/03/04(土) 00:19:50.00

結果にコミットしていいの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 00:59:09.29

面倒臭いのでだいたい
git add .
git commit --amend -m "hoge"

で済ましてる
一通り終わったらgit commit --amendでコミットメッセージちゃんと書く
squashしなくてよい方法だよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 03:38:59.15

Git - 高度なマージ手法
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%9E%E3%83%BC%E3%82%B8%E6%89%8B%E6%B3%95

これいいね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 11:03:44.63

git merge --abort
git rebase --abort

これいいよな。

svnとかだとやらかしてしまって中途半端な状態になって
これどうすりゃいいんだよってなってしまうけど、
gitだとたいてい--abortすればリセットできる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 14:23:44.15

AにコミットしてA'
A'にコミットしてA''
になってるとき
A'をBに名前変えて
A->A''と
A->Bに分けることはできますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 15:02:21.59

git checkout 好きなコミットID

ブランチ名なんて最新のコミットに名前つけてるだけであって
コミットIDで全て参照できる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:15:35.10

A->A''の方にはB(A')が無かったことにしたいのですが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:34:49.80

説明がわかりにくすぎだろw
pushしてればrevertで
してなければrebase -iで

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 21:55:14.48

cherrypickでA''からAにパッチ当てりゃいいだけじゃね？

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/04(土) 22:05:36.70

>>71
git branch B A'
をする
git rebase A -i
でA'の行を消す

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:20:15.96

ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み

こう言う場合って作業完了してからまとめてコミットすべき？
それともキリのいいところでコミットすべき？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:34:33.58

適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 15:02:30.70

rebaseは甘え。使ってはいけない。

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/07(火) 18:29:12.37

せっかくローカルにあるんだし、どんどんコミットしたら？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 19:25:45.74

rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:49:12.26

rerebaseだと!?

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:55:44.46

rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
rebaseしたってコミットそのものが世界からすぐに消えるわけじゃないんだし

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/07(火) 22:48:44.65

git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 00:28:53.24

> rebase怖いならブランチ切るなりタグつけるなりして

そのブランチやタグを作るのが面倒なバージョン管理ツールがありまして、
そのせいでブランチやタグを切るのが嫌なんですよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 01:12:08.47

知らんがな

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/08(水) 08:51:03.76

ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/08(水) 18:56:28.23

(1)git checkout -b hoge コミットID1 でhogeブランチを作る
(2)masterブランチに戻る
(3)git branch -D hoge でhogeブランチを削除する
(4)git checkout -b hoge コミットID2 で異なるコミットのhogeブランチを作る

hogeブランチでは何かを編集したりするわけではないので
hogeブランチにいたまま別のコミットIDでhogeブランチを上書き？する方法ありませんか？
masterブランチに戻ってからhogeブランチを作りなおして新たに作るのが面倒くさいので

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 19:57:59.67

git reset --hard コミットID2

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 06:48:45.74

>>88
コミットIDでcheckoutすりゃいいだけじゃね

(1)git checkout コミットID1
(2)git checkout コミットID2

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 08:26:50.81

>>88
git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/09(木) 08:37:37.52

>>82
リ・リ・リベース
アホデミー賞を総なめ

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/09(木) 10:28:24.13

resetは困ります。。。。
checkoutでどうにかやる方法はないということでしょうか？

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 10:29:17.80

ブランチは１個しか作りたくないんです

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 12:31:57.97

>>93
じゃあ>>90で良いんじゃないの？
コミットは出来ないけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:13:36.94

>>88
git checkout hoge
git merge <commit>

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:42:24.50

>>93
なんでreset困るの？ブランチ消してる時点で同じことだと思うけど
resetしたってコミットが消えるわけじゃないよ

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 22:57:50.27

git checkout -b hoge
git reset --hard コミットid1
git reset --hard HEAD@{1}
masterブランチには何の影響もないですね
最新のコミットに戻るときにreflogで位置を確認するのが面倒くさそうです
これも覚えておきます

>>96
mergeだと古いコミットに戻ろうとした時にAlready up-to-date.って表示されてしまいました

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 23:15:12.39

hogeにはすでにコミット1やコミット2が含まれてる場合もあって
その場合はそれ以降のコミットを捨てた状態にしたいってことなの！？
用途が謎

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 03:45:25.28

>>98
ブランチは1個しか作りたくない理由がわからないから、それだったらID1とID2に別のブランチを付けたら良いんじゃない？って思っちゃうんだけど
何で作りたくないんですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 04:41:26.50

>>90のやり方がスルーされるからやりたいことと違うんだろうなあ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 14:48:19.74

タグの代わりなんじゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:15:08.71

みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
する機能使ってる？

俺はファイル単位でしかコミットとかしないんだけどさ、そもそもステージング
してるところから行単位でまた編集するようなもんだから、テスト通るかわからなく
なるわけだし、あんまり積極的に使うもんじゃないよね。

あとdiffの結果画面の見方が今ひとつ苦手w

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:48:11.92

>>103
使わんなー

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:51:35.65

>>103
細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:13:50.48

git add -p のこと？
ならすげー使うけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:28:17.98

git add -pの存在がsvnからの移行を決定づけた

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:51:42.82

俺もよく使うな。

gitの便利さっていうのは現実的な問題を解決してることにあると思っていて、
理想は最初に計画を立てて間違えることなく作業をすることだけど
現実にはいろんな細かい修正を忘れたり分けるべき修正を一緒にやってしまったりするでしょ？

そういう時に俺は、いま修正している中で、特定の部分だけgit add -pつかって
一つのコミットにして、あとの分は別コミットにして、
テストは後から書いてrebaseしてまとめるとかやるよ。

他の人が理解・レビューしやすい並びのコミットと、
実際の開発順っていうのは必ずしも一致しないからさ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 23:30:38.30

git add -pなら使う。行単位でステージングする機能、だよね？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 06:24:50.89

>>108
SVN 使いだけどこの機能とローカルコミットはマジで欲しい

**デフォルトの名無しさん** (JP) · 2017/03/11(土) 10:36:14.71

>>110
gitに乗り換えても良いんですよ？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/11(土) 11:07:52.10

行単位使ってる人多いんだな
完全ファイル単位だわ
考え方古いのか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 12:21:39.87

>>111
何となくだけど git は性に合わない

**デフォルトの名無しさん** (ｽｯﾌﾟ) · 2017/03/11(土) 12:39:37.19

>>113
おじいちゃんこんにちは

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 13:07:42.60

stash, cherry-pick, rebaseのないコーディングなんてもう考えられない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 14:17:42.96

試行錯誤のあととかノイズでしかないからな。
そんなものを大事に抱えていても、コードリーディングの
じゃまになるだけで意味が全くない。
快適な開発をするときに役立つコマンドがgitには多く搭載されている

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 16:27:54.83

行単位とかやりすぎだろ。。
それなら作業者を統一するなり、ファイル分割するなりした方がいいんじゃねーの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 17:15:54.01

作業者が独りだから、同じファイルを複数行編集するんだろｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 18:39:00.61

まとめてコミットするつもりで編集中だったワークツリーから
部分的に何行かコミットしてpushする必要ができたとか
けっこうある

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 16:00:30.11

ファイルのタイムスタンプまで元に戻せるバージョン管理ツールってないの？

**デフォルトの名無しさん** (JP) · 2017/03/14(火) 16:01:15.03

>>120
git

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 16:49:48.82

ワロタ

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 19:54:39.02

はぁ？ｇｉｔじゃタイムスタンプは戻らんから質問してんのにバカなの？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/14(火) 20:00:39.69

もしそんなVCSがあるならmakeとかまともに動かなくて限られた用途にしか使い物にならんだろうなぁ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 21:49:01.07

>>120
svn+TortoiseSVN でコミット日時に戻せるので我慢するか作り込みするしかなさそう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 21:57:48.94

gitはOSSなんだからHACKするなり自分で手を加えればいいのでは？

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/14(火) 22:06:05.44

>>123
コミットフックで全ファイルのタイムスタンプを記録しておけば戻せるよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/14(火) 22:42:41.89

適当なツール使えばいいじゃん

https://github.com/search?q=timestamp+git

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 01:16:30.21

タイムスタンプは変えないでオリジナルのまま元に戻せるような機能は需要ありそうなのになんで最初から実装されてないの？
タイムスタンプはOSごとのローカルな仕様っぽいのでGit本体には入れなくないってこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 01:23:09.75

全く欲しいと思ったことが無いけど何に使うの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 02:50:18.09

>>130
あり得るとしたら、たぶんタイムスタンプで更新有無を判断する現場なんじゃないか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 04:09:45.52

そんな馬鹿げたことから解放されるための構成管理ツールだと思うのだけど、世の中の闇は深いな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 07:04:46.81

Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 07:44:08.96

>>131
今時そんな事してる現場なんてあるわけないじゃん？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 08:18:02.75

>>129
記録したいのはファイルがいつ修正されたかではなくて
ファイルの行がいつ修正されたかだから。

ファイルの日付どころか行単位で
修正日時が記録されているので必要ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 08:32:23.84

>>133
> Gitにない機能は闇呼ばわりのGit真理教の方ですねわかります

Aというブランチでファイルを追加します。
Aブランチから派生したBというブランチでそのファイルを修正します。
Bというブランチでコンパイルしてオブジェクトファイルを作ります。
Aというブランチに戻ります。

Bというブランチでコンパイルしたオブジェクトファイルが残っています。
ファイルの日付はリポジトリに入れないのでAの方が更新日付が新しくなります
そのためコンパイルするとBのオブジェクトファイルは使用されません。
という素晴らしい仕組みはgitだけの特典だとでも？

あんたはどうしてもほしいの？

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/15(水) 10:18:23.23

結論:Gitは素晴らしい仕組

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2017/03/15(水) 10:22:20.47

流れ見てるとGitはコミット時の日時にファイルのタイムスタンプが変えられることすら知らないで偉そうに答えている奴いるなw
所詮は℃素人の烏合の衆かw

**デフォルトの名無しさん** (ｽﾌｯ) · 2017/03/15(水) 10:35:49.13

gitを使うことが目的になってるからな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 12:42:56.93

>>135
ごもっとも
だけどFAQでこの文章みた記憶がない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 12:45:29.83

>>138
commit時の日時だっけ？
checkout時の日時だと思ってた

2017/03/15(水) 12:52:42.68

チェックアウトの度にタイムスタンプが書き換わっていたらさらに大混乱のような

手元にないから誰か試して

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/15(水) 13:05:12.43

>チェックアウトの度にタイムスタンプが書き換わっていたら

その時点で存在しないファイルとかチェックアウトの結果変更されるファイルのタイムスタンプの話なんですが