12 KiB
Getting started with git-appraise
This file gives an example code-review workflow using git-appraise. It starts with cloning a repository and goes all the way through to browsing your submitted commits.
The git-appraise tool is largely agnostic of what workflow you use, so feel free to change things to your liking, but this particular workflow should help you get started.
Cloning your repository
Since you're using a code review tool, we'll assume that you have a URL that you can push to and pull from in order to collaborate with the rest of your team.
First we'll create our local clone of the repository:
git clone ${URL} example-repo
cd example-repo
If you are starting from an empty repository, then it's a good practice to add a README file explaining the purpose of the repository:
echo '# Example Repository' > README.md
git add README.md
git commit -m 'Added a README file to the repo'
git push
Creating our first review
Generally, reviews in git-appraise are used to decide if the code in one branch (called the "source") is ready to merge into another branch (called the "target"). The meaning of each branch and the policies around merging into a branch vary from team to team, but for this example we'll use a simple practice called GitHub Flow.
Specifically, we'll create a new branch for a particular feature, review the changes to that branch against our master branch, and then delete the feature branch once we are done.
Creating our change
Create the feature branch:
git checkout -b ${USER}/getting-started
git push --set-upstream origin ${USER}/getting-started
... And make some changes to it:
echo "This is an example repository used for coming up to speed" >> README.md
git commit -a -m "Added an explanation to the README file"
git push
Requesting the review
Up to this point we've only used the regular commands that come with git. Now, we will use git-appraise to perform a review:
Request a review:
git appraise request
The output of this will be a summary of the newly requested review:
Review requested:
Commit: 1e6eb14c8014593843c5b5f29377585e4ed55304
Target Ref: refs/heads/master
Review Ref: refs/heads/ojarjur/getting-started
Message: "Added an explanation to the README file"
Show the details of the current review:
git appraise show
[pending] 1e6eb14c8014
Added an explanation to the README file
"refs/heads/ojarjur/getting-started" -> "refs/heads/master"
reviewers: ""
requester: "ojarjur@google.com"
build status: unknown
analyses: No analyses available
comments (0 threads):
Show the changes included in the review:
git appraise show --diff
diff --git a/README.md b/README.md
index 08fde78..85c4208 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
# Example Repository
+This is an example repository used for coming up to speed
Sending our updates to the remote repository
Before a teammate can review our change, we have to make it available to them. This involves pushing both our commits, and our code review data to the remote repository:
git push
git appraise pull
git appraise push
The command git appraise pull is used to make sure that our local code review
data includes everything from the remote repo before we try to push our changes
back to it. If you forget to run this command, then the subsequent call to
git appraise push might fail with a message that the push was rejected. If
that happens, simply run git appraise pull and try again.
Reviewing the change
Your teammates can review your changes using the same tool.
Fetch the current data from the remote repository:
git fetch origin
git appraise pull
List the open reviews:
git appraise list
The output of this command will be a list of entries formatted like this:
Loaded 1 open reviews:
[pending] 1e6eb14c8014
Added an explanation to the README file
The text within the square brackets is the status of a review, and for open reviews will be one of "pending", "accepted", or "rejected". The text which follows the status is the hash of the first commit in the review. This is used to uniquely identify reviews, and most git-appraise commands will accept this hash as an argument in order to select the review to handle.
For instance, we can see the details of a specific review using the "show" subcommand:
git appraise show 1e6eb14c8014
[pending] 1e6eb14c8014
Added an explanation to the README file
"refs/heads/ojarjur/getting-started" -> "refs/heads/master"
reviewers: ""
requester: "ojarjur@google.com"
build status: unknown
analyses: No analyses available
comments (0 threads):
... or, we can see the diff of the changes under review:
git appraise show --diff 1e6eb14c8014
diff --git a/README.md b/README.md
index 08fde78..85c4208 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
# Example Repository
+This is an example repository used for coming up to speed
Comments can be added either for the entire review, or on individual lines:
git appraise comment -f README.md -l 2 -m "Ah, so that's what this is" 1e6eb14c8014
These comments then show up in the output of git appraise show:
git appraise show 1e6eb14c8014
[pending] 1e6eb14c8014
Added an explanation to the README file
"refs/heads/ojarjur/getting-started" -> "refs/heads/master"
reviewers: ""
requester: "ojarjur@google.com"
build status: unknown
analyses: No analyses available
comments (1 threads):
"README.md"@1e6eb14c8014
|# Example Repository
|This is an example repository used for coming up to speed
comment: bd4c11ecafd443c9d1dde6035e89804160cd7487
author: ojarjur@google.com
time: Fri Dec 18 10:58:54 PST 2015
status: fyi
Ah, so that's what this is
Comments initially only exist in your local repository, so to share them with the rest of your team you have to push your review changes back:
git appraise pull
git appraise push
When the change is ready to be merged, you indicate that by accepting the review:
git appraise accept 1e6eb14c8014
git appraise pull
git appraise push
The updated status of the review will be visible in the output of "show":
git appraise show 1e6eb14c8014
[accepted] 1e6eb14c8014
Added an explanation to the README file
"refs/heads/ojarjur/getting-started" -> "refs/heads/master"
reviewers: ""
requester: "ojarjur@google.com"
build status: unknown
analyses: No analyses available
comments (2 threads):
"README.md"@1e6eb14c8014
|# Example Repository
|This is an example repository used for coming up to speed
comment: bd4c11ecafd443c9d1dde6035e89804160cd7487
author: ojarjur@google.com
time: Fri Dec 18 10:58:54 PST 2015
status: fyi
Ah, so that's what this is
comment: 4034c60e6ed6f24b01e9a581087d1ab86d376b81
author: ojarjur@google.com
time: Fri Dec 18 11:02:45 PST 2015
status: fyi
Submitting the change
Once a review has been accepted, you can merge it with the tool:
git appraise submit --merge 1e6eb14c8014
git push
The submit command will pop up a text editor where you can edit the default
merge message. That message will be used to create a new commit that is a
merge of the previous commit on the master branch, and the history of all
of your changes to the review. You can see what this looks like using
the git log --graph command:
* commit 3a4d1b8cd264b921c858185f2c36aac283b45e49
|\ Merge: b404fa3 1e6eb14
| | Author: Omar Jarjur <ojarjur@google.com>
| | Date: Fri Dec 18 11:06:24 2015 -0800
| |
| | Submitting review 1e6eb14c8014
| |
| | Added an explanation to the README file
| |
| * commit 1e6eb14c8014593843c5b5f29377585e4ed55304
|/ Author: Omar Jarjur <ojarjur@google.com>
| Date: Fri Dec 18 10:49:56 2015 -0800
|
| Added an explanation to the README file
|
* commit b404fa39ae98950d95ab06012191f58507e51d12
Author: Omar Jarjur <ojarjur@google.com>
Date: Fri Dec 18 10:48:06 2015 -0800
Added a README file to the repo
This is sometimes called a "merge bubble". When the review is simply accepted as is, these do not add much value. However, reviews often go through several rounds of changes before they are accepted. By using these merge commits, we can preserve both the full history of individual reviews, and the high-level (review-based) history of the repository.
This can be seen with the history of git-appraise itself. We can see the high
level review history using git log --first-parent:
commit 83c4d770cfde25c943de161c0cac54d714b7de38
Merge: 9a607b8 931d1b4
Author: Omar Jarjur <ojarjur@google.com>
Date: Fri Dec 18 09:46:10 2015 -0800
Submitting review 8cb887077783
Fix a bug where requesting a review would fail with an erroneous message.
We were figuring out the set of commits to include in a review by
listing the commits between the head of the target ref and the head of
the source ref. However, this only works if the source ref is a
fast-forward of the target ref.
This commit changes it so that we use the merge-base of the target and
source refs as the starting point instead of the target ref.
commit 9a607b8529d7483e5b323303c73da05843ff3ca9
Author: Harry Lawrence <hazbo@gmx.com>
Date: Fri Dec 18 10:24:00 2015 +0000
Added links to Eclipse and Jenkins plugins
As suggested in #11
commit 8876cfff2ed848d50cb559c05d44e11b95ca791c
Merge: 00c0e82 1436c83
Author: Omar Jarjur <ojarjur@google.com>
Date: Thu Dec 17 12:46:32 2015 -0800
Submitting review 09aecba64027
Force default git editor when omitting -m
For review comments, the absence of the -m flag will now attempt to load the
user's default git editor.
i.e. git appraise comment c0a643ff39dd
An initial draft as discussed in #8
I'm still not sure whether or not the file that is saved is in the most appropriate place or not. I like the idea of it being relative to the project although it could have gone in `/tmp` I suppose.
commit 00c0e827e5b86fb9d200f474d4f65f43677cbc6c
Merge: 31209ce 41fde0b
Author: Omar Jarjur <ojarjur@google.com>
Date: Wed Dec 16 17:10:06 2015 -0800
Submitting review 2c9bff89f0f8
Improve the error messages returned when a git command fails.
Previously, we were simply cascading the error returned by the instance
of exec.Command. However, that winds up just being something of the form
"exit status 128", with all of the real error message going to the
Stderr field.
As such, this commit changes the behavior to save the data written to
stderr, and use it to construct a new error to return.
...
Here you see a linear view of the reviews that have been submitted, but if we
run the command git log --oneline --graph, then we can see that the full
history of each individual review is also available:
* 83c4d77 Submitting review 8cb887077783
|\
| * 931d1b4 Merge branch 'master' into ojarjur/fix-request-bug
| |\
| |/
|/|
* | 9a607b8 Added links to Eclipse and Jenkins plugins
| * c7be567 Merge branch 'master' into ojarjur/fix-request-bug
| |\
| |/
|/|
* | 8876cff Submitting review 09aecba64027
|\ \
| * | 1436c83 Using git var GIT_EDITOR rather than git config
| * | 09aecba Force default git editor when omitting -m
|/ /
| * 8cb8870 Fix a bug where requesting a review would fail with an erroneous message.
|/
* 00c0e82 Submitting review 2c9bff89f0f8
...
Cleaning up
Now that our feature branch has been merged into master, we can delete it:
git branch -d ${USER}/getting-started
git push origin --delete ${USER}/getting-started