当社では現在、シンプルなトランク/リリース/ホットフィックスのブランチ モデルを使用しており、貴社または開発プロセスに最適なブランチ モデルについてアドバイスをいただきたいと考えています。
ワークフロー/分岐モデル
以下は私が目にした 3 つの主な説明ですが、部分的に矛盾していたり、その後に発生した問題 (以下で説明する) を解決するには不十分でした。そのため、私たちのチームは今のところ、あまり優れた解決策を採用していません。あなたはもっと良い方法を採用していますか?
マージとリベース（絡み合った履歴と連続した履歴）
pull --rebaseタスクが完了するまで、メインラインへのマージを待つべきでしょうか？個人的には、タスクがどのベースで開始され、完了したかを視覚的に表すことができるため、マージのほうが好きmerge --no-ffです。しかし、マージには他の欠点もあります。また、マージの便利な特性に気付いていない人も多くいます。交換可能な(トピック ブランチをマスターにマージすることは、マスターをトピック ブランチにマージすることを意味しません)。自然なワークフローを求めています
時々、私たちの手順が単純なルールで特定の状況を捉えていないために、間違いが起きます。たとえば、以前のリリースに必要な修正は、当然のことながら、上流を必要なすべてのブランチにマージできるように、下流に十分基づいている必要があります (これらの用語の使用は十分に明確ですか?)。しかし、開発者がそれをさらに下流に配置する必要があることに気付く前に、修正がマスターに取り込まれることがあります。そして、それがすでにプッシュされている場合 (さらに悪いことに、マージされているか、それに基づいているもの)、残されたオプションはチェリーピッキングであり、それに伴う危険を伴います。このような単純なルールはどのようなものですか?また、これには、1 つのトピック ブランチが必然的に他のトピック ブランチを除外するという厄介さも含まれます (それらが共通のベースラインから分岐していると仮定)。開発者は、自分が書いたコードがもう存在しないような気分で、機能を完成させて別の機能を開始したくはありません。
マージ競合 (チェリーピックによる) を回避するにはどうすればよいでしょうか?
マージ競合を確実に作成する方法は、ブランチ間でチェリーピックすることのようですが、それらは二度とマージできません。どちらのブランチでも、同じコミットをリバートに適用すると (これを行う方法は?)、この状況は解決されるでしょうか? これが、私がマージベースのワークフローを積極的に推進しない理由の 1 つです。
トピックブランチに分解するにはどうすればよいでしょうか?
トピック ブランチから完成した統合を組み立てることができれば素晴らしいことはわかっていますが、開発者の作業は明確に定義されていないことが多く (「ちょっと触る」だけの単純な作業である場合もあります)、一部のコードがすでに「misc」トピックに入っている場合、上記の質問に従って、そのコードをそこから再び取り出すことはできません。トピック ブランチの定義、承認、卒業、リリースはどのように行いますか?
コードレビューや卒業などの適切な手順があれば、もちろん素晴らしいでしょう。
しかし、これを管理できるほど物事を整理しておくことはできません。何か提案はありますか? 統合ブランチ、図解などはありますか?
関連する質問のリストは次のとおりです。
- 展開されたアプリケーションをホットフィックス可能にするための良い戦略は何ですか?
- 社内開発における Git の使用に関するワークフローの説明
- 企業向け Linux カーネル開発のための Git ワークフロー
- 開発コードと本番コードをどのように保守しますか?（についてありがとうございましたこれ（PDF）
- Git リリース管理
- Git チェリーピックとマージワークフロー
- 複数のコミットをチェリーピックする方法
- git-merge を使用して選択したファイルをどのようにマージしますか?
- コミットの範囲をチェリーピックして別のブランチにマージする方法
- ReinH Gitワークフロー
- 元の場所にプッシュバックしない変更を行うための Git ワークフロー
- マージを厳選する
- OS とプライベートコードを組み合わせた場合の適切な Git ワークフローですか?
- Git でプロジェクトを管理する
- Git は変更された親/マスターとファイルの変更をマージできないのはなぜですか。
- Git ブランチ / リベースのベストプラクティス
- 「git pull --rebase」はいつ問題を引き起こすのでしょうか?
- 大規模なチームでは DVCS はどのように使用されますか?
また、Plastic SCMが書いている内容もご覧ください。タスク駆動開発プラスチックがあなたの選択でない場合は、勉強してくださいnvie の分岐モデルそして彼のサポートスクリプト。
ベストアンサー1
DVCSの新規開発者が認識する必要がある最も厄介な機能は、出版プロセス:
- 必要なリモートリポジトリをインポート（フェッチ/プル）できます
- 任意の（ベア）リポジトリに公開（プッシュ）できます
そこから、質問を簡単にするためにいくつかのルールを守ることができます。
- プッシュされていないブランチのみをリベースする（最後のリベース以降にプッシュされていないブランチのみ）
- ベアリポジトリにのみプッシュする（Git1.7以降は必須）
- フォローするリベースとマージに関する Linus のアドバイス
今：
ワークフロー/分岐モデル:
各ワークフローはリリース管理プロセスをサポートする、そしてそれは各プロジェクトに合わせて調整されます。
あなたが言及したワークフローに私が付け加えることができるのは、各開発者は機能ブランチではなく、「現在の開発」ブランチのみを作成する必要があるということです。なぜなら、真実は、開発者は自分のブランチが正確に何を生み出すのかを知らないことが多いからです。1 つの機能、複数の機能 (複雑すぎる機能になったため)、何もない (リリースに間に合わなかったため)、別の機能 (元の機能が「変形」したため)、...
「インテグレーター」のみが「中央」リポジトリに公式の機能ブランチを確立する必要があります。これにより、開発者はそれを取得して、その機能に適合する作業部分をリベース/マージできます。
マージとリベース（絡み合った履歴と連続した履歴） :
あなたがおっしゃった私の答えが気に入りました（"社内開発における Git の使用に関するワークフローの説明）
自然なワークフローを探しています:
修正の場合、各修正をバグ追跡のチケットに関連付けるのに役立ちます。これにより、開発者はどこに (つまり、どのブランチ、つまり「修正」専用のブランチに) 変更をコミットする必要があるかを覚えておくことができます。
次に、フックは、検証されていないバグ修正やプッシュすべきでないブランチからのプッシュから中央リポジトリを保護するのに役立ちます。 (ここでは特定のソリューションはありません。これらすべてを環境に合わせて調整する必要があります)
マージ競合 (チェリーピックによる) を回避するにはどうすればよいでしょうか?
述べたようにヤクブ・ナレブスキで彼の答えチェリーピッキングは、それが必要なまれな状況でのみ使用してください。
設定にチェリーピッキングが頻繁に含まれる場合 (つまり、「まれではない」場合)、何かが間違っています。
同じコミットを元に戻して適用しますか (どうすればいいですか?)
git revertそれを処理する必要がありますが、それは理想的ではありません。
トピックブランチに分解するにはどうすればよいでしょうか?
ブランチがまだどこにでもプッシュされていない限り、開発者はコミットの履歴を（開発がより明確で安定した形になったと最終的に確認したら）次のように再編成する必要があります。
- 必要に応じて複数のブランチ（明確に識別された機能ごとに 1 つ）
- 1つのブランチ内での一貫したコミットのセット（Git チェックインのトリミング）
コードレビューや卒業などの適切な手順?
統合ブランチ (専用の統合内) リポジトリは、開発者が次のことを実行するのに役立ちます。
- リモート統合ブランチ上に開発をリベースする (pull --rebase)
- ローカルで解決する
- そのリポジトリに開発をプッシュする
- 混乱が生じないようにインテグレーターに確認してください ;)