Today I want to share with you a blog article originally written on the Japanese Six Apart blog. The author, my colleague Yuji Takayama, is currently one of the main developers of Movable Type. The post is about Movabele Type's Github repository. Now, let me share with you the current status of Movable Type's development.
The original entry in Japanese: http://blog.sixapart.jp/2012-04/movable-type-code-management.html
Hi. My name is Takayama, and I'm a Movable Type engineer at SixApart. Today I would like to talk a bit about code management, the so called "heart" of Movable Type development.
As many of you already know, Movable Type is currently developed on GitHub, with security fixes developed on our internal git server. When we moved to GitHub, we changed our branch management model in order to increase efficiency.
For those curious, this is what the present system looks like.
Did you notice there seems to be rules on how the branches are named?
Branch Management Rules
Above is our branch management model. This might look a bit complicated at first but is actually quite simple. It is based on the article "A successful Git branching model" and is used in maintenance on past and present versions. All the branches currently on GitHub are shown above. Yes, there are lot of them. When you see the branch's name, you should also notice that branch names and networks are chosen based on management policy.
Master is the branch that is always maintained as the newest, most stable code, and is generally not committed to with changes. When we do major releases, the version is merged to Master and tagged with the version number.
The major development commits for bug fixes and new features are done on this branch. If you want to follow the newest code, you need to check the commits on this branch.
Until the end of a specific version's product support, we do maintenance releases for bugs found in that version on these branches. If the master branch is updated to the next version, we create a new branch called "support-version#" that acts as a master of that version. Like other master branches, merging and tagging after release will take place on this branch.
This is the branch for bug fixes before maintenance releases. This branch is attached to the master branch when the maintenance release is scheduled. After the release is complete, this branch gets merged to the master before deletion.
The Movable Type engineering team sometimes adds on experimental features which we refer to as "Engineering Works". In this situation, we create branches named "feature-the name of feature". These feature branches are generally included among the develop branches.
On a more personal level, individuals can create what are known as topic branches from their own computers. In this way, different people in different places can collaborate on feature development. revise-XX works in the same way as feature-XX.
- If you have an interest in the newest in-production version, check out the develop branch.
- If you want the latest, most-stable version, check out the master branch.
I hope after reading this explanation, you have come to know a little more about how SixApart manages the Movable Type code.