Skip to content

Instantly share code, notes, and snippets.

@lkhagvadorj-amp
Last active July 24, 2024 14:25
Show Gist options
  • Save lkhagvadorj-amp/c953e3912c1fa2a3e9d0ef74b0637c04 to your computer and use it in GitHub Desktop.
Save lkhagvadorj-amp/c953e3912c1fa2a3e9d0ef74b0637c04 to your computer and use it in GitHub Desktop.
Policy to All Developers

issue policy

planing in the project

issue type and definition

  • Epic a large body of work - feature, release, etc
  • Issue a building block of work - story, bug, task, etc

all issues include checklists (Subtasks) to complete

issue title policy

[section 1] [section 2] [section 3]

  • [section 1] has to be verb what managers/developers want adding? deleting? fixing? testing?

  • [section 2] has to be feature what managers/develops discussing about feature name?

  • [section 3] has to be noun where managers/develops discussing about function name? page name?

example:

  • adding sortable table in audit history page
  • making paginable table in audit history page

issue description policy

  • Info explanation to answer this issue is requirred

  • Complete Condition explanation to answer this issue is completed

issue field policy

  • title
  • description
  • assignee
  • created_by
  • due_time
  • start_time
  • priority
  • severity

branch policy

branch construction

  • main
  • release
  • ${development_branch}
  • ${hotfix_branch}

branch usage

main is development branch release is staging branch release with taf is production branch ${development_branch} is local/origin development branch ${hotfix_branch} is local/origin hot fix branch

branch naming policy

default branch main

create ${development_branch} from main

create ${hotfix_branch} from release

git checkout -b ${issue_system}_${issue_id}

commit policy

commit prefix

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

additional commit

closes ${issue_id}

pull request policy

secure branch

  • main only pull request from ${development_branch}
  • release only pull request from main

approval rule

  • test report
  • release note

label policy

label construction

Labels should be clear, descriptive, and consistently used to categorize and prioritize issues. Labels help in filtering and organizing issues.


tag policy

tag construction

Tags are used to mark specific versions or releases of the project. Tags should be descriptive and follow a versioning scheme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment