Should I use release branch to push my changes?
What is the recommended practice?


The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful.

The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times a day will prefer tag then release from master. A team that releases once a sprint into an integration test environment for a week before it goes live will generally prefer two branches. 


  Should I use a release branch to push changes out to production or release it off master branch 


My personal experience is that adding branches later if you need them is easy but removing branches is very hard. So given that we want to minimise the number of branches I recommend that small teams who release often always release from a tag applied to master. It's very easy to create a branch from the tag that was last put live if you do need to create a short-live patch release branch. The point is that you want that to be the exception not the rule give the research in the book named above.

I have seen many teams use a two branch approach. To common ones are:


Integrate code into a ”develop” branch and deploy to an integration test environment. Then cherry-pick signed-off work down to master where it is tagged to release.
Integrate code into ”master” and deploy into a test environment. Then cherry-pick signed-off onto a long-lived ”release”  branch where it is tagged to released.


These approaches are actually identical. The reason to take this “two branches” approach is so that features can be released independently and reordered. 


  Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.


There isn’t really enough information in your question about how your team actually works to know whether a one or two branch strategy would be a good fit. Your actual release, testing and support ways-of-working dictate the best strategy for your team.