jimeh/commonflow.org
1
0
Fork 0
mirror of https://github.com/jimeh/commonflow.org.git synced 2026-02-19 05:46:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update to version 1.0.0-rc.3

Browse Source
This commit is contained in:
Jim Myhrberg
2017-07-12 14:41:41 +01:00
parent 80ce565080
commit 65b73bce68
11 changed files with 580 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/index.html
View File

@@ -8,8 +8,8 @@
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
<link type="text/css" rel="stylesheet" href="/assets/main-082b10f3e2581d4b34b66958419ec52aec823571e474eb04ffdb3b7c4e6f455e.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" />
<title>Git Common-Flow 1.0.0-rc.3 | Git Common Flow</title>
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.3" />
<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." />
@@ -18,7 +18,7 @@
<meta property="og:url" content="https://commonflow.org/" />
<meta property="og:site_name" content="Git Common Flow" />
<script type="application/ld+json">
{"@context":"http://schema.org","@type":"WebSite","name":"Git Common Flow","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/"}
{"@context":"http://schema.org","@type":"WebSite","name":"Git Common Flow","headline":"Git Common-Flow 1.0.0-rc.3","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/"}
</script>
<!-- End Jekyll SEO tag -->
</head>
@@ -33,7 +33,10 @@
<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">
<li class="pure-menu-item version-1.0.0-rc.3 pure-menu-selected">
<a href="/spec/1.0.0-rc.3.html" class="pure-menu-link">1.0.0-rc.3</a>
</li>
<li class="pure-menu-item version-1.0.0-rc.2">
<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">
@@ -44,21 +47,21 @@
</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>
<h1 id="git-common-flow-100-rc3">Git Common-Flow 1.0.0-rc.3</h1>
<p><img src="/spec/1.0.0-rc.3.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>
<p>In short, Common-Flow is essentially GitHub Flow with the addition of versioned
releases, optional release branches, 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>Master Branch</strong> - Must be named "master", must always have passing tests,
and is not guaranteed to always work in production environments.</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
@@ -69,7 +72,8 @@
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
<li><strong>Release</strong> - May be considered safe to use in production
environments. 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>
@@ -79,13 +83,21 @@
"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>TL;DR
<ol>
<li>Don't break the master branch.</li>
<li>A release is a git tag.</li>
</ol>
</li>
<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 IS NOT guaranteed to always work in production
environments. Despite test suites passing it may at times contain
unfinished work. Only releases may be considered safe for production use.</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>
@@ -234,7 +246,7 @@
<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>
<a href="https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines">https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines</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>