Q&A
開発、ステージング、本番はリポジトリを分けずに、ビルド時の設定で分ける (パスワードなどはそもそもリポジトリに登録しない) のが一般的かと。
外部とのやりとりは、どんな相手とどんな内容をどんな頻度でやり取りするかによるでしょうね…。
前提・実現したいこと
GitHubにおける開発、ステージング、本番のリポジトリの具体的な作成手順・管理方法
GitHubにおける外部の人のリポジトリの具体的な作成手順・管理方法
詳細
GitHubで開発、ステージング、本番とわけたいのですが、
具体的な作業としてはリモートリポジトリは３つ用意すればよいのでしょうか？
作業手順が知りたいのですが、、
１、ステージングのローカルリポジトリにクローンを作成する。
２、ステージングのリモートリポジトリを追加でつくる。
３、ステージングのリモートリポジトリに切り替えて、ローカルリポジトリにクローンをpushする。
本番用も同じように、この作業を繰り返せばよいのでしょうか？
また、外部の人にリモートリポジトリを丸々ではなく、一部共有する場合は外部の人用のリポジトリを新規で用意すべきですか？
部分的にソースコードを共有するよい方法が知りたいのですが、、
GitHubで運用したことがないため、運用方法がわかっていません。
GitHubは趣味程度の初心者です。お手数おかけしますが、よろしくお願いします。
ご回答ありがとうございます。
なるほど。。もしかした調べ方を間違えて壮大な勘違いをしていますかね…。
こういう記事もあったため、わけるものかと思っていましたが、こちらが特殊ということでしょうか。
https://qiita.com/airkoda/items/09c33c27e3f59dc636bc
そもそもやりたいのは開発、ステージング、本番で使うファイルを一部変えたく、その切り替える方法を探しています。VSCodeのnuxt(Vue)で、その環境を作りたいと考えています。
あ、むしろ私が勘違いしてたかもしれません。git は分散バージョン管理システムなので、clone すれば同じ内容のものがコピーされます。普通は github などにマスターのリポジトリを一つ作って、それを開発マシンや各種サーバーに clone (clone は最初の一回だけ) して、開発者が自分のマシンでコミットした内容を github に push して、サーバーでは pull して使う流れです。リポジトリの物理的な場所は分散してるけど、感覚的には一つのリポジトリというイメージになります。
開発、ステージング、本番という環境の切り替えは、それぞれの設定内容を別々のファイル名で用意しておいて、起動コマンドのオプションや環境変数などで切り替えるのが一般的だと思います。例えば、Ruby on Rails であればこんな感じです。
https://pikawaka.com/rails/env
参考にされた記事を読み直したところ、、その記事では devlab とmaster は確かに異なるリポジトリですね。外部とのやりとりにこの方法を使うこともありうるとは思いますが、面倒くさそうな気がします…。
何度もありがとうございます。
おっしゃるとおり、調べなおしたところ、開発・本番はコマンドや環境変数で切り替えるのが一般的なようですね。
どうしてもわけたい場合は、自分専用のプライベートリポジトリを作っておくとかでしょうか。面倒になるのは私も気にしている部分です。なので、２つにしておいた方がよさそうですね。
分けたい理由によりますが、たとえば自分が実験・試行錯誤した内容を外に出したくないという理由であれば、自分のマシンのローカルなリポジトリの中でプライベートなブランチを切って、それは外部には push しないという使い方もできます。
回答2件
0
ベストアンサー
それだと「開発している意味がない」ので、
1つのプロジェクトに対して「開発、本番、外部の人」全てでリポジトリを1個に統一します。
プロジェクトのリポジトリを「分ける」ケースに関しては、
Webサーバのパスによっては
Pythonの機械学習のデータが使いのでPythonを使うけど、
大まかな流れはPHPを使いからPHPとPythonの部分でリポジトリを分けるという風な使い方をします。
GitHubで開発、ステージング、本番とわけたいのですが、
具体的な作業としてはリモートリポジトリは３つ用意すればよいのでしょうか？
例えば本番環境はAWSでRDSのMySQLサーバを借りました。
データベースには下記の情報で接続してくださいみたいな事になったとしましょう。
host: 10.1.2.3, port: 3306, user: hoge, password: 1a2s3d4f
でもローカルの開発環境で10.1.2.3で繋ぐわけにも行かない。
ユーザもローカルならrootのパスワード無しの方が楽だしいいや。
こういう設定ファイルの管理の仕方をどないすんねん。
→そうだ！GitHubのリポジトリを「開発、ステージング、本番」で分けよう！
こういう流れでの思いつきだと思いますが、
そういう「人によって閲覧されると困るような情報」というのは、リポジトリに含めてはいけません。
一番良い構築は、漏れてもダメージのない「開発者用のローカル環境」情報をリポジトリに含めておくことです。
そして本番環境用の設定ファイルは権限のあるユーザーしか閲覧出来ない方法で管理します。
別にGitHubである必要は微塵もありませんが、
GitHubのプライベートリポジトリで管理したり、AWS S3等のサービスを別途利用したりしましょう。
投稿2021/01/12 11:46
総合スコア21158
ご丁寧にありがとうございます。
基本のリポジトリは１つにして、権限のあるユーザーしか閲覧できないものを管理する方法として、もうひとつプライベートリポジトリを用意する方向で検討したいと思います。
0
そのような分け方では基本的にはリポジトリは分けません。もし環境変数やトークンなどをリポジトリで管理しようと思っているならそれはセキュリティ上のリスクになるのでやめたほうがよいでしょう。
どうしても外部の人に触らせたくないコードがある場合、ソフトウェアをモジュールに分けて外部の人が触っていいリポジトリとそうでないリポジトリに分けて更に別のメインのリポジトリで二つのモジュールを合体させるコードを書いてビルドする……なんてやり方もあるにはあるかと思いますがしちめんどくさかろうとおもいます。
基本的に「ソースコード」は開発者みんなで共有して「秘密情報」は個別の担当者が管理するのがよいのではないかなと思います（この辺の知見はわたしもまだ薄い）。
投稿2021/01/12 11:14
総合スコア2853
ご丁寧にありがとうございます。
そうですね、環境変数やトークンはさすがにローカルにおこうと思っています。。たしかに結構面倒くさいことになりそうなので、なるべくシンプルにしたいと思います。
あなたの回答
tips
プレビュー
