Git 15©2ch.net YouTube動画>8本 ->画像>1枚

ソースコード管理を行う分散型バージョン管理システム、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

<　｀∀´>ﾆﾀﾞｰ

Git v2.12.0-rc0
https://github.com/git/git/blob/master/Documentation/RelNotes/2.12.0.txt

rebaseを使いこなして初めて
gitを使えるようになったと言える

>1 乙py

gitlab復旧作業8時間実況すげ

rebaseの使い途がそんなにないんじゃね
コミットが何百もあったときにrebaseで綺麗にできると思えん
squashはresetでできる
使えるのは過去のコメントを編集するときくらいか

>>7
コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね？

そのどでかいブランチから、小さく機能を抜き取って
小さなブランチにしてマージするべきだよ。

そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う

エスパーすると
>>7は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね

何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか？

いつもいろんなgit操作を試行錯誤してしまって、本題がコミットすることからブランチ整理することにずれていってしまうので。

>>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている

>>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ

>>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの

>>11
> cherry-pickは操作後の動作が保証できない

何を言ってるんだ？
cherry-pickはあるコミットを持ってくるというだけの機能で
cherry-pickしたあとの動作なんて最初から何も保証してないんだが

保証できないんじゃなくて、保証してない
だからrebaseして、そのcherry-pickしたコミットが正しく動くようにするんだよ

ちなみに、そもそもなんでcherry-pickして動かなくなるのかといえば
こまめなrebaseをしてないから。例えばコミットに対する修正を別コミットに
していたりするとそうなる。こまめにrebaseして意味のある単位にコミットを
修正していれば他人が読んだときのレビューも楽になるし、再利用もしやすくなる


> mergeなら操作後の動作が保証できる

mergeはブランチ全てをマージするものであってそもそも使うべきところが違う。
ブランチの中の1コミットだけを抜き取りたいときにmergeではできない
（できないからmergeの方が劣ってるとでも？ｗ）

使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない

>>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

簡単に言えば、こまめなコミット、こまめなrebaseだよ
有名なオープンソースソフト（例git）のコミットログを眺めてみればいい
あれが目標とすべきコミット

眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。
後から読むこともあるしレビューのときに読むこともある。だから可読性が必要

じゃあコミットの可読性はどうやればあげられるかというと
意味がある単位で小さくまとまめること

例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって
ここバグってる？すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ
かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる

では意味がある単位で小さくまとめる（＝ワークフロー）にはどうするかとうと
まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。
そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。
プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。

rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない

最初から意味がある単位で小さくまとめるのが理想だけど、
後からブランチの履歴を整理する手段も色々ある。

gitでアレを元に戻す108の方法
http://labs.timedia.co.jp/2011/08/git-undo-999.html
Gitでやらかした時に使える19個の奥義
http://qiita.com/muran001/items/dea2bbbaea1260098051

git(hub)-flow

git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか？

>>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ

改行コード変わるだけで別ファイルになるけどな

毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。

コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな

>>22
プッシュじゃなくて？

>>24
ごめん、プッシュね。

マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。

細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか

>>26
突っ走った後にgit add -p 使って複数のコミットを作る

>>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う

>>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ

cron 書けとしか言いようがない。

エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ

>>31
数分おきにエディタに :wq! を送るスクリプトを作ろう

意味のある区切りじゃない自動保存などゴミ

そもそもコミットは成果毎に行うのであって細かくすればいいというものではない

プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？

コミットと保存の話が混ざって混沌としてきてる

個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね

ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばＯＫ
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおｋ

>>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね

>>39
ない

svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある

チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか

SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/

それに対するLinusの見解
http://marc.info/?l=git&;m=148787047422954

hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし

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

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

v2.12.0

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

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

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

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

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

>>51
きも

俺も思った

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

>>50
人間よりは速い

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

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

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

普通じゃ？

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

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

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

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

Gitが使えない外注イラネ

篩に使うのはありか

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

本当になんでもいいの？

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

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

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

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

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


これいいね

git merge --abort
git rebase --abort

これいいよな。

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

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

git checkout 好きなコミットID

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

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

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

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

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

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

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

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

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

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

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

rerebaseだと!?

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

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

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

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

知らんがな

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

