2. Pre
• This is our initial agreement and we are looking to
evaluate if there is better solution
• Currently investigating
https://bitbucket.org/atlassian/maven-jgitflow-plugin to
avoid hand work as much as possible
4. Other view by stability
Picture from:
http://johanleino.wordpress.com/2013/05/06/using-gitflow-with-visual-studio-and-sourcetree/
• More stable
branch is
upper
5. Start a feature (story)
• Git
– Git flow
• git flow feature start FEATURE
– Git
• git checkout -b feature/FEATURE develop
• FEATURE = <EDB-1222->some-meaningful-name
• Change artifact version in pom to <version>-FEATURE
7. Finish a feature (story)
• Git
– Git flow
• git flow feature finish FEATURE
– Git
• git checkout develop
• git merge --no-ff feature/FEATURE
• git branch -d feature/FEATURE
• Fix artifact version in the pom
• Delete apk from file dev, artifactory and sonar project
8. Start a release
• Git
– Git flow
• git flow release start VERSION [BASE]
– Git
• git branch -b release/VERSION develop [BASE]
• Change version from snapshot to release pom
• Increase version in develop pom
9. Finish a release
• Git
– Git flow
• git flow release finish VERSION
– Git
• git checkout master
• git merge --no-ff release/VERSION
• git tag -a VERSION
• git checkout develop
• git merge --no-ff release/VERSION
• git branch -d release/VERSION
• Change version to snapshot in pom
10. Start a hotfix
• Git
– Git flow
• git flow hotfix start VERSION
– Git
• git branch -b hotfix/VERSION master
• Increase version in hotfix pom
11. Finish a hotfix
• Git
– Git flow
• git flow hotfix finish VERSION
– Git
• git checkout master
• git merge --no-ff hotfix/VERSION
• git tag -a VERSION
• git checkout develop (release/VERSION)
• git merge --no-ff hotfix/VERSION
• git branch -d hotfix/VERSION
• Change version to snapshot in pom
12. Versions checklist
• develop and feature branches must have SNAPSHOT version
• Increase develop version as soon as we started release
• release, hotfix and master branches should have RC candidate
and not snapshot version until released
• Hotfixes under unreleased versions increases version from
RC<n> to RC<n+1>
• master should have ‘clear’ version us soon as we released
• tag master branch every time when we distribute build
13. • Publish (Push) features, releases, hotfixes and tags
– git push --tags origin
• Pull before publishing
– git pull --rebase origin feature/FEATURE
• Merge conflicts during rebasing
– git add FILE
– git rebease --continue
– to revert: git rebase --abort
Working with Git
14. • History manipulating
– git checkout/revert/reset
– git commit --amend
• Untracked files
– git clean
• Save temporary work
– git stash
Manage changes with Git
15. • branches
– develop is default
– feature/* are active
• deploy folder is latest
– *devapp.apk
– *feature-devapp.apk
• live/beta/public beta are built on demand
TeamCity development configuration
16. • branches
– hotfix/* are active
– release/* are active
– master is default branch
• deploy folder is pre-release
TeamCity RC configuration
17. • branches
– master is active
• deploy folder is release-candidate
• build is pinnable (deploy to beta.ebuddy.com)
• build archived
• Note: version is still RC
TeamCity public beta configuration
18. • branches
– master is active
• deploy folder is market
• build is pinnable (to save in TC)
• build archived
TeamCity market configuration