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; nail down your JIRA ticket. If necessary, file it in JIRA.
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 |
Create a development branch for the ticket that you would like to work on and name it with the JIRA ID of the ticket:
git checkout -b <JIRA ID> |
Look at the checklist for developing code.
We recommend developing your code and your tests in parallel. Your PTL tests should provide good coverage of the requirements and your design.
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 <JIRA ID> |
git fetch upstream |
git checkout <JIRA ID> git rebase upstream/master |
git rebase --continue |
git rebase --abort |
git checkout <JIRA ID> git rebase -i --fork-point master |
Now, and this is MANDATORY, sign your commit with the GPG key you configured earlier in the setup stage.
git commit -S --amend |
If you would rather not have to remember this step, you might choose to develop the habit of signing all your commits at all times. If you use Git v2.0+, you can also setup automatic signing.
git push -f origin <JIRA ID> |
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. Link your issue to your pull request.
Don't forget about your pull request after you create it – inactive 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 you get sign-offs (at least two) on your changes, if there are multiple commits in your pull request, please squash all your change commits into a single, signed commit again.
Add a comment on your pull request informing the maintainers that your changes are ready to be merged into the golden repository.
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 <JIRA ID> (deletes <JIRA ID> from the fork) git branch -D <JIRA ID> (deletes <JIRA ID> from local clone) |
Update the issue on which you were working.
Save