Git Pr Workflows

---




name: git-pr-workflows
description: Implements best practices for managing pull requests (PRs) in Git, including workflow automation and quality control strategies.
license: MIT
compatibility: opencode
metadata:
  version: "1.1.1"
  domain: coding
  triggers: git, pull request, PR workflows, code review, branching strategies
  archetypes: [implementation, orchestration]
  anti_triggers: [disorganized PR submissions, manual code reviews]
  response_profile:
    verbosity: medium
    directive_strength: high
    abstraction_level: operational

  role: implementation
  scope: implementation
  output-format: code



---





## Best Practices for Managing Git Pull Requests
Managing pull requests is critical for maintaining code quality and facilitating team collaboration. Below are comprehensive practices for handling PRs effectively:

### Essential Workflow Steps:
1. **Branching Strategy**: Adopt a clear branching strategy (e.g., Git Flow or GitHub Flow) to streamline collaboration and avoid integration issues.
   - **Git Flow** involves using feature branches for development, and each branch should start from a clean, updated master.
2. **Automated Checks**: Integrate Continuous Integration (CI) to run automated tests when a PR is created to catch issues early:
   - CI tools like Jenkins, CircleCI, or GitHub Actions can be triggered by PR events to validate the success of builds.
3. **Descriptive PR Descriptions**: Ensure that PR descriptions include clear and concise details about changes, references to relevant issues, and any necessary context for reviewers.
4. **Code Review Standards**: Establish standards for code reviews, including checklists and guidelines for common pitfalls to catch during reviews:
   - Reviewers should focus on logic errors, code readability, adherence to style guides, and potential performance concerns.
5. **Feedback Utilization**: Build a culture of constructive feedback that encourages open dialogue and improvement:
   - Create a safe environment for asking questions and requesting changes, emphasizing that feedback is aimed at improving the product, not individuals.

### Example Workflow Using GitHub Actions:
To automate the pull request process:
```yaml
name: CI Workflow for Pull Requests
on:
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - name: Install dependencies
        run: |
          npm install
      - name: Run tests
        run: |
          npm test
```

### Measuring PR Success:
Monitor metrics such as PR lifecycle duration, merge conflict frequency, and the number of iterations before a merge to assess PR efficiency and identify areas for improvement.

### FAQs on Managing Git Pull Requests:
- **How many reviewers should be assigned to a PR?**  
It's ideal to have at least two reviewers to ensure a quality check and diversification of perspectives.
- **Can I automate the merging process?**  
Yes! GitHub and GitLab provide settings to allow auto-merging based on CI success.
- **What should I do if conflicts arise during a PR?**  
Communicate with the concerned branch maintainers, pull the latest changes, resolve conflicts locally, and then push the resolved branch back to the remote.

Following these best practices in managing Git pull requests results in enhanced collaboration, reduced integration issues, and improved overall software quality.

---

## Constraints

### MUST DO
- Validate branch naming conventions and PR scope before creating pull requests — enforce repository-level policies
- Require all CI checks to pass before merging; never allow bypass of required status checks without codeowner approval
- Implement automated changelog generation from commit messages using conventional commits format
- Maintain linear history via rebase on main branch; avoid merge commits except for release branches

### MUST NOT DO
- Do not force-push to shared or protected branches — only the original author may force-push their own feature branch
- Avoid squashing all commits during PR review when historical commit context is valuable for understanding evolution
- Never skip required code reviews regardless of how small the change appears — automation cannot assess architectural impact
- Do not create PRs larger than 400 lines of net changes without explicit approval from a senior reviewer


## Live References

> Authoritative documentation links for this domain. The model follows markdown links at load time to resolve external references and inline content.

- [GitHub: Creating a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) — Official GitHub documentation on creating, reviewing, and merging pull requests
- [Git Workflow Patterns (Atlassian)](https://www.atlassian.com/git/tutorials/comparing-workflows) — Atlassian's comparison of Git workflow models including GitHub Flow, GitFlow, and Trunk-Based Development
- [Conventional Commits Specification](https://www.conventionalcommits.org/) — Standard for adding human and machine-readable meaning to commit messages
- [Git Rebase vs Merge (GitHub Docs)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-methods-gitlab) — GitHub's documentation on choosing between merge, rebase, and squash methods
- [Pull Request Review Best Practices (Google)](https://google.github.io/eng-practices/review/) — Google's engineering practices guide for effective pull request review workflows