(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ブランチを作りなおして新たに作るのが面倒くさいので

git reset --hard コミットID2

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

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

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

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

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

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

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

>>88
git checkout hoge
git merge <commit>

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

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

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

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

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

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

タグの代わりなんじゃ？

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

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

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

>>103
使わんなー

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

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

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

俺もよく使うな。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>120
git

ワロタ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>138
馬鹿がばれるからやめとけ

>>133
で、何に使うの？

チェックアウトっていうのは手元のファイルを書き換えているわけで
ファイルの更新日付は変わるほうが動作として正しいんですよね

ユーザー視点からはタイムスタンプごと戻るほうが正しいだろ。

システムの都合を言われても知らんわ。

ユーザー視点ってなんだ？
バージョン管理ツールは開発者視点のものなんだが。

バージョン管理ツールができる以前から
makeはタイムスタンプを参照して更新されたものだけを
ビルド、リンクする。

checkoutしてブランチを切り替えてファイルが変わったら
当然ビルド、リンクしなきゃならないんだから、タイムスタンプは
新しくなくちゃいけないだろ。

バージョン管理ツールはバックアップツールじゃないんだぞ
開発者じゃないやつが使うものじゃない

>>147
システムの都合じゃなくて、ユーザー（開発者）視点から
ビルドしやすいようにあえて日付を更新してる

それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含めそっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

上の流れを要約するとそういうこと

>>150
誰も何に使うか挙げれてないのに？

gitの操作によって更新されたファイルのタイムスタンプをユーザが参照出来ないとか、ユーザーにとって拷問じゃね？

タイムスタンプの参照方法も知らんのか

大体お前ら殆どペチパーだろｗ
そもそもビルドプロセスなんかねえじゃんｗ

ペチパーてなに？

プロパーのことかな

https://www.indeed.com/jobtrends/Java,JavaScript,Perl,PHP,Python,Ruby,Scala.html
ペチパー=PHPerだけど、PerlとPHPの仕事は減る一方で３年以内にScalaに追い越される。
JavaとScalaはコンパイルのために、JavaScriptはトランスパイルのためにビルドが必要だ。

でも、githubなんかのリポジトリブラウザでlast commitが一覧できるのは便利。
ファイルの更新具合が一目瞭然。
git cloneのデフォルト動作がlast commitを復元するのでいいとさえ思う。

タイムスタンプ頼りのビルドツールも、なんか進化してくれないかと思うね。
ビルドしたときのハッシュを保存しておいて、違ってたらビルド（コンパイル）対象にするとか。

>>159
遅くなるだろ。何のためにタイムスタンプ単純比較してると思ってるんだ。

>>160
> 遅くなるだろ
そうでもない。

243ファイル10万行のハッシュ値計算：
$ ls *.[ch] | wc -l
243

$ wc -l *.[ch]
102429 合計

$ time md5sum *.[ch] > /dev/null
real 0m0.014s
user 0m0.008s
sys 0m0.006s

Git真理教信者はGitはとにかく正しいのだという盲信から発言するから、自分とは違ったニーズを持つ他者がいるという想像もできないし、そもそもエビデンスを出しての議論ができないんだよなあ
口汚く罵るだけで

>>150
初心者はとまどうのかもしれないが
慣れたら問題ないことに気付く

どうせ秀丸でも使ってるんだろ

hookで実現する方法はあるし、必要ならそれを使えばいいだけだと思うんだがどうしてその機能がデフォルトで用意されてないだけでそこまで喚くのかわからない

>>164
わからなければ参加しなくてもいいんですよw

公式のgit guiもネイティブのwindowsソフトのくせに日本語含んだディレクトリ名とか未だにダメダメだな
この時代に他言語対応がここまでダメなメジャーなソフトも珍しいんじゃね？

git for windows ならいける

>>166
まったく珍しくないけど。
ユーザー名に日本語含めないようにするというバッドノウハウが広まってるのがいい証拠

あれがだめだ
これもだめだ
文句ばっかり一人前

>>169
少しは文句ばっかり言われる自分を省みてみたらw

>>167
サンクス
そうなんだ。試してみる。

結局何に使うかも分からんような機能をネタに信者だなんだと煽って構って欲しかっただけ？
煽るにしたってgitに取って代わるようなツールを挙げてくれないと面白くないんだけど

お前が面白いとかつまらんとかほんとどうでもいい
言うことないならスレ汚さずに黙ってろ

>>150
> それじゃ使いづらい場合もある、開発環境によってはコミットした時点にタイムスタンプ含め
> そっくり元のまま復元する機能もあると便利だな、というだけなのに、それを言うとgitの思想と違う、と信者は発狂する

gitの思想じゃない。ソフトウェア開発の思想。
最新のタイムスタンプのものだけビルドするという考え方は
gitができるよりはるか昔からのやり方

gitを使うことでソフトウェア開発がしづらくなったら
本末転倒だろ？

>>174
gitしか知らないぺーぺーのひよっ子が面白い事言うなｗ
お前センスねえわｗ

そもそも
>gitの思想と違う
なんて発言は誰もしてないのに、さもそんな発言があって、それが共通認識であるかのように語る

病気ですね

>>175
svnも知ってるが？

svnを使っているときからsvnはだめだと理解していた。
gitを知った（がまだ使えない）ときから、俺が欲しかったのはgitだと理解できた。

svnはすごく開発しづらかった。なにせ間違いが許されないから。
人間だから間違いはかならずある。svnだと間違いが許されなかったから
仕事を一旦片付けて（コミットして）落ち着いて確認するという作業ができなかった。

間違いは間違いのまま残り、意味のないコードを他の人にレビューさせるのが
すごく無駄に感じた。それが解消されたのでgitはすごくストレスフリーだよ。

>>177
いや知らねえよお前はｗ
それどこのｲﾝﾀｰﾈｯﾂで拾ってきたgit神話だよｗ

>>178
なんで俺の書いた内容に反論しないの？ｗ

>>179
それはこっちのセリフだよｗぺーぺーのひよっ子クンｗ

このように必死になるのがワロエルｗ

>>161
例えばGoogle Chromeとか1000万行以上、ファイル数も数万個あるんだよなぁ、そこまで大きなプロジェクトはあまり無いだろうけどさ。
ハッシュをDBか何かにファイルパスのようなuniqueな値と合わせて書き込まなきゃならないだろうし、画像などのリソースを固めるなら大きめのファイルのハッシュも計算しなけらばならないだろう。そのベンチマークはちょっと見通し甘いと思う。

>>181
なんだよもう諦めたのかｗ
俺はもっと笑いたいんだけどなｗ
もっと聞かせてくれよぅ
ひよっ子クンのソフトウェアなんとかｗの思想ｗ

構ってもらえて嬉しそう
よかったね

>>174
なんかよくわからんけど、例えば一年前にコミットしたmakeファイル含むビルド環境一式があって、
それを再現したいとき、オプションでタイムスタンプも含めてぜんぶそのときの環境が再現される
オプションがあればそれはそれで便利じゃないの？

>>185
だから何が便利なの？
タイムスタンプを再現して何が嬉しいの？
標準に入れろっていうくらいなんだから大多数が納得するようなメリットを示せるはずだよね？
それがこのスレで一つも出てきてないんだけど

>>185
>それを再現したいとき
それってどんな時？ってのが行き着くところだと思うよ
上の方でもちらほら出てるけど、必要なら実装すれば良いし、必要だと思う人が多ければ標準の機能として組み込まれるでしょ

>>185
日付が戻るのはソースファイルだけ。
そのソースファイルを使ってコンパイルすると
オブジェクトファイルができる。
"現在の日付の"オブジェクトファイルができる。

その"現在の日付の"オブジェクトファイルをリンクして
"現在の日付の"実行ファイルができる。

出来上がるのは現在の日付のファイルばっかり

で、なんか言った？

まぁ git checkout でブランチ変えるたびに make clean なりでキレイサッパリにするならタイムスタンプ復元しても問題は生じないだろうな

タイムスタンプを復元して何が嬉しいのか良く分からないけど
（ファイルに変更を加えた日を知りたいだけなら適切にコミットしてたらファイルに手を加えた日とコミットした日に大きな違いはないだろうから確認に困るってことはないし）

git以外の何らかの管理ツールがタイムスタンプで何らかの整合性を保っててその管理ツールのデータファイルもgitリポジトリに一緒に突っ込んでるとかかなあ？

>>189
そんなありそうもない例出さなくても標準で入れるべきと主張する人が素晴らしく便利な例出してくれるでしょ。
焦らしプレイが好きみたいだけど気長に待とうぜ。

普通に考えて日付が違っていてもコンパイルすれば
同じ実行ファイルができるべきである。

でないと、ファイルを保存し直しただけで
違う物ができることになってしまう

>>188
いや >>185 はオブジェクトファイルや実行ファイルまで突っ込んでるイメージでしょ
まあバージョン管理というよりバックアップツールとかの範疇だと思うが

>>191
そもそも具体的に何のためにそんなことしたいのかが分からないな

>>192
じゃあバックアップツール使え馬鹿で終わりだなｗ

意外と次のバージョンであっさりオプションが実装されてて信者が「さすがGit」とその機能を絶賛してたりしてw

じゃあ実装されるまでは、何度もお前は馬鹿だなぁって
言い続けるかｗｗｗ

>>182
まぁ、ファイル数が1000未満、行数が100万行未満くらいだったら実用になるとおもうんだけど、どうだろう。
毎回全部のハッシュを計算する必要はなくて、まずはタイムスタンプで比較して違ったらハッシュでチェック。
そうすれば、「変更はないがタイムスタンプだけ異なる」ファイルのコンパイルが不要になる。

つか、書いてて思ったんだけど、そういうビルドツール既に存在するんじゃ？

>>189
秀丸ですねわかります

>>195
それは永遠にないわ

>>196
gitでタイムスタンプを管理しないのは失敗だったかも
（でも今更だし悪い仕様でもこのまま乗り切るわ）

と講演で言っていたよね

>>196
やっすいことで満足できんだなあお前って
悲しくない？

>>200
なんだライナスも悪い仕様ってみとめてんだ

プロジェクトを作り直してコードもファイル構成も全部作り直す場合は
gitでブランチを作成して底で作業するか、別のディレクトリを作成してそこで作業するかどっちがいいでしょうか？

>>200
ああ、アイツだろ？ 名前忘れたけど
あとでTwitterとかで馬鹿にされまくってて
アカウント削除して逃げちゃったやつ

>>202
> なんだライナスも悪い仕様ってみとめてんだ
ライナスのことじゃないよｗ

リーナスは「なんでお前、タイムスタンプを戻すのが間違ってるってわかんねーの？馬鹿なの？」って
煽ってるしなｗ


Linus Torvalds
https://web.archive.org/web/20120701070035/http://kerneltrap.org/mailarchive/git/2007/3/5/240530
> But Bill, don't you realize that restoring the timestamp is *WRONG*?



スレトップ
https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536

リーナス・トーバルズ曰く

https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536
>
> それは間違い
>
> それは馬鹿
>
（gitでタイムスタンプを管理なんて）
> ぜってーに実装しねーよｗｗｗｗ


リーナスにも煽られちゃったなｗｗｗｗ

調べてみるとvsもcsvもsubversionも当然のようにタイムスタンプ復活できるんだな
リーナスの手を離れたわけだしメンテやってるあの人もそんな当たり前の機能はとっとと実装して欲しいもの

つまりgitは進化したってことだな（爆笑）

はいはい、なんでsubversionでタイムスタンプ復活させるのが
間違ったやり方だって言われていてデフォルトオフなのか考えてみましょうか

>>207
あ、ぶっちゃけさ、お前

gitでタイムスタンプを管理しないのは失敗だったと
リーナスが言ったと嘘を言ったのがバレたから、
調べてきたろ？ｗ

git logからコミット日時引っ張ってくるシェルスクリプト書きゃいいだけなのに、標準で入れるまでもないだろう

>>207
焦らしてないで教えてよ。何に使うの？

>>210
わざわざ自分で書かなくてもGitHubとかで誰かがその手のツール作ってるだろうからそれ使えばよくね？

Linus教はLinusが言ったことは全て真理というドグマで洗脳されているのか。
そりゃ議論にならんわけだw

議論したかったら用途くらい考えてから来いよ

Linusが言ったとデマ飛ばして、それを否定したら >>213 コレ
議論したいやつには全く見えない

そんなこと誰もいってねーじゃん
病気なのお前？

>>167
>git for windows ならいける

そういやこれ試してみたがちゃんと日本語ディレクトリや空白いりディレクトリでもちゃんと動作するな。
なんで公式のGUIツールはあんなクソがいつまでもほったらかしなんだ？
メンテナの出来が悪いのか？

>>216
>>202

>>217
彼らにとってWindows版が必要ないからかな

git gui普通に日本語ディレクトリ名を表示できたけど・・・？

>>203
新しいリポジトリ作るほうがいいと俺個人は思う

gitでコードを管理している分にはタイムスタンプを戻すのは愚策だと思う
（Linusもそこはハッキリ言っている）

コード以外のファイルを管理するならタイムスタンプを戻せるようにすべきだし
cvsやsvnは実際に戻せる仕様になっている

要するにgitではソースコード以外は管理できないし、させたくもない
（Linusはこれもはっきり言っている）
だからタイムスタンプも戻さない

ExcelとかビットマップまでGitで管理しようと主張するマヌケが会社にいて困るわ。
適材適所ってことがわからなくて、なんでもGitが優れていると盲信してる。

>>223
おかしくないけど？

>>223
決めの問題だからそう決めたなら、Gitで管理すればいい。成果物によって数ヶ所に置き分けないといけないよりまし。

>>224
決めの問題ならなおのこと 決めたやつがおかしい という話では

実際のところ、テキストベースではないドキュメントの管理は
gitでやる価値が半減すると思う
もちろんcvsやsvnでもあまり意味はないけど

>>223
困るならちゃんと説明してあげるか転職して会社変わったほうがいいよ

節目節目のあるリリースに関連付けられた形での
重要なデータとかテストデータとかをコミットに加えるのはありでしょ

>>227
説明しても聞かないって話だろ
盲信ってことばも知らんのか？

なんだGitに向き不向きがあるよって話だけでここまで怒り狂うのか
怖いわほんとｗ

diffが取れない程度でべつにエクセルのファイルを管理してもいいと思うけどね。
向かないとかいっても 20170319-hogehoge.xls みたいなファイルが山盛りよりはいいと思うな。

ここでもめてるgitの話題って英語圏のフォーラムとかでも似たようなやりとりあったりすんのかな
please recovery timestamp!って

実質的にタイムスタンプ復元する方法が提示されて終わりじゃない？まともなフォーラムなら

どんなケースでどんな機能を求めてて何を試してみたかを全く明らかにしようとしないまま機能が足りないって喚いてるだけだからなぁ
建設的な議論にならないよね。

>>232
ググれば一杯出てくる
http://stackoverflow.com/questions/2179722/checking-out-old-file-with-original-create-modified-timestamps

>>229
知らなかったから辞書で調べてから書き込んだんだけど…
なにか気に触ったのならゴメンな

>>234
Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ

WindowsでGUIのものを使おうと思ったら・・・・
お勧めって、亀さん？

git archiveで作ったzipのタイムスタンプって
コミット時の時刻になってない？

>>231
Excelはxmlになってからdiffとれるでしょ
見やすいdiffが必要なら専用のツールが必要

diffについてのアイデアは公式見解が

Git - Git の属性
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7

そういや最近TortoiseSVNでexcelやwordファイルのdiff見たら、Office自体の
変更差分表示機能使ってくれて驚いた。
gitはコマンドラインでしか使わないから知らないが、どうなんだろう。

>>241
あのさ、差分機能で更新箇所を確認するのは仕事のやり方としては下策で、仕方なくやるものなんだけどな。

だからなに？

>>242
上級者のやり方教えてくれ w

プログラミングにかかわらずドキュメントの類は差分ベースで仕事を進めることで効率が著しく向上する
これに気がついてない日本のホワイトカラーの現場はほんとヤバイ

オイまた拗らしちゃったのが出てきたぜw

Excel仕様書なんか捨ててMarkdownとかで書いた方がいいこと多いよね
軽いし差分比較も見やすいし

おまえらどこをどう変えたのか毎回忘れて差分比較して仕事してんのかよw

>>248
お前の所は作った本人しかドキュメント読まないのか？

わざと忘れたりするわけじゃないが
最近は差分を積み上げてくような感じで仕事をしてる
できうる限りそれで進めて、どうしようもない時だけ時間をかけて全体を見る

>>249
共同作業の場合は更に効果倍増だな
でも、おれは一人でも作業する場合も、差分ベースで作業を進めることが劇的に効率を上げると思ってる

レベルが低すぎて話にならん

>>247
個人的には AsciiDoc 使ってるんだけど他にお勧めある？

>>252
もう逃げ恥モードかよ w

>>252
あんたにとってはgitもレベルが低い仕組みなんだろうな
でもこれが普及して他のツールを駆逐してしまった意味をよく考えてみた方がいいぞ

全然駆逐してないんだけどな
SVNもP4も普通に使われてる

>>255
駆逐してねーよ

もうgit以外を使ってるのは普通じゃない
特殊な事情

>>255
おまえのことなど知らない

>>259
で、gitのことはどう思ってるの？
差分を編集する機能を重視してるのがgitなんだけど
差分機能で更新箇所を確認するのが下策だと思ってる人はこれを受け入れちゃうわけ？

>>260
gitやその他vcsのことを何もわからずに煽ってるだけなんだから、
そんなに難しい質問してやるなよ。無視するしかなくなるだろ。

>>242
頭おかしい

>>237
亀はだめ
Explorereが劇重になる

>>258
新しいプロジェクトに配属されて、バージョン管理がSVNだったらガッカリするからな

>>236
> Gitはタイムスタンプなんて保存してねえよって回答もあって、けっこう高評価ついてて笑うｗ
ファイルのタイムスタンプだろ？
保存してないよ。

嘘だと思うのなら、ファイルを修正してから次の日にコミットしてみ
ファイルのタイムスタンプじゃないものが保存されるから

>>265
頭大丈夫か？

>>260
Office製品の変更履歴機能の失敗も知らない世代なのか？

>>266
え？ そんだけ？

>>267
それがどうしたんだよw

バイナリファイル系は適切なツールを使えば
差分を知ることはできるが、
差分を知る以上のことはできない。

例えばcherry-pickとかmergeとかね

ただsvnとかでバックアップツールとしか
見てなかったやつは、そもそもmergeとかいう概念がないから
差分だけわかればいいと勘違いしてしまう。

それじゃプログラマとはいえない。

officeのドキュメントを差分管理ベースで作業できるようにするなら
ドキュメントの中の要素を個別に差分取って管理できるようにならないとダメだろうなあ

アプリのソースが一つのファイルにすべて書かれてて、
それをgitで管理しろとか言われたら気が狂うｗ

複数のブランチを切ることがそもそもない環境なら、mergeとか知らなくてもしょうがない

>>271
ZIP解凍した中身をgitで管理
pullで自動圧縮するようにできればお望みのことが実現するのだが

>>273
docxとかだよね？あれの中身って文章が構造的に分割されてるわけじゃなくて
単にスタイルとかイメージとかが分離されてるだけじゃないの？

>>274
それでもXMLだから差分は一目瞭然かなと

xlsxやpptxならシート/ページごとにXMLファイルが分かれるからもっと管理しやすいかも

>>270
行単位の処理とかは無理かもだけどcherry-pickやmergeはできるんでない？

>>275
少なくとも、差分を見ただけでどの章のどこが更新されたかが分からないとつらいかな
ドキュメント全体をひとつのxmlで管理するなら
そういう機能をもった差分ビューワが必要になると思う

>>277
そういう目的ならExcelかPowerPointってことになるかね

Office用の見やすいGUIの差分ビューワもあるけどたいてい有償だから
まずはここに書いてるのから試してみたら
http://qiita.com/shuhei/items/6a18d968051378d7ac1a

>>275
差分見えてもmergeはconflictの山になって事実上無理ぽそう。

ここで言うことでもないけど
いい加減Officeを卒業したい

早く画面キャプチャをExcelに貼る作業にもどるんだ

>>275
> それでもXMLだから差分は一目瞭然かなと

え？ お前OfficeのXMLのタグを知ってるの？
XMLのタグを知っていないと、差分は分かっても
その意味はわからないよね？

>>280
> 差分見えてもmergeはconflictの山になって事実上無理ぽそう。

XMLのタグの整合性、つまり閉じタグの対応まで
ちゃんとやらないとだめだからねｗ
タグの意味、属性、誰か解説してる人いる？

Excelファイルのバージョン管理なんて実質タイムスタンプで管理するしかないのに、とにかくGiｔ真理教の信者は
なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す

gitがバイナリに弱いのは誰もが認める話だと思うけど、タイムスタンプで管理するのは無くない？
svnとか他のバージョン管理システムってタイムスタンプ見て管理なんかしてたっけ？

>>270
適切な扱いが出来るかはそのバイナリファイルを扱うソフトウェア次第
3wayマージが出来るならgitの機能は全部使えるだろう

>>285
gitがじゃなく、汎用バージョン管理システム全般が、個々のファイル仕様に独自に対応しなければならないファイルに弱い
というより、テキストファイルのシーケンシャル性と改行で意味分割する仕様が特別汎用性に優れてるだけ
gitはエディタも差分表示もマージツールもファイル属性に応じた外部ツールを使用出来るようになってるから、まだそういう仕様が不明なファイルに強いと言える
gitが弱いのはバイナリファイルではなくサイズが巨大なファイル
たとえテキストファイルでも1ファイル1Gとかになると扱い辛い事になるはず

>>284
excelは標準では同じファイル名のファイルを同時に複数開けないし開いただけでタイムスタンプが変わるから、ファイル名でバージョン管理するのが基本だと思うけど
どうやってタイムスタンプでバージョン管理するんだ？

>>265
どうでもいいけどファイルのタイムスタンプを保存している(する必要がある)なら
ファイルの中身を変更せずにファイルの日付だけ変更してコミットしたときに
何も変更されてねーコミットスルーしよーぜってのがgit
それもファイルの変更とみなしてコミットするのはあほ

指定した範囲のコミットログを表示する方法を教えてください

例えばhttps://github.com/git/git/releasesなら
タグv2.11.1からv2.10.0の間のログのみgit logで表示したい
タグがダメならコミットIDで指定でも構いません指定した範囲のログさえ取れれば

てんてん

>>284
> なにかテキストファイルレベルでの差分での管理が実用的みたいなウソを垂れ流す

差分での管理なんて一言も言ってないけど、
ソースコードであればテキストファイルで管理するのが
一番実用的だ。これは本当。

ソースコードがテキストファイルでないものがあるが
（例えばExcelなどの埋め込みVBScript）
見事に管理しづらい。

>>289
何を言ってるのか全くわからない。

コミットの日付とファイルの日付（タイムスタンプ）は本質的に違うものであって
gitが記録しているのはコミットの日付であって
タイムスタンプじゃないといったのが理解できなかったの？

コミットの日付を記録するんだから、ファイルに変更がなくコミット自体が発生しなければ
当然コミットの日付は記録されんよ。当たり前だよ。

>>288
> どうやってタイムスタンプでバージョン管理するんだ？

ここで>>284に言ってほしい言葉は、

「タイムスタンプが新しい方を最新バージョンとみなすべきだ。
たとえ古いファイルを間違って修正した結果、新しい日付になった場合でも
AさんとBさんがそれぞれ違うシートを修正したとしてもだ！」

って（間抜けな）言葉だねｗ

当然、そうならないようにロック機能をつけるんだよw

ロック機能をつけた所で、違うブランチで作業したら
ロックかからないんだから、同じ問題が発生するだろｗ

当然、リポジトリは1つだけに限定してブランチも認めないんだよw

>>297
それじゃファイルの管理しか出来ないじゃんｗ
どうやってアプリのバージョンの管理をするんだよｗ

新しいバージョンへ追加する機能をマージしていくのが
バージョン管理というものなのに

せっかくのボケに対してマジレスしてどうする。
「それはSVNやんかー」と正しく拾ってあげんか。

マジレスすると、馬鹿がムキーってなるだろ？ｗ
それが狙いだよ。

VSS
をお勧めするｗ

>>294
なんか勝手にレベルの低い敵を想定して、それをバカにすることで勝ったつもりってのが新しいなw
情けないにも程があるw

>>302
そうじゃないよ。もっと面白いことを言ってみせろってことだよｗ
>>294ぐらいの内容は想定済みだからさ

>>296
そんな間抜けな機能を実装してどうする w

v2.12.1

>>304
SVNディスってんの？

svnは駆逐された

svnはバックアップツール的な役割で当分生き続けると思う
ソースコード管理としてのsvnはもう見たくない
あとVSSとかいうゴミが未だに生き残ってるのはうちの会社だけであってくれ

>>307
されてないよ

GNU - Free Software Directory
http://directory.fsf.org/wiki/GNU

この中でGitを採用してるプロジェクト少なそう

GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)
https://gcc.gnu.org/


