Symphony.

I know the title looks full of keywords but hopefully I'll manage to explain my 'issue' if you could call it one.

I'm working with a team of 3 other developers on a multitude of websites / projects. Unfortunately management never know what they want / get their priorities right. So we end up developing a lot of stuff that stays on the side for some time awaiting approval whilst other changes have to go ahead.

Since I convinced everyone and made the move to Git we've been far off better and have better control on our code + deployment.

The only issue I've been having is that our main 'dev' branch where we do our changes to stage them on a development machine is getting littered with unapproved changes, thus having to cherry-pick the approved work into our Staging which was a pain.

I've asked everyone to use branches recently and whilst it helps me merge branches instead of cherry-picking commits it still leaves me merging stuff at different order then our dev branch making it an unclean working space.

I was wondering what solutions are any of you who experience the same problem have implemented.

I put in a request to our IT admin to modify the checkout script to allow us to use any branch we like or switch using a web-interface. However it seems it cannot be implemented quick enough.

Have you looked at git-flow yet? (https://github.com/nvie/gitflow) It makes a pretty big difference to keeping the rules clear, so there's not as much noise getting merged/rebased.

yes its what i based our branches / merges etc.

What I found out it is that it would work great for applications / websites which are to be released in a particular order. However what I need to do is make stuff I have in branches accessible to the outside (public domain) as sometimes final approval is given by someone in another country. The problem is that we usually develop something like 3-6 features which are awaiting final approval.

Currently our deployment system allows us to only deploy a single version thus I can only show one branch, which means I would have to merge everything. Due to shifting of priorities, last-minute changes and what not its impossible to keep this environment clean...

Its hard to convince my senior & management especially that anything which is not 100% confirmed shouldn't be merged in. So I'm looking to see if there's a possible work around.

Github Flow is another method that I like. A mix of both can be useful.

Thanks for these tips guys, they are both very useful!

Currently our deployment system allows us to only deploy a single version thus I can only show one branch, which means I would have to merge everything. Due to shifting of priorities, last-minute changes and what not its impossible to keep this environment clean...

It sounds to me like you have process issues, not technical ones. No software will be able to help you manage your releases/deployment if you can't keep your clients and your own requests under control.

I hate working under them at big organisations, but a formal change process might be what you need here to manage how releases are approved, and to drive home what out-of-band changes do to releases.

Last minute fixes should be easy enough to manage if you're using git-flow, as you should never be working directly against master or develop anyway — just tag a release, and then start a new hotfix off that release. Skip deploying the initial release, and deploy the release that gets tagged from the hotfix branch.

So take away all commit access to develop from your developers (and yourself) and only use it as a place that you merge branches back into before they are released.

Does that make sense?

So take away all commit access to develop from your developers

Do you have any means of doing this Tony? I didn't think it could be done.

Indeed tony you could call it process issues. We've had approved mockups change several times in a week simply because they wanted something quick but were not convinced about what they wanted...

I was indeed thinking of having every branch being based up on the master. Similar to the Github Flow I guess (thanks John) but wasn't sure how it would work out exactly. I would presume every task no matter size would have its own branch and each merged separatly first into dev / testing branch for approval and then into master ready to be deployed.

What I'm afraid that might become more of a hassle is database updates / synchronization when required. That is if I have to branches which each attach a data-source to a particular page. CDI or manually copied queries will be adding this singular ds, when merged into dev say running the same update would override the other. It would be interesting to know how you manage this.