git merge - Git Development vs Release branch best practices -

i have been monitoring 2 branches starting each sprint - release , master.

master branch developers create new branch(task specific), implement changes, , creates pull request gets merged master.

release branch sprint specific remains submittable production. merge branches committed master , verified qa release branch.

this approach works best submit release @ fix regular interval specific functionality implemented , verified, , hence know what's going in next release.

this question continuation of avoid-merging-master-into-development-branch , git-merging-only-branch-specific-commits

in 1 line want

"make sure development branches verified qa goes next release candidate."

i have thought of use following workflow options previous discussions;

git pull --rebase master taska //work on taska branch, multiple commits, , execute command multiple times whenever required; @ time of rebasing taska master git checkout taska git rebase -i origin/master // remove commits not belongs taska. git checkout origin/master git merge taska 

this workflow give me clear history each of branches rebased on master verified qas. can rebase verified branch release branch.

am going in right direction? git-flow works best? there better way of doing want achieve?

here's problem.

we merge branches committed master , verified qa release branch.

this means have integrate feature branches twice. once master , again release. you're struggling obvious problem: how make sure integrated master integrated release? , because features build on other features, have in similar order.

don't try solve problem. it's hard , messy , you'll have careful. better have process that's more foolproof. let's go stated goal.

make sure only development branches verified qa goes next release candidate.

(emphasis mine) that's not goal, that's solution implement goal. what's real goal? how this...

make sure only code has been verified qa goes next release.

see did there? quality release doesn't care code came from, cares state of code being released. want make sure nothing hasn't been checked qa goes release. that, suggest changing workflow version of gitflow workflow. goes this.

1. developer has task do.
2. developer branches off master, let's call task.
3. developer works on task.
   1. developer writes own unit tests task.
4. developer gets updates master when need them.
   1. they can rebase or can merge, doesn't matter.
5. developer finishes task.
   1. developer final update master.
   2. developer makes sure unit tests , regression tests pass.
   3. optional developer submits task qa acceptance testing.
   4. developer merges master.
   5. developer deletes task.

because developers writing own unit tests, @ point know in master has been unit , integration tested. important or hairy features have been acceptance tested in 5.3, don't bother qa @ point.

it important healthy workflow master kept in state of high quality. means developers have involved in testing process. there's no throwing on wall qa , hoping best, qa should spending time on acceptance , blackbox testing catch bugs developers not think of. master release candidate.

when decide you're ready release...

1. match testing branch master.
   1. you can merge master, rebase on master or delete , recreate testing branch. each have slight advantages , disadvantages become apparent.
2. qa gets list of changes have been added since last release.
   1. they can issue tracker.
   2. if testing rebased off master can git log , @ merge commits since last release.
3. have qa acceptance test change list against testing.

let's pause here , explain why step 3 important. qa final line before users see it. it's important qa testing users use. users see integrated code base, not individual feature branches working in isolation, qa should focus efforts on integrated release.

features can work great in isolation, , have weird bugs when they're combined. simple example feature changes project's encoding ascii unicode. developer dutifully changes whole system use unicode , it's great. meanwhile developer works on task includes changing views. they're not thinking character encoding, , write views ascii assumptions. developers horrible testing views. tested in isolation, feature branches work fine. combined together, qa can catch view still using wrong character encoding.

moving on.

4. qa finds bugs , reports them developers.
   1. developers patch testing (directly small things, in branch big things)
   2. optional developers cherry-pick fixes master. it's optional because taken care of later.
5. qa declares testing ready release.
   1. release git merge --ff-only testing. if doesn't fast-forward, have hotfixes in release need backported.
   2. tag release version number.
   3. release pushed production.
6. testing merged master.

that final step ensures patches bugs found in qa process merged master. why said earlier doesn't matter how reset testing, merged master anyway.

there have it. process ensuring code released has gone through qa. except developing change log qa, there no careful tracking of what's been integrated necessary.