gccですらSVNだし

Gnu Emacs は古参を説得してgitに移行したんだよな

ローカルコミットあればsvnでもいいんだけどな。

gitと同じ機能があればsvnでもいいんだけどなA: [0.091163 sec.]B: [1.205233 sec.]

いやそれなら git でいいだろってなるでしょ。
ってなんか話がわかんなくなってきた。。

リーナスの最大の功績はlinuxではないrebaseなのだ
おかげでバカがrebaseに夢中になっている間にスムーズに仕事が終えられる

そのリーナスがrebase使いまくってるんだが？

じゃあリーナスはバカだな

だって「git」じゃん……

道具は使うためにあるんだよ

道具に使われてる感があるな

gitは使うことに意義がある

ここは布教に意義を見いだしてる奴の方が多くね？

gitに限らずコイツらの布教活動が成功したためしなどただの一度もないけどなｗ

>>323
自分がいいと思ってる、使っているものが正しいという阿呆がなんにでもある。

世界を自分(たち)にとって都合の良い方向へ変えようとする活動が布教
変えてゆくためには相手を納得させるか騙すか強要するか
都合の良い部分は伝えるが都合の悪い部分は隠すか屁理屈か嘘で押し通す

布教行為を許してはならない

VCSは頭の良い奴にしか使いこなせない
複数種類のVCSを使いこなせるのならかなり頭が良い

