-
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 fromrelease/?
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 todevelop
- pattern:
hotfix/?
->hotfix/0.0.1
- pattern (for hotfix/tagId, patch/tagId); use version ###/tagId:
0.0.1/?
->0.0.1/SS-1234
- pattern:
-
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
- pattern:
version pattern should be current version +1 to mark the new accepted live release for further testing and validation.
- 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.
-
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
- pattern:
-
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
- pattern:
-
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
- pattern:
-
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
- pattern:
- 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
- ex.
- version ### and build #
- 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
or1.1.1.1
should be used for tagging bugfixes and other build updates during development.
- first number version number
Updated July 23, 2021.