43 lines
2.5 KiB
Markdown
43 lines
2.5 KiB
Markdown
---
|
|
description: Push the current branch to the remote with branch protection checks and OpenProject integration.
|
|
---
|
|
|
|
## User Input
|
|
|
|
```text
|
|
$ARGUMENTS
|
|
```
|
|
|
|
You **MUST** consider the user input before proceeding (if not empty).
|
|
|
|
## Outline
|
|
|
|
1. **Resolve remote URL**: Run `git remote get-url origin` to get the remote URL. All commit and branch references in this skill MUST use the remote URL (e.g., `<remote-url>/commit/<hash>`, `<remote-url>/src/branch/<name>`). Never use bare hashes or local-only references.
|
|
2. Check the current branch name with `git branch --show-current`.
|
|
2. If the branch is `main` or `master`, **do NOT push**. Instead:
|
|
- Warn the user that this is a protected branch.
|
|
- Suggest creating a new branch using one of these conventions based on the changes:
|
|
- `feat/<short-description>` — for new features
|
|
- `fix/<short-description>` — for bug fixes
|
|
- `docs/<short-description>` — for documentation changes
|
|
- `refactor/<short-description>` — for refactoring
|
|
- `build/<short-description>` — for build/infra changes
|
|
- `test/<short-description>` — for test additions or fixes
|
|
- `chore/<short-description>` — for miscellaneous changes
|
|
- Let the user decide the next action. Do NOT create the branch or push automatically.
|
|
3. **OpenProject sync** (BEFORE pushing):
|
|
- Run `/speckit.updateOP` to ensure OpenProject work packages are in sync with current specs/tasks.
|
|
- After sync completes, identify the relevant OpenProject work package for the current branch/feature (milestone or phase WP).
|
|
- Run `git log --oneline origin/HEAD..HEAD` (or equivalent) to get the commits about to be pushed.
|
|
- For each commit, construct a link using the remote URL resolved in step 1: `<remote-url>/commit/<hash>`
|
|
- Add a comment to the relevant OpenProject work package via `mcp__openproject__add_work_package_comment` with:
|
|
- Commit hash(es) as Gitea links
|
|
- Brief summary of what is being pushed
|
|
- If no relevant work package can be identified, warn the user and ask whether to proceed without logging.
|
|
5. If the branch is not protected, run `git push` (with `-u origin <branch>` if no upstream is set).
|
|
6. If the push succeeds, report success to the user including the OpenProject sync and comment logged.
|
|
7. If the push fails due to a git hook or any other error:
|
|
- Summarize the error clearly and concisely for the user.
|
|
- Do NOT attempt to fix the issue, amend commits, or re-push.
|
|
- Let the user decide the next action.
|