legacy git workflows
There are many common ways of using git, for example the YOLO method where everybody directly pushes into his master branch. This is a common workflow but well…
There is another approach, for example used by the phpBB team:
You’ve got a master branch which is always even with the latest release. You create a development branch after the release, every topic branch (bugfix or feature implementation) is a branch based on the latest development branch. This is a well known approach but it isn’t very fast (in terms of releasing a new change). but it is mostly used in teams that push a new release (in terms of semantic versioning) every few weeks with a bunch of changes or release at scheduled times (every second tuesday in a month for example).
Rapid deployment?
I’m currently working on several projects that use github and another development model for rapid deployment (how can we name the model?). First of all we need to clarify what rapid deployment is: You basically want to release every change into master directly after it is tested. Many teams are working with agile methods like scrum and kanban, we try to develop many small changes and we directly want to use them.
How does this work with git and github?
The current master code-base is always your development basis, so every new feature and bugfix gets his own so-called topic-branch. You should try to break up a huge new feature into smaller changes, they should be as small as possible but as huge as they have to be to be working without applying the other changes of the new feature (does somebody understand what I mean?). Every change should get his own commit, than you create a pull request for this single commit which gets hopefully soon reviewed and merged into master.
Why so many pull requests?
We don’t use the YOLO method so we don’t push to master directly, somebody else has to review our changes and merge them into master. A review always takes time, so document your code, use a meaningful commit message and commit description. What also speeds up reviews? Small changes! This is really important for open source projects, many contributors have a 9-5 job and contribute in their spare free time, most people contribute more if they can do it in small pieces so they are happier with small pull requests.
But there is no testing branch!
Yeah, so? Nobody needs a testing branch. Testing is very important, you can use CI systems like Travis CI to hook up on your github repos. Every commit will trigger a travis job will than will trigger all your defined tests. Github has a nice solution to display the test result in a PR so the reviewer directly notices if the changes are working or not. This all works without a dedicated branch for testing.
Conclusion
This is a cool method if you want to deploy changes very fast. It is uses in many project in the puppet world, I’m also trying to use it for my own VirtAPI projects, which development model do you use? Let me know!