The next step is to push your new code to the remote and create a PR. Normally you would do this by pushing your work branch and then creating a PR from it in the GitHub UI. Let’s see how this workflow differs when using the plz CLI.
Let’s start with the plz status command. This command will summarize your working changes:
$ plz status
0a2ea7b9 Skip rebase when the old and new bases are the ... (new)
The output looks a bit like git log but it’s only showing your new commit, not any commits that have already been merged into main like git log would.
Next we’ll create a PR from the new commit by running plz review:
$ plz review
0babae5b Skip rebase when the old and new bases are the ... created https://plz.review/review/55
This has caused a few different things to happen:
A new commit 0babae5 has been created, having the same diffs as 0a2ea7b
The new commit has been pushed to the remote repo
work has been updated to point at the new commit, but the branch itself has not been pushed
0babae5b Skip rebase when the old and new bases are the ... (rev 1, current) https://plz.review/review/55
There are a couple things worth noting:
The local repository state matches revision 1 (”rev 1”) of review 55
Revision 1 is “current”, that is it’s the most up to date revision in the review
Visiting the review URL, you can now add reviewers, update the title or description, or other things you would typically do in the GitHub PR UI.
You might be wondering why we created a new commit 0babae5 with the same diffs. If you run git log you’ll see a new line at the end of the commit message:
This is a structured message at the end of certain Git commit messages called a “trailer” that certain tools use for bookkeeping and other reasons. plz use the plz-review-url trailer to map commits to their corresponding reviews, similar to Gerrit’s Change-Id trailer.