Skip to content

Latest commit

 

History

History
87 lines (51 loc) · 3.54 KB

GITHUB-DEV.md

File metadata and controls

87 lines (51 loc) · 3.54 KB
Raw

🧰 Github Development Notes

🧪 Testing

Branching

🤚 Branch Protection Rules

A switch has been made to adopt the Pull Request model for development. This means that all code must be pushed on a feature branch. Before this push is performed, they should be squashed locally. Since this was new to me, there were a few teething problems encountered, particularly to do with the deletion of stale local branches (see discussion: When using Pull Request model how to safely delete local branch). Also see this discussion concerning Git release tags and their appearance on the Git Graph

There are various tools available that aim to clear up stale branches, eg: get-trim, but since the command to run is straight forward, I don't really see the need to use a third party tool; one can simply use:

git branch -D <local-branch-name>

Or, you can use:

git fetch --prune

but beware, that the prune method, depends on the upstream branch having been deleted as part of the merge process Rebase and Merge on Github. You'll need to look at the Git Graph to see the current state and act accordingly.

The rules that have been activated are:

  • Require a pull request before merging
  • Require linear history
  • Do not allow bypassing the above settings

💈 Workflows

The workflow functions mentioned here are available in the scripts folder and should be copied into zsh profile script (.zshrc)

🧱 Feature Development

Start Feature

startfeat <new-branch-name>

  • Creates a new branch

Finish Work On A Feature

endfeat

  • detaches local branch from upstream branch
  • checks out default branch
  • pull from default branch (these will be the rebased changes, derived from feature branch)

📑 Start A Release

This only initiates the release. Note the version specified must not contain a preceding v as this is added automatically. Also, this process assumes there is a VERSION file in the root of the repo.

release <semantic-version>

  • checks out a new release branch
  • updates the VERSION file and commits with Bump version to <semantic-version>
  • push the release branch upstream

🏷 Tag Release

This must be done after the release has been created using release function as described above.

tag-rel <semantic-version>

  • creates an annotated tag
  • push the tag upstream
  • this tag push will trigger the release workflow action

🤖 Github Actions Automation

pending...

♻️ CI