Git 20 (530ﾚｽ)
Git 20 http://mevius.5ch.net/test/read.cgi/tech/1707958209/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
217: デフォルトの名無しさん (ﾜｯﾁｮｲ 662c-1w4P) [sage] 2024/12/16(月) 15:08:47.67 ID:/03Ox5VG0 cherry-pickって言葉のニュアンスの通り http://mevius.5ch.net/test/read.cgi/tech/1707958209/217
218: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/16(月) 16:03:21.23 ID:ZibPg38H0 git の rebase と cherry-pick は同じ概念なので rebase とか使わない派閥のやつは cherry-pick も使わないだろうなあ cherry-pick はブランチ切って rebase してブランチを消すを一発でやってくれるコマンド 正確には rebase の方が cherry-pick を繰り返した後にブランチ位置をそっちに切り替える機能というべきだけど 要はブランチを使うか使わないかの違い http://mevius.5ch.net/test/read.cgi/tech/1707958209/218
219: デフォルトの名無しさん (ﾜｯﾁｮｲ be10-aNNs) [sage] 2024/12/16(月) 22:52:09.15 ID:m/ncuAnJ0 すみません、チェリーピックに関して質問した者ですが 追加で質問よろしいでしょうか？ 本流ブランチAから子ブランチBが作成されて 子ブランチBから一時的に孫ブランチCが作成されました ブランチCで修正した一部コミットだけブランチBにチェリーピックしてマージして 他のコミットは無駄なのでブランチCがもはや不要となりました 孫ブランチCを削除してもブランチBにチェリーピックした内容は 削除される（元に戻される）ことはない認識で合っているでしょうか？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/219
220: デフォルトの名無しさん (ﾜｯﾁｮｲ be10-aNNs) [sage] 2024/12/16(月) 22:58:16.88 ID:m/ncuAnJ0 コミットの独立性が保たれているためチェリーピック元のブランチを 削除しても問題ないと認識しています http://mevius.5ch.net/test/read.cgi/tech/1707958209/220
221: デフォルトの名無しさん (ﾜｯﾁｮｲ ea5b-Hfw5) [sage] 2024/12/17(火) 00:55:20.81 ID:Np7JyJBV0 >>219 削除されないから大丈夫 まず第一に、残ったブランチやタグのいずれかから到達可能なコミットは生存し続ける 第二に、cherry-pickによって作られたコミットはマージと違って元のコミットとは別物の複製体になるので原本がどうなろうと知ったこっちゃない http://mevius.5ch.net/test/read.cgi/tech/1707958209/221
222: デフォルトの名無しさん (ﾜｯﾁｮｲ be10-aNNs) [sage] 2024/12/17(火) 07:53:20.59 ID:n6Rf+SXX0 >>221 ありがとうございます Sourcetree独自の機能か分かりませんが チェリーピック元のコミットIDをコメントに付与しているため もう辿ることもないコミットならコメントから余計な情報は 省いた方がよさそうですね http://mevius.5ch.net/test/read.cgi/tech/1707958209/222
223: デフォルトの名無しさん (ﾜｯﾁｮｲ ea5b-Hfw5) [sage] 2024/12/17(火) 09:46:53.70 ID:Np7JyJBV0 >>222 それは git cherry-pick -x で付く情報だと思う 公開されないコミットへの参照は残さないほうがいいね http://mevius.5ch.net/test/read.cgi/tech/1707958209/223
224: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/17(火) 12:10:27.20 ID:Mk8ZrsM80 残ってても邪魔にはならないだろうけど cherry-pick 元がすぐ消える予定なら、付けないのが普通ですね http://mevius.5ch.net/test/read.cgi/tech/1707958209/224
225: デフォルトの名無しさん (ﾜｯﾁｮｲ 8fb9-/rN0) [] 2024/12/17(火) 13:07:22.36 ID:bMW/7Xg20 チェリーピックって童貞狩りじゃねえのか？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/225
226: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8a-1w4P) [sage] 2024/12/17(火) 13:48:26.81 ID:8t1OBzHLM つまんな http://mevius.5ch.net/test/read.cgi/tech/1707958209/226
227: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/17(火) 14:02:58.22 ID:Mk8ZrsM80 cherry pick 1. 都合の良いものだけを (恣意的に) 選び出す 2. 慎重に必要なものを選別する 2. 好きなもののみを摘み食いする 4. バーゲン品から掘り出しものを漁る 5. 木から熟したサクランボだけをもぎ取る 5が本来の使われ方、1の意味で使われることが多い http://mevius.5ch.net/test/read.cgi/tech/1707958209/227
228: デフォルトの名無しさん (ﾜｯﾁｮｲ 8f2d-iztn) [sage] 2024/12/17(火) 22:22:58.48 ID:uhdhcEFf0 コミットする内容を複数に分けたい場合、必要な部分だけステージングすると読んだのですが、 この機能を使っても作業フォルダの内容は変化しないので、 一緒にコミットするべきだったところを入れ忘れてしまい、 プルしても正しく動かない状態のものを上げてしまっていたということがあります この一発勝負みたいなステージングの機能をみんな使いこなしているのでしょうか？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/228
229: デフォルトの名無しさん (ﾜｯﾁｮｲ ea1e-Hfw5) [sage] 2024/12/17(火) 23:11:14.06 ID:Np7JyJBV0 >>228 一発勝負っていう感覚はおかしいでしょう 一度ステージングした後やコミットした後でプッシュするまでもいくらでも再確認とやり直しのチャンスがある 危うい操作をしたのに十分に確認していない内容をプッシュしてしまう習慣のほうがどちらかというと諸悪の根源だと思う SVNだってローカルの変更を部分的にコミットしようと思えば同じようなリスクがあるので、ステージングという考え方自体のリスクではない 分割してコミットはビルドの通らないコミットを作ってしまうリスクは増すから不慣れで自信のないオペレーションになったときはstashやswitchを活用して疎通確認しておくとか、要らん変更と意図的に残した変更と漏れた変更を混同しないようにassume-unchangedやskip-worktreeなんかを活用してもいい http://mevius.5ch.net/test/read.cgi/tech/1707958209/229
230: デフォルトの名無しさん (ﾜｯﾁｮｲ 231b-3k2I) [sage] 2024/12/17(火) 23:14:08.08 ID:QjcMYSDT0 >>228 複数のコミットで一つの修正になるならrebase してまとめたら？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/230
231: デフォルトの名無しさん (ﾜｯﾁｮｲ ea1e-Hfw5) [sage] 2024/12/17(火) 23:25:32.69 ID:Np7JyJBV0 >>228 問に回答してなかった ステージングの機能を使いこなしているかはNoです 差分確認からコミットまでの流れはGUIのほうが好きなのでステージングは全然活用できてない http://mevius.5ch.net/test/read.cgi/tech/1707958209/231
232: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/17(火) 23:33:17.82 ID:Mk8ZrsM80 >>229 git status とかを頻繁に打つくせをつけた方が良いぞ、それでコミットし忘れ防げる（ついでによく使うオプションは alias にするとさらに良いぞ） あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ http://mevius.5ch.net/test/read.cgi/tech/1707958209/232
233: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-f1VN) [sage] 2024/12/17(火) 23:34:08.72 ID:Mk8ZrsM80 >>232 アンカミス >>228 あて http://mevius.5ch.net/test/read.cgi/tech/1707958209/233
234: デフォルトの名無しさん (ﾜｯﾁｮｲ 0b49-7GPw) [age] 2024/12/18(水) 09:25:32.99 ID:IhQ3pKwU0 Git v2.48.0-rc0 http://mevius.5ch.net/test/read.cgi/tech/1707958209/234
235: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMd6-1w4P) [sage] 2024/12/18(水) 11:41:14.09 ID:pGa0ZLUBM >>228 もうでてるけど いれないものはstashして動確してcommit stagingの存在理由わかってくる http://mevius.5ch.net/test/read.cgi/tech/1707958209/235
236: デフォルトの名無しさん (ﾜｯﾁｮｲ 2ef8-Nme3) [sage] 2024/12/19(木) 21:05:36.88 ID:KU+lpcLj0 >>218 言うほど同じか？ rebaseを好む派閥がrebase使う最大のモチベーションはログの直線化 そういう神経質な連中がcherry-pickによる重複コミットの大量発生を許容するとは思えないのだが http://mevius.5ch.net/test/read.cgi/tech/1707958209/236
237: デフォルトの名無しさん (ﾜｯﾁｮｲ 2303-AYc0) [] 2024/12/19(木) 21:38:31.24 ID:QSrQ7dPA0 やってることの内容は似てるけど用途が全然違うからなあ かのPro Gitもリベースの章はベタ褒めでahhとかthe bliss of rebasingなどと顔もやや恍惚気味の御様子だが チェリーピックとなると淡々とした説明で真顔だよ http://mevius.5ch.net/test/read.cgi/tech/1707958209/237
238: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-IjhS) [sage] 2024/12/19(木) 23:45:56.41 ID:b251oEg00 >>236 目的じゃなくて動き(実装)の話 rebase で cherry-pick できるし cherry-pick で rebase できる どっちもコミットの再利用(付け先の変更)を目的とするコマンド あと直線化にしか rebase 使わないと思ってるうちは git の実力が認識できてない http://mevius.5ch.net/test/read.cgi/tech/1707958209/238
239: デフォルトの名無しさん (ﾜｯﾁｮｲ 7379-SnOJ) [sage] 2024/12/20(金) 01:21:38.28 ID:+bubGwJY0 リポジトリを分けるか、モノでやるか 統合度合いが微妙な場合にものすごく悩む http://mevius.5ch.net/test/read.cgi/tech/1707958209/239
240: デフォルトの名無しさん (ﾜｯﾁｮｲ 2ef8-Nme3) [sage] 2024/12/20(金) 09:56:06.03 ID:PANCPXf30 そんなところで悩んでいる段階なら分けなくていいよ。最初から細かく分けようとするのは基本的に時間の無駄。 成功している組織はだいたいクソデカリポジトリなのも事実。それについては戦略としてモノレポが優れているというよりは結果的にそうなっただけだろうけど。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/240
241: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-IjhS) [sage] 2024/12/20(金) 11:20:48.46 ID:Vt9p1L/d0 >>239 一般論にはメンバーで分けるとうまくいく事が多い 将来的に人が増えたり入れ替わっても同じ1つのグループで開発を続ける予定なら一緒にする、 対応するグループが分割されて片方だけに関わる人が出てきそう、もしくは不明なら別にしておく http://mevius.5ch.net/test/read.cgi/tech/1707958209/241
242: デフォルトの名無しさん (ﾜｯﾁｮｲ 2ef8-Nme3) [sage] 2024/12/20(金) 12:26:56.43 ID:PANCPXf30 「うまくいく」の定義によるかなあ 分かれている方が良いという前提のもとで失敗の可能性を下げるという意味では>>241に同意するが、 個人的には不適切な分割による失敗は幾度も見たことがあるが、逆に一緒であることの直接的な実害にはあまり遭遇した経験がない 巨大なモノリスへと誘導されやすいみたいなアーキテクチャに対する影響は否定しないが、そのへんは日常的なコーディング作業というより もっと大きな視点で恣意的に判断すべきことかと思う そして、その判断を今すべきか、そもそも可能なのかは冷静に考えた方がいい http://mevius.5ch.net/test/read.cgi/tech/1707958209/242
243: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-IjhS) [sage] 2024/12/20(金) 12:53:34.97 ID:Vt9p1L/d0 >>242 ・分かれてるものを一緒にするのはとても簡単だが、1つのものを分割するのはかなり手間がかかる ・単純なものどうしを組合わせるのは単純作業だが、複雑なものを組合わせるのは不可能な場合がある という一般原則による、悩んだ時は原則に従うのがたいてい正しい http://mevius.5ch.net/test/read.cgi/tech/1707958209/243
244: デフォルトの名無しさん (ﾜｯﾁｮｲ 8fe6-Nme3) [sage] 2024/12/21(土) 08:12:17.24 ID:/IqCjkFy0 >>243 同様に、下記も言える - 共通化されているものを個別化するのは簡単だが、個別化されているものを共通化するのは難しい 世の中そんなに単純じゃないんだわ http://mevius.5ch.net/test/read.cgi/tech/1707958209/244
245: デフォルトの名無しさん (ﾜｯﾁｮｲ 3ebb-IjhS) [sage] 2024/12/21(土) 10:33:21.60 ID:Hifil6s+0 >>244 俺の書いた2つは、お前が書いた共通化の手間より断然難しいというのが一般的だと思うが、お前にとっては同レベルなんだろうなあ まあ頑張れ http://mevius.5ch.net/test/read.cgi/tech/1707958209/245
246: デフォルトの名無しさん (ﾜｯﾁｮｲ 2ef8-Nme3) [sage] 2024/12/21(土) 11:20:34.07 ID:w/Sbt61U0 >>245 誤解させたようで申し訳ないが、単なるリポジトリの統合じゃなくてコードの共通化の話な 一般論として、集中管理は密結合を、分散管理は重複を招く 共通部分を介して密結合しているモジュール同士を切り離すには最悪共通部分をコピペすればよい 一方、分散管理され各所で個別化された重複を後から共通化する作業には、それほど自明な移行パスは存在しない コードスタイルや設計の問題といえばそれだけだが、それはモノレポだって同じことだ http://mevius.5ch.net/test/read.cgi/tech/1707958209/246
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 284 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.009s