ブランチをソロ開発者として使用する利点は何ですか？

最初に、ソロ開発者としてのVCSについて多くの質問が寄せられていることを知っていますが、それらはあまりにも広範であることが多いです。これは分岐のみに関係しますが、依然として重複としてマークされています...想定される重複は、あまりにも広範で、特に分岐に関係しない別の質問の別の重複としてマークされています。それが私の質問のユニークな方法です。

ブランチを単独の開発者として使用する利点がある場合、それは何ですか？ソロ開発のコンテキストでも推奨されることがよくありますが、見る限りでは、開発に「マスター」トランクを使用し、作業用のリリース準備コードに分岐する以外に、どのように見えるのかわかりません開発プロセス全体を過度に複雑にすることなく、分岐の力を活用できます（たとえば、新しい機能を区分化するために）。

利点は、開発者のグループの場合とほとんど同じです。常にリリース可能なマスターブランチと、新しい機能を開発するための機能ブランチを使用することにより、常にマスターからリリースできます。機能の作業中に重要なバグを見つけましたか？ブランチの切り替え、修正、リリース、スイッチバック、開発の継続。

または、これは趣味のプロジェクトであり、気分があなたを襲うように、あなたはちょうどこの機能で少し働くことができるのが好きです。基本的には、タイムスライシングによって複数人のチームをエミュレートしています。

DVCSがクローンで行う暗黙の分岐は、権限のあるリポジトリでの正式な分岐は人の調整ではなく、開発の方向性の調整であり、1人でも複数の作業を行えることを意味します。

長期にわたる開発

一人のチームのブランチは、そうでなければリリースサイクルに適合しない長期実行の開発機能に役立ちます。

数か月にわたるスパンの変更のためにブランチを取ることができ、それでも日常のバグ修正や変更をメインブランチから定期的にプッシュすることができます。

これは、メインブランチが常に展開可能な状態にあり、以前にテストされた他のコードに長時間実行される機能が影響を与えないことが保証されるという点で、単一のブランチの「スイッチ」よりも利点があります。

実験的機能

ブランチは、プロトタイプを作成したいが、デプロイされたコードに組み込むことのできない機能にも役立ちます。最終的に破棄されるブランチでこれらを完了すると、メインのコードベースを不必要に汚染することはありません。

重要なウェブサイトのメンテナンスに使用します。私は唯一の開発者ですが、マスター、開発、および発行ブランチを持っています。

サイトセットアップの私の作業プロセスは次のようになります。

1. 実行可能なマスターブランチを作成します。最初のコミットを行います。

2. Checkout開発ブランチ。何もせずに、マスターにマージするためのテストバッファーとして機能を開発します。

3. チェックアウト問題ブランチ。問題をコーディングし、完了したら開発に引き込み、問題が発生するかどうかを確認し、競合をマージするなどして修正します。

十分な問題がリリースの開発にマージされ、開発の安定性がテストされたら、開発をマスターにプルします。

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

そうすることで、開発中に完全なテストコレクションを取得し、Masterを傷つけたり、有害なコミットをロールバックしたりすることなく、安定性、問題などをテストできます。

また、コミットのために個々のブランチを使用することにより、すでに行った作業を「残す」ことができ、より緊急の問題を修正するために他の何かを新たに開始し、それをより早く展開できます。

実際には、私は通常1つの問題ブランチを持ち、それを開発してからマスターにします。面倒なこともありますが、RightNow™を作成する必要があると誰かが考えていたので、少なくとも2か月に1回は帽子を落とさなければなりません。そしてその後、私がいた場所に進みます。特に、数週間かかる大規模なプロジェクトでは、これはすぐにブランチを切り替えることができるという神聖なものです。

このシナリオを考えてみてください。あなたは常にメインブランチで作業し、AwesomeCodeThing™を使用してマスターブランチを心臓切開手術に残します
。そのようなシナリオで問題を迅速に解決する唯一の方法、

1. 以前のコミットを確認し、
2. 最後の安定したコミットがいつだったかを確認します（cursingはオプション）
3. そのコミットにロールバックする
4. 修正を行い、修正を本番にプッシュ
5. AwesomeCodeThing™ステータスに戻ろうとしているすべての競合と問題を解決します
6. あきらめ、泣き、やり直します。（オプション）

ブランチを使用する場合：

1. チェックアウトマスター
2. ブランチUrgentFix™を作成して修正します
3. UrgentFix™をマスターに引き込む
4. 生産にプッシュ
5. マスターを開発にマージ
6. AwesomeCodeThing™へのマージ開発
7. ビールを飲んで働き続けます。

ブランチを使用すると、一度に複数の機能を簡単に操作できます。これは、プロジェクトの進行中に優先順位が変更された場合に非常に役立ちます。

機能がより重要になったと判断したとします。おそらく、稼働中のシステムの重大なバグに緊急にパッチを当てる必要があります。長期間にわたって複数の機能でクライアントと作業している可能性があり、各機能の進捗を個別にデモすることができます。たぶん、あなたはちょうど厄介なゼロデイの悪用について読んで、クライアントがそれについて読む前にそれを手に入れたいと思うでしょう。

各機能/修正プログラムにブランチを使用している場合、通常、すべてに単一のブランチを使用するよりも、これらの変更を分離して展開する方が簡単、簡潔、迅速です。これは、あなたが唯一の開発者であろうと、チームの一員であろうと、当てはまります。

実際のプロセスに関しては、git flowはうまく機能しています。Daniel Kummerのgit flowチートシートは優れたリソースです。gitを使用していない場合でも、見る価値があります。

他のポスターで述べたように、利点はチームでの作業とほぼ同じです。機能を独自に開発およびテストし、ホットフィックス/プロダクションデプロイ用に個別のマスターブランチを維持し、実験する能力。

個人的には、自分が作業している領域をよく知っていれば、一般的にマスターで作業する傾向があります。とにかくそれらをマージするだけなので、ブランチにオーバーヘッドが追加されます。

しかし、私が持っている場合は任意の私は、私が分岐し、唯一のPR /ブランチが期待通りに動作し、一般的に完全にテストされるとマージします作っています変更について躊躇し。そうすれば、ロールバックがアクションのベストコースである問題を発見した場合、一連のコミット全体ではなく単一のコミットになります（一連のコミットをロールバックする構文を思い出すことはできませんが、単一のコミットは簡単です）。