Git Workflow

SCM/VCS tools
Branches
Integration branch
Stable branch
Live/production branch
Feature branches
Commit standards
Commit granularity
Commit messages
Merges/pull requests

SCM/VCS tools

Git is a version control system (VCS) that allows for distributed development and repositories. We have chosen to use Git, not only because of its
ease of use, but also because its wide acceptance as the leading VCS.

All changes should be tracked using Git and GitHub, with a private repository at https://github.com/forumone, unless otherwise specified by the
client.

With GitHub, you must have two-factor authentication enabled (see the GitHub settings page for more details).

Branches

Integration branch

Branch name: master

Deployment environment: dev

All active development should be captured in a feature branch and merged regularly into the integration branch. Most of this work should take
place in a developer’s repository where it can be pushed up to the project repository and merged back into origin/master.

Stable branch

Branch name: stable

Deployment environment: stage

The stable branch is assumed to contain the latest work that has passed initial developer QA and is ready for formal QA and client review. All
feature branches (see below) should be created from this branch.

Live/production branch

Branch name: live

Deployment environment: production

The latest commit on the live branch is assumed to always be ready for deployment and use in production. With this in mind, new work should
never be directly committed to live. When a new release is merged into the live branch a tag should be created to mark the new release. Any
projects using continuous integration (e.g., Jenkins) will automatically build and deploy a release from this commit and tag.

Feature branches

Branch name: follows the pattern "TICKETNUMBER-short-description"

Token Description Examples

Ticket This is the unique identifier for the ticket. For JIRA projects, this is also known as 12345
number the issue key, and includes both the project key and the issue number. 86753
NOB-34
CBCNY-84

Short A brief, two-to-four-word description of the ticket's goal, spaced with dashes. Ticket Name: Fix Resource
description Widget
Branch short description:
fix-resource-widget
 Deployment environment: N/A

Feature branches may be branched only from the stable branch, and should be merged back into the integration branch for developer testing.

Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When
starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a
feature branch is that it exists as long as the feature is in development, but will eventually be merged back into stable (to add the new feature to
the upcoming release) or discarded (in case of a disappointing experiment).

In most workflows, the life of a feature branch will follow the life of its related ticket in the project’s issue tracker. Once the ticket is accepted and
closed, the feature branch may be removed from the repository as well.

Assuming the best practices regarding non-fast-forward merges and labeling of issue numbers in merge commits were followed, then the absence
of a named branch does not preclude the history of the related work from being reviewed.

Commit standards

Commit granularity

Commits should be granular and described in the commit message. For example, if a file needs to be changed to correct multiple issues, each
change should be made, committed, and described independently of each other. Technical leads and developers are open to determine the level
of granularity the project requires.

Commit messages

All commits should have the related ticket number prepended to it in a format allowing bug-trackers to easily detect and relate the commit
message to a ticket.

For JIRA projects, the commit message would follow the pattern "[ISSUE-KEY] Short description", for example:

[NOB-288] Set site name

For Redmine projects, the commit message would follow the pattern "[#TICKETNUMBER] Short description", for example:

[#50823] Publish Initiative nodes by default

Merges/pull requests

Merges should be created with merge commits. The way to do this in Git is through the use of non-fast-forward merges. (TODO: add more detail
here)