1. Git&Gitlab Intro

About Git, Please read “Pro Git book” first, at least first three chapters and “6.6 Submodules”

About our “Gitlab” , it`s a self-hosted Github like service, so just use it like Github.

2. Brief Introduction About Our Deployment

Now our deployment workflow is Our master on git server is our development environment, our production environment is managed by Felix, he will push stable version from master on git to production environment(AKA www Server) himself. So we don`t separate develop and master, there will only be master( AKA dev Server).

3. Branching Model

Basically folk from “A successful Git branching model”: , which is known as “Git Flow”: , we have exact same definition for Release branches, Feature branches or Hotfix branches with Git branching model, so you guys can check out this article first, we just simplify and use it here.

The main branch – master

The central repo hold only one main branch with an infinite lifetime:

  • master

The master branch at origin should be familiar to every Git user. We consider origin/master to be the main branch where the source code of HEAD always reflects our development state. So when anyone want to start involve a project , check out code from git server

This is where continuous integration or any automatic nightly builds are built from. So for web front-end and server-side, everytime if there is commit to master, there is a git hook to make sure the dev server reflects the current master source code.

And if there is a new production release is ready, system administrator will push it to Production Server.

Supporting branches

Next to master branch, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

  • Feature branches
  • Release branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

Feature branches

May branch off from: master Must merge back into: master Branch naming convention: * Recommend branch name: component-#issue-feature_name * So must prefix feature name with different platforms` name, such as ios, android, backend, web

Creating a feature branch

When starting work on a new feature, branch off from the master branch.

$ git checkout -b web#2232-user_login origin
Switched to a new branch "web-user_login"

Commit on local created feature branch

$ git commit
Commit changes to branch "web-user_login"
$ git push origin --set-upstream web-user_login
Push local branch to origin, and after first time, you can use 'git push' instead.

Sumbit A Merge Request through Gitlab

If you are solving an issue on Redmine, start here:

  • Open relevanted issue page on Redmine
  • Click “New merge request”
  • Select your feature branch
  • Write title using branch name and sumbit

If you are not solving issue on Redmine, just do 3 and 4 will be ok.

Project Master’s review feature branch code

  • Check out remote branch(like origin/web-#2322-web_login):
$ git checkout -t remote_name/remote_branch
  • Review code, feedback on Gitlab
  • When code is approved, merge and remove this feature branch

** (Optional for master of project if needed) Incorporating a finished feature on master **

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff web-user_login
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d web-user_login
Deleted local branch web-user_login (was 05e9557).
$ git push origin :web-user_login
Deleted branch web-user_login from remote git server.

Release branches

  • May branch off from: master
  • Must merge back into: master
  • Branch naming convention:
    • Recommend branch name: release-component-version_name
    • So must prefix feature name with different platforms` name, such as “ios”, “android”, “backend”, “web”

Creating a release branch

Create release branch means there is a production ready version, we gonna do beta test in release branch,this branch will last until we push to Appstore, Google Play or any other markets.

$ git checkout -b release-iOS-v1.0 master
Switched to a new branch "release-iOS-v1.0"
$ ./ 1.2
Files modified successfully, version bumped to 1.2 
//(We don`t have this yet, maybe done with build tool)
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions

Finishing a release branch

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-iOS-v1.0
Merge made by recursive.
(Summary of changes)
$ git tag -a iOS-v1.0
$ git branch -d release-iOS-v1.0
Deleted branch release-iOS-v1.0 (was 05e9557).
$ git push origin :release-iOS-v1.0
Deleted branch release-iOS-v1.0 from remote git server.
$ git push --tags
[new tag]   iOS-v1.0 -> iOS-v1.0