>>327
あっそ

Git推しのやつの微妙なウザさってのはあるよなあ

>>326
という布教

>>329
gitスレで言うことかね

言ってもいいんじゃね。
おれもgit は好きだけどgit厨は嫌いだし。

>>331
言うことだよ！

>>332
わかる
特定のflowを絶対正義だと信じて「git pull --rebaseしないのは馬鹿」とか言い切ってくる奴とかなー

あるある大事典：
git の話ばかりしているから svn スレかと思ったら git スレだった…

>>335
意味が分からない

>>335
思わねーよ

gitの話ばかりしてるから、(gitに対して嫉妬してる)svn(ユーザ)のスレかと思ったら、git(信者がのさばってる)スレだった…

SourceTreeって重くね？
リポジトリを幾つかブックマークに追加しただけなのに
起動がとんでもなく遅くなった

v2.12.2

短期間リリースに方針変更？

branchだけしてcheckoutし忘れ
誤ってmasterブランチにコミットする大事故

王様のbranch

>>342
つgit checkout -b new_branch

git stash popは危険なコマンドだと思いませんか？
間違えたブランチで実行してしまったら元に戻せませんね。

正しいブランチでやり直せばいいだけ

>>345
元に戻すためのgitでしょ

マージ失敗したらdropされずに残るので、やり直せる
マージ成功ならもう一回stash saveも出来る

