Git 20 (530ﾚｽ)
上下前次1-新
284(1): (ﾜｯﾁｮｲ cebb-ncSF) 01/26(日)17:14 ID:OHuPDl3g0(1) AAS
>>282
もうちょっと上手に煽んないと乗れないぞ
そもそもこのスレに cvs 使ったことあるやつがどれだけいると思ってんだ
30年前のアプリ比較に出しても自分が年寄りと表明することにしか
まちもに cvs 使ってたやつなら、恥ずかしくこの書き込みできないんで、きちんと使ったことないのまでは分かるけど
285: 30 (ﾜｯﾁｮｲ 7f3d-ImQ9) 01/26(日)22:56 ID:Im+l/vn00(1) AAS
CVSなら知ってるよ
コンビニのことでしょ
286: (ﾜｯﾁｮｲ 7a86-Uu4E) 01/27(月)23:35 ID:5zVfH4ct0(1) AAS
>>284
40歳以上なら知っている
287: (ｱｳｱｳｳｰ Sa47-zrHT) 01/28(火)00:30 ID:knz0Jl8ca(1) AAS
RCSの話をしたくなるね
288: (ﾜｯﾁｮｲ 7a86-Uu4E) 01/28(火)06:16 ID:OdcIn15O0(1) AAS
VSSもかなりあとまで使っていたけどな
35歳以上なら知っていることが多い
289: (ﾜｯﾁｮｲ 1a6e-dNed) 01/28(火)12:37 ID:bnD9cEyX0(1) AAS
いまでもVisualStudioのソースコード管理はVSSライクなのあるよね。
Gitも使えるけど。
開発の中心じゃないメンバーも使う仕様書管理とかだとそっちの方が
評判高いというか、Gitは使わないよなw
290: (ｱｳｱｳｴｰ Sa52-FFa5) 01/28(火)13:19 ID:dqvH8r5Ca(1) AAS
SVNも忘れないで
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
盛り上がってまいりました
上下前次1-新書関写板覧索設栞歴
あと 217 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.014s