For detailed information on how to get started with the project, refer to README.md.
This is a rough outline of what a contributor's workflow looks like:
- Create a topic branch from where you want to base your work
- Make commits of logical units
- Make sure your commit messages are in the proper format (see below)
- Push your changes to a topic branch in your fork of the repository
- Submit a pull request
Example:
git checkout -b my-new-feature vmware/master
git commit -a
git push $USER my-new-featureWhen your branch gets out of sync with the vmware/master branch, use the following to update:
git checkout my-new-feature
git fetch -a
git rebase vmware/master
git push --force-with-lease $USER my-new-featureIf your PR fails to pass CI or needs changes based on code review, you'll most likely want to squash these changes into existing commits.
If your pull request contains a single commit or your changes are related to the most recent commit, you can simply amend the commit.
git add .
git commit --amend
git push --force-with-lease $USER my-new-featureIf you need to squash changes into an earlier commit, you can use:
git add .
git commit --fixup <commit>
git rebase -i --autosquash vmware/master
git push --force-with-lease $USER my-new-featureBe sure to add a comment to the PR indicating your new changes are ready to review, as GitHub does not generate a notification when you git push.
We follow the conventions on How to Write a Git Commit Message.
Be sure to include any related GitHub issue references in the commit message. See GFM syntax for referencing issues and commits.
When opening a new issue, try to roughly follow the commit message format conventions above.