Preparing Git PR Workflow

Bash
# 1. Inspect current state
git status
git diff
git branch --show-current

# 2. Create branch (if not already on a feature branch)
git checkout -b feature/short-description

# 3. Stage and commit logically grouped changes
git add <related-files>
git commit -m "feat(scope): add short description"

# 4. Push and open PR
git push -u origin feature/short-description
gh pr create --title "feat(scope): add short description" --body "## Summary\n..."

Progress:

• Step 1: Contextualize repository state
• Step 2: Determine branch type and name
• Step 3: Create the branch
• Step 4: Group changes into logical commits
• Step 5: Write conventional commit messages
• Step 6: Push branch
• Step 7: Open pull/merge request

Step 1: Contextualize repository state

Run git status, git diff, and git log -5 --oneline to understand:

• What files changed (new, modified, deleted)
• Whether changes are already partially staged
• The current branch and its relation to main/develop
• If there's an issue/ticket reference in branch name conventions used by the team

Step 2: Determine branch type and name

Follow AWS Amplify feature branch pattern conventions — use a type/description structure so branches can be matched by pattern-based rules:

Naming rules:

• Lowercase, kebab-case description: feature/user-avatar-upload
• Include ticket ID if the project uses one: feature/PROJ-123-user-avatar-upload
• Keep it short (≤ 50 chars) and descriptive of the intent, not the files touched

Infer the prefix from the nature of the diff (new files/logic → feature; error handling/bug corrections → fix; config/deps only → chore).

Step 3: Create the branch

Bash
git checkout -b <type>/<description>

If already on an appropriately named branch, skip this step.

Step 4: Group changes into logical commits

Do not commit everything in one blob. Group by:

• Feature/concern (e.g., backend change vs. UI change vs. tests)
• File relationship (a component and its test file together)
• Avoid mixing unrelated fixes with new features

Use git add -p or explicit file lists per group.

Step 5: Write conventional commit messages

Follow Conventional Commits:

<type>[optional scope]: <short description>

[optional body]

[optional footer(s)]

Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Rules:

• Subject line ≤ 72 chars, imperative mood ("add" not "added"), no trailing period
• Scope is optional but recommended when the repo has clear modules (feat(auth): ...)
• Use ! or BREAKING CHANGE: footer for breaking changes
• Body explains why, not just what, when the change isn't self-evident

Step 6: Push branch

Bash
git push -u origin <branch-name>

Step 7: Open pull/merge request

Use the platform CLI available in the repo (gh pr create for GitHub, glab mr create for GitLab). Build the description from the accumulated commits:

Markdown
undefined

Example 1: Input: Repo has modified src/api/auth.js (added token refresh logic) and new file src/api/auth.test.js. Output:

• Branch: feature/auth-token-refresh
• Commit: feat(auth): add automatic token refresh on expiry
• Commit: test(auth): add tests for token refresh flow
• PR title: feat(auth): add automatic token refresh on expiry

Example 2: Input: Repo has modified package.json, package-lock.json bumping a dependency version, no other changes. Output:

• Branch: chore/bump-lodash-4-17-21
• Commit: chore(deps): bump lodash to 4.17.21
• PR title: chore(deps): bump lodash to 4.17.21

Example 3: Input: Repo has a fix in src/utils/date.js correcting a timezone off-by-one bug, referencing ticket PROJ-456. Output:

• Branch: fix/PROJ-456-timezone-offset
• Commit: fix(date): correct timezone offset calculation (PROJ-456)
• PR title: fix(date): correct timezone offset calculation (PROJ-456)