Not a developer? Go to MovableType.com

News

Movable Type on Github

By Takeshi Nick Osanai
Posted June 14, 2012.

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.

% git branch -a
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/develop-backuprestore
  remotes/origin/feature-assetdrop
  remotes/origin/feature-backuprestore-refactor
  remotes/origin/feature-class-inspector
  remotes/origin/feature-cloneblog-refactor
  remotes/origin/feature-diff-revisions
  remotes/origin/feature-javascript-unit-test
  remotes/origin/feature-optimize-custom-fields
  remotes/origin/feature-revise-php
  remotes/origin/feature-richtext-editor
  remotes/origin/feature-translate-templatized
  remotes/origin/feature-use-warnings
  remotes/origin/hotfix-5.14
  remotes/origin/master
  remotes/origin/revise-tag-test
  remotes/origin/support-4.2x
  remotes/origin/support-4.3x
  remotes/origin/support-5.0x
  remotes/origin/support-5.1x

Did you notice there seems to be rules on how the branches are named?

Branch Management Rules

MovableTypeBranchMap.png

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

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.

develp

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.

support-XX

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.

hotfix-XX

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.

feature-XX

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.

In short:

  • 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.

https://github.com/movabletype/movabletype

Back

11 Comments

john

john on June 21, 2012, 10:57 a.m. Reply

great, thanks!

genf20 plus review site

genf20 plus review site on July 15, 2012, 6:41 p.m. Reply

Thanks for sharing this article. And for translating it to english. This is very useful information.

Adamina

Adamina on August 27, 2012, 12:00 p.m. Reply

Thank you translating this post in English. It is really useful.

Brion

Brion on August 28, 2012, 4:45 a.m. Reply

I really can’t understand the picture. Is it possible somebody to explain me what is the meaning of all these different tags in the last row?

Helga Lottar

Helga Lottar on September 24, 2012, 9:34 p.m. Reply

Thank you for sharing it with us, but can someone tell me what exactly is GitHub?

Garym

Garym on October 16, 2012, 1:41 a.m. Reply

Thank you for the translation. It is really useful.

nashtey

nashtey on October 17, 2012, 5:27 p.m. Reply

I just want to say thank you very much to translating this to English and it is very helpful for me. I hope others are enjoying this.

Ben10

Ben10 on October 24, 2012, 1:18 p.m. Reply

Thanks for translation, japanese is not my first language, neither the second hehe ;)

Mandy

Mandy on October 26, 2012, 5:52 a.m. Reply

So, the regular users who can’t deal with the code like me should download only the latest versions and never should try the fresh stuff because they are not reliable yet. Right?

Coleen York

Coleen York on November 14, 2012, 11:34 p.m. Reply

This is why I always stick only to the master version. I am not a code writer or bug fixer, just a blogger, but I see you guys re doing tremendous job here. Plus one for that.

Ivan Borisoff

Ivan Borisoff on November 21, 2012, 12:31 a.m. Reply

When are you going to release a new Beta version of Movable Type? If I use the diagram above you should be soon.

Leave a Comment