From e67812ca11250937786d33a977bb846cbce76226 Mon Sep 17 00:00:00 2001 From: Jim Myhrberg Date: Sun, 9 Jul 2017 20:09:53 +0100 Subject: [PATCH] Minor fixes --- common-flow.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/common-flow.md b/common-flow.md index 40d3b6f..9506836 100644 --- a/common-flow.md +++ b/common-flow.md @@ -47,8 +47,8 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). 2. The master branch MUST be considered bleeding edge. 3. The master branch MUST always be in a non-broken state with its test suite passing. - 4. The master branch SHOULD always be in a "as near as possible ready for - release/production" state to reduce the friction of creating a new + 4. 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. 2. Change Branches 1. Each change (feature, bugfix, etc.) MUST be performed on separate @@ -101,9 +101,9 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). first line of the commit message MUST read: "Bump version to 2.11.4" 4. The release tag on the version bump commit MUST be named exactly the same as the version string. The tag name can OPTIONALLY be prefixed with - "v". For example the tag name can be either "2.11.4" or "v2.11.4". But - you MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one - form and stick to it. + "v". For example the tag name can be either "2.11.4" or "v2.11.4". You + MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form + and stick to it. 5. 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. @@ -133,7 +133,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). 5. 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 was a change branch pulls in + on top of the master branch the same way a change branch pulls in updates from its source branch. 6. After the version bump commit and release tag have been created, the release branch MUST be merged back into its source branch and then @@ -149,10 +149,11 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). create a version bump commit and release tag directly on the release branch. 4. A long-term release branch MUST be created from the relevant release - tag. For example if there is a security fix for all 2.9.x releases, - 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 will then end up being version "2.9.8". + 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". 7. Bug Fixes & Rollback 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 @@ -168,11 +169,11 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). the official git documentation: - 2. You SHOULD never blindly commit all changes with "git commit -a". Use - "git add" to add individual changes to the staging area so you are fully - aware of what you are committing. + 2. You SHOULD never blindly commit all changes with "git commit -a". It is + RECOMMENDED you use "git add -i" to add individual changes to the staging + area so you are fully aware of what you are committing. 3. You SHOULD always use "--force-with-lease" when doing a force push. The - plain "--force" option is dangerous and destructive. More + regular "--force" option is dangerous and destructive. More information: 4. You SHOULD understand and be comfortable with