Crates.io | git-disjoint |
lib.rs | git-disjoint |
version | |
source | src |
created_at | 2022-08-10 21:28:02.279249 |
updated_at | 2024-10-29 10:31:56.917441 |
description | A tool to batch commits by issue into GitHub PRs |
homepage | |
repository | https://github.com/ericcrosson/git-disjoint |
max_upload_size | |
id | 642906 |
Cargo.toml error: | TOML parse error at line 29, column 1 | 29 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
git-disjoint automates an optimal git workflow for PR authors and reviewers by grouping commits by issue into GitHub PRs.
This encourages the submission of small, independent PRs, minimizing cognitive load on reviewers, maximizing the utility of your git history, and keeping cycle time low.
You're working on a feature. As you work, you create some commits that don't directly implement your feature. Maybe you improve some documentation, fix a minor bug, or first refactor to make the change easy, before making the easy change1. In any case, you commit directly to master as you go2, because you want each change to persist in your development environment, even before it's gone through code review and landed upstream.
When you come to a natural stopping point, you are ready to ship several commits. Each commit is atomic, relating to just one topic. It comes with a detailed commit message referencing an issue in your work tracker, passing unit tests, and documentation. You don't want to shove all these changes into a single PR, because they deal with orthogonal concerns. You trust your team to contribute quality code reviews, and iterating on one changeset shouldn't delay unrelated changes from merging.
Instead of creating a PR directly from your master, or manually moving commits into separate branches, do this:
git disjoint
git-disjoint will identify which commits relate to the same issue, batch these commits into a new branch, and create a PR.
git-disjoint looks for trailers3 in each commit message to determine which issue a commit relates to. By default, it creates one PR for each issue and associates the PR to an existing issue in your work tracker.
When a PR merges, your next git pull
effectively moves upstream's master from
behind your local commits to ahead of them.
git-disjoint adds value to your workflow if you:
You need a GitHub personal access token with repo
scope. Either export this
as the GITHUB_TOKEN
environment variable or pass it to git-disjoint with
the --token
option.
The easiest way to install git-disjoint is to download a release compatible with your OS and architecture from the Releases page.
Alternatively, install git-disjoint with one of the following package managers:
Repository | Command |
---|---|
Cargo | cargo +nightly install git-disjoint |
Cargo binstall | cargo binstall git-disjoint |
Nix | nix profile install github:EricCrosson/git-disjoint |
Add all of your commits to a single branch. I recommend using the repository's default branch.
In each commit message, include a reference to the relevant issue.
For example, use the Jira automation format:
Ticket: COOL-123
or
Closes Ticket: COOL-123
Or use the GitHub format:
Closes #123
When you're ready to:
run git disjoint
.
To ignore commits associated with an issue, use the --choose
flag. This will
open a menu where you can select the issues to create PRs for.
Use the --all
flag to include commits without a recognized trailer.