Gitのローカルマージとリモートマージについて教えてください

Question

###経緯と現在の状態

今までローカル（master）とリモート（master）だけで開発をしていました。
最近になり、リモートでdevブランチを切りました。同様にローカルでもdevブランチを切りました。
その後はずっとローカル（dev）とリモート（dev）間だけでソースを更新しています。

###質問内容

１）
通常は、このあとまずローカルでmasterにdevをマージし、
ローカル（master）→リモート（master）へpush、
ローカル（dev）→リモート（dev）へpush
という流れになるのでしょうか？

２）
リモート側はmasterとdevが常に平行しているというのが通常の運用なのでしょうか？

３）
そもそもローカルのmasterとdevでURLなどの向き先が本番用と開発用で違うのですが、
ブランチをマージするときに競合など問題あるでしょうか？

稚拙で申し訳ないのですが、Gitに不慣れなものでどなたか教えていただけると幸いです。
よろしくお願い申し上げます。

Answer 1

整合性さえ取れれば問題ありません。
お好きなようにご開発ください。

でもこれだけでは何なので、考え方の指針として一例を共有します。

---

master: 本番環境と同一
dev: 最新の開発環境

ルール

• 各作業者はdevブランチから、作業内容を端的に表した作業ブランチを作成するgit branch add-hoge
• 作業完了後該当ブランチを名称そのままでリモートにPushするgit push origin add-hoge
• 作業者はレビュワーに対してプルリクエストを出すadd-hoge → dev
• プルリクエストを受けたレビュワーは、リモートにPushされたブランチの変更点を確認後、承認する
• 全員のレビュワーの承認が受けられたら、プルリクエストの機能を利用してリモート上でマージを行うadd-hoge → dev
• 本番リリース時、dev → masterのプルリクを出して意思決定者がマージを行う
• 本番環境でgit pull origin masterを叩いて、更新差分を落として本番反映を行う
• 各作業者は不整合が出ないよう、作業ブランチを作成する前にdevブランチを最新に保つ事

上記が一番シンプルな運用方法となります。

そこからこのプロジェクトでは本番反映前に、ステージング環境を立ててチェックするから、
dev → staging → masterという承認プロセスを踏まえたブランチ構成にしても良いでしょうし、
緊急対応が必要なものはmaster → working → masterという修正を行い、後程devブランチにmasterに対して行った修正を反映というフローを用意しても良いです。

Comments

[teramasa]

miyabi-sunさん

コマンド付きで大変詳しいポリシーを書いてくださりありがとうございます！今後のうちの運用で是非使わせていただきます。人が増えたら承認フロー確率しないといけないです。

Answer 2

dev ブランチがどういう使用目的のブランチなのかによって違ってくると思います。
もし、本番環境を master ブランチで、開発環境を dev ブランチで、ということを意図しているのだとしたら、あまり好ましくない設計・運用かな、と思います。 本番環境も開発環境も同じコードで動くようにし、設定値の違いや振る舞いの違いは環境変数などで切り替えるのがよいと思います。

Comments

[teramasa]

unauさんご回答ありがとうございました。おっしゃる通り設定値の違いなどをブランチで吸収するよりも環境変数やプロパティファイルで切り替えるのがいいですね。jsの設定値を切り替える方法がすぐにわからず、今回はブランチに頼る方針となってしまいました。