万が一？pop後にファイルをresetしてもコンソールを閉じていなければdropしたコミットハッシュが残っているはず
億が一それも消しちゃってもfsckで到達不能なコミットを探せば復元可能
間違って消す方がむずい

大抵の手違いは元に戻せるのがgitのいいところなんだけど
ファイルスタンプを戻すのだけはなぜかできないんだよな・・・

ファイルスタンプは手違いで発生するものじゃないからねｗ
手違いじゃないのだから戻さらないというのが
正しい動作。

またお前か

東京電力の新会長に日立製作所の人間が就任

>>352
git終了だな

いつまでタイムスタンプの話続けるの？
欲しいやつはgit logから引っ張ってくればいいだろ

リーナスにタイムスタンプ入れるとかアホって言われたのが
よっぽど悔しいんだろｗ

またお前か

インターネットみてると「マスターをチェックアウトして」とか
「マスターへチェックアウトして」とかいろいろな表現を見るけれど。
どれもマスターのブランチへ移動していることを示しているのがおかしくないですか？
今のブランチをチェックアウトしてマスターにチェックインするってことなんだから
前者はマスターから抜け出すことになるし、後者は意味不明になりますと思いませんか？

君の日本語が意味不明

自分がブランチに出たり入ったりするというのは斬新な見方だな。ホテルかよ。
リポジトリから指定のリビジョンのソースを(ブランチ・タグ・ハッシュ等で指定して)チェックアウトするんだよ。
後者は日本語に不自由なやつなだけだと思うが。

