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