[解決済み】どのようなGitブランチングモデルが有効ですか？

質問

私たちの会社は現在、単純なtrunk/release/hotfixesのブランチモデルを使用していますが、あなたの会社や開発プロセスに最適なブランチモデルについてアドバイスをお願いします。

1. ワークフロー／ブランチングモデル

   以下は、私が見た主な3つの説明ですが、部分的に矛盾していたり、私たちが遭遇したその後の問題（後述）を整理するのに十分な内容ではありません。したがって、私たちのチームは今のところ、あまり良くない解決策をデフォルトとしています。何か良い方法はないでしょうか？

   • gitworkflows(7) マニュアルページ
   • (nvie) Git の成功したブランチモデル
   • (reinh) アジャイルチームのためのGitワークフロー

2. マージとリベース (絡み合った履歴と連続した履歴)

   あるべき姿 pull --rebase それとも、タスクが終了するまでメインラインにマージするのを待つのでしょうか？個人的には、マージしたほうが、どのベースでタスクが開始され、終了したかが視覚的にわかるので、マージするほうに傾いています。 merge --no-ff ということです。しかし、これには他の欠点があります。また、多くの人がマージの便利な性質に気づいていません。 可換 (トピックブランチをmasterにマージしても、masterがトピックブランチにマージされるわけではありません）。

3. 自然なワークフローを探している

   時には、私たちの手順が特定の状況を単純なルールで捉えていないために、間違いが起こることがあります。例えば、以前のリリースに必要な修正は、もちろん十分に下流をベースにして、必要なすべてのブランチに上流からマージできるようにすべきです（この用語の使い方は十分明確でしょうか）。しかし、開発者がもっと下流に置くべき修正に気づかないうちにマスターに入ってしまうことがあります。もしそれがすでにプッシュされている（さらに悪いことに、それを元にマージされている）なら、残された選択肢はチェリーピックとなり、それに伴う危険性が出てきます。このような単純なルールはどのようなものですか？ また、あるトピックブランチが他のトピックブランチ（共通のベースラインからブランチされたと仮定）を必ずしも排除しないことの厄介さも、これに含まれます。開発者は、ある機能を終了して別の機能を開始するときに、今書いたコードがもう存在しないかのように感じたくはないでしょう。

4. チェリーピックによる）マージの競合を回避する方法は？

   マージコンフリクトを起こす確実な方法は、ブランチ間でチェリーピックを行い、二度とマージできないようにすることでしょうか？revert で同じコミットを適用すれば(どうすれば?)この状況を解決できるのでしょうか? これが、私があえてマージベースのワークフローを推し進めない理由の一つです。

5. 局所的な枝に分解する方法は？

   トピックブランチから完成した統合を組み立てるのは素晴らしいことだと理解していますが、開発者による作業が明確に定義されていないことが多く（時には "poking around" と同じくらい単純）、コードがすでに "misc" トピックに入っている場合、上記の質問に従って、そこから再び取り出すことができないのではありませんか？トピックブランチの定義、承認、卒業、解放はどのように行っていますか？

6. コードレビューや卒業などの適切な手続き もちろん、それは素晴らしいことです。

   しかし、これを管理するために物事を十分にほぐしておくことができません。何か提案はありますか？ 何か提案はありますか？

以下は、関連する質問の一覧です。

• デプロイされたアプリケーションをホットフィックスできるようにするための良い戦略は何ですか？
• 社内開発でのGit活用のためのワークフロー説明
• 企業向けLinuxカーネル開発のためのGitワークフロー
• 開発コードと本番コードのメンテナンスはどのように行っていますか？ (ありがとうございます これ PDF！)
• git リリース管理
• Git Cherry-pick vs Merge ワークフロー
• 複数のコミットをチェリーピックする方法
• git-mergeで選択的なファイルをマージするには？
• ある範囲のコミットをチェリーピックして別のブランチにマージする方法
• ReinH Git のワークフロー
• オリジンにプッシュすることのない変更を行うための git ワークフロー
• マージをチェリーピックする
• OS とプライベートコードを組み合わせた場合の適切な Git ワークフローは？
• Gitによるプロジェクトの維持管理
• なぜ、Git はファイルの変更を、変更された親/マスターにマージできないのですか。
• Git のブランチング/リベースのグッドプラクティス
• git pull --rebase" はいつ問題になるのですか？
• 大規模なチームでは、DVCSはどのように使用されていますか？

また、Plastic SCMの記事もご覧ください。 タスク駆動開発 また、Plasticがだめな場合は、以下の勉強をしてください。 nvieのブランチングモデル と彼の サポートスクリプト .

解決するには？

DVCSの新規開発者が最も困るのが、この 公開処理 :

• 必要なリモートレポをインポート（フェッチ/プル）することができます。
• 任意の（素の）レポに公開（プッシュ）することができます。

そこから、質問をしやすくするためにいくつかのルールを尊重することができます。

• ブランチがプッシュされていない (前回のリベース以降にプッシュされていない) 場合のみ、リベースを行います。
• ベアリポジトリへのプッシュのみ(Git1.7から必須)
• フォロー Linusによるリベースとマージのアドバイス

今すぐ

ワークフロー／ブランチングモデル :

各ワークフローは リリースマネジメントプロセスのサポート そしてそれは、それぞれのプロジェクトに合わせたものです。

というのも、開発者は自分のブランチから何が生まれるかわからないことが多いからです。1つの機能、複数の機能（複雑すぎる機能になってしまったため）、何もない（リリースに間に合わないため）、別の機能（元の機能が変質してしまったため）などなど...。

公式の機能ブランチをセントラルレポに設置し、開発者がその機能を満たす部分をリベース/マージできるようにするのは、quot;インテグレータだけです。

マージとリベース（絡み合った歴史と連続した歴史） :

私はあなたが言及した私の答えが好きです（" 社内開発でgitを利用する際のワークフロー説明 ということです。）

自然なワークフローを探している :

修正については、各修正をバグ追跡のチケットと関連付けることで、開発者がその修正をコミットすべき場所（つまりどのブランチ、つまり修正専用ブランチ"）を覚えておくのに役立ちます。

そしてフックは、検証されていないバグフィックスやプッシュすべきでないブランチからのプッシュからセントラルリポジトリを保護するのに役立ちます。(ここでは特定の解決策はありません。すべてあなたの環境に適応させる必要があります)

チェリーピックによる）マージの競合を回避するには？

が述べているように ヤコブ・ナレブスキー で 回答 チェリーピッキングは、それが必要とされる稀な状況に限って行われるべきです。

もし、あなたのセットアップが多くのチェリーピックを含んでいる（つまり、"それは稀ではない"）場合、何かが間違っているのです。

revertで同じコミットを適用するか（どうやるか？）

git revert が対処してくれるはずですが、それは理想的ではありません。

トピックの枝に分解する方法は？

まだどこにもプッシュされていないブランチである限り、開発者は (開発がより決定的で安定した形になったと判断したら) そのコミット履歴を次のように再編成する必要があります。

• 必要に応じて複数のブランチ（明確な特定機能ごとにブランチ）
• 1つのブランチ内の一貫したコミットセット ( Git チェックインのトリミング )

コードレビューや卒業などの適切な手続きは？

統合ブランチ（統合専用）レポは、開発者の助けになります。

• リモート統合ブランチの上に、自分の開発をリベースする (pull --rebase)
• ローカルで解決する
• そのレポに開発をプッシュする
• インテグレーターに確認し、混乱が生じないようにする ;)