Simple Git Workflow for Rapid Development

simple-git-workflow-for-rapid-development.md

As a lean team, so we've optimized Git-flow to be more simple and have it fits with our team size and project complexities better

We gonna have 3 primary types of branches: master branch, staging branch and features branches, which are:

• Brach master is latest version of workable product. Each increaments will be merged to master after sprint is finished. And it's always release-able.

• Branch staging is branched-off from master. When new iteration is started, it will reset to latest master's state. And dev team will use this branch to demo their work.

• Branches features are likely

  • feat-x, fix-y, ref-z, chore-a or
  • feat-add-login-form, fix-bug-on-swap-eth...

Each branch in this type, is represented for a product's improvement - which could be new feature, a bug fixing, a refactor... that include in a iteration. They're branched-off from master, and will always check with latest master state by merging or rebasing to make sure they're compatible with product's state.

Developers will follow this process to work on features:

• Based on feature they work with, create new branch from master, with a pre-agreed naming convention:
  • Jira tasks' number, E.g TWCI-21, WP-111, GSS-53 ...
  • Features' name, E.g feature-user-login, feature-mail-subscrition, feature-form-contact...
  • Grouping by type, E.g feature/GSS-53, task/TWCI-21 , bug/WP-11 ...
• Developers now will start working on new branch: code, commit, push - Classic!
  • If there are changes from master, e.g Other features being merged, then developers will need to rebase/merge (we prefer rebase) their working branches with master to get those updates (means keep sync with master)
  • When working branches are ready (completed Definition of DONE), developers will need others review his work by creating pull-requests for their branches - those PRs will point to master.
  • Whoever do QA assurance will manually merge it to staging for testing on UAT and check it's compatibility with other features.
  • If PR is okay, then QA will merge it to master (PS: Hitting the Merge button!)
  • If anything wrong, QA will tell branch owner to fix it.
• After iteration end, or before new iteration starts, someone will need to reset staging to latest master, in order to make sure they're in sync for up-coming features.