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.5

Browse Source
This commit is contained in:
Jim Myhrberg
2018-05-04 13:27:45 +01:00
parent 9452466843
commit 7ab8829442
13 changed files with 890 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/index.html
View File

@@ -9,8 +9,8 @@
<link rel="stylesheet" href="https:////maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
<link type="text/css" rel="stylesheet" href="/assets/main-c6d2e6591d58bffada09ccc7f6d4f28960908c6bdb6192e726de2a896036b150.css">
<!-- Begin Jekyll SEO tag v2.2.3 -->
<title>Git Common-Flow 1.0.0-rc.4 | Git Common Flow</title>
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.4" />
<title>Git Common-Flow 1.0.0-rc.5 | Git Common Flow</title>
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.5" />
<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." />
@@ -19,7 +19,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.4","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.5","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>
@@ -34,7 +34,10 @@
<li class="pure-menu-item">
<div class="pure-menu-label">Versions:</div>
</li>
<li class="pure-menu-item version-1.0.0-rc.4 pure-menu-selected">
<li class="pure-menu-item version-1.0.0-rc.5 pure-menu-selected">
<a href="/spec/1.0.0-rc.5.html" class="pure-menu-link">1.0.0-rc.5</a>
</li>
<li class="pure-menu-item version-1.0.0-rc.4">
<a href="/spec/1.0.0-rc.4.html" class="pure-menu-link">1.0.0-rc.4</a>
</li>
<li class="pure-menu-item version-1.0.0-rc.3">
@@ -56,17 +59,30 @@
</div>
<div id="main">
<div class="content">
<h1 id="git-common-flow-100-rc4">Git Common-Flow 1.0.0-rc.4</h1>
<p><img src="/spec/1.0.0-rc.4.svg" width="100%" /></p>
<h2 id="summary">Summary</h2>
<h1 id="git-common-flow-100-rc5">Git Common-Flow 1.0.0-rc.5</h1>
<p><img src="/spec/1.0.0-rc.5.svg" width="100%" /></p>
<h2 id="introduction">Introduction</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>
into account how a lot of open source projects most commonly use git.</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="summary">Summary</h2>
<ul>
<li>The "master" branch is the mainline branch with latest changes, and must not
be broken.</li>
<li>Changes (features, bugfixes, etc.) are done on "change branches" created from
the master branch.</li>
<li>Rebase change branches <a href="https://i.imgur.com/1RS8x2d.png">early and often</a>.</li>
<li>When a change branch is stable and ready, it is merged back in to master.</li>
<li>A release is just a git tag who's name is the exact release version string
(e.g. "2.11.4").</li>
<li>Release branches can be used to avoid change freezes on master. They are not
required, instead they are available if you need them.</li>
</ul>
<h2 id="terminology">Terminology</h2>
<ul>
<li><strong>Master Branch</strong> - Must be named "master", must always have passing tests,
@@ -93,7 +109,7 @@
<ol>
<li>TL;DR
<ol>
<li>Don't break the master branch.</li>
<li>Do not break the master branch.</li>
<li>A release is a git tag.</li>
</ol>
</li>
@@ -162,8 +178,9 @@
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>
others, it is RECOMMENDED you create a pull request and discuss the
changes with others there. This leaves a clear and visible history of
how, when, and why the code looks and behaves the way it does.</li>
</ol>
</li>
<li>Versioning
@@ -263,8 +280,8 @@
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>
"release-2.9" from the "2.9.7" release tag. The security fix release will
then end up being version "2.9.8".</li>
<li>To create a new release from a long-term release branch, you MUST follow
the same process as a release from the master branch, except the
long-term release branch takes the place of the master branch.</li>
@@ -323,7 +340,7 @@
<ul>
<li>You create change branches instead of feature branches, without the need of a
"feature/" or "change/" prefix in the branch name.</li>
<li>Change branches are typically created off of and merged back into "master"
<li>Change branches are typically created from and merged back into "master"
instead of "develop".</li>
<li>Creating a release is done by simply creating a git tag, typically on the
master branch.</li>
@@ -367,12 +384,17 @@
<li>remove-sort-by-middle-name-functionality</li>
<li>update-font-awesome</li>
<li>change-search-behavior</li>
<li>improve-pagination-performance</li>
<li>tweak-footer-style</li>
</ul>
<p>Notice how none of these have any prefixes like "feature/" or "hotfix/", they're
not needed when branch names are properly descriptive. However there's nothing
to say you can't use such prefixes if you want. That also means that you can add
ticket number prefixes if your team/org has that as part of it's process.</p>
to say you can't use such prefixes if you want.</p>
<p>You can also add ticket numbers to the branch name if your team/org has that as
part of it's process. But it is recommended that ticket numbers are added to the
end of the branch name. The ticket number is essentially metadata, so put it at
the end and out of the way of humans trying to read the descriptive name from
left to right.</p>
<h3 id="how-do-we-release-an-emergency-hotfix-when-the-master-branch-is-broken">How do we release an emergency hotfix when the master branch is broken?</h3>
<p>This should ideally never happen, however if it does you can do one of the
following:</p>
@@ -390,11 +412,11 @@
the master branch when you have more time on your hands.</p>
<h2 id="about">About</h2>
<p>The Git Common-Flow specification is authored
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
by <a href="https://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>
<p><a href="https://creativecommons.org/licenses/by/4.0/">Creative Commons - CC BY 4.0</a></p>
</div>
</div>
</div>