Definition of a feature in GithubFlow model?

Question

I have been using git for a while now primarily on CLi. I am the only person working on this project so far. I just have 1 master branch and 1 production branch. The production branch is named such that all tests in that branch pass. I work directly on the master branch.

I had a issue recently, which prompted me to think that perhaps I wasn't using the best practices. I finished working on a featureA, and started working on featureB. While working on featureB, I made some changes to the code for featureA, but didnt run the tests for featureA. Later while running the tests for featureB, I also decided to check that featureA works, and tests for featureA stopped working. This prompted me to think of how I am defining a feature and perhaps I should be able to isolate the work I do on each feature. This would help me quickly figure out what changes have led to this bug. Its only in hindsight that I am defining these as featureA and featureB.

While talking to some other people, I realized that I am supposed to be using branches for each feature, and then merge them as I complete each feaure.

To figure out an appropriate workflow, I came across 2 main workflows: gitflow proposed by Vincen: http://nvie.com/posts/a-successful-git-branching-model/

and

github-flow proposed by Github: https://guides.github.com/introduction/flow/

and have also reviewed multiple other documents such as:

code review with git-flow and github,

comparisons of the 2 workslows: https://www.youtube.com/watch?v=nPNA8ZfDjKM

From these, it seems that gitflow is too much of a overhead, since I am working by myself. So I thinking of using github flow.

Question

1. I understand that I should create branches off master, in the GitHub flow model of working. However, how do you define a feature? Because I am working by myself on this codebase, I considered the entire package as a feature, and which led me to working on a single branch. However, after reading the Githhub flow and gitflow models, it seems the definition of feature is much more granular. I haven't come across a definition of what a feature stands for in these and other documents I have read so far. Is a feature a function, a class? I also use the github issues periodically to file away changes that I think would be useful, but I dont have time now. Should I use the GitHub issues to create issues, and then use them to create features out of them?

Answer 1

There isn't a clear definition. Usually, the scope of features would depend on the development process of the team. A feature might be a typo fix, or a complete reimplementation of a module. It depends.

One good approximation: a feature is whatever can be reasonably reviewed as a pull request, and still be “complete”. Frequent small changes are annoying, but a huge pull request is totally unreviewable. Like a class, a pull request should be cohesive, and not do numerous weakly related things. A feature must be sufficiently complete so that it can be merged without breaking anything.

This doesn't mean that a feature must be immediately shippable! Many Git problems disappear or are reduced if you merge early, merge often. This means that features should be small, and should be merged even before they are completely ready. One way to manage that is to use feature toggles: parts of the feature are already in the master branch (and can therefore be integrated with other changes), but must be explicitly activated by some switch. So these incomplete features will not be used in production.

As you are a solo developer, all of this doesn't really apply. You could generally develop one feature at a time, without having to branch and merge at all. That is a totally valid process. The branching model should serve your needs, not the other way round.

It is therefore a bit surprising that you are trying to implement both GitFlow and GitHub Flow. These two sound similar, but have very different goals.

• GitFlow is a fairly heavy-weight branching model that tries to coordinate multiple developers, and assumes that you have a clear concept of a released version that you then support for some time.
• GitHub Flow is a fairly light-weight branching model that tries to showcase GitHub features like pull request comments, and assumes that you do continuous deployment from your master branch.

The overlap between these two branching models is “the master branch represents what has been released” and “development happens on feature branches”. Those are good but not necessary ideas. E.g. it is also common to use the master branch as an integration branch, but not necessarily deploy/release this state. Releases would instead be marked with tags. So it might be sensible to look at existing branching models, then set them aside and come up with a process that works for you.

One aspect that didn't seem to work in your experience was testing. Where do these workflows assume testing?

• In GitFlow, there would typically be testing while merging the feature branch into the development branch, and more thorough QA while you prepare a release branch.
• In GitHub Flow, the pull request is reviewed, and automated tests run as part of your deployment pipeline. The deployment proceeds only if the tests succeed.

In all cases is it sensible to run the tests locally before committing and/or pushing changes. This helps to detect problems early. One generally sensible approach: every commit should build successfully! It is fairly straight forward to set up a build server (e.g. with Jenkins) that builds the newest commit whenever you push your code. That way, you can run quick tests before check-in, and let a comprehensive test suite run afterwards.

If you use feature toggles, the tests should account for this. If the tests run in order to check whether the integrated code works, all features should probably be enabled. If you run the tests in order to QA a release, you of course want to test the configuration that you are going to release. It is not generally feasible to test all combinations of feature toggles separately, which is why they should be removed as soon as the feature is permanently enabled.

---

To summarize: There isn't a clear definition. A “feature” is often some kind of change that sits between “individual commit” and “release”. When working alone, keeping a clear distinction is probably not necessary. When working with other people, it is more important to follow a common process that serves your needs than it is to follow some existing process. But whatever you do, automated tests are super helpful.

Answer 2

We use featurebranches a lot. A feature in this context would be the delta that would result in a shipable product. A PBI might be a feature, sometimes a few PBI's together if it really doesn't make sense to ship one of them without the other. (for example it doesn't make sense to view a tax report without being able to enter the relevant information and the other way around)

Examples of this would be a new feature to your product (hence the game). A new screen, a new export template, a new button in the screen (including functionality behind the button of course).

The decision to actually go to production would be up to the product owner (in scrum) or agreements you made with the customer. But master would always contain work that could go to production if asked to do so. And a featurebranch should be the least amount of work to get your code into that state again.