Git-flow for the system that others have heavy dependency on

Question

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.

Answer 1

I've done something like this...not convinced it was a good idea though

So we did something similar to what you're describing at my previous company, where we had a "throwaway" branch where people could just quickly push their changes for demoing purposes. It was understood that this branch may be unstable and contain bugs. I'm not entirely convinced that it was helpful to have this sort of process in place, but I'm not going to discuss the merits or pitfalls of the approach in this answer.

A solution to overwriting other developers' work

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.

If you're worried about people overwriting other people's work, you can disable force pushes for an entire repo by setting this in the repo's git config:

# In repo
git config receive.denyNonFastForwards true

You could create another remote instance and set that config, then have your developers push a copy of their work to a shared branch there. It's still possible to "overwrite" the branch by deleting it, then pushing your copy of it, and there's a setting that will disable that in an individual repo too, receive.denyDeletes, but disabling remote branch deletion can make it inconvenient for when you actually do want to delete the branch remotely...so I guess that's up to you.

Answer 2

Update.

We just executed our plan AS_IS, and it seemed smooth process so far. Engineers just over worried about all of situations because we are creating ton of feature branch and sometimes liveops bug fix branch.

Engineer merge their feature in adhoc branch, and push it to test environment ( they can use adhoc test environment if they don't mind someone "possibly" overwrite their code during merge by accident ), or create their own test environment which other systems can pointing.

Once it's done, other process is exactly same like NVIE Git-Flow model. Just need more love & attention for "what's coming next release" and "what's the prerequisite/dependency for your live push". If your team has highly depends on some database side change (like stored procedure ) and that's not handled by your team, make sure it's way easy to wait your merge until you get updates that CR has been deployed and ready to go instead of merge it to develop branch first after test and worrying about if you have to revert your change if database change request is delayed. ( this case, there should be backward-compability guarantee, probably your and other team will if you have many years of experience though )

We'll regularly delete adhoc branch and recreate it from latest develop branch to sync-up.