|
| 1 | + |
| 2 | +# Contributing to terraform-provider-tanzu-mission-control |
| 3 | + |
| 4 | +The terraform-provider-tanzu-mission-control project team welcomes contributions from the community. Before you start working with terraform-provider-tanzu-mission-control, please |
| 5 | +read our [Developer Certificate of Origin](https://cla.vmware.com/dco). All contributions to this repository must be |
| 6 | +signed as described on that page. Your signature certifies that you wrote the patch or have the right to pass it on |
| 7 | +as an open-source patch. |
| 8 | + |
| 9 | +## Contribution Flow |
| 10 | + |
| 11 | +This is a rough outline of what a contributor's workflow looks like: |
| 12 | + |
| 13 | +- Create a topic branch from where you want to base your work |
| 14 | +- Make commits of logical units |
| 15 | +- Make sure your commit messages are in the proper format (see below) |
| 16 | +- Push your changes to a topic branch in your fork of the repository |
| 17 | +- Submit a pull request |
| 18 | + |
| 19 | +Example: |
| 20 | + |
| 21 | +``` shell |
| 22 | +git remote add upstream https://github.com/vmware/terraform-provider-tanzu-mission-control.git |
| 23 | +git checkout -b my-new-feature main |
| 24 | +git commit -a |
| 25 | +git push origin my-new-feature |
| 26 | +``` |
| 27 | + |
| 28 | +### Staying In Sync With Upstream |
| 29 | + |
| 30 | +When your branch gets out of sync with the vmware/main branch, use the following to update: |
| 31 | + |
| 32 | +``` shell |
| 33 | +git checkout my-new-feature |
| 34 | +git fetch -a |
| 35 | +git pull --rebase upstream main |
| 36 | +git push --force-with-lease origin my-new-feature |
| 37 | +``` |
| 38 | + |
| 39 | +### Updating pull requests |
| 40 | + |
| 41 | +If your PR fails to pass CI or needs changes based on code review, you'll most likely want to squash these changes into |
| 42 | +existing commits. |
| 43 | + |
| 44 | +If your pull request contains a single commit or your changes are related to the most recent commit, you can simply |
| 45 | +amend the commit. |
| 46 | + |
| 47 | +``` shell |
| 48 | +git add . |
| 49 | +git commit --amend |
| 50 | +git push --force-with-lease origin my-new-feature |
| 51 | +``` |
| 52 | + |
| 53 | +If you need to squash changes into an earlier commit, you can use: |
| 54 | + |
| 55 | +``` shell |
| 56 | +git add . |
| 57 | +git commit --fixup <commit> |
| 58 | +git rebase -i --autosquash main |
| 59 | +git push --force-with-lease origin my-new-feature |
| 60 | +``` |
| 61 | + |
| 62 | +Be sure to add a comment to the PR indicating your new changes are ready to review, as GitHub does not generate a |
| 63 | +notification when you git push. |
| 64 | + |
| 65 | +### Code Style |
| 66 | + |
| 67 | +### Formatting Commit Messages |
| 68 | + |
| 69 | +We follow the conventions on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/). |
| 70 | + |
| 71 | +Be sure to include any related GitHub issue references in the commit message. See |
| 72 | +[GFM syntax](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) for referencing issues |
| 73 | +and commits. |
| 74 | + |
| 75 | +## Reporting Bugs and Creating Issues |
| 76 | + |
| 77 | +When opening a new issue, try to roughly follow the commit message format conventions above. |
0 commit comments