Search code examples
phpgitsvnmerge

Git: Best practices for ticket based workflow

I'm looking to progress a move from SVN to Git at the company I work for. The issue I'm having is getting my head around a decent workflow.

Typically for a PHP project in a post-launch state, the client would create a ticket for some work with an ID (smeg23452). In SVN, we would typically put the ticket ID in each commit on the develop branch and then cherry pick those changes and put them into the trunk. It's okay, but there have been times where merges have failed or developers have failed to put ticket numbers against work.

In an ideal world, I would like to be able to have a branch in Git for the ticket (e.g. smeg23452), merge smeg23452 into develop when changes have been completed and then merge smeg23452 into staging which will be tested, staging will be merged to master ready for deployment live (not merge develop to master, which seems to be common practice). A client may typically create 5 tickets, want to see them in the develop environment online and then pick only 3 of those tickets to go live which is why I need to be able to keep them far away from other environments.

Have I got it all wrong?

Solution

  • I was referring to "Git branching strategy integated with testing/QA process" as an integration process.
    I was pointing out git revert to quickly exclude features that must not go into prod just yet.

    But the OP MrNorm asks:

    Would it work in this situation?

    http://cl.ly/image/3w1c0F0k0l0U

    Branches si001 and si003 are OK in develop (client visible environment) and have been requested to go live, but si002 needs to go.
    As we've had 2 merges of it to develop, would we need to revert those one by one before I can merge develop to master

    You would revert only the merge commit "Merge branch 'feature/si002' into develop".