Git Coding Standards

Branching

The master branch is reserved for code approved for production.

All development work should be done in topic branches for review. All code in a Topic branch should be able to be deployed at once. New, unrelated, requests should be done in separate Topic branches.

Naming Conventions

Use descriptive branch names that readily identify what they do.

Bad branch names

  • chance
  • 08_20_2018
  • updates

Good branch names

  • dosing_calculator
  • phase_2_updates
  • core_security_update

Note: While a date is a bad choice for a branch name, it makes perfect sense for a tag. Tags point to one specific commit in the repo history.

Best Practices

When branching branch from the latest approved change in code. For new requests, this would usually the latest code in production & on Master. For requests modifying another topic branch, it would be the latest approved commit on that branch.

Examples

# Create a branch from the latest code in master.
git checkout master
git checkout -b my_topic_branch

# Create a branch from a tag (2018-08-22) on master (i.e. hotfix).
git checkout master
git checkout -b my_topic_branch 2018-08-22

# Delete a local branch.
git branch -d my_unused_branch

Merging

All team members may merge topic branches into each other (or combine into a new topic branch) for the purposes of staging & review.

Only team leads may:

  • Merge approved code into the master branch.
  • Update the production server with a new git tag.

Deploying to Production

  1. The team lead should checkout Master and make sure no updates have been made to the branch since the last production release.

    • If there are commits in Master that are not on production for any reason, a hotfix branch should be created from the latest approved tag.

  2. They should then review the topic branch one last time, with the developer assigned to the update & the PM, to confirm exactly what changed.

  3. After confirming all updates, merge the code into Master & create a new tag for release. Pushing both to the remote repo.

  4. Update the production server to point at the new tag.

  5. Run database updates & clear/rebuild the site caches.

Examples

Git merges are run from the branch you want to merge into. Use the branch command to specify which branch to merge.

# Checkout the branch that we want to merge into.
git checkout stage

# Merge our topic branch into the current branch `stage`.
git merge my_topic_branch

# Push our merged branch back to the remote.
git push -u origin stage

Tagging

Git tags are used to identify production releases. They should consist of the date in YYYY-MM-DD format, optionally followed by a short message for hotfixes.

git tag 2018-08-22_redirect_hotfix
git push --tags
← TwigNPM/Package JSON →