Question

I quite like Gitflow branching model

but I’m not sure where to put the TDD cycle – should I simply use a feature branch and commit everytime I either wrote or passed a test (plus after refactoring)? Create a sub-branch and merge “finished” units into the feature branch? Should I commit each failing test or only after having it made pass?

Here’s what I currently do, on a feature branch:

1. Write a test, commit
2. The test may yield errors due to non-existing interfaces, fix this, amend commit
3. Make the (now only failing) test pass, amend commit
4. Refactor, new commit
5. goto 1

Answer 1

I’m not sure that this is representative, but just speaking as one developer, I use git-flow and here’s (roughly) my workflow for a new feature:

• Create a feature branch
• Write failing high-level acceptance test (cucumber) that fails with a @wip (work in progress) tag so it is left out of the test suite for now, and commit this to the new branch
• (Sometimes) write rspec request test for integration testing of edge cases, and commit that to the feature branch
• Write lower-level tests (rspec/jasmine) for individual components of the feature, and for each roughly-defined “unit”, commit to the feature branch
• When the feature is finished enough that it passes the acceptance test, take off the @wip tag, make sure it passes and commit to the feature branch
• Merge the feature branch into the develop branch using git merge (and not git flow finish). This leaves the feature branch there so I can update the feature later on if need be.
• Once the branch is merged in to develop, travis-ci runs the full test suite on it and if there’s any problem, I get an email. (I only include the develop and master branches in my .travis.yml file.)

I should say, this is my “ideal” workflow — in actual practice I break these rules a lot: commit an untested change before writing the test, start working on parts of the feature before actually fleshing out the high-level acceptance test, etc. I am basically the only one committing to the project, so I have the freedom to do that; if you’re working in a larger group I think you’d have to be stricter about sticking to whatever workflow you have.

Anyway that’s how I do it. I’d be keen on hearing from other people as well, so I’ve upvoted the question.

UPDATE:

I realized after writing this that there is one sense in which I deviate from the above flow, which is when I’m adding “features” which are not strictly-speaking the normal user-oriented kind (i.e. not things the user would be aware of). For example, early on in developing an app, we decided we wanted to use backbone.js for structuring our js code — so I created a feature branch for it and added @javascript tags to various existing cucumber features. I merged it back once the branch was roughly able to do (with backbone.js) what the original app was doing with HTML views.

I’m also planning to switch to using require.js, and in this case I’ll also create a feature branch for doing this, and once it’s done merge it back. There won’t be any high-level integration test for it — as long as the existing tests pass, it’s all good.