Chicago says Hello to Katherine,
First thanks for the time and energy to share this. I am adopting
Git and researching workflows to manage development and builds of 20
plus and growing different client releases of a handful of batch
applications I need to support.
First, when you say you merge the final QA branch to master, are
you rebasing QA with master prior to merging? then deleting the
feature branches which made it into the release?
Second, I understand the need to have developers merge after a
commit to a shared integration branch. Do I correctly assume the
integration branch is created from origin/master from the point of the
last release? And, do I assume that the integration branch remains
until the next release? Meaning where as the QA branch is recreated
when the completion of a new feature is ready for testing, the
Integration branch remains until the final QA branch is merged back
Third, what happens to the integration branch when a feature is
dropped (as in it was a requirement but now VP says to forget about it
until I tell you otherwise ) mid-development from the upcoming
release? Meaning other features are still undergoing development for
the upcoming release. Do I assume to recreate the Integration branch
like you do the QA except to leave out the dropped feature?
Lastly, is the submit pull request executed, or is it just for the
purpose of a code review? I do not see how the pull request would
actually be executed since the developer would have already pushed to
origin/Integration and origin/QA.
Thanks and I am definitely hope you publish the $ git newqa.
More information about text formats