Branching Strategies For Git and Subversion

most common source control branching strategies for Git and Subversion.

1. Branching Strategy For Git and Subversion

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

3. 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 r elease branches track prod (not trunk)

4. env trunk bugfixes release 3.merge hotfix tag 2.0 1.prepare hotfix 2.deploy release 2.0 RC1 1.prepare release tag 1.1 3.merge release 2.deploy hotfix

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

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

7. Branching in Git Use develop branch for development Use master as golden image. i.e. merge back to master after deployment 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 m aster track prod

8. env master 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