Dev ToolsGitHub

Local work

The model of work

Imagine, you have a repository hosted on GitHub with a project that you are going to develop. It may be a forked repository or an original one, the main is that you have a full access to it.

The standard approach to work with a project is to have a local copy of the repository and commit your changes to this copy rather than to remote repo hosted on GitHub through the web interface. This local repository has the full version history of the project which can be useful when developing without an internet connection. After you've changed something in the local repo, you can push your changes to the remote repository to make them visible to other developers.

The picture below shows the model of how to work with GitHub.

The model of work with GitHub

This picture demonstrates two separated areas: GitHub and your computer.

First, consider the GitHub's area. There are two repositories:

upstream is an original project's repo that you have forked
origin is your fork (copy) on GitHub to which you have full access

To provide changes from your fork to the original project's repo, you need to make a pull request as we did before.

If you want to make small changes in your repo (fork), you may use GitHub's web interface. But this approach is not convenient when developing programs, because you often need to run and debug them locally. The standard way is to create a local clone of a remote repository and work with it locally, periodically pushing changes to the remote repo.

Installing Git

In order to continue this tutorial, you need to install Git locally, if you do not already have it. Just follow these instructions according to your operating system. If you do not like this manual, you may Google another one.

To check that Git was successfully installed, enter the command below in the terminal to display the version of your Git:

git version

If it works, lets set your name (first and last), and an email associated with your GitHub account:

git config --global user.name <YOUR_NAME>
git config --global user.email <EMAIL>

Cloning a repo

Now you need to clone your fork (origin) of our educational repository on your computer. Find the Clone or download button within the repo and click it to show the address of the repository for cloning.

Open your command line or terminal and enter the directory where you would like to copy the repository. Then just write git clone and insert the address:

git clone https://github.com/hyperskill/intro-to-github.git

Now, you have a local repository of the project.

Note, you can switch to use SSL protocol instead of HTTPS to clone a repo. We will not consider this case here, but you may learn and do it if you would like (e.g. developers often prefer SSL in practice).

Modifying contents locally

Navigate to the directory of the repository and look at the content. The local repo includes all of the files, branches and commits history like the remote repository. Type the special command to verify the state of your repo:

git status

Now your working copy is actually on the master branch of your local repo. And it does not have differences with the origin (fork) master branch.

On branch master
Your branch is up-to-date with 'origin/master'.

To make changes in your repo, first, you will create a branch to protect your master branch. Type the command below:

git branch edit-readme

After the command is executed, the branch exists, a new branch will be created, but you are still on master. You may check it using status as above.

To get another branch, use checkout with the branch name:

git checkout edit-readme

Now you are on the created branch.

git status

The result:

On branch edit-readme
nothing to commit, working tree clean

The basic workflow goes something like this:

You modify files in your working copy.
You selectively stage changes you want to be part of your next commit.
You perform a commit that includes your changes.

Let's make some changes. Open the README.md file and change something in it. After check repo's status again and you will see, that the file was changed.

modified:   README.md

And then stage this changes using add:

git add README.md

Now you can commit these changes in your local repo with a descriptive comment:

git commit -m "Add information about local repository in readme file"

You may make as many commits as you need and includes different types of changes to them: adding new files, deleting and modifying existing ones. Do not forget to stage them using add before performing commit.

Pull & Push

It is important that commit adds changes only to your local repository. If you want to propagate them to the origin repository on GitHub, you will use push.

The first time, you need to push your local branch as well because it does not exist in the remote repo.

git push --set-upstream origin edit-readme

The next time it is easier to do:

git push

To get changes from origin made by someone else, use pull:

git pull

One of the good cases is to execute pull periodically, especially before pushing, to prevent possible conflicts when someone else has changed the files in the repository in the same branch. Now we will not learn conflicts and how to prevents them, it will be studied in topics related to the team development.

After you have pushed your branch with changes, you may find it on GitHub and create Pull Request to the original (upstream) repo as we did it before.

There is another problem that we have not yet considered - the original repository may be changed while you are working in your fork and you need to synchronize your local and remote repositories with these changes. This problem will also be addressed in other topics.

As a recap

As the end of this stage, you have to understand what a local repository is and how to change files locally, and then propagate the changes to a remote repository hosted on GitHub. Perhaps working with the command line with Git seems difficult for beginners, but we will learn how to perform the same commands more easily using a convenient user interface.

How did you like the theory?

Report a typo

Cookie Preferences