Introduction To Git With a Little Taste of HTML and CSS


I know there are many tutorials on Git out there and it may not seems a great use of time to write a new one. However, I’m writing this for my recitation hoping it would benefit everyone. Therefore, I will not spend too much time writing same things over and over. Instead I will link to other tutorials and pages.  Also I will include few tips to keep your code well organized and modular when your writing HTML, CSS and later one when your writing backend codes.

What is Git?

From their website:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

From Wikipedia:

Git is a distributed revision control system with an emphasis on speed, data integrity,and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development.

Git has been widely used by development groups of any sort and it became extremely popular when Github was introduced. Here I found a ranking of Version Control softwares like Git and SVN. You can see that Git is the second most popular (though there are not that many voters). SVN is much more commonly used due to the fact that was introduced earlier and is a little easier to use. However, it lacks many features that seem to be necessary as the size of your code and team grows.

  • Git is decentralized, meaning if you don’t have access to internet to push your changes to the centeral server, you can maintain a local series of versions and commit them as soon as you can and merges them with the changes from other members.
  • Git has a smarter merging algorithm
  • Git keeps less information needed to keep changes and needs less bandwidth to transmit changes to server (makes it faster)

However, the fact that Git is distributed makes it harder (a little) to learn, but once you learn it you will enjoy it.

Here is a list of Version Control softwares and comparison

If Git is so good why SVN?

So why some people still use SVN?

  • Will there can be many reasons for that. One that I can think if is that once you have it you don’t want to loose your history and you will stick to it.
  • Another can be because its easier to learn.
  • SVN is perfect for really small teams with minimal conflict in their work.
  • SVN is also really good for individual projects where your code doesn’t grow significantly and is less likely to have conflict with yourself 😀

Anyway, we are going to learn Git here but they are all similar and once you learn one it will become easy to learn others.


Where to start?

I personally know a couple really goof websites that provide Git and are pretty nice and FREE. GitHub is probably one that you already know, BitBucket is also a very nice website that provides private repositories for free. However, you can also get private repositories on GitHub if you have an edu account and in this tutorial I will be using a private GitHub repository since you (students) may want to make it public after the finals. It would be a good idea to keep your code clean, simple and modular and make it public. It will have good impact on your resume if you include it in your CV. I have asked may of my friends who have been or are recruiters and they all agreed that sometimes interviewers actually review your Git accounts and read your codes. Especially if you are using something they need and what you learn in this course (CS1520) is among requirements of many software engineering positions.
bitbucket_logo github-logo


Start with creating an account on GitHub. If you want to have private accounts with GitHub you should have an .edu email address. If you already have and account but with different email address use Go to Settings/Emails to change your email address or add a new address. You can see that I have to email addresses setup for my account:

Screen Shot 2015-01-26 at 10.09.56 AM

Then you should use the following link:


To request a discount for private repositories. Fill in the form for individual accounts. It may take a few days before you are granted one. So here we will continue our tutorial with public accounts. Creating a private account is almost the same way you create a public repository. So you should be fine as soon as you get our discount from Github.

Now, from the top menu click on the Plus (+) sign and select new repository.


Screen Shot 2015-01-26 at 10.13.16 AM



Next, select a name for your project and fill in the URL/Id and the description. Choose public if you don’t yet have the discount.

Screen Shot 2015-01-26 at 10.19.04 AM

Now you have your project repository ready and you should see the following if you have chosen to add a readme file.

Screen Shot 2015-01-26 at 10.19.16 AM


GREAT.  So far you have installed you have created you Github remote repository. Next, is to create local repositories on your own computers and connect them to this repository.


Install Git on your computer

installing git is actually pretty easy. I’m not going to re-explain it here since they have a nice page for it on their website. For installing Git visit this page.


Cloning the Remote Repository

Here I will explain how to create a local repository to start adding your codes to it. But before that I want you to know what is a remote repository and what is a local repository.

Local Repository: Is a copy of your code stored in an efficient snapshot-based way on your local machine. Therefore, your local repository will contain all versions of the code from you and any other developer if you synchronize it with the remote repository.

Remote repository: Is a version of your code with the change history stored on a publicly available to everyone or at least to all members of your team and contains all versions and changes from everyone on the team who have synchronized their codes with the server.


In order to create a local repository on your computer you have to first create a directory anywhere that you prefer to have the code. Next, from your Github repository page copy the URL for your project (right side menu)

Screen Shot 2015-01-26 at 10.46.00 AM


Next use Terminal, bash or CMD tools to go to the specific directory on your local machine and use the following command to clone the project.

