Skip to content

GitHub guidelines and best practices

Jump to bottom
Dileep Gadiraju edited this page Feb 17, 2022 · 10 revisions

Git Branching Strategy

  1. Make sure long-lived branches (eg. main, develop, master) in git repo are identified. These are the branches where established and quality checked source code is maintained.

  2. Based on Project if the team have admin access, block direct commit and push permissions to long-lived branches. This will help in enforcing Pull Request and review process. This will minimize potential code overwrites/conflicts.

  3. Teams should always create a feature/ or bugfix/ sub-branches from long-lived branches to work on features or bug fixes. Also during their unit testing, developers need to ensure the latest code from long-lived branches are pulled from time to time and merged with their changes.

  4. Once the feature or bugfix is unit tested, raise a PR(Pull Request) to long-lived branches(eg. main, develop, master) for review. It is recommended to raise Pull Request(PR) to develop branch for development. During release, raise Pull Request(PR) to master or main branch.

  5. Reviewer or tester to whom the PR(Pull Request) is assigned needs to validate the following. In future, we can also plan to automate some of these steps using tools like sonarqube

    • Coding standards are followed.
    • Any security risks with the coding
    • Does the code meet functional and non-functional requirements

  6. Reviewer needs to do peer review and test to double-check the code quality and fitment before approving and merging code to long-lived branches.

  7. Once the PR(Pull Request) gets merged from a feature/ or bugfix/ branch to long-lived branches, make sure feature/ or bugfix/ are deleted.

  8. Once a set of features are bugfixes are regression tested on a long-lived branch say develop/, make sure a release is cut and a tag is created for the same by raising Pull Request(PR) to main. This helps in having milestone code bases for future reference and maintenance for a given release.

  9. For project milestone releases, Use <repo_base_url>/releases/new (for example https://github.com/Sunbird-Saral/Project-Saral/releases/new to create release tag and fill in details of the release notes and attach related artefacts that are not maintained in GitHub (eg. binary files, documents etc.) in the Assets section of the GitHub release. Refer Sunbird-Saral v1.5.0 release notes.

  10. Recommend using Semantic Versioning for releases.

  11. For any maintenance on a given release, create maintenance branches from release tags with naming convention _<client/impl name>_maint. This can be used for implementation and release specific maintenance. Example: v1.5.0_odisha_maint

Clone this wiki locally