|
| 1 | +# Pull Request Workflow |
| 2 | + |
| 3 | +Load this file before creating, updating, landing, or documenting pull request workflows. |
| 4 | + |
| 5 | +JayJay uses jj bookmarks for pull requests on both GitHub and Codeberg. This keeps the pushed commit identical to the signed jj change, avoids generated PR commits, and matches jj's normal edit-and-rewrite model. |
| 6 | + |
| 7 | +GitHub PR status and checks still use `gh`; Codeberg PR status is not integrated yet. |
| 8 | + |
| 9 | +## Default Flow |
| 10 | + |
| 11 | +Start from current trunk: |
| 12 | + |
| 13 | +```bash |
| 14 | +jj git fetch |
| 15 | +jj new main@origin |
| 16 | +``` |
| 17 | + |
| 18 | +Keep edits in the working-copy change `@` until they are ready to publish: |
| 19 | + |
| 20 | +```bash |
| 21 | +jj st |
| 22 | +jj diff |
| 23 | +jj describe -m "scope: concise change summary" |
| 24 | +``` |
| 25 | + |
| 26 | +Split by responsibility when the working copy contains more than one logical change: |
| 27 | + |
| 28 | +```bash |
| 29 | +jj split --paths <paths-for-one-change> -m "scope: one logical change" |
| 30 | +``` |
| 31 | + |
| 32 | +Repeat `jj split` until each PR-sized change has one clear purpose. Do not split just to mirror file boundaries; split by behavior, bug fix, or user-visible feature. |
| 33 | + |
| 34 | +Before publishing, run the checks that match the change: |
| 35 | + |
| 36 | +```bash |
| 37 | +just test |
| 38 | +just test-app |
| 39 | +just lint |
| 40 | +``` |
| 41 | + |
| 42 | +Publish the selected change by moving a bookmark to it and pushing that bookmark: |
| 43 | + |
| 44 | +```bash |
| 45 | +jj bookmark set <topic> -r @ |
| 46 | +jj git push --bookmark <topic> |
| 47 | +``` |
| 48 | + |
| 49 | +Then open the bookmark context menu in JayJay and choose **Pull Request on GitHub** or **Pull Request on Codeberg**. For GitHub, `gh pr create --draft --base main --head <topic>` is also fine when the browser flow is inconvenient. |
| 50 | + |
| 51 | +Use `master@origin` or `trunk@origin` instead of `main@origin` when that is the repository's trunk bookmark. |
| 52 | + |
| 53 | +## Review Updates |
| 54 | + |
| 55 | +Handle review feedback by editing the same change and pushing the same bookmark again: |
| 56 | + |
| 57 | +```bash |
| 58 | +jj git fetch |
| 59 | +jj edit <topic> |
| 60 | + |
| 61 | +# edit files |
| 62 | +jj st |
| 63 | +jj diff |
| 64 | +jj describe -m "scope: updated summary" |
| 65 | +just test |
| 66 | +just lint |
| 67 | + |
| 68 | +jj bookmark set <topic> -r @ |
| 69 | +jj git push --bookmark <topic> |
| 70 | +``` |
| 71 | + |
| 72 | +The remote branch moves as part of normal jj history editing. `jj git push` applies jj's bookmark safety checks, so fetch first if the push reports that the remote bookmark changed. |
| 73 | + |
| 74 | +## Multiple Changes |
| 75 | + |
| 76 | +For independent PRs, use one bookmark per ready change: |
| 77 | + |
| 78 | +```bash |
| 79 | +jj bookmark set <topic-a> -r <rev-a> |
| 80 | +jj bookmark set <topic-b> -r <rev-b> |
| 81 | +jj git push --bookmark <topic-a> |
| 82 | +jj git push --bookmark <topic-b> |
| 83 | +``` |
| 84 | + |
| 85 | +For stacked work, prefer separate bookmarks only when the stack is actually useful for review. Push the base change first, then the dependent change, and set the dependent PR's base branch to the base bookmark in the hosting UI. |
| 86 | + |
| 87 | +## Landing Cleanup |
| 88 | + |
| 89 | +After the PR lands: |
| 90 | + |
| 91 | +```bash |
| 92 | +jj git fetch |
| 93 | +jj new main@origin |
| 94 | +``` |
| 95 | + |
| 96 | +If the hosting service deleted the remote branch, forget the local bookmark and its stale remote tracking state: |
| 97 | + |
| 98 | +```bash |
| 99 | +jj bookmark forget <topic> --include-remotes |
| 100 | +``` |
| 101 | + |
| 102 | +If the hosting service did not delete the remote branch, delete it before forgetting it: |
| 103 | + |
| 104 | +```bash |
| 105 | +jj bookmark delete <topic> |
| 106 | +jj git push --bookmark <topic> |
| 107 | +``` |
| 108 | + |
| 109 | +Keep the local reviewed change only when it is still useful for follow-up work; otherwise start new work from `main@origin`. |
0 commit comments