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