Git Pull Requests and Merging

Plan, build, and merge Pull Requests using a professional GitHub workflow.

Introduction

30 Second Summary

Think about how a team edits a shared document. You wouldn't just overwrite everyone's work directly. You'd propose your changes, explain what you did, and let someone review before it goes live.

In this project, you will use GitHub's Pull Request workflow to propose, review, and merge changes into your repository. You'll plan work with Issues, open Pull Requests that auto-close those Issues, and try two different merge strategies.

What You'll Build

A professional collaboration history on your existing git-learning-log repository, complete with closed Issues linked to merged Pull Requests and two different merge strategies in action.

By the end of this project, you'll have:

  • Two closed GitHub Issues linked to merged Pull Requests showing a professional workflow history.
  • A merged PR using the default merge commit strategy that preserves full branch history.
  • A second merged PR using squash merge to condense multiple commits into one clean entry.
  • Secret Mission: A reusable Pull Request template that auto-populates every future PR in your repo.

Want a complete demo of how to do this project, from start to finish? Check out our 🎬 walkthrough with Maya.

Are there any prerequisites?

This project builds on the "Learn Git Fundamentals" project. You should be comfortable with git commit, branching, pushing, and have a GitHub account with a public repository.

Sync Your Local Repo and Create a GitHub Issue

On professional dev teams, you never jump straight into coding. You start by making sure your local code matches what's on GitHub, then you create a plan for what you're about to build.

In this step, you'll sync your local repository and create your first GitHub Issue to plan a new feature. Issues are how teams track planned work, bugs, and feature requests.

In this step, get ready to:
  • Pull the latest changes from your remote repository.
  • Create a GitHub Issue to plan a new feature.
  • Assign the Issue to yourself and note the Issue number.
Set up your tools and repository

This project continues from the Learn Git Fundamentals project, where you set up Cursor, Git, and a git-learning-log repository connected to GitHub.

✔️ I've done the Git Fundamentals project

You're all set. Skip ahead to the next substep to open your project and pull the latest changes.

ⓧ I haven't done it yet

We recommend completing the Learn Git Fundamentals project first for the full guided experience. If you'd like to jump straight in, follow these steps to get set up.

Install Cursor
  • Download Cursor from cursor.com and install it.
  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Cursor and press Enter to open it.
Install Git and create a GitHub account
  • Download and install Git from git-scm.com/downloads.
  • Create a free account at github.com if you don't already have one.
  • Open the terminal in Cursor by pressing Ctrl+` (backtick key, located above Tab on most keyboards).
  • Configure your Git identity by running these commands:
git config --global user.name "[[YOUR_NAME="your full name"]]"
git config --global user.email "[[YOUR_EMAIL="your GitHub email address"]]"
Create the git-learning-log repository
  • Move to your Desktop by running this command:
cd ~/Desktop
  • Create your project folder, move into it, and initialize a Git repository by running these commands:
mkdir git-learning-log
cd git-learning-log
git init
  • Create the learning-log.md file with starter content and commit it by running:
# My Learning Log

## About This Project
I'm learning Git and version control to track my work.

## Goals
- Understand how commits work
- Learn branching and merging
- Push my work to GitHub

## What I Learned Today

- Git is like a time machine for your files
- Every commit is a snapshot you can go back to
- Git tracks changes to files over time
- Branches let you experiment without affecting the main project
- You can merge branches back together when ready
Push your repository to GitHub
  • Open github.com in your browser.
  • Click the + icon in the top-right corner and select New repository.
  • Enter git-learning-log as the repository name.
  • Leave all other settings as defaults and click Create repository.
  • Back in your Cursor terminal, connect your local repo to GitHub and push by running these commands:
git remote add origin https://github.com/[[GITHUB_USERNAME="your-github-username"]]/git-learning-log.git
git branch -M main
git push -u origin main

GitHub will ask you to sign in

When you push for the first time, a browser window opens asking you to authorize Git to access your GitHub account. Click Authorize to complete the connection.

Once the push succeeds, your repository is live on GitHub and you're ready to continue with this project.

You're all caught up, but...

Your repository is fully set up and ready for this project. The one difference is commit history. Learners who completed the previous project built up their learning-log.md over multiple commits (adding sections one at a time), so their git log shows several entries. Yours has a single commit.

This won't affect anything you do in this project. Pull Requests work the same whether your main branch has one commit or ten.

Open your project and pull the latest changes

Before making any new changes, you need to make sure your local copy of the repository matches what's on GitHub. This prevents conflicts later.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Cursor and press Enter to open it.
  • Click File in the top menu bar.
  • Click Open Folder.
  • Navigate to your git-learning-log folder on your Desktop and click Open.
  • Open the terminal in Cursor by pressing Ctrl+` (backtick key, located above Tab on most keyboards).
  • Make sure you're on the main branch and pull the latest changes by running these commands:
