GitHub for Beginners: Answers to some common questions

Common Git questions, answered

If you're new to Git and GitHub, a few concepts tend to trip people up more than others. We've rounded up some of the most frequently asked questions from beginners and walked through the answers step by step.

What is SSH and how do I add an SSH key?

SSH, or Secure Shell, uses a key pair stored on your computer. The private key stays on your machine and should never be shared. The public key is what you give to services like GitHub. When you push or pull code, Git uses your private key to verify you identity, matching it against the public key you've stored on GitHub.

To create a key pair and add your public key to GitHub:

1. Open a terminal and enter the following command, replacing the email placeholder with the email address you use for GitHub:

ssh-keygen –t ed25519 – C [email protected]

2. When prompted for a file to save the key, press Enter to accept the default.
3. Enter and then confirm a passphrase. The terminal won't display your input, so watch for typos.

Next, add the key to your ssh-agent, a program that securely stores your keys so you don't have to re-enter your passphrase constantly:

Run the following command to add the new SSH key to the ssh-agent, entering your passphrase when prompted:

ssh-add ~/.ssh/id_ed25519

With the key created and configured, now add the public key to GitHub:

1. Run this command in your terminal to display the public key:

cat ~/.ssh/id_ed25519.pub

2. Copy the entire output.
3. Go to github.com in your browser.
4. Click your profile picture in the top-right corner and choose Settings.
5. Select SSH and GPG keys from the left-hand menu.
6. Click the New SSH key button.
7. Give the key a descriptive title, like "work-laptop."
8. Paste the copied key into the "Key" box.
9. Click Add SSH key.

What are Personal Access Tokens and how do I create them?

A Personal Access Token (PAT) is a credential you create on GitHub for tools that require authentication. You control what permissions it has and can revoke it at any time. PATs are commonly used for command-line or API authentication.

GitHub offers two types of PATs: fine-grained and classic. To create a fine-grained token:

1. On github.com, go to Settings from your profile picture menu.
2. Scroll down in the left column and choose Developer settings.
3. Expand Personal access tokens and select Fine-grained tokens.
4. Click Generate new token.
5. Add a clear name and description, such as "cli-access" with a description of "access the Copilot CLI."
6. Set an expiration date that fits how long you need the token to work.
7. Under "Repository access," pick which repos the token can access — or limit it to specific ones.
8. Under "Permissions," click Add permissions to grant the token only what it needs, choosing between read-only or read-and-write for each.
9. Review the settings and click Generate token at the bottom.
10. Copy the token immediately and store it somewhere safe, such as a password manager. GitHub will only show it to you once.

For a classic token, the process is similar:

1. Navigate to Settings from your profile picture menu on github.com.
2. Scroll down and pick Developer settings.
3. Expand Personal access tokens and select Tokens (classic).
4. Click Generate new token and select Generate new token (classic).
5. Give it a name like "terminal-access."
6. Set an expiration date.
7. Select the scopes for the token to define its access level.
8. Click Generate token and save the token somewhere safe, since you'll only see it once.

When a terminal session asks for your GitHub password, you can paste a classic token instead.

Merge vs. rebase, and fixing merge conflicts

A merge conflict happens when two changes affect the same part of a file and Git can't decide on its own which version to keep. The GitHub UI makes it straightforward to sort out:

1. Open the pull request with the conflict. GitHub will show a warning that it can't be merged automatically.
2. Click Resolve conflicts in that warning.
3. Use the on-screen editor to pick the correct version of the file for each marked conflict.
4. Once every conflict marker is resolved, select Mark as resolved.
5. Repeat for every conflicting file.
6. Click Commit merge to finish.

Merging combines branches by creating a commit that ties both histories together, preserving the full record. It's the right choice when you want to keep the complete story of how changes unfolded, such as bringing a feature branch into main.

Rebasing instead rewrites your branch's commits on top of another branch's latest state, producing a linear, cleaner history. Use it when you want that tidy sequence — for instance, pulling recent main changes into a feature branch before merging.

Undoing a commit

If you've pushed a commit and want to undo it through the GitHub UI:

1. Open the commit on github.com.
2. Click Revert at the bottom of the commit.
3. GitHub creates a new commit that reverses the previous one. This doesn't erase history; instead it adds a change that cancels out the earlier edit. You can merge the revert commit directly or open a pull request to review it first — safer when others might be using the branch.

For changes that haven't been pushed yet, you can revert locally:

git reset --soft HEAD~1

That removes the commit from your local repository but stages your work, so nothing is lost. If you'd rather reset your workspace entirely, this command does that — just be aware it may discard your changes:

git reset --hard HEAD~1 

Forking and keeping your fork in sync

Forking creates a personal copy of a project so you can modify it without impacting the original. Here's how:

1. Open the repository you want to fork on github.com.
2. Click the Fork button at the top.
3. Choose the Owner, usually your own account.
4. Keep or change the Repository name.
5. Click Create fork.
6. Use the Code button to clone your new fork locally.

A forked repository can quickly fall behind the original, called "upstream." To sync via the GitHub UI:

1. Open your forked repository's main page on github.com.
2. Click the Sync fork button.
3. Select Update branch to pull in the latest changes from upstream.

You can also sync from the command line:

1. In a terminal, go to your local repository.
2. Set the upstream remote, updating the URL in this command to point at the original repository:

git remote add upstream YOUR_ORIGINAL_REPOSITORY_URL

3. Fetch the upstream changes:

git fetch upstream

4. Merge them into your project. This command assumes the upstream project's default branch is main:

git merge upstream/main

5. Finally, push the updates to your fork on GitHub:

git push origin main

Once you've done that, your fork and local copy are all aligned with the latest upstream state.

Practical tips for pull request reviews

A pull request (often abbreviated PR) is where code changes are shared and discussed. When you’re reviewing one, a few habits can make the process smoother for everyone involved.

1. First, understand the intent. Read the PR description and check for a linked issue, screenshots, or author notes. Knowing what the change is meant to accomplish tells you what to look for as you go through the code.
2. Work through the diff in chunks. Open the Files changed tab and review the changes group by group. If something is unclear, leave a comment directly on that line. Be specific so the author knows exactly what you’re referring to. You can also pull the branch locally or open a codespace to run the code yourself for better context. Use “nit” when a comment is optional and not required for merging.
3. Call out what works well. If you see code that’s organized, thoughtful, or instructive, say so. Positive feedback reinforces strong patterns and supports your teammates.

When the review is done, use the Submit review button to approve or request changes.

Copilot code review can also assist with understanding pull requests and spotting potential improvements. Your organization admin must enable Copilot for your repository or user account first. Once enabled, no extra setup is needed—Copilot code review shows up as an option in pull requests automatically.

1. Open a pull request on github.com where you want to use Copilot code review.
2. Select Reviewers in the top-right.
3. Select Copilot from the list of suggested reviewers.

Copilot finishes its review quickly. You can scroll down to read the comments it leaves. Copilot always leaves a Comment-type review, never an Approve or Request changes. That means its reviews do not count toward required approvals and will not block a merge.