mirror of
https://github.com/jimeh/commonflow.org.git
synced 2026-02-19 05:46:40 +00:00
303 lines
15 KiB
HTML
303 lines
15 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link href='https://fonts.googleapis.com/css?family=Open+Sans+Condensed:700,300|Open+Sans:400italic,700italic,400,700' rel='stylesheet' type='text/css'>
|
|
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
|
<link rel="stylesheet" href="/css/main.css">
|
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
|
<title>Git Common-Flow 1.0.0-rc.2 | Git Common Flow</title>
|
|
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.2" />
|
|
<meta name="author" content="Jim Myhrberg" />
|
|
<meta property="og:locale" content="en_US" />
|
|
<meta name="description" content="An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification." />
|
|
<meta property="og:description" content="An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification." />
|
|
<link rel="canonical" href="https://commonflow.org/spec/1.0.0-rc.2.html" />
|
|
<meta property="og:url" content="https://commonflow.org/spec/1.0.0-rc.2.html" />
|
|
<meta property="og:site_name" content="Git Common Flow" />
|
|
<script type="application/ld+json">
|
|
{"@context":"http://schema.org","@type":"WebPage","headline":"Git Common-Flow 1.0.0-rc.2","author":{"@type":"Person","name":"Jim Myhrberg"},"description":"An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification.","url":"https://commonflow.org/spec/1.0.0-rc.2.html"}</script>
|
|
<!-- End Jekyll SEO tag -->
|
|
|
|
</head>
|
|
<body>
|
|
<div id="layout">
|
|
<a href="#menu" id="menuLink" class="menu-link">
|
|
<span></span>
|
|
</a>
|
|
<div id="menu">
|
|
<div class="pure-menu">
|
|
<ul class="pure-menu-list">
|
|
<li class="pure-menu-item">
|
|
<div class="pure-menu-label">Versions:</div>
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li class="pure-menu-item version-1.0.0-rc.2 pure-menu-selected">
|
|
<a href="/spec/1.0.0-rc.2.html" class="pure-menu-link">1.0.0-rc.2</a>
|
|
</li>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<li class="pure-menu-item version-1.0.0-rc.1">
|
|
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</a>
|
|
</li>
|
|
|
|
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div id="main">
|
|
<div class="content">
|
|
<h1 id="git-common-flow-100-rc2">Git Common-Flow 1.0.0-rc.2</h1>
|
|
|
|
<p><img src="/spec/1.0.0-rc.2.svg" width="100%" /></p>
|
|
|
|
<h2 id="summary">Summary</h2>
|
|
|
|
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
|
usage patterns of git into a single and concise specification. It is based on
|
|
the <a href="http://scottchacon.com/2011/08/31/github-flow.html">original variant</a>
|
|
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
|
into account how a lot of open source projects use git.</p>
|
|
|
|
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
|
releases, maintenance releases for old versions, and without the requirement to
|
|
deploy to production all the time.</p>
|
|
|
|
<h2 id="terminology">Terminology</h2>
|
|
|
|
<ul>
|
|
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
|
edge, and must be named <code class="highlighter-rouge">master</code>.</li>
|
|
<li><strong>Change Branches</strong> - Any branch that introduces changes like a new feature, a
|
|
bug fix, etc.</li>
|
|
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
|
changes in the source branch should be incorporated into the change branch via
|
|
rebasing.</li>
|
|
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
|
branch. Typically the merge target branch will be the same as the source
|
|
branch.</li>
|
|
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
|
its merge target, allowing others to review, discuss and approve the changes.</li>
|
|
<li><strong>Release</strong> - Consists of a version bump commit, and a git tag named according
|
|
to the new version string placed on said commit.</li>
|
|
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
|
also for long-term maintenance of older version.</li>
|
|
</ul>
|
|
|
|
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
|
|
|
<p>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 <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
|
|
|
<ol>
|
|
<li>The Master Branch
|
|
<ol>
|
|
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
|
"master branch".</li>
|
|
<li>The master branch MUST be considered bleeding edge.</li>
|
|
<li>The master branch MUST always be in a non-broken state with its test
|
|
suite passing.</li>
|
|
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
|
release/production" state to reduce any friction with creating a new
|
|
release.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Change Branches
|
|
<ol>
|
|
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
|
branches that SHOULD be referred to as "change branches". All change
|
|
branches MUST have descriptive names. It is RECOMMENDED that you commit
|
|
often locally, and you SHOULD regularly push your work to the same named
|
|
branch on the remote server.</li>
|
|
<li>You MUST create separate change branches for each distinctly different
|
|
change. You MUST NOT include multiple unrelated changes into a single
|
|
change branch.</li>
|
|
<li>When a change branch is created, the branch that it is created from
|
|
SHOULD be referred to as the "source branch". Each change branch also
|
|
needs a designated "merge target" branch, typically this will be the same
|
|
as the source branch.</li>
|
|
<li>Change branches MUST be regularly updated with any changes from their
|
|
source branch. This MUST be done by rebasing the change branch on top of
|
|
the source branch.</li>
|
|
<li>After rebasing a change branch on top of its source branch you MUST push
|
|
the change branch to the remote server. This will require you to do a
|
|
force push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Pull Requests
|
|
<ol>
|
|
<li>To merge a change branch into its merge target, you MUST open a "pull
|
|
request" (or equivalent) so others can review and approve your changes.</li>
|
|
<li>A pull request MUST only be merged when the change branch is up-to-date
|
|
with its source branch, the test suite is passing, and you and others are
|
|
happy with the change. This is especially important if the merge target
|
|
is the master branch.</li>
|
|
<li>To get feedback, help, or generally just discuss a change branch with
|
|
others, the RECOMMENDED way to do so is by creating a pull request and
|
|
discuss the changes with others there.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Versioning
|
|
<ol>
|
|
<li>The project MUST have its version hard-coded somewhere in the
|
|
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
|
located in the root of the project.</li>
|
|
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
|
only contain the exact version string.</li>
|
|
<li>The version string SHOULD follow the Semantic Versioning
|
|
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
|
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
|
is bad, and "2.11.4" is good.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Releases
|
|
<ol>
|
|
<li>To create a new release, you MUST create a "version bump" commit which
|
|
changes the hard-coded version string of the project. The version bump
|
|
commit MUST have a git tag created on it and named as the exact version
|
|
string.</li>
|
|
<li>If you are not using a release branch, then the version bump commit MUST
|
|
be created directly on the master branch.</li>
|
|
<li>The version bump commit MUST have a commit message title of "Bump version
|
|
to VERSION". For example, if the new version string is "2.11.4", the
|
|
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
|
<li>The release tag on the version bump commit MUST be named exactly the same
|
|
as the version string. The tag name can OPTIONALLY be prefixed with
|
|
"v". For example the tag name can be either "2.11.4" or "v2.11.4". You
|
|
MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form
|
|
and stick to it.</li>
|
|
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
|
OPTIONALLY use annotated tags if you want to include changelog
|
|
information in the release tag itself.</li>
|
|
<li>If you use annotated release tags, the first line of the annotation MUST
|
|
read "Release VERSION". For example for version "2.11.4" the first line
|
|
of the tag annotation would read "Release 2.11.4". The second line must
|
|
be blank, and the changelog MUST start on the third line.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Release Branches
|
|
<ol>
|
|
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
|
as a "release branch".</li>
|
|
<li>Use of release branches is OPTIONAL.</li>
|
|
<li>Changes in a release branch SHOULD typically come from work being
|
|
done against the master branch. Meaning changes SHOULD only trickle
|
|
downwards from the master branch. If a change needs to trickle back up
|
|
into the master branch, that work should have happened against the master
|
|
branch in the first place. One exception to this is version bump commits.</li>
|
|
<li>There are two types of release branches; short-term, and long-term.</li>
|
|
<li>Short-Term Release Branches
|
|
<ol>
|
|
<li>Used for creating a specific versioned release.</li>
|
|
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
|
pre-release verification process to avoid a code freeze on the master
|
|
branch.</li>
|
|
<li>MUST have a name of "release-VERSION". For example for version
|
|
"2.11.4" the release branch name MUST be "release-2.11.4".</li>
|
|
<li>When using a short-term release branch, the version bump commit and
|
|
release tag MUST be made directly on the release branch itself.</li>
|
|
<li>Only very minor changes should be performed on a short-term release
|
|
branch directly. Any larger changes SHOULD be done in the master
|
|
branch, and SHOULD be pulled into the release branch by rebasing it
|
|
on top of the master branch the same way a change branch pulls in
|
|
updates from its source branch.</li>
|
|
<li>After the version bump commit and release tag have been created, the
|
|
release branch MUST be merged back into its source branch and then
|
|
deleted. Typically the source branch will be the master branch.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Long-Term Release Branches
|
|
<ol>
|
|
<li>Used for work on versions which are not currently part of the master
|
|
branch. Typically this is useful when you need to create a new
|
|
maintenance release for a older version.</li>
|
|
<li>The branch name MUST have a non-specific version number. For example
|
|
a long-term release branch for creating new 2.9.x releases would be
|
|
named "release-2.9".</li>
|
|
<li>To create a new release from a long-term release branch, you MUST
|
|
create a version bump commit and release tag directly on the release
|
|
branch.</li>
|
|
<li>A long-term release branch MUST be created from the relevant release
|
|
tag. For example if the master branch is on version 2.11.4 and there
|
|
is a security fix for all 2.9.x releases, the latest of which is
|
|
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7"
|
|
release tag. The security fix release will then end up being version
|
|
"2.9.8".</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>Bug Fixes & Rollback
|
|
<ol>
|
|
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
|
<li>If a change branch which has been merged into the master branch is found
|
|
to have a bug in it, the bug fix work MUST be done as a new separate
|
|
change branch and MUST follow the same workflow as any other change
|
|
branch.</li>
|
|
<li>If a change branch is wrongfully merged into master, or for any other
|
|
reason the merge must be undone, you MUST undo the merge by reverting the
|
|
merge commit itself. Effectively creating a new commit that reverses all
|
|
the relevant changes.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Git Best Practices
|
|
<ol>
|
|
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
|
the official git
|
|
documentation:
|
|
<a href="https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project">https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project</a></li>
|
|
<li>You SHOULD never blindly commit all changes with "git commit -a". It is
|
|
RECOMMENDED you use "git add -i" to add individual changes to the staging
|
|
area so you are fully aware of what you are committing.</li>
|
|
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
|
regular "--force" option is dangerous and destructive. More
|
|
information:
|
|
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
|
<li>You SHOULD understand and be comfortable with
|
|
rebasing: <a href="https://git-scm.com/book/en/v2/Git-Branching-Rebasing">https://git-scm.com/book/en/v2/Git-Branching-Rebasing</a></li>
|
|
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
|
pull" to avoid unnecessary merge commits. You can make this the default
|
|
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
|
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
|
This makes sure the reference to the original branch is kept in the
|
|
commits, allows one to revert a merge by reverting a single merge commit,
|
|
and creates a merge commit to mark the integration of the branch with
|
|
master.</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<h2 id="about">About</h2>
|
|
|
|
<p>The Git Common-Flow specification is authored
|
|
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
|
|
|
|
<p>If you'd like to leave feedback,
|
|
please <a href="https://github.com/jimeh/common-flow/issues">open an issue on GitHub</a>.</p>
|
|
|
|
<h2 id="license">License</h2>
|
|
|
|
<p><a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons - CC BY 3.0</a></p>
|
|
|
|
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<script src="/js/ui.js"></script>
|
|
</body>
|
|
</html>
|