Project Git Process - NCIOCPL/cgov-digital-platform GitHub Wiki

High-level overview of our git process

  • One Git Issue per commit - no multi-fixes in the same commit.
  • The commit message should follow the format of (#<ISSUENUM>) Descriptive Message.
    • Descriptive multiline comments are appreciated as well.
  • Unless otherwise APPROVED IN ADVANCE, one commit per PR.
    • Sometimes we will allow two or three cleanup tickets to be rolled into a single PR to reduce build overhead
  • All PRs must be deployed to an ODE, and submitted for IA Review
  • The url of the ODE will be entered into the ticket
  • We follow the git-flow process
    • Hotfix branches come off of master and are merged to master & develop after deployment
    • Release branches come off develop and are merged to master & develop after deployment
    • Feature branches come off develop and are merged to develop upon completion/approval

Process

We will follow the git-flow pattern. Branches within this repository can be:

  • master is only used to hold released software (there can be only one)
  • Story development is done against the develop branch (there can be only one)
  • A release/vX.Y.Z branch will be created from develop it is time for a release, i.e. enough functionality has been completed to warrant the overhead of doing a release
    • Bug fixes found in the release code and approved new story develop will be applied to that release branch
    • Stories for the next releases can be targeted against the develop branch during this phase
  • feature/short-name branches can be created for more complex work that may encompass multiple tickets, and be worked on by multiple developers. For example implementing a new complex modules (e.g. an app module like Clinical Trials Search) can be done here and merged into develop when complete.
  • hotfix/vX.Y.Z branches are created from master and are for pressing hot fixes.
  1. Developers will create ticket/num-short-name branches to implement their tickets
    • This branch should created off of a upstream develop, release/vX.Y.Z, hotfix/vX.Y.Z or feature/short-name
    • One GitHub Issue (ticket), per branch please
      • Similarly, one commit per GitHub Issue.
      • This allows all the related changes to appear together in the code history.
      • It also any problems to be resolved (via squashing) in the same commit without preventing other changes from being merged into the parent branch.
    • The title for the commit should reflect the work in the main ticket and MUST include the issue number.
      • For example "(#92) Implemented the Chicken Module"
  2. When the developer is done, they will submit a pull request to merge the changes into the develop, release/vX.Y.Z or feature/short-name branch of the NCIOCPL/cgov-digital-platform repository
    • The pull request should include the ticket number in the title of the PR
      • If you only have one commit, Github is usually smart enough to copy the commit title.
    • PRs will be rejected if they have incorrect commit message formatting
      • Github links Issues, PRs and Code via these numbers, if they are missing, we lose the ability to easily trace through work.
  3. Once the build has successfully completed the developer will deploy their built PR artifact (pipelines-build-pr1234) to an ODE
  4. Once the ODE has been successfully deployed, the developer will then put the ODE URL on their PR and mark it for IA Review
  5. The IAs will review the functionality, and work with the developer to implement changes. Additionally a development lead will review the code for style, proper separation of concerns and best practices.
    • If changes are required, the developer will need to interactively rebase their code in order to squash their changes into a single commit to keep in line with our 1 commit per issue requirement.

      NOTE: If you don't understand this ASK!

  6. The developer should rebase their PR commit off the source branch in order to make sure it is up to date with the latest commits
    • A PR MUST be up to date before it will be accepted. This is to ensure that it will build successfully.
  7. If all conditions are met, a GitHub administrator will use the github "Rebase and Merge" option to pull the PR.
⚠️ **GitHub.com Fallback** ⚠️