ivan.jovanovikj
e3cdcfc419
- code-review: critical code review of uncommitted changes - code-self-review: self-review after writing code - code-cleanup: garbage collection for technical debt - security-review: security review from pentester perspective - create-merge-request: create GitLab MR from uncommitted changes - understand-project: learn about a project from docs and structure
63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
---
|
|
name: create-merge-request
|
|
description: >
|
|
Create a GitLab Merge Request from uncommitted changes. Automatically creates a feature
|
|
branch, organizes changes into logical commits, pushes to remote, and opens an MR.
|
|
allowed-tools: bash
|
|
argument-hint: "[branch-name] [optional: description]"
|
|
---
|
|
|
|
# Create a GitLab Merge Request from Uncommitted Changes
|
|
|
|
You are tasked with creating a GitLab Merge Request (MR) from the current uncommitted changes in the working directory.
|
|
|
|
## Steps to Follow
|
|
|
|
### 1. Analyze the Current State
|
|
- Run `git status` to see all uncommitted changes (staged and unstaged)
|
|
- Run `git diff` to understand what has been modified
|
|
- Identify the default branch (check if it's `main` or `master`)
|
|
|
|
### 2. Create a New Feature Branch
|
|
- Create and checkout a new branch with a descriptive name
|
|
- If the user provided a branch name as $1, use that
|
|
- Otherwise, derive a meaningful branch name from the changes (e.g., `feature/add-user-authentication`, `fix/login-validation-bug`)
|
|
- Use the format: `<type>/<short-description>` where type is one of: feature, fix, refactor, docs, chore
|
|
|
|
### 3. Organize and Commit Changes Logically
|
|
- Group related changes into logical, atomic commits
|
|
- Each commit should represent a single logical change
|
|
- Write clear, conventional commit messages following this format:
|
|
```
|
|
<type>(<scope>): <description>
|
|
|
|
[optional body explaining what and why]
|
|
```
|
|
- Types: feat, fix, refactor, docs, style, test, chore
|
|
- If all changes are related, a single well-described commit is acceptable
|
|
- Stage and commit the changes appropriately
|
|
|
|
### 4. Push the Branch to Remote
|
|
- Push the new branch to the GitLab remote: `git push -u origin <branch-name>`
|
|
|
|
### 5. Create the Merge Request
|
|
- Use the GitLab CLI (`glab`) to create the merge request
|
|
- Target the default branch (main or master)
|
|
- Command: `glab mr create --target-branch <default-branch> --title "<title>" --description "<description>"`
|
|
- The title should summarize the changes concisely
|
|
- The description should include:
|
|
- A summary of what the MR accomplishes
|
|
- List of key changes made
|
|
- Any relevant context or notes
|
|
- If the user provided a description as $ARGUMENTS (after the branch name), incorporate it
|
|
|
|
### 6. Report the Result
|
|
- Display the MR URL for easy access
|
|
- Summarize what was done (branch created, commits made, MR opened)
|
|
|
|
## Important Notes
|
|
- Do NOT force push or use destructive git operations
|
|
- Ensure all changes are properly staged before committing
|
|
- If there are no uncommitted changes, inform the user and stop
|
|
- If `glab` CLI is not installed, inform the user how to install it
|