Practical Guide to Git: Part II

Practical Guide to Git: Part II

Part II, deserves a follow up XKCD comic.

Creating a GitHub account and a Repository

Before we proceed forward we’ll need a GitHub account. Open www.github.com and create an account. Then click on the + sign at the top right and click on New Repository.

Enter a Repository name, have it set to Public (the default) and click on Create Repository. It will open a new page with a list of unix shell commands and an address bar with HTTPS/SSH link.

We are already familiar with the first 3 commands in the above screenshot, now let’s look into the latter two. 

Working with Remotes

What is a remote? A remote is just a link to a repository that is stored on a remote server somewhere. Our goal is to align the contents of our local repo to the one on the server. So we’ll use the git remote add command to add the link. Now, there is a convention that the main remote of your own repository is to be called origin, as when we fork, and clone someone else’s repository, we’ll have the same name and if we want to contribute to someone else’s repository with code, usually that remote is called upstream. This will make more sense as we progress through the guide, so don’t worry. Make sure you are in the git initiated repository and in the unix shell enter:

git remote add <remote name> <remote link>

put in origin for the remote name and paste the HTTPS link, as the SSH one will require more setup steps, such as generating keys, which we’ll skip it for now. Once you finish the guides, I strongly advise you to spend 5-10 minutes and setup the SSH one, as to avoid entering your username and password every time you want to push the contents of local repository to the server.

Congratulations, you now have your first remote connection to your local git changes. Now, we want to push our local contents to GitHub.com. So we can run the command:

git push origin master

breaking down the command, git push shows the intent, origin is the remote, master is branch to which we want to push to. Again, by default the main branch you get is master, as explained in the Part I post on the blog. So the actual syntax is actually: 

git push <remote name> <branch name>

You can now refresh the GitHub page and you’ll see your files uploaded and the README.md file, which has now become a part of the landing page for your repo. You can now make changes locally in any of the files. Do git status to check, if changes are reflected, git add . if you’ve created a new file, and then git commit -m "commit message" to make the commit, and now git push origin master.

The opposite action is git pull. If you make changes to the README.md from the GitHub website, and want these to reflect on your computer locally. Run

git pull origin master

and open the file contents to the reflected changes. In the background, git pull executes two commands – git fetch and git merge, which download the remote contents locally and then merges them into your local repo. This action as you can imagine is the origin of many of the headaches in Git, to be covered in Part III.

Repository Forking and Git Clone

Now that we know how to work with git locally and upload/download our contents remotely. Let’s focus on the other use cases. You will often be in a position where you’ll be working on someone’s code. Assuming they have a repo on GitHub already. It’s unlikely that they would have provided free access to everyone to update the code directly, as it takes one malicious person to destroy a lot of hard work. So the steps are as follows. Open a Repo you want to work on, let’s say. Microsoft’s TypeScript: https://github.com/Microsoft/TypeScript and click on the Fork button at the top right.

It will create a copy of it in your GitHub account, as if you’ve written it and you will have absolute control over the code in your repo. You can now use the git clone command to download the contents locally. You need the link for your fork first. Click on the green Clone or Download and copy the link from the popup box.

now you can run

git clone <forked repo link>

and it will create a folder called TypeScript with all the files in there. You make your edits of the code, and push the changes to your origin master for that repo. However to get the changes to the original repository, you are to create what is known as a Pull Request (the button on the left in the above screenshot), where it will compare your fork contents with the master repo and then the owner of the original repo has the power to merge your changes to the main one or have a chat discussion with you before doing so.
You are now 80% ready with how to use Git & GitHub. However, the juiciest bits are yet to come.

In Part III, we’ll cover merging and rebasing of different branches and how to keep the code you work on up to date, along with the most common issues encountered.

Leave a Reply