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

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

ただいまの
回答率

90.75%

  • Git

    1156questions

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

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

解決済

回答 5

投稿

  • 評価
  • クリップ 6
  • VIEW 1,188

redhat98

score 226

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

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

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

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

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

checkベストアンサー

+6

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

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

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


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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/10/19 11:04

    > masterへマージする直前のdevelopmentブランチを用意して受け皿にする
    実際やってみたのですが、

    1. リモートリポジトリにはmasterが1本だけある
    2. その、リポジトリをローカルへclone
    3. ローカルでmasterからdevelopを作成
    4. 変更をdevelopへコミット
    5. リモートリポジトリへdevelopをpush
    6. プルリクエストを作成し、developをmasterへマージ
    7. リモートのdevelop(マージ元の)ブランチを削除する

    といったイメージでしょうか?

    キャンセル

  • 2017/10/19 12:09 編集

    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の今のバージョンにタグを打って確定という作業を行います。

    キャンセル

+4

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

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/10/18 10:53

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

    キャンセル

+3

こんにちは。

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/10/18 10:55

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

    キャンセル

  • 2017/10/18 18:24 編集

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

    キャンセル

  • 2017/10/19 10:59

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

    キャンセル

0

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

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

  • ただいまの回答率 90.75%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

  • 解決済

    開発環境と本番環境の整合性について

    一般論なのですが、開発環境と本番環境を分けている場合、整合性をどのように保っていくかがなかなか難しいと思っています。 緊急のバグフィックスとかで本番環境を直接いじってしまうこともあ

  • 解決済

    gitのremoteリポジトリの設定

    お世話になります。gitの勉強中です。 gitのだいたいの概要は理解しているつもりなのですが、gitでremoteリポジトリにアクセスしていろいろやろうとすると、 fatal: '

  • 受付中

    Gitで複数プロジェクトの管理方法。おすすめは?

    Git初心者です。 こちら(http://qiita.com/yuba/items/3670235cf87be335fb39)のサイトと(たぶん)同じ質問なのですが、 例えば、S

  • 解決済

    GitHubEnterpriseでの開発フロー

    新規プロジェクトが立ち上がり、GitHub Enterpriseでの開発を行おうとしています。 その際の開発フローとして、 一般的なOSS開発のような、各開発者がそれぞれ

  • 解決済

    Git初心者の開発フローについて

    SourceTreeを使ってアプリの作成をGit管理で行っています。 ローカルリポジトリとリモートリポジトリを使ってどう作業していくか悩んでいます。 今考えているのは

  • 解決済

    SourceTreeの基本的なことですが。

    windowsでSourceTreeを使っています。 別の作業者が、masterブランチで作業しており、途中から自分が加わることになったのですが、リモートから「新規/クローン

  • 解決済

    github-flowでhotfixはどのように行うのでしょうか

     質問内容 gitの運用方法としてgit-flowとgithub-flowを勉強しました。 git-flowの場合、次のバージョンのdevelopブランチを作成し、新機能をpush

  • 解決済

    github flowではmasterの変更を取り込む必要は無いのですか?

    GitHub flowでソース運用しています。 質問なのですが、 masterの変更が影響なければトピックブランチはmasterを反映する必要は無いのでしょうか?

同じタグがついた質問を見る

  • Git

    1156questions

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