1. Git&Gitlab Intro
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”:http://nvie.com/posts/a-successful-git-branching-model/ , which is known as “Git Flow”:https://github.com/nvie/gitflow , 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:
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.
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.
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.
- 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" $ ./bump-version.sh 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