Introduction

In the articles we’ve posted thus far, we’ve worked with git and saved changes by making commits on our local system. This is one way to use git i.e like a local backup system wherein we save the state of our files so that we may revert back to a specific state of a file if and when required. In this article, we will demonstrate how we may integrate our local git repositories with the GitHub code hosting and collaboration platform and also explain important terms and related vocabulary along the way.

Given below is a pictorial representation of how to create, use and integrate our git repositories on local and remote systems.

We may refer to this representation on multiple occasions throughout the length of this article.

What is a remote?
Using git as a local backup system is good but it’s not good enough because we may lose the local system and the data along with it in an unlikely event. So we may end up losing all our work. Now let’s introduce the term ‘remote’.
In simple terms, you may consider a remote as any folder or place where you did not type ‘git init’ to create your git repository initially. The most common remote that we see is some cloud or Internet-based services. Among these services, GitHub is a very popular one.

What is GitHub?
GitHub is a service which stores all the git related information that you had on your local computer. It allows you to have an unlimited amount of repositories as long as they are open source and publically available. You could even use GitHub as a project management software.

You can have issues which are a good way to document code bugs. You can have pull requests which is a way to add small bits of changes to your code. You may also have a wiki where you may store some information related to a project.

We would like to add that github isn’t the only service that stores git repositories. Given below are two popular alternatives to GitHub:

1) Bitbucket
2) Gitlab

Signing up on GitHub:
Signing up on GitHub is a fairly simple process. All you really need is a valid email address and an internet connection. Open https://github.com and you’ll be brought to the signup page as shown in the screenshot below:

 

Using GitHub as a remote:
For the purpose of this article, we will be using GitHub as a remote. It takes all of the commits on our local computer and makes a local copy of it. The way we interact with the local computer and the remote is by means of pushing code to the remote and pulling code from the remote. We can have multiple remotes i.e. we can save our git repository to multiple locations. By default, our primary remote location is called origin and this is a convention that is followed throughout git related documentation.

When you log in to GitHub you’ll be brought to the below page:

Click on ‘start a project’ to create a new repository. This will bring you to the below page where we will provide a name for our repository along with a description. We may keep the repository public or private and initialize the repository with a README and .gitignore file. The repository I’ll be using already has a README file so I won’t initialize one here. We can also specify a license outlining how we intend our code/files to be used. After we’ve entered the information, we need to click on ‘create repository’.

The name for the repository we give here does not have to match the git repository on our local system. But when we or other people copy our repository from github then the repository will be copied using this name. Initially, we will be using https protocol to establish communication between git and GitHub. In a later article, we will demonstrate how we could use ssh instead of https so that we do not need to type in credentials every time we communicate with github.

Now we move to the command line where I have created a local git repository in the folder /home/sahil/git/scripts_for_training. This contains a couple of shell scripts that I had created to be used for explaining bash shell scripting concepts for an organizational training. So now we’ll use github as our remote, named as the origin and will push code from our local repository to github. Given below is the command we need to type to accomplish this task.

[sahil@linuxnix scripts_for_training]$ git remote add origin https://github.com/sahilsuri007/shell_scripts_for_training
[sahil@linuxnix scripts_for_training]$ pwd
/home/sahil/git/scripts_for_training

Note that this command needs to be typed from within the folder in which our git repository resides. Once this command executes successfully, the term origin becomes a shortcut for the entire URL.

If we execute ‘git remote -v’ we get the following output:

[sahil@linuxnix scripts_for_training]$ git remote -v
origin https://github.com/sahilsuri007/shell_scripts_for_training (fetch)
origin https://github.com/sahilsuri007/shell_scripts_for_training (push)
[sahil@linuxnix scripts_for_training]$

Notice that both the remotes are named origin.
We have a fetch URL and a push URL indicating that we could fetch code from one place and push it to another place and these URLs will generally be the same. To push our repository from the command line to GitHub, we use the git push command. This asks for our github username and password.

When I tried to push my changes to github, I was greeted with an error.

[sahil@linuxnix scripts_for_training]$ git push origin master
Username for 'https://github.com': sahilsuri007
Password for 'https://sahilsuri007@github.com':
To https://github.com/sahilsuri007/shell_scripts_for_training
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/sahilsuri007/shell_scripts_for_training'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

As a fix for this, I pulled the repository I had created from origin (github) to my local computer using git pull.

[sahil@linuxnix scripts_for_training]$ git pull origin master
From https://github.com/sahilsuri007/shell_scripts_for_training
* branch master -> FETCH_HEAD
Merge made by the 'recursive' strategy.
LICENSE | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 LICENSE

Now I tried the ‘git push’ command again and this time it worked.

[sahil@linuxnix scripts_for_training]$ git push origin master
Username for 'https://github.com': sahilsuri007
Password for 'https://sahilsuri007@github.com':
Counting objects: 32, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (30/30), done.
Writing objects: 100% (31/31), 5.63 KiB | 0 bytes/s, done.
Total 31 (delta 13), reused 0 (delta 0)
remote: Resolving deltas: 100% (13/13), done.
To https://github.com/sahilsuri007/shell_scripts_for_training
b3a0afa..059fdd9 master -> master
[sahil@linuxnix scripts_for_training]$

The .git folder in our repository which gets created when we typed ‘git init’ gets compressed and shipped off to github or the remote that we are specifying. Git doesn’t store a new version of a file every time we make a commit rather it stores the individual differences between subsequent commits. So, there is not a lot of extra space being consumed when we start using git. The only time an entire file gets copied will be the case when git can’t resolve the individual differences between subsequent versions of the file. Examples of such files could be some pdfs, word and excel documents. If git is unable to obtain a clean diff between file versions then it will create a new copy of the file. After we’ve pushed our changes if we now take a look at the repository we created on GitHub we will observe that it has been populated with the files that we had pushed to it from the command line of our local system.
GitHub renders the README.md file on the repository page itself. This helps people in understanding the content/description of the repository without having to download the repository files.

 

Conclusion

In this article, we demonstrated how we could push/store git repositories from our local system to GitHub. We hope that this article was useful and we look forward towards your feedback and suggestions.

Post Views: 9,427
The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.