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