GitHub Mastery: Creating Repositories and Managing PRs With Ease

Published · Updated

A reliable GitHub workflow is small and repeatable: start from the current default branch, create a focused topic branch, commit tested changes, push that branch, and open a pull request into the correct base branch. The pull request then becomes the place for review, automated checks and the merge decision.

If the words repository, branch, remote, head and base are unfamiliar, read Repositories, Branches, and Pull Requests first. This guide focuses on doing the workflow.

1. Choose how the repository starts

There are two common starting points.

GitHub-first: create, then clone

Use this for a new exercise or shared project. On GitHub, create a repository with the correct owner and visibility. You may add a README, .gitignore and license when GitHub is the starting point. Then clone it:

git clone https://github.com/OWNER/REPOSITORY.git
cd REPOSITORY
git remote -v

Local-first: connect existing work

If a project already has local commits, create an empty GitHub repository so you do not introduce an unrelated README commit. Then add the remote and push. The detailed safety checklist—including secret exclusion—is in How to Link a Spring Boot Project to a GitHub Repository.

GitHub documents both repository visibility and initialization choices in Creating a new repository.

2. Synchronize the default branch

Before creating a topic branch, make sure you are branching from the intended base:

git switch main
git pull --ff-only
git status

The default branch may not be named main, so check the repository page or run git remote show origin. The --ff-only option stops rather than creating an unexpected merge commit when local and remote histories have diverged. If it stops, inspect the histories and follow your team’s integration policy.

3. Create a focused branch

Give the branch a name that communicates its purpose:

git switch -c feature/add-order-validation

Keep unrelated changes on separate branches. A reviewer can reason about “add order validation” more easily than a branch that also reformats files and upgrades dependencies.

Make the change, run the project’s checks, then review what you are about to commit:

git status
git diff
git add src test
git diff --cached
git commit -m "Validate required order fields"

Avoid git add . when the working tree contains generated files, local configuration or unrelated edits. Never commit passwords, tokens, private keys or .env files. GitHub advises against pushing unencrypted credentials to any repository, including private ones: Keeping API credentials secure.

4. Push the topic branch

git push -u origin feature/add-order-validation

Authenticate with GitHub CLI, a credential manager, a suitably scoped token or SSH. GitHub account passwords do not authenticate HTTPS Git operations. Do not embed a token in the URL or command.

The upstream setting lets later git push commands update the same remote branch. It does not merge the branch into main.

5. Open the pull request carefully

On GitHub, select Compare & pull request, or open the repository’s Pull requests tab and choose New pull request.

Confirm the comparison before submitting:

  • Base is the destination branch that should receive the changes.
  • Head or compare is your topic branch containing the proposed changes.
  • The commit list and file diff contain only the intended work.

GitHub defines the base/head relationship in Creating a pull request.

A useful PR description answers:

  1. What problem does this solve?
  2. What changed?
  3. How was it tested?
  4. What should the reviewer examine closely?
  5. Are there screenshots, migration steps or follow-up work?

Use a draft pull request when the work is not ready to merge but early feedback would help. Do not use “draft” as a substitute for a clear description.

6. Review the change, not just the green check

Reviewers should read the changed files, consider edge cases and confirm that tests match the intended behavior. GitHub reviews can comment, approve or request changes. Whether an approval or requested change actually blocks merging depends on repository rules and permissions; the review UI alone is not enforcement. See About pull request reviews.

Automated checks add evidence, but a passing build does not prove the change is correct or secure. Look for:

  • tests that would fail without the intended behavior;
  • accidental secrets or generated files;
  • dependency or permission changes;
  • unsafe input handling;
  • unclear rollback or deployment effects.

7. Respond to feedback on the same branch

Make requested changes locally, test them, commit and push:

git add src test
git commit -m "Cover empty order payload"
git push

The open pull request updates automatically. Resolve conversations after the concern has been addressed, according to the repository’s review practice. Avoid closing the PR and opening a replacement unless the proposal itself has changed.

8. Merge and clean up

When reviews and required checks are satisfied, use a merge method allowed by the repository:

  • Merge commit preserves the branch’s commits and adds a merge commit.
  • Squash merge combines the PR changes into one commit on the base branch.
  • Rebase merge adds the individual commits onto the base without a merge commit.

No method is universally best; follow the repository’s documented history policy. After merging, delete the remote topic branch if it is no longer needed, then update locally:

git switch main
git pull --ff-only
git branch -d feature/add-order-validation

The safe -d option refuses to delete a local branch Git considers unmerged. Investigate rather than switching immediately to forced deletion.

A practice exercise

Create a small repository with a README. On a topic branch, add a “How to run” section, open a PR, review the Files changed tab, add one follow-up commit, and merge. Then repeat with a tiny code change and a test. The goal is not command memorization; it is learning to leave evidence another person can review.

Once this loop feels natural, configure branch protection rules or rulesets so important repositories enforce the checks and reviews they depend on. These collaboration habits also support the delivery work in the Forward-Deployed Engineer program.