|
| 1 | +## Pull requests |
| 2 | + |
| 3 | +Please adhere to the coding conventions used throughout the project. If in doubt, consult the |
| 4 | +[Effective Go](https://golang.org/doc/effective_go.html) style guide. |
| 5 | + |
| 6 | +Adhering to the following process is the best way to get your work included in the project: |
| 7 | + |
| 8 | +1. [Fork](https://help.github.com/articles/fork-a-repo/) the project, clone your fork, and configure |
| 9 | + the remotes: |
| 10 | + |
| 11 | + ```bash |
| 12 | + # Clone your fork of the repo into the current directory |
| 13 | + git clone https://github.com/intel-samples/langchain-samples.git |
| 14 | + |
| 15 | + # Navigate to the newly cloned directory |
| 16 | + cd langchain-samples |
| 17 | + |
| 18 | + # Assign the original repo to a remote called "upstream" |
| 19 | + git remote add upstream https://github.com/intel-samples/langchain-samples.git |
| 20 | + ``` |
| 21 | + |
| 22 | +2. If you cloned a while ago, get the latest changes from upstream: |
| 23 | + |
| 24 | + ```bash |
| 25 | + git checkout main |
| 26 | + git pull --rebase upstream main |
| 27 | + ``` |
| 28 | + |
| 29 | +3. Create a new issue branch from `main` using the naming convention `I-[issue-number]` to |
| 30 | + help us keep track of your contribution scope: |
| 31 | + |
| 32 | + ```bash |
| 33 | + git checkout -b I-[issue-number] |
| 34 | + ``` |
| 35 | + |
| 36 | +4. Commit your changes in logical chunks. When you are ready to commit, make sure to write a Good |
| 37 | + Commit Message™ by consulting the [Commit Message Guidelines](#commit-message-guidelines) following the conventional commit standard. |
| 38 | + |
| 39 | + |
| 40 | + Note that every commit you make must be signed. By signing off your work you indicate that you |
| 41 | + are accepting the [Developer Certificate of Origin](https://developercertificate.org/). |
| 42 | + |
| 43 | + Use your real name (sorry, no pseudonyms or anonymous contributions). If you set your `user.name` |
| 44 | + and `user.email` git configs, you can sign your commit automatically with `git commit -s`. |
| 45 | + |
| 46 | +5. Locally merge (or rebase) the upstream development branch into your issue branch: |
| 47 | + |
| 48 | + ```bash |
| 49 | + git pull --rebase upstream main |
| 50 | + ``` |
| 51 | + |
| 52 | +6. Push your issue branch up to your fork: |
| 53 | + |
| 54 | + ```bash |
| 55 | + git push origin I-[issue-number] |
| 56 | + ``` |
| 57 | + |
| 58 | +7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title |
| 59 | + and detailed description. |
| 60 | + |
| 61 | +## Pull Requests practices |
| 62 | + |
| 63 | +* PR author is responsible to merge its own PR after review has been done and CI has passed. |
| 64 | +* When merging, make sure git linear history is preserved. PR author should select a merge option (`Rebase and merge` or `Squash and merge`) based on which option will fit the best to the git linear history. |
| 65 | +* PR topic should follow the same guidelines as the header of the [Git Commit Message](#commit-message-format) |
| 66 | + |
| 67 | +## <a name="commit"></a> Commit Message Guidelines |
| 68 | + |
| 69 | +The git commit messages for this project follow the conventional commit format guideline. This leads to more readable messages that are easy to follow when looking through the project history. |
| 70 | + |
| 71 | +### Commit Message Format |
| 72 | +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: |
| 73 | + |
| 74 | +``` |
| 75 | +<type>(<scope>): <subject> |
| 76 | +<BLANK LINE> |
| 77 | +<body> |
| 78 | +<BLANK LINE> |
| 79 | +<footer> |
| 80 | +``` |
| 81 | + |
| 82 | +The **header** with **type** is mandatory. The **scope** of the header is optional as far as the automated PR checks are concerned, but be advised that PR reviewers **may request** you provide an applicable scope. |
| 83 | + |
| 84 | +Any line of the commit message should not be longer 72 characters! This allows the message to be easier to read on GitHub as well as in various git tools. |
| 85 | + |
| 86 | +The footer should contain a reference to an Azure Boards ticket (e.g. AB#[number]). |
| 87 | + |
| 88 | +Example 1: |
| 89 | +``` |
| 90 | +feat(telemetry): Add new MQTT events |
| 91 | +
|
| 92 | +Events are now emitted over various /mps topics on MQTT for success/failures |
| 93 | +as they occur throughout the service. |
| 94 | +
|
| 95 | +Resolves: AB#2222 |
| 96 | +``` |
| 97 | + |
| 98 | + |
| 99 | +### Revert |
| 100 | +If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
| 101 | + |
| 102 | +### Type |
| 103 | + |
| 104 | +Must be one of the following: |
| 105 | + |
| 106 | +* **feat**: A new feature |
| 107 | +* **fix**: A bug fix |
| 108 | +* **docs**: Documentation only changes |
| 109 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc) |
| 110 | +* **refactor**: A code change that neither fixes a bug nor adds a feature |
| 111 | +* **perf**: A code change that improves performance |
| 112 | +* **test**: Adding missing tests or correcting existing tests |
| 113 | +* **build**: Changes that affect the CI/CD pipeline or build system or external dependencies (example scopes: travis, jenkins, makefile) |
| 114 | +* **ci**: Changes provided by DevOps for CI purposes. |
| 115 | +* **revert**: Reverts a previous commit. |
| 116 | + |
| 117 | +### Scope |
| 118 | + |
| 119 | +Should be one of the following: |
| 120 | +Modules: |
| 121 | +* **cli**: A change or addition to application interface |
| 122 | +* **config**: A change or addition to service configuration |
| 123 | +* **deps**: A change or addition to dependencies (primarily used by dependabot) |
| 124 | +* **deps-dev**: A change or addition to developer dependencies (primarily used by dependabot) |
| 125 | +* **docker**: A change or addition to docker file or composition |
| 126 | +* **gh-actions**: A change or addition to GitHub actions |
| 127 | +* **heci**: A change or addition to heci functionality |
| 128 | +* **lib**: A change or addition that affects RPC built as a library |
| 129 | +* **lme**: A change or addition to local management engine functionality |
| 130 | +* **lms**: A change or addition to local management service functionality |
| 131 | +* **lmx**: A change or addition to both lme and lms functionality |
| 132 | +* **pthi**: A change or addition to pthi functionality |
| 133 | +* **rps**: A change or addition to interactions with Remote Provisioning Server |
| 134 | +* **sample**: A change or addition to the sample application |
| 135 | +* **utils**: A change or addition to the utility functions |
| 136 | +* *no scope*: If no scope is provided, it is assumed the PR does not apply to the above scopes |
| 137 | + |
| 138 | +### Body |
| 139 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". |
| 140 | +Here is detailed guideline on how to write the body of the commit message ([Reference](https://chris.beams.io/posts/git-commit/)): |
| 141 | +``` |
| 142 | +More detailed explanatory text, if necessary. Wrap it to about 72 |
| 143 | +characters or so. In some contexts, the first line is treated as the |
| 144 | +subject of the commit and the rest of the text as the body. The |
| 145 | +blank line separating the summary from the body is critical (unless |
| 146 | +you omit the body entirely); various tools like `log`, `shortlog` |
| 147 | +and `rebase` can get confused if you run the two together. |
| 148 | +
|
| 149 | +Explain the problem that this commit is solving. Focus on why you |
| 150 | +are making this change as opposed to how (the code explains that). |
| 151 | +Are there side effects or other unintuitive consequences of this |
| 152 | +change? Here's the place to explain them. |
| 153 | +
|
| 154 | +Further paragraphs come after blank lines. |
| 155 | +
|
| 156 | + - Bullet points are okay, too |
| 157 | +
|
| 158 | + - Typically a hyphen or asterisk is used for the bullet, preceded |
| 159 | + by a single space, with blank lines in between, but conventions |
| 160 | + vary here |
| 161 | +``` |
| 162 | + |
| 163 | +### Footer |
| 164 | + |
| 165 | +The footer should contain a reference to JIRA ticket (e.g. SL6-0000) that this commit **Closes** or **Resolves**. |
| 166 | +The footer should contain any information about **Breaking Changes**. |
| 167 | + |
| 168 | +**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. |
0 commit comments