diff --git a/docs/404.html b/docs/404.html index e020757..52bbd76 100644 --- a/docs/404.html +++ b/docs/404.html @@ -8,19 +8,19 @@ -404 Page Not Found | Git Common Flow - - - - - - - - - - - + 404 Page Not Found | Git Common Flow + + + + + + + + + +
@@ -33,42 +33,35 @@
  • Versions:
    • - - - - - - -
  • - 1.0.0-rc.2 -
    • - - - - - - - -
  • - 1.0.0-rc.1 -
    • - - +
  • + 1.0.0-rc.2 +
    • +
  • + 1.0.0-rc.1 +
    • -
    -

    404

    -

    Page not found :(

    -

    The requested page could not be found.

    -
    - +

    404

    +

    Page not found :(

    +

    The requested page could not be found.

    +
    + - + \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index 8d701a4..f07af9e 100644 --- a/docs/index.html +++ b/docs/index.html @@ -8,19 +8,19 @@ -Git Common-Flow 1.0.0-rc.2 | Git Common Flow - - - - - - - - - - - + Git Common-Flow 1.0.0-rc.2 | Git Common Flow + + + + + + + + + +
    @@ -33,270 +33,248 @@
  • Versions:
    • - - - - - - -
  • - 1.0.0-rc.2 -
    • - - - - - - - -
  • - 1.0.0-rc.1 -
    • - - +
  • + 1.0.0-rc.2 +
    • +
  • + 1.0.0-rc.1 +
    • -

    Git Common-Flow 1.0.0-rc.2

    - -

    - -

    Summary

    - -

    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 original variant -of GitHub Flow, while taking -into account how a lot of open source projects use git.

    - -

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned -releases, maintenance releases for old versions, and without the requirement to -deploy to production all the time.

    - -

    Terminology

    - - - -

    Git Common-Flow Specification (Common-Flow)

    - -

    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 RFC 2119.

    - -
      -
    1. The Master Branch -
        -
      1. A branch named "master" MUST exist and it MUST be referred to as the -"master branch".
        2. -
      2. The master branch MUST be considered bleeding edge.
        3. -
      3. The master branch MUST always be in a non-broken state with its test -suite passing.
        4. -
      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.
        5. -
      -
      2. -
    2. Change Branches -
        -
      1. Each change (feature, bugfix, etc.) MUST be performed on separate -branches that SHOULD be referred to as "change branches". All change -branches MUST have descriptive names. It is RECOMMENDED that you commit -often locally, and you SHOULD regularly push your work to the same named -branch on the remote server.
        2. -
      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. -
      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 -needs a designated "merge target" branch, typically this will be the same -as the source branch.
        4. -
      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 -the source branch.
        5. -
      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 -force push, and you SHOULD use the "--force-with-lease" git push option.
        6. -
      -
      3. -
    3. Pull Requests -
        -
      1. To merge a change branch into its merge target, you MUST open a "pull -request" (or equivalent) so others can review and approve your changes.
        2. -
      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 -happy with the change. This is especially important if the merge target -is the master branch.
        3. -
      3. 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.
        4. -
      -
      4. -
    4. Versioning -
        -
      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" -located in the root of the project.
        2. -
      2. If you are using a "VERSION" file in the root of the project, this MUST -only contain the exact version string.
        3. -
      3. The version string SHOULD follow the Semantic Versioning -(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" -is bad, and "2.11.4" is good.
        4. -
      -
      5. -
    5. Releases -
        -
      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 -commit MUST have a git tag created on it and named as the exact version -string.
        2. -
      2. If you are not using a release branch, then the version bump commit MUST -be created directly on the master branch.
        3. -
      3. The version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        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". You -MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form -and stick to it.
        5. -
      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.
        6. -
      6. If you use annotated release tags, the first line of the annotation MUST -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 -be blank, and the changelog MUST start on the third line.
        7. -
      -
      6. -
    6. Release Branches -
        -
      1. Any branch that has a name starting with "release-" SHOULD be referred to -as a "release branch".
        2. -
      2. Use of release branches is OPTIONAL.
        3. -
      3. Changes in a release branch SHOULD typically come from work being -done against the master branch. Meaning changes SHOULD only trickle -downwards from the master branch. If a change needs to trickle back up -into the master branch, that work should have happened against the master -branch in the first place. One exception to this is version bump commits.
        4. -
      4. There are two types of release branches; short-term, and long-term.
        5. -
      5. Short-Term Release Branches -
          -
        1. Used for creating a specific versioned release.
          2. -
        2. 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.
          3. -
        3. MUST have a name of "release-VERSION". For example for version -"2.11.4" the release branch name MUST be "release-2.11.4".
          4. -
        4. When using a short-term release branch, the version bump commit and -release tag MUST be made directly on the release branch itself.
          5. -
        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 way a change branch pulls in -updates from its source branch.
          6. -
        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 -deleted. Typically the source branch will be the master branch.
          7. -
        -
        6. -
      6. Long-Term Release Branches -
          -
        1. Used 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.
          2. -
        2. The branch name MUST have a non-specific version number. For example -a long-term release branch for creating new 2.9.x releases would be -named "release-2.9".
          3. -
        3. To create a new release from a long-term release branch, you MUST -create a version bump commit and release tag directly on the release -branch.
          4. -
        4. A long-term release branch 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".
          5. -
        -
        7. -
      -
      7. -
    7. Bug Fixes & Rollback -
        -
      1. You MUST NOT under any circumstances force push to the master branch.
        2. -
      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 -change branch and MUST follow the same workflow as any other change -branch.
        3. -
      3. 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.
        4. -
      -
      8. -
    8. Git Best Practices -
        -
      1. All commit messages SHOULD follow the Commit Guidelines and format from -the official git -documentation: -https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. -
      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. -
      3. You SHOULD always use "--force-with-lease" when doing a force push. The -regular "--force" option is dangerous and destructive. More -information: -https://developer.atlassian.com/blog/2015/04/force-with-lease/
        4. -
      4. You SHOULD understand and be comfortable with -rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        5. -
      5. 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".
        6. -
      6. 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.
        7. -
      -
      9. -
    - -

    About

    - -

    The Git Common-Flow specification is authored -by Jim Myhrberg.

    - -

    If you'd like to leave feedback, -please open an issue on GitHub.

    - -

    License

    - -

    Creative Commons - CC BY 3.0

    - - +

    +

    Summary

    +

    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 original variant + of GitHub Flow, while taking + into account how a lot of open source projects use git.

    +

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned + releases, maintenance releases for old versions, and without the requirement to + deploy to production all the time.

    +

    Terminology

    + +

    Git Common-Flow Specification (Common-Flow)

    +

    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 RFC 2119.

    +
      +
    1. The Master Branch +
        +
      1. A branch named "master" MUST exist and it MUST be referred to as the + "master branch".
        2. +
      2. The master branch MUST be considered bleeding edge.
        3. +
      3. The master branch MUST always be in a non-broken state with its test + suite passing.
        4. +
      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.
        5. +
      +
      2. +
    2. Change Branches +
        +
      1. Each change (feature, bugfix, etc.) MUST be performed on separate + branches that SHOULD be referred to as "change branches". All change + branches MUST have descriptive names. It is RECOMMENDED that you commit + often locally, and you SHOULD regularly push your work to the same named + branch on the remote server.
        2. +
      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. +
      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 + needs a designated "merge target" branch, typically this will be the same + as the source branch.
        4. +
      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 + the source branch.
        5. +
      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 + force push, and you SHOULD use the "--force-with-lease" git push option.
        6. +
      +
      3. +
    3. Pull Requests +
        +
      1. To merge a change branch into its merge target, you MUST open a "pull + request" (or equivalent) so others can review and approve your changes.
        2. +
      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 + happy with the change. This is especially important if the merge target + is the master branch.
        3. +
      3. 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.
        4. +
      +
      4. +
    4. Versioning +
        +
      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" + located in the root of the project.
        2. +
      2. If you are using a "VERSION" file in the root of the project, this MUST + only contain the exact version string.
        3. +
      3. The version string SHOULD follow the Semantic Versioning + (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" + is bad, and "2.11.4" is good.
        4. +
      +
      5. +
    5. Releases +
        +
      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 + commit MUST have a git tag created on it and named as the exact version + string.
        2. +
      2. If you are not using a release branch, then the version bump commit MUST + be created directly on the master branch.
        3. +
      3. The version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        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". You + MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form + and stick to it.
        5. +
      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.
        6. +
      6. If you use annotated release tags, the first line of the annotation MUST + 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 + be blank, and the changelog MUST start on the third line.
        7. +
      +
      6. +
    6. Release Branches +
        +
      1. Any branch that has a name starting with "release-" SHOULD be referred to + as a "release branch".
        2. +
      2. Use of release branches is OPTIONAL.
        3. +
      3. Changes in a release branch SHOULD typically come from work being + done against the master branch. Meaning changes SHOULD only trickle + downwards from the master branch. If a change needs to trickle back up + into the master branch, that work should have happened against the master + branch in the first place. One exception to this is version bump commits.
        4. +
      4. There are two types of release branches; short-term, and long-term.
        5. +
      5. Short-Term Release Branches +
          +
        1. Used for creating a specific versioned release.
          2. +
        2. 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.
          3. +
        3. MUST have a name of "release-VERSION". For example for version + "2.11.4" the release branch name MUST be "release-2.11.4".
          4. +
        4. When using a short-term release branch, the version bump commit and + release tag MUST be made directly on the release branch itself.
          5. +
        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 way a change branch pulls in + updates from its source branch.
          6. +
        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 + deleted. Typically the source branch will be the master branch.
          7. +
        +
        6. +
      6. Long-Term Release Branches +
          +
        1. Used 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.
          2. +
        2. The branch name MUST have a non-specific version number. For example + a long-term release branch for creating new 2.9.x releases would be + named "release-2.9".
          3. +
        3. To create a new release from a long-term release branch, you MUST + create a version bump commit and release tag directly on the release + branch.
          4. +
        4. A long-term release branch 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".
          5. +
        +
        7. +
      +
      7. +
    7. Bug Fixes & Rollback +
        +
      1. You MUST NOT under any circumstances force push to the master branch.
        2. +
      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 + change branch and MUST follow the same workflow as any other change + branch.
        3. +
      3. 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.
        4. +
      +
      8. +
    8. Git Best Practices +
        +
      1. All commit messages SHOULD follow the Commit Guidelines and format from + the official git + documentation: + https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. +
      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. +
      3. You SHOULD always use "--force-with-lease" when doing a force push. The + regular "--force" option is dangerous and destructive. More + information: + https://developer.atlassian.com/blog/2015/04/force-with-lease/
        4. +
      4. You SHOULD understand and be comfortable with + rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        5. +
      5. 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".
        6. +
      6. 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.
        7. +
      +
      9. +
    +

    About

    +

    The Git Common-Flow specification is authored + by Jim Myhrberg.

    +

    If you'd like to leave feedback, + please open an issue on GitHub.

    +

    License

    +

    Creative Commons - CC BY 3.0

    + - + \ No newline at end of file diff --git a/docs/robots.txt b/docs/robots.txt index 8401d2a..c6d7aaa 100644 --- a/docs/robots.txt +++ b/docs/robots.txt @@ -1 +1 @@ -Sitemap: https://commonflow.org/sitemap.xml +Sitemap: https://commonflow.org/sitemap.xml \ No newline at end of file diff --git a/docs/sitemap.xml b/docs/sitemap.xml index 2637737..0df94bc 100644 --- a/docs/sitemap.xml +++ b/docs/sitemap.xml @@ -1,12 +1,12 @@ - - -https://commonflow.org/spec/1.0.0-rc.1.html - - -https://commonflow.org/spec/1.0.0-rc.2.html - - -https://commonflow.org/ - - + + + https://commonflow.org/spec/1.0.0-rc.1.html + + + https://commonflow.org/spec/1.0.0-rc.2.html + + + https://commonflow.org/ + + \ No newline at end of file diff --git a/docs/spec/1.0.0-rc.1.html b/docs/spec/1.0.0-rc.1.html index 150e39b..58104cf 100644 --- a/docs/spec/1.0.0-rc.1.html +++ b/docs/spec/1.0.0-rc.1.html @@ -8,19 +8,19 @@ -Git Common-Flow 1.0.0-rc.1 | Git Common Flow - - - - - - - - - - - + Git Common-Flow 1.0.0-rc.1 | Git Common Flow + + + + + + + + + +
    @@ -33,236 +33,214 @@
  • Versions:
    • - - - - - - -
  • - 1.0.0-rc.2 -
    • - - - - - - - -
  • - 1.0.0-rc.1 -
    • - - +
  • + 1.0.0-rc.2 +
    • +
  • + 1.0.0-rc.1 +
    • -

    Git Common-Flow 1.0.0-rc.1

    - -

    - -

    Summary

    - -

    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 original variant -of GitHub Flow, while taking -into account how a lot of open source projects use git.

    - -

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned -releases, maintenance releases for old versions, and without the requirement to -deploy to production all the time.

    - -

    Terminology

    - - - -

    Git Common-Flow Specification (Common-Flow)

    - -

    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 RFC 2119.

    - -
      -
    1. The Master Branch -
        -
      1. A branch named "master" MUST exist and it MUST be referred to as the -"master branch".
        2. -
      2. The master branch MUST be considered bleeding edge.
        3. -
      3. The master branch MUST always be in a non-broken state with its test -suite passing.
        4. -
      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 -release.
        5. -
      -
      2. -
    2. Changes -
        -
      1. Changes MUST be performed on a separate branch that SHOULD be referred to -as a "change branch". All change branches MUST have descriptive names. It -is RECOMMENDED that you commit often locally, and you SHOULD regularly -push your work to the same named branch on the remote server.
        2. -
      2. 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.
        3. -
      3. 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. To be clear you MUST NOT merge a source branch into a -change branch.
        4. -
      4. 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 do a force -push, and you SHOULD use the "--force-with-lease" git push option.
        5. -
      5. To merge a change branch into its merge target branch, you MUST open a -"pull request" (or equivalent) so others can review and approve your -changes.
        6. -
      6. 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.
        7. -
      7. 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 -discuss the changes with others there.
        8. -
      -
      3. -
    3. Git Best Practices -
        -
      1. All commit messages SHOULD follow the Commit Guidelines and format from -the official git -documentation: -https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. -
      2. You SHOULD always use "--force-with-lease" when doing a force push. The -plain "--force" option is dangerous and destructive. More -information: -https://developer.atlassian.com/blog/2015/04/force-with-lease/
        3. -
      3. You SHOULD understand and be comfortable with -rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        4. -
      4. 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".
        5. -
      5. 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.
        6. -
      -
      4. -
    4. Versioning -
        -
      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" -located in the root of the project.
        2. -
      2. If you are using a "VERSION" file in the root of the project, this MUST -only contain the exact version string.
        3. -
      3. The version string SHOULD follow the Semantic Versioning -(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" -is bad, and "2.11.4" is good.
        4. -
      -
      5. -
    5. Releases -
        -
      1. To create a new release, you MUST create a "version bump" commit directly -on the master branch which changes the hard-coded version value of the -project. The version bump commit MUST have a git tag created on it and -named as the exact version string.
        2. -
      2. A version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        3. -
      3. 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".
        4. -
      4. 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.
        5. -
      5. If you use annotated release tags, the first line of the annotation MUST -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 -be blank, and the changelog MUST start on the third line.
        6. -
      -
      6. -
    6. Bug Fixes & Rollback -
        -
      1. You MUST NOT under any circumstances force push to the master branch.
        2. -
      2. If a change branch which has been merged in to 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.
        3. -
      3. If a change branch is wrongfully merged in to 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.
        4. -
      -
      7. -
    7. Maintenance Releases -
        -
      1. Any branch that has a name starting with "stable-" SHOULD be referred to -as a "maintenance branch".
        2. -
      2. Maintenance branches are used for managing new releases of older -versions. Typically this is used to provide security updates for older -versions when the master branch has moved on to a point that a new -release for the old version cannot be made from the master branch.
        3. -
      3. A "maintenance release" is identical to a regular release, except the -version bump commit and the release tag are placed on the maintenance -branch instead of on the master branch.
        4. -
      4. A maintenance branch SHOULD follow a "stable-X.Y" naming pattern, where -"X" is the MAJOR version and "Y" is the minor version.
        5. -
      5. A maintenance 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 "stable-2.9" off of the -"2.9.7" release tag. The security fix release will then end up being -version "2.9.8".
        6. -
      6. When working on a maintenance release, the relevant maintenance branch -MUST be thought of as the master branch for that maintenance work.
        7. -
      7. Changes in a maintenance branch SHOULD typically come from work being -done against the master branch. Meaning changes SHOULD only trickle -downwards from the master branch. If a change needs to trickle back up -into the master branch, that work should have happened against the master -branch in the first place.
        8. -
      -
      8. -
    - -

    About

    - -

    The Git Common-Flow specification is authored -by Jim Myhrberg.

    - -

    If you'd like to leave feedback, -please open an issue on GitHub.

    - -

    License

    - -

    Creative Commons - CC BY 3.0

    - - +

    +

    Summary

    +

    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 original variant + of GitHub Flow, while taking + into account how a lot of open source projects use git.

    +

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned + releases, maintenance releases for old versions, and without the requirement to + deploy to production all the time.

    +

    Terminology

    + +

    Git Common-Flow Specification (Common-Flow)

    +

    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 RFC 2119.

    +
      +
    1. The Master Branch +
        +
      1. A branch named "master" MUST exist and it MUST be referred to as the + "master branch".
        2. +
      2. The master branch MUST be considered bleeding edge.
        3. +
      3. The master branch MUST always be in a non-broken state with its test + suite passing.
        4. +
      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 + release.
        5. +
      +
      2. +
    2. Changes +
        +
      1. Changes MUST be performed on a separate branch that SHOULD be referred to + as a "change branch". All change branches MUST have descriptive names. It + is RECOMMENDED that you commit often locally, and you SHOULD regularly + push your work to the same named branch on the remote server.
        2. +
      2. 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.
        3. +
      3. 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. To be clear you MUST NOT merge a source branch into a + change branch.
        4. +
      4. 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 do a force + push, and you SHOULD use the "--force-with-lease" git push option.
        5. +
      5. To merge a change branch into its merge target branch, you MUST open a + "pull request" (or equivalent) so others can review and approve your + changes.
        6. +
      6. 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.
        7. +
      7. 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 + discuss the changes with others there.
        8. +
      +
      3. +
    3. Git Best Practices +
        +
      1. All commit messages SHOULD follow the Commit Guidelines and format from + the official git + documentation: + https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. +
      2. You SHOULD always use "--force-with-lease" when doing a force push. The + plain "--force" option is dangerous and destructive. More + information: + https://developer.atlassian.com/blog/2015/04/force-with-lease/
        3. +
      3. You SHOULD understand and be comfortable with + rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        4. +
      4. 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".
        5. +
      5. 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.
        6. +
      +
      4. +
    4. Versioning +
        +
      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" + located in the root of the project.
        2. +
      2. If you are using a "VERSION" file in the root of the project, this MUST + only contain the exact version string.
        3. +
      3. The version string SHOULD follow the Semantic Versioning + (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" + is bad, and "2.11.4" is good.
        4. +
      +
      5. +
    5. Releases +
        +
      1. To create a new release, you MUST create a "version bump" commit directly + on the master branch which changes the hard-coded version value of the + project. The version bump commit MUST have a git tag created on it and + named as the exact version string.
        2. +
      2. A version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        3. +
      3. 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".
        4. +
      4. 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.
        5. +
      5. If you use annotated release tags, the first line of the annotation MUST + 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 + be blank, and the changelog MUST start on the third line.
        6. +
      +
      6. +
    6. Bug Fixes & Rollback +
        +
      1. You MUST NOT under any circumstances force push to the master branch.
        2. +
      2. If a change branch which has been merged in to 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.
        3. +
      3. If a change branch is wrongfully merged in to 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.
        4. +
      +
      7. +
    7. Maintenance Releases +
        +
      1. Any branch that has a name starting with "stable-" SHOULD be referred to + as a "maintenance branch".
        2. +
      2. Maintenance branches are used for managing new releases of older + versions. Typically this is used to provide security updates for older + versions when the master branch has moved on to a point that a new + release for the old version cannot be made from the master branch.
        3. +
      3. A "maintenance release" is identical to a regular release, except the + version bump commit and the release tag are placed on the maintenance + branch instead of on the master branch.
        4. +
      4. A maintenance branch SHOULD follow a "stable-X.Y" naming pattern, where + "X" is the MAJOR version and "Y" is the minor version.
        5. +
      5. A maintenance 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 "stable-2.9" off of the + "2.9.7" release tag. The security fix release will then end up being + version "2.9.8".
        6. +
      6. When working on a maintenance release, the relevant maintenance branch + MUST be thought of as the master branch for that maintenance work.
        7. +
      7. Changes in a maintenance branch SHOULD typically come from work being + done against the master branch. Meaning changes SHOULD only trickle + downwards from the master branch. If a change needs to trickle back up + into the master branch, that work should have happened against the master + branch in the first place.
        8. +
      +
      8. +
    +

    About

    +

    The Git Common-Flow specification is authored + by Jim Myhrberg.

    +

    If you'd like to leave feedback, + please open an issue on GitHub.

    +

    License

    +

    Creative Commons - CC BY 3.0

    + - + \ No newline at end of file diff --git a/docs/spec/1.0.0-rc.2.html b/docs/spec/1.0.0-rc.2.html index a1d676b..f95a95e 100644 --- a/docs/spec/1.0.0-rc.2.html +++ b/docs/spec/1.0.0-rc.2.html @@ -8,19 +8,19 @@ -Git Common-Flow 1.0.0-rc.2 | Git Common Flow - - - - - - - - - - - + Git Common-Flow 1.0.0-rc.2 | Git Common Flow + + + + + + + + + +
    @@ -33,270 +33,248 @@
  • Versions:
    • - - - - - - -
  • - 1.0.0-rc.2 -
    • - - - - - - - -
  • - 1.0.0-rc.1 -
    • - - +
  • + 1.0.0-rc.2 +
    • +
  • + 1.0.0-rc.1 +
    • -

    Git Common-Flow 1.0.0-rc.2

    - -

    - -

    Summary

    - -

    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 original variant -of GitHub Flow, while taking -into account how a lot of open source projects use git.

    - -

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned -releases, maintenance releases for old versions, and without the requirement to -deploy to production all the time.

    - -

    Terminology

    - - - -

    Git Common-Flow Specification (Common-Flow)

    - -

    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 RFC 2119.

    - -
      -
    1. The Master Branch -
        -
      1. A branch named "master" MUST exist and it MUST be referred to as the -"master branch".
        2. -
      2. The master branch MUST be considered bleeding edge.
        3. -
      3. The master branch MUST always be in a non-broken state with its test -suite passing.
        4. -
      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.
        5. -
      -
      2. -
    2. Change Branches -
        -
      1. Each change (feature, bugfix, etc.) MUST be performed on separate -branches that SHOULD be referred to as "change branches". All change -branches MUST have descriptive names. It is RECOMMENDED that you commit -often locally, and you SHOULD regularly push your work to the same named -branch on the remote server.
        2. -
      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. -
      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 -needs a designated "merge target" branch, typically this will be the same -as the source branch.
        4. -
      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 -the source branch.
        5. -
      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 -force push, and you SHOULD use the "--force-with-lease" git push option.
        6. -
      -
      3. -
    3. Pull Requests -
        -
      1. To merge a change branch into its merge target, you MUST open a "pull -request" (or equivalent) so others can review and approve your changes.
        2. -
      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 -happy with the change. This is especially important if the merge target -is the master branch.
        3. -
      3. 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.
        4. -
      -
      4. -
    4. Versioning -
        -
      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" -located in the root of the project.
        2. -
      2. If you are using a "VERSION" file in the root of the project, this MUST -only contain the exact version string.
        3. -
      3. The version string SHOULD follow the Semantic Versioning -(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" -is bad, and "2.11.4" is good.
        4. -
      -
      5. -
    5. Releases -
        -
      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 -commit MUST have a git tag created on it and named as the exact version -string.
        2. -
      2. If you are not using a release branch, then the version bump commit MUST -be created directly on the master branch.
        3. -
      3. The version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        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". You -MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form -and stick to it.
        5. -
      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.
        6. -
      6. If you use annotated release tags, the first line of the annotation MUST -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 -be blank, and the changelog MUST start on the third line.
        7. -
      -
      6. -
    6. Release Branches -
        -
      1. Any branch that has a name starting with "release-" SHOULD be referred to -as a "release branch".
        2. -
      2. Use of release branches is OPTIONAL.
        3. -
      3. Changes in a release branch SHOULD typically come from work being -done against the master branch. Meaning changes SHOULD only trickle -downwards from the master branch. If a change needs to trickle back up -into the master branch, that work should have happened against the master -branch in the first place. One exception to this is version bump commits.
        4. -
      4. There are two types of release branches; short-term, and long-term.
        5. -
      5. Short-Term Release Branches -
          -
        1. Used for creating a specific versioned release.
          2. -
        2. 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.
          3. -
        3. MUST have a name of "release-VERSION". For example for version -"2.11.4" the release branch name MUST be "release-2.11.4".
          4. -
        4. When using a short-term release branch, the version bump commit and -release tag MUST be made directly on the release branch itself.
          5. -
        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 way a change branch pulls in -updates from its source branch.
          6. -
        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 -deleted. Typically the source branch will be the master branch.
          7. -
        -
        6. -
      6. Long-Term Release Branches -
          -
        1. Used 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.
          2. -
        2. The branch name MUST have a non-specific version number. For example -a long-term release branch for creating new 2.9.x releases would be -named "release-2.9".
          3. -
        3. To create a new release from a long-term release branch, you MUST -create a version bump commit and release tag directly on the release -branch.
          4. -
        4. A long-term release branch 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".
          5. -
        -
        7. -
      -
      7. -
    7. Bug Fixes & Rollback -
        -
      1. You MUST NOT under any circumstances force push to the master branch.
        2. -
      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 -change branch and MUST follow the same workflow as any other change -branch.
        3. -
      3. 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.
        4. -
      -
      8. -
    8. Git Best Practices -
        -
      1. All commit messages SHOULD follow the Commit Guidelines and format from -the official git -documentation: -https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. -
      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. -
      3. You SHOULD always use "--force-with-lease" when doing a force push. The -regular "--force" option is dangerous and destructive. More -information: -https://developer.atlassian.com/blog/2015/04/force-with-lease/
        4. -
      4. You SHOULD understand and be comfortable with -rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        5. -
      5. 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".
        6. -
      6. 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.
        7. -
      -
      9. -
    - -

    About

    - -

    The Git Common-Flow specification is authored -by Jim Myhrberg.

    - -

    If you'd like to leave feedback, -please open an issue on GitHub.

    - -

    License

    - -

    Creative Commons - CC BY 3.0

    - - +

    +

    Summary

    +

    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 original variant + of GitHub Flow, while taking + into account how a lot of open source projects use git.

    +

    TL;DR: Common-Flow is basically GitHub Flow with the addition of versioned + releases, maintenance releases for old versions, and without the requirement to + deploy to production all the time.

    +

    Terminology

    + +

    Git Common-Flow Specification (Common-Flow)

    +

    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 RFC 2119.

    +
      +
    1. The Master Branch +
        +
      1. A branch named "master" MUST exist and it MUST be referred to as the + "master branch".
        2. +
      2. The master branch MUST be considered bleeding edge.
        3. +
      3. The master branch MUST always be in a non-broken state with its test + suite passing.
        4. +
      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.
        5. +
      +
      2. +
    2. Change Branches +
        +
      1. Each change (feature, bugfix, etc.) MUST be performed on separate + branches that SHOULD be referred to as "change branches". All change + branches MUST have descriptive names. It is RECOMMENDED that you commit + often locally, and you SHOULD regularly push your work to the same named + branch on the remote server.
        2. +
      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. +
      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 + needs a designated "merge target" branch, typically this will be the same + as the source branch.
        4. +
      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 + the source branch.
        5. +
      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 + force push, and you SHOULD use the "--force-with-lease" git push option.
        6. +
      +
      3. +
    3. Pull Requests +
        +
      1. To merge a change branch into its merge target, you MUST open a "pull + request" (or equivalent) so others can review and approve your changes.
        2. +
      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 + happy with the change. This is especially important if the merge target + is the master branch.
        3. +
      3. 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.
        4. +
      +
      4. +
    4. Versioning +
        +
      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" + located in the root of the project.
        2. +
      2. If you are using a "VERSION" file in the root of the project, this MUST + only contain the exact version string.
        3. +
      3. The version string SHOULD follow the Semantic Versioning + (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" + is bad, and "2.11.4" is good.
        4. +
      +
      5. +
    5. Releases +
        +
      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 + commit MUST have a git tag created on it and named as the exact version + string.
        2. +
      2. If you are not using a release branch, then the version bump commit MUST + be created directly on the master branch.
        3. +
      3. The version bump commit MUST 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 MUST read: "Bump version to 2.11.4"
        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". You + MUST not use a mix of "v" prefixed and non-prefixed tags. Pick one form + and stick to it.
        5. +
      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.
        6. +
      6. If you use annotated release tags, the first line of the annotation MUST + 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 + be blank, and the changelog MUST start on the third line.
        7. +
      +
      6. +
    6. Release Branches +
        +
      1. Any branch that has a name starting with "release-" SHOULD be referred to + as a "release branch".
        2. +
      2. Use of release branches is OPTIONAL.
        3. +
      3. Changes in a release branch SHOULD typically come from work being + done against the master branch. Meaning changes SHOULD only trickle + downwards from the master branch. If a change needs to trickle back up + into the master branch, that work should have happened against the master + branch in the first place. One exception to this is version bump commits.
        4. +
      4. There are two types of release branches; short-term, and long-term.
        5. +
      5. Short-Term Release Branches +
          +
        1. Used for creating a specific versioned release.
          2. +
        2. 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.
          3. +
        3. MUST have a name of "release-VERSION". For example for version + "2.11.4" the release branch name MUST be "release-2.11.4".
          4. +
        4. When using a short-term release branch, the version bump commit and + release tag MUST be made directly on the release branch itself.
          5. +
        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 way a change branch pulls in + updates from its source branch.
          6. +
        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 + deleted. Typically the source branch will be the master branch.
          7. +
        +
        6. +
      6. Long-Term Release Branches +
          +
        1. Used 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.
          2. +
        2. The branch name MUST have a non-specific version number. For example + a long-term release branch for creating new 2.9.x releases would be + named "release-2.9".
          3. +
        3. To create a new release from a long-term release branch, you MUST + create a version bump commit and release tag directly on the release + branch.
          4. +
        4. A long-term release branch 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".
          5. +
        +
        7. +
      +
      7. +
    7. Bug Fixes & Rollback +
        +
      1. You MUST NOT under any circumstances force push to the master branch.
        2. +
      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 + change branch and MUST follow the same workflow as any other change + branch.
        3. +
      3. 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.
        4. +
      +
      8. +
    8. Git Best Practices +
        +
      1. All commit messages SHOULD follow the Commit Guidelines and format from + the official git + documentation: + https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
        2. +
      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. +
      3. You SHOULD always use "--force-with-lease" when doing a force push. The + regular "--force" option is dangerous and destructive. More + information: + https://developer.atlassian.com/blog/2015/04/force-with-lease/
        4. +
      4. You SHOULD understand and be comfortable with + rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
        5. +
      5. 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".
        6. +
      6. 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.
        7. +
      +
      9. +
    +

    About

    +

    The Git Common-Flow specification is authored + by Jim Myhrberg.

    +

    If you'd like to leave feedback, + please open an issue on GitHub.

    +

    License

    +

    Creative Commons - CC BY 3.0

    + - + \ No newline at end of file