The basic usage pattern for Git Patch Stack is pretty straight forward and is outlined as follows.
- add one or more WIP patch(es) to your stack
- iterate and evolve a patch to a state where it is ready to be reviewed
- request review of the patch
- rinse and repeat steps 2 & 3 until that patch is approved
- integrate the patch
The first step is to add a WIP, Work In Progress, patch to your stack. This is effectively a stack that is incomplete in it's nature with a summary prefixed with "WIP:".
This is done simply by making some local changes, staging them with
and then create a patch with
gps c or
gps create-patch. This will take the
staged changes and create a patch on top of your stack from them.
The second step is to iterate the WIP patch using various commands like
gps rebase, etc. to get it to a place where it is ready
to review. At this point you remove the "WIP:" prefix from the patches summary.
Then you request review of the patch with
gps rr or
This requests review of the specified patch using the provided hook. This most
likely is creating a pull request on GitHub, Bitbucket, or GitLab.
Once you have requested review of the patch you wait for feedback and make any
necessary changes using the same commands as when iterating on it before. Once
you feel it is once again ready to be reviewed you simply request review for
the patch again using
gps rr or
gps request-review. You continue this
process until you have addressed all the issues and the patch has been
Once the patch has been approved you are ready to integrate it upstream so that
the rest of the team can continue building on it. This is done with the
gps int or
gps integrate command.
Once you have integrated your patch in. You do it all over again with another patch.