マージされたブランチを再利用するのは良い習慣ですか？
現在、私はアプリケーションに新しい機能を追加する必要があるたびに、新しいブランチを作成していました。
機能が完成して機能するようになったら、masterブランチとマージします。
しかし、後で、この機能を更新する必要がある場合（改善など）は、新しいブランチを作成するか、以前のブランチをマスターでリベースする必要がある場合、更新を行ってから再度マージしますか？
たとえば、Ruby on Rails applicationにmodeling-memberというブランチがあります。後で、メンバーモデルに属性を追加する必要がありました（これはこのブランチで作成されます）どうすればよいですか？このブランチをマスターでリベースし、モデルを更新して再度マージするか、単に新しいブランチを作成しますか？
次の理由により、新しいブランチを作成します。
新しいブランチは、完了してマスターにマージしたいときにマージの競合が発生する可能性が低くなります。マージの競合を修正するよりもエラーが発生しやすいものはほとんどありません。
この機能は、元の実装以降、いくつかの変更と更新が行われ、元のブランチが完全に廃止されている可能性があります。それを最新の状態にする唯一の方法は、masterを機能ブランチにマージすることです...そしてその時点で、不必要に複雑な方法でmasterをブランチしているだけです。
単純化するためだけであれば、更新、バグ修正、新機能についても同じワークフローを使用することをお勧めします。これは、分岐、コードレビュー、バグトラッカーの使用など、ほとんどすべてに当てはまります。とにかく、既存の機能を更新すること、新しい機能を追加すること、バグを修正することの違いは、主観的であることがよくあります。
新しいブランチを使用します。
命名については、内部フォーマットの使用を検討することができますthis_workは拡張であるかthat_workに変更します
たとえば、2番目のブランチに名前を付けることができます
modeling-member--attributes
で-左側の名前名が元のブランチであることを示す
支店名にJiraチケット番号を使用するため、同様の問題に取り組みます。同じチケットに対して追加の作業が必要になる場合があります。データベースの変更をロールバックできない場合があります。これらの場合、たとえば、元のブランチSEND-123を使用し、2番目のブランチをSEND-123aにします
マスターのマージからのコミットのみを保存する場合、githubを使用している場合は、すべての新機能に「フォーク」を使用し、すべての新機能が完了した後にプルリクエストを実行してプルリクエストを受け入れることができます。
古いブランチで作業することはお勧めしません。マスターのヘッドにマージすると競合が発生する可能性があるためです。もちろん、その必要はありません...