jimeh/common-flow
1
0
Fork 0
mirror of https://github.com/jimeh/common-flow.git synced 2026-02-19 09:26:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

Break pull request information into it's own section

Browse Source
This commit is contained in:
Jim Myhrberg
2017-07-07 16:31:40 +01:00
parent 4b1dac4d2d
commit 1362060294
1 changed files with 22 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
common-flow.md
View File

@@ -51,31 +51,35 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
release/production" state to reduce the friction of creating a new release/production" state to reduce the friction of creating a new
release. release.
2. Change Branches 2. Change Branches
1. Changes MUST be performed on a separate branch that SHOULD be referred to 1. Each change (feature, bugfix, etc.) MUST be performed on separate
as a "change branch". All change branches MUST have descriptive names. It branches that SHOULD be referred to as "change branches". All change
is RECOMMENDED that you commit often locally, and you SHOULD regularly branches MUST have descriptive names. It is RECOMMENDED that you commit
push your work to the same named branch on the remote server. often locally, and you SHOULD regularly push your work to the same named
2. When a change branch is created, the branch that it is created from branch on the remote server.
2. You MUST create separate change branches for each distinctly different
change. You MUST NOT include multiple unrelated changes into a single
change branch.
3. 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 SHOULD be referred to as the "source branch". Each change branch also
needs a designated "merge target" branch, typically this will be the same needs a designated "merge target" branch, typically this will be the same
as the source branch. as the source branch.
3. Change branches MUST be regularly updated with any changes from their 4. 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 source branch. This MUST be done by rebasing the change branch on top of
the source branch. the source branch.
4. After rebasing a change branch on top of its source branch you MUST push 5. After rebasing a change branch on top of its source branch you MUST push
the change branch to the remote server. This will require you to do a the change branch to the remote server. This will require you to do a
force push, and you SHOULD use the "--force-with-lease" git push option. force push, and you SHOULD use the "--force-with-lease" git push option.
5. To merge a change branch into its merge target branch, you MUST open a 3. Pull Requests
"pull request" (or equivalent) so others can review and approve your 1. To merge a change branch into its merge target, you MUST open a "pull
changes. request" (or equivalent) so others can review and approve your changes.
6. A pull request MUST only be merged when the change branch is up-to-date 2. 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 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 happy with the change. This is especially important if the merge target
is the master branch. is the master branch.
7. To get feedback, help, or generally just discuss a change branch with 3. To get feedback, help, or generally just discuss a change branch with
others, it is RECOMMENDED you do this by creating a pull request and others, the RECOMMENDED way to do so is by creating a pull request and
discuss the changes with others there. discuss the changes with others there.
3. Versioning 4. Versioning
1. The project MUST have its version hard-coded somewhere in the 1. The project MUST have its version hard-coded somewhere in the
code-base. It is RECOMMENDED that this is done in a file called "VERSION" code-base. It is RECOMMENDED that this is done in a file called "VERSION"
located in the root of the project. located in the root of the project.
@@ -85,7 +89,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
(<http://semver.org/>) format. Use of Semantic Versioning is OPTIONAL, (<http://semver.org/>) format. Use of Semantic Versioning is OPTIONAL,
but the version string MUST NOT have a "v" prefix. For example "v2.11.4" but the version string MUST NOT have a "v" prefix. For example "v2.11.4"
is bad, and "2.11.4" is good. is bad, and "2.11.4" is good.
4. Releases 5. Releases
1. To create a new release, you MUST create a "version bump" commit which 1. To create a new release, you MUST create a "version bump" commit which
changes the hard-coded version string of the project. The version bump changes the hard-coded version string of the project. The version bump
commit MUST have a git tag created on it and named as the exact version commit MUST have a git tag created on it and named as the exact version
@@ -105,7 +109,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
read "Release VERSION". For example for version "2.11.4" the first line read "Release VERSION". For example for version "2.11.4" the first line
of the tag annotation would read "Release 2.11.4". The second line must of the tag annotation would read "Release 2.11.4". The second line must
be blank, and the changelog MUST start on the third line. be blank, and the changelog MUST start on the third line.
5. Release Branches 6. Release Branches
1. Any branch that has a name starting with "release-" SHOULD be referred to 1. Any branch that has a name starting with "release-" SHOULD be referred to
as a "release branch". as a "release branch".
2. Use of release branches is OPTIONAL. 2. Use of release branches is OPTIONAL.
@@ -147,7 +151,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
the latest of which is "2.9.7", we create a new branch called the latest of which is "2.9.7", we create a new branch called
"release-2.9" off of the "2.9.7" release tag. The security fix "release-2.9" off of the "2.9.7" release tag. The security fix
release will then end up being version "2.9.8". release will then end up being version "2.9.8".
6. Bug Fixes & Rollback 7. Bug Fixes & Rollback
1. You MUST NOT under any circumstances force push to the master branch. 1. You MUST NOT under any circumstances force push to the master branch.
2. If a change branch which has been merged into the master branch is found 2. 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 to have a bug in it, the bug fix work MUST be done as a new separate
@@ -157,7 +161,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
reason the merge must be undone, you MUST undo the merge by reverting the 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 merge commit itself. Effectively creating a new commit that reverses all
the relevant changes. the relevant changes.
7. Git Best Practices 8. Git Best Practices
1. All commit messages SHOULD follow the Commit Guidelines and format from 1. All commit messages SHOULD follow the Commit Guidelines and format from
the official git the official git
documentation: documentation: