mirror of
https://github.com/jimeh/commonflow.org.git
synced 2026-02-19 05:46:40 +00:00
Rebuild site with Google Analytics and tidy html
This commit is contained in:
@@ -8,19 +8,19 @@
|
|||||||
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
<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">
|
<link type="text/css" rel="stylesheet" href="/assets/main-082b10f3e2581d4b34b66958419ec52aec823571e474eb04ffdb3b7c4e6f455e.css">
|
||||||
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
||||||
<title>404 Page Not Found | Git Common Flow</title>
|
<title>404 Page Not Found | Git Common Flow</title>
|
||||||
<meta property="og:title" content="404 Page Not Found" />
|
<meta property="og:title" content="404 Page Not Found" />
|
||||||
<meta name="author" content="Jim Myhrberg" />
|
<meta name="author" content="Jim Myhrberg" />
|
||||||
<meta property="og:locale" content="en_US" />
|
<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 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." />
|
<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/404.html" />
|
<link rel="canonical" href="https://commonflow.org/404.html" />
|
||||||
<meta property="og:url" content="https://commonflow.org/404.html" />
|
<meta property="og:url" content="https://commonflow.org/404.html" />
|
||||||
<meta property="og:site_name" content="Git Common Flow" />
|
<meta property="og:site_name" content="Git Common Flow" />
|
||||||
<script type="application/ld+json">
|
<script type="application/ld+json">
|
||||||
{"@context":"http://schema.org","@type":"WebPage","headline":"404 Page Not Found","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/404.html"}</script>
|
{"@context":"http://schema.org","@type":"WebPage","headline":"404 Page Not Found","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/404.html"}
|
||||||
<!-- End Jekyll SEO tag -->
|
</script>
|
||||||
|
<!-- End Jekyll SEO tag -->
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<div id="layout">
|
<div id="layout">
|
||||||
@@ -33,42 +33,35 @@
|
|||||||
<li class="pure-menu-item">
|
<li class="pure-menu-item">
|
||||||
<div class="pure-menu-label">Versions:</div>
|
<div class="pure-menu-label">Versions:</div>
|
||||||
</li>
|
</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">
|
||||||
|
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</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">
|
|
||||||
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</a>
|
|
||||||
</li>
|
|
||||||
|
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div id="main">
|
<div id="main">
|
||||||
<div class="content">
|
<div class="content">
|
||||||
<div class="header">
|
<div class="header">
|
||||||
<h1>404</h1>
|
<h1>404</h1>
|
||||||
<p><strong>Page not found :(</strong></p>
|
<p><strong>Page not found :(</strong></p>
|
||||||
<p>The requested page could not be found.</p>
|
<p>The requested page could not be found.</p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
||||||
|
<script>
|
||||||
|
if (window.location.hostname == "commonflow.org") {
|
||||||
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||||
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||||
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||||
|
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
||||||
|
ga('create', 'UA-102330905-1', 'auto');
|
||||||
|
ga('send', 'pageview');
|
||||||
|
} else { _gaq = []; };
|
||||||
|
</script>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
516
docs/index.html
516
docs/index.html
@@ -8,19 +8,19 @@
|
|||||||
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
<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">
|
<link type="text/css" rel="stylesheet" href="/assets/main-082b10f3e2581d4b34b66958419ec52aec823571e474eb04ffdb3b7c4e6f455e.css">
|
||||||
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
||||||
<title>Git Common-Flow 1.0.0-rc.2 | Git Common Flow</title>
|
<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 property="og:title" content="Git Common-Flow 1.0.0-rc.2" />
|
||||||
<meta name="author" content="Jim Myhrberg" />
|
<meta name="author" content="Jim Myhrberg" />
|
||||||
<meta property="og:locale" content="en_US" />
|
<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 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." />
|
<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/" />
|
<link rel="canonical" href="https://commonflow.org/" />
|
||||||
<meta property="og:url" content="https://commonflow.org/" />
|
<meta property="og:url" content="https://commonflow.org/" />
|
||||||
<meta property="og:site_name" content="Git Common Flow" />
|
<meta property="og:site_name" content="Git Common Flow" />
|
||||||
<script type="application/ld+json">
|
<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/"}</script>
|
{"@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/"}
|
||||||
<!-- End Jekyll SEO tag -->
|
</script>
|
||||||
|
<!-- End Jekyll SEO tag -->
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<div id="layout">
|
<div id="layout">
|
||||||
@@ -33,270 +33,248 @@
|
|||||||
<li class="pure-menu-item">
|
<li class="pure-menu-item">
|
||||||
<div class="pure-menu-label">Versions:</div>
|
<div class="pure-menu-label">Versions:</div>
|
||||||
</li>
|
</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>
|
||||||
<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>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div id="main">
|
<div id="main">
|
||||||
<div class="content">
|
<div class="content">
|
||||||
<h1 id="git-common-flow-100-rc2">Git Common-Flow 1.0.0-rc.2</h1>
|
<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>
|
||||||
<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
|
||||||
<h2 id="summary">Summary</h2>
|
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>
|
||||||
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
||||||
usage patterns of git into a single and concise specification. It is based on
|
into account how a lot of open source projects use git.</p>
|
||||||
the <a href="http://scottchacon.com/2011/08/31/github-flow.html">original variant</a>
|
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
||||||
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
releases, maintenance releases for old versions, and without the requirement to
|
||||||
into account how a lot of open source projects use git.</p>
|
deploy to production all the time.</p>
|
||||||
|
<h2 id="terminology">Terminology</h2>
|
||||||
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
<ul>
|
||||||
releases, maintenance releases for old versions, and without the requirement to
|
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
||||||
deploy to production all the time.</p>
|
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
|
||||||
<h2 id="terminology">Terminology</h2>
|
bug fix, etc.</li>
|
||||||
|
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
||||||
<ul>
|
changes in the source branch should be incorporated into the change branch via
|
||||||
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
rebasing.</li>
|
||||||
edge, and must be named <code class="highlighter-rouge">master</code>.</li>
|
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
||||||
<li><strong>Change Branches</strong> - Any branch that introduces changes like a new feature, a
|
branch. Typically the merge target branch will be the same as the source
|
||||||
bug fix, etc.</li>
|
branch.</li>
|
||||||
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
||||||
changes in the source branch should be incorporated into the change branch via
|
its merge target, allowing others to review, discuss and approve the changes.</li>
|
||||||
rebasing.</li>
|
<li><strong>Release</strong> - Consists of a version bump commit, and a git tag named according
|
||||||
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
to the new version string placed on said commit.</li>
|
||||||
branch. Typically the merge target branch will be the same as the source
|
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
||||||
branch.</li>
|
also for long-term maintenance of older version.</li>
|
||||||
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
</ul>
|
||||||
its merge target, allowing others to review, discuss and approve the changes.</li>
|
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
||||||
<li><strong>Release</strong> - Consists of a version bump commit, and a git tag named according
|
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
||||||
to the new version string placed on said commit.</li>
|
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
||||||
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
||||||
also for long-term maintenance of older version.</li>
|
<ol>
|
||||||
</ul>
|
<li>The Master Branch
|
||||||
|
<ol>
|
||||||
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
||||||
|
"master branch".</li>
|
||||||
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
<li>The master branch MUST be considered bleeding edge.</li>
|
||||||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
<li>The master branch MUST always be in a non-broken state with its test
|
||||||
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
suite passing.</li>
|
||||||
|
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
||||||
<ol>
|
release/production" state to reduce any friction with creating a new
|
||||||
<li>The Master Branch
|
release.</li>
|
||||||
<ol>
|
</ol>
|
||||||
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
</li>
|
||||||
"master branch".</li>
|
<li>Change Branches
|
||||||
<li>The master branch MUST be considered bleeding edge.</li>
|
<ol>
|
||||||
<li>The master branch MUST always be in a non-broken state with its test
|
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
||||||
suite passing.</li>
|
branches that SHOULD be referred to as "change branches". All change
|
||||||
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
branches MUST have descriptive names. It is RECOMMENDED that you commit
|
||||||
release/production" state to reduce any friction with creating a new
|
often locally, and you SHOULD regularly push your work to the same named
|
||||||
release.</li>
|
branch on the remote server.</li>
|
||||||
</ol>
|
<li>You MUST create separate change branches for each distinctly different
|
||||||
</li>
|
change. You MUST NOT include multiple unrelated changes into a single
|
||||||
<li>Change Branches
|
change branch.</li>
|
||||||
<ol>
|
<li>When a change branch is created, the branch that it is created from
|
||||||
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
SHOULD be referred to as the "source branch". Each change branch also
|
||||||
branches that SHOULD be referred to as "change branches". All change
|
needs a designated "merge target" branch, typically this will be the same
|
||||||
branches MUST have descriptive names. It is RECOMMENDED that you commit
|
as the source branch.</li>
|
||||||
often locally, and you SHOULD regularly push your work to the same named
|
<li>Change branches MUST be regularly updated with any changes from their
|
||||||
branch on the remote server.</li>
|
source branch. This MUST be done by rebasing the change branch on top of
|
||||||
<li>You MUST create separate change branches for each distinctly different
|
the source branch.</li>
|
||||||
change. You MUST NOT include multiple unrelated changes into a single
|
<li>After rebasing a change branch on top of its source branch you MUST push
|
||||||
change branch.</li>
|
the change branch to the remote server. This will require you to do a
|
||||||
<li>When a change branch is created, the branch that it is created from
|
force push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
||||||
SHOULD be referred to as the "source branch". Each change branch also
|
</ol>
|
||||||
needs a designated "merge target" branch, typically this will be the same
|
</li>
|
||||||
as the source branch.</li>
|
<li>Pull Requests
|
||||||
<li>Change branches MUST be regularly updated with any changes from their
|
<ol>
|
||||||
source branch. This MUST be done by rebasing the change branch on top of
|
<li>To merge a change branch into its merge target, you MUST open a "pull
|
||||||
the source branch.</li>
|
request" (or equivalent) so others can review and approve your changes.</li>
|
||||||
<li>After rebasing a change branch on top of its source branch you MUST push
|
<li>A pull request MUST only be merged when the change branch is up-to-date
|
||||||
the change branch to the remote server. This will require you to do a
|
with its source branch, the test suite is passing, and you and others are
|
||||||
force push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
happy with the change. This is especially important if the merge target
|
||||||
</ol>
|
is the master branch.</li>
|
||||||
</li>
|
<li>To get feedback, help, or generally just discuss a change branch with
|
||||||
<li>Pull Requests
|
others, the RECOMMENDED way to do so is by creating a pull request and
|
||||||
<ol>
|
discuss the changes with others there.</li>
|
||||||
<li>To merge a change branch into its merge target, you MUST open a "pull
|
</ol>
|
||||||
request" (or equivalent) so others can review and approve your changes.</li>
|
</li>
|
||||||
<li>A pull request MUST only be merged when the change branch is up-to-date
|
<li>Versioning
|
||||||
with its source branch, the test suite is passing, and you and others are
|
<ol>
|
||||||
happy with the change. This is especially important if the merge target
|
<li>The project MUST have its version hard-coded somewhere in the
|
||||||
is the master branch.</li>
|
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
||||||
<li>To get feedback, help, or generally just discuss a change branch with
|
located in the root of the project.</li>
|
||||||
others, the RECOMMENDED way to do so is by creating a pull request and
|
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
||||||
discuss the changes with others there.</li>
|
only contain the exact version string.</li>
|
||||||
</ol>
|
<li>The version string SHOULD follow the Semantic Versioning
|
||||||
</li>
|
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
||||||
<li>Versioning
|
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
||||||
<ol>
|
is bad, and "2.11.4" is good.</li>
|
||||||
<li>The project MUST have its version hard-coded somewhere in the
|
</ol>
|
||||||
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
</li>
|
||||||
located in the root of the project.</li>
|
<li>Releases
|
||||||
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
<ol>
|
||||||
only contain the exact version string.</li>
|
<li>To create a new release, you MUST create a "version bump" commit which
|
||||||
<li>The version string SHOULD follow the Semantic Versioning
|
changes the hard-coded version string of the project. The version bump
|
||||||
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
commit MUST have a git tag created on it and named as the exact version
|
||||||
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
string.</li>
|
||||||
is bad, and "2.11.4" is good.</li>
|
<li>If you are not using a release branch, then the version bump commit MUST
|
||||||
</ol>
|
be created directly on the master branch.</li>
|
||||||
</li>
|
<li>The version bump commit MUST have a commit message title of "Bump version
|
||||||
<li>Releases
|
to VERSION". For example, if the new version string is "2.11.4", the
|
||||||
<ol>
|
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
||||||
<li>To create a new release, you MUST create a "version bump" commit which
|
<li>The release tag on the version bump commit MUST be named exactly the same
|
||||||
changes the hard-coded version string of the project. The version bump
|
as the version string. The tag name can OPTIONALLY be prefixed with
|
||||||
commit MUST have a git tag created on it and named as the exact version
|
"v". For example the tag name can be either "2.11.4" or "v2.11.4". You
|
||||||
string.</li>
|
MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form
|
||||||
<li>If you are not using a release branch, then the version bump commit MUST
|
and stick to it.</li>
|
||||||
be created directly on the master branch.</li>
|
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
||||||
<li>The version bump commit MUST have a commit message title of "Bump version
|
OPTIONALLY use annotated tags if you want to include changelog
|
||||||
to VERSION". For example, if the new version string is "2.11.4", the
|
information in the release tag itself.</li>
|
||||||
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
<li>If you use annotated release tags, the first line of the annotation MUST
|
||||||
<li>The release tag on the version bump commit MUST be named exactly the same
|
read "Release VERSION". For example for version "2.11.4" the first line
|
||||||
as the version string. The tag name can OPTIONALLY be prefixed with
|
of the tag annotation would read "Release 2.11.4". The second line must
|
||||||
"v". For example the tag name can be either "2.11.4" or "v2.11.4". You
|
be blank, and the changelog MUST start on the third line.</li>
|
||||||
MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form
|
</ol>
|
||||||
and stick to it.</li>
|
</li>
|
||||||
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
<li>Release Branches
|
||||||
OPTIONALLY use annotated tags if you want to include changelog
|
<ol>
|
||||||
information in the release tag itself.</li>
|
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
||||||
<li>If you use annotated release tags, the first line of the annotation MUST
|
as a "release branch".</li>
|
||||||
read "Release VERSION". For example for version "2.11.4" the first line
|
<li>Use of release branches is OPTIONAL.</li>
|
||||||
of the tag annotation would read "Release 2.11.4". The second line must
|
<li>Changes in a release branch SHOULD typically come from work being
|
||||||
be blank, and the changelog MUST start on the third line.</li>
|
done against the master branch. Meaning changes SHOULD only trickle
|
||||||
</ol>
|
downwards from the master branch. If a change needs to trickle back up
|
||||||
</li>
|
into the master branch, that work should have happened against the master
|
||||||
<li>Release Branches
|
branch in the first place. One exception to this is version bump commits.</li>
|
||||||
<ol>
|
<li>There are two types of release branches; short-term, and long-term.</li>
|
||||||
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
<li>Short-Term Release Branches
|
||||||
as a "release branch".</li>
|
<ol>
|
||||||
<li>Use of release branches is OPTIONAL.</li>
|
<li>Used for creating a specific versioned release.</li>
|
||||||
<li>Changes in a release branch SHOULD typically come from work being
|
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
||||||
done against the master branch. Meaning changes SHOULD only trickle
|
pre-release verification process to avoid a code freeze on the master
|
||||||
downwards from the master branch. If a change needs to trickle back up
|
branch.</li>
|
||||||
into the master branch, that work should have happened against the master
|
<li>MUST have a name of "release-VERSION". For example for version
|
||||||
branch in the first place. One exception to this is version bump commits.</li>
|
"2.11.4" the release branch name MUST be "release-2.11.4".</li>
|
||||||
<li>There are two types of release branches; short-term, and long-term.</li>
|
<li>When using a short-term release branch, the version bump commit and
|
||||||
<li>Short-Term Release Branches
|
release tag MUST be made directly on the release branch itself.</li>
|
||||||
<ol>
|
<li>Only very minor changes should be performed on a short-term release
|
||||||
<li>Used for creating a specific versioned release.</li>
|
branch directly. Any larger changes SHOULD be done in the master
|
||||||
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
branch, and SHOULD be pulled into the release branch by rebasing it
|
||||||
pre-release verification process to avoid a code freeze on the master
|
on top of the master branch the same way a change branch pulls in
|
||||||
branch.</li>
|
updates from its source branch.</li>
|
||||||
<li>MUST have a name of "release-VERSION". For example for version
|
<li>After the version bump commit and release tag have been created, the
|
||||||
"2.11.4" the release branch name MUST be "release-2.11.4".</li>
|
release branch MUST be merged back into its source branch and then
|
||||||
<li>When using a short-term release branch, the version bump commit and
|
deleted. Typically the source branch will be the master branch.</li>
|
||||||
release tag MUST be made directly on the release branch itself.</li>
|
</ol>
|
||||||
<li>Only very minor changes should be performed on a short-term release
|
</li>
|
||||||
branch directly. Any larger changes SHOULD be done in the master
|
<li>Long-Term Release Branches
|
||||||
branch, and SHOULD be pulled into the release branch by rebasing it
|
<ol>
|
||||||
on top of the master branch the same way a change branch pulls in
|
<li>Used for work on versions which are not currently part of the master
|
||||||
updates from its source branch.</li>
|
branch. Typically this is useful when you need to create a new
|
||||||
<li>After the version bump commit and release tag have been created, the
|
maintenance release for a older version.</li>
|
||||||
release branch MUST be merged back into its source branch and then
|
<li>The branch name MUST have a non-specific version number. For example
|
||||||
deleted. Typically the source branch will be the master branch.</li>
|
a long-term release branch for creating new 2.9.x releases would be
|
||||||
</ol>
|
named "release-2.9".</li>
|
||||||
</li>
|
<li>To create a new release from a long-term release branch, you MUST
|
||||||
<li>Long-Term Release Branches
|
create a version bump commit and release tag directly on the release
|
||||||
<ol>
|
branch.</li>
|
||||||
<li>Used for work on versions which are not currently part of the master
|
<li>A long-term release branch MUST be created from the relevant release
|
||||||
branch. Typically this is useful when you need to create a new
|
tag. For example if the master branch is on version 2.11.4 and there
|
||||||
maintenance release for a older version.</li>
|
is a security fix for all 2.9.x releases, the latest of which is
|
||||||
<li>The branch name MUST have a non-specific version number. For example
|
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7"
|
||||||
a long-term release branch for creating new 2.9.x releases would be
|
release tag. The security fix release will then end up being version
|
||||||
named "release-2.9".</li>
|
"2.9.8".</li>
|
||||||
<li>To create a new release from a long-term release branch, you MUST
|
</ol>
|
||||||
create a version bump commit and release tag directly on the release
|
</li>
|
||||||
branch.</li>
|
</ol>
|
||||||
<li>A long-term release branch MUST be created from the relevant release
|
</li>
|
||||||
tag. For example if the master branch is on version 2.11.4 and there
|
<li>Bug Fixes & Rollback
|
||||||
is a security fix for all 2.9.x releases, the latest of which is
|
<ol>
|
||||||
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7"
|
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
||||||
release tag. The security fix release will then end up being version
|
<li>If a change branch which has been merged into the master branch is found
|
||||||
"2.9.8".</li>
|
to have a bug in it, the bug fix work MUST be done as a new separate
|
||||||
</ol>
|
change branch and MUST follow the same workflow as any other change
|
||||||
</li>
|
branch.</li>
|
||||||
</ol>
|
<li>If a change branch is wrongfully merged into master, or for any other
|
||||||
</li>
|
reason the merge must be undone, you MUST undo the merge by reverting the
|
||||||
<li>Bug Fixes & Rollback
|
merge commit itself. Effectively creating a new commit that reverses all
|
||||||
<ol>
|
the relevant changes.</li>
|
||||||
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
</ol>
|
||||||
<li>If a change branch which has been merged into the master branch is found
|
</li>
|
||||||
to have a bug in it, the bug fix work MUST be done as a new separate
|
<li>Git Best Practices
|
||||||
change branch and MUST follow the same workflow as any other change
|
<ol>
|
||||||
branch.</li>
|
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
||||||
<li>If a change branch is wrongfully merged into master, or for any other
|
the official git
|
||||||
reason the merge must be undone, you MUST undo the merge by reverting the
|
documentation:
|
||||||
merge commit itself. Effectively creating a new commit that reverses all
|
<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>
|
||||||
the relevant changes.</li>
|
<li>You SHOULD never blindly commit all changes with "git commit -a". It is
|
||||||
</ol>
|
RECOMMENDED you use "git add -i" to add individual changes to the staging
|
||||||
</li>
|
area so you are fully aware of what you are committing.</li>
|
||||||
<li>Git Best Practices
|
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
||||||
<ol>
|
regular "--force" option is dangerous and destructive. More
|
||||||
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
information:
|
||||||
the official git
|
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
||||||
documentation:
|
<li>You SHOULD understand and be comfortable with
|
||||||
<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>
|
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>You SHOULD never blindly commit all changes with "git commit -a". It is
|
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
||||||
RECOMMENDED you use "git add -i" to add individual changes to the staging
|
pull" to avoid unnecessary merge commits. You can make this the default
|
||||||
area so you are fully aware of what you are committing.</li>
|
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
||||||
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
||||||
regular "--force" option is dangerous and destructive. More
|
This makes sure the reference to the original branch is kept in the
|
||||||
information:
|
commits, allows one to revert a merge by reverting a single merge commit,
|
||||||
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
and creates a merge commit to mark the integration of the branch with
|
||||||
<li>You SHOULD understand and be comfortable with
|
master.</li>
|
||||||
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>
|
</ol>
|
||||||
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
</li>
|
||||||
pull" to avoid unnecessary merge commits. You can make this the default
|
</ol>
|
||||||
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
<h2 id="about">About</h2>
|
||||||
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
<p>The Git Common-Flow specification is authored
|
||||||
This makes sure the reference to the original branch is kept in the
|
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
|
||||||
commits, allows one to revert a merge by reverting a single merge commit,
|
<p>If you'd like to leave feedback,
|
||||||
and creates a merge commit to mark the integration of the branch with
|
please <a href="https://github.com/jimeh/common-flow/issues">open an issue on GitHub</a>.</p>
|
||||||
master.</li>
|
<h2 id="license">License</h2>
|
||||||
</ol>
|
<p><a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons - CC BY 3.0</a></p>
|
||||||
</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>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
||||||
|
<script>
|
||||||
|
if (window.location.hostname == "commonflow.org") {
|
||||||
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||||
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||||
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||||
|
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
||||||
|
ga('create', 'UA-102330905-1', 'auto');
|
||||||
|
ga('send', 'pageview');
|
||||||
|
} else { _gaq = []; };
|
||||||
|
</script>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
@@ -1 +1 @@
|
|||||||
Sitemap: https://commonflow.org/sitemap.xml
|
Sitemap: https://commonflow.org/sitemap.xml
|
||||||
@@ -1,12 +1,12 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8"?>
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
<urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd" xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
<urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd" xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||||
<url>
|
<url>
|
||||||
<loc>https://commonflow.org/spec/1.0.0-rc.1.html</loc>
|
<loc>https://commonflow.org/spec/1.0.0-rc.1.html</loc>
|
||||||
</url>
|
</url>
|
||||||
<url>
|
<url>
|
||||||
<loc>https://commonflow.org/spec/1.0.0-rc.2.html</loc>
|
<loc>https://commonflow.org/spec/1.0.0-rc.2.html</loc>
|
||||||
</url>
|
</url>
|
||||||
<url>
|
<url>
|
||||||
<loc>https://commonflow.org/</loc>
|
<loc>https://commonflow.org/</loc>
|
||||||
</url>
|
</url>
|
||||||
</urlset>
|
</urlset>
|
||||||
@@ -8,19 +8,19 @@
|
|||||||
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
<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">
|
<link type="text/css" rel="stylesheet" href="/assets/main-082b10f3e2581d4b34b66958419ec52aec823571e474eb04ffdb3b7c4e6f455e.css">
|
||||||
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
||||||
<title>Git Common-Flow 1.0.0-rc.1 | Git Common Flow</title>
|
<title>Git Common-Flow 1.0.0-rc.1 | Git Common Flow</title>
|
||||||
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.1" />
|
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.1" />
|
||||||
<meta name="author" content="Jim Myhrberg" />
|
<meta name="author" content="Jim Myhrberg" />
|
||||||
<meta property="og:locale" content="en_US" />
|
<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 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." />
|
<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.1.html" />
|
<link rel="canonical" href="https://commonflow.org/spec/1.0.0-rc.1.html" />
|
||||||
<meta property="og:url" content="https://commonflow.org/spec/1.0.0-rc.1.html" />
|
<meta property="og:url" content="https://commonflow.org/spec/1.0.0-rc.1.html" />
|
||||||
<meta property="og:site_name" content="Git Common Flow" />
|
<meta property="og:site_name" content="Git Common Flow" />
|
||||||
<script type="application/ld+json">
|
<script type="application/ld+json">
|
||||||
{"@context":"http://schema.org","@type":"WebPage","headline":"Git Common-Flow 1.0.0-rc.1","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.1.html"}</script>
|
{"@context":"http://schema.org","@type":"WebPage","headline":"Git Common-Flow 1.0.0-rc.1","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.1.html"}
|
||||||
<!-- End Jekyll SEO tag -->
|
</script>
|
||||||
|
<!-- End Jekyll SEO tag -->
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<div id="layout">
|
<div id="layout">
|
||||||
@@ -33,236 +33,214 @@
|
|||||||
<li class="pure-menu-item">
|
<li class="pure-menu-item">
|
||||||
<div class="pure-menu-label">Versions:</div>
|
<div class="pure-menu-label">Versions:</div>
|
||||||
</li>
|
</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 pure-menu-selected">
|
||||||
|
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</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 pure-menu-selected">
|
|
||||||
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</a>
|
|
||||||
</li>
|
|
||||||
|
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div id="main">
|
<div id="main">
|
||||||
<div class="content">
|
<div class="content">
|
||||||
<h1 id="git-common-flow-100-rc1">Git Common-Flow 1.0.0-rc.1</h1>
|
<h1 id="git-common-flow-100-rc1">Git Common-Flow 1.0.0-rc.1</h1>
|
||||||
|
<p><img src="/spec/1.0.0-rc.1.svg" width="100%" /></p>
|
||||||
<p><img src="/spec/1.0.0-rc.1.svg" width="100%" /></p>
|
<h2 id="summary">Summary</h2>
|
||||||
|
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
||||||
<h2 id="summary">Summary</h2>
|
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>
|
||||||
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
||||||
usage patterns of git into a single and concise specification. It is based on
|
into account how a lot of open source projects use git.</p>
|
||||||
the <a href="http://scottchacon.com/2011/08/31/github-flow.html">original variant</a>
|
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
||||||
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
releases, maintenance releases for old versions, and without the requirement to
|
||||||
into account how a lot of open source projects use git.</p>
|
deploy to production all the time.</p>
|
||||||
|
<h2 id="terminology">Terminology</h2>
|
||||||
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
<ul>
|
||||||
releases, maintenance releases for old versions, and without the requirement to
|
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
||||||
deploy to production all the time.</p>
|
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
|
||||||
<h2 id="terminology">Terminology</h2>
|
bug fix, etc.</li>
|
||||||
|
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
||||||
<ul>
|
changes in the source branch should be incorporated into the change branch via
|
||||||
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
rebasing.</li>
|
||||||
edge, and must be named <code class="highlighter-rouge">master</code>.</li>
|
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
||||||
<li><strong>Change Branches</strong> - Any branch that introduces changes like a new feature, a
|
branch. Typically the merge target branch will be the same as the source
|
||||||
bug fix, etc.</li>
|
branch.</li>
|
||||||
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
<li><strong>Maintenance Branches</strong> - Used for maintaining old versions and releasing
|
||||||
changes in the source branch should be incorporated into the change branch via
|
PATCH updates when the master branch has moved on. Should follow a
|
||||||
rebasing.</li>
|
<code class="highlighter-rouge">stable-X.Y</code> naming pattern, where <code class="highlighter-rouge">X</code> is MAJOR version and <code class="highlighter-rouge">Y</code> is MINOR
|
||||||
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
version.</li>
|
||||||
branch. Typically the merge target branch will be the same as the source
|
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
||||||
branch.</li>
|
its merge target, allowing others to review, discuss and approve the changes.</li>
|
||||||
<li><strong>Maintenance Branches</strong> - Used for maintaining old versions and releasing
|
<li><strong>Release</strong> - Consists of a version bump commit directly on the master branch,
|
||||||
PATCH updates when the master branch has moved on. Should follow a
|
and a git tag named according to the new version string placed on said commit.</li>
|
||||||
<code class="highlighter-rouge">stable-X.Y</code> naming pattern, where <code class="highlighter-rouge">X</code> is MAJOR version and <code class="highlighter-rouge">Y</code> is MINOR
|
<li><strong>Maintenance Release</strong> - Just like a regular release, except the version bump
|
||||||
version.</li>
|
commit and release tag are on a maintenance branch instead of the master
|
||||||
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
branch.</li>
|
||||||
its merge target, allowing others to review, discuss and approve the changes.</li>
|
</ul>
|
||||||
<li><strong>Release</strong> - Consists of a version bump commit directly on the master branch,
|
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
||||||
and a git tag named according to the new version string placed on said commit.</li>
|
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
||||||
<li><strong>Maintenance Release</strong> - Just like a regular release, except the version bump
|
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
||||||
commit and release tag are on a maintenance branch instead of the master
|
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
||||||
branch.</li>
|
<ol>
|
||||||
</ul>
|
<li>The Master Branch
|
||||||
|
<ol>
|
||||||
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
||||||
|
"master branch".</li>
|
||||||
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
<li>The master branch MUST be considered bleeding edge.</li>
|
||||||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
<li>The master branch MUST always be in a non-broken state with its test
|
||||||
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
suite passing.</li>
|
||||||
|
<li>The master branch SHOULD always be in a "as near as possible ready for
|
||||||
<ol>
|
release/production" state to reduce the friction of creating a new
|
||||||
<li>The Master Branch
|
release.</li>
|
||||||
<ol>
|
</ol>
|
||||||
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
</li>
|
||||||
"master branch".</li>
|
<li>Changes
|
||||||
<li>The master branch MUST be considered bleeding edge.</li>
|
<ol>
|
||||||
<li>The master branch MUST always be in a non-broken state with its test
|
<li>Changes MUST be performed on a separate branch that SHOULD be referred to
|
||||||
suite passing.</li>
|
as a "change branch". All change branches MUST have descriptive names. It
|
||||||
<li>The master branch SHOULD always be in a "as near as possible ready for
|
is RECOMMENDED that you commit often locally, and you SHOULD regularly
|
||||||
release/production" state to reduce the friction of creating a new
|
push your work to the same named branch on the remote server.</li>
|
||||||
release.</li>
|
<li>When a change branch is created, the branch that it is created from
|
||||||
</ol>
|
SHOULD be referred to as the "source branch". Each change branch also
|
||||||
</li>
|
needs a designated "merge target branch", typically this will be the same
|
||||||
<li>Changes
|
as the source branch.</li>
|
||||||
<ol>
|
<li>Change branches MUST be regularly updated with any changes from their
|
||||||
<li>Changes MUST be performed on a separate branch that SHOULD be referred to
|
source branch. This MUST be done by rebasing the change branch on top of
|
||||||
as a "change branch". All change branches MUST have descriptive names. It
|
the source branch. To be clear you MUST NOT merge a source branch into a
|
||||||
is RECOMMENDED that you commit often locally, and you SHOULD regularly
|
change branch.</li>
|
||||||
push your work to the same named branch on the remote server.</li>
|
<li>After rebasing a change branch on top of its source branch you MUST push
|
||||||
<li>When a change branch is created, the branch that it is created from
|
the change branch to the remote server. This will require you do a force
|
||||||
SHOULD be referred to as the "source branch". Each change branch also
|
push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
||||||
needs a designated "merge target branch", typically this will be the same
|
<li>To merge a change branch into its merge target branch, you MUST open a
|
||||||
as the source branch.</li>
|
"pull request" (or equivalent) so others can review and approve your
|
||||||
<li>Change branches MUST be regularly updated with any changes from their
|
changes.</li>
|
||||||
source branch. This MUST be done by rebasing the change branch on top of
|
<li>A pull request MUST only be merged when the change branch is up-to-date
|
||||||
the source branch. To be clear you MUST NOT merge a source branch into a
|
with its source branch, the test suite is passing, and you and others are
|
||||||
change branch.</li>
|
happy with the change. This is especially important if the merge target
|
||||||
<li>After rebasing a change branch on top of its source branch you MUST push
|
is the master branch.</li>
|
||||||
the change branch to the remote server. This will require you do a force
|
<li>To get feedback, help, or generally just discuss a change branch with
|
||||||
push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
others, it is RECOMMENDED you do this by creating a pull request and
|
||||||
<li>To merge a change branch into its merge target branch, you MUST open a
|
discuss the changes with others there.</li>
|
||||||
"pull request" (or equivalent) so others can review and approve your
|
</ol>
|
||||||
changes.</li>
|
</li>
|
||||||
<li>A pull request MUST only be merged when the change branch is up-to-date
|
<li>Git Best Practices
|
||||||
with its source branch, the test suite is passing, and you and others are
|
<ol>
|
||||||
happy with the change. This is especially important if the merge target
|
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
||||||
is the master branch.</li>
|
the official git
|
||||||
<li>To get feedback, help, or generally just discuss a change branch with
|
documentation:
|
||||||
others, it is RECOMMENDED you do this by creating a pull request and
|
<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>
|
||||||
discuss the changes with others there.</li>
|
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
||||||
</ol>
|
plain "--force" option is dangerous and destructive. More
|
||||||
</li>
|
information:
|
||||||
<li>Git Best Practices
|
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
||||||
<ol>
|
<li>You SHOULD understand and be comfortable with
|
||||||
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
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>
|
||||||
the official git
|
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
||||||
documentation:
|
pull" to avoid unnecessary merge commits. You can make this the default
|
||||||
<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>
|
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
||||||
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
||||||
plain "--force" option is dangerous and destructive. More
|
This makes sure the reference to the original branch is kept in the commits,
|
||||||
information:
|
allows one to revert a merge by reverting a single merge commit, and creates
|
||||||
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
a merge commit to mark the integration of the branch with master.</li>
|
||||||
<li>You SHOULD understand and be comfortable with
|
</ol>
|
||||||
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>
|
||||||
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
<li>Versioning
|
||||||
pull" to avoid unnecessary merge commits. You can make this the default
|
<ol>
|
||||||
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
<li>The project MUST have its version hard-coded somewhere in the
|
||||||
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
||||||
This makes sure the reference to the original branch is kept in the commits,
|
located in the root of the project.</li>
|
||||||
allows one to revert a merge by reverting a single merge commit, and creates
|
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
||||||
a merge commit to mark the integration of the branch with master.</li>
|
only contain the exact version string.</li>
|
||||||
</ol>
|
<li>The version string SHOULD follow the Semantic Versioning
|
||||||
</li>
|
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
||||||
<li>Versioning
|
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
||||||
<ol>
|
is bad, and "2.11.4" is good.</li>
|
||||||
<li>The project MUST have its version hard-coded somewhere in the
|
</ol>
|
||||||
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
</li>
|
||||||
located in the root of the project.</li>
|
<li>Releases
|
||||||
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
<ol>
|
||||||
only contain the exact version string.</li>
|
<li>To create a new release, you MUST create a "version bump" commit directly
|
||||||
<li>The version string SHOULD follow the Semantic Versioning
|
on the master branch which changes the hard-coded version value of the
|
||||||
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
project. The version bump commit MUST have a git tag created on it and
|
||||||
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
named as the exact version string.</li>
|
||||||
is bad, and "2.11.4" is good.</li>
|
<li>A version bump commit MUST have a commit message title of "Bump version
|
||||||
</ol>
|
to VERSION". For example, if the new version string is "2.11.4", the
|
||||||
</li>
|
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
||||||
<li>Releases
|
<li>The release tag on the version bump commit MUST be named exactly the same
|
||||||
<ol>
|
as the version string. The tag name can OPTIONALLY be prefixed with
|
||||||
<li>To create a new release, you MUST create a "version bump" commit directly
|
"v". For example the tag name can be either "2.11.4" or "v2.11.4".</li>
|
||||||
on the master branch which changes the hard-coded version value of the
|
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
||||||
project. The version bump commit MUST have a git tag created on it and
|
OPTIONALLY use annotated tags if you want to include changelog
|
||||||
named as the exact version string.</li>
|
information in the release tag itself.</li>
|
||||||
<li>A version bump commit MUST have a commit message title of "Bump version
|
<li>If you use annotated release tags, the first line of the annotation MUST
|
||||||
to VERSION". For example, if the new version string is "2.11.4", the
|
read "Release VERSION". For example for version "2.11.4" the first line
|
||||||
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
of the tag annotation would read "Release 2.11.4". The second line must
|
||||||
<li>The release tag on the version bump commit MUST be named exactly the same
|
be blank, and the changelog MUST start on the third line.</li>
|
||||||
as the version string. The tag name can OPTIONALLY be prefixed with
|
</ol>
|
||||||
"v". For example the tag name can be either "2.11.4" or "v2.11.4".</li>
|
</li>
|
||||||
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
<li>Bug Fixes & Rollback
|
||||||
OPTIONALLY use annotated tags if you want to include changelog
|
<ol>
|
||||||
information in the release tag itself.</li>
|
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
||||||
<li>If you use annotated release tags, the first line of the annotation MUST
|
<li>If a change branch which has been merged in to the master branch is found
|
||||||
read "Release VERSION". For example for version "2.11.4" the first line
|
to have a bug in it, the bug fix work MUST be done as a new separate
|
||||||
of the tag annotation would read "Release 2.11.4". The second line must
|
change branch and MUST follow the same workflow as any other change
|
||||||
be blank, and the changelog MUST start on the third line.</li>
|
branch.</li>
|
||||||
</ol>
|
<li>If a change branch is wrongfully merged in to master, or for any other
|
||||||
</li>
|
reason the merge must be undone, you MUST undo the merge by reverting the
|
||||||
<li>Bug Fixes & Rollback
|
merge commit itself. Effectively creating a new commit that reverses all
|
||||||
<ol>
|
the relevant changes.</li>
|
||||||
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
</ol>
|
||||||
<li>If a change branch which has been merged in to the master branch is found
|
</li>
|
||||||
to have a bug in it, the bug fix work MUST be done as a new separate
|
<li>Maintenance Releases
|
||||||
change branch and MUST follow the same workflow as any other change
|
<ol>
|
||||||
branch.</li>
|
<li>Any branch that has a name starting with "stable-" SHOULD be referred to
|
||||||
<li>If a change branch is wrongfully merged in to master, or for any other
|
as a "maintenance branch".</li>
|
||||||
reason the merge must be undone, you MUST undo the merge by reverting the
|
<li>Maintenance branches are used for managing new releases of older
|
||||||
merge commit itself. Effectively creating a new commit that reverses all
|
versions. Typically this is used to provide security updates for older
|
||||||
the relevant changes.</li>
|
versions when the master branch has moved on to a point that a new
|
||||||
</ol>
|
release for the old version cannot be made from the master branch.</li>
|
||||||
</li>
|
<li>A "maintenance release" is identical to a regular release, except the
|
||||||
<li>Maintenance Releases
|
version bump commit and the release tag are placed on the maintenance
|
||||||
<ol>
|
branch instead of on the master branch.</li>
|
||||||
<li>Any branch that has a name starting with "stable-" SHOULD be referred to
|
<li>A maintenance branch SHOULD follow a "stable-X.Y" naming pattern, where
|
||||||
as a "maintenance branch".</li>
|
"X" is the MAJOR version and "Y" is the minor version.</li>
|
||||||
<li>Maintenance branches are used for managing new releases of older
|
<li>A maintenance branch MUST be created from the relevant release tag. For
|
||||||
versions. Typically this is used to provide security updates for older
|
example if there is a security fix for all 2.9.x releases, the latest of
|
||||||
versions when the master branch has moved on to a point that a new
|
which is "2.9.7", we create a new branch called "stable-2.9" off of the
|
||||||
release for the old version cannot be made from the master branch.</li>
|
"2.9.7" release tag. The security fix release will then end up being
|
||||||
<li>A "maintenance release" is identical to a regular release, except the
|
version "2.9.8".</li>
|
||||||
version bump commit and the release tag are placed on the maintenance
|
<li>When working on a maintenance release, the relevant maintenance branch
|
||||||
branch instead of on the master branch.</li>
|
MUST be thought of as the master branch for that maintenance work.</li>
|
||||||
<li>A maintenance branch SHOULD follow a "stable-X.Y" naming pattern, where
|
<li>Changes in a maintenance branch SHOULD typically come from work being
|
||||||
"X" is the MAJOR version and "Y" is the minor version.</li>
|
done against the master branch. Meaning changes SHOULD only trickle
|
||||||
<li>A maintenance branch MUST be created from the relevant release tag. For
|
downwards from the master branch. If a change needs to trickle back up
|
||||||
example if there is a security fix for all 2.9.x releases, the latest of
|
into the master branch, that work should have happened against the master
|
||||||
which is "2.9.7", we create a new branch called "stable-2.9" off of the
|
branch in the first place.</li>
|
||||||
"2.9.7" release tag. The security fix release will then end up being
|
</ol>
|
||||||
version "2.9.8".</li>
|
</li>
|
||||||
<li>When working on a maintenance release, the relevant maintenance branch
|
</ol>
|
||||||
MUST be thought of as the master branch for that maintenance work.</li>
|
<h2 id="about">About</h2>
|
||||||
<li>Changes in a maintenance branch SHOULD typically come from work being
|
<p>The Git Common-Flow specification is authored
|
||||||
done against the master branch. Meaning changes SHOULD only trickle
|
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
|
||||||
downwards from the master branch. If a change needs to trickle back up
|
<p>If you'd like to leave feedback,
|
||||||
into the master branch, that work should have happened against the master
|
please <a href="https://github.com/jimeh/common-flow/issues">open an issue on GitHub</a>.</p>
|
||||||
branch in the first place.</li>
|
<h2 id="license">License</h2>
|
||||||
</ol>
|
<p><a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons - CC BY 3.0</a></p>
|
||||||
</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>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
||||||
|
<script>
|
||||||
|
if (window.location.hostname == "commonflow.org") {
|
||||||
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||||
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||||
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||||
|
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
||||||
|
ga('create', 'UA-102330905-1', 'auto');
|
||||||
|
ga('send', 'pageview');
|
||||||
|
} else { _gaq = []; };
|
||||||
|
</script>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
@@ -8,19 +8,19 @@
|
|||||||
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
<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">
|
<link type="text/css" rel="stylesheet" href="/assets/main-082b10f3e2581d4b34b66958419ec52aec823571e474eb04ffdb3b7c4e6f455e.css">
|
||||||
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
||||||
<title>Git Common-Flow 1.0.0-rc.2 | Git Common Flow</title>
|
<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 property="og:title" content="Git Common-Flow 1.0.0-rc.2" />
|
||||||
<meta name="author" content="Jim Myhrberg" />
|
<meta name="author" content="Jim Myhrberg" />
|
||||||
<meta property="og:locale" content="en_US" />
|
<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 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." />
|
<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" />
|
<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:url" content="https://commonflow.org/spec/1.0.0-rc.2.html" />
|
||||||
<meta property="og:site_name" content="Git Common Flow" />
|
<meta property="og:site_name" content="Git Common Flow" />
|
||||||
<script type="application/ld+json">
|
<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>
|
{"@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"}
|
||||||
<!-- End Jekyll SEO tag -->
|
</script>
|
||||||
|
<!-- End Jekyll SEO tag -->
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<div id="layout">
|
<div id="layout">
|
||||||
@@ -33,270 +33,248 @@
|
|||||||
<li class="pure-menu-item">
|
<li class="pure-menu-item">
|
||||||
<div class="pure-menu-label">Versions:</div>
|
<div class="pure-menu-label">Versions:</div>
|
||||||
</li>
|
</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>
|
||||||
<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>
|
</ul>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div id="main">
|
<div id="main">
|
||||||
<div class="content">
|
<div class="content">
|
||||||
<h1 id="git-common-flow-100-rc2">Git Common-Flow 1.0.0-rc.2</h1>
|
<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>
|
||||||
<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
|
||||||
<h2 id="summary">Summary</h2>
|
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>
|
||||||
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
||||||
usage patterns of git into a single and concise specification. It is based on
|
into account how a lot of open source projects use git.</p>
|
||||||
the <a href="http://scottchacon.com/2011/08/31/github-flow.html">original variant</a>
|
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
||||||
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
releases, maintenance releases for old versions, and without the requirement to
|
||||||
into account how a lot of open source projects use git.</p>
|
deploy to production all the time.</p>
|
||||||
|
<h2 id="terminology">Terminology</h2>
|
||||||
<p>TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned
|
<ul>
|
||||||
releases, maintenance releases for old versions, and without the requirement to
|
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
||||||
deploy to production all the time.</p>
|
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
|
||||||
<h2 id="terminology">Terminology</h2>
|
bug fix, etc.</li>
|
||||||
|
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
||||||
<ul>
|
changes in the source branch should be incorporated into the change branch via
|
||||||
<li><strong>Master Branch</strong> - Must always have passing tests, is considered bleeding
|
rebasing.</li>
|
||||||
edge, and must be named <code class="highlighter-rouge">master</code>.</li>
|
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
||||||
<li><strong>Change Branches</strong> - Any branch that introduces changes like a new feature, a
|
branch. Typically the merge target branch will be the same as the source
|
||||||
bug fix, etc.</li>
|
branch.</li>
|
||||||
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
||||||
changes in the source branch should be incorporated into the change branch via
|
its merge target, allowing others to review, discuss and approve the changes.</li>
|
||||||
rebasing.</li>
|
<li><strong>Release</strong> - Consists of a version bump commit, and a git tag named according
|
||||||
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
to the new version string placed on said commit.</li>
|
||||||
branch. Typically the merge target branch will be the same as the source
|
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
||||||
branch.</li>
|
also for long-term maintenance of older version.</li>
|
||||||
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
</ul>
|
||||||
its merge target, allowing others to review, discuss and approve the changes.</li>
|
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
||||||
<li><strong>Release</strong> - Consists of a version bump commit, and a git tag named according
|
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
||||||
to the new version string placed on said commit.</li>
|
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
||||||
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
||||||
also for long-term maintenance of older version.</li>
|
<ol>
|
||||||
</ul>
|
<li>The Master Branch
|
||||||
|
<ol>
|
||||||
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
||||||
|
"master branch".</li>
|
||||||
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
<li>The master branch MUST be considered bleeding edge.</li>
|
||||||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
<li>The master branch MUST always be in a non-broken state with its test
|
||||||
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
suite passing.</li>
|
||||||
|
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
||||||
<ol>
|
release/production" state to reduce any friction with creating a new
|
||||||
<li>The Master Branch
|
release.</li>
|
||||||
<ol>
|
</ol>
|
||||||
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
</li>
|
||||||
"master branch".</li>
|
<li>Change Branches
|
||||||
<li>The master branch MUST be considered bleeding edge.</li>
|
<ol>
|
||||||
<li>The master branch MUST always be in a non-broken state with its test
|
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
||||||
suite passing.</li>
|
branches that SHOULD be referred to as "change branches". All change
|
||||||
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
branches MUST have descriptive names. It is RECOMMENDED that you commit
|
||||||
release/production" state to reduce any friction with creating a new
|
often locally, and you SHOULD regularly push your work to the same named
|
||||||
release.</li>
|
branch on the remote server.</li>
|
||||||
</ol>
|
<li>You MUST create separate change branches for each distinctly different
|
||||||
</li>
|
change. You MUST NOT include multiple unrelated changes into a single
|
||||||
<li>Change Branches
|
change branch.</li>
|
||||||
<ol>
|
<li>When a change branch is created, the branch that it is created from
|
||||||
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
SHOULD be referred to as the "source branch". Each change branch also
|
||||||
branches that SHOULD be referred to as "change branches". All change
|
needs a designated "merge target" branch, typically this will be the same
|
||||||
branches MUST have descriptive names. It is RECOMMENDED that you commit
|
as the source branch.</li>
|
||||||
often locally, and you SHOULD regularly push your work to the same named
|
<li>Change branches MUST be regularly updated with any changes from their
|
||||||
branch on the remote server.</li>
|
source branch. This MUST be done by rebasing the change branch on top of
|
||||||
<li>You MUST create separate change branches for each distinctly different
|
the source branch.</li>
|
||||||
change. You MUST NOT include multiple unrelated changes into a single
|
<li>After rebasing a change branch on top of its source branch you MUST push
|
||||||
change branch.</li>
|
the change branch to the remote server. This will require you to do a
|
||||||
<li>When a change branch is created, the branch that it is created from
|
force push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
||||||
SHOULD be referred to as the "source branch". Each change branch also
|
</ol>
|
||||||
needs a designated "merge target" branch, typically this will be the same
|
</li>
|
||||||
as the source branch.</li>
|
<li>Pull Requests
|
||||||
<li>Change branches MUST be regularly updated with any changes from their
|
<ol>
|
||||||
source branch. This MUST be done by rebasing the change branch on top of
|
<li>To merge a change branch into its merge target, you MUST open a "pull
|
||||||
the source branch.</li>
|
request" (or equivalent) so others can review and approve your changes.</li>
|
||||||
<li>After rebasing a change branch on top of its source branch you MUST push
|
<li>A pull request MUST only be merged when the change branch is up-to-date
|
||||||
the change branch to the remote server. This will require you to do a
|
with its source branch, the test suite is passing, and you and others are
|
||||||
force push, and you SHOULD use the "--force-with-lease" git push option.</li>
|
happy with the change. This is especially important if the merge target
|
||||||
</ol>
|
is the master branch.</li>
|
||||||
</li>
|
<li>To get feedback, help, or generally just discuss a change branch with
|
||||||
<li>Pull Requests
|
others, the RECOMMENDED way to do so is by creating a pull request and
|
||||||
<ol>
|
discuss the changes with others there.</li>
|
||||||
<li>To merge a change branch into its merge target, you MUST open a "pull
|
</ol>
|
||||||
request" (or equivalent) so others can review and approve your changes.</li>
|
</li>
|
||||||
<li>A pull request MUST only be merged when the change branch is up-to-date
|
<li>Versioning
|
||||||
with its source branch, the test suite is passing, and you and others are
|
<ol>
|
||||||
happy with the change. This is especially important if the merge target
|
<li>The project MUST have its version hard-coded somewhere in the
|
||||||
is the master branch.</li>
|
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
||||||
<li>To get feedback, help, or generally just discuss a change branch with
|
located in the root of the project.</li>
|
||||||
others, the RECOMMENDED way to do so is by creating a pull request and
|
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
||||||
discuss the changes with others there.</li>
|
only contain the exact version string.</li>
|
||||||
</ol>
|
<li>The version string SHOULD follow the Semantic Versioning
|
||||||
</li>
|
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
||||||
<li>Versioning
|
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
||||||
<ol>
|
is bad, and "2.11.4" is good.</li>
|
||||||
<li>The project MUST have its version hard-coded somewhere in the
|
</ol>
|
||||||
code-base. It is RECOMMENDED that this is done in a file called "VERSION"
|
</li>
|
||||||
located in the root of the project.</li>
|
<li>Releases
|
||||||
<li>If you are using a "VERSION" file in the root of the project, this MUST
|
<ol>
|
||||||
only contain the exact version string.</li>
|
<li>To create a new release, you MUST create a "version bump" commit which
|
||||||
<li>The version string SHOULD follow the Semantic Versioning
|
changes the hard-coded version string of the project. The version bump
|
||||||
(<a href="http://semver.org/">http://semver.org/</a>) format. Use of Semantic Versioning is OPTIONAL,
|
commit MUST have a git tag created on it and named as the exact version
|
||||||
but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
|
string.</li>
|
||||||
is bad, and "2.11.4" is good.</li>
|
<li>If you are not using a release branch, then the version bump commit MUST
|
||||||
</ol>
|
be created directly on the master branch.</li>
|
||||||
</li>
|
<li>The version bump commit MUST have a commit message title of "Bump version
|
||||||
<li>Releases
|
to VERSION". For example, if the new version string is "2.11.4", the
|
||||||
<ol>
|
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
||||||
<li>To create a new release, you MUST create a "version bump" commit which
|
<li>The release tag on the version bump commit MUST be named exactly the same
|
||||||
changes the hard-coded version string of the project. The version bump
|
as the version string. The tag name can OPTIONALLY be prefixed with
|
||||||
commit MUST have a git tag created on it and named as the exact version
|
"v". For example the tag name can be either "2.11.4" or "v2.11.4". You
|
||||||
string.</li>
|
MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form
|
||||||
<li>If you are not using a release branch, then the version bump commit MUST
|
and stick to it.</li>
|
||||||
be created directly on the master branch.</li>
|
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
||||||
<li>The version bump commit MUST have a commit message title of "Bump version
|
OPTIONALLY use annotated tags if you want to include changelog
|
||||||
to VERSION". For example, if the new version string is "2.11.4", the
|
information in the release tag itself.</li>
|
||||||
first line of the commit message MUST read: "Bump version to 2.11.4"</li>
|
<li>If you use annotated release tags, the first line of the annotation MUST
|
||||||
<li>The release tag on the version bump commit MUST be named exactly the same
|
read "Release VERSION". For example for version "2.11.4" the first line
|
||||||
as the version string. The tag name can OPTIONALLY be prefixed with
|
of the tag annotation would read "Release 2.11.4". The second line must
|
||||||
"v". For example the tag name can be either "2.11.4" or "v2.11.4". You
|
be blank, and the changelog MUST start on the third line.</li>
|
||||||
MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form
|
</ol>
|
||||||
and stick to it.</li>
|
</li>
|
||||||
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
<li>Release Branches
|
||||||
OPTIONALLY use annotated tags if you want to include changelog
|
<ol>
|
||||||
information in the release tag itself.</li>
|
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
||||||
<li>If you use annotated release tags, the first line of the annotation MUST
|
as a "release branch".</li>
|
||||||
read "Release VERSION". For example for version "2.11.4" the first line
|
<li>Use of release branches is OPTIONAL.</li>
|
||||||
of the tag annotation would read "Release 2.11.4". The second line must
|
<li>Changes in a release branch SHOULD typically come from work being
|
||||||
be blank, and the changelog MUST start on the third line.</li>
|
done against the master branch. Meaning changes SHOULD only trickle
|
||||||
</ol>
|
downwards from the master branch. If a change needs to trickle back up
|
||||||
</li>
|
into the master branch, that work should have happened against the master
|
||||||
<li>Release Branches
|
branch in the first place. One exception to this is version bump commits.</li>
|
||||||
<ol>
|
<li>There are two types of release branches; short-term, and long-term.</li>
|
||||||
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
<li>Short-Term Release Branches
|
||||||
as a "release branch".</li>
|
<ol>
|
||||||
<li>Use of release branches is OPTIONAL.</li>
|
<li>Used for creating a specific versioned release.</li>
|
||||||
<li>Changes in a release branch SHOULD typically come from work being
|
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
||||||
done against the master branch. Meaning changes SHOULD only trickle
|
pre-release verification process to avoid a code freeze on the master
|
||||||
downwards from the master branch. If a change needs to trickle back up
|
branch.</li>
|
||||||
into the master branch, that work should have happened against the master
|
<li>MUST have a name of "release-VERSION". For example for version
|
||||||
branch in the first place. One exception to this is version bump commits.</li>
|
"2.11.4" the release branch name MUST be "release-2.11.4".</li>
|
||||||
<li>There are two types of release branches; short-term, and long-term.</li>
|
<li>When using a short-term release branch, the version bump commit and
|
||||||
<li>Short-Term Release Branches
|
release tag MUST be made directly on the release branch itself.</li>
|
||||||
<ol>
|
<li>Only very minor changes should be performed on a short-term release
|
||||||
<li>Used for creating a specific versioned release.</li>
|
branch directly. Any larger changes SHOULD be done in the master
|
||||||
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
branch, and SHOULD be pulled into the release branch by rebasing it
|
||||||
pre-release verification process to avoid a code freeze on the master
|
on top of the master branch the same way a change branch pulls in
|
||||||
branch.</li>
|
updates from its source branch.</li>
|
||||||
<li>MUST have a name of "release-VERSION". For example for version
|
<li>After the version bump commit and release tag have been created, the
|
||||||
"2.11.4" the release branch name MUST be "release-2.11.4".</li>
|
release branch MUST be merged back into its source branch and then
|
||||||
<li>When using a short-term release branch, the version bump commit and
|
deleted. Typically the source branch will be the master branch.</li>
|
||||||
release tag MUST be made directly on the release branch itself.</li>
|
</ol>
|
||||||
<li>Only very minor changes should be performed on a short-term release
|
</li>
|
||||||
branch directly. Any larger changes SHOULD be done in the master
|
<li>Long-Term Release Branches
|
||||||
branch, and SHOULD be pulled into the release branch by rebasing it
|
<ol>
|
||||||
on top of the master branch the same way a change branch pulls in
|
<li>Used for work on versions which are not currently part of the master
|
||||||
updates from its source branch.</li>
|
branch. Typically this is useful when you need to create a new
|
||||||
<li>After the version bump commit and release tag have been created, the
|
maintenance release for a older version.</li>
|
||||||
release branch MUST be merged back into its source branch and then
|
<li>The branch name MUST have a non-specific version number. For example
|
||||||
deleted. Typically the source branch will be the master branch.</li>
|
a long-term release branch for creating new 2.9.x releases would be
|
||||||
</ol>
|
named "release-2.9".</li>
|
||||||
</li>
|
<li>To create a new release from a long-term release branch, you MUST
|
||||||
<li>Long-Term Release Branches
|
create a version bump commit and release tag directly on the release
|
||||||
<ol>
|
branch.</li>
|
||||||
<li>Used for work on versions which are not currently part of the master
|
<li>A long-term release branch MUST be created from the relevant release
|
||||||
branch. Typically this is useful when you need to create a new
|
tag. For example if the master branch is on version 2.11.4 and there
|
||||||
maintenance release for a older version.</li>
|
is a security fix for all 2.9.x releases, the latest of which is
|
||||||
<li>The branch name MUST have a non-specific version number. For example
|
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7"
|
||||||
a long-term release branch for creating new 2.9.x releases would be
|
release tag. The security fix release will then end up being version
|
||||||
named "release-2.9".</li>
|
"2.9.8".</li>
|
||||||
<li>To create a new release from a long-term release branch, you MUST
|
</ol>
|
||||||
create a version bump commit and release tag directly on the release
|
</li>
|
||||||
branch.</li>
|
</ol>
|
||||||
<li>A long-term release branch MUST be created from the relevant release
|
</li>
|
||||||
tag. For example if the master branch is on version 2.11.4 and there
|
<li>Bug Fixes & Rollback
|
||||||
is a security fix for all 2.9.x releases, the latest of which is
|
<ol>
|
||||||
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7"
|
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
||||||
release tag. The security fix release will then end up being version
|
<li>If a change branch which has been merged into the master branch is found
|
||||||
"2.9.8".</li>
|
to have a bug in it, the bug fix work MUST be done as a new separate
|
||||||
</ol>
|
change branch and MUST follow the same workflow as any other change
|
||||||
</li>
|
branch.</li>
|
||||||
</ol>
|
<li>If a change branch is wrongfully merged into master, or for any other
|
||||||
</li>
|
reason the merge must be undone, you MUST undo the merge by reverting the
|
||||||
<li>Bug Fixes & Rollback
|
merge commit itself. Effectively creating a new commit that reverses all
|
||||||
<ol>
|
the relevant changes.</li>
|
||||||
<li>You MUST NOT under any circumstances force push to the master branch.</li>
|
</ol>
|
||||||
<li>If a change branch which has been merged into the master branch is found
|
</li>
|
||||||
to have a bug in it, the bug fix work MUST be done as a new separate
|
<li>Git Best Practices
|
||||||
change branch and MUST follow the same workflow as any other change
|
<ol>
|
||||||
branch.</li>
|
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
||||||
<li>If a change branch is wrongfully merged into master, or for any other
|
the official git
|
||||||
reason the merge must be undone, you MUST undo the merge by reverting the
|
documentation:
|
||||||
merge commit itself. Effectively creating a new commit that reverses all
|
<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>
|
||||||
the relevant changes.</li>
|
<li>You SHOULD never blindly commit all changes with "git commit -a". It is
|
||||||
</ol>
|
RECOMMENDED you use "git add -i" to add individual changes to the staging
|
||||||
</li>
|
area so you are fully aware of what you are committing.</li>
|
||||||
<li>Git Best Practices
|
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
||||||
<ol>
|
regular "--force" option is dangerous and destructive. More
|
||||||
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
information:
|
||||||
the official git
|
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
||||||
documentation:
|
<li>You SHOULD understand and be comfortable with
|
||||||
<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>
|
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>You SHOULD never blindly commit all changes with "git commit -a". It is
|
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
||||||
RECOMMENDED you use "git add -i" to add individual changes to the staging
|
pull" to avoid unnecessary merge commits. You can make this the default
|
||||||
area so you are fully aware of what you are committing.</li>
|
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
||||||
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
||||||
regular "--force" option is dangerous and destructive. More
|
This makes sure the reference to the original branch is kept in the
|
||||||
information:
|
commits, allows one to revert a merge by reverting a single merge commit,
|
||||||
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
and creates a merge commit to mark the integration of the branch with
|
||||||
<li>You SHOULD understand and be comfortable with
|
master.</li>
|
||||||
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>
|
</ol>
|
||||||
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
</li>
|
||||||
pull" to avoid unnecessary merge commits. You can make this the default
|
</ol>
|
||||||
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
<h2 id="about">About</h2>
|
||||||
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
<p>The Git Common-Flow specification is authored
|
||||||
This makes sure the reference to the original branch is kept in the
|
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
|
||||||
commits, allows one to revert a merge by reverting a single merge commit,
|
<p>If you'd like to leave feedback,
|
||||||
and creates a merge commit to mark the integration of the branch with
|
please <a href="https://github.com/jimeh/common-flow/issues">open an issue on GitHub</a>.</p>
|
||||||
master.</li>
|
<h2 id="license">License</h2>
|
||||||
</ol>
|
<p><a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons - CC BY 3.0</a></p>
|
||||||
</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>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
||||||
|
<script>
|
||||||
|
if (window.location.hostname == "commonflow.org") {
|
||||||
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||||
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||||
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||||
|
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
||||||
|
ga('create', 'UA-102330905-1', 'auto');
|
||||||
|
ga('send', 'pageview');
|
||||||
|
} else { _gaq = []; };
|
||||||
|
</script>
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
Reference in New Issue
Block a user