Definition of a feature in GithubFlow model?

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.

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.