質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Q&A

解決済

5回答

6970閲覧

少人数で開発する時に、gitをどのように運用すべきか?

redhat98

総合スコア236

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

0グッド

6クリップ

投稿2017/10/18 01:06

3人程度でチーム開発する時、gitをどのように運用すれば良いのかわからずに困っています。
gitを使って開発したことがあるのですが

・業務系なので半年に1度程度しかリリースが発生しない
・サーバはmasterリポジトリだけでgitを運用
→ ローカルでmasterからブランチを作成し、修正は新しく作成したブランチへコミットしています。
その後、ローカルのmasterへマージし、サーバのmasterへpushしていました。

という運用でした。
元々、svnを使っていたので、それをそのままgitに移行しただけになってしまいました。

git-flowやgithub-flowを導入しようとしたこともあるのですが、敷居が高く導入することが出来ませんでした。
masterだけでgitを運用すると、開発の生産性が下がる気がします。
少人数で開発する時、gitをどのように運用しているのでしょうか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答5

0

ベストアンサー

理想はgit-flow運用ですからね……
スキルの高いエンジニアにとっては速度やセキュアのバランスが取れているgit-flow運用を好みます。
敷居が高いとは思いますが、意味がある運用ですし頑張ってみては?

あとは、それを少人数という理由でどこまで崩すかという差だけです。
DB設計の第三正規形を速度の為にどこまで削るのかと似ていますね。
概念が難しいからと何も考えずに第三正規形を崩すとプロジェクトが空中分解するのと同じことです。

まぁ、散々脅しましたがそのままでも良いかとは思います。
Gitは他のバージョン管理システムと比較して、
マージが賢いので並列開発ができるだけでも十分なメリットですからね。


改善するなら下記2箇所を取り組みましょう

  • リリースタイミングでタグを打つ
  • masterへマージする直前のdevelopmentブランチを用意して受け皿にする

大幅な改修やWIPのコミットの受け皿としてdevelopmentブランチは一つ欲しいですね。
大失敗してシステムが動作しなくなっても、developmentブランチを捨てるだけで済み、
masterの履歴には傷一つつかないので運用が楽です。

大部分は捨てたいけど、このコミットだけはmasterに含めたいというケースがありますが、
cherry-pickコマンドで個別にmasterに反映させることも可能です。

また、リリースタイミングでタグを打っておけば最悪の事態を回避するのに役立ちます。
戻りたいタイミングですぐに昔のバージョンに戻れるようになりますからね、運用が楽になります。

投稿2017/10/18 01:43

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2017/10/19 02:04

> masterへマージする直前のdevelopmentブランチを用意して受け皿にする 実際やってみたのですが、 1. リモートリポジトリにはmasterが1本だけある 2. その、リポジトリをローカルへclone 3. ローカルでmasterからdevelopを作成 4. 変更をdevelopへコミット 5. リモートリポジトリへdevelopをpush 6. プルリクエストを作成し、developをmasterへマージ 7. リモートのdevelop(マージ元の)ブランチを削除する といったイメージでしょうか?
miyabi-sun

2017/10/19 03:12 編集

