Skip to content
Snippets Groups Projects
Commit 8aac87bd authored by Nick Laurenson's avatar Nick Laurenson
Browse files

[doc] Add contribution.md and .gitmessage template

fix #29
parent 299d6c91
No related branches found
No related tags found
1 merge request!132[doc] Add contribution.md and .gitmessage template
Pipeline #200493 failed
Pipeline: LidarView

#200494

    # Contribution to LidarView and Co.
    ## Commit convention
    Developers are encouraged to use the provided [gitmessage template](Documentation/.gitmessage) in their [git configuration](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_commit_template), so every commit message follows the same convention.
    ```bash
    $ git config --global commit.template <LVCore_path>/Documentation/.gitmessage
    ```
    Adopting a commit convention, has multiple advantages:
    * enforce coherence
    * force to have atomic commits
    * enable to parse automatically commit messages
    * quickly see if a submodule upgrade could be done easily (no api break, no default value change, ...)
    * and many more ...
    \ No newline at end of file
    # [<tag>] (If applied, this commit will...) <subject> (Max 72 char)
    # |<---- Preferably using up to 50 chars --->|<------------------->|
    # Example:
    # [feat] Implement automated commit messages
    # (Optional) Explain why this change is being made
    # |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->|
    # (Optional) Provide links or keys to any relevant tickets, articles or other resources
    # Example: fix #23
    # --- COMMIT END ---
    # Remember to:
    # * Capitalize the subject line
    # * Use the imperative mood in the subject line
    # * Do not end the subject line with a period
    # * Separate subject from body with a blank line
    # * Use the body to explain what and why vs. how
    # * Can use multiple lines with "-" or "*" for bullet points in body
    # --------------------
    # Tag can be
    #
    # feat (new feature)
    # fix (bug fix)
    # ci (change to ci scripts)
    # refactor (refactoring code)
    # deprec (deprecate or remove deprecated code)
    # style (formatting, missing semi colons, etc; no code change)
    # doc (changes to documentation)
    # test (adding or refactoring tests; no production code change)
    # version (version bump/new release; no production code change)
    # license (edits regarding licensing; no production code change)
    # perf (improve code performance)
    # defaults (changes default options)
    # submodule (update one or several submodules)
    # api (break the public api)
    # ui (user interface change)
    #
    # Please avoid the following, but in case none of the above fit:
    #
    # hack (temporary fix to make things move forward)
    # change (in case none of them work)
    # --------------------
    # Credit && Resources:
    # https://www.conventionalcommits.org/en/v1.0.0/#specification
    # https://gitmoji.carloscuesta.me/
    # https://gist.github.com/zakkak/7e06725ebd1336bfebebe254de3de825
    0% Loading or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Finish editing this message first!
    Please register or to comment