Ps-Tech Git / GitHub workflow
Scope
- Encode PS-Tech defaults: linear history, rebase over merge for integrating work, draft PRs early, clean history before review, revert instead of rewriting shared history.
- Read GitHub state with
gh when available (schemas first—see reference.md).
- Mutating git (rebase, push, revert): only when the user explicitly asks to run commands or recover from a described situation. Do not push, force-push, merge on GitHub, approve, or comment on PRs unless the user requests it.
Inspecting branches and PRs
- Run from the repository root (or
cd there first). If not a git repo, say so and stop there.
- Prefer
gh: gh auth status; then list/view PRs and checks (see reference.md).
- Branches:
git branch -a, git status; optional gh api repos/{owner}/{repo}/branches if JSON is needed (gh repo view --json nameWithOwner for owner/repo).
Linear history and branch roles
production and staging: staging tracks production, often with a few extra commits. Updating production means moving it forward to staging (conceptually), using the flows below—not merge-button shortcuts that scatter merge commits.- Dev branches sit on top of
staging. If staging advances before the feature is ready, rebase the dev branch onto staging.
Merge vs rebase
- Goal: land commits onto another branch.
git rebase moves your branch on top of the target and keeps history linear—this is the team preference.
- Avoid
git merge.
GitHub merges
- Merge buttons or
gh actions often behave like non–fast-forward merges and break linearity. Prefer CLI (git checkout, git rebase, git push) for control.
Rebase conflicts
- Find conflict markers (
<<<<<<<).
- Fix the files.
git add <file>git rebase --continue- Escape hatch:
git rebase --abort
Pull request etiquette
- Open a draft PR early so others see what you are doing.
- Push regularly (e.g. daily or when switching tasks) to reduce lost work.
- Mark ready for review and assign a reviewer when appropriate.
- Before review, clean up history: interactive rebase—squash, fixup, reword (
git rebase -i HEAD~X). Aim for one commit per feature (often one task per feature).
Staying current and merging (commands)
Use git fetch first; rebase onto origin/<branch> so the base is the latest remote tip. Full command sequences for updating dev from staging, merging dev → staging, staging → production, promotion up to a commit, excluding a middle commit, Odoo.sh trigger, reverts, and force-push policy are in reference.md.
After you push: treat commits as immutable
Once others may have your commits, treat them as immutable. Follow-ups are new commits with clear why in the body—not silent history rewrites on shared branches.
Commit messages
The training deck stresses a short first line and a verbose body focused on why. For bracketed [TAG], [TASK], module prefix, and the 80-character header rule, use the project skill commit-message-format.
Related skills
- Commit headers and tags: commit-message-format.
- Full read-only PR review report (severity, confidence, workspace validation): use the
review-github skill when the user wants a production-style review; this skill focuses on workflow and discovery/read.
Additional reference
- Command cheat sheets and
gh read patterns: reference.md.
Source: brinkflew/odoo-skills — distributed by TomeVault.
1---2name: brinkflew-odoo-skills-git-workflow-ps-tech3description: Ps-Tech Git / GitHub workflow4---56# Ps-Tech Git / GitHub workflow78## Scope910- Encode **PS-Tech** defaults: linear history, **rebase** over merge for integrating work, **draft PRs early**, clean history before review, **revert** instead of rewriting shared history.11- **Read GitHub state** with **`gh`** when available (schemas first—see [reference.md](reference.md)).12- **Mutating git** (rebase, push, revert): only when the user **explicitly** asks to run commands or recover from a described situation. Do not push, force-push, merge on GitHub, approve, or comment on PRs unless the user requests it.1314## Inspecting branches and PRs15161. Run from the **repository root** (or `cd` there first). If not a git repo, say so and stop there.172. Prefer **`gh`**: `gh auth status`; then list/view PRs and checks (see [reference.md](reference.md)).183. **Branches:** `git branch -a`, `git status`; optional `gh api repos/{owner}/{repo}/branches` if JSON is needed (`gh repo view --json nameWithOwner` for owner/repo).1920## Linear history and branch roles2122- **`production`** and **`staging`**: staging tracks production, often with a few extra commits. Updating production means moving it **forward** to staging (conceptually), using the flows below—not merge-button shortcuts that scatter merge commits.23- **Dev branches** sit **on top of `staging`**. If `staging` advances before the feature is ready, **rebase** the dev branch onto `staging`.2425## Merge vs rebase2627- **Goal:** land commits onto another branch. **`git rebase`** moves your branch on top of the target and keeps history **linear**—this is the team preference.28- Avoid **`git merge`**.2930## GitHub merges3132- Merge buttons or `gh` actions often behave like **non–fast-forward** merges and **break linearity**. Prefer **CLI** (`git checkout`, `git rebase`, `git push`) for control.3334## Rebase conflicts35361. Find conflict markers (`<<<<<<<`).372. Fix the files.383. `git add <file>`394. `git rebase --continue`405. Escape hatch: `git rebase --abort`4142## Pull request etiquette4344- Open a **draft PR early** so others see what you are doing.45- **Push regularly** (e.g. daily or when switching tasks) to reduce lost work.46- Mark **ready for review** and assign a reviewer when appropriate.47- Before review, **clean up** history: interactive rebase—squash, fixup, reword (`git rebase -i HEAD~X`). Aim for **one commit per feature** (often one task per feature).4849## Staying current and merging (commands)5051Use **`git fetch`** first; rebase onto **`origin/<branch>`** so the base is the latest **remote** tip. Full command sequences for updating dev from staging, merging dev → staging, staging → production, promotion up to a commit, excluding a middle commit, Odoo.sh trigger, reverts, and force-push policy are in [reference.md](reference.md).5253## After you push: treat commits as immutable5455Once others may have your commits, treat them as **immutable**. Follow-ups are **new commits** with clear **why** in the body—not silent history rewrites on shared branches.5657## Commit messages5859The training deck stresses a short first line and a **verbose body focused on why**. For bracketed **`[TAG]`**, **`[TASK]`**, module prefix, and the **80-character** header rule, use the project skill [commit-message-format](../commit-message-format/SKILL.md).6061## Related skills6263- **Commit headers and tags:** [commit-message-format](../commit-message-format/SKILL.md).64- **Full read-only PR review report** (severity, confidence, workspace validation): use the **`review-github`** skill when the user wants a production-style review; this skill focuses on **workflow and discovery/read**.6566## Additional reference6768- Command cheat sheets and **`gh`** read patterns: [reference.md](reference.md).6970---71> Source: [brinkflew/odoo-skills](https://github.com/brinkflew/odoo-skills) — distributed by [TomeVault](https://tomevault.io).72<!-- tomevault:4.0:skill_md:2026-06-16 -->
tomevault-io