Motivator
It's important for a team to have an agreement on how the changes of source code should be applied.According to projects and teams size, we will define a workflow or select one from recommended workflows; the "Feature Branch Workflow" is a candidate.
What is it?
- One branch "master" for main codebase- Several separated branches for features development
Why should we care?
- Be super simple and allow each developer works on a particular feature.- A stable codebase (master) benefits for continuous integration (CI) environment
- Leverage "Pull request" for Code review
How it works?
A lifecyle of a feature branch (usually created by a story)1. Creator creates a new branch from a story. For example: "ABC-1-setup-projects"
2. Creator checkouts the created branch and works on the branch (commits, pushes)
3. Creator has done the feature, he uses "pull request" to merge his branch into branch "master"
4. Reviewers review creator's code and gives feedbacks (if any) OR reviewers approve the "pull request" and go to 6.
5. Creator adjusts his code counting on reviewer's feedbacks, back to 3.
6. Creator merges his feature into master and deletes his branch.
Reference:
[1]. https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow