Quick and easy way to get started with Git & GitHub – a step-by-step guide

(Note: This blog post was originally published under my old domain(codesmiles.com), here. Web Archive link.

(This is an accompanying text article for the session I’ll be taking at Coimbatore .NET User Group this weekend)

In this fast paced post I will write about the simplest and quickest set of steps needed for getting started in Git & GitHub. Ultimately the aim of the post is to give a good essential idea of Git & GitHub ignoring whatever IMHO is not needed for anyone who is trying to get started, my aim is to make sure the reader could read & understand this post in 20 minutes or less. Also GitHub for windows has made things easier and I thought of spreading the word about it from my side.

In this post:

  • I will talk a little about the concepts of Git & GitHub
  • How to use “GitHub for Windows” and setup a GitHub based distributed source control system(if you are a non windows user, then still you’ll be able to learn the way Git & GitHub works from this post)
  • How Open Source projects on GitHub works

Before proceeding, I would like to tell you that using Git via command line is not so easy and has at least a tiny learning curve, but it is powerful. For developers who have used other popular source control systems this maybe bit difficult, so I thought of writing this blog post showing how simple it is to use GitHub windows application and simplify Git based SCM.

What is Git?

Git is a Distributed Revision Control System. It is developed by Linus Torvalds, creator of Linux. Git is used by many popular open source projects, I came to know because of many .NET open source projects, so it is not a Non-.NET/Microsoft kind of thing. Git’s performance is very high and it is its Unique Selling  Point(but it’s free Winking smile).

Git is primarily a CUI based system but there are tools to do GUI based interaction.

Why Distributed?

In short..

  • Repository is present in all clients where it is cloned, so server crash isn’t a problem
  • Each clone is a full repository, it contains all the code and version history
  • Provides several new workflows where it gets easier to isolate each user’s changes and easy to integrate changes of all the users, more info on various distributed workflows is here.

More about distributed version control systems here.

The Git & GitHub Jargon

Git’s workflow may feel strange or uncomfortable initially for many developers who got used to working in other version control systems, for instance, there is no word called check-in or check-out in Git.

So I would suggest that you understand the below terms before trying to use Git/GitHub to avoid confusion.

  • repo – repository – where your files and version history of them are stored
  • pull – pulling code from a repository(public/online) to your repository
  • push – pushing your changes to a repository, this is not the equivalent of check in, but it is Step 1 of the git’s way of check in
  • commit – commit the pushed changes, second & last step of the git’s way of check in
  • staged changes – changes that are pushed to a repository but not yet committed
  • clone – create a copy of the whole repository along with version history etc, brings the whole version control system’s stuff to this clone, this is a general term in several other version control systems
  • fork – forking creates a copy of a repository and provides a way for you to isolate your changes, there are provisions to merge your changes later into the actual repository(main repository/source repository)
  • pull request – you send a pull request so that the main repository admin will know that there are changes that you have done in your fork(your version of the repository) and you would like the admin to pull your changes and merge them with the main repository if she/he thinks it is fine
  • pull vs pull-request – pull is generally used when you pull files from a repository, but pull request comes into picture only if your workflow involves forking
  • merge pull-request to main repo – as said earlier, this means that the admin of the actual repository from which you forked will receive a pull request and will review the changed/added files and then merge them with the actual repository

Creating Repositories

After you create an account in GitHub and sign in, you will have a button named New repository, click it to create a new repository on GitHub server.



Provide necessary inputs as prompted.


(click to enlarge)

Setting up your system to work with GitHub

Before proceeding, go to windows.github.com and download and install the GitHub windows application.

Note that, up to my analysis, the GitHub for Windows application can be used with any git setup not just GitHub.

For easy reading I will use “GitHub” instead of “Git/GitHub” henceforth.


(click to enlarge)

In GitHub.com…

Once you create a repository as shown earlier, below screen will be shown.


(click to enlarge)

Note that it has the URL of your public online repository and a button named “Set up in Desktop” and help information on how to use command line interface to setup your machine to point to this repository. The next time you want to clone a repository, you go to its main URL and click the “Clone in Desktop” button as shown below.

ScreenHunter_170 Sep. 30 00.08 - Copy

(click to enlarge)

Now you can click “Set up in Desktop”, you will get the below prompt..

(Internet Explorer)

ScreenHunter_159 Sep. 20 02.14




(click to enlarge)

This button was not working in Firefox, I don’t know why.

Once you click Launch Application or Allow based on the browser you are using, GitHub windows application will be launched for you and if you have launched the application some time before and logged in to it then automatically the repo will be cloned, but I will show you the other way of what happens for the first time, when you have never used GitHub for windows.

Using GitHub for Windows

After the GitHub windows application is launched you should login to it with your GitHub credentials


(click to enlarge)

After logging in, below screen will be shown to configure the user information, user information is used for your commits as explained in the screen.



After initial setup, GitHub for Windows shows the below screen, which shows the local and github’s online repositories linked to this user.


(click to enlarge)

GitHub for Windows’ Options screen lets you configure various settings as shown below, you might want to take a look at this before proceeding.


(click to enlarge)

To access your GitHub repositories select github on the left section of the screen, which lists the online repositories you have. You can clone a particular repository as shown below, it will be cloned to the directory configured in the Options screen shown above.


(click to enlarge)

You can open the files’ location in explorer as shown below.


(click to enlarge)


I have created couple of files in this location as shown below. Now let’s see how we can move these files to the online GitHub repository, I mean Git’s way of checking-in.



GitHub windows application automatically detects that the repository is changed and shows the below screen. Now you can type a commit message and click commit as shown below.


(click to enlarge)


Next, you can see that the commit you just made is not yet published(pushed) to the GitHub server, click the publish button to publish the changes.


(click to enlarge)


Files are now pushed to GitHub server as shown below.


(click to enlarge)


Publish & Sync Vs. Push & Pull

I noticed that first time if files are added to a repository the above shown publish button is displayed. If the files are modified later in your local repository or if someone else modifies the files and commits them to the server, meaning whenever your local repo changes or whenever server repo changes, then the publish button becomes a sync button.

So, the sync button does two things..

  • Pushes changes you made in your local repository to github server
  • Pulls changes committed to the server by other users to your local repo


(click to enlarge)


Two Most Popular Collaborative Development Workflows in GitHub

Even though GitHub supports several workflows as discussed here. IMHO, I think there are two most popular workflows.

  1. General Collaborative Development – Single shared repository
  2. Collaborative Development in Public Repos/Open Source projects – involving Fork & Pull Requests

Workflow 1 – General Collaborative Development

A shared single repository with access permissions for users is setup, users can pull and push changes, we just saw above how you change your local repo and push(sync) with the online repo.

Workflow 2 – Collaborative Development in Public repos/Open Source projects – involving Fork & Pull Requests

In many open source projects people collaborate using this workflow in GitHub. This is not as complex as it sounds, just quickly review the jargon section again, now you should be clear about what is Fork and Pull request.

In general forking provides below benefits:

– Makes your own repo called a fork

– Provides freedom to change your version of the repo

– Isolated from the main repo

The below figure explains what happens in this workflow.

1. You Fork the Main repo, this creates your version of Main repo’s files; your version of the repository, your Fork.

2. You Make changes – Add/modify files and commit these changes

3. You send Pull request to the main repo which goes to the main repo admin

4. Main Repo admin reviews the code changes and accepts & merges your pull request

(sorry for the site name in the middle of the image, it is NOT for promo purposes, but just an attempt to stop plagiarism)

Hide/Show animation




In this post, I gave an introduction to Git and how distributed SCM could help you. Then we saw the jargons in Git & GitHub and we setup our system to work with GitHub and then created a repository in GitHub.com. Then, we used the GitHub windows application and cloned the GitHub repository and worked with it. Lastly we saw the collaborative development workflows and most importantly how open source projects work in GitHub.

I hope I have given enough information for you to get started in Git & GitHub.

Happy Coding!

Leave a Reply

Your email address will not be published. Required fields are marked *

Copy link
Powered by Social Snap