mirror of
https://github.com/jimeh/commonflow.org.git
synced 2026-02-19 05:46:40 +00:00
403 lines
27 KiB
HTML
403 lines
27 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link href='https://fonts.googleapis.com/css?family=Open+Sans+Condensed:700,300|Open+Sans:400italic,700italic,400,700' rel='stylesheet' type='text/css'>
|
|
<link rel="stylesheet" href="https://unpkg.com/purecss@1.0.0/build/pure-min.css" integrity="sha384-nn4HPE8lTHyVtfCBi5yW9d20FjT8BJwUXyWZT9InLYax14RDjBj46LmSztkmNP9w" crossorigin="anonymous">
|
|
<link rel="stylesheet" href="https:////maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
|
|
<link type="text/css" rel="stylesheet" href="/assets/main-c6d2e6591d58bffada09ccc7f6d4f28960908c6bdb6192e726de2a896036b150.css">
|
|
<!-- Begin Jekyll SEO tag v2.2.3 -->
|
|
<title>Git Common-Flow 1.0.0-rc.4 | Git Common Flow</title>
|
|
<meta property="og:title" content="Git Common-Flow 1.0.0-rc.4" />
|
|
<meta name="author" content="Jim Myhrberg" />
|
|
<meta property="og:locale" content="en_US" />
|
|
<meta name="description" content="An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification." />
|
|
<meta property="og:description" content="An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification." />
|
|
<link rel="canonical" href="https://commonflow.org/spec/1.0.0-rc.4.html" />
|
|
<meta property="og:url" content="https://commonflow.org/spec/1.0.0-rc.4.html" />
|
|
<meta property="og:site_name" content="Git Common Flow" />
|
|
<script type="application/ld+json">
|
|
{"@context":"http://schema.org","@type":"WebPage","headline":"Git Common-Flow 1.0.0-rc.4","author":{"@type":"Person","name":"Jim Myhrberg"},"description":"An attempt to gather a sensible selection of the most common usage patterns of git into a single and concise specification.","url":"https://commonflow.org/spec/1.0.0-rc.4.html"}
|
|
</script>
|
|
<!-- End Jekyll SEO tag -->
|
|
</head>
|
|
<body>
|
|
<div id="layout">
|
|
<a href="#menu" id="menuLink" class="menu-link">
|
|
<span></span>
|
|
</a>
|
|
<div id="menu">
|
|
<div class="pure-menu">
|
|
<ul class="pure-menu-list">
|
|
<li class="pure-menu-item">
|
|
<div class="pure-menu-label">Versions:</div>
|
|
</li>
|
|
<li class="pure-menu-item version-1.0.0-rc.4 pure-menu-selected">
|
|
<a href="/spec/1.0.0-rc.4.html" class="pure-menu-link">1.0.0-rc.4</a>
|
|
</li>
|
|
<li class="pure-menu-item version-1.0.0-rc.3">
|
|
<a href="/spec/1.0.0-rc.3.html" class="pure-menu-link">1.0.0-rc.3</a>
|
|
</li>
|
|
<li class="pure-menu-item version-1.0.0-rc.2">
|
|
<a href="/spec/1.0.0-rc.2.html" class="pure-menu-link">1.0.0-rc.2</a>
|
|
</li>
|
|
<li class="pure-menu-item version-1.0.0-rc.1">
|
|
<a href="/spec/1.0.0-rc.1.html" class="pure-menu-link">1.0.0-rc.1</a>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="links">
|
|
<a href="https://github.com/jimeh/common-flow">
|
|
<i class="fa fa-github" aria-hidden="true"></i>
|
|
</a>
|
|
</div>
|
|
</div>
|
|
<div id="main">
|
|
<div class="content">
|
|
<h1 id="git-common-flow-100-rc4">Git Common-Flow 1.0.0-rc.4</h1>
|
|
<p><img src="/spec/1.0.0-rc.4.svg" width="100%" /></p>
|
|
<h2 id="summary">Summary</h2>
|
|
<p>Common-Flow is an attempt to gather a sensible selection of the most common
|
|
usage patterns of git into a single and concise specification. It is based on
|
|
the <a href="http://scottchacon.com/2011/08/31/github-flow.html">original variant</a>
|
|
of <a href="https://guides.github.com/introduction/flow/">GitHub Flow</a>, while taking
|
|
into account how a lot of open source projects use git.</p>
|
|
<p>In short, Common-Flow is essentially GitHub Flow with the addition of versioned
|
|
releases, optional release branches, and without the requirement to deploy to
|
|
production all the time.</p>
|
|
<h2 id="terminology">Terminology</h2>
|
|
<ul>
|
|
<li><strong>Master Branch</strong> - Must be named "master", must always have passing tests,
|
|
and is not guaranteed to always work in production environments.</li>
|
|
<li><strong>Change Branches</strong> - Any branch that introduces changes like a new feature, a
|
|
bug fix, etc.</li>
|
|
<li><strong>Source Branch</strong> - The branch that a change branch was created from. New
|
|
changes in the source branch should be incorporated into the change branch via
|
|
rebasing.</li>
|
|
<li><strong>Merge Target</strong> - A branch that is the intended merge target for a change
|
|
branch. Typically the merge target branch will be the same as the source
|
|
branch.</li>
|
|
<li><strong>Pull Request</strong> - A means of requesting that a change branch is merged in to
|
|
its merge target, allowing others to review, discuss and approve the changes.</li>
|
|
<li><strong>Release</strong> - May be considered safe to use in production environments. Is
|
|
effectively just a git tag named after the version of the release.</li>
|
|
<li><strong>Release Branches</strong> - Used both for short-term preparations of a release, and
|
|
also for long-term maintenance of older version.</li>
|
|
</ul>
|
|
<h2 id="git-common-flow-specification-common-flow">Git Common-Flow Specification (Common-Flow)</h2>
|
|
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
|
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
|
|
interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>.</p>
|
|
<ol>
|
|
<li>TL;DR
|
|
<ol>
|
|
<li>Don't break the master branch.</li>
|
|
<li>A release is a git tag.</li>
|
|
</ol>
|
|
</li>
|
|
<li>The Master Branch
|
|
<ol>
|
|
<li>A branch named "master" MUST exist and it MUST be referred to as the
|
|
"master branch".</li>
|
|
<li>The master branch MUST always be in a non-broken state with its test
|
|
suite passing.</li>
|
|
<li>The master branch IS NOT guaranteed to always work in production
|
|
environments. Despite test suites passing it may at times contain
|
|
unfinished work. Only releases may be considered safe for production use.</li>
|
|
<li>The master branch SHOULD always be in a "as near as possibly ready for
|
|
release/production" state to reduce any friction with creating a new
|
|
release.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Change Branches
|
|
<ol>
|
|
<li>Each change (feature, bugfix, etc.) MUST be performed on separate
|
|
branches that SHOULD be referred to as "change branches".</li>
|
|
<li>All change branches MUST have descriptive names.</li>
|
|
<li>It is RECOMMENDED that you commit often locally, and that you try and
|
|
keep the commits reasonably structured to avoid a messy and confusing git
|
|
history.</li>
|
|
<li>You SHOULD regularly push your work to the same named branch on the
|
|
remote server.</li>
|
|
<li>You SHOULD create separate change branches for each distinctly different
|
|
change. You SHOULD NOT include multiple unrelated changes into a single
|
|
change branch.</li>
|
|
<li>When a change branch is created, the branch that it is created from
|
|
SHOULD be referred to as the "source branch". Each change branch also
|
|
needs a designated "merge target" branch, typically this will be the same
|
|
as the source branch.</li>
|
|
<li>Change branches MUST be regularly updated with any changes from their
|
|
source branch. This MUST be done by rebasing the change branch on top of
|
|
the source branch.</li>
|
|
<li>After updating a change branch from its source branch you MUST push the
|
|
change branch to the remote server. Due to the nature of rebasing, you
|
|
will be required to do a force push, and you MUST use the
|
|
"--force-with-lease" git push option when doing so instead of the regular
|
|
"--force".</li>
|
|
<li>If there is a truly valid technical reason to not use rebase when
|
|
updating change branches, then you can update change branches via merge
|
|
instead of rebase. The decision to use merge MUST only be taken after all
|
|
possible options to use rebase have been tried and failed. People not
|
|
understanding how to use rebase is NOT a valid reason to use merge. If
|
|
you do decide to use merge instead of rebase, you MUST NOT use a mixture
|
|
of both methods, pick one and stick to it.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Pull Requests
|
|
<ol>
|
|
<li>To merge a change branch into its merge target, you MUST open a "pull
|
|
request" (or equivalent).</li>
|
|
<li>The purpose of a pull request is to allow others to review your changes
|
|
and give feedback. You can then fix any issues, complaints, and more that
|
|
might arise, and then let people review again.</li>
|
|
<li>Before creating a pull request, it is RECOMMENDED that you consider the
|
|
state of your change branch's commit history. If it is messy and
|
|
confusing, it might be a good idea to rebase your branch with "git rebase
|
|
-i" to present a cleaner and easier to follow commit history for your
|
|
reviewers.</li>
|
|
<li>A pull request MUST only be merged when the change branch is up-to-date
|
|
with its source branch, the test suite is passing, and you and others are
|
|
happy with the change. This is especially important if the merge target
|
|
is the master branch.</li>
|
|
<li>To get feedback, help, or generally just discuss a change branch with
|
|
others, the RECOMMENDED way to do so is by creating a pull request and
|
|
discuss the changes with others there.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Versioning
|
|
<ol>
|
|
<li>A "version string" is a typically mostly numeric string that identifies a
|
|
specific version of a project. The version string itself MUST NOT have a
|
|
"v" prefix, but the version string can be displayed with a "v" prefix to
|
|
indicate it is a version that is being referred to.</li>
|
|
<li>The source of truth for a project's version MUST be a git tag with a name
|
|
based on the version string. This kind of tag MUST be referred to as a
|
|
"release tag".</li>
|
|
<li>It is OPTIONAL, but RECOMMENDED to also keep the version string
|
|
hard-coded somewhere in the project code-base.</li>
|
|
<li>If you hard-code the version string into the code-base, it is RECOMMENDED
|
|
that you do so in a file called "VERSION" located in the root of the
|
|
project. But be mindful of the conventions of your programming language
|
|
and community when choosing if, where and how to hard-code the version
|
|
string.</li>
|
|
<li>If you are using a "VERSION" file in the root of the project, this file
|
|
MUST only contain the exact version string, meaning it MUST NOT have a
|
|
"v" prefix. For example "v2.11.4" is bad, and "2.11.4" is good.</li>
|
|
<li>It is OPTIONAL, but RECOMMENDED that that the version string follows
|
|
Semantic Versioning (<a href="http://semver.org/">http://semver.org/</a>).</li>
|
|
</ol>
|
|
</li>
|
|
<li>Releases
|
|
<ol>
|
|
<li>To create a new release, you MUST create a git tag named as the exact
|
|
version string of the release. This kind of tag MUST be referred to as a
|
|
"release tag".</li>
|
|
<li>The release tag name can OPTIONALLY be prefixed with "v". For example the
|
|
tag name can be either "2.11.4" or "v2.11.4". It is however RECOMMENDED
|
|
that you do not use a "v" prefix. You MUST NOT use a mixture of "v"
|
|
prefixed and non-prefixed tags. Pick one form and stick to it.</li>
|
|
<li>If the version string is hard-coded into the code-base, you MUST create a
|
|
"version bump" commit which changes the hard-coded version string of the
|
|
project.</li>
|
|
<li>When using version bump commits, the release tag MUST be placed on the
|
|
version bump commit.</li>
|
|
<li>If you are not using a release branch, then the release tag, and if
|
|
relevant the version bump commit, MUST be created directly on the master
|
|
branch.</li>
|
|
<li>The version bump commit SHOULD have a commit message title of "Bump
|
|
version to VERSION". For example, if the new version string is "2.11.4",
|
|
the first line of the commit message SHOULD read: "Bump version to
|
|
2.11.4"</li>
|
|
<li>It is RECOMMENDED that release tags are lightweight tags, but you can
|
|
OPTIONALLY use annotated tags if you want to include changelog
|
|
information in the release tag itself.</li>
|
|
<li>If you use annotated release tags, the first line of the annotation
|
|
SHOULD read "Release VERSION". For example for version "2.11.4" the first
|
|
line of the tag annotation SHOULD read "Release 2.11.4". The second line
|
|
MUST be blank, and the changelog MUST start on the third line.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Short-Term Release Branches
|
|
<ol>
|
|
<li>Any branch that has a name starting with "release-" SHOULD be referred to
|
|
as a "release branch".</li>
|
|
<li>Any release branch which has a name ending with a specific version
|
|
string, MUST be referred to as a "short-term release branch".</li>
|
|
<li>Use of short-term release branches are OPTIONAL, and intended to be used
|
|
to create a specific versioned release.</li>
|
|
<li>A short-term release branch is RECOMMENDED if there is a lengthy
|
|
pre-release verification process to avoid a code freeze on the master
|
|
branch.</li>
|
|
<li>Short-term release branches MUST have a name of "release-VERSION". For
|
|
example for version "2.11.4" the release branch name MUST be
|
|
"release-2.11.4".</li>
|
|
<li>When using a short-term release branch to create a release, the release
|
|
tag and if used, version bump commit, MUST be placed directly on the
|
|
short-term release branch itself.</li>
|
|
<li>Only very minor changes should be performed on a short-term release
|
|
branch directly. Any larger changes SHOULD be done in the master branch,
|
|
and SHOULD be pulled into the release branch by rebasing it on top of the
|
|
master branch the same way a change branch pulls in updates from its
|
|
source branch.</li>
|
|
<li>After a release tag has been created, the release branch MUST be merged
|
|
back into its source branch and then deleted. Typically the source branch
|
|
will be the master branch.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Long-term Release Branches
|
|
<ol>
|
|
<li>Any release branch which has a name ending with a non-specific version
|
|
string, MUST be referred to as a "long-term release branch". For example
|
|
"release-2.11" is a long-term release branch, while "release-2.11.4" is a
|
|
short-term release branch.</li>
|
|
<li>Use of long-term release branches are OPTIONAL, and intended for work on
|
|
versions which are not currently part of the master branch. Typically
|
|
this is useful when you need to create a new maintenance release for a
|
|
older version.</li>
|
|
<li>A long-term release branch MUST have a name with a non-specific version
|
|
number. For example a long-term release branch for creating new 2.9.x
|
|
releases MUST be named "release-2.9".</li>
|
|
<li>Long-term release branches for maintenance releases of older versions
|
|
MUST be created from the relevant release tag. For example if the master
|
|
branch is on version 2.11.4 and there is a security fix for all 2.9.x
|
|
releases, the latest of which is "2.9.7". Create a new branch called
|
|
"release-2.9" off of the "2.9.7" release tag. The security fix release
|
|
will then end up being version "2.9.8".</li>
|
|
<li>To create a new release from a long-term release branch, you MUST follow
|
|
the same process as a release from the master branch, except the
|
|
long-term release branch takes the place of the master branch.</li>
|
|
<li>A long-term release branch should be treated with the same respect as the
|
|
master branch. It is effectively the master branch for the release series
|
|
in question. Meaning it MUST always be in a non-broken state, MUST NOT be
|
|
force pushed to, etc.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Bug Fixes & Rollback
|
|
<ol>
|
|
<li>You MUST NOT under any circumstances force push to the master branch or
|
|
to long-term release branches.</li>
|
|
<li>If a change branch which has been merged into the master branch is found
|
|
to have a bug in it, the bug fix work MUST be done as a new separate
|
|
change branch and MUST follow the same workflow as any other change
|
|
branch.</li>
|
|
<li>If a change branch is wrongfully merged into master, or for any other
|
|
reason the merge must be undone, you MUST undo the merge by reverting the
|
|
merge commit itself. Effectively creating a new commit that reverses all
|
|
the relevant changes.</li>
|
|
</ol>
|
|
</li>
|
|
<li>Git Best Practices
|
|
<ol>
|
|
<li>All commit messages SHOULD follow the Commit Guidelines and format from
|
|
the official git
|
|
documentation:
|
|
<a href="https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines">https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines</a></li>
|
|
<li>You SHOULD never blindly commit all changes with "git commit -a". It is
|
|
RECOMMENDED you use "git add -i" or "git add -p" to add individual
|
|
changes to the staging area so you are fully aware of what you are
|
|
committing.</li>
|
|
<li>You SHOULD always use "--force-with-lease" when doing a force push. The
|
|
regular "--force" option is dangerous and destructive. More
|
|
information:
|
|
<a href="https://developer.atlassian.com/blog/2015/04/force-with-lease/">https://developer.atlassian.com/blog/2015/04/force-with-lease/</a></li>
|
|
<li>You SHOULD understand and be comfortable with
|
|
rebasing: <a href="https://git-scm.com/book/en/v2/Git-Branching-Rebasing">https://git-scm.com/book/en/v2/Git-Branching-Rebasing</a></li>
|
|
<li>It is RECOMMENDED that you always do "git pull --rebase" instead of "git
|
|
pull" to avoid unnecessary merge commits. You can make this the default
|
|
behavior of "git pull" with "git config --global pull.rebase true".</li>
|
|
<li>It is RECOMMENDED that all branches be merged using "git merge --no-ff".
|
|
This makes sure the reference to the original branch is kept in the
|
|
commits, allows one to revert a merge by reverting a single merge commit,
|
|
and creates a merge commit to mark the integration of the branch with
|
|
master.</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
<h2 id="faq">FAQ</h2>
|
|
<h3 id="why-use-common-flow-instead-of-git-flow-and-how-does-it-differ">Why use Common-Flow instead of Git Flow, and how does it differ?</h3>
|
|
<p>Common-Flow tries to be a lot less complicated than Git Flow by having fewer
|
|
types of branches, and simpler rules. Normal day to day development doesn't
|
|
really change much:</p>
|
|
<ul>
|
|
<li>You create change branches instead of feature branches, without the need of a
|
|
"feature/" or "change/" prefix in the branch name.</li>
|
|
<li>Change branches are typically created off of and merged back into "master"
|
|
instead of "develop".</li>
|
|
<li>Creating a release is done by simply creating a git tag, typically on the
|
|
master branch.</li>
|
|
</ul>
|
|
<p>In detail, the main differences between Git Flow and Common-Flow are:</p>
|
|
<ul>
|
|
<li>There is no "develop" branch, there is only a "master" branch which contains
|
|
the latest work. In Git Flow the master branch effectively ends up just being
|
|
a pointer to the latest release, despite the fact that Git Flow includes
|
|
release tags too. In Common-Flow you just look at the tags to find the latest
|
|
release.</li>
|
|
<li>There are no "feature" or "hotfix" branches, there's only "change"
|
|
branches. Any branch that is not master and introduces changes is a change
|
|
branch. Change branches also don't have a enforced naming convention, they
|
|
just have to have a "descriptive name". This makes things simpler and allows
|
|
more flexibility.</li>
|
|
<li>Release branches are available, but optional. Instead of enforcing the use of
|
|
release branches like Git Flow, Common-Flow only recommends the use of release
|
|
branches when it makes things easier. If creating a new release by tagging
|
|
"master" works for you, great, do that.</li>
|
|
</ul>
|
|
<h3 id="why-use-common-flow-instead-of-github-flow-and-how-does-it-differ">Why use Common-Flow instead of GitHub Flow, and how does it differ?</h3>
|
|
<p>Common-Flow is essentially GitHub Flow with the addition of a "Release" concept
|
|
that uses tags. It also attempts to define how certain common tasks are done,
|
|
like updating change/feature branches from their source branches for
|
|
example. This is to help end arguments about how such things are done.</p>
|
|
<p>If a deployment/release for you is just getting the latest code in the master
|
|
branch out, without caring about bumping version numbers or anything, then
|
|
GitHub Flow is a good fit for you, and you probably don't need the extras of
|
|
Common-Flow.</p>
|
|
<p>However if your deployments/releases have specific version numbers, then
|
|
Common-Flow gives you a simple set of rules of how to create and manage
|
|
releases, on top of what GitHub Flow already does.</p>
|
|
<h3 id="what-does-descriptive-name-mean-for-change-branches">What does "descriptive name" mean for change branches?</h3>
|
|
<p>It means what it sounds like. The name should be descriptive, as in by just
|
|
reading the name of the branch you should understand what the branch's purpose
|
|
is and what it does. Here's a few examples:</p>
|
|
<ul>
|
|
<li>add-2fa-support</li>
|
|
<li>fix-login-issue</li>
|
|
<li>remove-sort-by-middle-name-functionality</li>
|
|
<li>update-font-awesome</li>
|
|
<li>change-search-behavior</li>
|
|
<li>tweak-footer-style</li>
|
|
</ul>
|
|
<p>Notice how none of these have any prefixes like "feature/" or "hotfix/", they're
|
|
not needed when branch names are properly descriptive. However there's nothing
|
|
to say you can't use such prefixes if you want. That also means that you can add
|
|
ticket number prefixes if your team/org has that as part of it's process.</p>
|
|
<h3 id="how-do-we-release-an-emergency-hotfix-when-the-master-branch-is-broken">How do we release an emergency hotfix when the master branch is broken?</h3>
|
|
<p>This should ideally never happen, however if it does you can do one of the
|
|
following:</p>
|
|
<ul>
|
|
<li>Review why the master branch is broken and revert the changes that caused the
|
|
issues. Then apply the hotfix and release.</li>
|
|
<li>Or use a short-term release branch created from the latest release tag instead
|
|
of the master branch. Apply the hotfix to the release branch, create a release
|
|
tag on the release branch, and then merge it back into master.</li>
|
|
</ul>
|
|
<p>In this situation, it is recommended you try to revert the offending changes
|
|
that's preventing a new release from master. But if that proves to be a
|
|
complicated task and you're short on time, a short-term release branch gives you
|
|
a instant fix to the situation at hand, and let's you resolve the issues with
|
|
the master branch when you have more time on your hands.</p>
|
|
<h2 id="about">About</h2>
|
|
<p>The Git Common-Flow specification is authored
|
|
by <a href="http://jimeh.me">Jim Myhrberg</a>.</p>
|
|
<p>If you'd like to leave feedback,
|
|
please <a href="https://github.com/jimeh/common-flow/issues">open an issue on GitHub</a>.</p>
|
|
<h2 id="license">License</h2>
|
|
<p><a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons - CC BY 3.0</a></p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<script type="text/javascript" src="/assets/main-870855580c69dec57be4c965d0cf8afe78afa6b7b6f6bdb5aff91ac0256c0a1a.js"></script>
|
|
</body>
|
|
</html> |