Hello Git!

Want to host your project on sites like GitHub using git and at the same time wish to do it with command line interface instead of graphical user interface? or, Looking for a quick reference to Git? or maybe you don’t wish to read the lengthy documentation to follow a fixed number of steps? or you wish to introduce yourself to git world?  Worry not, this blog will cover all that you need for hosting your projects on a platform like GitHub and say hello to git. Do you want me not to blabber anymore? OK, without wasting much of your time, let’s quickly get into this.

Without actually moving to the steps (because it is essential to know a little about it before following blindly), I want you to have an idea of what the terms mean and refer to. I am trying myself in explaining this to you with simple, layman words. However, if you do not find convincing, you may click on them to know more, from where they are taken and re-framed. Also for those who are new to Git, I should consider them, by saying that, you need to know the terms before moving onto following steps. Make yourself clear about the analogies and terms (Note: I am limiting the terms to what is required in the steps, there are many more) used in the steps before we proceed. And here I go:

VCS – Version Control System, is the management of the projects that you build, helps you to track your process in doing any kind of project and it allows you to use this system by a numerous tools. One such is Git. That means, if you ever want to look back to your own code and revert some changes, using the tools provided by VCS helps a lot. Obviously, you won’t be willing to make several folders, subdirectories to track each changes that you make while building a project.

Repository – A place where your project resides is repository. So, a local repository means a place where your own files are in the system. Remote repositories are versions of your project that are hosted on the Internet or network somewhere.

Branch – GitHub is a place where developers do collaborative projects. It becomes very essential that their work is separated from others, to avoid confusion and maintain clarity. Working on core code might be one such task, implementing features or fixing bugs might be another. The developers branch their work to obtain different versions. The main branch is your origin/master.

commit –  Whenever you want to make changes to your repository, you commit. And after you commit using commands from git, your changes in the project are reflected onto your system. You can add short messages as well.

push – After that you have done commit using commit, you would like this changes made onto a remote server or platform, like, one as GitHub. To make those changes available to your  GitHub repositories, you push the changes.

clone – Whenever you wish to make a copy of a remote repository, you clone it. In other words, you download it to your local system so that you can amend changes, update, etc.

Now one more useful thing to add after understanding some selected terms (you may always refer for more). When you are on the way to host your project on GitHub, you need to understand the levels it is going through. By levels I mean, the performing areas that it passes through. Suppose, you have created several files that constitute your project, in a directory. Now, this is your working directory i.e, the directory where you have started all the work. These files are untracked files (i.e, they are not known by git yet). To make git track your files, you add them so that it can be ready or be prepared to make the final changes. The moment you add them, you send your files to the staging area. You may take the word staging, as laying down the stage to perform something big. Here also, you are preparing your files before commit. At this stage, if you modify any file, you need to again add it. I hope till now you are fine with it. You have reached the staging area. Now, your task is to finally commit (or, make it happen). When you commit, you now have your local repository created, with all the files of your project.

Not to mention, I have a story told to me by Sayan, that could make things clear to you all the more:

You create a new character, Tux. Tux wants to be photographer, who has just bought a new DSLR. Tux plans to be the next travel photographer, who would take the best picture from the top of Mt. Everest. But Tux is a newbie, so Tux starts watching for YouTube tutorials for learning to post process the images. Tux creates a directory named *working* to put all un-processed images. Then, fires up DarkTable to process the images. Every time after a set of similar operations (like crop & rotate, shadows & highlights, etc), Tux creates a copy of the *working* directory and names it `snapshot-{n}. After a couple of operations, Tux stands having “snapshot-1”, “snapshot-2”, “snapshot-3”, …. , “snapshot-100” directories. This directories is history of how Tux developed the image over time. At any point, Tux can go back to a given snapshot and build again on top of it. It’s been a month now, Tux have learned a lot on post-processing images. Tux now mixes and matches multiple images file to create a snapshot directory. One day, Tux while processing the images, goes into experimental mode. and only after a while realized that the changes should be going into two different snapshot directories (`snapshot-139` & `snapshot-140`). Smart Tux quickly thought of an idea, creates a new staging directory. A staging directory works as an intermediate between the working directory and the snapshot directory. So, Tux now works on working directory, and one Tux is happy with the changes
Tux moves all changed files into staging directory, and then creates a copy of the staging directory as new snapshot directory.

Thanking Sayan for the awesome analogy which he mentioned here. Nice story, isn’t? Got cleared? OK, let’s move on to apply Git. Fire your terminal and go to the directory in which you have all the projects. Time to say Hello to Git. Skipping the installation of git in your OS, with the hope that you can follow this. Moving on to the steps:

1. Configure git settings.

You need to configure git, that is, you need to introduce yourself to git by giving your name and email. Perform as below by providing your name in the place of “Your Name” and email id in place of “Your email”:
git config --global user.name "Your Name"
git config --global user.email "Your email id"

Say, you are presently in a directory named git_demo, and you have files as hello.txt, gitfun.txt.

2. To make your current directory as git repository, you have to initiate git by:
git init

An empty repository is initialized, as you can see what it says.

3. Check your status. You will see the terminal mentioning of some untracked files (as I told you about the untracked files earlier). You can always perform this step whenever you wish to know the tracked and untracked files in the directory.
git status

Initially, you will see all the files as untracked.

4. To make git track your file, do
git add hello.txt

After performing this, your file directly goes into the staging area. Now, if you perform step 3 again, i.e, run git status, you will see that hello.txt comes under “Changes to be committed” and gitfun.txt comes under the heading “Untracked files”. Things are getting cleared, what I mentioned above, isn’t it?

If you wish to make changes to hello.txt, no problem, you can create changes.

5. To see the changes that are made to your file (i.e., what is deleted and what is inserted), do
git diff

Note: If you are modifying your file, you need to add it again (step 4) and you can check the status then (step 3).

6. You can also see the difference created in the staging area by
git diff --staged

7. At any point of time, if you feel that you want to unstage it, you may do this:
git reset --filename

7. Now that you are done with adding, be ready to commit. You add a short message along with it, so that, it helps you to comprehend the actual changes or the reason to change, etc.
git commit -m "Your message"

“Your message” can be “Created a new file” if you are committing for the first time. It may be “Updated the contents”, if you are updating the contents. You can simply mention anything you want.

8. To see the committed changes, you ought to do
git log

Now this will give you the information of the author (i.e, you if you have provided your own name and email id while git configuration), message which is committed, timestamp, commit ID.

You have successfully created your local repository. Now you would be willing to host it to GitHub. You should create an empty repository in GitHub before doing this. Say, you have created a repository named as project. After creating, you will see a URL under quick setup. Copy the URL

9. Add your files to the GitHub, perform as below. “Your URL” is the copied URL that you enter.
git remote add origin "Your URL"

To add a new remote Git repository as a shortname you can reference the URL easily (by default its origin). You can alternatively use any shortname in place of origin, but you have to use the same in the next step as well.

10. Push the files to the GitHub. This will require you to enter your GitHub handle and password.
git push origin master

This means that you are pushing your files to the master branch of your created repository.

Hooray! Successfully hosted your first ever project on GitHub!
Do make out time to follow ProGit or GitMagic for more detailed knowledge on Git.