>>359
後者は「マスターをチェクアウト」と「マスターブランチへ移動」が混ざったんじゃ無いかな？

>>357
> 「マスターへチェックアウトして」とかいろいろな表現を見るけれど。
気のせいでは？

https://www.google.co.jp/webhp?sourceid=chrome-instant&;ion=1&espv=2&ie=UTF-8#q=%22%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%B8%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A2%E3%82%A6%E3%83%88%22&*
"マスターへチェックアウト"との一致はありません。

ごめん、結構いたわ。

"masterにチェックアウト"
約 724 件 （0.45 秒）

コンフィグのここで疑問なんだけど
[branch "master"]
remote = origin
merge = refs/heads/master
ここで、なぜmerge = origin/masterじゃなんですか？
branchマスターが追跡しているのはorigin/masterで
origin/masterが追跡しているのがrefs/heads/masterなので、
一段飛び越えていて変なんですけど。

ブランチを切る ってどっちの意味？
作成する？ 削除する？

もしかしてrefs/heads/masterはローカルを指していて
デフォルトでmasterでpullすると別のブランチのところにmergeされるってこと？
それがなにの役に立つというの？

小切手を切ると同じ意味

>>363
それは、ローカルのファイルシステムのパスです。
https://git-scm.com/book/ja/v1/Git%E3%81%AE%E5%86%85%E5%81%B4-Git%E3%81%AE%E5%8F%82%E7%85%A7

refs/heads/masterはリモートを指してるらしい、
そしてpullで初めにfetchしたときにrefs/heads/masterがfetchしたなかにあると
refspecで調べてorigin/masterに変換して今のブランチにmergeするらしい

>>368
refs/heads/masterが、masterという名前のブランチの正式表記で、originのリモートリポジトリの別名表記ってだけじゃないの？

tagにも同じ名前を付けられるからコンフィグは正式名称の方が都合がいいし、
リモートリポジトリは参照するサーバーやリポジトリパスが変わることもあるし、同時に同じリモート名は付けられないから別名表記の方が都合が良い
ってことだと思うけど。

ホテルから出ることをチェックアウトと言う

リポジトリという名のホテルに
masterブランチさんやdevelopブランチさんたちが宿泊してる
そこからチェックアウトして作業現場まで来てくださいって意味

git checkout master

SVCとかSubversionとかVSSだとリポジトリからファイルがチェックアウトされて
編集されたあとまたチェックインして元に戻る、というアナロジーが非常にわかりやすい
けど、Gitだとなんかいろんな路線に分岐してはまた合流、って感じが強くてなんか
あわない感じはあるよな。
流れのなかのある「状態」に戻したり勧めたりする感じというか。
もっとわかりやすい用語にできたのかもしれない。

成る程

VCSでチェックイン使う人っておっさんのイメージ

>>373
おっさんは色んな環境・用語に晒されてるから、VCSみたいな同じような機能にそれぞれのアプリケーションで別の用語を割り当てるシステムだと、ごっちゃになるんだよ

gitのタイムスタンプは記録されてないけれど
パーミッションは記憶されてるの？

>371
そーかなー
むしろそういう風にコマンドを整理したのがsvnでリポジトリからローカルコピーを得る時しかcheckoutじゃないでしょ。

