Must read carefully when working as a team
By Minh Pham, 2020
To view your branches within your repository run the following command:
$ git branch -aThis will list all of your local and remote repositories. You will see the following output for Git repo:
$ git branch -a
* develop
develop_internal
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/develop_internal
remotes/origin/release
remotes/origin/verticalA/<xxx>
remotes/origin/verticalB/<xxx>
remotes/origin/verticalC/<xxx>This output indicates you have local repositories and remote repositories. Each of the local repositories is tracked with a remote repository. This means that when you perform a git push from a local repository, the changes will be sent to the remote repository. Likewise, whenever you perform a git pull changes will be pulled from the remote repository.
| Branch | Description |
|---|---|
<vertical>/<feature><vertical>/issue_<id> |
Fix bug, feature branch |
| develop | Features are picked when starting new release cycle |
release_<version> |
Branch off of develop when release. Goals: - Unchanged code if unnecessary. Only commit fix bug / minor UAT - Release hot fix, patch - Merge next release feature for testing |
daily/<vertical>-build |
Daily build of each vertical team, used to merge all features of each team |
| develop_internal | Build daily. Merge all features of all team to UAT |
vertical: each vertical team chat, group, social, platform
vertical/<feature>, vertical/issue_<id>: You should name your newly feature branch with the prefix of your vertical team followed by the descriptive branch name which describe your bug/feature.
Some of good branch name example: chat/issue-123, group/add_log, ...
Each bug/feature branch will have 3 cycles:
- Start bug/feature to code review
- QC testing process
- Integrate into
developbranch (ready for release)
Each cycle will have different git workflow. So let's go through each one of them.
1.1. Create a local branch from the develop branch specific to the bug/feature you are working on. ALL
development work for this bug/feature MUST be done within this local branch.
First you must switch to the develop branch that is tracking the remote branch we created during
the setup. We want to create our branches from the develop branch because we know the code
that exists in the develop branch has already passed QA and is working in the field. This way we
will never merge over code to the develop branch that contains bugs.
$ git checkout develop
Switched to branch 'develop'Make sure you have the latest and greatest code that exists in the develop branch by updating
your local repository copy:
$ git pull
or
$ git pull origin developNow, you ALWAYS want to be working on the branch you are about to create here for ALL changes in code. Now we will create a local branch using the bug/feature for the branch name:
$ git branch chat/issue_123
or
$ git branch chat/magic_featureNOTE: If it is a bug in the mantis, you should name the branch with the <bug-id>. E.g: chat/issue-123 with 123 is the bug-id on mantis system.
Now, you want to switch to the new branch you created
$ git checkout chat/magic_feature
Switched to branch 'chat/magic_feature'1.2. Write your code!
1.3. Now that your code is ready to commit to your LOCAL remote repository, you must add and commit the
files for your bug fix/feature add. You will need to understand the file status lifecycle in order properly move files around locally. Now you want to push your changes from your local to the remote bug/feature branch.
$ git push origin chat/magic_featureThen ask the reviewer to checkout your bug/feature branch to review your change. Your code may pass, may fail review process depends on reviewer. And you can go ahead change as many times as you like on your local branch to satisfy the reviewers' need.
1.4. There is time you want to update your current working bug/feature branch with the latest code from develop branch. I recommend you to use git rebase strategy rather than git merge one. Using the rebase will keep your history clean, not create intermediate merge commit, easy to rewrite your local commit history as many times, in many ways as you like
$ git checkout develop
$ git pull origin develop # make sure the latest code on develop
$ git checkout chat/magic_feature
$ git rebase develop # rebase develop onto bug/feature branchIf you use git rebase, you can't push the local branch into remote any longer.
To [...]
! [rejected] chat/magic_feature -> chat/magic_feature (fetch first)
error: failed to push some refs to [...]
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ’git pull ...’) before pushing again.
hint: See the ’Note about fast-forwards’ in ’git push --help’ for details.To fix this issue, use git push --force or git push --force-with-lease. I recommend using the latter.
$ git push --force-with-lease origin chat/magic_featureFor more information, read here
When you pass code review process. There are 2 ways QC can test your bug/feature:
- Build the apk base on your bug/feature branch. Use this way you can go ahead go to step 1.2 through 1.4 and
rebaseyour bug/feature branch as many times as you like even if you fail QC testing. - Merge your bug/feature branch into daily build of the vertical team, then build vertical-daily-build apk. If for some reasons you fail QC testing process, then NEVER REBASE BUG/FEATURE BRANCH WITH DEVELOP BRANCH AGAIN. From now on, use the
git mergestrategy instead. Follow by the commands:
$ git checkout develop
$ git pull origin develop ## make sure the latest code from develop branch
$ git checkout chat/magic_feature
$ git merge develop # now feature branch has the latest code from develop branch
$ git push origin chat/magic_feature
$ git checkout chat/daily-chat
$ git pull chat/daily-chat
$ git merge chat/magic_feature # sync the vertical-daily-build with the latest code from develop branch and the fix
$ git push origin chat/daily-chatThere are two cases here:
- If your bug/feature branch has not been merged into any branches
- If your bug/feature branch has been merged into at least one branch (usually
<vertical>/daily-branch)
Either cases you need to update the latest code on develop branch. First, you must change our branch to the development branch:
$ git checkout develop
Switched to branch 'develop'Again, make sure you have the latest and greatest code in the development branch. The development will always be considered (unstable). This stream is to ensure you do not have broken builds that hit QA’s hands. If a code review doesn’t catch a broken build, this stream will. NOTE: DO NOT RELY ON THIS STREAM TO CATCH YOUR MISTAKES!!
$ git pullThis case is suitable for the bug fix branch, rather than feature branch.
With the latest code from develop branch, rebase it onto your bug/feature branch. Resolve any conflicts that have occurred (if any have occurred). Then git push --force-with-lease your bug/feature branch into remote. Then next follow the Merge Request Guide
$ git checkout chat/magic_branch
$ git rebase develop
$ git push --force-with-lease origin chat/magic_branch3.2. If your bug/feature branch has been merged into at least one branch (usually <vertical>/daily-branch)
This case is suitable for feature branch which has been merged into vertical-daily-branch.
NEVER REBASE BUG/FEATURE BRANCH THAT HAS BEEN MERGE INTO OTHER BRANCHES
With the latest code from develop branch, merge develop branch into bug/feature branch. Resolve any conflicts that have occurred (if any have occurred). Then git push your bug/feature branch into remote. Then next follow the Merge Request Guide
$ git checkout chat/magic_branch
$ git merge develop
$ git push origin chat/magic_branchComing soon