-
Notifications
You must be signed in to change notification settings - Fork 2
Workflow
We're developing on a branch of the original zaproxy/zap-extensions repo, so we need to fit to to that model as we add features/make changes/etc.
This should be done periodically; especially before beginning any development work. Some generic instructions can be found here, though these instructions are modified to take into account the idea that that we probably only want to ever fast forward our fork (and keep any development work in a branch).
- If you haven't done so previously, add a remote for the upstream repository - in this case,
zaproxy/zap-extensions. These instructions assume you have named the remoteupstream. - Open a terminal to the repository, make sure you've checked out the
masterbranch. -
git fetch upstreamto fetch new commits/pointers from the base repository. -
git merge --ff-only upstream/masterto update our copy of the branch from theirs. The--ff-onlyflag will prohibit actual merges from happening. We shouldn't be modifying this branch directly, so if we ever get into a state where we can't fast forward, someone's done something wrong. - Push back to GitHub.
Create a new branch from master. The way we "release" is by sending pull requests back to the ZAP folks. A brand new branch should be created for every pull request that we make. Make changes and commit on this new branch until satisfied.
There's no hard-and-fast rule at the moment, so just break apart into logical units for pull requests.
After the changes have been tested, reviewed internally, and are ready to go, we need to make a pull request to get the changes merged in.
If there are more than a couple of commits, those should probably be squashed down into one. This can most cleanly be done by creating a new branch off of master and doing a git merge --squash of the development branch into the new branch.
Create a pull request from your development branch (or the branch you squash merged into, if you did that) to their master branch. Give a concise description of what's been done in the pull request. They will review and comment/request changes/etc., so follow through on those as appropriate as you would do with internal reviews.
An example pull request can be found here.
After the pull request is approved, delete any development/squash-merge branches that were created from our end. They're not needed anymore, and they'll just become out of date.