Q&A
ブランチとリポジトリの区別もついてないじゃないですか。「教え過ぎは良くない」ではなく、「教えられない」の間違いでしょう。あなたの知ったかぶりはさすがに目に余ります。
前提・実現したいこと
現在複数の社内システム（WEBアプリケーション）の運用開発を10人程のチームでおこなっております。
FTPでの開発を行ってますが、開発用のサーバーと本番サーバーをAWSに移行するにあたりGitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。
現在の開発の流れとしては、
1.共有ファイル用のローカルサーバーにあるソースをそれぞれが編集
2.共有ファイルをFTPでテスト用のローカルサーバーにアップロード
3.テストサイト上でデバッグなどを行う
4.問題なければGMOの専用サーバー上から変更ファイルをダウンロードし差分を確認してから、
5.専用サーバー上にFTPでアップロードし本番公開を行う。
という風になってます。
また、AWSは開発用と本番用で2つ契約してます。
試したこと
Gitについてはまるっきりの初心者で経験もありませんが、Git利用にあたり一通り調べてgitやgithubの基本的な概念なら把握できているかと思います。
各自のローカルリポジトリからリモートリポジトリへpushしてそれを本番公開という流れはなんとなくわかるのですが、
おそらく開発用と本番用とサーバーがわかれているので、githubにローカルからpushしその内容を開発用のサーバーにデプロイ？する。
問題なければ本番にデプロイという流れなのかなと考えています。
githubは使用しないでサーバー上にリモートリポジトリを作るやり方などもあるのでしょうが、どの方法が一般的なのか、またそれぞれの方法にどのようなメリットデメリットがあるのかがわかりませんでした。
まるっきり見当違いのことを言っていたら申し訳ないです。
よろしくお願いします。
回答4件
0
ベストアンサー
いろんなやり方があって究極的には正解はないのですが、ベストプラクティスに近いものはあります。
おそらく開発用と本番用とサーバーがわかれているので、githubにローカルからpushしその内容を開発用のサーバーにデプロイ？する。
問題なければ本番にデプロイという流れなのかなと考えています
大まかな流れとしては問題ないと思います。
ただ、できれば開発、ステージング、本番と3つは環境があったほうがいいでしょう。
開発環境は本当に各メンバーの開発用で、ローカルで開発したものを動作確認したり直接その上で開発をしたりするための、比較的実際の動作環境に近めの環境（同じ環境を用意できるならベスト）
ステージングは複数人が開発したソースを合わせた上で、本番環境同様の構成でテストや動作確認をするための環境
みたいな感じで分けるイメージです。
これもざっくりな分け方なので、絶対ではないです。
各自のローカルリポジトリからリモートリポジトリへpush
この辺は説明の必要がないかもしれませんが念の為。
同じリポジトリの同じブランチに無条件にpushすると同じ箇所を変更したときに問題が発生します（コンフリクト）
なので、基本的には作業ごとにブランチを切って、プルリクエストでレビューを行った上で承認されたらデプロイ用のブランチにマージする、という流れにすると良いでしょう。
差分はGitHubのプルリクエスト上で確認します。
デプロイするブランチは予め決めておきます。
開発環境と本番環境で専用のデプロイブランチを用意しておくのもいいですし、開発環境でテストが済んだことを何かで保証できるならデプロイ用ブランチを一つだけ用意しておくでもいいので、このへんはルールで決めることです。
デプロイの方法についてはソースによって変わります。
最も単純な手段はサーバ上でgit clone/pullすることですが、ただ配置するだけでは動かないケースは多々あります。
配置後に何かしらのコマンド実行が必要になったり、ビルドが必要だったり。
それらすべてを手動でやることもできますが、そのへんは少しずつ自動化するといいでしょう。
デプロイはブランチやコミット、タグを指定した上で自動でできるようにしておくと、実環境への反映がスムーズに行なえて開発効率が大きく上がるでしょう。
いきなりここまでやるのは大変ですが、CI/CDという言葉について調べてみるといいかなと。
それについて追加で説明するのはあまりにも大変なので一旦は割愛します。
CI/CD とは
CI/CDのエキスパートが解説：CI/CDとは何か？ なぜ今、必要とされるのか？
GitHubならGitHub Actionsを使った方法もありますし、AWSのサービスを使うならCodeBuild/CodeDeployやそれらをまとめたCodePipelineを使う方法もあります。
古くからだとJenkinsを使う方法もありますね。
CircleCIみたいな、そのためのサービスみたいなものもあります。
githubは使用しないでサーバー上にリモートリポジトリを作るやり方などもある
できなくはないですが、それをやることはほぼないです。自分も実際には全く見たことがありません。
※GitHubをサーバ上で動かす、GitHubエンタープライズというサービスならありますが…。
GitHubがデファクトスタンダードなので、何もわからなければとりあえずGitHubを使うことをお勧めします。
あと、一応同様のgitリポジトリ管理サービスは他にもいくつかあります。
GitLabやBitBucket、AWSならCodeCommitなど。
ただ、全くgitの経験がないなら素直にスタンダードであるGitHubを使っておいたほうが良いかと思います。
また、社内システムならリポジトリを非公開にすることをお忘れなく。
今ならGitHub Organizationも無料で使えるようになったので、自分の会社のOrganizationを作るといいでしょう。
これらはかつては有料プランでしかできませんでしたが、今なら無料でできます。
投稿2020/08/13 08:51
総合スコア7590
0
有名な競合製品としてperforceもありますので、それを参考にすると、分散開発環境としてGitがよく見えてきます。bareでもbareでなくても、そのかたの環境ごとに調整すればよいとおもいます。
その時に、あまりにも多くの知識が必要となりますのでスローガンとしては、たくさんある言葉の中から１つを選ばさせていただいております。
わからないことがあれば、こべつに回答しますし、他の方がご回答なさることもあるかとおもいますが、
私の解答で、誤解などがある場合は説明不足の責任として補足回答させていただいております。
スペースを汚してしまい、申し訳ございません。ありがとうございます
投稿2020/08/22 04:25
総合スコア190
0
諸般の事情で私だとその構成にしないと思う。
何故その構成を自社で禁止するか？というのは会社ごとの運営方針や他のツールとの依存関係があるために、答えはない。
ただ、リモートとローカルというのは、自分が作業していない方、自分が今作業をしている方という意味合いを持っていて、かりに、自分がリリース用の環境で作業していて、開発用の環境にフィードバックする場合、リモートとローカルの意味が通常のときと逆転する場合がある。
そのため、リリース用のサーバをリモートとした場合、など安全策をとっておかないといけない場合がある。なので言葉をもう少し丁寧に使うとトラブルが増え（誤字訂正 トラブルが減りが本意）、デスマーチが早期解決すると少し思いました。外部からの一読者としてのコメントです。
Gitを扱う場合、いつ、だれが、どのように、なぜ行ったかというのをすべて記録をとりながらおこない、いつでも、その変更を取り消せるというのが、ツールの基本マインドです。それを念頭に入れながら、分散開発環境とはなにか？サーバとはなにか？というところをきちんと勉強すると、まちがいがなく安価にAWSなどに移行できると思いました。
教え過ぎは良くない、聞かれたことのみにこたえよというのが鉄則ですからこういうふうに書かせてください。追加質問は新しいTOPICをお願いします。それがここのルールでない場合は教えて下さい。がんばってね。
投稿2020/08/18 01:10
編集2020/08/18 01:14総合スコア190
perforceの業務経験もあります。
セキュリティーチームではセキュリティーの都合で最近でもCVSでした。gitは個人利用などのほうが多いです。
今年の合言葉はDid you believe in the Force of the Power?
です。質問があれば個別にお願いします。私のできる範囲で、お答えします。
Git を使ったことのある人がベアで作業すると？
そんなわけないでしょ。
※ https://www.perforce.com/ja/ perforce 企業向けバージョン管理システムで、Gitの分散バージョン管理システムの対極をなしてている中央集中管理システムのうち有名なものの方のことです。 補足まで
で？
あくまでベアで作業すると？
Git の話をしてるんだけど Git 知ってる？
> Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。
質問にこう書いてあるけど読めるの？
大変申し訳ございませんが、git にもbareオプションがありますが こちらは専門用語のためbareと区別するとbare であるかnon bareであるかは、大きな違いではない環境で作業しております。私は主に利用者側で、gitの場合はローカルの環境に余裕がある環境の場合が大多数ですので、管理者に指示されたとおりにgit作業を行います。
そのためペア ベアの打ち間違いも考慮し 申し訳ございませんが意味が取れませんでした。
こちらがどちらか知らないけど、perforce の話は誰もしてない。日本語読めるようになってから来い。
わけのわからない類推で知らないことを知ったかぶるな。
> Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。
ですので 今年のスローガンは
Did you believe in the Force of the Power?
で象徴されると思います。
Forceには映画スタウォーズおよび Perforceという製品もかかっていますので念の為、予備知識として、ご紹介しました。
寝言でごまかすのもやめろ。
0
開発用のサーバーと本番サーバーをAWSに移行するにあたり
Gitを利用してのチーム開発へ変更したくどのような構成にするべきか教えて頂きたいです。githubにローカルからpushしその内容を開発用のサーバーにデプロイ？する。
問題なければ本番にデプロイという流れなのかなと考えています。
以前そのような構成で開発していました
今のワークフローに影響が少ないようなやりやすいところ、
効果の大きいいところから少しずつその構成に近づけていくと良いと思います
投稿2020/08/13 09:00
総合スコア3272
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/08/14 01:08
2020/08/14 05:57
2020/08/18 04:19