You should have the following structure of files:

The .git directory contains all files for your local repository. Usually, you shouldn’t touch the files in this directory unless you really know what you are doing. The is created if you chose to create readme when you initialized the directory.  Otherwise, don’t worry you can do it anytime you want.

Great now we have a working copy of our repository and we will start adding files to it

Adding Changes to Local and Remote repositories.

First, lets create a simple html files to test our repositories. create index.html file in the root of your project (here is gittutorial) and copy the following code to it.

Now your directory should have the following files. Use ls in Mac/Linux and dir in windows to see the list:

If you open the file you should also see a title with a simple paragraph.

In order to add the new file to our repository we need to use the add command:

this commands add all the new files in the given root directory to the local repository. For example here we will use “.” which means current directory if we are in the project directory. Now our new index.html file is added to the files that git monitors.

Next, we want to commit the changes to the monitored files (including our new index.html files ) to the local repository using the commit command.

This will output:


Many people find it waste of time to write comments for commits. However, my experience on working with groups on especially long term projects has shown that its significantly important to do this. Finding the write version in a history of hundreds or thousands of commits is not easy and a simple comment may prevent you from reading the code over and over.

For a funny comment generator check out here. (Don’t use these :D)

If you have noticed we still can’t see the changes on our remote repository. This is because we only pushed changes to our local repository. Now lets try pushing them to the server. We can do this using the following command

This will ask for your username and password on GitHub and will output:

Notice that our project is already connected to our remote repository since we cloned it. If you want to connect them for the first time you can use the following command:


How to get changes from other developers

To test this, I will create a different local repository on my own computer mitigating the behavior of another developer. So, you can also as well create a different directory on your computer with any name such as “gittutorial2” and use the same clone command to clone the project.

Create a new style.css file in your new local repository with the following content and add, commit to the local and next push it the remote repository as explained above. Note, that you are going to do this with the same username. But, there is no difference between what you are doing and what other developers would do. As a matter of fact each local repository is an independent entity here. We are trying to push changes and update a different local repository and next remove conflicts. similar to using a git to maintain a clean version of your code at home, office and your laptop.


Now add, commit and push it to the remote repository as explained and check GitHub to make sure everything is on your remote repository.

Next, move back to your first local repository and use the following command to update your local repository using the latest changes on the remote one.

This will pull changes from the origin and master revision. You can use revision number/id to pull from a different revision instead of master which is the latest one. You should be able to see the style.css file in your first local repo too.

Now what?


Merging Conflicts (It hurts but its beautiful)

Something that happens often is that developers change the same files and same place on files at the same time and the commit to remote. The second committer will have to first pull all changes, but he will get a conflict error since the code that his trying to change is different on server and Git can’t figure out what to keep and what not to keep.

  • To do this change the content of your index.html file in both local repositories.
  • Next only commit and push the local repository one first.
  • Then commit and push the second local repository.

Now change the content of index.html in the second repository to:

But, when you try to push it, the first error yo you will get is:

As the hint suggests, this is because you are not working on the latest version of the remote repository. Now, you have to fist pull the current version.

Do this using the pull command

The output will be similar to the following:


This is because the changes are applied to same places and are different. Now Git doesn’t know which one to use and doesn’t want you to loose any of them So it will change your index.html file to the following keeping both:

You can see the HEAD which is your new commit and repo 2 is marked with <<<<<<HEAD. the = signs show the separation of the two versions and the older version currently on remote server finishes at >>>>>>>>>> revision number.

You can and should manually merge these lines by choosing one or a mix of both to the following and remove the marks.


Then update your local repository and the remote using the following commands:


Now you can see the your changes at repo 2 are committed and pushed successfully.


Few friendly advises:

  • Make your code as modular as possible to prevent conflicts
    • Use different python/php files for your backend code
    • Use different apps, modules and etc in different frameworks
    • Use different CSS files or HTML files in your code. If you and your friends are working on different parts of the projects not only its not bad to have multiple css files but also makes it readable too.
    • Commit changes only if they are stable so you wouldn’t miss other members code.
    • Commit small changes. Don’t wait for the whole milestone to finish before committing.
    • Don’t forget accurate commits. No matter how small your project be. you will face having at least hundreds of commits. Its not fun reading all of the changes in codes to find the one you want.
    • Write clean code (as always :D)
    • Use Branches (I’ll add a tutorial on this)

2 comments On Introduction To Git With a Little Taste of HTML and CSS

Leave a reply:

Your email address will not be published.

Site Footer