Skip to content

Instantly share code, notes, and snippets.

@mjavadhpour

mjavadhpour/my-git-convention-and-style-guide.md

Last active November 15, 2024 16:49
Show Gist options
  • Save mjavadhpour/a140e75882b87d8f3d70f2b0508f21cd to your computer and use it in GitHub Desktop.
Save mjavadhpour/a140e75882b87d8f3d70f2b0508f21cd to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. mjavadhpour renamed this gist Jan 1, 2020. 1 changed file with 0 additions and 0 deletions.
    0 nikmodern-git-convention-and-style-guide.md → my-git-convention-and-style-guide.md
    View file
    File renamed without changes.
  2. mjavadhpour revised this gist Jan 1, 2020. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@

    # Nikmodern Git Convention And Style Guide:
    # My Git Convention And Style Guide:

    This is a Git Style Guide inspired by [*How to Get Your Change Into the LinuxKernel*](https://kernel.org/doc/html/latest/process/submitting-patches.html),
    the [git man pages](http://git-scm.com/doc) and various practices popular
  3. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,12 +9,12 @@ among the community.

    1. [Branches](#branches)
    1. [Commits](#commits)
    i. [Messages](#messages)
    ii. [Template](#template)
    - [Messages](#messages)
    - [Template](#template)
    1. [Changelog](#changelog)
    i. [Standard CHANGELOG](#standard-changelog)
    ii. [Standard Version](#standard-version)
    iii. [Commitizen for contributors](#commitizen-for-contributors)
    - [Standard CHANGELOG](#standard-changelog)
    - [Standard Version](#standard-version)
    - [Commitizen for contributors](#commitizen-for-contributors)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)
  4. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,12 +9,12 @@ among the community.

    1. [Branches](#branches)
    1. [Commits](#commits)
    i. [Messages](#messages)
    ii. [Template](#template)
    i. [Messages](#messages)
    ii. [Template](#template)
    1. [Changelog](#changelog)
    i. [Standard CHANGELOG](#standard-changelog)
    ii. [Standard Version](#standard-version)
    iii. [Commitizen for contributors](#commitizen-for-contributors)
    i. [Standard CHANGELOG](#standard-changelog)
    ii. [Standard Version](#standard-version)
    iii. [Commitizen for contributors](#commitizen-for-contributors)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)
  5. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,12 +9,12 @@ among the community.

    1. [Branches](#branches)
    1. [Commits](#commits)
    1-1. [Messages](#messages)
    1-1. [Template](#template)
    i. [Messages](#messages)
    ii. [Template](#template)
    1. [Changelog](#changelog)
    1-1. [Standard CHANGELOG](#standard-changelog)
    1-1. [Standard Version](#standard-version)
    1-1. [Commitizen for contributors](#commitizen-for-contributors)
    i. [Standard CHANGELOG](#standard-changelog)
    ii. [Standard Version](#standard-version)
    iii. [Commitizen for contributors](#commitizen-for-contributors)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)
  6. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,12 +9,12 @@ among the community.

    1. [Branches](#branches)
    1. [Commits](#commits)
    1-1. [Messages](#messages)
    1-1. [Template](#template)
    1-1. [Messages](#messages)
    1-1. [Template](#template)
    1. [Changelog](#changelog)
    1-1. [Standard CHANGELOG](#standard-changelog)
    1-1. [Standard Version](#standard-version)
    1-1. [Commitizen for contributors](#commitizen-for-contributors)
    1-1. [Standard CHANGELOG](#standard-changelog)
    1-1. [Standard Version](#standard-version)
    1-1. [Commitizen for contributors](#commitizen-for-contributors)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)
  7. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 5 additions and 2 deletions.
    7 changes: 5 additions & 2 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,9 +9,12 @@ among the community.

    1. [Branches](#branches)
    1. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    1-1. [Messages](#messages)
    1-1. [Template](#template)
    1. [Changelog](#changelog)
    1-1. [Standard CHANGELOG](#standard-changelog)
    1-1. [Standard Version](#standard-version)
    1-1. [Commitizen for contributors](#commitizen-for-contributors)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)
  8. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 37 additions and 0 deletions.
    37 changes: 37 additions & 0 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -212,7 +212,10 @@ We use [conventional commits](https://conventionalcommits.org/) and you must to
    Note: We will use [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) and [Commitizen for contributors](https://github.com/commitizen/cz-cli) to commit our changes in a right way by using angular commit conventions. The [Commitizen for contributors](https://github.com/commitizen/cz-cli) will generate our commits in a template that acceptable by [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) and help us to no more digging through CONTRIBUTING.md to find what the preferred format is and will generate our CHANGELOG.md automatically.

    * ##### [**Standard CHANGELOG**](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/standard-changelog)

    An opinionated approach to CHANGELOG generation using angular commit conventions.

    **Note:** You can use [Standard Version](#standard-version) for Automatic versioning and CHANGELOG generation.

    **Install:**
    ```sh
    @@ -228,6 +231,40 @@ We use [conventional commits](https://conventionalcommits.org/) and you must to
    ```sh
    $ standard-changelog
    ```
    * ##### [**Standard Version**](https://github.com/conventional-changelog/standard-version)
    Install globally:
    ```sh
    $ npm i -g standard-version
    ```
    Create *package.json* in root of your project:
    ```sh
    $ cd my-project
    $ nano package.json
    ```
    Then add this folowing json string to *package.json*:
    ```json
    {
    "version": "<my-first-version>",
    "description": "<my-description>",
    "scripts": {
    "release": "standard-version"
    }
    }
    ```
    Note: Fill `<my-first-version>` and `<my-description>` with your own version and description.
    First Release:
    ```sh
    $ standard-version --first-release
    ```
    If you typically use npm version to cut a new release, do this instead:
    ```sh
    $ standard-version
    ```
    And it will automatically tag and update changelog really nicely.
    * ##### [**Commitizen for contributors**](https://github.com/commitizen/cz-cli)
    After you install [Standard CHANGELOG](#standard-changelog) you can install as simple as running the following command
    ```sh
  9. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 6 additions and 2 deletions.
    8 changes: 6 additions & 2 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -137,9 +137,13 @@ We use [conventional commits](https://conventionalcommits.org/) and you must to
    of the `Phpcr\Session`. This means that initializers can retrieve both
    the PHPCR session and the `DocumentManager`.
    - The `init` method of the InitializerInterface now accepts a `ManagerResistry` instead of a `PhpcrSession`. The PHPCR session can be retrieved using `$registry->getConnection` and the manager with `$registry->getManager()`;
    - The `init` method of the InitializerInterface now accepts a
    `ManagerResistry` instead of a `PhpcrSession`. The PHPCR session can be
    retrieved using `$registry->getConnection` and the manager with
    `$registry->getManager()`;
    - The first argument to the `GenericInitializer` constructor is now the name of the initializer. Short (50 chars or fewer) summary of changes
    - The first argument to the `GenericInitializer` constructor is now the
    name of the initializer. Short (50 chars or fewer) summary of changes
    Fixes: #1234, #4321
    See also: #12, #34
  10. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -238,6 +238,7 @@ We use [conventional commits](https://conventionalcommits.org/) and you must to
    $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
    ```
    You are all set! Now cdinto any git repository and use git cz instead of git commit and you will find the commitizen prompt some thing like this image:
    ![add-commit](https://raw.githubusercontent.com/commitizen/cz-cli/master/meta/screenshots/add-commit.png)
    ## Merging
  11. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 18 additions and 101 deletions.
    119 changes: 18 additions & 101 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,14 +8,13 @@ among the community.
    ## Table of contents

    1. [Branches](#branches)
    2. [Commits](#commits)
    1. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
    6. [Examples](#examples)
    7. [Misc.](#misc)
    1. [Changelog](#changelog)
    1. [Merging](#merging)
    1. [Release process](#release-process)
    1. [Misc.](#misc)

    ## Branches

    @@ -53,6 +52,10 @@ among the community.

    ## Commits

    We use [conventional commits](https://conventionalcommits.org/) and you must to tell your users that you adhere to the Conventional Commits specification:
    ```
    [![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org)
    ```
    * Each commit should be a single *logical change*. Don't make several
    *logical changes* in one commit. For example, if a patch fixes a bug and
    optimizes the performance of a feature, split it into two separate commits.
    @@ -130,27 +133,16 @@ among the community.
    ```text
    feat(Initializer): Initializers use ManagerRegistry
    Fixes: #1234, #4321
    See also: #12, #34
    Initializers are now passed an instance of `ManagerRegistry` instead
    of the `Phpcr\Session`. This means that initializers can retrieve both
    the PHPCR session and the `DocumentManager`.
    This PR also introduces a requirement that all initializers provide a name
    which can be used in diagnostics.
    BC Breaks
    ---------
    - The `init` method of the InitializerInterface now accepts a
    `ManagerResistry` instead of a `PhpcrSession`. The PHPCR session can
    be retrieved using `$registry->getConnection` and the manager with
    `$registry->getManager()`;
    - The `init` method of the InitializerInterface now accepts a `ManagerResistry` instead of a `PhpcrSession`. The PHPCR session can be retrieved using `$registry->getConnection` and the manager with `$registry->getManager()`;
    - The first argument to the `GenericInitializer` constructor is now the
    name of the initializer.
    Short (50 chars or fewer) summary of changes
    - The first argument to the `GenericInitializer` constructor is now the name of the initializer. Short (50 chars or fewer) summary of changes
    Fixes: #1234, #4321
    See also: #12, #34
    ```

    Ultimately, when writing a commit message, think about what you would need
    @@ -179,28 +171,18 @@ among the community.
    ```text
    <type>(<scope>): <short description>
    Fixes: <list of issues fixed>
    See also: <list of related issues>
    <long description>
    BC Breaks (as required)
    ---------
    [optional body]
    <list of BC breaks and required migrations>
    Deprecations (as required)
    ------------
    <list of deprecations>
    [optional footer]
    ```
    * `<scope>` is fully depend on your project and can be anything specifying place of the commit change. for example
    if you work on the Android project maybe your scope is: `<manifest|drawerLayout|...>`. to get fully supported
    scope in your project please contact to your team manager.
    * In `[footer]` you can reference the issue that was resolved or closes or related.

    * ###### Short Commit Message:
    Not all Pull Requests require this much information for the commit. In most cases, a more simpler commit convention is enough:
    ```nano
    ```text
    <type>(<scope>): <short description>
    ```

    @@ -256,7 +238,6 @@ among the community.
    $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
    ```
    You are all set! Now cdinto any git repository and use git cz instead of git commit and you will find the commitizen prompt some thing like this image:
    ![add-commit](https://raw.githubusercontent.com/commitizen/cz-cli/master/meta/screenshots/add-commit.png)
    ## Merging
    @@ -353,70 +334,6 @@ among the community.
    * [`git-prune(1)`](http://git-scm.com/docs/git-prune)
    * [`git-fsck(1)`](http://git-scm.com/docs/git-fsck)

    ## Examples

    1. Change url without any issue.
    ```sh
    feat [$browser]: onUrlChange event (popstate/hashchange/polling)
    Added new event to $browser:
    - forward popstate event if available
    - forward hashchange event if popstate not available
    - do polling when neither popstate nor hashchange available
    ```
    2. Fix issue #392.
    ```sh
    fix [$compile]: couple of unit tests for IE9
    Fixes: #392
    Older IEs serialize html uppercased, but IE9 does not...
    Would be better to expect case insensitive, unfortunately jasmine does
    not allow to user regexps for throw expectations. Closes
    ```
    3. Fully huge commit with big important breaking change.
    ```sh
    feat [$compile]: simplify isolate scope bindings
    Changed the isolate scope binding options to:
    - @attr - attribute binding (including interpolation)
    - =model - by-directional model binding
    - &expr - expression execution binding
    This change simplifies the terminology as well as
    number of choices available to the developer. It
    also supports local name aliasing from the parent.
    BC Breaks
    ---------
    isolate scope bindings definition has changed and the inject option for the directive controller injection was removed.
    To migrate the code follow the example below:
    Before:
    scope: {
    myAttr: 'attribute',
    myBind: 'bind',
    myExpression: 'expression',
    myEval: 'evaluate',
    myAccessor: 'accessor'
    }
    After:
    scope: {
    myAttr: '@',
    myBind: '@',
    myExpression: '&',
    // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
    myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }
    The removed `inject` wasn't generaly useful for directives so there should be no code using it.
    ```
    ## Workflow Diagram

    ![Git Branching Model](http://f.cl.ly/items/3i1Z3n1T1k392r1A3Q0m/gitflow-model.001.png)
  12. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -256,6 +256,7 @@ among the community.
    $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
    ```
    You are all set! Now cdinto any git repository and use git cz instead of git commit and you will find the commitizen prompt some thing like this image:
    ![add-commit](https://raw.githubusercontent.com/commitizen/cz-cli/master/meta/screenshots/add-commit.png)
    ## Merging
  13. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 39 additions and 6 deletions.
    45 changes: 39 additions & 6 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -128,7 +128,7 @@ among the community.
    corresponding issue in a bug tracker):

    ```text
    feat [Initializer]: Initializers use ManagerRegistry
    feat(Initializer): Initializers use ManagerRegistry
    Fixes: #1234, #4321
    See also: #12, #34
    @@ -177,7 +177,7 @@ among the community.
    * ###### Commit Message:
    The commit message should be formatted as follows:
    ```text
    <type> [<scope>]: <short description>
    <type>(<scope>): <short description>
    Fixes: <list of issues fixed>
    See also: <list of related issues>
    @@ -201,7 +201,7 @@ among the community.
    * ###### Short Commit Message:
    Not all Pull Requests require this much information for the commit. In most cases, a more simpler commit convention is enough:
    ```nano
    <type> [<scope>]: <short description>
    <type>(<scope>): <short description>
    ```

    Allowed types:
    @@ -219,10 +219,44 @@ among the community.
    ```shell
    $ git config --global commit.template ~/.git_commit_msg.txt
    ```
    Note: We can automatically generate commit message with using **Commitizen for contributors**. please see [Commitizen for contributors](#commitizen-for-contributors)

    ## Changelog


    Note: We will use [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) and [Commitizen for contributors](https://github.com/commitizen/cz-cli) to commit our changes in a right way by using angular commit conventions. The [Commitizen for contributors](https://github.com/commitizen/cz-cli) will generate our commits in a template that acceptable by [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) and help us to no more digging through CONTRIBUTING.md to find what the preferred format is and will generate our CHANGELOG.md automatically.

    * ##### [**Standard CHANGELOG**](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/standard-changelog)
    An opinionated approach to CHANGELOG generation using angular commit conventions.

    **Install:**
    ```sh
    $ npm install -g standard-changelog
    ```
    **usage:**
    your first release:
    If you're using this tool for the first time and want to generate new content in CHANGELOG.md, you can run:
    ```sh
    $ standard-changelog --first-release
    ```
    For normal usage you can execute just:
    ```sh
    $ standard-changelog
    ```
    * ##### [**Commitizen for contributors**](https://github.com/commitizen/cz-cli)
    After you install [Standard CHANGELOG](#standard-changelog) you can install as simple as running the following command
    ```sh
    $ npm install -g commitizen
    ```
    Install your preferred commitizen adapter globally, for example cz-conventional-changelog
    ```sh
    $ npm install -g cz-conventional-changelog
    ```
    Create a .czrc file in your home directory, with path referring to the preferred, globally installed, commitizen adapter with run this command in terminal:
    ```sh
    $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
    ```
    You are all set! Now cdinto any git repository and use git cz instead of git commit and you will find the commitizen prompt some thing like this image:
    ![add-commit](https://raw.githubusercontent.com/commitizen/cz-cli/master/meta/screenshots/add-commit.png)
    ## Merging
    @@ -286,10 +320,9 @@ among the community.

    * Example for version `v1.7.0`

    1. Bump the version in `lib/omniauth-saml/version.rb`
    1. Update [CHANGELOG.md](CHANGELOG.md) in root of project with `bundle exec conventional-changelog version=v1.7.0 since_version=v1.6.0`
    1. Commit all your changes
    1. Tag the latest commit with `git tag v1.7.0`
    1. Update [CHANGELOG.md](CHANGELOG.md) in root of project with `standard-changelog`
    1. Contact the maintainers

    ## Misc.
  14. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 9 additions and 0 deletions.
    9 changes: 9 additions & 0 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -70,6 +70,15 @@ among the community.
    * Commits should be ordered *logically*. For example, if *commit X* depends
    on changes done in *commit Y*, then *commit Y* should come before *commit X*.

    * Consider these messages as the instructions for what applying the commit will do. Rather than having a commit with the
    title:

    renamed the iVars and removed the common prefix

    Have one like this:

    rename the iVars to remove the common prefix

    * Use the imperative, present tense: "change" not "changed" nor "changes".

    * Don't capitalize first letter in commit title.
  15. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -119,7 +119,7 @@ among the community.
    corresponding issue in a bug tracker):

    ```text
    feat [Initializer] Initializers use ManagerRegistry
    feat [Initializer]: Initializers use ManagerRegistry
    Fixes: #1234, #4321
    See also: #12, #34
    @@ -168,7 +168,7 @@ among the community.
    * ###### Commit Message:
    The commit message should be formatted as follows:
    ```text
    <type> [<scope>] <short description>
    <type> [<scope>]: <short description>
    Fixes: <list of issues fixed>
    See also: <list of related issues>
    @@ -192,7 +192,7 @@ among the community.
    * ###### Short Commit Message:
    Not all Pull Requests require this much information for the commit. In most cases, a more simpler commit convention is enough:
    ```nano
    <type> [<scope>] <short description>
    <type> [<scope>]: <short description>
    ```

    Allowed types:
    @@ -333,7 +333,7 @@ among the community.
    ```
    3. Fully huge commit with big important breaking change.
    ```sh
    feat($compile): simplify isolate scope bindings
    feat [$compile]: simplify isolate scope bindings
    Changed the isolate scope binding options to:
    - @attr - attribute binding (including interpolation)
  16. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -344,7 +344,7 @@ among the community.
    number of choices available to the developer. It
    also supports local name aliasing from the parent.
    BC Breaks:
    BC Breaks
    ---------
    isolate scope bindings definition has changed and the inject option for the directive controller injection was removed.
  17. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -344,9 +344,9 @@ among the community.
    number of choices available to the developer. It
    also supports local name aliasing from the parent.
    BC Breaks: isolate scope bindings definition has changed and
    -------------------------------------------------------------
    the inject option for the directive controller injection was removed.
    BC Breaks:
    ---------
    isolate scope bindings definition has changed and the inject option for the directive controller injection was removed.
    To migrate the code follow the example below:
  18. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 45 additions and 3 deletions.
    48 changes: 45 additions & 3 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -317,9 +317,9 @@ among the community.
    feat [$browser]: onUrlChange event (popstate/hashchange/polling)
    Added new event to $browser:
    - forward popstate event if available
    - forward hashchange event if popstate not available
    - do polling when neither popstate nor hashchange available
    - forward popstate event if available
    - forward hashchange event if popstate not available
    - do polling when neither popstate nor hashchange available
    ```
    2. Fix issue #392.
    ```sh
    @@ -331,6 +331,48 @@ among the community.
    Would be better to expect case insensitive, unfortunately jasmine does
    not allow to user regexps for throw expectations. Closes
    ```
    3. Fully huge commit with big important breaking change.
    ```sh
    feat($compile): simplify isolate scope bindings
    Changed the isolate scope binding options to:
    - @attr - attribute binding (including interpolation)
    - =model - by-directional model binding
    - &expr - expression execution binding
    This change simplifies the terminology as well as
    number of choices available to the developer. It
    also supports local name aliasing from the parent.
    BC Breaks: isolate scope bindings definition has changed and
    -------------------------------------------------------------
    the inject option for the directive controller injection was removed.
    To migrate the code follow the example below:
    Before:
    scope: {
    myAttr: 'attribute',
    myBind: 'bind',
    myExpression: 'expression',
    myEval: 'evaluate',
    myAccessor: 'accessor'
    }
    After:
    scope: {
    myAttr: '@',
    myBind: '@',
    myExpression: '&',
    // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
    myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.
    ```
    ## Workflow Diagram
  19. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 24 additions and 1 deletion.
    25 changes: 24 additions & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -14,7 +14,8 @@ among the community.
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
    6. [Misc.](#misc)
    6. [Examples](#examples)
    7. [Misc.](#misc)

    ## Branches

    @@ -309,6 +310,28 @@ among the community.
    * [`git-prune(1)`](http://git-scm.com/docs/git-prune)
    * [`git-fsck(1)`](http://git-scm.com/docs/git-fsck)
    ## Examples
    1. Change url without any issue.
    ```sh
    feat [$browser]: onUrlChange event (popstate/hashchange/polling)
    Added new event to $browser:
    - forward popstate event if available
    - forward hashchange event if popstate not available
    - do polling when neither popstate nor hashchange available
    ```
    2. Fix issue #392.
    ```sh
    fix [$compile]: couple of unit tests for IE9
    Fixes: #392
    Older IEs serialize html uppercased, but IE9 does not...
    Would be better to expect case insensitive, unfortunately jasmine does
    not allow to user regexps for throw expectations. Closes
    ```
    ## Workflow Diagram
    ![Git Branching Model](http://f.cl.ly/items/3i1Z3n1T1k392r1A3Q0m/gitflow-model.001.png)
  20. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -185,7 +185,7 @@ among the community.
    <list of deprecations>
    ```
    * `<scope>` is fully depend on your project and can be anything specifying place of the commit change. for example
    if you work on the Android project maybe your scope is: `<Manifest|DrawerLayout|...>`. to get fully supported
    if you work on the Android project maybe your scope is: `<manifest|drawerLayout|...>`. to get fully supported
    scope in your project please contact to your team manager.

    * ###### Short Commit Message:
  21. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -184,7 +184,9 @@ among the community.
    <list of deprecations>
    ```
    * `<scope>` is fully depend on your project. for example if you work on the Android project maybe your scope is: `<Manifest|DrawerLayout|...>`. to get fully supported scope in your project please contact to your team manager.
    * `<scope>` is fully depend on your project and can be anything specifying place of the commit change. for example
    if you work on the Android project maybe your scope is: `<Manifest|DrawerLayout|...>`. to get fully supported
    scope in your project please contact to your team manager.

    * ###### Short Commit Message:
    Not all Pull Requests require this much information for the commit. In most cases, a more simpler commit convention is enough:
  22. mjavadhpour revised this gist Oct 19, 2017. 1 changed file with 12 additions and 6 deletions.
    18 changes: 12 additions & 6 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -69,6 +69,12 @@ among the community.
    * Commits should be ordered *logically*. For example, if *commit X* depends
    on changes done in *commit Y*, then *commit Y* should come before *commit X*.

    * Use the imperative, present tense: "change" not "changed" nor "changes".

    * Don't capitalize first letter in commit title.

    * No dot (.) at the end.

    Note: While working alone on a local branch that *has not yet been pushed*, it's
    fine to use commits as temporary snapshots of your work. However, it still
    holds true that you should apply all of the above *before* pushing it.
    @@ -266,13 +272,13 @@ among the community.
    ```
    ## Release process
    Example for version `v1.7.0`
    * Example for version `v1.7.0`
    1. Bump the version in `lib/omniauth-saml/version.rb`
    1. Update [CHANGELOG.md](CHANGELOG.md) in root of project with `bundle exec conventional-changelog version=v1.7.0 since_version=v1.6.0`
    1. Commit all your changes
    1. Tag the latest commit with `git tag v1.7.0`
    1. Contact the maintainers
    1. Bump the version in `lib/omniauth-saml/version.rb`
    1. Update [CHANGELOG.md](CHANGELOG.md) in root of project with `bundle exec conventional-changelog version=v1.7.0 since_version=v1.6.0`
    1. Commit all your changes
    1. Tag the latest commit with `git tag v1.7.0`
    1. Contact the maintainers
    ## Misc.
  23. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,8 +9,8 @@ among the community.

    1. [Branches](#branches)
    2. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
  24. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,8 +9,8 @@ among the community.

    1. [Branches](#branches)
    2. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
  25. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -19,6 +19,7 @@ among the community.
    ## Branches

    * Quick Legend:

    |Instance | Branch | Description, Instructions, Notes|
    |---------|---------|-------------------------------------|
    |Stable | stable | Accepts merges from Working and Hotfixes|
    @@ -27,6 +28,7 @@ among the community.
    |Hotfix | hotfix-* | Always branch off Stable|

    * Conventions:

    | Description|Good example|Bad example|
    |------------|------------|-----------|
    |Choose *short* and *descriptive* names|oauth-migration|login_fix|
  26. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@

    # My Git Convention And Style Guide:
    # Nikmodern Git Convention And Style Guide:

    This is a Git Style Guide inspired by [*How to Get Your Change Into the LinuxKernel*](https://kernel.org/doc/html/latest/process/submitting-patches.html),
    the [git man pages](http://git-scm.com/doc) and various practices popular
  27. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -9,8 +9,8 @@ among the community.

    1. [Branches](#branches)
    2. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
  28. mjavadhpour revised this gist Oct 17, 2017. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nikmodern-git-convention-and-style-guide.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@

    # Nikmodern Git Convention And Style Guide:
    # My Git Convention And Style Guide:

    This is a Git Style Guide inspired by [*How to Get Your Change Into the LinuxKernel*](https://kernel.org/doc/html/latest/process/submitting-patches.html),
    the [git man pages](http://git-scm.com/doc) and various practices popular
  29. mjavadhpour renamed this gist Oct 17, 2017. 1 changed file with 0 additions and 0 deletions.
    0 nikmodern-git-convention-and-style-guide → nikmodern-git-convention-and-style-guide.md
    View file
    File renamed without changes.
  30. mjavadhpour created this gist Oct 17, 2017.
    304 changes: 304 additions & 0 deletions nikmodern-git-convention-and-style-guide
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,304 @@

    # Nikmodern Git Convention And Style Guide:

    This is a Git Style Guide inspired by [*How to Get Your Change Into the LinuxKernel*](https://kernel.org/doc/html/latest/process/submitting-patches.html),
    the [git man pages](http://git-scm.com/doc) and various practices popular
    among the community.

    ## Table of contents

    1. [Branches](#branches)
    2. [Commits](#commits)
    2-1. [Messages](#messages)
    2-2. [Template](#template)
    3. [Changelog](#changelog)
    4. [Merging](#merging)
    5. [Release process](#release-process)
    6. [Misc.](#misc)

    ## Branches

    * Quick Legend:
    |Instance | Branch | Description, Instructions, Notes|
    |---------|---------|-------------------------------------|
    |Stable | stable | Accepts merges from Working and Hotfixes|
    |Working | master | Accepts merges from Features/Issues and Hotfixes|
    |Features/Issues | topic-* | Always branch off HEAD of Working|
    |Hotfix | hotfix-* | Always branch off Stable|

    * Conventions:
    | Description|Good example|Bad example|
    |------------|------------|-----------|
    |Choose *short* and *descriptive* names|oauth-migration|login_fix|
    |Use *hyphens* to separate words|branch-name|branchName, branch name, branch_name|
    |When several people are working on the *same* feature, it might be convenient to have *personal* feature branches and a *team-wide* feature branch.|feature-a/master, feature-a/maria, feature-a/nick| - |

    Merge at will the personal branches to the team-wide branch (see ["Merging"](#merging)).
    Eventually, the team-wide branch will be merged to "master".

    * Delete your branch from the upstream repository after it's merged, unless
    there is a specific reason not to.

    **Required**: If you working with [GitLab Issues Functionalities](https://docs.gitlab.com/ce/user/project/issues/index.html#gitlab-issues-functionalities) issue name used for branch name, then you must regard to [Quick Legend](#Quick-Legend) in issue title.

    Tip: Use the following command while being on "master", to list merged
    branches:

    ```shell
    $ git branch --merged | grep -v "\*"
    ```

    ## Commits

    * Each commit should be a single *logical change*. Don't make several
    *logical changes* in one commit. For example, if a patch fixes a bug and
    optimizes the performance of a feature, split it into two separate commits.

    *Tip: Use `git add -p` to interactively stage specific portions of the
    modified files.*

    * Don't split a single *logical change* into several commits. For example,
    the implementation of a feature and the corresponding tests should be in the
    same commit.

    * Commit *early* and *often*. Small, self-contained commits are easier to
    understand and revert when something goes wrong.

    * Commits should be ordered *logically*. For example, if *commit X* depends
    on changes done in *commit Y*, then *commit Y* should come before *commit X*.

    Note: While working alone on a local branch that *has not yet been pushed*, it's
    fine to use commits as temporary snapshots of your work. However, it still
    holds true that you should apply all of the above *before* pushing it.

    * ### Messages

    * Use the editor, not the terminal, when writing a commit message:

    ```sh
    # good
    $ git commit

    # bad
    $ git commit -m "Quick fix"
    ```

    Committing from the terminal encourages a mindset of having to fit everything
    in a single line which usually results in non-informative, ambiguous commit
    messages.

    * The summary line (ie. the first line of the message) should be
    *descriptive* yet *succinct*. Ideally, it should be no longer than
    *50 characters*. It should be capitalized and written in imperative present
    tense. It should not end with a period since it is effectively the commit
    *title*:

    ```shell
    # good - imperative present tense, capitalized, fewer than 50 characters
    Mark huge records as obsolete when clearing hinting faults

    # bad
    fixed ActiveModel::Errors deprecation messages failing when AR was used outside of Rails.
    ```

    * After that should come a blank line followed by a more thorough
    description. It should be wrapped to *72 characters* and explain *why*
    the change is needed, *how* it addresses the issue and what *side-effects*
    it might have.

    It should also provide any pointers to related resources (eg. link to the
    corresponding issue in a bug tracker):

    ```text
    feat [Initializer] Initializers use ManagerRegistry

    Fixes: #1234, #4321
    See also: #12, #34

    Initializers are now passed an instance of `ManagerRegistry` instead
    of the `Phpcr\Session`. This means that initializers can retrieve both
    the PHPCR session and the `DocumentManager`.

    This PR also introduces a requirement that all initializers provide a name
    which can be used in diagnostics.

    BC Breaks
    ---------

    - The `init` method of the InitializerInterface now accepts a
    `ManagerResistry` instead of a `PhpcrSession`. The PHPCR session can
    be retrieved using `$registry->getConnection` and the manager with
    `$registry->getManager()`;

    - The first argument to the `GenericInitializer` constructor is now the
    name of the initializer.
    Short (50 chars or fewer) summary of changes
    ```

    Ultimately, when writing a commit message, think about what you would need
    to know if you run across the commit in a year from now.

    * If a *commit A* depends on *commit B*, the dependency should be
    stated in the message of *commit A*. Use the SHA1 when referring to
    commits.

    Similarly, if *commit A* solves a bug introduced by *commit B*, it should
    also be stated in the message of *commit A*.

    * If a commit is going to be squashed to another commit use the `--squash` and
    `--fixup` flags respectively, in order to make the intention clear:

    ```shell
    $ git commit --squash f387cab2
    ```

    *(Tip: Use the `--autosquash` flag when rebasing. The marked commits will be
    squashed automatically.)*

    * ### Template
    * ###### Commit Message:
    The commit message should be formatted as follows:
    ```text
    <type> [<scope>] <short description>

    Fixes: <list of issues fixed>
    See also: <list of related issues>

    <long description>

    BC Breaks (as required)
    ---------

    <list of BC breaks and required migrations>

    Deprecations (as required)
    ------------

    <list of deprecations>
    ```
    * `<scope>` is fully depend on your project. for example if you work on the Android project maybe your scope is: `<Manifest|DrawerLayout|...>`. to get fully supported scope in your project please contact to your team manager.

    * ###### Short Commit Message:
    Not all Pull Requests require this much information for the commit. In most cases, a more simpler commit convention is enough:
    ```nano
    <type> [<scope>] <short description>
    ```

    Allowed types:

    * **feat**: A new feature (refers to `MINOR` in [SemVer](http://semver.org/))
    * **fix**: A bug fix (refers to `PATCH` in [SemVer](http://semver.org/))
    * **docs**: Documentation only changes
    * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, newline, line endings, etc)
    * **refactor**: A code change that neither fixes a bug or adds a feature (refers to `MAJOR` in [SemVer](http://semver.org/))
    * **perf**: A code change that improves performance
    * **test**: Adding missing tests
    * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation

    You can set git template globally with runnig this command:
    ```shell
    $ git config --global commit.template ~/.git_commit_msg.txt
    ```

    ## Changelog



    ## Merging

    Note: If you are not *project manager* you can skip this step.

    * **Do not rewrite published history.** The repository's history is valuable in
    its own right and it is very important to be able to tell *what actually
    happened*. Altering published history is a common source of problems for
    anyone working on the project.

    * However, there are cases where rewriting history is legitimate. These are
    when:

    * You are the only one working on the branch and it is not being reviewed.

    * You want to tidy up your branch (eg. squash commits) and/or rebase it onto
    the "master" in order to merge it later.

    That said, *never rewrite the history of the "master" branch* or any other
    special branches (ie. used by production or CI servers).

    * Keep the history *clean* and *simple*. *Just before you merge* your branch:

    1. Make sure it conforms to the style guide and perform any needed actions
    if it doesn't (squash/reorder commits, reword messages etc.)

    2. Rebase it onto the branch it's going to be merged to:

    ```shell
    [my-branch] $ git fetch
    [my-branch] $ git rebase origin/master
    # then merge
    ```

    This results in a branch that can be applied directly to the end of the
    "master" branch and results in a very simple history.

    *(Note: This strategy is better suited for projects with short-running
    branches. Otherwise it might be better to occassionally merge the
    "master" branch instead of rebasing onto it.)*

    * If your branch includes more than one commit, do not merge with a
    fast-forward:

    ```shell
    # good - ensures that a merge commit is created
    $ git merge --no-ff my-branch

    # bad
    $ git merge my-branch
    ```

    Useful command:
    ```shell
    $ git checkout master // change to the master branch
    $ git merge --no-ff feature-id // makes sure to create a commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :feature-id // deletes the remote branch
    ```
    ## Release process

    Example for version `v1.7.0`

    1. Bump the version in `lib/omniauth-saml/version.rb`
    1. Update [CHANGELOG.md](CHANGELOG.md) in root of project with `bundle exec conventional-changelog version=v1.7.0 since_version=v1.6.0`
    1. Commit all your changes
    1. Tag the latest commit with `git tag v1.7.0`
    1. Contact the maintainers

    ## Misc.

    * There are various workflows and each one has its strengths and weaknesses.
    Whether a workflow fits your case, depends on the team, the project and your
    development procedures.

    That said, it is important to actually *choose* a workflow and stick with it.

    * *Be consistent.* This is related to the workflow but also expands to things
    like commit messages, branch names and tags. Having a consistent style
    throughout the repository makes it easy to understand what is going on by
    looking at the log, a commit message etc.

    * *Test before you push.* Do not push half-done work.

    * Use [annotated tags](http://git-scm.com/book/en/v2/Git-Basics-Tagging#Annotated-Tags)
    for marking releases or other important points in the history. Prefer
    [lightweight tags](http://git-scm.com/book/en/v2/Git-Basics-Tagging#Lightweight-Tags)
    for personal use, such as to bookmark commits for future reference.

    * Keep your repositories at a good shape by performing maintenance tasks
    occasionally:

    * [`git-gc(1)`](http://git-scm.com/docs/git-gc)
    * [`git-prune(1)`](http://git-scm.com/docs/git-prune)
    * [`git-fsck(1)`](http://git-scm.com/docs/git-fsck)

    ## Workflow Diagram

    ![Git Branching Model](http://f.cl.ly/items/3i1Z3n1T1k392r1A3Q0m/gitflow-model.001.png)