Branching Strategies For Git and Subversion
Download as PPTX, PDF1 like2,783 views
The document discusses branching strategies for Subversion and Git source control systems. For Subversion, the trunk is used for development and branches are used for releases and bug fixes. Changes are merged back into the trunk. For Git, the develop branch is used for development, the master branch is the golden image with no direct check-ins, and release and bugfix branches are used for releases which are deployed from those branches. Tags are used to mark specific versions in both systems.
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 release branches track prod (not trunk).
- 4. trunk bugfixes release env 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. 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.
- 8. master develop bugfixes release env 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
- 9. Fini