Replacing SVN with Git for’s code’s code currently uses SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the released code are all centrally managed through SVN. as the primary tool of version control hosted on the Meta SVN repo. For the last several months we have also been experimenting with GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. to see if it improves the development workflow.

Currently there is a GitHub repo which is set up as the mirror of the official SVN repo of’s code. This repo is used to hold code reviews, and sync with SVN with every  new commit.

So far this setup has been a big help in making it easier to get and give reviews, therefore improving code quality. Many basic features in Git like commit, stash, branch etc have been a delight to use in place of their SVN counterparts because of Git’s decentralized nature.

At this point it’s worth discussing removing SVN altogether, from at least the local development flow. Right now the process is prone to errors, not easy to set up, and has an extra step of manually syncing Git with latest changes in SVN.

New proposed process

It seems like a good idea to change the version control system as follows:

  1. Make the GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. repo the primary destination for code reviews. It will be configured on the local system of whoever wants to contribute to’s code, and will be the primary place to work and develop.

  2. Keep SVN as part of the release process. That is, whenever code is deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. changes will be synced from Git to SVN and start the deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. process. This process will be manual (or at least will be triggered manually) and SVN will be used only as a release tool (i.e. aim is not to preserve commit metadata like author, commit message etc). This approach has two main benefits:

    1. No changes to deploy scripts will be necessary to use Git. These script are used while pushing code from latest SVN revision to’s server. They would continue using SVN as before.

    2. No dependence on an external tool in order to deploy changes. For example, Github going down will not affect us in case we want to push an emergency fix.

Commits with their authors have already been imported from the SVN repo into the Github repo.

Share your thoughts

Do you have any technical concerns about moving from SVN to Git? Do you suggest any changes to the process?

If the development process is indeed changed, it might be a good idea to also think about importing issues from MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub. to Github that are reported for and its components. Do you have any concerns about importing issues into Github, or should they continue to exist in Trac?

Please leave your suggestions and feedback in a comment on this post.