Git 20 (530ﾚｽ)
上下前次1-新
273(1): (ﾜｯﾁｮｲ ff95-YoY9) 01/23(木)18:26 ID:ZEFHCs1J0(1/2) AAS
>>265
ローカルにスタッシュする or 専用ブランにコミットした上で、.git以下を適当にバックアップするんじゃないの？
リモートに個人的なブランチをpushするのは抵抗感があるなぁ。
274(1): (ﾜｯﾁｮｲ c3e6-Trbs) 01/23(木)18:36 ID:vFJWSuXb0(3/3) AAS
>>273
>>270で書いたような、今自分がやっている方法と同じですね
Gitの使い方としてどうかと思っていたのですが、それも間違いではないのですか
275: (ﾜｯﾁｮｲ ff95-YoY9) 01/23(木)19:41 ID:ZEFHCs1J0(2/2) AAS
>>274
大丈夫じゃない？
外部ﾘﾝｸ:git-scm.com
276: (ﾍﾞｰｲﾓ MMff-4FDL) 01/24(金)14:03 ID:/oFMYy+rM(1) AAS
仕事でやってるならそれは個人的な作業ではないのだから堂々とリモートにpushすればよい
OSSならそもそもforkしてるだろうからリモートは元々自分専用
277: (ﾄﾞｺｸﾞﾛ MM7f-wVPw) 01/25(土)15:00 ID:i3NO8nb7M(1) AAS
道具として異常
知恵遅れがしがみつく道具がgit
278: 30 (ﾜｯﾁｮｲ d315-+m+E) 01/25(土)17:08 ID:i1hyUUYx0(1) AAS
じゃあ天才は何使ってんの
279: (ﾜｯﾁｮｲ 6f9b-Bxv4) 01/25(土)17:22 ID:W3I6NstP0(1) AAS
未だにsvnから移行できないじじいはいたな
280: (ﾜｯﾁｮｲ 6f5f-3AqC) 01/25(土)17:57 ID:aP269JYO0(1) AAS
better cvs として使ってます。本当にすみません。 ブランチとか良く使わないです
281: (JP 0Hb6-dNed) 01/26(日)13:26 ID:uiy/DQQ3H(1) AAS
やっぱりVisual Source Safeが一番わかりやすくていいよね
282(1): (ﾍﾞｰｲﾓ MM06-zT4W) 01/26(日)16:30 ID:h32xfORHM(1) AAS
Better CVSではないGitならではのやり方と言えるのなんて、
複数のリモートリポジトリ間でpullし合うような真に分散管理された伝統的なOSS開発スタイルくらいだろ
基本的に大半の人の使い方はBetter CVSの域を出ない
ローカルリポジトリがリモートリポジトリへの反映前のバッファとして使えて便利だな、という程度
283: (ﾜｯﾁｮｲ b6f0-jays) 01/26(日)16:51 ID:v8RHgYNZ0(1) AAS
↑中途半端にわかった気になってるじじい
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だとマージリクエストって名前なんだけど、個人的にはこっちの名の方がしっくり来るんだよなあ
上下前次1-新書関写板覧索設栞歴
あと 228 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.009s