非エンジニアのため、現場でのGitHubを使ったプロジェクト管理がイメージできずにいます。
お聞きしたいのですが、機能追加やバグフィックスでブランチを作成しコードを書き換えている間、エンジニアは別環境に全体のクローンを作成して機能確認を行うのでしょうか。それともプルリクエスト後、管理者がデプロイするまで機能確認はしない（できない）のでしょうか。

小規模なアプリ開発のケースで自主性と安全性のバランスがとれた管理方法などアドバイスいただけないでしょうか。
どうぞよろしくお願いします。

行動規範の内容に同意します

回答1件

ベストアンサー

小規模なアプリ開発のケースで自主性と安全性のバランスがとれた管理方法などアドバイスいただけないでしょうか

githubを使うなら、git-flow,Github flowなどを使うと良いです。

どちらかというとGithub flowの方が簡単です。

#Github Flowの簡単な説明

masterのメインブランチがあり、開発用のdevelopブランチ、そして機能毎のfeatureブランチや緊急用のhotfixブランチが存在し、これらのブランチを使い分けて開発・リリースを進めていきます。

詳しくは英語だけど本家サイトで。

git-flowの簡単な説明

git-flowは少し大きめなプロジェクトなどに使われる、バージョン管理がしやすい方法です。

詳しくは英語だけど本家サイトで。

お聞きしたいのですが、機能追加やバグフィックスでブランチを作成しコードを書き換えている間、エンジニアは別環境に全体のクローンを作成して機能確認を行うのでしょうか。それともプルリクエスト後、管理者がデプロイするまで機能確認はしない（できない）のでしょうか。

まず、ローカルでしか変更が保存されていない(=pushしていない)場合は、
他の人は見ることができません。

そしてリモートにも変更が保存されている場合は(push済み)場合は、みる方法が二つあります。

①コマンドプロンプトからの操作

別環境でリポジトリをクローンし(またはクローンしたあと変更が入ってpushした場合)checkoutをして
ブランチを切り替えて見る。

②Githubのリポジトリページからの操作

Githubの方からブランチを切り替えることもできます。
(git-flowを使用しているリポジトリの例です。タイトルなどは伏せています。)

多分ほとんどの人が②を使うと思います。

投稿2020/10/04 06:14

編集2020/10/04 06:17

programming-go

総合スコア55

kai0310

2020/10/04 07:44

重複投稿は削除することができますので、削除依頼を行ってください。

tonomori

2020/10/04 12:01

詳しいご説明ありがとうございました。 GitHub Flowに関する記事の記述について追加で質問させてください。＞GitHub Flowでは、masterブランチへマージした時、すぐにデプロイを行います。そのため、masterブランチが不安定になるようなマージを行ってはいけません。また、直接masterブランチにコミットすることもありません。しっかりテストとレビューを行った上でマージしましょう。 masterブランチへのプルリクエスト → 開発者プルリクエストのレビュー、masterブランチへのマージ、デプロイ → 管理者かと思うのですが、開発者は自分が修正中のブランチをどのようにテストするのでしょうか。管理者がデプロイするまで確認できないのか、それともローカルなどでテスト環境を複製して開発を進めるのでしょうか。