Project Git Process - NCIOCPL/cgov-digital-platform GitHub Wiki
- 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
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.
- 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
orfeature/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"
- This branch should created off of a upstream
- When the developer is done, they will submit a pull request to merge the changes into the
develop
,release/vX.Y.Z
orfeature/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.
- The pull request should include the ticket number in the title of the PR
- Once the build has successfully completed the developer will deploy their built PR artifact (pipelines-build-pr1234) to an ODE
- Once the ODE has been successfully deployed, the developer will then put the ODE URL on their PR and mark it for IA Review
- 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!
- 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.
- 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.
- If all conditions are met, a GitHub administrator will use the github "Rebase and Merge" option to pull the PR.