Working with Remote Repositories

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 the green “New” button above your list of repositories. Fill in a name and a short description for your repository. Note that the create wizard defaults to creating a public repository. Public repositories can be used to host open-source projects to which anyone can potentially contribute by forking the repository and then using a merge request to propose that changes made to their fork be incorporated into the original repo. Since we’re just creating this repo for demonstration purposes, change it to a private repo. Check the box to create a README file, and then click “Create repository.”

GitHub will auto-generate the README file by filling in the repository name and description you entered in the creation wizard. We now have a repository with a main branch and an initial commit of the README file.

This created a remote repository on GitHub.com. To access and edit this repo through GitHub Desktop, we must clone it to our local machine.

Cloning a Repository

Open GitHub Desktop and click the “Clone a repository from the Internet…” button on the left-hand side of the screen. You will see a list of your repositories on GitHub.com. Select the repository you just created from the list and click “Clone.”

GitHub Desktop will show a progress bar while the contents of the repo are downloaded from GitHub.com, and then you will be taken to the familiar repository view from the previous post. Now you can start branching, editing, and committing changes in the same way as previously discussed.

Push and Pull in More Detail

In GitHub Desktop, create a branch called push-pull-test in the repo you just cloned. Use the keyboard shortcut Ctrl-Shift-A to open the README in Visual Studio Code and add some information to it. When you come back to GitHub Desktop, you should see the change comparison view in the main part of the window. Add a commit message in the bottom of the left-hand sidebar and then click “Commit to push-pull-test.”

The changes we just made only exist in the local copy of the repo, for now. Click the “Publish branch” button in the top toolbar or use the keyboard shortcut Ctrl-P to push your changes to the remote copy on GitHub.com. In a real project with multiple people working on it, you should push your changes regularly so that the rest of your team can see what you are working on. You should also regularly pull changes made by other developers from the remote repo into your local copy. This ensures that you will have the most up-to-date version of the code when you start work on a new task. To simulate a change made my someone else, we will use GitHub.com’s web interface to edit the README file further.

Open your repository on GitHub.com. On the left side of the screen, above the list of files, you will see a dropdown menu from which you can select which branch to view. Switch to the push-pull-test branch we just created.

Click on the README file in the file listing for the new branch, and then click on the pencil icon in the top-right corner of the file view to edit the file.

Add some more text to the file and type a commit message in the smaller text box at the bottom of the screen. Leave the “Commit directly to the push-pull-test branch” option selected and click “Commit changes.”

The remote repository is now ahead of the local copy by 1 commit; that is to say, there is 1 commit in the remote’s history that is not in our local history. To synchronize our local copy with the remote repo, we pull the changes from the remote repo into our local copy. Click on the “Fetch origin” button in the top toolbar. This will cause GitHub Desktop to query the remote repo to see whether there are new changes. In this case, there are, so the “Fetch origin” button changes to a “Pull origin” button. Click “Pull origin” to incorporate the changes from the remote repo into our local copy.

You can also fetch and pull in a single operation using the keyboard shortcut Ctrl-Shift-P.

Comments

Post a Comment

Popular posts from this blog

Cherry-Picking

Image
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...
Read more

Our First Repository

Image
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...
Read more

Getting Started

Image
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, ...
Read more