developmentブランチを使った時の運用の一例を紹介します。 (これは私が以前の職場で行っていた方法です) サーバーには常にmasterとdevelopmentの2本のブランチが存在しています development -> masterのプルリクは修正箇所が多すぎて誰も何もレビュー出来ない≒プルリクの存在意味が殆どないです。 各々のメンバーはローカルではmasterやdevelopmentブランチを更新したりマージしてはいけません。 各々のメンバーはdevelopmentブランチをpullしてきて、 新たに好き勝手なブランチを生やして(add_hoge, delete_piko)改修します。 そのブランチ(add_hoge, delete_piko)をそのままリモートにプッシュします。 GitHubの管理画面で、add_hogeやdelete_pikoからdevelopmentへのプルリクエストを生成します。 皆や上位者がプルリクエストの内容をレビュー、これで良ければマージボタンをクリックしてGitHub上でdevelopmentを更新するという流れになります。 半年後のリリースが来たら、development -> masterへのプルリクエストを作成してマージ。 もちろんこの時は変更箇所が多すぎてわからないので、さらっとチェックする感じになるでしょう。 --- 既存のgit-flowやgithub-flowとの差分ですが、それぞれこのような違いがあります。 git-flowはリリースメンバーがdevelopmentをmasterに反映したいが、 開発メンバーも別に居て、リリース期間中もdevelopmentを更新していきたい。 そこでリリースの範囲を限定する為にdevelopmentからmasterへの反映箇所を締め切る目的で、一時的にリリースブランチを生成します。 github-flowは超絶簡略化した管理手法です。 development = masterと考えて、developmentブランチは削除。 リリースはmasterの今のバージョンにタグを打って確定という作業を行います。
guest

0

特に困っていることはないのでしょうか?

ないのであればそのままでも良いような気はしますが
気になることがあるとすれば
リリースのスパンが半年と長めなことからすると
意外とブランチが多くなったりするのではないかと思います。

masterブランチのみとなると、部分リリースやリリース後の切り戻しを考えた時に
キツくなって来る場面があるかもしれません。

個人的な見解ではありますが
現時点で問題があったり、今後問題が出そうなことが想定される場合に
それに適した運用を考えるのが良いような気がします。

適した運用を考える際には推奨されている方法(git-flow等)や
他の方がどうしているのかを聞くのはアリですが、
git-flowも含めて全てが、どこの現場にも最適なものではないと思いますので
現場で最適なものが一番なのではないかと思ったりはします。

投稿2017/10/18 01:51

編集2017/10/18 01:54
yuki-saito

総合スコア928

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2017/10/18 01:53

回答ありがとうございます。
guest

0

こんにちは。

ローカルでmasterからブランチを作成し、修正は新しく作成したブランチへコミットしています。

そのブランチを共有する必要がない(担当者一人にて開発する)ケースであれば問題ないように感じます。私も少人数プロジェクトが多かったのですが、1つの案件1担当者は非常に良くありました。

新人さんだけはその人専用のブランチをサーバに置いて、新人さんはマスターではなく個人専用ブランチへのみプッシュし、レビュー者(教育指導者?)にてレビュー後にマスターへ反映するような使い方も便利と思います。(教育段階に応じて、ブランチへマスターをマージする作業まで新人さんにやらせる)

投稿2017/10/18 01:58

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

私も、おっしゃるような運用でやっていました。
お互いの作業内容を十分共有できていれば、一つのブランチで十分管理できます。
チームの状況が変わっても後から変更することもできるので、今やりやすい方法で良いと思います。

(追記)
master だけでリリースを管理するのが難しいと思う場面もあるかもしれません。
そういった場合のテクニックとしては、「フィーチャートグル」という手法があります。
コードはデプロイ済みでも機能はトグルをオンにしない限り有効にならないという手法です。

使いすぎには注意ですが、節度を持っていれば割と上手く機能して便利ですよ。

投稿2017/10/18 01:25

編集2017/10/18 09:37
okinaka3

総合スコア304

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2017/10/18 01:55

仲間ですね。 SVNよりも運用を考えなければならないところが、gitの問題点ですね
okinaka3

2017/10/18 09:26 編集

巷では色々やり方が提案されていますが、「これが正解」というのはありませんので、あまり考えすぎず SVN 的な使い方でも十分いけると思いますよ。コンフリクトを避けるように運用していければいいと思います。
redhat98

2017/10/19 01:59

なるほど、ありがとうございます
guest

0

developmentはほしい。
masterへはリリースのタイミングにマージするだけにして、
開発はdevelopmentで行うというのはどうでしょうか。

投稿2017/10/21 07:40

deigo

総合スコア200

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問