Git Best Practices - nickpalmer789/ProductionNumber4 GitHub Wiki

Introduction:

To keep the codebase for this project manageable and clean contributors and developers should adhere to the following git best practices for this project. If you have any questions about this please email [email protected].

Git Workflow

For this project there are two main branches. master and develop. The master branch will always contain the most recent release of the project, whereas develop will be where releases are created. This way a working copy of the software can always be obtained by checking out any commit on the master branch. Use the following rules to accomplish this:

  1. Developers will create feature branches which branch off from develop.
    a. Feature branches should be named as follows: Card#_XXX_descriptor where XXX is the developers initials and the descriptor describes the purpose of the feature branch.
    b. For larger coding sessions epic branches can be created which have smaller feature branches branching from it. These branches should be named as follows: XXX_descriptor where XXX is the developers initials and the descriptor describes the purpose of the epic branch.
    c. Before developers bring their code to code review they should pull the most recent changes from develop, merge develop into their feature/epic branch, test their code to ensure that it works, and then push their feature branch to origin so the rest of the team can view the branch.

Code Review

Code reviews help prevent unnecessary SLOC (what's this?) in the codebase. The following procedures will be utilized during code review to ensure code review goes smoothly.

Procedures for contributors:

  1. During code review the review team will fetch/checkout the feature branch under review and view its contents.
  2. Reviewers will help ensure that the code performs as it should given the requirements of the user story/epic.
  3. Once reviewers are satisfied that the code is ready to be merged, the feature branch will be merged with develop.

Procedures for non-contributors:

Want to contribute to the project? Great! Please make a pull request, and a contributor will review your code and provide feedback/accept your pull request as appropriate.

Major Releases

When it is time for a major release, the code will be tested to ensure that it is ready to release. Once the code has been deemed ready-for-release, the develop branch will be merged into the master branch. This will ensure that the master branch always has a working copy of the software.

Tagging

Upon release a new tag on the master branch will be created with a version number and a detailed description of the new features.
The version number will follow the format major.minor.patch. The following describes each part of this format:

  • Major version numbers change whenever there is something significant change being introduced.
  • Minor version numbers change whenever there is a new minor feature change, or when a set of smaller features is rolled out.
  • Patch numbers change when a new build of the software must be released. This usually involves a bug-fix or the like.