Answering the most common GitHub beginner questions

How do I add an SSH key to GitHub? Or undo my last commit? And what's the difference between merging and rebasing? Today, we'll answer those questions and much more. Hey, I'm Kadesha and I'm so excited that you're here with me today. I want to answer some of your most asked questions and to do so, [music] I've invited some of my engineering friends from GitHub. Hey Angela, what is SSH and how do I add my SSH key to GitHub? Good question, Kadesha. An SSH key, or secure shell key, is a pair of files on your computer that has two parts: a private key and a public key. The private key stays on your computer and should never be shared. The public key is what you share with platforms like GitHub. When you store your public key on GitHub, Git uses your private key to confirm your identity when you push and pull code. If your public key on GitHub matches the private key on your computer, you're authenticated. Let's set up an SSH key for your GitHub account. On your computer, open a terminal and type the following command, replacing the email placeholder with your GitHub email address: ssh-keygen -t ed25519 -c [email protected]. This will create a new SSH key on your machine. When prompted, click enter and accept the default file location. When asked for a passphrase, type one you'll remember. Remember that the passphrase is case sensitive. Now, let's add our new SSH key to the SSH agent. Learn more about creating and adding your SSH key to an SSH agent [music] by going to gh.io/gfbssh. An SSH agent is a program that securely stores your keys so you don't have to keep entering your passphrase. Now, if you use the default name, run this command to add your new SSH key to the SSH agent. SSH-add tilde /.ssh/id_ed25519. Now that it's added to the agent, let's get the public key for GitHub. In your terminal, run cat tilde/.ssh/id_ed25519.pub. Then copy the whole line that appears. Now, go to GitHub in your browser. In the top right, select your profile picture. Choose settings. On the left, pick SSH and GPG keys. Click new SSH key. Paste the key you copied into the key box. Give it a name like laptop or work machine. Then select add SSH key. And that's it. Your computer is now set up to securely connect to GitHub over SSH. Hey Liz, how do I add PAT to GitHub? Also, what is a PAT? Great questions. Let me explain. A personal access token, commonly called a PAT, is a special credential you create on GitHub for tools that need authentication. You control its permissions and can revoke it anytime. On GitHub, you'll commonly use a PAT to authenticate via command line or the GitHub API. To create a personal access token on GitHub, select your profile picture and choose settings. On the left side, scroll down to developer settings. Select personal access tokens. You can create fine-grained tokens and classic tokens. Today, we'll be making fine-grained tokens. Choose fine-grained tokens or your org's recommended option. Select generate new token. Give the token a clear name like CLI access and a description. Set an expiration date that matches how long you need it. Once the token expires, it will not work anymore. On the repository access, select the repositories you want the token to access. In this case, I'll choose the only selected repositories and choose GitFolio. Now, under permissions, we can choose the scopes for this token. In this case, I'll choose actions for workflows, issues, and pull requests. Add any other permissions that you need. Learn more about [music] personal access tokens by going to this link, gh.io/ghptokens. [music] We can now update the access for each permission to be read and write or leave it as read only. When you're ready, scroll down and select generate token. GitHub shows you the token once, so copy it and store it in a safe place, such as a password manager. If you want to create a classic token, in developer settings, click tokens classic, then click generate token. Give the token a clear name, like terminal access, and set an expiration date that matches how long you need it. Choose the scopes for this token. For Git operations on your own repos, select a scopes like repo for repository access and any others your workflow needs. When you're ready, scroll down and select generate token. a password manager. Next time Git asks for a password in your terminal, paste this token instead of your GitHub password. Hey Liz, what's the difference between merging and rebasing? And how do I fix a merge conflict? A merge conflict happens when two changes touch the same part of a file, and Git needs your help to decide what the final version should be. Let me show you how to use the GitHub UI to resolve a merge conflict. When you open a pull request that has a conflict, GitHub shows a message that the branch cannot be merged. Select resolve conflict. GitHub will show you the conflicting file with the markers. You can edit the file right in your browser. Choose the final version you want and remove the conflict markers. When you're done, select mark as resolved in the top right-hand corner. Then, select commit merge. Your pull request is now updated with the resolved conflict. Now, what are the difference between merging and rebasing? And when do you use each? Merging combines changes from one branch into another by creating a new commit that ties both histories together. It preserves the complete history of both branches. You merge when you want to preserve the pull history of how work happened. Very common for feature branches going into main. Rebasing moves or replace your branch commits on top of another branch, rewriting history to create a linear cleaner commit timeline. You rebase when you want a clean linear history, like updating your feature branch with the latest changes from main before merging. Hey Glenda, how do I undo my last commit? So, you want to undo that last commit you just made. No problem. Let's say you already push your commit to your branch. You can undo your last commit through the GitHub UI. Open that commit on GitHub and select revert. GitHub will now create a new commit that removes the changes from the earlier one. That commit doesn't erase history. It adds a new commit that puts things back. You can either merge the reverter commit or open a pull request with it. That is the safest options when others might be using the branch. If you haven't pushed to your branch and your changes are local, you can revert a commit by running this command. Get reset {dash} {dash} soft head tilde one. This removes that commit but keeps your work staged, so you don't lose your changes. You can use that get reset {dash} {dash} hard head tilde one if you want to undo your last commit and disregard the changes you made. Hey Emily, how do I update or sync a fork repository on GitHub? Forking a creates your own copy of someone else's project so you can explore or make changes without affecting the original repo. This is especially important when you want to contribute to an open source project. Here's how to do it in the GitHub UI and how to keep your fork updated. Open the repository you want to copy. In the top right, select fork. Choose where to create the fork. Give it a name if you want or keep the original name. Select create fork. You now have a full copy of the project under your account. To work on it locally, select the code button and clone it to your [music] machine. Learn more by going to gh.io/gfp-forks. To keep your fork updated in the GitHub UI, you can do the following. Open your fork on GitHub. Above the file list, open the sync fork menu. Select update branch. GitHub pulls in the latest changes from the original repository into your fork. This keeps your copy up to date. You can also do this via the command line instead of the UI. First, add the original project as an upstream remote. Run the following command. Get remote add upstream and add your original repo URL. Then, pull in the latest changes and run get fetch upstream and get merge upstream {slash} main. Or, if the project uses a different default branch, merge that branch instead. This brings the newest updates from the original project into your local copy of the fork. Push the merged changes to the repo on GitHub with get push and your forked repo will be synced. Hey Glenda, how do I review a pull request on GitHub? A pull request or a PR is a place to share code and talk about changes. Here are three helpful practice when reviewing a PR. First, start by understanding the goal of the PR. Open the pull request and read the description. Look for the issue it relates to and the or notes from the author. Knowing the purpose helps you understand why that change exists and what you're looking for. Next, review the code in a small sections. Open the files changed up. Move through the changes one group at a time. If something isn't clear, leave a comment on the line. Ask questions, offer suggestions, or let the author know if there is any better approach that you can see. Keep your comments as specific so that they know exactly what you're referring to. It might also help to open the code on your machine, either via the command line or in a code space, to run the code to ensure that you understand. Use terms like "nit" if your comment is not a necessary suggestion for merging the PR. Lastly, highlight what's going well. When you see code that's well organized, thoughtful, or teaches you something, mention it. Positive feedback reinforces good patterns and help teammates feel supported. When everything looks ready, use the review changes button to approve or request [music] updates. Learn more about reviewing pull requests by going to gh.io/ghprreviews. As a little bonus, Copilot code review can also help you understand pull requests and suggest improvements. Your organization admin needs to enable Copilot for the repo or your user account. Once Copilot is enabled, you don't need to install anything special. Code review appears directly in pull requests. When you open a PR, open the reviewers menu and select Copilot. Wait about 30 seconds for Copilot to complete its review, then scroll down to read through Copilot's comments. Copilot always leaves a comment review, not an approved review or a request changes review. This means that Copilot reviews do not count towards required approvals for the pull request, and Copilot's reviews will not block merging changes. Learn more about Copilot code review by going to gh.io/copilotcodereview. Remember, when reviewing a PR, understand the goal, review in small sections, and highlight what's going well. These three tips will help you review code like a pro. Thanks so much, Emily, Liz, Glenda, and Angela for answering our questions today. Next time you have a question about SSH, PAT, or rebase, you know where to go. Remember to check out the blog post that accompanies this [music] episode, and thanks so much for watching Get Up for Beginners.