git workflow and rules

git - workflow rules.md

MANDATORY GIT WORKFLOW RULES:

master

• core production branch

• do not push directly.

• all hotfix/? code will always be forked from master branch

• merges should be from PR (supervised). PR should be either hotfix/?, patch/? or from release/? for final live build

• updates (hotfix/patch) should be merged back to develop - means this branch will not be in sync with develop, but its changes (hotfix) will always be synched back to develop

  • pattern: hotfix/? -> hotfix/0.0.1
  • pattern (for hotfix/tagId, patch/tagId); use version ###/tagId: 0.0.1/? -> 0.0.1/SS-1234

release

• branch is always fokred from latest working development branch

• do not push directly.

• all (quickfix/bugfix/hotfix)/? code will always be forked from release/? branch

• merges should be from PR (supervised). PR should be either (quickfix/bugfix/hotfix)

• should be merged back to develop - means this branch will be in sync with develop with its latest changes (quickfix/bugfix/hotfix)/?

  • pattern: release/? -> release/0.0.1
  • pattern (for quickfix/bugfix/hotfix): 0.0.1/? -> 0.0.1/SS-1234

notes

version pattern should be current version +1 to mark the new accepted live release for further testing and validation.

develop

• core development branch
• do not push directly.
• merges should be from PR (supervised).
• all code updates will be merged and synched to this (development) branch.
• all new code updates will always be forked from this (development) branch.

feature

• branch is always fokred from development branch

• branch should always be with prefixed with feature/ -> feature/? ex. feature/test_feature

• new tasks should always be done in subbranch even if you're the only one tasked in this feature; this will always make our parallel development a lot easier in case there's suddent update that needs the other dev to work along side the main developer.

• subbranch should always be in ?/ - test_feature/? ex. test_feature/(add_details | JiraID)

• subbranch should always be merged only to their corresponding parent branch feature/? ex. feature/test_feature <- subbranches

• merging a subbranch to the parent branch will not be supervised; developers should coordinate to their co-developers.

• features from feature/feature_name will be merged and synched back to develop through PR (supervised); branch will be closed after successful merged (optional).

  • pattern: feature/? -> feature/test_feature
  • pattern: feature/tagId -> feature/SS-1234
  • pattern (for subbranches): test_feature/? -> test_feature/SS-1234

revision

• miscellaneous branch

• branch can be fokred from development or any active work branch

• branch should always be with prefixed with revision/ -> revision/? ex. revision/SS-1234`

• will be used for reopened tasks

• will be merged and synched back to develop through PR (supervised); branch will be closed after successful merged.

  • pattern: revision/? -> revision/SS-1234

update

• branch is always fokred from development branch

• branch should always be with prefixed with update/ -> update/? ex. update/SS-1234`

• will be used for random update tasks; [updates, extras or misc]

• will be merged and synched back to develop through PR (supervised); branch will be closed after successful merged.

  • pattern: update/? -> update/SS-1234

bugfix

• miscellaneous branch

• branch should always be with prefixed with bugfix/ -> bugfix/? ex. bugfix/SS-1234`

• will be used for bugfix updates

• will be merged and synched back to develop through PR (supervised); branch will be closed after successful merged.

  • pattern: bugfix/? -> bugfix/SS-1234
  • pattern: bugfix/bug-name -> bugfix/proceed-button

note

• always fork from remote development branch before starting any new tasks
• naming or adding commit messages should always be in format: JiraID - commit message ex. SS-1234 - test changes
• using version and build number should go in format #.#.# or #.#.#.#
  • version ### and build #
    • ex. 0.0.1.1, 0.0.5.13
• format legend: #.#.#
  • first number version number # ex. 1.0 should be used for defining major build updates.
    • support deprecation should be included here
  • second number version number #.# ex. 1.1 should be used for defining minor version updates
  • third or fourth version number #.#.# | #.#.#.# ex. 1.1.1 or 1.1.1.1 should be used for tagging bugfixes and other build updates during development.

Updated July 23, 2021.