gitはチェックイン/チェックアウトシステム体系はCVSと変わらないからcheckoutするときはcheckoutで良いと思うんだが、ローカルの編集を破棄したいときこそresetだとかrevertとかにして欲しかったとは思う。

>>375
実行権限のみ

いろんな人がいろんな環境でチェックアウトするのだから
グループやその他のパーミッションは記録する意味がないし、
umaskの設定に従えば十分

また自分自身がチェックアウト（＝書き込む）ファイルなのだから、
リードオンリーにすることもできない。

よって実行権限のみ記録するのが
バージョン管理ソフトとして正しい仕様。
gitもそれに従っている。

>>377
所有者くらいは記録してほしかったよね

その心は？

正しい仕様、みたいにすぐドグマ化しちゃう人って柔軟な発想ができなくて開発者としてはポンコツなんだろうなあ

必死に覚えたんです
違うこと言わんといて

>>380
これわかるわ
正しいとか正解とかそういう言葉を頻繁に使う人は状況に応じた選択ができない

小池知事のようなひとのことですね

>>380
同意
明確に条件が限定された状況で、考え抜いた上に「正しい」とか言うのならわかるけど、バージョン管理なんてソフトウェアのソースコードに限ったとしても
ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに、自分の知ってる範囲だけで決めつけちゃうのってダメだよね
お客さんの要求の本質を汲み取ろうとせず勝手に自分の都合で判断してそう

>>378
> 所有者くらいは記録してほしかったよね

所有者とは？ 会社名？ｗ

一行ごとに誰が修正したかは記録されている。
その話をしていないということはお互い理解しているという前提で


なんのために所有者を記録するの？

>>384
> ゲーム、組み込み、Web、業務システムで求めるものが全然違いそうなのはちょっと想像しただけでわかるのに

ぜんぜん違うと言うものの具体的な例を
君はこれから言わなくてはいけないということになったんだが、
できるかい？


それができるまでは、ゲーム、組み込み、Web、業務システムで
求めるものに違いはないという今までの常識通りでいくからさｗ

日本語が理解できない信者登場

信者というとgitが如何わしい新興宗教みたいじゃないか
こういうのはストレートに馬鹿と呼んで欲しい

git信者は巨大なバイナリデータの管理もgit一本でやるの？
カッコ良すぎて濡れちゃう//

信者なら「そんなもんリポジトリに入れんな」って一蹴だろ。

そしたらリポジトリに入れないでどうやって管理するの？という質問がでてくる

刺身包丁で中華料理をつくる料理人みたいだな。
gitでバイナリ管理。

巨大なファイルはリポジトリに入れないで、ファイルがある場所の情報だけいれればいいのよという意見が出てくる

ブランチ切り替えて別のファイルに変わるたびに入れ替えるの面倒だよ

gitのフックがあるじゃないか。そこで自動化すれば良いのさ

なるほど。巨大なファイルは別のストレージで管理して、git cloneしたときなどに
フックでファイルが有る場所の情報からファイルを取ってくれば良いのか！

便利そう！それプラグインにした良いんじゃないかな！？

ふふ、実はそれ、もう実用化されてるんだ。

なんだってー！！！

その名も

その名も？

・・・

（ゴクリ）

暇なので何度も出たであろうネタ投下ｗ

Linus曰く「Subversionは史上最も無意味なプロジェクト」
https://developers.srad.jp/story/07/12/03/1024220/

何に使うかも分からん機能について語るのが最近の流行りなん？

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

gitを批判することが目的となってるやつだなｗ

>>407
それはいない

>>385
基本的に 可能な限りファイルの属性は記録してほしい ということ
タイムスタンプもそうだし、userやgroupもほしい
あとはスペシャルファイルのたぐいも

GitLFSじゃあかんのか

>>409
なんのために？

>>411
バックアップソフトとして使うためだろ

gitはバックアップソフトとして使えないからクソ

ならバックアップソフトを使えば良い

>>390
じゃあどうするの？
別のバージョン管理ツール使うの？

>>415
"バージョン"管理ソフトっていうのはファイルの版ではなくて
アプリのバージョンを管理するもので突き詰めるとソースコードを管理するものなんだよ。
ソースコードの管理というのはファイルの中の修正箇所を調べたり
一部分を抜き出したりマージすること、ソースコードエディタと言ってもいいぐらい

バイナリファイルであればそれらが出来ないので
どうあがいてもバージョン管理は出来ない
せいぜいファイル管理程度

>>416
じゃぁファイルの版はどうやって管理するの？

ファイルサーバーにでもおいておけば良いんじゃねーの？

>>418
ファイルサーバーで「版」の管理はできるの？

「版」の管理ができるファイルサーバーを使えばいいし、
たいていはバックアップ機能で十分

バイナリはどうせ差分見れないからなんでもいいよ

>>419
そんなもんWindows標準のバックアップ機能でもできるよ

ソースの版とリンクしてる
バイナリファイルの版をどう管理するのかってことじゃないのか？

バイナリしかないサードパーティライブラリとか画像系のアセットも普通gitで管理するよね？
デザイナ系の人が頻繁に編集するデカいファイルはGitLFSみたいな追加の仕組みを使うか
別のツールで管理してリリースバージョンのみgitに入れるかかな

>>423
結局これが一番困るよな。
テキスト以外なくても困らない開発だったらいいんだろうけど、そうじゃないものも多い。

バイナリだとかdiffだとかこれで対応しろバカども

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7

大きなバイナリファイルのバージョン管理が本当に必要ならべつにリポジトリに入れてもいいんじゃね？
単にリポジトリがでかくなるのが嫌われるだけで、他のsvn等に比べて特にgitが苦手というわけでもあるまい。

>>423
そんなもんファイル名、もしくなディレクトリ名を別にしておいて
参照先の名前を変えれば済む話だろう？

>>427
済まないから困るんだろ、勝手に問題ないケースに置き換えて話するのはおかしいでしょ

画像リソースまでソース管理から除外するのかよw
基地外じみてる

>>428
なんですまないの？

俺はできる限りはリポジトリに入れるけど。
100 M とか超えてる場合はちとどうするか迷うが。

>>427
参照先の名前変えるってなにそれ？
管理したいバージョンごとにファイル名やディレクトリ名を変えるの？

