The Complete Beginner's Guide to GitHub

As you’ll recall from the last post, when we tried to cherry-pick our bug fix from the feature branch into the main, Git wasn’t sure what we wanted the finished file to look like and forced us to tell it ourselves. That shouldn’t have happened in the particular situation we dealth with last time, but today, we’ll be looking at situations where we would actually expect that to occur. Merge Conflicts When moving code from one branch of a repository to another, a merge conflict occurs when there have been commits to both branches that change the same line of the same file since the last time the branches were synced with each other. In this situation, Git needs to be told which version of that line you want to keep in the final result. Log into GitHub.com and create a new private repo initialized with a README file. The README will be initialized with a heading containing the name of your new repo. After creating the repo, click the pencil in the top-right co...

We’ve now dealt with two ways to move code from one branch of a Git repository to another: merging and rebasing. Both merging and rebasing transfer all of the code currently on the source branch to the destination branch, which is not always desirable. To move only some of the source branch’s code to the destination branch, we use a procedure called cherry-picking . No one found the bug from last week’s program, which doesn’t surprise me since it’s a subtle one. The bug is actually twofold, and both aspects have to do with how the Tkinter GUI toolkit handles modifier keys. The first aspect of the problem is that the keybinding Alt-c is only triggered when the focused window receives a lowercase c . If the user has Caps Lock on, pressing Alt and the C key will send a capital C , and the keybinding will not trigger. Open GitHub Desktop to the add-counter branch of the rcp-demo repository we were working in last week, and open the file helloWorldGUI.py i...

Thus far, we’ve only dealt with one way of moving code from one branch of a GitHub repo to another: by merging the branches. This is by far the most common way that code moves from one branch to another, but it is not the only way. In particular, merging is generally used to move code from feature branches back into the main. Let’s now look at rebasing , a way of moving code from the main branch into a feature branch. Rebasing a Branch Rebasing allows you to update your feature branch to reflect changes that have been made to the main branch since the feature branch was created. If, for example, another developer commits changes onto the main branch that affect the same functionality you’re changing in your feature branch, you can rebase your feature branch so that the feature branch includes that other developer’s changes. This lets you ensure that your changes will work correctly with the code on the most up-to-date version of the main branch, not just with...

In the previous post, we discussed the basic GitHub workflow: create a feature branch, do work on the feature branch (committing changes as you go), push the feature branch, create a merge request, and pull the updated code once the merge request is accepted. In the push step and the pull step, we interface between our local copy of the repository and the copy of the repository maintained on GitHub.com (the remote repository ). Let’s go into more detail about remote repositories and how GitHub Desktop can interact with them. Public and Private Repositories Log into GitHub.com. You should see a list of your repositories in the left-hand sidebar. If you hover over the desktop-tutorial repository we created in the last post, you should see that GitHub automatically created it as a private repository , meaning that only you and anyone to whom you explicitly grant access can see the repository and the code it contains. Let’s create a new repository on GitHub.com. Click t...

If you’ve been following along with the last two posts, you should now have a basic idea of what GitHub is and how it works, and you should also have the infrastructure in place to start using it. Now let’s create our first repository. Open GitHub Desktop and click the blue “Create a tutorial repository…” button at the top of the left-hand column. Then click “Continue” in the dialog box that shows up. You will be prompted to authorize GitHub Desktop to access your GitHub account; as in the previous post, click the green button to authorize. You may need to reenter your GitHub password. You will then be taken to the screen below: The first step when using GitHub is to create a branch . You can see in the toolbar at the top of the window that one branch, main , has already been created for us. This is the default branch for our repo. In a repository containing executable application code, the main branch is usually the most recent stable version of the application. For thi...

Welcome back! Now that we have a basic overview of what GitHub is, let’s get ready to start using it. In order to do that, we need two things: a GitHub account and the GitHub Desktop client. Let’s handle the account first. Creating a GitHub Account Go to github.com , enter your email address in the box in the middle of the screen, and click the green “Sign up for GitHub” button. Enter a password and click “Continue.” The password must either be at least 15 characters long or be at least 8 characters long and include both a number and a lowercase letter. After clicking “Continue,” you will be prompted to enter a username. The username may contain only letters, numbers, and hyphens, and must not be a username that is already in use by another GitHub user. Click “Continue” again. You will now be asked whether you want to receive email updates and announcments from GitHub. Enter y to receive such updates or n to opt out, ...