Git 20 (530ﾚｽ)
上
下
前
次
1-
新
299
:
(ﾜｯﾁｮｲ 7f3c-zT4W)
01/29(水)18:19
ID:u4GPoyB40(1/2)
AA×
[240|
320
|
480
|
600
|
100%
|
JPG
|
べ
|
ﾚｽ栞
|
ﾚｽ消
]
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
君のチームのワークフローに合わせればいいだからどうとかじゃなく 考え方は簡単他者の承認またはレビューを必要とするときに を作る承認したらマージするこれだけ 例えばタスク毎にメイン開発者とレビュワーがアサインされていてリリースにオーナーの承認を必要とするなら下記が考えられる 開発タスクのクローズ がタスクのブランチからブランチへのを作成しにレビューを依頼がを承認しまたはがマージ リリース 開発チームの誰かが から ブランチへのを作成しがマージその後 等のツールが本番環境へデプロイする 上記はよくある流れではあるがやだからこうするというわけではないことに留意せよ 開発フローはそれらとは独立に決められるべきでありそれをの機能を使って実装するだけだ
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 231 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
ぬこの手
ぬこTOP
0.028s