Workflow: Git Flow

Understanding this Project's Workflow

We use the now ubiquitous git-flow model to contribute to this project. If you intend to write new features and eventually have those features included in the codebase, take the time to familiarize yourself with this model. You can find a detailed overview here.

In sum:

• The main, or production, branch is DEGEN. This is a protected branch and requires two admins to review and approve any pull requests made to this branch, along with a series of other stipulations. The primary stipulation being that only release branches get merged with DEGEN.
• The secondary, or primary working copy, branch is develop. This is also a protected branch and requires one admin to review and approve any pull requests made to this branch. As this is the working copy, this branch holds the latest approved commits; it is this branch that you will branch off of when preparing to write a new feature. Also, when branches are merged into develop, it's good practice to pull the updated develop branch to your local environment and merge it with your feature branch so you have the latest changes available.
• When creating branches to develop new features, use the format feature/your-very-specific-feature-branch-name-here.

There are otherwise few hard and fast rules, and of those that exist, many of them can be found in the ESLint and Prettier configuration files. How often should you commit? Who cares! Every developer has their own way of developing. Some commit every little change. Others will commit entire features. Who should you go to for help regarding this flow? Any available admin. Not sure where to find one? Ask in the Garage. When in doubt, drop your questions in the Garage. For everything else, use your best judgement.