Development and testing branch in @nvie's Git branching model?

Question

I've read about @nvie's Git branching model and gitflow and I think this is a good model to use for a project (web application) I'm currently working on.

I'm the lead developer of the project and I develop on a local environment (MAMP-like). Whenever I've made something to show the client, I commit my work and push it to a central Git host. From there I deploy it to a server connected to the internet. Then my client can see the changes.

A second developer just started working on the project. He develops single features at a time and pushes them to the central Git host when they're ready. I review his work before deploying it.

Currently all commits are done in the master branch and are deployed to the single hosted environment. In the future I'd like to have a production environment (for real usage), testing environment (to test new versions of the app just before they're released), and a development environment (where I can show features that are finished or still in progress to the client). I think the production environment would get deploys from master, while the development environment would get deploys from develop.

The questions I have are the following:

1. I'm often working on several tasks at the same time. When a part of a feature is ready, I sometimes want to show it to my client before I continue to work on that feature. However, to my understanding, a feature (branch) would only be merged to develop when it's finished and scheduled for release. How can I show features that are in progress (or not yet scheduled for release) to my client (in the development environment)?

2. From which branch should I deploy to the testing environment? Should I manually pick the release branch of that moment, or could there be a dedicated testing branch?

Answer 1

Here's my take on this:

1. You can deploy the feature branch you want to show to the development environment. Just remember to deploy the develop branch after the client has seen the new feature.

2. For the testing environment you use the release branch. After the testing period is over and you have released your app, you would deploy the master branch to the testing environment until the next release schedule.

Disclaimer: I am the developer of git-flow (AVH Edition)
What you need to remember is that the original gitflow software doesn't delete remote feature and release branches. So when you finish a feature or release with the original gitflow you need to manually delete the remote branches. In git-flow (AVH Edition) the software takes care of it.

Answer 2

Feature branches can be switched to at any time with 1 command (git checkout). Sometimes (in rails, development mode I keep the app server up and switch code out without even restarting the server!). regardless of which branch I am in I am still in 'development' mode.
So switch to the branch you want and demo that. then switch back to master or whatever branch you want.
Initially I worked all in master at some orgs but now I do all my work - features, chores or bugs in branches. Often I'll tag the branch name and/or commit text with the id from the tracking system (Pivotal Tracker in our case).
The trick is to keep branches up to date with frequent git fetch's of the latest master and git merge master (while in the 'topic' branch).

For the other environments I have remotes configured, e.g. mycoolapp-stage and I push code to them separately. I have about 6 different remote for 1 app, 4 of them used for testing.

As for testing, the tester can either pull down the changes and work locally in a development environment (works for both programmers and QA testers) or they can just use a testing or staging area that you push code to as a remote.

Overall, you work in branches and then push stuff through master. See more info at my answer on the process at git branch, fork, fetch, merge, rebase and clone, what are the differences?