How to Open Pull Requests from GitHub Issues with GitAuto

Already have GitAuto installed? Great! If not, you can install it directly from GitHub Marketplace or check out our detailed installation guide.

TL;DR - Quick Steps

1. Creating Your First GitHub Issue
2. Assigning GitAuto to Your Issue
3. How GitAuto Works
4. Reviewing the Pull Request
5. Usage and Pricing
6. What's Next?
7. Why Use GitAuto?

Need more details? Read on for a detailed step-by-step guide below.

1. Creating Your First GitHub Issue

First, let's create a new GitHub issue. Look for the "Issues" tab in your repository:

If you don't see it, you'll need to enable issues in your repository settings first (they're disabled by default):

Once you click the Issues tab, you'll see the issues list:

Click the green "New issue" button:

You'll see the issue creation form:

Don't overthink your first issue! While you can use existing issues (we'll cover that later), let's start fresh. For your first try, a simple title is enough. Need ideas? Here's an example: "Add a folder structure to README.md"

Other good starter examples:

• "Write unit tests for function B in file A"
• "Improve performance of function B in file A"

Click "Create issue" and you're done!

Pro tip: If you have specific requirements in mind, adding them to the description will improve accuracy. But don't worry if you don't - GitAuto can work with just a title, and you can always refine requirements after seeing the initial pull request.

2. Assigning GitAuto to Your Issue

Once you create your issue, GitAuto will automatically comment on it. You'll see something like this:

To assign the issue to GitAuto, simply check the checkbox in its comment. Why this approach? While GitHub issues have an assignee field, it can't accept GitHub Apps as assignees, so we use this checkbox method instead.

2-1. Working with Existing Issues

For existing issues that don't have GitAuto's comment, simply add the gitauto label to the issue. The first time you do this, you'll need to create the label by typing "gitauto" manually. After that, the label will be available in your repository's label list, and you can find it quickly by typing part of the word like "git" in the label field.

This labeling approach is particularly useful for bulk assignments - you can label multiple issues at once to assign them to GitAuto!

2-2. Working with Sub-Issues

GitHub recently released sub-issues, a feature that was previously missing and made GitHub Issues less convenient compared to other issue platforms like Jira, as you couldn't create parent-child issue relationships. This limitation has now been resolved, and GitAuto can be assigned to these sub-issues as well!

3. How GitAuto Works

While GitAuto is working, it'll keep you updated on its progress. Here's what's happening behind the scenes:

1. Input Analysis: Reviews issue title, description, and comments
2. Repository Analysis: Checks folder structure and configuration files (like package.json or requirements.txt)
3. File Location: Identifies files to modify through directory traversal or targeted searches
4. Research: Validates approach against current best practices and latest library versions
5. Implementation: Makes changes and commits them
6. Iteration: Repeats steps 3-5 until the issue's goals are met
7. Pull Request: Creates a PR and links it back to the issue

Let's see this process in action:

When the process is complete, GitAuto will comment on your issue with a link to the new pull request:

4. Reviewing the Pull Request

Click through to the pull request to review the changes. You'll see GitAuto's proposed modifications, complete with:

• A clear title linking back to the original issue
• A description explaining the changes
• The actual code changes with inline comments explaining key decisions

Review the changes and if they look good, go ahead and merge!

If not, you have several options:

1. Major Changes Needed? Add your requirements to the original issue's description and reassign GitAuto:

• Either uncheck and recheck the checkbox in GitAuto's comment
• Or remove and re-add the gitauto label

For example, in our "Add folder structure to README.md" case, you might realize: "Actually, we only need the root-level or main-level structure, not every single file. That would be overkill." While the model might handle this intuitively, it's a specific requirement worth adding to ensure the right level of detail. If you want certainty, it's better to make such requirements explicit.

1. Minor Tweaks? Just leave review comments like you would for any human engineer:

For example, in our case, you might notice that the added "4. Folder Structure" h2 heading is too close to the text above - missing one blank line. While this kind of spacing issue might be slightly irritating, let's use it as a chance to practice the review comment workflow.

Click the blue "+" button that appears when you hover over line numbers to add a review comment:

Write your comment explaining what needs to be changed:

Submit your review as "Request Changes":

No need to mention GitAuto specifically - it will automatically receive notifications for any review comments on its pull requests and start working on the changes:

And here's the result - a properly spaced heading with an added blank line:

5. Usage and Pricing

As of writing, GitAuto offers several pricing tiers:

• Free Plan: Up to 3 issues per month
• Standard Plan: $100 per 10 issues per month (e.g., $200 for 20 issues)
• Enterprise Plan: Unlimited issues available

Important notes about issue counting:

• Multiple iterations on the same issue count as one issue
• This includes both reassignments from the issue and review comments on the PR
• When bulk assigning issues, each issue counts separately (e.g., assigning 10 issues at once consumes 10 from your quota)

You can check your remaining issue count by creating a new issue (e.g., creating a test issue).

6. What's Next?

Now that you know how to use GitAuto with GitHub issues, why not try it out? Start with something simple - maybe that documentation update you've been putting off? Let GitAuto handle the initial PR while you focus on more complex tasks.

7. Why Use GitAuto?

How many open GitHub issues do you have right now (A)? And how many issues did your team close this month/last month (B)? Using a simple formula:

A/B = Estimated months to close all current issues

This quick calculation can give you a reality check on your issue backlog. Let's look at a real-world example:

Microsoft's VSCode, one of the most popular open-source repositories, has 8,262 open issues:

In the last three months (Oct-Dec 2024), they closed 5,656 issues (excluding PRs), averaging about 1,885 issues per month (using the GitHub query is:issue closed:2024-10-01..2024-12-31 -is:pr):

Using our formula: 8,262 / 1,885 = 4.4 months. This means if you filed an issue today and joined the end of the queue (assuming no queue-jumping), you'd theoretically wait about 4.4 months for your issue to be addressed. Try calculating this number for your repository - is the result acceptable for your team and users? If this number is higher than you (or your boss) would like, it might be time to consider adding resources.

Have questions or need help? Feel free to reach out through the chat icon in the bottom right corner or email us at [e-mail]. We'd love to hear about your experience!