Your first pull request starts with a branch, because GitHub will not open one from main into main.
A pull request is a proposal to merge code from one branch into another. A generated app usually arrives as one branch with one large commit on it, so there is nothing to propose yet. You make a branch, put the change on the branch, and open the pull request from there into main. GitHub's own documentation is blunt about the requirement: pull requests can only be opened between two different branches. Read on 16 October 2026. Owning the repository on your own changes none of the mechanics. It only means the write access the documentation asks for is already yours.
What follows is why the extra step pays on code you did not write, the exact path through the GitHub interface, the one thing GitHub will not let you do on your own pull request, and what a merge does and does not ship.
Start hereThe short version
On your own repo a pull request is a reading room, not a request.
On a team, a pull request asks somebody for something. On a repository you own alone, nobody is going to arrive and tell you the function is wrong. What you get instead is the diff: every file your change touched, next to what was there before. On a project a generator wrote, that is the only view which shows how much of the app one small edit actually moved.
The second thing you get is an undo that takes one click. A merged pull request carries a Revert button, and GitHub creates a new pull request that reverts the original merge commit. A commit pushed straight to main can be undone as well, but you do that with git on your machine, and first you have to work out which commit it was.
Do you need a pull request at all if you own the repo alone?
Nothing requires it. You can commit to main, push, and GitHub will take it without a word. The question is what you give up, and on a generated app you give up more than you would on code you typed yourself.
You give up the diff first. A generated project is full of files you have never opened. Ask an agent for one change and it may edit nine of them. The pull request page is where you find out which nine. Reading that list takes two minutes and it is how you learn where things live in your own app. Second, you give up the record. Each pull request has a title, a description and a conversation, and the Commits tab shows how the branch changed over time. Months later that is the only surviving explanation of why a file looks the way it does.
People skip it because they assume a pull request with no reviewer is a dead end. It is not. GitHub's page on required reviews says repository owners and administrators can merge a pull request without an approving review. So the routine for one person is: make the branch, open the pull request, read it, merge it. Nobody is waiting, and nothing is blocked.
There is one case where the answer turns into a firm yes. If the builder syncs both ways with the same repository, main is not only yours any more. The agent commits there too. A branch keeps your half separate until you have looked at it, and the diff is the only honest way to tell your edit from its edit. Check which branch your project syncs with before you start renaming or protecting anything.
GitHub Docs, approving a pull request with required reviews, read 16 October 2026
Pick yours
Does this change earn a branch and a pull request?
Tick what you are about to change. The answer is about how far the change reaches, not about how many lines you typed.
Nothing ticked. If you genuinely cannot say what the change touches, that on its own is the argument for opening a pull request and reading the file list.
Do you need a branch, or can you commit straight to main?
A branch, and this is the one hard requirement in the whole process. GitHub says pull requests can only be opened between two different branches. Main into main is not a small pull request, it is not a pull request. GitHub is equally plain about where branches come from: you always create a branch from an existing branch. On a fresh generated project that existing branch is main, because the first branch in a repository is the default branch, and GitHub names it main in new repositories.
The default branch matters beyond naming. It is the branch GitHub shows anyone who visits the repository, and the base it uses for new pull requests unless you pick another one. That is the whole case for the habit. Branch off main, work on the branch, propose it back. Main does not move while you work, so the version you could build and hand to a tester yesterday is still sitting there today.
Naming the branch costs nothing and pays later. GitHub calls a branch made for one piece of work a feature branch or a topic branch. Name it after the change. In a project where most of the code is unfamiliar, a branch called fix-signup-copy is a better memory aid than a commit message you are never going to reread.
One warning that is specific to generated apps. If the change pulls in a payment or subscription library, the branch will be large and it will touch native folders and the app config at the same time. That is a bad moment to be making a product decision, so settle which payment layer to use before you open the branch, not while you are halfway down the diff.
How do you open the pull request, step by step?
The path GitHub documents starts on the repository page, not on the pull request list, which is why people hunt for it. Push your branch. Open the repository's main page. In the Branch menu, choose the branch that contains your commits. A banner appears above the list of files with Compare & pull request on it. Click that.
The next page has two dropdowns. The base dropdown is where the change is going, normally main. The compare dropdown is your branch. Read the file list underneath them before you type anything, because it is the same diff you will be reviewing in a minute and mistakes are cheapest to fix here. Then type a title and a description and click Create Pull Request.
There is a second button hiding inside that one. Use the dropdown beside it and you get Create Draft Pull Request, then Draft Pull Request. GitHub says draft pull requests cannot be merged, and that code owners are not automatically requested to review them. The second half means nothing on a one-person repository. The first half is the useful bit: a draft is a pull request with the merge button switched off while you are still pushing commits to it. You can convert a pull request to a draft at any time, so neither choice traps you.
Permissions are the step nobody notices on their own repository and everybody hits on somebody else's. GitHub asks for write access to create a branch, open a pull request, or delete and restore branches in a pull request. Owning the repository hands you all of that. On a public repository you do not own, you fork it first and open the pull request from your fork, which is the same five minutes with one extra copy of the code.
Who reviews it, and what happens when you merge?
You review it, and GitHub will not let you approve it. That is documented in one sentence: pull request authors cannot approve their own pull requests. The approval is not for you, so stop looking for it. What you do instead is open the Files changed tab and read. If you want a note on the record, click Review changes above the code, write it, and submit it as a comment rather than as an approval. The merge is not waiting on any of this, because owners and administrators can merge without an approving review.
Merging gives you three options and they are not the same thing. A merge commit preserves every commit from the pull request branch and adds an explicit merge point. Squash and merge combines all the commits in the pull request into a single commit on the base branch. Rebase and merge adds each commit onto the base branch without a merge commit, for a linear history. The plain merge option is the default. On a solo generated project, squash is usually the kind choice, because nobody later needs your six attempts at one screen.
A merge changes the repository and nothing else. It does not build anything, it does not upload a binary, and it does not touch a store listing. Getting the change to real users is a separate job, and on iOS the submission is yours by rule, because Apple rejects apps created by an app generation service unless the provider of the app's content submits them directly. The route for that is publishing to the App Store. On Android, if the change makes you nervous, put it behind a staged rollout on Google Play rather than holding the merge hostage while you worry.
Two traps to close before you leave. The first: if you require approving reviews and then switch on the setting that stops anyone bypassing the rule, you have locked yourself out of your own repository. You cannot approve your own work, and you just gave away the exemption that let you merge anyway. GitHub says that by default, the restrictions of a branch protection rule do not apply to people with admin permissions to the repository. Leave that default alone. The second: the Revert button sits near the bottom of a merged pull request and opens a new pull request that reverts the original merge commit. It is not magic. You may still need to revert individual commits if the revert runs into merge conflicts.
GitHub Docs, approving a pull request with required reviews, read 16 October 2026
Three ways to get a change onto main when you are the only person on the repo
| What you want to know | Commit straight to main | Branch, then a pull request | Pull request with required approvals |
|---|---|---|---|
| Needs a second branch | No | Yes | Yes |
| You see the diff before it lands on main | No | Yes | Yes |
| You can approve it yourself | Nothing to approve | No approval is asked for | No, GitHub blocks the author |
| You can still merge it | Yes | Yes | Only through the admin exemption |
| Undo is a button on the pull request | No | Yes | Yes |
| Still works once bypassing is disallowed | Rule does not apply | Yes | No, you lock yourself out |
Where this lands if a builder generated your app
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. Paid plans start at $25 a month and there is no free tier.
The part that matters for a pull request is the two-way GitHub sync. The project is not a zip file you download once, it is a repository, and changes move in both directions. Your branch and the agent's commits end up in the same place. The pull request is where you see which is which, so if you intend to touch the code at all, this is the habit to start with rather than the one to add after something goes wrong.
The honest limit: a pull request is a GitHub feature, and no builder generates one for you or reviews it on your behalf. Newly does not submit to the App Store for you either, because Apple wants the content owner to press submit, and a green merge is not a release. A clean diff also says nothing about screenshots, age ratings or privacy answers, which make up a large share of why apps get rejected. What a generated project does hand you is a repository that was already set up to be read, which is more than most people get on their first pull request.
Questions people ask about a first pull request
Yes. GitHub's documentation on creating a pull request says pull requests can only be opened between two different branches, so main into main is not a pull request at all. You make a branch, commit to it, push it, and open the pull request from that branch into main. GitHub also says you always create a branch from an existing branch, which on a fresh generated project means you branch off main. The requirement is the same whether the repository has twenty people on it or only you.
Describe the app, then read the diff
Generate the project, connect the repository, and make the first change on a branch. The pull request turns an app you cannot read into one you can, a few files at a time.
Start building