- 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
- 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]
- あ〜なるほど！謎が解けました！
ありがとうございます！
- 260 名前：デフォルトの名無しさん mailto:sage [2025/01/12(日) 17:53:29.03 ID:6ooBodrm0.net]
- Git用GUIがなまじっか日本語化されていると、
求めているコマンドを探すときに面倒くさい
- 261 名前：デフォルトの名無しさん [2025/01/12(日) 18:29:09.15 ID:ORJFqn4Yd.net]
- >>260
わかる
- 262 名前：デフォルトの名無しさん [2025/01/12(日) 18:29:16.18 ID:ORJFqn4Yd.net]
- >>260
わかる
- 263 名前：デフォルトの名無しさん mailto:age [2025/01/15(水) 09:29:23.33 ID:3C2APGzS0.net]
- Git v2.48.1
- 264 名前：デフォルトの名無しさん mailto:sage [2025/01/15(水) 14:32:20.61 ID:gq5bJ2fy0.net]
- Git for Windows 2.47.1(2)Latest
- 265 名前：デフォルトの名無しさん mailto:sage [2025/01/15(水) 14:42:56.61 ID:gq5bJ2fy0.net]
- Git Credential Managerの脆弱性で
Git for Windows 2.47.1、2.46.2、2.45.2の各バージョンで差し替え
（日本時間2025-01-15 03:11）
- 266 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 09:18:49.62 ID:vFJWSuXb0.net]
- ローカル上の作業ブランチで複数回コミットして、まだマージやプッシュをしたくない状態のとき、
ここでPCやSSDが壊れたら痛いのでローカルの内容をバックアップしておきたいとなったら、
どうやるのが常套手段なんでしょうか
- 267 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 09:22:23.44 ID:5LAJlDxM0.net]
- 個人作業用のブランチにpushすりゃいいじゃん
- 268 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:01:54.42 ID:RFmrvYtC0.net]
- 常套手段は知らんけど壊れることまで心配するならクラウドバックアップとRAIDじゃないの
手軽な手段ならpushとpush -fだな
-fで困る人いないでしょ
- 269 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:05:22.41 ID:RFmrvYtC0.net]
- 汚すことができないやむを得ない事情があるなら自由になる別のリモートを増やしてブランチをミラーリングしておく
- 270 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 10:42:03.41 ID:JYmON0LL0.net]
- >>266
・ディスクをレイドとかにして耐障害性を上げる
・ディスク／ファイルシステムのバックアップを取る
・バックアップ用の別のリモート・リポジトリにプッシュする
・共用リポジトリに別のブランチ名でプッシュしておく
どれでも好きなのをどうぞ
全部やれば完璧
（最後のなら簡単、運用ルール的にかぶらないブランチ名の付け方決めとくだけでOK、個人名_ブランチ名 とか
- 271 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:27:44.30 ID:vFJWSuXb0.net]
- >>267-270
参考になりました、ありがとうございます
.gitフォルダだけを圧縮して逃がしたりしていましたが、
自分しか使わない前提のブランチなら、リモートにプッシュしてしまってもよいものなのですね
- 272 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:36:39.07 ID:5LAJlDxM0.net]
- >>271
チームでやってるならチームのルールを確認
- 273 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 12:54:07.03 ID:JYmON0LL0.net]
- >>271
git のブランチなんていくら push しても容量がそんなに増えるようなもんじゃないし、邪魔にもならないんで駄目って言われることはほぼないよ
フィルターしやすくしたり、名前かぶるの避けるためにブランチの命名規則だけは決めておくと良い
（方針によってはバックアップは別のリポジトリがあるからそっち使えって言われることはあるかもしれない
- 274 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 18:26:22.96 ID:ZEFHCs1J0.net]
- >>266
ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？
リモートに個人的なブランチをpushするのは抵抗感があるなぁ。
- 275 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 18:36:02.43 ID:vFJWSuXb0.net]
- >>274
>>271で書いたような、今自分がやっている方法と同じですね
Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか
- 276 名前：デフォルトの名無しさん mailto:sage [2025/01/23(木) 19:41:26.62 ID:ZEFHCs1J0.net]
- >>275
大丈夫じゃない？
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
- 277 名前：デフォルトの名無しさん mailto:sage [2025/01/24(金) 14:03:41.62 ID:/oFMYy+rM.net]
- 仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい
OSSならそもそもforkしてるだろうからリモートは元々自分専用
- 278 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 15:00:31.31 ID:i3NO8nb7M.net]
- 道具として異常
知恵遅れがしがみつく道具がgit
- 279 名前：30 mailto:sage [2025/01/25(土) 17:08:54.33 ID:i1hyUUYx0.net]
- じゃあ天才は何使ってんの
- 280 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 17:22:25.79 ID:W3I6NstP0.net]
- 未だにsvnから移行できないじじいはいたな
- 281 名前：デフォルトの名無しさん mailto:sage [2025/01/25(土) 17:57:50.21 ID:aP269JYO0.net]
- better cvs として使ってます。本当にすみません。 ブランチとか良く使わないです
- 282 名前：デフォルトの名無しさん [2025/01/26(日) 13:26:52.01 ID:uiy/DQQ3H.net]
- やっぱりVisual Source Safeが一番わかりやすくていいよね
- 283 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 16:30:13.37 ID:h32xfORHM.net]
- Better CVSではないGitならではのやり方と言えるのなんて、
複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ
基本的に大半の人の使い方はBetter CVSの域を出ない
ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度
- 284 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 16:51:43.41 ID:v8RHgYNZ0.net]
- ↑中途半端にわかった気になってるじじい
- 285 名前：デフォルトの名無しさん mailto:sage [2025/01/26(日) 17:14:21.11 ID:OHuPDl3g0.net]
- >>283
もうちょっと上手に煽んないと乗れないぞ
そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ
30年前のアプリ比較に出しても自分が年寄りと表明することにしか
まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど
- 286 名前：30 mailto:sage [2025/01/26(日) 22:56:56.08 ID:Im+l/vn00.net]
- CVSなら知ってるよ
コンビニのことでしょ
- 287 名前：デフォルトの名無しさん [2025/01/27(月) 23:35:25.04 ID:5zVfH4ct0.net]
- >>285
40歳以上なら知っている
- 288 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 00:30:38.67 ID:knz0Jl8ca.net]
- RCSの話をしたくなるね
- 289 名前：デフォルトの名無しさん [2025/01/28(火) 06:16:26.21 ID:OdcIn15O0.net]
- VSSもかなりあとまで使っていたけどな
35歳以上なら知っていることが多い
- 290 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 12:37:10.14 ID:bnD9cEyX0.net]
- いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。
Gitも使えるけど。
開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が
評判高いというか、Gitは使わないよなw
- 291 名前：デフォルトの名無しさん [2025/01/28(火) 13:19:48.30 ID:dqvH8r5Ca.net]
- SVNも忘れないで
- 292 名前：デフォルトの名無しさん mailto:sage [2025/01/28(火) 20:38:47.97 ID:n6IrqaQHa.net]
- Gitを知ろう！昔のソース管理とGit
の絵を見るとGitって難しい事してるな、って思う。
逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。
- 293 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:05:47.15 ID:iK+g/tdh0.net]
- Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、
社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる
- 294 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:38:14.63 ID:vsr4sfYf0.net]
- >>293
git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので
少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし
- 295 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 13:41:47.19 ID:vsr4sfYf0.net]
- git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単
みたいなのに慣れてくると個人利用のみでも手放せなくなる
- 296 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 15:51:35.40 ID:O2q9bD9Z0.net]
- 正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う
クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、
安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね
余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する
- 297 名前：デフォルトの名無しさん [2025/01/29(水) 16:45:51.30 ID:NEN1+s6c0.net]
- なるほど、必要なら作ってくれ
- 298 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 17:08:05.77 ID:j23j/EVS0.net]
- 最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？
あんまし使ったことないけど
- 299 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 17:26:33.12 ID:wXwWo4Yf0.net]
- 会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない
このブランチをプルしてマージしてください ってお願いするのがプルリクなんだよね？
会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？
- 300 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 18:19:19.91 ID:u4GPoyB40.net]
- 君のチームのワークフローに合わせればいい。Gitだからどうとかじゃなく。
考え方は簡単、他者の承認またはレビューを必要とするときに pull request を作る、承認したらマージする、これだけ。
例えばタスク毎にメイン開発者AとレビュワーBがアサインされていて、リリースにオーナーCの承認を必要とするなら、下記が考えられる。
開発タスクのクローズ : AがタスクのブランチからmainブランチへのPRを作成し、Bにレビューを依頼。BがPRを承認し、AまたはBがマージ。
リリース : 開発チームの誰かが main から production ブランチへのPRを作成し、Cがマージ。その後GitHub Actions等のCI/CDツールが本番環境へデプロイする。
上記はよくある流れではあるが、GitやGitHubだからこうするというわけではないことに留意せよ。
開発フローはそれらとは独立に決められるべきであり、それをGitHubの機能を使って実装するだけだ。
- 301 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 19:20:58.17 ID:vsr4sfYf0.net]
- >>299
ワークフロー次第だが、もともと想定されてるのは
個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ
という環境を全員が持ってる前提で
プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求
これを責任者宛に出せば
チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する）
- 302 名前：デフォルトの名無しさん mailto:sage [2025/01/29(水) 21:57:23.24 ID:u4GPoyB40.net]
- 企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する
forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス
- 303 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 01:09:50.68 ID:o8nH7UIQ0.net]
- GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ
- 304 名前：デフォルトの名無しさん mailto:sage [2025/01/30(木) 01:12:38.22 ID:sgBWR4v+0.net]
- プルだと向こうが主語だもんな
引っ張ってぇ、的な
|
 |
