My team has been used SVN for a long time, and we are going to move our source repo to Git soon. In my team, there at at least 10+ dedicated developers for the system and more developers who frequently touch systems codebase.

Since our system has many features like account management, payment, 3rd party connection, etc, almost every systems in the company has dependency on it, and we should always deliver early feature implementation in dev(or QA) to allow others develop their feature.

With Git-flow model we are trying to use, I see some issue.
1. Due to 2nd reason I've mentioned, we should provide basic functionality to other team for their testing & QA. Also, some feature only takes 1~2 days to develop and deployed next week whereas big feature touching many parts would stay in dev or QA environment more than couple of months. It's impossible to merge it to release QA branch and deploy with other features at the same time.

Best way would be asking developers create their own test instances on company's test VM so that other system can point, but unfortunately we have some limited VM resources right now and can't create many VMs as we like.

So What I'm thinking right now is, as team did same way before in SVN based.. We are going to introduce "adhoc branch" ( or "test branch" ) which allows engineers just dump their code into the branch only for "dev testing for others" and run it with VMs.
There will be no merge from this branch, and even sometimes branch will be re-created from develop branch. And once other systems finish their implementation, we push that feature branch into develop branch, and brach off next release QA branch from it, etc. ( following Git-Flow)

One problem of this is, since people will keep dumping their code here, there is no guarantee your code will stay their as you initially committed ( others can overwrite yours ). I'll tell other folks about the purpose of this branch/instance and don't point this for release QA, etc.. but I'm wondering if there is any simple solution for this situation.

We definitely don't want cherry-pick for this since we experienced too many pitfall of cherry-pick. 

Thanks for reading.