jimeh/common-flow
1
0
Fork 0
mirror of https://github.com/jimeh/common-flow.git synced 2026-02-19 09:26:40 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
955328a5f274416f8ef4f0eee4df3bc81cf0a30c
common-flow/common-flow.md
Jim Myhrberg 955328a5f2 Updated specification
2017-07-01 14:46:41 +01:00

2.6 KiB
Raw Blame History

Git Common-Flow 1.0.0-draft.1

Summary

Common-Flow is an attempt to gather a sensible selection of the most common usage patterns of git out in the wild into a single and concise specification. It is based on the original variant of GitHub Flow, while taking into account how a lot of open source projects use git.

Branch types:

  • Master Branch - Should always be deployable / usable, is considered "bleeding edge", and must be named master.
  • Change Branches - Any branch that introduces changes (new feature, bug fix, etc), should be created off of master, and must have a descriptive name.
  • Maintenance Branches - Used to maintain old versions, and should follow a stable-X.Y naming pattern, where X is MAJOR version and Y is MINOR version.

Rules:

  • The master branch should always be deployable / usable, while considered to be "bleeding edge".
  • New work must be done on a descriptively named change branch created off of master.
  • Commit to the change branch locally, and regularly push your work to the same named branch on the remote server.
  • When you need feedback, help, or think the branch is ready for merging, open a pull request.
  • After someone else has reviewed and signed off on the change, you can merge it in to master.
  • New releases are created by committing a version bump commit directly to master, and then tagging that commit with the version.
  • Maintenance branches are updated by manually merging and/or backporting relevant change branches in to them.

Git Common-Flow Specification (Common-Flow)

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  1. A branch called "master" MUST exist, and it SHOULD be referred to as the "master branch". The master branch MUST always be in a non-broken state, but MUST be considered to be "bleeding edge". That means the master branch MUST always be in a good enough state that, depending on your deployment/release flow, a new release can always be built from master, or that master can always be safely deployed to production.
  2. Changes MUST be performed on a separate branch that SHOULD be referred to as a "change branch". All change branches MUST have descriptive names. You SHOULD commit often locally, and you MUST regularly push your work to the same named branch on the remote server.