ブランチをソロ開発者として使用する利点は何ですか？
最初に、一人の開発者としてのVCSについて多くの質問がなされてきたことを承知していますが、それらはしばしば広範すぎます。これは分岐のみに関係し、それでも重複としてマークされています...想定される重複再び、広すぎて分岐に特に関係のない別の質問の別の重複としてマークされます。これが私の質問のユニークな方法です。
ブランチをソロ開発者として使用する利点は何ですか？ solo-devのコンテキストでも推奨されることはよくありますが、「マスター」トランクを開発に使用したり、機能するリリース対応コードに分岐したりする以外は、どのようにしたらよいかわかりません開発プロセス全体を過度に複雑にすることなく、分岐の力を利用できます（たとえば、新しい機能を区分化するため）。
利点は、開発者グループの場合とほとんど同じです。常にリリース可能なマスターブランチと、新しい機能を開発するための機能ブランチを使用することで、常にマスターからリリースできます。機能の作業中に重要なバグを見つけますか？ブランチの切り替え、修正、リリース、切り替え、開発の継続。
あるいは、これは趣味のプロジェクトで、気分に合わせて、この機能とその機能について少し作業できることが好きなのかもしれません。基本的に、タイムスライシングによって複数人のチームをエミュレートしています。
DVCSがクローンに対して行う暗黙の分岐は、権限のあるリポジトリ上の正式な分岐は、人々の調整ではなく、開発の方向性の調整よりも重要であり、1人でも複数のことを行うことができます。
長期的な開発
一人のチームのブランチは、リリースサイクルに適合しない長期的な開発機能に役立ちます。
複数の月にまたがる変更のためにブランチを作成し、日常のバグ修正やメインブランチからの変更を定期的にプッシュすることができます。
これは、メインブランチが常に展開可能な状態にあり、長期実行機能の何も以前にテストされた他のコードに影響を及ぼさないことが保証されるという点で、単一ブランチの「スイッチ」よりも優れています。
実験的機能
ブランチは、プロトタイプを作成したいが、デプロイされたコードに含まれない機能にも役立ちます。私が最終的に捨てられるブランチでこれらを完了することは、メインのコードベースを不必要に汚染しないことを意味します。
重要なウェブサイトのメンテナンスに使用します。私は唯一の開発者ですが、私にはマスターがあり、ブランチを開発して発行します。
サイト設定の私の作業プロセスは次のようになります。
実行可能なマスターブランチを作成します。初期コミットを行います。
チェックアウト開発ブランチ。何もしないで、マスターにマージするためのテストバッファーとして関数を開発します。
チェックアウト問題ブランチ。問題をコード化し、完了したら、開発に引き込み、問題が発生するかどうかを確認し、競合をマージするなど...それらを修正します。
十分な問題がリリースの開発にマージされ、開発の安定性がテストされたら、開発をマスターにプルします。
Master
|
Develop - E
/ | \ \
A B C D
このようにして、開発中に完全なテストコレクションを取得します。マスターを傷つけたり、有害な場合はコミットをロールバックしたりするリスクなしに、安定性や問題などをテストできます。
また、コミットに個別のブランチを使用することで、すでに行った作業を「残す」ことができ、何か別のことからやり直して、より緊急の問題を修正し、それをより早く展開できます。
実際には、通常、1つの問題ブランチがあり、そのブランチを開発でマスターにプルします。面倒なこともありますが、RightNow™を作成する必要があると誰かが考えていたので、少なくとも2か月に1度は作業を一瞬でやらなければなりません。そうすれば、すぐに基本状態に切り替えることができます。その後、私がいた場所に進みます。特に数週間かかる大規模なプロジェクトの場合、これはすぐにブランチを切り替えることができるという神の信念です。
このシナリオを検討してください。常にメインブランチで作業していて、AwesomeCodeThing™を使用してマスターブランチを開胸手術にすると、緊急修正が必要なYugeBug™がポップアップします。そうしないと、何千ものユーザーがBigProblems™について不満を言うでしょう。
このようなシナリオで問題をすばやく解決する唯一の方法は、
- 以前のコミットを確認し、
- 最後の安定したコミットがいつ行われたかを確認します（呪いはオプションです）
- そのコミットにロールバックします
- 修正を行い、修正を本番にプッシュします
- awesomeCodeThing™ステータスに戻ろうとしているすべての競合と問題を解決します
- あきらめて、泣いて、仕事をやり直します。（オプション）
ブランチを使用する場合：
- チェックアウトマスター
- ブランチUrgentFix™を作成して修正
- urgentFix™をマスターにプルします
- 生産にプッシュ
- マスターをマージして開発する
- MergeはAwesomeCodeThing™に発展します
- ビールを手に入れて、仕事を続けましょう。
ブランチを使用すると、一度に複数の機能を簡単に操作できます。これは、プロジェクトの進行中に優先順位が変更された場合に非常に役立ちます。
今、機能がより重要であると判断したとします。おそらく、稼働中のシステムの重大なバグに緊急にパッチを適用する必要があります。長期間にわたって複数の機能でクライアントと作業している可能性があり、各機能の進行状況を個別にデモしたい場合があります。たぶんあなたは厄介なゼロデイエクスプロイトについて読んだばかりで、クライアントがそれについて読む前にそれに乗りたいと思うかもしれません。
機能/修正プログラムごとにブランチを使用している場合、通常、すべてに対して単一のブランチを使用するよりも、これらの変更を分離して展開する方が簡単、明確、迅速になります。これは、あなたが単独の開発者であっても、チームの一部であっても当てはまります。
実際のプロセスとしては、gitフローがうまく機能していることがわかりました。 Daniel Kummerの git flow cheat sheet は素晴らしいリソースです。gitを使用していない場合でも、一見の価値があります。
他のポスターで述べられているように、利点はチームでの作業とほぼ同じです：機能を個別に開発およびテストし、修正プログラム/本番展開用に個別のマスターブランチを維持する機能、実験。
個人的には、自分がよく取り組んでいる領域がわかっていれば、通常はマスターで作業する傾向があります。マージするだけなので、ブランチのオーバーヘッドが増えるだけです。
ただし、私がanyに加えた変更についてためらいがある場合は、分岐し、分岐が期待どおりに動作し、一般に完全にテストされた後にのみPR /マージします。そのようにして、ロールバックが最善の行動方針である問題を発見した場合、それはシリーズ全体ではなく単一のコミットです（一連のコミットをロールバックする構文を覚えることはできませんが、単一のコミットは簡単です）。