Feature Branch Workflow

Posted on | In

I recommend to use Feature Branch Workflow(FBW) as a daily guideline of source code check-in. Read more why FBW is a good workflow

It starts from a new branch (either for a new feature or bug-fixing):

1
2
3
4
5
git checkout -b <feature-branch>

// then make change locally
git add .
git commit -a

Suppose someone else checks in something important for your feature in the remote develop branch (since developers rarely work on master directly), then it’s necessary to pull down the change and merge it into the local feature branch.

1
2
git checkout develop
git pull

At this moment, there are two options to do the merge. One is git merge, which creates a “merge commit” in the feature branch.

1
2
git checkout <feature-branch>
git merge develop

It’s a safe operation though it can make feature branch’s history hard to understand for others. So another way is to use git rebase, which cuts the feature branch and pastes it after the last commit on develop to keep a linear history for feature branch. Read more on the comparison of merge and rebase and when NOT to do rebase

1
2
3
4
5
6
7
8
9
10
git checkout <feature-branch>
// -i flag provides an interactive editing of commit message 
git rebase -i --autosquash develop

// do conflict merge and
git add <file1> <file2> ...
git rebase --continue

// and publish the branch
git push -f

Read more on how to do conflict merge
Read more on autosquash and how to commit fixup

Just keep in mind that don’t do rebase on a public branch that someone else could work on. Once the feature is done and there is no failed tests, make a pull request (via github’s website or like). After the request has been accepted and merged and closed, clean up local feature branch.

Another article about the relation of master/develop/feature/hotfix branch