Github Workflow.

A streamlined SemVer workflow using the terminal.

1. The Terminal Workflow (Step-by-Step)

Step 1: Start the Task

Find your next task and create a local branch tied to the issue.

# List open issues to find what to work on
gh issue list

# Create a branch and switch to it
# (Assuming Issue #5 is "Add dark mode")
gh bb feat/5-dark-mode

Step 2: Code and “Tag” your Intent

Write your code. When you commit, use the Conventional Commit prefix. This is the “data” the automation will use later.

git add .
git commit -m "feat: implement high-contrast dark mode (#5)"

Step 3: Push and Create the PR

Push your branch and use the CLI to open a Pull Request.

Bash

# Push branch to GitHub
git push -u origin HEAD

# Create the PR via CLI
gh pr create --title "feat: dark mode" --body "Closes #5"

Step 4: The Merge (The Trigger)

Once tests pass and the code is reviewed, merge it. This “signals” the automation to prepare a release.

gh pr merge --squash --delete-branch

---

2. The Automation Setup

To make this work, you need to add a “Release Butler” to your repository. Google’s release-please is the gold standard for GitHub.

Create the automation file:

In your terminal, create this file: .github/workflows/release-please.yml

name: release-please
on:
  push:
    branches:
      - main
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v4
        with:
          release-type: node # Change to python, go, etc. based on your project

---

3. What Happens Next? (The “Magic”)

After you merge your feat or fix branch using the CLI:

1. Automation wakes up: The GitHub Action sees the new commit on main.
2. The Release PR appears: You will see a new PR created by github-actions[bot] titled “chore: release 1.1.0”.
3. The Changelog is written: Inside that PR, the bot has automatically listed your feat: dark mode under a “Features” heading.
4. The Final Step: When you are ready to actually “ship” the version, just use the CLI to merge that specific release PR:Bashgh pr merge --merge As soon as you merge the Release PR, the bot creates the Git Tag (e.g., v1.1.0) and an official GitHub Release.

---

Summary of Commands to Remember

Goal	Command
Check Tasks	gh issue list
Start Work	git checkout -b feat/your-feature
Commit (SemVer)	git commit -m "feat: description"
Submit Work	gh pr create
Finish Work	gh pr merge --squash
View Releases	gh release list

This keeps your hands on the home row and your versioning perfectly synced with your code. Does this terminal-centric approach fit your current setup, or do you need the specific release-type config for a language like Python or Rust?