2

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?

MrNorm
  • 407
  • 4
  • 13
  • This can help: http://stackoverflow.com/a/18899910/6309 – VonC Sep 30 '13 at 10:19
  • It does somewhat, but what if a client wanted to see 2 tickets alongside each other and only signs one off to go into production? – MrNorm Sep 30 '13 at 10:46
  • Then you would revert ([`git revert`](http://git-scm.com/docs/git-revert)) the commit of the second ticket in the `integration` branch, and merge that new `integration` `HEAD` to `master` (or `prod`) branch. – VonC Sep 30 '13 at 10:49
  • Hmm, I'm not so sure that'll work. We can't freeze changes due to the nature of the client. Also, if we get a large change set come in, then having to revert all of those out of integration before we can pop it into master/prod would be time consuming. One thing we could do is set up a remote origin/environment to automatically host each feature branch. At least once a feature is signed off we could put it into integration. – MrNorm Sep 30 '13 at 13:52
  • time consuming? `git revert` is build to *quickly* revert large number of files. If there are no conflicts, then it is instantaneous. – VonC Sep 30 '13 at 14:32
  • Would it work in http://cl.ly/image/3w1c0F0k0l0U this situation? 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? – MrNorm Oct 01 '13 at 09:08

2 Answers2

1

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".

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Thanks for the edit and clarification. Would I need to revert both instances of "Merge branch 'feature/si002' into develop" (there are more than one there)? – MrNorm Oct 01 '13 at 09:49
  • @MrNorm yes, a revert of the two merge commits, starting by the newest, then the oldest. – VonC Oct 01 '13 at 10:16
  • Hmm, I'm starting to think our workflow in general is wrong now. I know on one project, we have 6 ongoing 'features' with multiple merges to 'develop' for UAT. If we had one text change feature that got signed off, we'd need to undo all of those merges. Which, as much as it is a simple command would get time consuming and/or prone to user error. Would having a 'develop' and an 'staging' branch agnostic of each other (but having features merged to both them) be a no-no? – MrNorm Oct 01 '13 at 10:54
  • @MrNorm a staging branch is generally a good idea, in which you can integrate features that you *know* must go into production. Having two branches doesn't mean they have to be merged at some point: they can fulfill different objectives, independently one from another. – VonC Oct 01 '13 at 11:10
  • I think that could be it then. So, we'd have develop, staging and feature branches. A feature branch can be merged to develop until UAT is complete and it's signed off, then the feature branch can be merged (again) with staging, ready to be merged with master. Would that work? – MrNorm Oct 01 '13 at 11:30
  • @MrNorm it does work, it your release cycle allows it: it doesn't work well for daily production release. It works well for releases every week or more. – VonC Oct 01 '13 at 11:50
  • It's not far off what we do currently really. All development happens in a 'dev' branch in SVN, then changes are cherry picked over to trunk, which is then deployed. I think this method is a bit more solid as all changes for a feature/ticket are in one place. Thanks for your patience and advice :) – MrNorm Oct 01 '13 at 12:20
0

Take a look at git flow. Git flow is branching strategy that also comes with some nifty commands to help you along the way.

http://nvie.com/posts/a-successful-git-branching-model/

crea1
  • 7,749
  • 3
  • 32
  • 39