Git 20 (530ﾚｽ)
上下前次1-新
203(1): (ﾜｯﾁｮｲ 7f10-f5HH) 2024/12/14(土)11:54 ID:mefXJp+A0(2/2) AAS
>>202
回答ありがとうございます
まさに他人がプッシュしたものを派生ブランチにも適用させようとしています
その中に特定ブランチの対応分も混ぜてしまっていたため
どう対応すべきか質問した次第です
コミット分割は癖にしておきたいと思います
204: (ﾜｯﾁｮｲ 87f0-gWKG) 2024/12/14(土)14:22 ID:jFwYZGRF0(1) AAS
ろくに開発経験ないやつがgitの仕様はグダグダとか言ってるのまじで面白いな
205: (ﾜｯﾁｮｲ dffd-thkz) 2024/12/14(土)19:07 ID:cLbKsfdN0(1) AAS
>>93の質問以降まともだったのは96、97、99、101、107くらいしかいなかった
7bは置いとくとしても100レスも使ってこの体たらくとは情けない
206(1): (ﾜｯﾁｮｲ 4a97-66FK) 2024/12/15(日)22:01 ID:D9xraIFr0(1) AAS
>>178
diffでわざわざ比較するというのは時間の無駄
207: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/15(日)22:49 ID:9FCwcKO70(1) AAS
>>206
相手にすんな
バケツ君はマニュアル読めなくて git が外部 diff に対応してることすら見つけられずに俺の望む出力じゃないと散々暴れた過去がある、今もそう思い込んでるので
208: (ﾜｯﾁｮｲ fb50-Nme3) 2024/12/15(日)23:49 ID:UElXL8/K0(1) AAS
>>203
コミットの際にcherry-pickまで考慮するなんて不毛だからやめておいた方がいいよ
そんなことをしなければならないほど強くcherry-pickに依存したワークフローになっているならその方がよほど問題
209: (ﾜｯﾁｮｲ eac0-Hfw5) 2024/12/16(月)00:02 ID:I9YsDANU0(1/2) AAS
不毛っていうのも程度問題でしょ
経験の浅いメンバーだと一つのコミットに複数のバグトラッカーのissueを混ぜこぜにすることがある
hot−fixブランチが必ずしも計画的に作られるとは限らないからcherry-pickで取り出したいことは時々起こる
210: (ﾜｯﾁｮｲ 8fd6-NWjc) 2024/12/16(月)12:28 ID:UeL/Eu4T0(1/2) AAS
cherry-pickに依存するのは不毛だと思うが、リモートへのコミットは機能単位・イシュー単位に整理した方がやり取り楽じゃない？
211: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)12:38 ID:ZibPg38H0(1/4) AAS
同じプロジェクト内に並行で製品(バージョン)を維持しているような場合には cherry-pick は多用するよ
特にブランチ切るまでもない単純な修正の場合とか
要はコミット1個だけのブランチの rebase/merge の簡略形なので不毛とか言うやつは単に経験が足りないだけ
212(1): (ﾜｯﾁｮｲ 8fd6-NWjc) 2024/12/16(月)12:42 ID:UeL/Eu4T0(2/2) AAS
せっかくbranch切ったのに、merge代わりにcherry-pickしたら後でトレース面倒にならん？
213: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)12:53 ID:ZibPg38H0(2/4) AAS
>>212
cherry-pick はブランチ切るまでもない修正用だよ
コミット1個ならどこから cherry-pick したか分かれば良いだけだし
214: (ﾜｯﾁｮｲ 4a6b-O1Z7) 2024/12/16(月)13:11 ID:56LO+jCc0(1) AAS
今度はチェリーピックでやり合いか
215: (ﾜｯﾁｮｲ eaa0-Hfw5) 2024/12/16(月)13:17 ID:I9YsDANU0(2/2) AAS
将来どのコミットが急遽hotfixに採用されるか分からないからといってあらゆる事前の修正コミットをもしものためだけにブランチ分けするのもガチガチで作業効率が落ちる
程度問題と言った通り俺はcherry-pickを多用する気もないしフローとして禁止扱いも効率が悪いと思う
hotfixが必要ない現場なら必要になる機会は少ないだろうな
216: (ﾜｯﾁｮｲ 3ebb-f1VN) 2024/12/16(月)13:41 ID:ZibPg38H0(3/4) AAS
cherry-pick には複数の使いみちがあって別に全部の使い方しなければいけない訳ではないが色々知ってると便利
・最新版から過去リリースへのバックポート
・セキュリティなどの hotfix の適用
・テスト用の addhoc 修正版（正式なマージは今ではない
・ゴミ箱ブランチ等から拾ってコードの再利用（コードだけ拾ってコミットは再利用しない
など多数
「1つのコミットには1つの修正」という大原則を守ってさえいれば、cherry-pick に限らずあらゆる再利用や利用中止がやり易くなるといだけ
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 にするとさらに良いぞ）
あと正しく動かないコミットに分割するのは「必要な部分だけ」とは言わないぞ
上下前次1-新書関写板覧索設栞歴
あと 298 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.008s