GitHubでリモートリポジトリにブランチを複数作成する事に意味はあるか

#気になったこと、知りたい事
最近GitHubを使用したバージョン管理やチームでのソースコード共有について興味を持ち調べ、ある程度流れを理解することができました。
ただその中で気になったのが、リモートリポジトリに複数のブランチを作成するという事、そもそもリモートのブランチから同じリモートのブランチにプッシュできるのか、についてです。

###自分の中の流れについての認識
※つい最近GitとGitHubに触れたばかりで細部まで調べつくせてはいないので誤りがあったら申し訳ありません。

１、リモートリポジトリにmasterブランチを作成
２、ローカルにクローンを作成
３、ローカルのmasterから、developmentなどの名前を付けてブランチを作成
４、作業を行う際はローカルのdevelopmentからさらに子ブランチを作成
５、作業が終わったら子ブランチをコミット＆プッシュ
６、ローカルのdevelopmentにチェックアウトし、子ブランチをマージ
７、ローカルのdevelopmentをリモートリポジトリのmasterにプッシュ

今現在は上記のような流れで作業を行うものだと認識しています。
ですが、開発の段階や流れを考えたときにリモートリポジトリのmasterブランチは『これ以上ソースコードの追加や修正が必要なく、動作が確約できたリリース版としての状態』にしておきたいな、と思いまして。

なので、仮に開発の段階が３つに分かれているとしたら

[リモートリポジトリ]
master:step3の内容をそのまま反映したい
step3:step2の内容を反映し、ソースコードを追加。この段階が終われば完成。
step2:step1の内容を反映し、ソースコードを追加。
step1:何もない状態。

[ローカルリポジトリ]
development:現時点での作業段階(step)に対して常に最新の状態を維持する。
step1の作業段階ならリモートのstep1に、2なら2にプッシュする。
step1_1(1_2,1_3...):developから作成されたブランチ。単体の作業を行い完成したらローカルのdevelopementにコミット＆プッシュ。step2以降も共通。

という形で行えないか？とふと思いました。

###上記の考えに対する個人的な懸念
・そもそもversion管理ツールとしてGitHubをとらえた場合、やり方として正しいのか
・回りくどい方法になっていないか？
・リモートリポジトリのAブランチの内容を同じリモートリポジトリ内のBブランチにコピーできるのか
→step2,step3のブランチに関してはstep1が完成したらそれをもとにstep2ブランチ作成、step2が完成したらそれをもとにstep3ブランチ作成、でコピーなどしなくてもできるのかなと思ってます。
ただmasterに関しては最初に作られるものなのでコピーする必要があるのかなとか思ったり。そもそもmasterもstep3が完成してからブランチ作成すればいいじゃんという意見や、この行為に何のメリットがあるのか？という疑問はあるかもしれませんが、その辺の意見も含めて色々教えていただけたらと思います。

よろしくお願いいたします。

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

回答1件

ベストアンサー

意味はありますか？という質問ですが、
大いにあります。むしろ上げずにどうすんだ？レベルで重要なことです。

これだけだとふーんで終わるので軽く解説します。

Gitはバージョン管理ソフトです。
GitHubはGitで生成したバージョン管理履歴(リポジトリ)を預かるサービスです。
ですが、これはGitHubを全て理解した訳ではありません。

GitHubの本当の姿はGitのリポジトリを預かり、
エンジニアのアカウント同士で議論や共同作業をするための総合SNSサービスと呼ぶべきなのです。
Gitだけでは出来ない機能は沢山ありますが、その中でもSNSだなと評価すべき機能が2つあります。

Issue
Pull Request

Issueを直訳すれば問題です。
これは利用者や開発者が「相談」するための掲示板です。
掲示板のスレッドを建てて皆で議論や相談します。
なので利用者側の立場の人も問題が発生した時にスレッドを建てて相談すれば回答がもらえる事もあります。

「こんな機能欲しい」「終わったよ」「対応不要」「バグ」「緊急！」といった趣旨のラベルをペタペタ張れます。
そのIssueがソースコードの対応まで必要になると皆が判断した場合、
「要修正」という風なラベルと共に誰かの作業によってソースコードが書き換わることでしょう。

Pull Request(プルリク)はブランチからのブランチへのマージする際の承認依頼です。
本番環境で運用しているソースコードに脆弱性が含まれており、
悪意の第三者に本番環境に侵入されてデータを盗み取られたり、DBの値を全て消去されて復旧できません、マシンでrm -rf /を実行されました
…という会社が潰れるレベルの再起不能なやべー状況に追い込まれる事は結構あります。

これへの対策として、
自分のマシンでソースコードをペチペチ修正したらそのブランチをGitHubに反映させて、
GitHub上のサービスで意思決定者に「こんな機能作ったんだけどどう？」とお伺いをたてます。

これを様々な権限を持った人達があーでもないこーでもないと議論をして、
GitHub上でブランチを精査し、「よし、これで行こう！採用！」と承認することで
根っこのmasterブランチへのマージを行ったりします。

これにはmasterブランチへ取り込まれる履歴や誰がどう見たのか判断したのか全て追えるので、
悪意の第三者がウィルス等を混入させてもすぐに発見出来るし未然に防げる仕組みとなっているのです。

最初の質問に戻りましょう。