このgitブランチモデルまたはワークフローについて質問しています。私は本当にこれが好きです。それは私に非常に直感的で生産的な印象を与えますが、私が求めているのは、（ClearCaseがその日を支配した別の世界から来た）私にはまだ明らかではないこのアプローチに欠陥または欠点があるかどうかです。
（あなたが役立つことができるものは何でも、すべての質問に答える必要はありません）
これまたは同様のgit分岐ワークフローを使用していますか？
これは生産的なアプローチだと思いますか？
このアプローチに欠陥はありますか？潜在的な欠点はありますか？
より良いアプローチがある場合は、共有したり、それに関する記事やディスカッションへのリンクを提供したりしますか？
回答:
ほとんどの場合、これはこれまでに使用したすべてのVCSで採用されている通常のワークフローです。一部の（CVS、SVN）の場合は実行が難しく、GITの場合は簡単です。とは言っても、私は2つの発言があります。
まず、機能ブランチに関しては2つの考え方があります。
（1）は記事が示唆しているようです。マージコミットの問題は、いわゆるEvil Mergesです。具体的には、いずれかのブランチで関数がセマンティクスを変更した開発パスに参加するものですが、自動マージは、他のブランチからのコード内のすべてのオカレンスにパッチを適用できません。この方法で導入された回帰は、デバッグが難しいことで有名です。GITユーザーは、git bisect自動的に原因を見つける必要があるため、通常、回帰についてはるかにリラックスできます。ただし、上記の状況では、git bisectマージコミットが指摘されるため、まったく役に立ちません。
（2）履歴をできるだけ線形に維持することで、この問題を回避します。それらの反対するリベースは、それがリベースの前に行ったテストを無効化すると主張しています。
個人的に、私はしっかりとキャンプ（2）にいます。なぜならgit bisect、適切なCIシステムを使用することで容易に補償されるテストカバレッジの潜在的な損失よりも、結果の有効性を重視しているからです。
第二に、開発者の間でプッシュすることはめったにないことだと私は決めました。誰もがsshを使用してボックスにフェッチしたり、git-deamonをローカルで実行したりすることに関連するセキュリティの問題があり、さらに重要なことに、極端に小さくないチームでは、見落としがすぐに失われる可能性があります。
とは言っても、ステージングリポジトリ（スクラッチとも呼ばれることもあります）に賛成です。これにより、サブサーバーは中央サーバーを介して進行中の作業を共有できます。公開されていない場合は、直面しています）。一般的に、各サブチームは、自分自身のための1つのトピックブランチを維持するであろう、とCIシステムは、定期的に実行することになりタコのマージ一つの大きな統合ブランチにすべてのトピックブランチのを、紛争やビルドエラー不満。
git bisectそのときもフラットな戦略を維持する理由として与えられました。
git bisect単独では何の関係もありません。機能Aが、機能Bも使用する機能を変更すると発生します。すべてのテストはマージ前にAとBの両方に合格しますが、マージ後はAとBの間に互換性のない変更が原因でテストが中断する可能性があります。ただし、git bisect1つのブランチを別のブランチに部分的に適用することはできないため、マージコミットはバグが導入されたときです。
他のチームメンバーが引き続き新しい機能に取り組んでいるため、私は現在、大規模で長時間のリファクタリング（アプリケーションをあるGUIツールキットから別のGUIツールキットに変換する）を実行し、成功したリベース中心のワークフローを実行しています。
主に2つのメインブランチがmasterあり、新しい機能が開発されるtoolkit-conversionブランチとブランチがあります。最も重要なルールは単純ですtoolkit-conversion。変換に関連するブランチ内の処理のみを実行します。master（古いGUIツールキット）で実行できる処理がある場合はいつでも、それを実行し、toolkit-conversion変更を新しいmasterヘッドにリベースします。別のルールは、toolkit-conversionブランチをかなり短くすることです。したがって、私はよくリセット、チェリーピック、修正コミットを使用して、小さなコミットを大きなコミットに結び付けます（最終的には同じ目的を持っています）。これは、変更を「元に戻す」のにうまくいかなかったものを試したとき、または一時的なヘルパーコードを使用して一部のコードをリファクタリングした後にも正常に機能します。
変更masterをtoolkit-conversionブランチにマージしないことを決定しました。ブランチをクリーンでレビューしやすい状態に保つために以前のコミットをリベースすることが非常に難しくなるためです。また、マージにより競合が発生する可能性があり、その解決策は、履歴をクリーンに保つ場合ほど明確ではありません。
もちろん、このワークフローには欠点もあります。最も重要なのは、それが一人のためにのみうまくいくということです。toolkit-conversionブランチをの先頭にリベースした後で強制的にプッシュするmasterと、別のリポジトリでそれをプルすることが難しくなります（追跡ブランチに自動的にリベースすると、競合が発生して失敗することがよくあります）。
最後に、私のtoolkit-conversionブランチは短く、クリーンで、レビューしやすいままです。たとえば、SVNでこれと同様の強力なことをしているとは思えませんでした。
私が現在働いている会社では、この同じ分岐モデルのバリエーションをしばらく適用しています。また、スクラムを使用しているため、ストーリーごとのワークフローワークフローを実行しています。
これまでの唯一の問題は、チームが十分に大きく、複数のストーリーを開始でき、それらのストーリーが相互に依存している場合であり、ブランチ間の変更をマージしてマスターに戻すのは一種の混乱になります。
その上、これは信頼できることが証明されています:)。
これまたは同様のgit分岐ワークフローを使用していますか？
職場でも同様のワークフローを使用していますが、少し複雑ではありません。ただし、この記事を何度も読んだことがあるので、このワークフローに大きく影響を受けています。私は自分の机の横に色分けされた分岐モデルのpdfさえ持っています:)
これは生産的なアプローチだと思いますか？
生産的。生産性をどのように定義しますか？ええと、私の心の中で、少なくとも常により良い品質を試し、達成することは、高品質であることが最も重要です。常にプロセスなどを改善します。高品質のコードを作成できれば、生産性はその恩恵を受けます。だから問題は本当に：これはソフトウェアの品質を改善しますか？そして、それに対する私の答えは間違いなくイエスです。
このタイプの分岐モデルで最も気に入っているのは、品質の異なるレイヤーで分岐を導入することです。画像の右側にあるほど、安定性と品質が高くなります。マスターブランチは神聖であり、それに対するすべてのコミットはソフトウェアの安定したバージョンと見なされるべきです。左側に行くほど、実験的で安定性が低くなります。
新しい機能とバグ修正をテストしたらすぐに、それらを左から右に徐々に転送して、コードが要求する品質要件を満たしていることがわかっている場合に、高品質のコードを正確に移動できます。まあ、少なくとも理論的には、すべてを100％までテストすることはできず、コードには常にバグが含まれているため、コードにバグが含まれていないことを確認できます。しかし、それはあなたが高い信頼を保つことを可能にします。
プログラマーとしては、誰もコードに自信がないシステムで作業するよりも、何も悪いことはしません。
このアプローチに欠陥はありますか？潜在的な欠点はありますか？
組織のニーズにうまく適合するように、ブランチモデルをよく検討することが重要です。このモデルが一部の人に適しているからといって、必ずしも他の人にとって最適または望ましいというわけではありません。
常にトレードオフがあり、この場合でもです。トレードオフの1つは、ブランチの数と複雑さです。さまざまな種類のブランチを導入することで、ワークフローの複雑さが増します。たとえば、数行のコードを変更して簡単なバグを修正しようとしているときに、常に新しい機能のブランチを作成するように強制するのは間違っているかもしれません。
バグの解決は多かれ少なかれ複雑であることは誰もが知っています。したがって、些細なバグが発見された場合は、複雑さや管理を削減して余分なオーバーヘッドを取り除き、人々がマスターやブランチの開発などに直接コミットできるようにすることができます。しかし、修正の性質がより複雑になるにつれて、修正のために新しいブランチを作成するための余分なオーバーヘッドの価値があります。特に、そのサイズと長さがわからない場合、または自分と他の開発者の間のコラボレーションを改善したい場合。
より良いアプローチがある場合は、共有したり、それに関する記事やディスカッションへのリンクを提供したりしますか？
これは間違いなく良いアプローチであり、ほとんどの場合私たちのほとんどが同様の開発プロセスを持っているため、それはほとんどの場合に適合しますが、すべての人に適しているわけではありません。今すぐコードをどのように処理するかを検討し、既存のモデルに適合する分岐モデルを作成してみることを強くお勧めします。
最も重要な点はgitを使い始めることであり、残りは自然に続くでしょう。シンプルに始めて、徐々に改善していきましょう！クリエイティブに！
乾杯