github.com/seilagamo/poc-lava-release@v0.3.3-rc3/CONTRIBUTING.md (about)

     1  # Contributing
     2  
     3  **This project is in an early stage, we are not accepting external
     4  contributions yet.**
     5  
     6  ## Workflow
     7  
     8  The recommended workflow is feature branching.
     9  That means that new features are developed in branches that are merged
    10  to main once they are tested, reviewed and considered stable.
    11  
    12  Small, short-lived and self-contained feature branches along with
    13  small pull requests are recommended.
    14  Feature flags are helpful to avoid having very long lived branches
    15  that can be sometimes hard to merge, depending on how quickly the main
    16  branch is updated.
    17  
    18  The main branch of this repository is protected.
    19  No one is allowed to push directly to main.
    20  
    21  ## Commit messages
    22  
    23  Commit messages in this project follow a specific set of conventions,
    24  which we discuss in this section.
    25  
    26  ```
    27  Header line: explain the commit in one line (use the imperative)
    28  
    29  Body of commit message is a few lines of text, explaining things
    30  in more detail, possibly giving some background about the issue
    31  being fixed, etc.
    32  
    33  The body of the commit message can be several paragraphs, and
    34  please do proper word-wrap and keep columns shorter than about
    35  74 characters or so. That way "git log" will show things
    36  nicely even when it's indented.
    37  
    38  Make sure you explain your solution and why you're doing what you're
    39  doing, as opposed to describing what you're doing. Reviewers and your
    40  future self can read the patch, but might not understand why a
    41  particular solution was implemented.
    42  ```
    43  
    44  The header line of the commit must be prefixed by the primary affected
    45  component followed by colon.
    46  
    47  The body of the commit can be omitted if the header line describes the
    48  change well enough and the pull request message contains the missing
    49  details.
    50  
    51  ## Pull requests
    52  
    53  Similarly to what happens with commit messages, pull requests follow a
    54  specific set of conventions.
    55  
    56  The title must explain the pull request in one line (use the
    57  imperative) and must be prefixed by the primary affected component
    58  followed by colon.
    59  
    60  The body of the pull request is a few lines of text, explaining things
    61  in more detail, possibly giving some background about the issue being
    62  fixed, etc.
    63  
    64  Make sure you explain your solution and why you're doing what you're
    65  doing, as opposed to describing what you're doing.
    66  Reviewers and your future self can read the patch, but might not
    67  understand why a particular solution was implemented.
    68  
    69  Pull requests must be in a "mergeable" state, pass all the automatic
    70  checks and receive at least +1 from the reviewers before being merged.
    71  
    72  When merging pull requests, using merge commits is mandatory.
    73  That means that the commit history of the pull request must be
    74  meaningful and clean.