マージされたブランチを再利用しますか？

現在、アプリケーションに新しい機能を追加するたびに新しいブランチを作成していました。

機能が完成して機能するようになったら、それをmasterブランチにマージします。

しかし、後で、この機能を更新する必要がある場合（改善など）、新しいブランチを作成する方が良いですか、マスターで以前のものをリベースする必要がありますか？更新してから再度マージしますか？

たとえば、Ruby on Railsアプリケーションにmodeling-memberというブランチがあります。後で、メンバーモデル（このブランチで作成された）にいくつかの属性を追加する必要があります。私は何をすべきか？このブランチをマスターでリベースし、モデルを更新して再度マージするか、単に新しいブランチを作成しますか？

次の理由により、新しいブランチを作成します。

• 新しいブランチは、完了してマスターにマージするときにマージの競合が発生する可能性が低くなります。マージの競合を修正するよりもエラーが発生しやすいものはほとんどありません。

• この機能は、元の実装以降にいくつかの変更と更新が行われている可能性があり、元のブランチは完全に廃止されています。これを最新の状態にする唯一の方法は、マスターを機能ブランチにマージすることです...そして、その時点で、不必要に複雑な方法でマスターから分岐しているだけです。

• 簡単にするためだけに、更新、バグ修正、新機能に同じワークフローを使用することをお勧めします。これは、分岐、コードレビュー、バグトラッカーの使用、その他ほとんどすべてに適用されます。とにかく、多くの場合、既存の機能の更新、新しい機能の追加、およびバグの修正の違いは主観的です。

新しいブランチを使用します。

命名については、this_workが拡張であるか、that_workに変更するという内部形式の使用を検討できます

たとえば、2番目のブランチに名前を付けることができます

modeling-member--attributes

with-左側の名前nameが元のブランチであることを示す

ブランチ名にJiraチケット番号を使用しているため、やや似たような問題に取り組んでいます。同じチケットに対して追加の作業が必要になる場合があります。データベースの変更をロールバックできないことがありました。そのような場合、たとえば、元のブランチSEND-123と2番目のブランチをSEND-123aとして使用します

マスターでのマージからのコミットのみを保存し、githubを使用している場合は、すべての新機能に対して「フォーク」を使用し、すべての新機能が完了した後にプル要求を実行し、プル要求を受け入れます。

古いブランチで作業することはお勧めしません。マスターのヘッドにマージすると競合が発生する可能性があり、もちろんそれを行う必要はありません...