- Created by Anne Urban, last modified on Aug 10, 2016
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 18 Next »
The branch where development work takes place is the master.
Set up your Git environment (for first-time contributors):
- Make sure you have your basic Git environment set up.
Choose a bug:
- Find a bug or feature you like; nail down your JIRA ticket; if necessary, file it in JIRA.
Design phase:
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.
If you're working on a feature or a complex bug, document it in the space used for project designs on Confluence. Create a design document describing your design. See this example. Some bugs are small enough that they don't need documenting. If you are not sure, ask on the development forum. Initiate a discussion of your idea or bug fix by starting a topic for it on the PBS Pro development forum: After you've started your topic, add an HTML link in your design page on Confluence that points to the discussion topic in the forum Get review comments from community members about your bug fix or design. Make sure review comments are solicited and posted in the development forum, and not on the wiki. All discussion of your design and code should take place on the development forum. For features or complex bugs, get sign-off of the high-level design approach from two people: one maintainer and one other contributor (who can be a maintainer). If you took a complex feature and broke it down into sub-tasks, and you are working on a sub-task, you need two sign-offs on the design for your sub-task. Make sure that all approvals are posted in the development forum, not on the wiki. Add a link in the design page containing the EDD that points to the discussion, and vice versa. Also add a link from the EDD to the pull request and vice versa.Document your design
Get comments on your design
Get approval for your design
Make finding information easy
Development cycle:
Update fork:
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 dev branch:
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> 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. Your code is ready to be merged into the golden repository when the following are true: Commit changes in the updated file to your branch with a good commit message. Make your commit message relevant and concise, so that it will be helpful to you later: git add <updated file> git commit -m "<Commit message>" Tip: Commit often, perfect later. git push origin <JIRA ID> Fetch changes made to the golden repository by other contributors. By convention, 'upstream' points to the golden repository on GitHub: git fetch upstream Rebase your development branch with new changes from the golden repository's master. 'upstream/master' is the remote tracking branch for the golden repository's (upstream's) master branch, on your local machine: git checkout <JIRA ID> git rebase upstream/master Then, just continue the rebase operation: git rebase --continue If the conflict is complex or problematic, you can abort the current rebase operation instead of continuing, and come back to it later: git rebase --abort Squash all your commits into fewer, meaningful change commits (just one suffices if the code change is small enough). git checkout <JIRA ID> git rebase -i --fork-point master Write meaningful commit messages for your commits while doing the squash above. You can also use git commit --amend or rebase if you'd rather do it later. Finally, push the polished branch to your fork. Because you did a git rebase, you'll need to do a force push. git push -f origin <JIRA ID>
Develop Your Code and Your Tests
Put License Text in Headers for Code and Tests
Get Approval for Your Code and Tests
- Your changes are now ready to be reviewed.
Get Approval for Your Code and Tests
Your code is ready to be merged into the golden repository when the following are true:
- The code adheres to our coding standards
- You have approval from two people: one maintainer and one other contributor (who can be a maintainer); approvals for code and tests happen on GitHub inside pull requests, not the wiki
Review and check-in:
Cleanup:
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 your bug
- No labels