GitFlow in daily development

The master/develop branches:

1. Master Branch:
   1. Should be any time production deployable
   2. Only two scenario to update master:
      1. hotfix.
      2. production release.
   3. all tags go with master branch
   4. No need to have any routine Jenkins task to run any unittest against on this branch.
2. Branch Release
   1. Used as stable branch to merge all features/bugs.

The feature branches:

1. use develop as their parent branch.
2. used to fix bug and add new feature
3. used as internal branch and the life cycle won’t be more 2 weeks as the good practice.
4. start a new feature branch

1 2 3 4 5 6 7 8 9 10 11 12 git checkout develop # if go with jira, the ticket number will be FWS-1, etc. git checkout -b feature/{ticket number} # use --amend to keep commit transaction clear if possbile. # since sometimes we can't make perfect commit and always forget sth. # do your work git add something git commit -m "first commit" git add another git commit -m "second commit" --amend # you can do rebase as much as you want in daily development. # At least do rebase every morning to keep your local branch refresh.

5. when push the code, a new feature/{ticket number} will be created on origin

6. finish the feature branch

1 2 3 4 5 6 7 8 9 1. permanently rebase with origin/develop before create pull request to avoid the pull request code merge conflict git fetch git rebase origin/develop 2. push your local featureXXX branch to origin/featureXXX. 3. create a pull request from origin/feature/{ticket number} to origin/develop 3.1 TODO: use teamcity to pre-pull-request check. 4. once review, use to merge the all commite into one on origin/develop 5. close branch feature/{ticket number}.

The release branch:

1. At the code frozen phase, we create release branch

1 2 git checkout develop git checkout -b release/0.1.0

2. Do all the release preparation work and urgent production fix.

3. create pull request to master. (rebase firstly)

4. DO NOT SQUASH MERGE when go for master. keep the feature commit history

5. create pull request to develop (may need rebase at first).

6. DO NOT SQUASH MERGE when go for develop as well. keep the behavior consistent between master and develop.

Common Sense

1. master branch
   1. should be deployable branch, don’t touch the meste branch unless it must be required.
   2. set very restricted write access to master branch
   3. only the release manager can approve and do the update master branch.
2. develop branch
   1. all code go to develop new code review through the pull request
   2. Any check in code to develop will trigger the unittest tasks from Jenkins (when Teamcity comes online, the task would launch upon a pull request).
3. feature branch
   1. maintained by developers them self
   2. should be closed when the feature is done.
   3. try to break down the big feature to small feature and have single feature down. Jira introduced the parent issues and child issues that support such scenario.
   4. the workflow for new feature:
      1. master branch
         1. should be deployable branch, don’t touch the meste branch unless it must be required.
         2. set very restricted write access to master branch
         3. only release manager can approve and do the update master branch.
      2. develop branch
         1. all code go to develop new code review through the pull request
         2. Any check in code to develop will trigger the unittest tasks from Jenkins
      3. feature branch
         1. maintained by developers them self
         2. should be closed when the feature is done.
         3. try to break down the big feature to small feature and have single feature down. Jira introduced the parent issues and child issues that support such scenario.
         4. the workflow for new big feature:
            1. Create the Spike ticket to eval the scope and workflow and possible solution and technical challenge. most of case, it will take about 3 - 5 days. The scope for this ticket is as following:
               1. Pickup the technology we should use
               2. List all technical issues we need spent more time to do, if we can’t resolve them in the spike
               3. Create children tickets we can do without dependencies.