Git on Huy Minh Ha

Git branching strategy

Mon, 09 Jan 2017 00:00:00 +0700

Branching strategy is an important part of using git correctly. Without a proper branching strategy, even with a few people in the project, you will create a mess in no time. Below is a simple branching strategy that can be applied to various situation. It is also available on github here

Branch Description

master

Master branch represents what’s in live. It should not be modified directly.

When it is deployed, it will be tagged so that we can revert to a certain deployment later.

Lifetime: forever

release/xxx

After finishing a feature, make a release branch off the develop branch, merge all the necessary feature branches and do final test. Bugs found in this final QA phases can also be hotfixed in the same branch. After everything is complete, we will rebase this branch over develop branch, then the rebase branch will be merged into the master branch for release in Live environment.

Lifetime: Feature Finish ~ Release in Live

hotfix/xxx

If a bug is found in production, we wil branch hotfix branch off master.

Lifetime: Bugfix ~ Release in Live

develop

This is the main branch where feature branches should be branched off. Trivial changes can be directly applied to develop if you are sure it should go into the next version. Major feature/bugfix branches have to go through PR process to be merged into develop.

Lifetime: forever

feature/xxx

Feature branch should be branched off develop. While working on feature branches, developers can choose to merge develop into it. Once QA is completed on the feature branch, developers can send PR.

Lifetime: Feature development ~ PR merge

art

Art branch lives forever. Artists only need to deal with this branch.

Lifetime: forever

Role Descriptions

Engineer / UIDesigner

develop -> feature
feature -> develop (PR)

Artist

art -> art

Lead Engineer

develop -> release
release -> develop
master -> hotfix
hotfix -> master
hotfix -> develop

Embed git file to pelican

Thu, 11 Sep 2014 00:00:00 +0700

Writing articles in github pages is nice, because you have github repository with all the nice features for document management, however sometimes it’s not where I want my articles to reside. For instance, I want the articles about git to be in a separate git repository.

I have several solutions for this problem:

I could duplicate the article. But I won’t do this.
I could store the articles as gist like this:

[gist:id=dc8b7c536d0fe9c7003f]

But I can’t store a lot of related things in gist because that’s the role of a real git repo.

I could store the articles in the normal git repo, and embed it into the article in github page. I chose this approach for long articles. Like this:

There’s already a nice tool to do this: gist-it. Using it is really simple, just clone the repo and deploy it to an AppEngine instance. The downside of this is it does not generate html code for Markdown.

The best solution for me is to use a plugin for embedding git file into pelican like this:

minhhh/wiki/sample.md

How to rebase in Git

Tue, 09 Sep 2014 00:00:00 +0700

minhhh/git-manual/git_rebase.md

Git cheat sheet

Fri, 05 Sep 2014 00:00:00 +0700

minhhh/git-manual/README.md