Git 20

1 名前：デフォルトの名無しさん mailto:age [2024/02/15(木) 09:50:09.07 ID:En27mXas0.net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git git-scm.com/ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 17 https://mevius.5ch.net/test/read.cgi/tech/1599016710/ Git 18 mevius.5ch.net/test/read.cgi/tech/1650651945/ Git 19 https://mevius.5ch.net/test/read.cgi/tech/1667720427/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 159 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:28:35.11 ID:nRxMArw0a.net] 双極性障害で、今が元気な期間で鬱に入ったら静かになるよ。 160 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:31:13.80 ID:sGQQlBSJ0.net] >>156 ブランチ使わねーとか、やっぱお前長文君だろ 開発どうなったんだ？ 自分のスレに帰れ、完成まで戻って来んな 161 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 12:55:13.36 ID:maUGvQsbM.net] 仮にパーミッション対応するにはどうしたらいいか、という生産的な議論はできんのか？ 162 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:04:16.91 ID:iBb8Uq0X0.net] >>157 > 用途ごとに複数のペンチや金槌を準備する ペンチや金槌ほど違いはないって事 ソフトウェア界隈でよく言われる、 「気に入らないからといってオレオレフレームワーク/ライブラリを作っても どうせ９割は同じコードになるのだから、(＝車輪の再開発でしかないので) 多少気に入らなくとも既存のフレームワーク/ライブラリを使え、その方が生産性が断然高い」が該当する 俺はGitを気に入らないが、かといって自分で作ったとしても９割は同じコードになるので、 わざわざ作り直すよりはそのまま使って、本来のアプリケーション開発に注力する方が全体的にマシ、ということ コマンドが糞の山だが、基本コマンド以外は使わなければいいだけではあるので その他てんこ盛りの機能も同様 まあ俺的にはタイプスタンプを保存して欲しいんですけどね 理由は一番分かりやすいから でもLinusは何か知らんがこれは絶対に認めないんだろうしね 163 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:15:59.11 ID:maUGvQsbM.net] gitも再発明だろ お前はひたすらやらない理由を考えるタイプ 164 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:17:40.15 ID:iBb8Uq0X0.net] >>161 Gitでやるなら>>93-100 Gitを改造する気なら、commit時に何かしらのメタファイル(的なもの)を自動コミットしてしまって、 その中にパーミッションを記録しておき、戻すときに使えばいいだけ まあ、やる気になればすぐ出来る問題だから、現時点で入ってないのは、 ・本気で要らないと思ってる ← Git信者の予想 ・まだブチ切れた奴が居ないだけ ← 俺の予想 ・何かしらの理由で、政治的に拒否している ← Linusならあり得る 最後のは、例の発言 > マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 > https://cpplover.blogspot.com/2013/05/linus-torvalsc.html なので、Git信者が喚き散らしてる「Gitをバックアップツールとして使わせない！！！」為に意図的にやってるってのは、 (半分ジョークだとしても、)Linusならあり得る 165 名前：デフォルトの名無しさん [2024/12/10(火) 13:21:33.43 ID:1EevVDftM.net] ファイルの中身の先頭にファイルそのものの属性情報を付けるという発想は、メインフレームなどの古い思想。 166 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 13:23:12.69 ID:0BGH+xex0.net] >>160 同意 長文君のスレ 日常の進捗履歴記録ツールWitBucket(仮称)検討中 https://mevius.5ch.net/test/read.cgi/tech/1668901194/ 167 名前：デフォルトの名無しさん [2024/12/10(火) 13:49:10.16 ID:yCEb4nkG0.net] ごっみばけっつ君来てるのか ばーじょん0.1でいいから早く成果物公開してや 168 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 14:56:53.30 ID:sGQQlBSJ0.net] 長文君は問題外なので放っておくとして unix 文化圏の KISS 原則というのは他の文化圏から来たやつには不思議でしょうがないんだろうな Keep It Simple Stupid 「単純で馬鹿なままにしておけ ＝ 余計なことはするな」 単純なものを組み合わせて何か複雑なものを作るのは簡単だけど、複雑なものを組み合わせるのは困難 お仕着せじゃなくて自分で工夫して何とかする人には元が単純であるほど良い 169 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 15:14:11.48 ID:r7RcD6Xd0.net] まあ使いやすくしたければ自分でツール作れば良いだけの話なのに何で作らないの？ 必要なら作った方が効率がいいと思うんだけど。 170 名前：デフォルトの名無しさん [2024/12/10(火) 16:47:08.21 ID:IViAh4+E0.net] 元の質問者だけど、質問はただ出来るのかどうか聞いてただけなんだけどなあ こうなって欲しいとかあるべきとか別に何とも思ってないんだが、なんで勝手に仮定してそんなに膨らませるんだろw あとバックアップがどうのって言ってる人が最初の方からちらほらいるけど、バックアップの話ってどこから出してきたんだ? 誰もそんな話しとらんよね 171 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 17:00:49.95 ID:nRxMArw0a.net] Gitのことは嫌いでも、Linusのことは嫌いにならないでください！！ 172 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 18:03:32.07 ID:6HlM5sdR0.net] >>170 読んだら分かると思うけどこのスレには「git は初心者向けのバックアップ・ツールであるべき」というのが持論の変なやつが一人居着いていて定期的に湧くんだ そして、ちょっとでもバックアップぽい使い方をしてるやつや初心者っぽい質問があると持論の補強に使おうとする で、他の人がそれに反論したり予防するのが日常風景になってる 関係なければ軽く無視しても大丈夫だよ 173 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 18:45:20.68 ID:iBb8Uq0X0.net] >>168 GitはKISSとは真逆だけどな >>170 手動でスクリプト書いてパーミッションを保存する気なのに、自分が使いたい機能と認識出来ないのは知障だろ >>171 いやLinusの発言内容は大体同意だし、(163に挙げた物含めて) ズバズバ言うところも割と俺は好きだけどな もちろん会った事も話した事もないが ただGitはなぁ…OSSの中でもここまで仕様がグダグダなのは存在しない 仕様を詰めるのは時間の無駄だ、として嫌う奴はいるが、大体そいつらはプログラミング初心者で、 Linusがこの辺理解出来無いとも思えないので、意図的に放置してる気もする 結果的にVCS界のmulticsになってるので、いつかunixが生まれる ただまあ、使う分にはコマンドが多すぎても大して困らないんだよ、使わなければいいだけだから しかしメンテするとなると、本来は全部のコマンドが正しく動く事をチェックしないといけないので、肥大化すると無理になってくる Gitはこの辺、自動テストもする気無く、動かなければ動きませんね、文句があるならお前が直せ、でやってるように見える また、勿論OSSなのでプロプライエタリと比べれば限界点は10～100倍上であり、 行けるところまで行ってしまえ、限界点のテストだ、という風にも取れる この辺の思想が俺には合わないね、まあ他も多々あるが だから、俺が参戦するとしたら、Gitではなく、unixを作る側だよ 174 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 21:54:47.54 ID:KgYOToHf0.net] そんなにGitが嫌なら使わなければいいのでは？ 誰もお前にGit使えなんて言ってないでしょ 175 名前：デフォルトの名無しさん mailto:sage [2024/12/10(火) 23:14:48.26 ID:cIogiqHs0.net] ゴミバケツ君また自分でVCS作る話してる。 前のはどうなったのか。 176 名前：デフォルトの名無しさん [2024/12/11(水) 01:32:29.88 ID:bYjfV/I80.net] バージョン管理システムを変更履歴システムだと思い込んでいる人間は多いよなあ。 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。 177 名前：デフォルトの名無しさん [2024/12/11(水) 01:35:22.67 ID:bYjfV/I80.net] Linuxは開発者の質が低いんだよ カーネルに次々と新しいバグを追加する だからLinuxを採用するとカーネルを独自に直すという作業が必要になる 178 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 01:50:58.96 ID:Y83IEE6u0.net] このスレ痛いやつ多いのな ↑とか 179 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 08:49:43.35 ID:bZvW/lze0.net] >>176 > 変更履歴用ならどこがどう変わったのかを表示する機能がないことに疑問を持たないのだろうか。 それはdiffで十分だし、しかもGitの場合はdiffを内包してしまってる（俺はこれにも反対) だから不満があるとするならバイナリか？(Excel等を含む) 勿論これは対応してないだけだし、 また、対応するにしても、Gitが直接差分を出す「モノリシック」ではなく、 「プラグイン」で各社が自社アプリ用の差分出力ツールを供給出来る形態にするのが正しい VCSから各種diffを直接出力すべきと考えるのは間違いだと思うぜ >>177 そうだとしてもLinux以外にないわけだが、 > カーネルに次々と新しいバグを追加する これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと 従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから そして(文句あるかもしれんが)カーネル開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、 同じ事をGitでやったからあの「ぼくがおもいついたすごいこまんど」の山になったのだと思う 交通整理すらやる気無かったわけだ とはいえ、「使われなくなったコマンドは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、 Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ 厳選されてるように思えるunixコマンドだって、レイヤーが1つ違うだけで同じライフゲーム状態だし 180 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 09:57:22.36 ID:34XO7K6O0.net] お前よりAIのほうが賢いんじゃね？ https://i.imgur.com/V1cME8T.png 181 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:19:18.72 ID:+nAxu/ku0.net] git を始めとして最近のVCSは著者(author)とか承認者(commiter)とかの由来を管理するけど、所有者(owner)とか所属グループ(group)とかの現状は管理しない 管理の粒度もファイル単位ではなくて変更点単位 「バックアップ」という言葉の使い方次第だが次元の違うものを管理してるというのは最低限の事前知識 182 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:25:55.27 ID:JMogi+gN0.net] GitHubを容量無制限のファイルバックアップ置き場として紹介しているサイトもあるけどな 183 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 12:45:40.19 ID:kPp0f2Rs0.net] >>162 タイムスタンプがそうなっている理由はプログラマならわかるかと。 makeとかのビルドシステムがファイル更新をタイムスタンプで判定しているんだから、gitが書き換えるごとにタイムスタンプが新しくなるのはビルドシステムを考慮したら当然の話。 タイムスタンプを勝手に書き戻したら再現困難なバグになるから、採用は無いだろうね。 184 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 13:21:42.72 ID:JMogi+gN0.net] 自分もタイムスタンプは戻してほしい派 その手のビルドツールって、なんで「タイムスタンプが古くなってても更新扱い」にしてくれないの？ 185 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 13:29:52.53 ID:+nAxu/ku0.net] 1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？ そのタイムスタンプ更新の著作権は誰に所属するの？ コミッタはそれを確認して承認作業するの？ 古いパッチの再利用したら日付が昔に戻るの？ ブランチ統合したらどっちの日付が採用されるの？ アホらし過ぎる議論 ファイルのバックアップは別に取れ 186 名前：デフォルトの名無しさん [2024/12/11(水) 17:38:01.33 ID:HXU8Fpor0.net] >>170 今話してるのは質問がGitをバックアップに使ってると勘違いしてる人たちだから無視していいよ 他の人は>>100でやりとりが終わってると分かってる 187 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 18:37:28.10 ID:bZvW/lze0.net] >>180 それは「現時点でもGitはバックアップツールとして十分使えます」と言ってるんだがお前はそれで良いのか？ >>183-184 つ make distclean >>185 回答を期待してるわけではないだろうが、俺が今思いついた範囲なら、 1バイトも更新せずにタイムスタンプだけ更新したら、それも記録すんの？→古い日付のファイルに戻してからcommitしろ(或いは「内容が同一のファイルは非更新扱いにする」オプションをcommitコマンドに追加するからそれを使え) そのタイムスタンプ更新の著作権は誰に所属するの？→上記なので関係なし コミッタはそれを確認して承認作業するの？→同上 古いパッチの再利用したら日付が昔に戻るの？→パッチを当てた日になる、つまり戻らない ブランチ統合したらどっちの日付が採用されるの？→マージ時に変更されたファイルはマージした日付になる これで別段大して問題ない気がするが まあ日付を保存する事について技術的問題はないと思うけど Linusがわざわざ外したんだから、政治的な問題はあって、採用はされないんだろうけどさ (全世界からメール等で連絡受けてたLinusは、テメエのローカルタイムなんて知るか！！！とブチ切れ、 タイプスタンプでの連絡が出来ないように作ったと予想) が、多分根本は、形式主義者か現実主義者か、といったところか 形式主義者： GitはVCSであり、それ以外の使い方をしてはならない 現実主義者： 機能が揃ってればラベルがどうであれ使う 　つまりGitもバックアップツールとして使えるし、 　GitHubは容量無制限のファイル置き場だし、 　git clone GitHubのURL: が現状一番簡単なデプロイ方法であるので、Gitはデプロイツールでもある 　(ただし目的外流用だから色々機能が揃ってないが、それでも他ツールよりマシなら使うだけ) 188 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 19:28:51.98 ID:kPp0f2Rs0.net] >>187 開発者に「俺達の利便性のために、お前らはチェックアウトするごとに手動でcleanして一からビルドしろ」と言ったらさすがに傲慢かと。 gitはプログラム開発者がソースコード管理のために用意したツールだから、開発者にとって百害あって一利無しの機能が入ることは無いんじゃないんかね。 189 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 20:38:24.90 ID:WFtEMDpk0.net] >>183 Subversionには、ファイルのタイムスタンプをコミット日時にする設定はあるけどな もちろん、makeを使うような人には危険な機能だが、それなりの要望はあったのだろう 190 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 20:46:11.17 ID:bZvW/lze0.net] >>188 それはお前が傲慢すぎ 元々makeはインクリメンタルビルドの為のツールで、 Git以前からC界隈ではほぼ100%使われてたし、勿論Linusも使ってたはず make clean; make distclean; は常識であり、知らない奴は死ねレベル ただし通常はそもそも clean する必要がない clean はだいたい rm *o だが、そもそも中間ファイル(*.o)は tar ボールには入ってないので、自分で make しない限り存在しない だから「同一ディレクトリで『再度』makeしなおす」前に make clean であって、初回はやる必要がない つまり「何度もビルドし直す」実際の開発者向けの機能であり 「ソースをダウンロードして一回ビルド成功したら終わり」のユーザーはどのみち clean なんてやる必要がないし、知らなくていい これがGitの普及で毎回全部リビルドがデフォになっており、 君のように勘違いしてたり、あるいは makefile 内の clean が機能しなくなってる(メンテされてない)、という可能性はある 或いは、この辺の行き違いがLinuxで相当数発生し、『常に全部リビルド』するようにLinusが作った、という可能性もある (Linus発言見てる限りは「タイムスタンプじゃなくてちゃんとコメント書けやボケ！」のように感じるが) ただまあ、どのみちお前らのような、現状のGitに満足してる連中にはどうでもいい事だし、 俺ならタイプスタンプは戻すし、Gitにはコミットせずにフォークして勝手に作る 勿論気に入らなければ使うな、タイムスタンプ戻したければ勝手に使えだし ただお前ら、繰り返すが > それを思いついたやつは今までいない (126) とか考えるのがとにかく傲慢すぎるんだよ 自分以外は超絶馬鹿としか思ってない奴しかこんな発言はできない 実際には、考えた上で、違う選択になってる 「タイムスタンプも保存した方がいいのでは」という提案を、これまで世界で誰も思いつかなかった、なんて事はあり得ない Linus自身も最初から分かってて、敢えて落としてるんだよ で、本来は、その落とした理由が分からないと地雷を踏むだけなので確認すべきなんだけども、 Git信者共はポジショントークを繰り返すだけでクソ使えねえ、 まあどのみちrejectされるのは分かり切ってるのでやるならフォークしかない、といったところ 191 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 21:17:41.31 ID:+nAxu/ku0.net] 何も分かってないやつがいて草 タイムスタンプは過去には戻らない未来に進むだけ、という前提で多くのツールが設計されてる make もそう この前提を壊さないように配慮することが大原則で git のみならず unix 系のツールは設計されてる バックアップからの復元はこの前提を壊して過去に時間を戻す行為なので特別な時にのみ使うもの 192 名前：デフォルトの名無しさん mailto:sage [2024/12/11(水) 21:35:45.41 ID:bZvW/lze0.net] >>191 zipやtarは普通にタイムスタンプは保存されるだろ その延長で考えるなら、保存された方が自然だし有用だ、というだけ ただまあ、これも合意する必要はない フォークしてどちらがウケるかで決するフォーク主義が正しいし、ユーザーは好きな方使えば済むだけ (現実的にはcp -p と同様にオプションで切り替えるのが普通で、 逆に言えばオプションすら存在しないGitは何らかの「意図」をもってそうしてるとも言える 理由は今のところ不明なので思いつく人はよろしく) まあ心配せずとも、Linuxカーネルにコミットしてくる連中で、make clean を知らない奴なんて一人もいないよ (だから多分問題はここではない) 193 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 00:21:35.10 ID:C7R5gozk0.net] git pull した後に make clean とか git 使ったことないのが丸わかりだな 何のための make だよ？ 194 名前：デフォルトの名無しさん [2024/12/12(木) 01:11:52.06 ID:2Npzz1EV0.net] 負け組のためのだろ 195 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 08:57:54.12 ID:yWChnlb80.net] >>190 「俺はタイムスタンプの管理をgitでやりたいから、お前らはチェックアウトするごとにmake dustclean しろ」と言ったら、温厚になったLinusでもさすがに罵倒するかと。 gitはLinusがlinuxのソースコードを管理するために作ったツール。今もメインユーザーはLinux開発者で想定利用シーンもLinux開発なんだから、「Linux開発者の足を引っ張る機能」を追加するのはディレクターの正気を疑うレベルですな。 196 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 09:15:02.60 ID:C7R5gozk0.net] >>195 いや linux とか Linus とかもはや関係なく全プログラマー大爆笑案件だろ git pull で同期したら日付が過去に戻りましたとか全員が git の使用やめるレベル 197 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 09:16:55.48 ID:OOlmzVQX0.net] https://stackoverflow.com/questions/1964470/whats-the-equivalent-of-subversions-use-commit-times-for-git PythonやPerlを使う人には、makeのためにタイムスタンプが失われるのはいい迷惑だと言われてるな 今さらリポジトリにメタデータを埋め込むのは難しいにしても、 gitconfigで>>189くらいさせてくれてもいいのにとは思う 198 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 15:16:51.62 ID:d+ZuY6W00.net] >>197 当然だが既に同じことを考えてパッチしてた奴が居たか > Linus' rationale of timestamps being harmful just because it "confuses make" is lame: 189に書いたようにこれはないと思ってたが、マジだったとは makeで問題になる場合って、 makeした同じディレクトリでより古いバージョンでソースを上書きしてcleanせずにmakeした場合、 に限られるのでLinus以外はほぼやらねえし、Linusがmakeの使い方知らんわけねえし、ねえわと思ってたが、 自分専用ツールだからカスタマイズ済みの感じか とはいえ謎の地雷があるわけではなさそうというのは分かった、ありがとう 普通に考えれば、保存した上で戻す際にオプションで選べるようにしておけばいいだけなのだがな この辺Gitは無駄に押し付けがましいのが意識高い系と被るし、 だからこそ連中とも親和性が高く、このスレにもそういう奴が多いのだろうけど 用途は考え方の違いで、(俺がそういう使い方をするわけではないが) cron に commit させとけば、VCSはバックアップツールとしても使えて、 偶に過去バージョンにパッチ当てる際は branch すればいいのだから、 一本線しか許されないバックアップツールよりはソースコードのバックアップには向いているというだけ ただHgなら保存されるのか？なら俺はそれでもいいんだが (料理の腕前で勝負してるのに、整理棚に必要以上にこだわっても本末転倒) 199 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 15:21:09.29 ID:JM/xCx8/0.net] 料理の腕前で勝負してるつもりならさっさとWitBucketとやらを作れよ 200 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 16:33:59.70 ID:d0NKDmelM.net] >>198 ChatGPTで3行に縮めて投稿しろ 201 名前：デフォルトの名無しさん mailto:sage [2024/12/12(木) 18:58:50.56 ID:yWChnlb80.net] >>198 >Linus以外はほぼやらねえし、 「gitはLinusがLinux開発で使うために作った」という大前提を忘れるのはアルツハイマー病の一種かしらん？ 202 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 10:34:37.92 ID:mefXJp+A0.net] Gitの使い方というかSourcetreeの使い方というか質問があります とある1コミットに複数ファイルがあって複数個所に変更がまたがってて 別ブランチにそのコミットの1ファイルの1部分だけをマージしたいです その場合はチェリーピックは使えないので1部分のHunkをステージングに移動して コミットするという方法が素直なマージ方法でしょうか？ 203 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 11:43:48.24 ID:kPFQFgKW0.net] >>202 採用元が push 後とか他人のコードだとそんな感じかな 私だと cherry-pick してから巻き戻し修正するけど、複数パッチなら rebase -i で edit を使う 採用元がローカルにしかない push 前なら元のコミットを分割しておくのが良い方法だろう 将来的に再利用するときにも別々に利用する可能性があるものは、今のうちに別パッチに分割しておくのが賢いと思う 204 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 11:54:03.74 ID:mefXJp+A0.net] >>203 回答ありがとうございます まさに他人がプッシュしたものを派生ブランチにも適用させようとしています その中に特定ブランチの対応分も混ぜてしまっていたため どう対応すべきか質問した次第です コミット分割は癖にしておきたいと思います 205 名前：デフォルトの名無しさん mailto:sage [2024/12/14(土) 14:22:21.70 ID:jFwYZGRF0.net] ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな 206 名前：デフォルトの名無しさん [2024/12/14(土) 19:07:11.21 ID:cLbKsfdN0.net] >>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった 7bは置いとくとしても100レスも使ってこの体たらくとは情けない 207 名前：デフォルトの名無しさん [2024/12/15(日) 22:01:21.97 ID:D9xraIFr0.net] >>179 diffでわざわざ比較するというのは時間の無駄 208 名前：デフォルトの名無しさん mailto:sage [2024/12/15(日) 22:49:45.11 ID:9FCwcKO70.net] >>207 相手にすんな バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので 209 名前：デフォルトの名無しさん mailto:sage [2024/12/15(日) 23:49:43.28 ID:UElXL8/K0.net] >>204 コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題 210 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 00:02:22.98 ID:I9YsDANU0.net] 不毛っていうのも程度問題でしょ 経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある hot−fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる 211 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:28:18.00 ID:UeL/Eu4T0.net] cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？ 212 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:38:05.37 ID:ZibPg38H0.net] 同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ 特にブランチ切るまでもない単純な修正の場合とか 要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ 213 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:42:21.10 ID:UeL/Eu4T0.net] せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？ 214 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 12:53:45.68 ID:ZibPg38H0.net] >>213 cherry-pick はブランチ切るまでもない修正用だよ コミット1個ならどこから cherry-pick したか分かれば良いだけだし 215 名前：デフォルトの名無しさん [2024/12/16(月) 13:11:10.31 ID:56LO+jCc0.net] 今度はチェリーピックでやり合いか 216 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 13:17:14.68 ID:I9YsDANU0.net] 将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる 程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う hotfixが必要ない現場なら必要になる機会は少ないだろうな 217 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 13:41:54.88 ID:ZibPg38H0.net] cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利 ・最新版から過去リリースへのバックポート ・セキュリティなどの hotfix の適用 ・テスト用の addhoc 修正版（正式なマージは今ではない ・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない など多数 「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ 218 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 15:08:47.67 ID:/03Ox5VG0.net] cherry-pickって言葉のニュアンスの通り 219 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 16:03:21.23 ID:ZibPg38H0.net] git の rebase と cherry-pick は同じ概念なので rebase とか使わない派閥のやつは cherry-pick も使わないだろうなあ cherry-pick はブランチ切って rebase してブランチを消すを一発でやってくれるコマンド 正確には rebase の方が cherry-pick を繰り返した後にブランチ位置をそっちに切り替える機能というべきだけど 要はブランチを使うか使わないかの違い 220 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 22:52:09.15 ID:m/ncuAnJ0.net] すみません、チェリーピックに関して質問した者ですが 追加で質問よろしいでしょうか？ 本流ブランチAから子ブランチBが作成されて 子ブランチBから一時的に孫ブランチCが作成されました ブランチCで修正した一部コミットだけブランチBにチェリーピックしてマージして 他のコミットは無駄なのでブランチCがもはや不要となりました 孫ブランチCを削除してもブランチBにチェリーピックした内容は 削除される（元に戻される）ことはない認識で合っているでしょうか？ 221 名前：デフォルトの名無しさん mailto:sage [2024/12/16(月) 22:58:16.88 ID:m/ncuAnJ0.net] コミットの独立性が保たれているためチェリーピック元のブランチを 削除しても問題ないと認識しています 222 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 00:55:20.81 ID:Np7JyJBV0.net] >>220 削除されないから大丈夫 まず第一に、残ったブランチやタグのいずれかから到達可能なコミットは生存し続ける 第二に、cherry-pickによって作られたコミットはマージと違って元のコミットとは別物の複製体になるので原本がどうなろうと知ったこっちゃない 223 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 07:53:20.59 ID:n6Rf+SXX0.net] >>222 ありがとうございます Sourcetree独自の機能か分かりませんが チェリーピック元のコミットIDをコメントに付与しているため もう辿ることもないコミットならコメントから余計な情報は 省いた方がよさそうですね 224 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 09:46:53.70 ID:Np7JyJBV0.net] >>223 それは git cherry-pick -x で付く情報だと思う 公開されないコミットへの参照は残さないほうがいいね 225 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 12:10:27.20 ID:Mk8ZrsM80.net] 残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね 226 名前：デフォルトの名無しさん [2024/12/17(火) 13:07:22.36 ID:bMW/7Xg20.net] チェリーピックって童貞狩りじゃねえのか？ 227 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 13:48:26.81 ID:8t1OBzHLM.net] つまんな 228 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 14:02:58.22 ID:Mk8ZrsM80.net] cherry pick 1. 都合の良いものだけを (恣意的に) 選び出す 2. 慎重に必要なものを選別する 2. 好きなもののみを摘み食いする 4. バーゲン品から掘り出しものを漁る 5. 木から熟したサクランボだけをもぎ取る 5が本来の使われ方、1の意味で使われることが多い 229 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 22:22:58.48 ID:uhdhcEFf0.net] コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、 この機能を使っても作業フォルダの内容は変化しないので、 一緒にコミットするべきだったところを入れ忘れてしまい、 プルしても正しく動かない状態のものを上げてしまっていたということがあります この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？ 230 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:11:14.06 ID:Np7JyJBV0.net] >>229 一発勝負っていう感覚はおかしいでしょう 一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある 危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない 分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい 231 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:14:08.08 ID:QjcMYSDT0.net] >>229 複数のコミットで一つの修正になるならrebase してまとめたら？ 232 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:25:32.69 ID:Np7JyJBV0.net] >>229 問に回答してなかった ステージングの機能を使いこなしているかはNoです 差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない 233 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:33:17.82 ID:Mk8ZrsM80.net] >>230 git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ） あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ 234 名前：デフォルトの名無しさん mailto:sage [2024/12/17(火) 23:34:08.72 ID:Mk8ZrsM80.net] >>233 アンカミス >>229 あて 235 名前：デフォルトの名無しさん mailto:age [2024/12/18(水) 09:25:32.99 ID:IhQ3pKwU0.net] Git v2.48.0-rc0 236 名前：デフォルトの名無しさん mailto:sage [2024/12/18(水) 11:41:14.09 ID:pGa0ZLUBM.net] >>229 もうでてるけど いれないものはstashして動確してcommit stagingの存在理由わかってくる 237 名前：デフォルトの名無しさん mailto:sage [2024/12/19(木) 21:05:36.88 ID:KU+lpcLj0.net] >>219 言うほど同じか？ rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化 そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが 238 名前：デフォルトの名無しさん [2024/12/19(木) 21:38:31.24 ID:QSrQ7dPA0.net] やってることの内容は似てるけど用途が全然違うからなあ かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが チェリーピックとなると淡々とした説明で真顔だよ 239 名前：デフォルトの名無しさん mailto:sage [2024/12/19(木) 23:45:56.41 ID:b251oEg00.net] >>237 目的じゃなくて動き(実装)の話 rebase で cherry-pick できるし cherry-pick で rebase できる どっちもコミットの再利用(付け先の変更)を目的とするコマンド あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない 240 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 01:21:38.28 ID:+bubGwJY0.net] リポジトリを分けるか、モノでやるか 統合度合いが微妙な場合にものすごく悩む 241 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 09:56:06.03 ID:PANCPXf30.net] そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。 成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。 242 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 11:20:48.46 ID:Vt9p1L/d0.net] >>240 一般論にはメンバーで分けるとうまくいく事が多い 将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、 対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく 243 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 12:26:56.43 ID:PANCPXf30.net] 「うまくいく」の定義によるかなあ 分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>242に同意するが、 個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない 巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより もっと大きな視点で恣意的に判断すべきことかと思う そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい 244 名前：デフォルトの名無しさん mailto:sage [2024/12/20(金) 12:53:34.97 ID:Vt9p1L/d0.net] >>243 ・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる ・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある という一般原則による、悩んだ時は原則に従うのがたいてい正しい 245 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 08:12:17.24 ID:/IqCjkFy0.net] >>244 同様に、下記も言える - 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい 世の中そんなに単純じゃないんだわ 246 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 10:33:21.60 ID:Hifil6s+0.net] >>245 俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ まあ頑張れ 247 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 11:20:34.07 ID:w/Sbt61U0.net] >>246 誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な 一般論として、集中管理は密結合を、分散管理は重複を招く 共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい 一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ 248 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 12:43:49.34 ID:Hifil6s+0.net] >>247 一般論だけどコードの共通化は難しくない というのは必須ではないし時間の制限がないから バラバラのまま結合して共通化できるところから時間をかけてゆっくり丁寧に共通部品に切り替えていけば良い linux kernel とか部品の共通化に3年とか5年とかかけてゆっくりやってることも多い、共通化しないこともある （手間だけの問題と技術的難易度の問題という本質的な部分の優先度を分けて考えると理解できると思うよ） 249 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 14:07:45.37 ID:w/Sbt61U0.net] うーん、難しいと感じるかどうかはあなたの感性の問題だから、比較対象と根拠を示してね 250 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 17:31:11.06 ID:Hifil6s+0.net] >>249 感性の議論はしてないよ、お前がそう思ってるだけ 技術的にすぐに必要なものもと、条件によって無くてもすむし後回しにもできるものとを同次元で語るなって指摘なだけ （後回しにして良いなら簡単、やらなくて済むのが一番簡単、という当たり前の指摘、感性の余地とかない） 251 名前：デフォルトの名無しさん mailto:sage [2024/12/21(土) 18:23:30.51 ID:Bjr5M2i00.net] >>250 読み返してみたけど>>245のツッコミがまとも お前は自分の意見が一般的と言い張ってるだけ 252 名前：デフォルトの名無しさん mailto:sage [2024/12/22(日) 11:25:46.33 ID:KQFeVRO70.net] >>230-236 みなさんご意見どうもです SVNを使っていた頃や、ステージングを使ってみる前は、 変更ファイルをいったんどこかに逃がして、作業フォルダを綺麗な状態に戻して、 今回コミットしたいところだけくっつけ直して、動作確認できたらそれらをすべてコミットして、 逃がしておいたものを元の場所に戻して作業再開、みたいな操作をしてました 結局プッシュする前にステージングし忘れなどを確認する必要があるとなると、 コミット時に確実に確認できる上記の方法もそんなに悪くはないってことですかね 253 名前：デフォルトの名無しさん mailto:sage [2024/12/22(日) 14:58:34.96 ID:1vLY5nWA0.net] >>252 それで良いんじゃないかな？ 私だと2つに分けたのを両方先にコミットしておいて、両方別々にチェックアウトしてテストを走らせるけど 問題があれば巻き戻してやり直し 問題がなけば push push 前ならローカルでいくらでもやり直しが効くのが git の利点なので個人的に分かりやすいやり方でやれば良い 慣れたらテストの自動化とか検討すると捗る 254 名前：デフォルトの名無しさん mailto:age [2025/01/01(水) 05:03:32.91 ID:RPjVgyjf0.net] Git v2.48.0-rc1 255 名前：デフォルトの名無しさん mailto:age [2025/01/07(火) 09:45:36.95 ID:DbV6+6Xe0.net] Git v2.48.0-rc2 256 名前：デフォルトの名無しさん mailto:age [2025/01/11(土) 11:00:17.95 ID:tzzUwbv+0.net] Git v2.48.0 257 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 11:20:09.87 ID:L3maUoeD0.net] サル先生でGitの学習を始めました そこで質問です！ 下記コマンドの中に dewfr という記述が存在するのですが、これは何を意味するのでしょうか？ > git config --global core.editor "\"[使用するエディタのパス]\""dewfr 参照：https://backlog.com/ja/git-tutorial/intro/06/ 258 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 12:11:34.88 ID:hjmuezNa0.net] 先生が個人的に使っているエディタのファイル名なのでは？ 直前がパス区切り文字で終わってるし 259 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 12:24:19.20 ID:L3maUoeD0.net] あ〜なるほど！謎が解けました！ ありがとうございます！

---

---

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

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