Branching Strategy

For Git and Subversion

Subversion

● Subversion is a centralized source control

management system.

● Very easy to use, checkout a working copy

and sync before you check-in.

● Multiple working copies to work on different

releases. big context switch.

● Hard at merge. Prepare to rewrite the code

while you are at it.

Branching in Subversion

● Use trunk for development.

● Branch for releases and bugfixes.

● Merge branch back into trunk after

deployment.

● Reintegrate branch and don’t use again.

● Use maven release plugin to publish artifacts

and tag source.

● Let release branches track prod (not trunk).

envtrunk bugfixes release

3.merge

hotfix

tag

2.0

1.prepare

hotfix

2.deploy

release2.0 RC1

1.prepare

release

tag

1.1

3.merge

release

2.deploy

hotfix

Maven release plugin

<!-- scm repo url -->

<scm><connection>https://myrepo/myproject/trunk</connection></scm>

<!-- release plugin -->

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-release-plugin</artifactId>

<version>2.4.1</version>

<configuration>

<tagBase>https://myrepo/myproject/tags</tagBase>

<tagNameFormat>${project.version}</tagNameFormat>

<dryRun>false</dryRun>

<checkModificationExcludes>

<checkModificationExclude>pom.xml</checkModificationExclude>

</checkModificationExcludes>

</configuration>

</plugin>

Git

● Git is a distrubuted source control

management system.

● Not easy to use: clone repo, checkout a

branch to local copy, pull and push to origin.

● One working copy enough to work on

different releases. fast context switch.

● Excellent merge because of the local history.

Branching in Git

● Use develop branch for development.

● Use master as golden image. i.e. no direct

check-ins only merges.

● Use bugfixes and release branches as

“release” branches. i.e. deploy from these.

● Don’t release from master or develop.

● Use private branches outside of these freely.

● Let master track prod.

envmaster develop bugfixes release

tag

1.0

3.merge

hotfix

tag

2.0

1.prepare

hotfix

next

release

2.deploy

release

2.0 RC1

1.prepare

release

tag

1.1

3.merge

release

2.deploy

hotfix

Fini