Simple suggestion: don't do that.

git branches are not for long-running forks of the code, as discussed here and https://newrelic.com/blog/best-practices/long-running-branches-considered-harmful. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to something a project manager (let alone end user) might care about you are doing something wrong.

Recommended practice is to use continuous integration with feature toggles or branch-by-abstraction to ensure that:

• all code is integrated at all times (at least every day, preferably more often)
• what gets deployed is under explicit control.

Simple suggestion: don't do that.

git branches are not for long-running forks of the code, as discussed here and here. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to something a project manager (let alone end user) might care about you are doing something wrong.

Recommended practice is to use continuous integration with feature toggles or branch-by-abstraction to ensure that:

• all code is integrated at all times (at least every day, preferably more often)
• what gets deployed is under explicit control.

Simple suggestion: don't do that.

git branches are not for long-running forks of the code, as discussed here and https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to something a project manager (let alone end user) might care about you are doing something wrong.

Recommended practice is to use continuous integration with feature toggles or branch-by-abstraction to ensure that:

• all code is integrated at all times (at least every day, preferably more often)
• what gets deployed is under explicit control.

Simple suggestion: don't do that.

git branches are not for long-running forks of the code, as discussed here and https://newrelic.com/blog/best-practices/long-running-branches-considered-harmful. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to something a project manager (let alone end user) might care about you are doing something wrong.

Recommended practice is to use continuous integration with feature toggles or branch-by-abstraction to ensure that:

• all code is integrated at all times (at least every day, preferably more often)
• what gets deployed is under explicit control.