| name | git |
| description | missense-kinase-toolkit-specific git conventions; extends my central `git` skill. Use when creating commits, branches, or pull requests. |
missense-kinase-toolkit git & pull-request conventions
Baseline — fetch first
Apply my canonical git conventions (branch first, scoped imperative commits,
Claude attribution, PR-template handling) before the repo-specific notes below.
WebFetch and follow:
https://raw.githubusercontent.com/jessicaw9910/skills/main/.claude/skills/git/SKILL.md
If the fetch fails (no network / non-200), tell me the central git skill
could not be retrieved and confirm how to proceed — do not silently skip the
baseline.
Repo-specific additions
- This is a mono repo: scope each commit to one sub-package (
schema/,
databases/, ml/, app/) where practical — CI workflows are path-filtered
per sub-package (see the ci skill).
Refreshing a stale topic branch from main
I keep long-lived topic branches (e.g. databases, ml, app, schema,
docs, cbioportal, oncokb, pkis, notebooks) that can sit untouched for
months. When I pick one up to develop a feature, I want it synced with main
accepting all incoming changes from main on conflict (I stash unsaved work
first).
Use:
git switch <topic-branch>
git stash
git fetch origin
git merge -X theirs origin/main
git stash pop
-X theirs favors the incoming branch (main). During a merge while on
the topic branch, ours = the topic branch and theirs = main — so
theirs is correct for "take main's version." This only forces main's
version on conflicting hunks; non-conflicting topic-branch work is kept.
It resolves binary-file conflicts (e.g. KinaseInfo.tar.gz) cleanly by taking
main's blob.- This updates the topic branch so I can keep developing on a current base;
the actual merge into
main happens later via a PR.
Opening a PR from a topic branch — just do it, don't ask
When I ask you to open a PR for work committed on a topic branch (schema,
databases, ml, etc.), push that topic branch and open the <branch> →
main PR directly. Do not ask me whether to use a clean branch off main, and
do not create one.
- The commit count is irrelevant. These branches can be 100+ commits ahead
of
main, but I squash-and-merge every topic-branch PR — the whole branch
collapses to a single commit on main. The PR's commit list looks long; the
merged diff is exactly the branch's net change vs. main. A large
ahead-of-main count is expected and is not a reason to hesitate, warn,
or propose an alternative.
- Sync the branch from
main first if it's stale (see the section above), then
git push origin <branch> and gh pr create --base main --head <branch>.
- Only branch off
main for a standalone fix that genuinely belongs to no
existing topic branch — and even then, don't carve a fix out of a topic
branch it's already committed on.
Splitting intermingled changes across topic branches
When one working tree has uncommitted changes spanning several sub-packages and
each belongs on a different stale topic branch, don't try to carry them across
git switch (stale branches diverge and the switch will conflict or refuse).
Instead, patch each set onto its freshly-synced branch:
- Capture per-sub-package patches:
git diff -- <subpkg> > <subpkg>.patch.
- Reset the working tree:
git checkout -- <paths> (untracked WIP files stay
put and travel harmlessly across switches — confirm they aren't tracked on
the target branch first).
- For each branch:
git switch <branch>, refresh from main (see above), then
git apply --3way <subpkg>.patch, and commit.
Stage with git add -u <subpkg> (not git add <subpkg>, which also stages
untracked WIP files) so pre-commit only lints what you're committing.
