The general workflow for developing our application is as follows:
- Pull down the latest version of the
masterbranch. - Pick a feature to implement from our requirements list.
- Create a topic branch to keep our changes isolated.
- Write tests that describe the behavior desired by our feature.
- Develop the code until it passes all the tests.
- Commit and push the code into the remote repository.
- Pull down the latest version of the
masterbranch and merge it with our topic branch. - Run the test suite to ensure that everything still works.
- Merge the code back with the
masterbranch. - Commit and push the code to the remote repository.
The previous list should give you a rough idea of what is involved in a typical software project involving multiple developers. The use of topic branches ensures that our work in progress won't affect other developers (called breaking the build) until we've confirmed that our code has passed all the tests and resolved any conflicts by merging in the latest stable code from the master branch.
The practical upside of this methodology is that it allows bug fixes or work from another developer to be added to the project at any time without us having to worry about incomplete code polluting the build. This also gives us the ability to deploy production from a stable code base.
In practice, a lot of projects will also have a production branch (or tagged release) that contains a copy of the code currently running in production. This is primarily in case of a server failure so that the application can be restored without having to worry about new features being released ahead of schedule, and secondly so that if a new deploy introduces bugs, it can easily be rolled back.