Last active
August 1, 2022 18:11
-
-
Save titenkov/df7a63e9508458172e1d0128afdfee8b to your computer and use it in GitHub Desktop.
Revisions
-
titenkov revised this gist
Aug 1, 2022 . 1 changed file with 3 additions and 55 deletions.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -95,14 +95,11 @@ and create a clean rebased history. ## Give branches meaningful names Feature branch name format should follow this convention: ``` <type>/<short-description> F.e. docs/contribution-guide chore/fix-artifact-publishing ``` @@ -114,53 +111,4 @@ Should be one of the following: * **chore**: End-user not noticible change (f.e. CI/build changes or tests) * **docs**: Documentation change * **feature**: A new feature * **defect**: A bug fix -
Aug 1, 2022 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,166 @@ This file contains guidelines that should be followed when making any changes to the repository. # The basics This repository is using Trunk Based Development approach - a branching model that focuses on collaborating through a single `main` branch. Read more about Trunk Based Development - [https://trunkbaseddevelopment.com](https://trunkbaseddevelopment.com). ## Every `main` branch commit is releasable Code in `main` branch should be releasable at any point of time. If you're introducing any breaking changes, ensure they are hidden under the feature toggles. ## Ensure the quality of the code before pushing it to the `main` You need to verify that the code follows the guidelines, all tests are passed before you push any changes to `main`. Your code should also be covered with automated tests. ## Fix the build of `main` branch immediately or revert the change Sometimes build can fail after you pushed your changes directly into main. You need to either fix the build immediately or revert your changes, so that you do not block others. # Pull requests The repository uses "Ship/Show/Ask" pull request strategy ([https://martinfowler.com/articles/ship-show-ask.html](https://martinfowler.com/articles/ship-show-ask.html)). ## Ship If you want to make a change, which is small and obvious, doesn't require code review or mention in automatic release notes - push it directly to `main`. ## Show If you want to make a change, which doesn't require code review, but worth mentioning in automatic release notes or other developers be aware of - push it to your branch, open a pull request and merge it without waiting for a review. You’ll want to wait for your automated checks (tests, code coverage, etc.), but you don’t wait for anyone’s feedback. ## Ask If you want to make a change, which you're not fully confident in or have some related questions - push it to your branch, open a pull request and wait for feedback. Maybe you're not sure you’ve taken the right approach. Maybe there’s some code you’re not quite happy with but you’re unsure how to improve it. Maybe you’ve done an experiment and want to see what people think. ## The rules - Approvals are not required to merge the pull request - People get to merge their own pull requests - Make use of CI/CD techniques to keep `main` releasable (f.e. feature toggles) - Branches and pull requests should not live long and should rebase on `main` often - Strive to small and self-contained pull requests # Releases Release can be made from any commit on the `main` branch. In order to make a release, navigate to `Releases` tab on `Github`. There you will be able to see the draft-release, generated automatically from the merged pull-requests history. Feel free to edit it and publish - git tag will be published automatically. ## Versioning The repository is using semantic versioning ([https://semver.org/](https://semver.org/)). Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. # Git hygiene To ensure we have a readable history in our Git repositories we try to follow some basic principles when working with Git. ## Break changes into logical commits A commit should be self-contained and tell a story. ## Keep changes that refactor code in their own commits This allows reviewers to understand your changes in context. ## Rebase and avoid merge-commits Continually rebase your branch, and avoid merge-commits. Ensure you are always up to date with the base branch by rebasing frequently. By doing this you ensure that your changes work and integrates well with the latest changes in the base repository. If you have accidentally merged, learn how to modify your branch history and create a clean rebased history. ## Give branches meaningful names Feature branch name format should follow this convention. It's not required to specify the JIRA number, if you don't have it. ``` <type>/IP-<jira-number>-<short-description> F.e. feature/IP-101-customers-api defect/IP-102 docs/contribution-guide chore/fix-artifact-publishing ``` Type Should be one of the following: * **chore**: End-user not noticible change (f.e. CI/build changes or tests) * **docs**: Documentation change * **feature**: A new feature * **defect**: A bug fix ## Write proper commit messages In order to easier read commit history, your commits should follow this structure: ``` IP-123 Short summary │ │ │ └─⫸ Summary in present tense. | Not capitalized. | Wrap it to 72 characters. │ └─⫸ Commit scope is the JIRA number or none/empty string More detailed explanatory text. Wrap it to 72 characters. The blank line separating the summary from the body is critical (unless you omit the body entirely). Further paragraphs come after blank lines. - Bullet points are okay, too. - Typically a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent. ``` A properly formed git commit subject line should always be able to complete the following sentence > If applied, this commit will `<your subject line here>` Examples: ``` IP-123 Introduce create customer api ``` ### Rules for a great git commit message style * Use the relevant Jira number where applicable * Separate subject from body with a blank line * Do not end the subject line with a period * Capitalize the subject line and each paragraph * Use the imperative mood in the subject line * Wrap lines at 72 characters * Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made Good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages