How to Get Started with Git and GitHub

Today, I'm going to simplify Git and GitHub. What’s the difference? What are they for? And how can you start using these technologies in your own personal projects?

To start, what are Git and GitHub?

Git is an open-source version control system. It is used to manage different versions of your code as well as track any modifications made to your code. Using git, you can easily and quickly find what modifications were made, when they were made, and who made them. This is especially helpful if there is a bug in our code that wasn’t there in previous versions. Using Git, we can find older and working versions of our code, detect when bugs first appeared, and find a solution to our problems.

We can also organize our projects by creating different branches. Though that’s a little more complex. To get started with git, you can work with a single branch. As you practice with these tools and become more comfortable, that’s when you should start looking into branching. Atlassian has a really beginner-friendly article about one of many different branching strategies — the Git Workflow Branching strategy. The article will definitely highlight why branching can be beneficial.

But for now, we can skip over that.

So what about GitHub? GitHub is an online repository hosting system. In addition to providing a remote repository — basically a storage location for your project in the cloud — GitHub also provides a user-friendly interface for viewing all the data collected by Git. You can view branches, the history of changes to your code, and the modifications that were made to your code.

The General Process

So all of that information in the previous section was a giant mouthful — and I would not blame you if you don’t understand entirely. Let’s just talk about the general process to help you understand a little better.

We start off with our text editor, like VS Code. We create our out HTML, CSS, and JavaScript files. Now our project consists of files; it’s not empty. So since our project has files, now there are files that git can actually track.

Remember, git is used for tracking changes made to our code. Ergo, if you make changes to your code — like adding navigation bars, adding logic to buttons, or maybe adding media queries — you want those changes to be recorded by git.

So that’s what we do. When you make changes to your files, hit the save button in your text editor. Then with Git, you’re going to stage that file at its current state, commit that file, and add a commit message like “added navbars”. A commit message basically says what changes you made. In this way, when you look at your history of changes, you can understand what happened every time a modification was made.

Then you’re going to push that file and commit message to your remote repository located in GitHub. Now GitHub will hold the most recent version of your code (along with past versions).

Tutorial Time (plus Git Commands)

Preparations

To begin, we need to have a few things.

First, we need a GitHub account. If you don’t have one, sign up. It’s free.

Second, we need to install Git. It can be downloaded from Git’s official website. Select your operating system. Download and install. If you’re still a newbie, just keep hitting next during the installation process. You’ll be fine.

So when you install Git, it also installs Git Bash. Git Bash is the interface that we’re using to provide Git commands. If that’s a bunch of gibberish you don’t understand, don’t worry too much about it. You’ll understand as you follow along.

Lastly, we’re going to need a text editor. You can use whatever you want. I am going to use Visual Studio Code, aka VS Code. This is different from Microsoft’s Visual Studios application. You can install VS Code from their official site.

Now you have all the tools you need.

GitHub

So every time you create a new project and you want to upload it to GitHub, you have to create a repository. You can think of a repository as a storage space for your project, in the cloud.

To get started, open GitHub. At the top right corner, you should see a + icon. Hit it. It will open a dropdown menu, as shown. Click “New Repository” to create a new repository.

The directions are straightforward. Just follow the prompts.

If you want to learn more about the different options, keep reading. Otherwise, feel free to skip to the next section. It’s not important for beginners.

We start by inputting our project’s name in the Repository Name’s text box. You can also add a description for your project. It’s optional and can be changed later.

The public and private options are self-explanatory. It sets the visibility of your repository.

Now for the more interesting parts…

A README file is a file that describes your projects. It can include whatever you want. It can include an introduction, technology used, languages used, credits, screenshots, How-To-Install, How-To-Use etc.

For example, people publish frameworks, libraries, APIs, and a bunch of other cool tools that you can use in your projects. For those types of projects, developers want to tell other GitHub users how they use these tools in their own projects.

Here is an example: g-sheets-api. It allows you to pull information from Google Sheets and use it in your projects.

Here is an example: vanilla-lazyload. It allows you to load your images upon scroll to boost web page loading times.

Or for others, people publish games, CSS art, HTML layouts, or websites. Developers might use a README file to describe how the project was built.

If you’re really curious how other people use README files, just explore GitHub. There’s really no concrete way people use them.

Moving on, we have git ignore files. Within a .gitignore file, you write files that you don’t want git to track and upload into GitHub. A popular use for this is to hide API keys.

To use some APIs, you need a unique API Key that authorizes you to use it. This means that your API key will be somewhere in your JavaScript file.

The issue comes when you’re using an API that isn’t free. After x amount of requests (to the API), you’re going to have to start paying money for every request. For that reason, you don’t want your API Key to be posted on GitHub for everyone to see.

There are stories of this happening, and people get charged thousands of dollars because someone else used their API key. So to avoid that, we can hide API keys in separate JavaScript files. And we would tell git to ignore that secret file so it's not posted to GitHub.

Lastly, there is a license. By posting your code online to GitHub, people can see every line of your source code. People can also download it. Is it okay for people to use your code in their own projects? Can they take your code, post it online, and sell it somehow? That’s what the license is for.

These options (README, git ignore, and license) are optional. And you can also add them later. Don’t stress too much about it.

Hit Create Repository.

It should look something like this.

Let’s move on. Don’t close this window.

Create Project

We’re creating a new project. Maybe it’s a website, an API, or a web game. Regardless, it needs to exist on our computer.

Create your project folder somewhere on your computer. I created it on my desktop.

After you’re finished, open VS Code. At the top right, click File > Open Folder. Open the folder you just created.

You should see a screen that looks like this:

I added an html file, a CSS file, and js file. To add files, click the button shown below. Make sure you add the file extension ( like.html or .

s)

Git Bash

We created our remote repository on GitHub. We created our project and added some files to our project. Now, we can throw in Git to the mix.

I am going to show you the easiest way to access Git Ba

h.

Find your folder in your File Explorer or Desktop(if it's there).

Right-click on your project folder and select “Git Bash Here”. This will open Git Bash in your project’s folder.

Do you see the path in yellow? It’s OneDrive/Desktop/Tutorial.Make sure Git Bash is opened in your project folder. That is incredibly important.

Initialize Local Repository

The first thing you will do every single time you create a new project folder is to initialize your local repository.

GitHub will host our remote repository. Our computers will host our local repository. So again, we need to establish the fact that our project is now a git repository.

git init        

Connect our Local Repository to GitHub

The next thing we will do is connect our local repository to our remote repository.

Go back to your GitHub. After creating your repository, you should have been redirected to the following scre

n.

The most important part is the link to your git. Above, there’s an arrow pointing to it at the top. I also circled the command that uses it.

git remote add origin https://github.com/kyledeguzmanx/group-name.git        

Let’s break it down.

If you haven’t noticed by now, every command starts with git.

remote add is basically giving us the ability to add a remote repository.

origin is the name we’re using to reference the remote repository. Think about it like x = 4. Now we can use x to reference the number 4. It’s the same idea. origin represents the remote repository. You can change it if you want. But for the sake of the tutorial, keep it so you can follow along.

Then after origin, we have the link to our remote repository.

So take that git command and just paste it into your Git Bash. (Note: You cannot use control+v to paste. To paste, right-click and paste.)

If everything is successful, you should not get any error messages.

And to confirm that you successfully added the git repository, type the following command:

git remote        

If it does not return origin or another name you used, then you did it wrong. Retrace your steps. Otherwise, let’s carry on.

Track Files

You’ve learned a lot so far. Great job. Let’s keep going.

So you connected your local repo to your remote repo. Now we can start pushing files from our computer to GitHub.

Remember we said git’s entire job is to track files. So let’s see if there are files we can track.

git status        

git status tells us about any changes in our project. Were files created? Or were files modified? And modified basically means if we added or deleted code. After entering git status you should see this. It should say untracked files are index.html, index.js, and style.css.

If you don’t see this, make sure your Git Bash is opened in your project folder. Again, mine is OneDrive/Desktop/Tutorial. Your path should end with your folder’s name.

Or if you don’t see this, are you sure you created the files in your project folder? If you didn’t, that would explain why you can’t track them. They don’t exist.

Assuming everything looks great, let’s keep going. Now we want to track our files.

You can add the files one by one using:

git add        

Example: git add index.html

Example: git add style.css

Note: This is case-sensitive.

As you can see, after we added the index.html file, I used git status to check for any changes. Notice that the file we added is now green. This means the file is staged. It’s ready to be committed. It also means that we successfully used git add.

In addition to adding files one by one, we can also add all the files that have been modified or untracked. Or you can say, we can add all the files that are red or unstaged.

git add .        

Yes, that’s a period. That will add all the unstaged files.

Notice how all our files are now staged and green. This means they are ready to be committed.

Commit Files

Git is a version control system. If needed, we want to be able to look at our commit history. So every time there’s a noteworthy change in our code, we want that reflected in our history.

Here is an example from the repository: vanilla-lazyloading. Here is the commit history.

When we’re browsing through our commit history we want to be able to understand it, at a glance, without deep diving into the code. Otherwise, it’s not helpful to us. This is the reason for commit messages. These are messages attached to commits that explain changes and modifications.

Each entry in this history (or each commit) isn’t necessarily changing one file. It can change one file, but it can also change multiple files. The key thing with commits is making sure that changes are related. You don’t want to fix twenty different, unrelated issues and shove them in one commit. Why? Because then your commit history won’t be helpful to you.

If that doesn’t make sense, it will eventually. You can definitely slack off with commits and commit messages, as a beginner. But eventually, when problems inevitably arise with your code, you will see the benefit of it. It happens to everyone; hence, the popularity of this tool.

Let’s jump back to the code.

git commit        

This command is how we commit files. And note, we can only commit files if there are files that are currently staged/green. We can only commit files if we already did git add to the files.

Here, we used git status to see if there are files that are ready to be committed. You don’t have to use git status every time. I’m just using it to show you that there are files that are ready to be committed.

After entering git commit in your Git Bash, you will be redirected to a new screen. This screen is asking you for your commit message.

If you try to type, it won’t work. In order to begin typing your message, you must hit i on your keyboard.

Type in your response. When done, hit escape on your keyboard. Then type in :x and hit enter to exit.

As shown, I added my commit message and wrote :x to exit the screen. You will be redirected back.

If your commit was successful, it should not get any error messages.

Alternatively, to avoid entering another screen, you could also write:

git commit -m "enter commit message between these quotes"        

This will allow you to provide your commit message here instead of a separate screen.

Note: you cannot try it now because you just committed your staged files. There are no files to commit

Pushing Files

We staged our files by using git add . Then we commited our files with git commit . Now we are ready to push our files to GitHub.

The first time you push in every project, you will need to write:

git push -u origin master        

But obviously, we push over and over again throughout our project. For the next time we push, we just need to write

git push        

And just so it’s not skimmed over, let’s break down the first command.

git push is used to push to the remote repository.

-u origin is used to tell git that the next time you push, it will be to the remote repository origin. And if you used another name earlier (for git remote add origin), you wouldn’t use origin. You would use whatever name you used.

And lastly, master is the branch we’re currently on.

After pushing, you should see your files in your GitHub repository.

Modified Files

Notice how if we write git status there are no files that are mentioned. There are no red unstaged files or green staged files.

Let’s see what happens when I add code (and save the file) to index.html.

When code is added, it shows that the index.html file has been modified. It is not staged and it is red.

git add . 
git commit -m "updated index.html"
git push        

If you add the following code, one by one, you should it works perfectly.

Let’s modify style.css

Using git status we see that style.css has been modified. It’s red and unstaged. Let’s stage it.

It is now green. It has been successfully staged. What if we wanted to unstage the file? And the reason we want that is for the reasons stated earlier about an accurate commit history. We want commits to reflect related changes.

git reset        

The command git reset is how we can unstage files. You can see that we successfully unstaged the file.

Collaboration

At some point in time, you’re going to be in a team that’s working on the same repository as you.

Let me tell you what will happen:

You will stage files, commit files, and then try to push. But your push will be unsuccessful.

When you push, GitHub is going to make an assumption. It’s going to assume that the remote repository (on GitHub) is in the same state/version as it was when you began working on it in your local repository.

Imagine the repository before you made all your changes. It’s going to assume it looks like that. And when you push, it’s assuming you made additions or deletions.

When you’re working on a repository yourself, this isn’t a problem. The repository is only going to change if you change it.

But when you’re working with a team, GitHub sees that additions and deletions have been made, but you didn’t do that. In other words, the remote repository and your local repository(in your computer) look different — and the difference cannot be explained because of changes you made. So an error occurs.

Let’s see what I’m talking about.

Open your GitHub repository and create a README.

The contents of the README, for this exercise, don’t matter. So put whatever you want.

At the very bottom, hit the green button to commit changes.

What did we do? We created a change to our remote repository, and our local repository doesn’t know it yet. It will only know when Git Bash will try to push changes, and it will fail.

Let’s modify any file in our project. Or add a new file.

I added code to style.css

git add .
git commit -m "updated "
git push        

The push failed. There is an error. Our remote repository contains changes that weren’t made in our local repository.

To fix that, we simply do two things

git fetch
git pull        

These are partners in crime. I always use them together, one after the other. fetch retrieves the changes. And pull actually changes our code to reflect those changes.

After that is settled, git push works fine.

Delete Files

Lastly, delete files.

If you want to delete a file, delete it in your local repository.

Right-click the file and hit delete. You can do this in VS Code or File Explorer. Or you can click the file once and hit delete in your keyboard.

After doing so, commit and push your changes in Git Bash. Since you deleted it in your local repository, it will also be deleted in your GitHub repository.

But what if you wanted to remove a file from the GitHub Repository and keep it on your local repository?

If you delete it on GitHub, Git Bash will expect you to fetch and pull. This will delete your local copy of the file.

git rm -r --cached fileName        

Example: git rm -r — cached index.html

Note: We can also remove folder.

After executing the command, the README exists in our local copy only. It will be red and unstaged.

More Commands

git branch        

• used to show which branch you are currently on

git branch -r        

• to view all the branches available on the local repository

git branch -a        

• to view all the branches available on local and remote repository

Note: To view newly created branches (that were created in GitHub remote repo), make sure you fetch and pull first. Otherwise, your local repo doesn’t know it exists

git checkout --track origin/branch-name-here        

• to change branches to a branch in the remote repo that you have not visited yet

Note: Use git branch to confirm the switching of branches was successful

git merge branch-name-here        

• to merge two branches together
• requires two branches: receiving branch and giving branch
• the receiving branch will absorb the merge. The code will change according to the code given by the giving branch.
• The giving branch provides additions and deletions
• To use this, you must be in the branch that is receiving/absorbing the additions and deletions. And branch-name-here should be the branch that is providing the code to be added and deleted
• Prior to using merge, make sure to fetch and pull

Thank You