1. Sign in
Go to the sign-in page and put in your university email address. It has to end in charlotte.edu or uncc.edu; departmental subdomains like cs.charlotte.edu work too.
There is no password. We email you a link, you click it, you are signed in. The link works once and expires after fifteen minutes. If it expires, ask for another one - there is no limit worth worrying about, though asking five times in fifteen minutes will get you throttled for a few minutes.
The first time you sign in you pick a handle. Your handle is permanent, because every link to your profile and every review you leave points at it. Pick something you would not mind a recruiter seeing.
2. Install the command line tool
You can do everything in a browser, but pushing code is far easier from the terminal. See the tool page for install instructions, then:
$ bw auth login Your code is KRPT-8N2W Approve it at https://branchwork.info/device Waiting for you to approve. Press Ctrl-C to stop. ok Signed in as yourhandle.
The tool opens your browser. Check that the code shown in the browser matches the one in your terminal, then approve it. That connects this one machine, and you can disconnect it later under Settings.
3. Make a stack
A stack belongs to a repository and a base branch. From inside a git repository, on the branch holding your work:
$ bw stack create "Search pipeline" --base main ok Created Search pipeline stk_8f56e965 yourhandle/project onto main https://branchwork.info/stack/stk_8f56e965
The repository name is taken from your origin remote if you have one. Pass --repo owner/project if you do not, or if the guess is wrong.
4. Write small commits
This is the part that matters. One commit becomes one change, and one change is what somebody reviews in one sitting. Three commits of eighty lines each get better review than one commit of two hundred and forty.
A useful test: if the commit subject needs the word "and", it is probably two commits.
$ git commit -m "Tokenize search queries" $ git commit -m "Plan index scans from typed nodes" $ git commit -m "Rank results by recency"
5. Submit
$ bw submit 3f9a1c2b created chg_b9d22681 Tokenize search queries 7ce4d0a1 created chg_7d2cab5c Plan index scans from typed nodes 9b1f6e30 created chg_55dca3df Rank results by recency 3f9a1c2b pushed to chg_b9d22681 Tokenize search queries 7ce4d0a1 pushed to chg_7d2cab5c Plan index scans from typed nodes 9b1f6e30 pushed to chg_55dca3df Rank results by recency ok 3 changes created, 3 revisions pushed, 0 changes unchanged.
Each commit becomes a change, in order, each stacked on the one before it. Branchwork writes a Change-Id trailer into each commit message so it can recognize the same commit later even after a rebase rewrites every hash.
Run bw submit as often as you like. It only creates a change for a commit that does not already have one, and it only stores a revision when the content actually differs.
6. Get it reviewed
Send someone the stack link. They open a change, hover any line, click the blue plus, and write a note. Notes queue up in yellow until they submit them together with a verdict: comment, approve, or request changes.
When you push a fix, their next visit opens on Since your last review - only the lines that landed after they signed off. That is the part everybody notices first.
7. Merge in order
A change can only be marked merged once everything below it in the stack is merged. The button is disabled otherwise, and the server refuses it too. Work from the bottom up.
What to do next
- Run bw init in your repository. It installs a small commit hook that adds the Change-Id trailer as you commit, so bw submit never has to rewrite anything.
- Write your page. It is one Markdown page that anyone can read, and it is the thing to link on a resume.
- Make a group for your class project and add your teammates.
