Git 8

1 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 21:16:57.41 .net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System git-scm.com/ ◆関連サイト Pro Git - Table of Contents progit.org/book/ja/ Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 7 toro.2ch.net/test/read.cgi/tech/1381929347/ 321 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 11:48:56.23 .net] >>314 ゴネたり誤魔化す奴のために機能を削れってか？ 糞だな。 確かにそういう環境ならgit使わなくていいよ 322 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 12:00:16.05 .net] >>317 リーダーとかマネージャーやるようになったら、そういう苦労もわかるようになるよ 323 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 12:03:21.74 .net] そこまで考えてクソだと思うなら使わなきゃいいだけなのに いったいどうしたいんだろう 324 名前：デフォルトの名無しさん [2014/02/12(水) 12:11:30.31 .net] 馬鹿には無理 325 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 12:35:12.28 .net] >>318 まずは、誤魔化したりゴネたりする部下の態度を改める努力はしたのか？ それが面倒くらいだけなんだろ？ その面倒を避けるためにgitという他に余りあるメリットを切り捨てるという愚策。 つまり本質的なところでお前はマネージャーとしての苦労を放棄してるんだよ。 326 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 12:58:54.22 .net] リーダーとかマネージャ側の都合でGit使えないとか情けなさすぎて涙が出る 327 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 13:02:24.34 .net] 折衷案としては 「履歴書換申請書」（専門部署による決裁） かなｗ 328 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 13:26:37.62 .net] >>321 いや、想像だから。うちはポリシーで対応してるって書いてる。 まあ、誤魔化しとかチェックしないとわからないけど。 329 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 13:29:32.60 .net] 共有リポジトリの改変許可は>>323のレベルの非常事態対応だけでいい 好き勝手やっていいのはローカルリポジトリだけだ 共有リポジトリとローカルリポジトリに明確な線引きをして ローカルリポジトリ側で好き勝手やれるのがGitのメリット 330 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 13:32:20.21 .net] >>324 共有リポジトリへの直接ログインを制限してさらに>>315の設定してあれば、 誤魔化すとかできないだろ？ 331 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 14:00:22.11 .net] >>326 それは俺が>>314で言ってること。 高機能と低機能の比較の話で、gitがって話ではない。 332 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 15:17:51.75 .net] あ、話をまとめるとだな。 「subversion」 = 「gitのリモートリポジトリ」 こういうことだよ。 subversionでできることはgitのリモートリポジトリでもできるので リーダーとかマネージャーとかマージする時にチェックが必要とか そういう問題については解決だ。 で、重要な違いはここから 「gitのローカルリポジトリ」　これはsubversionには無い。 subversionではローカルで作業している間は昔ながらの ファイルコピーでバックアップ（笑）をしていなきゃならないし 作業中の特定の地点のコードに戻すのは大変だが、 gitではリモートリポジトリに加えて、ローカルにも 個人専用のリポジトリがあるので開発作業が格段に楽になる。 333 名前：デフォルトの名無しさん [2014/02/12(水) 15:43:45.82 .net] robocopy使えよ捗るぞ 好きなタイミングで突っ込めるし何よりわかりやすい 334 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 15:44:38.64 .net] robocopyじゃ捗りません。 どれだけ低機能で満足してるんだよｗ 335 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 15:45:58.04 .net] 結局アレだ、subversionをファイル倉庫として バックアップ機能としてしか見ていないから コミットをマージして開発する流れが理解できんのだ。 336 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 15:51:00.22 .net] むしろそういう旧態然の人が居てくれるお陰で ご飯を食べるチャンスが増える 337 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 17:17:26.77 .net] robocopyみたいなツールじゃ特定地点に戻したりとかしかできないもんな。 Gitなら特定地点から現在までのコードの差分を機能別に分類。 分類した差分を任意の組み合わせで適用して試すとか出来るからなあ。 そして必要な差分だけを一つのコミットとして共有リポジトリにpush。 残りの差分はまたローカルにいじくり回す作業を続ける。 こんなのを手作業でやるのは気が遠くなるけどGitなら簡単にできる。 338 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 17:20:34.88 .net] git でリモートブランチとのアクセスが生じるのって push と pull 以外にあるかしら？ 339 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 17:29:04.93 .net] ローカルとリモートのリポジトリ間で情報をやりとりするのはpushとfetchだな pullはfetch+mergeでしかない 後はcloneで丸ごとリモートリポジトリをローカルにコピーとか ls-remoteでリモートリポジトリを参照するとか 340 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 17:35:56.45 .net] >>335 ありがとう。 ls-remote を知らなかったよ。peek-remote とか色々あるんだな・・・ 341 名前：デフォルトの名無しさん [2014/02/12(水) 21:44:27.44 .net] repoA　　　repoB リモート　　ローカル 俺が指摘したのはこの間をrobocopy使えつー話なのに robocopyでバックアップ管理だとしかおもえなかったんだね やはり馬鹿には無理だね(笑) 342 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 21:46:59.74 .net] そう。無理無理。わかったよ天才だ君は。 343 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:14:40.24 .net] >>337 なにそれ？ローカルが一つなの？ 344 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:16:54.79 .net] svn使ってるなら、git-svnでかなりの事が出来るのに。 まあ、オレの周りでも禁止してるわけじゃないのに頑なに使わずにコミットミスや コミット漏れを続けてるのがいるけどね。 345 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:34:59.03 .net] commitしてpushまでしちゃったら もう取り返しはつかないよね？ つくかもしれないけど 下手にごちゃごちゃやるよりは 忘れてもっかいcommitすべきだよね 346 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:35:31.22 .net] それは使わないんじゃなくて、使えないんだろ。 347 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:41:16.96 .net] git-cvs は便利だね 348 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 22:58:42.71 .net] >>337 馬鹿には無理wwwwwwwwｗｗｗｗ 349 名前：デフォルトの名無しさん mailto:sage [2014/02/12(水) 23:27:27.46 .net] robocopyは便利だな というかrsyncのコマンド体系が分かりづらすぎる 350 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 00:08:11.05 .net] >>337 それで何がしたいの？ 351 名前：デフォルトの名無しさん [2014/02/13(木) 00:09:58.47 .net] アンチって何でわざわざ自分から嫌いなものに関わろうとするんだろうね、よく分からない 352 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 00:46:03.94 .net] rebase するときって一つ前のコミット ID を指定するけど、 一つ前のコミットが存在しない初回のコミットって内容の修正は出来ないのかな。 353 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 00:53:59.26 .net] rebaseの引数にコミットIDなんか書いたこと無いなぁｗ 354 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 00:59:46.37 .net] rebase -iを使うときは書き換え始める位置のひとつ前のコミットIDを指定するかな 355 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:02:21.03 .net] 質問の意味がよく分からない 図で説明してくれ 356 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:05:00.67 .net] え？ 一つ前ならHEAD^じゃん？ 357 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:11:03.20 .net] イニシャルコミットの一つ前のコミットが存在しないから イニシャルコミットは書き換え出来ないってことだろ 358 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:13:24.26 .net] git init直後の最初のコミットは空にするようにしてる 359 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:19:58.57 .net] 空のコミットってどうやるん？ 360 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 01:23:04.70 .net] git commit --allow-empty 361 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:01:03.09 .net] お、さんきゅー 362 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:02:02.05 .net] >>348 最初のコミットの書き換えはメンドクサイことすればできるよ 最初のコミットからブランチを作ってそれをcommit --amendで書き換え (この時点で起点を共有しないブランチがリポジトリに存在することになる) その後もとのブランチに戻って、書き換えた最初のコミットのブランチへrebaseする 363 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:22:14.50 .net] はぁ？ git rebase -i -root これだけじゃん。 何が面倒くさいのか。 364 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:47:35.96 .net] >>359 うちのgitにはそんなオプションないな バージョン� 365 名前：｢くつよ？ [] [ここ壊れてます] 366 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:52:49.96 .net] Git - git-rebase Documentation git-scm.com/docs/git-rebase > --root > Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. 367 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:54:45.78 .net] 1.7.xだとgit rebase -i --rootもダメだ 368 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:55:26.77 .net] ああ、1.7.12から使えるようになったらしい 369 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 02:55:44.94 .net] gitは最新版を使った方がいい。 370 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 03:03:25.78 .net] rebase: learn to rebase root commit ・ 190f532 ・ git/git ・ GitHub https://github.com/git/git/commit/190f53232d1e92a57843df90e889bcfea39620d3 > Teach git-rebase a new option --root 371 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 03:06:14.41 .net] debian squeezeだとbackportsでも1.7.10が最新なんだよなあ そろそろ新しくするか 372 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 03:14:09.08 .net] debianとかねーわ 373 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 03:14:32.42 .net] コンパイルして入れればいいのに。 gitは仕組み的に、ファイルにアクセスして ネットワーク通信するだけだから簡単にコンパイルできるよ。 374 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 03:14:32.86 .net] >>365 そのへんのバージョンだと-i --rootじゃダメで、--ontoを指定しないと叱られる 375 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 08:00:01.28 .net] >>368 > ファイルにアクセスしてネットワーク通信するだけ そんな言い方したらほとんどのソフトが当てはまるわけだが (w 376 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 08:39:06.72 .net] 数百を超えるソフト使ってるのに、いちいち手動で入れてられんわ 377 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 08:47:43.84 .net] 必要な物だけ手動で入れればいいのでは？ 378 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 09:00:12.35 .net] お、新しいバージョンだと最初のコミットもいじれるのか 379 名前：デフォルトの名無しさん [2014/02/13(木) 14:21:01.59 .net] squeezeなんてもうすぐeolだぞ 380 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 17:31:20.08 .net] filter-branchって 既に ・master ・develop ・feature/hoge ってブランチがリモートにあったら git branch -t -b xxx origin/xxx って手元に全部持ってきてから git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch keshitai.txt' -- --all をしてから全部をpush -fする必要がある？ 381 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 18:02:11.12 .net] >>372 じゃあgitは不要だ。 382 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 23:47:25.44 .net] 最新安定バージョンのwheezyでも1.7.10なんだけどな 383 名前：デフォルトの名無しさん mailto:sage [2014/02/13(木) 23:49:44.46 .net] 無駄に用心深いdebianじゃどうしようもない、捨てろ 384 名前：デフォルトの名無しさん [2014/02/14(金) 00:06:06.24 .net] backportsに1.8.5.3あるじゃん 385 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 00:16:15.53 .net] >>377 フリーズしてから1年以上立つんじゃないか。 安定版は機能追加しないぞ? 386 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 05:41:16.11 .net] tortoiseGit1.8.7使っているんだけど、一度コードを変更してから前の状態に戻したら大抵は 変更無しとみなしてくれるんだけど、ちょくちょく変更ありのままになってどうしようもなくなる。 これってどうやったら巻き戻せるの？checkoutしてもresetしてもrevertしても戻せない。 結局面倒になって全部消してcloneしなおす感じになっているんだけどなんか納得いかないんだよな。 Subversionだとrevertするか一度消して取りなおせばokだったけどどうも思う様にいかん・・・。 387 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 06:09:27.03 .net] 馬鹿には無理 388 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 06:20:22.73 .net] デスマおつかれさまです。 さっさと寝たら？ 389 名前：デフォルトの名無しさん [2014/02/14(金) 11:06:14.85 .net] git config core.filemode false git config core.symlinks false ローカルでの変更全破棄 git checkout -- * 面倒なことが起きてる場合 git reset --hard origin/upstream_worktree 390 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 13:59:33.24 .net] >>384 ダメだった・・・ 391 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 19:26:59.57 .net] コミットの打ち消し ってなにをするんだろう どうなるのか実験するの怖い 392 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 19:54:17.77 .net] revertは、過去のコミットで追加した部分を削除する、新しいコミットを作るだけだよ あまり高度なことをやってるわけじゃないから revertしようとするコミットで追加した部分が既に変更されてたりするとコンフリクトする その場合は手作業でコンフリクト解消しないといけない 393 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 22:52:05.12 .net] git って差分じゃないのによくマージとかできるなと思う。 394 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:02:10.42 .net] gitは圧縮されたスナップショットだがsvnと違ってブランチ切りで大量のコピーは生み出さない 395 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:02:48.56 .net] メインのブランチがある。 そのブランチからの派生が二つあって それぞれブランチAとブランチB ブランチAは正しく作られテストもOK ブランチBも正しく作られテストもOK この二つのブランチをマージしてコンフリクトも起きないが マージされたブランチにバグが発生するってこと起こりえるよな？ なんでみんなそんなほいほいマージできるんだ？ 396 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:03:07.76 .net] 2つのファイルから差分情報を作るのと、 1つのファイルと差分情報からもう1つのファイルを再現するのと、 難度に違いがあるの？ 397 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:06:34.35 .net] >>390 そのためにレグレッションテストを用意しておくんじゃね？ ほいほいマージっていうけどなんの検証も保証も無しにほいほいやってる人はよっぽどの自信家なんだろう。 398 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:07:24.76 .net] プルリクエストをマージする権限のある人がちゃんと検証するもんじゃないの？ 399 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:08:23.67 .net] プルリクエストって・・なんで github 前提なんだよ 400 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:08:44.65 .net] 複数人で開発してる場合にはどちみちマージしなけりゃいけないんだから それを手作業でやるかツールでやるかの違いにしか過ぎない 401 名前：デフォルトの名無しさん mailto:sage [2014/02/14(金) 23:53:29.96 .net] マージかよ 402 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 00:19:15.38 .net] >>389 svnもコピーを作ってるわけじゃないぞ。ブランチ切っても変更したやつだけが 格納される。 ただローカルに落とすときに実体としてのファイルが必要になる。 svn copyとか処理自体はgitのブランチと同じですぐに終わる。 403 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 00:21:11.45 .net] gitのブランチ切りはすぐ終わるという謳い文句は一体何だったのか 404 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 00:27:19.10 .net] Gitのブランチ切りは管理してるファイルとか一切変更しないからマジはやいよ 405 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 00:54:23.16 .net] >>398 ブランチ切りは速いよ。切り替えは遅いこともある 406 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 01:07:59.97 .net] 簡単に切れちゃうからこんどは使い終わったブランチを消すべし消さないべし論争が 407 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 02:32:22.58 .net] 昔みたいに安定版と開発版みたいな2本のラインで無理なく開発出来るくらいの 開発スピードだったらsvnでも良かったんだけど、今だと無駄に並行開発して、 リリースもまちまちだったりするからsvnだと取り回しがしんどいって部分も 結構あるからなぁ。 408 名前：デフォルトの名無しさん [2014/02/15(土) 12:07:43.91 .net] 　　↓　　↓　　↓　　↓　　↓　　↓ kohada.2ch.net/test/read.cgi/prog/1190866177/816 409 名前：デフォルトの名無しさん mailto:sage [2014/02/15(土) 23:18:20.85 .net] >>401 保守するなら残す。しないなら、する必要ないなら削除する。 それがgitのブランチ運用じゃん？ マージ済みとかで開発の終わったブランチを残す理由って何だろ。 410 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 00:52:30.25 .net] >>404 テンポラ 411 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 02:08:55.31 .net] >>404 マージの仕方にもよると思うけど試行錯誤の跡が見えた方が履歴を追う時に 良いというのは考えられるけど・・・大抵は古い作業データなんぞ見ても意味ないし 殆ど理由は無いと思われ。なかなか物を捨てられずに整理できない人と同じじゃない？ 412 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 02:53:00.67 .net] 隠し状態に出来れば一番いいんだけどな そういう痒いところにはなかなか手が届かないな 413 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 03:15:36.94 .net] どこかに適当なリポジトリ作っといてpushすればいい それで手元からは消す 414 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 03:51:37.16 .net] 人間は消してもいい、という判断が適切にできるもんじゃないという思想が 根底にあるんじゃないのGitって。とにかくとにかく過去にやったことは極力 追えるようにしておきたい、というのがデフォ。 自分一人でやってることならそれでいいんだろうけどさ、多人数でやる以上 絶対はない、必ずさかのぼれるようにしておきたいという思想があるんだと思う。 415 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 08:45:19.90 .net] git svn cloneで、svnの同一階層のディレクトリから 一部のディレクトリについてだけcloneすることってできませんか? たとえばsvn側が以下のようなディレクトリ構成だとして DirAとDirBについての履歴だけいっしょにcloneしたい状況です。 　Dir 　 |-DirA 　 |-DirB 　 `-DirC git svn clone Dirしてしまうと 不要なDirC含めてすべての履歴がクローンされますけど DirCの差分は不要な場合、どうしたらいいでしょう? 416 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 10:02:21.18 .net] マージコミットの粒度がすごく荒いとブランチ消したくなくなる 417 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 11:25:23.06 .net] >>409 うーんどうだろ gitの場合は過去を改ざんする手段が割と豊富にあるし その気になったらなんでもさせる気構えなのがイヤだよ 418 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 12:30:51.95 .net] >>409 それはVCSの存在意義みたいなものだし… むしろgitは性善説に則って人間側の自由を重んじている感があるけどなあ VCSの中でもgitは何でも出来ちゃう部類だと思う 419 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 12:44:28.39 .net] マージするとき XX な時以外は fast-forward するな！とかみたいな 運用フローをプログラムレベルで保証するようなラッパーとかあったらいいのかもね。 github のプルリクエストみたいなのはうまくいってる例じゃないかなあ。 420 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 13:06:56.02 .net] >>406 バグ修正してる時に、なんでその変更したか読み取るのに必要。BTSと連携してるので特に。 421 名前：デフォルトの名無しさん mailto:sage [2014/02/16(日) 19:28:42.49 .net] >>415 それあるね 消されるとわからなくなる 消せないフラグがあるといいのかね

---

---

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

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