The branch where development work takes place is the master.
Make sure you have your basic Git environment set up.
Find a bug or feature you like and can manage. If you wish, file it, or go straight to creating a pull request. Make sure your pull request follows the guidelines for pull requests.
If you are developing a feature, or you are working on a bug that involves an interface change, you'll need to go through the design phase:
Update your (forked & locally cloned) repository's master branch with the golden repository's master (IMPORTANT: Your fork's master branch should not be touched with any of your development changes. It should just reflect the golden repository's master, exactly).
git checkout master git pull upstream master |
Push the updated master branch to your fork:
git push origin master |
Create a development branch for your bug or feature:
git checkout -b <dev branch> |
Look at the checklist for developing code.
We recommend developing your code and your tests in parallel.
For large projects, it may help to break down your contribution into smaller, workable pieces. Code for smaller pieces must follow the guidelines for contributions.
Write an automated test for every change you make, if that test does not already exist. Your PTL tests should provide good coverage of the requirements and your design. Take a look at the steps for testing code.
If you create new source or test files, make sure that this license text is in the header for all code and test files.
git add <updated file> git commit -m "<Commit message>" |
Tip: Commit often, perfect later.
git push origin <dev branch> |
git fetch upstream |
git push -f origin <dev branch> |
Your code changes are good to go! Go ahead and create a pull request. This allows other contributors to review your changes and provide comments.
Give your pull request a short descriptive title. The title of your pull request (which comes from the title of your commit message) should summarize the bug/issue as it affects a user/customer. If you also have an issue, the titles should match.
In your pull request, add a link to the design document and discussion (for features). If you created an issue, add a link to it.
Add your test logs and other test results to the pull request.
Make sure your pull request follows the guidelines for contributions; if it doesn't, it will not be accepted.
Make your pull request informative. Follow the guidelines in the pull request template.
Don't forget about your pull request after you create it – stale pull requests will be closed without warning.
Your code is ready to be merged into the golden repository when the following are true:
Address review comments on your code, making changes to your development branch as necessary
To help reviewers see incremental diffs during the code review process, we recommend that you don't squash again until the code review process is complete
Once the maintainers review the pull request, they will merge it in. Congratulations on becoming a contributor to PBS Pro!
Housekeeping: we strongly recommend that you delete the development branch from your forked and cloned repos now.
git checkout master git push origin --delete <dev branch> (deletes <dev branch> from the fork) git branch -D <dev branch> (deletes <dev branch> from local clone) |
If you filed an issue, /wiki/spaces/~agurban/pages/13991979.
List of Steps