>>432
ファイル名やディレクトリ名は最初に作ったまま固定変えたりしない。
ファイルサーバーは原則として追加するだけ。

そして新しいリソースに更新したければ、
ソースコードの設定ファイルをいじって、
参照するファイル名（ディレクトリ名）のパスを変更する

パスを変更するってことはディレクトリ名かファイル名かは変わってるんじゃないの？

>>434
ファイルは追加するだけなんだから、最初から別の名前にするしかないだろ。
中身が違えば、それは別のものだ。

結局ファイル名に日付入れて管理しろと言い出すわけだな。
gitいらないじゃん。

>>431
Excelも入れる？

ソースコードはGitで管理して
ソースコードに関連するバイナリはファイルサーバに日付入りのディレクトリにおいて
新しいバイナリが追加されたらGitで管理してるソースコードにそのバイナリへの参照の更新をコミットする
こんなの普通にやるだろ
これとgit無しで全部日付入りフォルダで管理することの違いが判らないのは基地外

>>436
> 結局ファイル名に日付入れて管理しろと言い出すわけだな。
> gitいらないじゃん。

だからバージョン管理システムは、ファイルの版ではなく、
ソースコードのバージョンを管理するものだから、
バイナリにはgitいらないって言ってる。
人の話聞けやｗ

gitはソースコードを管理するためのものだ
ソースコードじゃないものを管理するものじゃない。
巨大なバイナリファイルをいれんなｗ

Git LFSはすでにVersion2.0.2でGitHubもGitLabもGit LFSに対応済みなのに
バイナリだけファイルサーバや別のツールを使う理由がわからない。

Git LFSは "別のツール" だぞｗ

それこそバイナリだけ別のファイルサーバーに格納するものだし、
単にファイル名とリンク先の対応を自動化したものにすぎない。

画像リソースだけ別サーバーとかありえねー

>>442
別サーバーにする必要はないよｗ
同じサーバーで2つのツールを動かせばいいだけ
gitサーバーとファイルサーバーの2つ

同一サーバー別サービスでも有り得ない

何がありえないのかわからん。

そんなにいやなら、gitlabみたいな
gitサーバーとlfsサーバーが
一緒になったツールに使えばいいやん。

>>441
バイナリは世代ごとにディレクトリを変えて保存し
ソースコードの設定ファイルをいじれという話はなんだったの?
Git LFSならそんな手間は不要でソースと同じように扱えるだろ。
まあGit LFSを使う事に異論がないなら他は重要ではないけど。

>>444
GitLabとGit LFSを使ってExcelなどのバイナリでできたドキュメントの世代管理をする
http://blog.naotaco.com/archives/1112
最初にバイナリ管理にしたい拡張子とLFSサーバを登録するだけで、
後はソースと同じgit コマンドで取り扱える。

>>446
> バイナリは世代ごとにディレクトリを変えて保存し
> ソースコードの設定ファイルをいじれという話はなんだったの?

gitにバイナリファイルを入れないでバイナリファイルを使う方法の一つ
それを自動化したのがgit lfs

>>445
そんなアホなことせんでも全部gitに放り込んで問題ないですし

>>448
バージョン管理ソフトでバイナリファイルを扱う意味がないということ
問題がないなら入れてもいいだろうが、それは単に入れるだけ。
バージョン管理は出来ない。

>>449
プロジェクトのリリースバージョンごとにバイナリを管理できて大いに価値がありますが

>>450
> プロジェクトのリリースバージョンごとにバイナリを管理できて大いに価値がありますが

それは、リリースバージョンごとにバイナリをディレクトリに配置して
リポジトリに登録するという作業をやった場合の話だろう？

その作業とファイルのリンク先を変えるのとは手間は大して変わらんのだが？

>>451
え？
リリースごとにタグ付けるなりブランチ切るなりするだけですけど

>>452
それはファイルのリンク先変えるのも一緒です。
はい、ざーんねーんｗ

>>453
なに言ってんのこの人

>>454
お前本気で分かってないのな（苦笑）

>>439
ソースコードと不可分なリソースファイルだったとしても、「見た目がバイナリだから」バージョン管理ツールであるgitで管理する必要はないと言いたいのかな？
例えば、ゲームのマップデータのような独自フォーマットのリソースはパーサーと一緒に管理しないと意味が無いわけだが、「バイナリだから」入れる必要はないのかな？

逆に、自動生成された巨大なXMLは実際にはgitで管理しても実際にはdiffを確認したりマージしたりすることはできないけど、結局はバイナリデータのようにしか
取り扱えないと思うけど、「テキストだから」gitで管理する意味があるのかな？

「バージョン管理」と「差分確認、マージ」は完全に同一というわけではないし、バイナリだからできない、テキストだからできるってものでもないだろ。

>>456
バージョン管理ソフトはソースコードを管理（＝マージなど）するもので
それができないのなら入れる必要はない。
入れてもいいけど入れる必要はない。
大きいバイナリなど入れることで問題が起きるのなら
入れないほうが良い

画像リソースなんてソースファイルみたいなもんなのにいちいち分離してられるかよ
CUIしか作ったことないのかな

バイナリはファイル名でバージョン管理したい人みたいだからもうほっといて差し上げろ
ID:9Eckjtd/0 == ID:n7h/bBRg0

ファイルを管理するためにgitを使うんじゃなくて、
gitを使うためにソースコード入れてるだけの人だよね。
開発してるわけじゃないんだよ、git使ってるだけ。

>>383
>ファイルを管理するためにgitを使うんじゃなくて、
>gitを使うためにソースコード入れてるだけの人だよね。
>開発してるわけじゃないんだよ、git使ってるだけ。

こいつバカかw

好きに使え。
ツールに振り回されてどうする。
バイナリ入れたきゃ入れればいい。
入れたくなければ入れなきゃいい。
ケースバイケース。

バックアップツールとして使いたいなら
gitじゃなくてバックアップツールを使ったら良いじゃん？

プログラムに内蔵されるリソースの話をしてるのに、
バックアップツール使えとか、頭おかしいだろ。
頭の中身もgitで管理してみたらどうだろう？

画像リソースで話が通じないんだもん
本当にCUIしか知らないんだろ

git lfs使えで結論出てると思うのですが