Git 20 (530ﾚｽ)
Git 20 http://mevius.5ch.net/test/read.cgi/tech/1707958209/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
291: デフォルトの名無しさん (ｱｳｱｳｳｰ Sa47-zrHT) [sage] 2025/01/28(火) 20:38:47.97 ID:n6IrqaQHa Gitを知ろう！昔のソース管理とGit の絵を見るとGitって難しい事してるな、って思う。 逆に古いツールは複雑なマージ出来るんだっけ？と不安になる。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/291
292: デフォルトの名無しさん (ﾜｯﾁｮｲ 3be6-6AoA) [sage] 2025/01/29(水) 13:05:47.15 ID:iK+g/tdh0 Gitはオープンソースのプロジェクトを分散管理するのが目的だろうから、 社内のソース管理とかに使うと、なんか前より面倒くさくなったなと感じる http://mevius.5ch.net/test/read.cgi/tech/1707958209/292
293: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/29(水) 13:38:14.63 ID:vsr4sfYf0 >>292 git は world wide にユニークな名前で管理して無限（おおげさな表現）にスケールすることが利点の1つなので 少人数のプロジェクトだとこの利点は感じ難いのは仕方ない、あらゆる利点は逆からみれば欠点なわけだし http://mevius.5ch.net/test/read.cgi/tech/1707958209/293
294: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/29(水) 13:41:47.19 ID:vsr4sfYf0 git の他の利点、例えばブランチを切ったり繋いだりするのが早くて操作も簡単 みたいなのに慣れてくると個人利用のみでも手放せなくなる http://mevius.5ch.net/test/read.cgi/tech/1707958209/294
295: デフォルトの名無しさん (ﾜｯﾁｮｲ 1bf9-pXYx) [sage] 2025/01/29(水) 15:51:35.40 ID:O2q9bD9Z0 正直、ローカルリポジトリを持たずに直接GitHubにコミットできるオプションがあったら便利だと思う クライアントとサーバーが等価なのがアーキテクチャとして美しいのはわかるけど、 安定したネットワーク環境とリモートへの反映が前提なら実用的にはあまり意味ないのよね 余計な手間が増えるだけだし、作業者マインドの人(情シスとか情シスとか)に理解させるのに苦労する http://mevius.5ch.net/test/read.cgi/tech/1707958209/295
296: デフォルトの名無しさん (ﾜｯﾁｮｲ 7a8e-0HiR) [] 2025/01/29(水) 16:45:51.30 ID:NEN1+s6c0 なるほど、必要なら作ってくれ http://mevius.5ch.net/test/read.cgi/tech/1707958209/296
297: デフォルトの名無しさん (ﾜｯﾁｮｲ 7ab6-N+ua) [sage] 2025/01/29(水) 17:08:05.77 ID:j23j/EVS0 最近のGitHubはweb上で編集してプルリク投げまで完結できたよね？ あんまし使ったことないけど http://mevius.5ch.net/test/read.cgi/tech/1707958209/297
298: デフォルトの名無しさん (ﾜｯﾁｮｲ b65f-rEDf) [sage] 2025/01/29(水) 17:26:33.12 ID:wXwWo4Yf0 会社ではプッシュばっかり使っててプルリクの概念がいまだによくわかってない このブランチをプルしてマージしてください ってお願いするのがプルリクなんだよね？ 会社でこれをやるなら、ソース管理者みたいな人を立ててその人に依頼すんの？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/298
299: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f3c-zT4W) [sage] 2025/01/29(水) 18:19:19.91 ID:u4GPoyB40 君のチームのワークフローに合わせればいい。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の機能を使って実装するだけだ。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/299
300: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/29(水) 19:20:58.17 ID:vsr4sfYf0 >>298 ワークフロー次第だが、もともと想定されてるのは 個人用公開リポジトリ ←push― 個人用ローカルリポジトリ ←commit― 作業ディレクトリ という環境を全員が持ってる前提で プルリクエストというのは、「俺の公開リポジトリに push したので、そこからお前のリポジトリに pull してくれ」という要求 これを責任者宛に出せば チームリーダーとかリリース・マネージャーとかの責任者がチェックして問題なければ、それを彼の個人ローカル・リポジトリでマージする（その後に彼の公開リポジトリに push して公開する） http://mevius.5ch.net/test/read.cgi/tech/1707958209/300
301: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f36-zT4W) [sage] 2025/01/29(水) 21:57:23.24 ID:u4GPoyB40 企業での開発においては共通のリポジトリを皆で触るのが一般的であり、”pull” requestは実際には同一リポジトリ内でのマージのみに使用する forkはガバナンスを困難にし情報漏洩につながるリスクがあるため、そもそもorganizationまたはenterpriseのポリシーで一律禁止するのがベストプラクティス http://mevius.5ch.net/test/read.cgi/tech/1707958209/301
302: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f86-ImQ9) [sage] 2025/01/30(木) 01:09:50.68 ID:o8nH7UIQ0 GitLabだとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ http://mevius.5ch.net/test/read.cgi/tech/1707958209/302
303: デフォルトの名無しさん (ﾜｯﾁｮｲ 9727-dNed) [sage] 2025/01/30(木) 01:12:38.22 ID:sgBWR4v+0 プルだと向こうが主語だもんな 引っ張ってぇ、的な http://mevius.5ch.net/test/read.cgi/tech/1707958209/303
304: デフォルトの名無しさん (ﾜｯﾁｮｲ 0ec9-X4Kx) [sage] 2025/01/30(木) 08:03:04.92 ID:yzi2OnyQ0 リクエストだから向こうが主語だよ 何いってんのさ どちらも依頼だけど取り込む段階に着目するかマージする段階に着目するかの違いだよ http://mevius.5ch.net/test/read.cgi/tech/1707958209/304
305: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/30(木) 08:48:49.49 ID:5L7oVd850 pull ってのは 「fetch して merge 」の省略形なので当然 merge もリクエストしてる 分散リポジトリなら先に merge の前に fetch してもらう必要があるので pull リクエストを出す 共用リポジトリとかなら fetch する必要がないので単なる merge リクエストを出す この違いが分かって使い分けできないやつが git 使ってるの爆笑ものなんだが ここは分かってないやつ多そうだな http://mevius.5ch.net/test/read.cgi/tech/1707958209/305
306: デフォルトの名無しさん (ﾍﾞｰｲﾓ MM06-zT4W) [sage] 2025/01/30(木) 10:31:13.18 ID:Be3+/jiBM 企業内での開発の場合、pull(merge) requestは要請というよりレビューと承認を求める意味合いが強い。 結局マージを行うのも同じ人(別の人間かもしれないが基本的には同一の責任主体と見做せる)であることがほとんどだから。 その意味ではシンプルに review request http://mevius.5ch.net/test/read.cgi/tech/1707958209/306
307: デフォルトの名無しさん (ﾍﾞｰｲﾓ MM06-zT4W) [sage] 2025/01/30(木) 10:47:11.99 ID:sLaRrBQRM 企業内での開発の場合、pull(merge) requestはコードレビューと承認を得ることを目的に作成され、その上でマージを誰が行うかは重要ではないんだよね。 というか多くのチームでは作成した本人がマージしている。 このへんの用語は実際初心者に教えてると理解しづらいようで、pullじゃなくてmergeにしたら解決というものでもない。 まあ、だからってもっと良い呼称は俺は思いつかないが。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/307
308: 307 (ﾍﾞｰｲﾓ MM06-zT4W) [sage] 2025/01/30(木) 10:52:20.88 ID:sLaRrBQRM すまん、>>306は誤って書き込んだ。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/308
309: デフォルトの名無しさん (ｵｯﾍﾟｹ Sr3b-ImQ9) [sage] 2025/01/30(木) 11:21:31.02 ID:aXMNWhD7r >>305 じゃあなんでGitLabはプルリクエストじゃなくてマージリクエストなの？ GitLabユーザーはfetchなんてしないのかしら？ http://mevius.5ch.net/test/read.cgi/tech/1707958209/309
310: デフォルトの名無しさん (ｽﾌﾟｰﾌﾟ Sd5a-zT4W) [sage] 2025/01/30(木) 15:36:37.44 ID:yII0bm57d しない。したとしても極めて稀。 OSS開発者のためのソーシャルコーディングサービスとして開発されたGitHubと異なり、 GitLabは当初からエンタープライズでのクローズドな開発を前提としており、>>301の通り基本的に共有リポジトリを使うから。 http://mevius.5ch.net/test/read.cgi/tech/1707958209/310
311: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/30(木) 16:07:15.77 ID:5L7oVd850 >>307 それはちょっと違う 本来は review とかが全部終わった完成したものについて出すのが merge/pull リクエスト review する人と merge する人が一緒の時に手抜きで一回で済ますだけでワークフロー上は完全に別物 http://mevius.5ch.net/test/read.cgi/tech/1707958209/311
312: デフォルトの名無しさん (ﾜｯﾁｮｲ 1b16-zT4W) [sage] 2025/01/30(木) 16:38:36.48 ID:NcQM/92I0 >>311 使ったことがあるとは思えん pull requestに対するレビュー結果の追加とマージの実行は別の操作だぞ http://mevius.5ch.net/test/read.cgi/tech/1707958209/312
313: デフォルトの名無しさん (ﾜｯﾁｮｲ 973f-dNed) [sage] 2025/01/30(木) 16:53:48.01 ID:sgBWR4v+0 盛り上がってまいりました http://mevius.5ch.net/test/read.cgi/tech/1707958209/313
314: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/30(木) 17:25:50.04 ID:5L7oVd850 >>309 >>311 github は分散リポジトリを念頭にサーバ上の統合作業の用語を選択した gitlab は共用リポジトリを念頭にサーバ上の統合作業の用語を選択した これは本来の git の意図とはズレてるのでリーナスが切れた（サーバ上では統合作業 merge/pull しない、それらは手元のローカル・リポジトリでやるのが git 本来の流儀） git で pull request はもともと相手のローカル・リポジトリへの pull を要求するというそのままの意味（github は用語を変に流用しただけ、本来の使い方ではない linux kernel だと subsystem maintainer とかが subsystem の開発リポジトリから完成した分をリーナスの個人リポジトリに取り込んでリリースに含めるよう最終的な要求するのが pull request の意味 コードのレビューとかはもっとずっと前に ML とかで多くの人が議論し尽くしてる、そういうのが全部終わって次のバージョンのリリースに含めて良くなったら pull request 出す http://mevius.5ch.net/test/read.cgi/tech/1707958209/314
315: デフォルトの名無しさん (ﾜｯﾁｮｲ 0ec9-X4Kx) [sage] 2025/01/30(木) 21:25:55.92 ID:yzi2OnyQ0 fetchしないってかなり語弊があるよな http://mevius.5ch.net/test/read.cgi/tech/1707958209/315
316: デフォルトの名無しさん (ﾜｯﾁｮｲ df02-zT4W) [sage] 2025/01/31(金) 09:01:26.86 ID:fWRcePGc0 >>314 で、あんたは>>298が会社でGitHubのpull requestを活用するにあたってLinuxカーネルと同様のMLベースのプロセスを導入すべきだと言いたいのか？ でないならその情報は質問者にとってたんなるのいずだ http://mevius.5ch.net/test/read.cgi/tech/1707958209/316
317: デフォルトの名無しさん (ﾜｯﾁｮｲ cebb-ncSF) [sage] 2025/01/31(金) 09:31:32.44 ID:uF0JLDg90 >>316 ここは GitHub スレではなくて git スレだ git 本来の用法と用語があるんだ GitHub の勝手用語を前提にしていない http://mevius.5ch.net/test/read.cgi/tech/1707958209/317
318: デフォルトの名無しさん (ﾜｯﾁｮｲ 7f65-ncSF) [sage] 2025/01/31(金) 10:15:03.05 ID:9dfMKsJi0 >>316 > あんたはGitHubのpull requestを活用するにあって 俺に聞いてる？ 俺のアドバイスなら git 本来の pull request は業務フローによって必要だったり不要だったりする、参考に知っておくと良い Github の pull request は使う必要も学ぶ必要もないゴミ、そのまま忘れてしまって良い、周りで使おうとするやついたら全力で止めるレベル http://mevius.5ch.net/test/read.cgi/tech/1707958209/318
319: デフォルトの名無しさん (ｱｳｱｳｴｰ Sabf-J/8e) [] 2025/02/05(水) 14:37:49.09 ID:RWIQAOlpa fork して勝手に成長させて fork 側が立派に育ったら pull request なんてしなくても勝手に pull してくれるのが理想 http://mevius.5ch.net/test/read.cgi/tech/1707958209/319
320: デフォルトの名無しさん (ﾜｯﾁｮｲ 7fbb-xxu2) [sage] 2025/02/06(木) 01:42:29.43 ID:3KBUKtr20 >>319 いつ、誰が、何のために、どこから、どこへ pull すべきか指定するのが pull request なんだが 超絶AIでも開発してタイミングや理由を説明するのか？ 誰がはどうする？ 人間が AI から命令を受け取るのか？ 責任者不明のコミットができる GitHub状態なのか？ 楽し過ぎるな。それやるくらいなら多分AIに全部のプログラム書かせた方が早いと思うぞ http://mevius.5ch.net/test/read.cgi/tech/1707958209/320
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 210 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.007s