git checkout main
git pull origin main

What do these commands do?

  • git checkout main switches your local repository to the main branch. This ensures you're starting from the primary branch.
  • git pull origin main downloads any new commits from GitHub and merges them into your local main branch. origin is the nickname Git gave your GitHub repo URL when you first connected them. It's how Git knows where to pull from.

You should see either Already up to date. or a summary of changes pulled from the remote.

Seeing an authentication error?

If git pull asks for credentials or fails with an authentication error, your GitHub credentials may have expired. Re-authenticate using the same method you set up in the previous project (HTTPS with a personal access token or SSH key).

Help me fix this authentication error

Create your first GitHub Issue

GitHub Issues are lightweight tickets for tracking planned work. You'll create one now to plan adding a Resources section to your learning log.

  • Open github.com in your browser.
  • Click your profile icon in the top-right corner and select Your repositories.
  • Click git-learning-log.
  • Click the Issues tab near the top of the repository page.
  • Click New issue.
  • In the Title field, type Add a Resources section to learning-log.md.
  • In the description body field, type a brief explanation of what you plan to do. For example: Add a section with helpful Git learning resources including links to documentation and tutorials.

Why write a description?

On a team, someone else might pick up your Issue or review your Pull Request later. A clear description helps others understand the plan without needing to ask follow-up questions.

Assign the Issue and note the Issue number
  • In the right sidebar of the new Issue form, click the Assign yourself link under Assignees.

What does this look like on a team?

Because you're the only collaborator on this repository, GitHub shows a simple Assign yourself link. On a team with multiple collaborators, clicking Assignees opens a searchable list of team members instead. You'd type a name, select the person, and then submit.

  • Click Create.

After submitting, GitHub takes you to the Issue detail page. Notice the number next to your Issue title (e.g. #1). You'll use this number in the next step to link your Pull Request to this Issue.

What is an Issue number?

Every Issue in a repository gets a unique number starting from 1. This number is how GitHub tracks and links work across Issues, Pull Requests, and commits.

💡 Where do issues fit in the workflow?

The core Git workflow is: create a branch, make edits, submit a PR. Creating an issue first is optional but recommended for team projects. It documents what needs to be done before you start the how, and helps the team track and discuss work.

Many teams use dedicated project management tools like Linear, Jira, or Asana for issue tracking instead of GitHub Issues. The workflow stays the same. This project uses GitHub Issues because it keeps everything in one place for learning.

Your local repository is synced and your first Issue is live on GitHub. Next up, you'll create a feature branch to start building the planned feature and open your first Pull Request.

Build a Feature Branch and Open Your First Pull Request

You have an Issue describing what to build. Now you need a safe workspace to build it without affecting the main branch.

In professional teams, developers create a feature branch for every Issue they work on. The branch isolates your changes until they are reviewed and approved through a Pull Request.

In this step, get ready to:
  • Create a feature branch named after your Issue.
  • Add a Resources section to your learning log, then commit and push.
  • Open a Pull Request that links back to your Issue.
Create a feature branch for your Issue

A feature branch gives you an isolated copy of the codebase to work on. Naming it after the Issue number makes it easy to trace which branch solves which problem.

  • In Cursor, open the terminal by pressing Ctrl+` (macOS and Windows).
  • Create and switch to a new feature branch by running this command:
git checkout -b feature/1-add-resources

What does this command do?

The -b flag tells Git to create a new branch and switch to it in one step. The name feature/1-add-resources follows a common convention: the prefix describes the type of work, and the number references your Issue.

  • Confirm you are on the new branch by running:
git branch

You should see an asterisk (*) next to feature/1-add-resources, confirming it is your active branch.

Seeing an error about an invalid branch name?

Make sure you typed the branch name with forward slashes (/) and hyphens (-), not spaces. Branch names cannot contain spaces.

Help me figure out what went wrong

Add a Resources section and push your changes

Now you will add the actual content that your Issue describes. You are adding a Resources section with helpful Git learning links to your learning log.

  • In Cursor's Explorer sidebar, click on learning-log.md to open it.
  • Scroll to the bottom of the file, after the ## What I Learned Today section.
  • Add the following new section at the end of the file:
## Resources
- [Learn Git Fundamentals](https://learn.nextwork.org/projects/8bf3bcb5-a70d-418a-9c76-251365f69028) - Hands-on practice with Git basics
- [Collaborate with Pull Requests](https://learn.nextwork.org/projects/3ac00a14-cbfc-476a-9a2f-2d9b678880b9) - Hands-on practice with branches, PRs, and merge strategies
- [Pro Git Book](https://git-scm.com/book/en/v2) - Free comprehensive Git reference
- [GitHub Docs](https://docs.github.com) - Official GitHub documentation
- [Oh My Git!](https://ohmygit.org) - Interactive game to learn Git

What does this section add?

Each bullet is a Markdown link pointing to a free resource for learning Git. The Pro Git Book is the official reference. GitHub Docs covers the platform features. Oh My Git is a visual game for practising commands.

  • Save learning-log.md by pressing Cmd+S (macOS) or Ctrl+S (Windows).

✔️ Awesome, I've got everything!

Great. Double check you have saved the file before continuing.

ⓧ I'd like to double check the full code

Here is what your full learning-log.md should look like:

# My Learning Log

## About This Project
I'm learning Git and version control to track my work.

## Goals
- Understand how commits work
- Learn branching and merging
- Push my work to GitHub

## What I Learned Today
- Git is like a time machine for your files
- Every commit is a snapshot you can go back to
- Branches let you experiment without affecting the main project
- You can merge branches back together when ready

## Resources
- [Learn Git Fundamentals](https://learn.nextwork.org/projects/8bf3bcb5-a70d-418a-9c76-251365f69028) - Hands-on practice with Git basics
- [Collaborate with Pull Requests](https://learn.nextwork.org/projects/3ac00a14-cbfc-476a-9a2f-2d9b678880b9) - Hands-on practice with branches, PRs, and merge strategies
- [Pro Git Book](https://git-scm.com/book/en/v2) - Free comprehensive Git reference
- [GitHub Docs](https://docs.github.com) - Official GitHub documentation
- [Oh My Git!](https://ohmygit.org) - Interactive game to learn Git
  • Stage and commit your changes by running these commands:
git add learning-log.md
git commit -m "Add resources section with helpful Git links"

You should see a message confirming one file changed with insertions.

  • Push your changes by running this command:
git push

What is git push?

Up to this point, your commits only exist on your computer. git push uploads your commits to GitHub so others can see them. Think of it as syncing your local work to the cloud.

Git responds with an error because this branch doesn't exist on GitHub yet. It suggests the full command you need, including the remote name and branch.

  • Run the suggested command to push and set the upstream:
git push --set-upstream origin feature/1-add-resources

What does --set-upstream do?

The --set-upstream flag tells Git to create the branch on GitHub and link your local branch to it. This is only needed the first time you push a new branch.

Future pushes on this branch only need git push because the link is already set. You can also use HEAD instead of typing the branch name. It means "whatever branch I'm currently on."

You should see output confirming the branch was pushed and a remote tracking branch was set up.

Push rejected or permission denied?

Make sure you are signed into GitHub in Cursor or your terminal. If you see a 403 error, your Git credentials may need refreshing.

Also confirm you are on the feature/1-add-resources branch by running git branch. You should not be pushing from main.

Help me troubleshoot this push error

Open a Pull Request on GitHub

Your branch is now on GitHub. A Pull Request is how you propose merging your changes into the main branch. It gives collaborators a place to review your work before it lands in production.

  • Switch back to your browser where your git-learning-log repository is open on GitHub.
  • Click the Pull requests tab near the top of the page.
  • Look for the yellow banner about your recently pushed branch. Click Compare & pull request.

Don't see the yellow banner?

Click the Pull requests tab, then click New pull request. Set the compare branch to feature/1-add-resources and the base branch to main.

  • Enter a descriptive title such as Add Resources section to learning log.
  • In the description body, type Closes #1 on its own line.

How does Issue linking work?

When your PR description contains a keyword like Closes #1, GitHub automatically closes the linked Issue when the PR merges into the default branch. Other supported keywords include fixes and resolves.

  • Click Create pull request.
  • Click the Files changed tab to see a line-by-line diff of your additions.

You should see your new Resources section highlighted in green, showing exactly what this PR adds to the main branch.

Why is my PR numbered #2?

GitHub numbers Issues and Pull Requests from the same counter. Your Issue was #1, so the next item created in this repository (your Pull Request) gets #2. The Closes #1 in your description still correctly points at the Issue, not the PR itself.

🙋‍♀️ PR shows no changes or wrong branch?

Check that the base branch is set to main and the compare branch is feature/1-add-resources. If the branches are the same, the diff will be empty.

Help me fix my Pull Request

Your first Pull Request is live. Next up, you will merge it and watch the linked Issue close automatically.

Merge with a Merge Commit and Sync Locally

Your Pull Request is open and reviewed. The next step in a real team workflow is merging that PR into the main branch so everyone gets your changes.

GitHub offers multiple merge strategies. In this step, you will use the default "Create a merge commit" option, which preserves the full history of your feature branch inside main.

In this step, get ready to:
  • Merge the Pull Request on GitHub and watch Issue #1 auto-close.
  • Sync your local main branch with the remote so your machine is up to date.
  • Delete the feature branch locally and on GitHub to keep things tidy.
Merge the Pull Request on GitHub

When a PR is merged, the commits from your feature branch are integrated into main. Because you included "Closes #1" in the PR body, GitHub will automatically close the linked Issue the moment the merge completes.

  • In your browser, go back to the Conversation tab of your open Pull Request on the git-learning-log repository.
  • Scroll to the bottom of the PR page where you see the merge options.
  • Click the green Merge pull request button. This is the default "Create a merge commit" strategy.
  • Click Confirm merge.

You should see a purple Merged badge on the Pull Request page. GitHub also shows a Delete branch button, but leave that for now.

What does "Create a merge commit" do?

This strategy uses git merge --no-ff behind the scenes. It creates a special merge commit that ties the feature branch history into main.

The benefit is full traceability. Anyone reading the log can see exactly which commits came from which branch.

  • Click the Issues tab in your repository.
  • Confirm that Issue #1 now shows as Closed. GitHub closed it automatically because your PR body contained "Closes #1".

Why did the Issue close automatically?

GitHub recognises keywords like closes, fixes, and resolves followed by an Issue number. When the PR merges into the default branch, the linked Issue closes. This only works when the PR targets the default branch (main).

Switch to main and pull the merged changes

The merge happened on GitHub's servers. Your local machine still has the old main branch without the merge commit. You need to pull the latest changes so your local copy matches the remote.

  • In your terminal in Cursor, switch back to the main branch by running this command:
git checkout main
  • Pull the merged changes from GitHub by running:
git pull origin main

Your terminal should confirm it downloaded the merge commit and updated your local files.

  • View your commit history by running:
git log

You should see a merge commit at the top of the log. It has a message like "Merge pull request #1 from..." followed by the commits you made on your feature branch.

  • Press q to exit the log viewer.

Not seeing the merge commit?

Make sure you ran git checkout main before pulling. If you pulled while still on the feature branch, switch to main and pull again.

If git pull shows "Already up to date" but you don't see the merge commit, confirm the PR was actually merged on GitHub first.

Why isn't my git log showing the merge commit after pulling?

Delete the feature branch

The feature branch has served its purpose. Its commits now live in main through the merge commit. Deleting stale branches keeps your repository clean and makes it obvious which work is still in progress.

  • Delete the feature branch from your local machine by running:
git branch -d feature/1-add-resources

What does the -d flag do?

The -d flag is a safe delete. Git only allows it if the branch has been fully merged. If you accidentally try to delete an unmerged branch, Git will warn you.

  • Delete the branch from GitHub by running:
git push origin --delete feature/1-add-resources
  • Confirm both deletions worked by running:
git branch -a

You should only see main listed. The feature/1-add-resources branch is gone from both local and remote.

Seeing an error when deleting the remote branch?

If you see "remote ref does not exist", the branch was already deleted on GitHub. This can happen if you clicked the Delete branch button on the merged PR page earlier. No action needed.

If the remote tracking reference still shows in git branch -a, run git fetch --prune to clean up stale references.

Help me troubleshoot deleting my feature branch on GitHub.

Your first full PR workflow is complete. You planned work with an Issue, built it on a branch, merged with a merge commit, and cleaned up. Next, you will try a second merge strategy that produces a cleaner, more compact history.

Create a Second Issue, Branch, and Squash Merge

You now have a merged Pull Request and a closed Issue in your repository. That's the core GitHub workflow in action.

In this step, you'll repeat the cycle with one key difference. Instead of a merge commit that preserves every individual commit from your branch, you'll use squash merge to condense all your feature branch commits into a single clean entry on main.

In this step, get ready to:
  • Create a second GitHub Issue for your next feature.
  • Build a feature branch with multiple small commits.
  • Open a Pull Request, squash merge it, and observe the difference in your git log.
Create a second GitHub Issue

Just like before, you'll start by planning the work in a GitHub Issue before touching any code. This time, you're adding a "Next Steps" section to your learning log.

  • Open your git-learning-log repository on GitHub in your browser.
  • Click the Issues tab near the top of the page.
  • Click New issue.
  • Enter a title like Add Next Steps section to learning log.
  • In the description, explain what you'll add. For example: Add a Next Steps section with future learning goals.
  • In the right sidebar, click Assignees and assign the Issue to yourself.
  • Click Submit new issue.

Note your Issue number — you'll use it in your branch name and PR description. It's likely #3 because GitHub numbers Issues and Pull Requests from the same counter.

Why plan with Issues first?

Issues create a paper trail that connects why a change was made to the code that implements it. When you link a Pull Request to an Issue, anyone reviewing your repository can trace decisions back to their origin.

Build a feature branch with multiple commits

This time you'll deliberately make multiple small commits on the feature branch. This simulates real work where you save progress incrementally. Later, the squash merge will compress them into one tidy commit.

  • Switch back to your terminal in Cursor.
  • Create and switch to a new branch called feature/3-add-next-steps:

✔️ I know how to do it

Go ahead and create the branch. Come back when you're on it.

ⓧ Walk me through it

  • Create and switch to the new branch by running this command:
git checkout -b feature/3-add-next-steps

What does this branch name mean?

The convention is feature/<issue-number>-<description>. You grab the number from the Issue title you just noted (no need to memorize it). This connects the branch back to the Issue it solves, so anyone on the team can trace the work.

  • Go back to learning-log.md in Cursor, and add a new section heading and one bullet point at the bottom of the file, below the ## Resources section:
## Next Steps
- Learn about rebasing and interactive rebase
  • Save learning-log.md.
  • Stage and commit this first change with the message Add Next Steps heading and first item:

✔️ I know how to do it

Go ahead and stage + commit. Come back when it's done.

ⓧ Walk me through it

  • Stage and commit by running these commands:
git add learning-log.md
git commit -m "Add Next Steps heading and first item"
  • Now go back to learning-log.md and add two more bullet points below the first one:
- Explore GitHub Actions for automation
- Practice contributing to open source projects
  • Save learning-log.md.
  • Stage and commit the second change with the message Add remaining next steps:

✔️ I know how to do it

Go ahead and stage + commit. Come back when it's done.

ⓧ Walk me through it

  • Stage and commit by running these commands:
git add learning-log.md
git commit -m "Add remaining next steps"

Why two separate commits?

You now have two commits on this branch. In a real project, you'd often have even more as you iterate. The squash merge will roll all of them into one clean commit, so the main branch stays readable.

  • Push your branch to GitHub by running:
git push origin feature/3-add-next-steps

Why no --set-upstream this time?

git push origin feature/3-add-next-steps gives Git the full address every time: "push to origin, on the branch feature/3-add-next-steps." Git has everything it needs for this one push.

git push --set-upstream origin feature/3-add-next-steps does the same push, but also saves the address so next time you can just type git push and Git remembers where to go.

This feature branch is going to be merged and deleted soon. There's no point saving the address if you're never going to push to it again. Just use the full address this one time and move on.

Your branch with both commits is now on GitHub, ready for a Pull Request.

✔️ Awesome, I've got everything!

Great. Double check you've saved learning-log.md and that the push completed without errors.

ⓧ I'd like to double check the full code

Here's what your full learning-log.md should look like at this point:

# My Learning Log

## About This Project
I'm learning Git and version control to track my work.

## Goals
- Understand how commits work
- Learn branching and merging
- Push my work to GitHub

## What I Learned Today
- Git is like a time machine for your files
- Every commit is a snapshot you can go back to
- Branches let you experiment without affecting the main project
- You can merge branches back together when ready

## Resources
- [Pro Git Book](https://git-scm.com/book/en/v2) - Free comprehensive Git reference
- [GitHub Docs](https://docs.github.com) - Official GitHub documentation
- [Oh My Git!](https://ohmygit.org) - Interactive game to learn Git

## Next Steps
- Learn about rebasing and interactive rebase
- Explore GitHub Actions for automation
- Practice contributing to open source projects
  • Open your git-learning-log repository on GitHub in your browser.
  • You should see a yellow banner that says Compare & pull request for your recently pushed branch. Click it.
  • Enter a descriptive title like Add Next Steps section.
  • In the description body, type Closes #3 so the Issue auto-closes when this PR merges.
  • Click Create pull request.

Check the Files changed tab

Click Files changed to see your diff. Notice it shows both commits' changes combined into one view.

Squash merge and sync locally

This is where things get interesting. Instead of preserving each individual commit, you'll squash everything into one commit on main. Teams often use this to keep the main branch history clean and scannable.

  • Scroll to the bottom of your Pull Request page on GitHub.
  • Click the dropdown arrow next to the green Merge pull request button.
  • Select Squash and merge from the dropdown menu.
  • Click Squash and merge again.
  • Click Confirm squash and merge.

GitHub condenses both of your feature branch commits into a single commit and adds it to main. Issue #3 auto-closes because your PR body contained Closes #3.

What is squash merge?

You made two commits on your branch ("Add Next Steps heading and first item" and "Add remaining next steps"), but your log only shows one entry. That's squash merge at work. GitHub combined both commits into a single commit before adding it to main.

This is useful when your branch has messy work-in-progress commits that don't add value to the project's long-term history. One clean entry is easier to scan than five "fix typo" commits.

  • Back in your terminal in Cursor, switch to main and pull the merged changes by running:
git checkout main
git pull origin main
  • View your commit history by running:
git log --oneline

You should see a single commit for the Next Steps feature. The number in parentheses (like #4) is the Pull Request number, not the Issue number. Compare this to the merge commit from Step 3. The squash merge produced one clean line instead of separate commits plus a merge commit.

Merge commit vs squash merge in your log

After Step 3, your log showed a merge commit with a message like "Merge pull request #1". That preserves every individual commit from the branch.

After squash merging, your log shows just one commit. All the branch commits were condensed. Teams choose between these strategies based on whether preserving fine-grained history matters for that particular change.

  • Delete the local feature branch by running:
git branch -d feature/3-add-next-steps

You'll see an error saying the branch is not fully merged. This is expected after a squash merge.

Why did -d fail?

In Step 3, -d worked because the merge commit preserved your original commit hashes. Git could see them in main's history and agreed the branch was safe to delete.

After a squash merge, Git creates a brand-new commit with different hashes. Your original branch commits don't appear in main's history anymore. So -d thinks the branch isn't merged, even though the content is there. -D bypasses that safety check and force-deletes the branch.

  • Force-delete the branch by running:
git branch -D feature/3-add-next-steps
  • Confirm the branch is deleted by running:
git branch

The feature/3-add-next-steps branch should no longer appear in the list. If you see other branches from earlier work, that's fine.

Your repository now has two merged Pull Requests using two different merge strategies. You've experienced the full GitHub collaboration workflow from planning to merge.

Secret mission

Add a Pull Request Template

Your PRs so far had great descriptions because you wrote them from scratch. But on a real team with dozens of PRs a week, people forget to include context. Add a PR template to your repository so every future Pull Request starts with a structured checklist automatically.

Clean Up Your Resources

Clean Up Your Resources

This project uses only free GitHub features and local Git. There are no ongoing costs or paid resources to worry about.

Resources you used:

  • Local git-learning-log folder on your Desktop.
  • GitHub git-learning-log repository (Issues, Pull Requests, branches).

Keep everything running

No action needed. Choose this if you want to keep building on your repository or use it as a reference for future projects.

  • Your GitHub repository, Issues, and Pull Requests are free to keep indefinitely.
  • Your local folder takes up minimal disk space.
  • The PR template will auto-populate every future Pull Request you open in this repo.

Pause - I'll come back to this later

There is nothing to pause for this project. GitHub repositories, Issues, and Pull Requests have no running processes or recurring costs.

  • Everything stays exactly as you left it whenever you come back.
  • If you want to free up Desktop space, you can delete the local folder and re-clone later with git clone.

Delete - I don't want to use this again

Remove all project resources from your machine and GitHub.

  • Delete the local folder by running the following command.

macOS

rm -rf ~/Desktop/git-learning-log

Windows

rmdir /s /q %USERPROFILE%\Desktop\git-learning-log
  • To delete the GitHub repository, go to your repository page on GitHub.
  • Click Settings in the top navigation bar.
  • Scroll to the bottom of the page to the Danger Zone section.
  • Click Delete this repository and follow the confirmation prompts.

This is permanent

Deleting a GitHub repository removes all Issues, Pull Requests, branches, and commit history. This cannot be undone.

Nice Work!

Nice Work!

You just leveled up from solo Git user to team-ready collaborator. Your git-learning-log repository now shows a polished collaboration history with closed Issues, linked Pull Requests, and two merge strategies in action.

What you learned:

  • Opened Pull Requests with descriptive bodies that link to GitHub Issues and auto-close them on merge.
  • Merged PRs using two strategies: merge commit to preserve full branch history, and squash merge to condense multiple commits into one clean entry.
  • Synced your local repository after remote merges and cleaned up stale branches to keep your project tidy.
  • Secret Mission: Added a PR template that auto-populates a structured description for every future Pull Request in your repo.

Ready to quiz yourself?