Introduction to Git

This is a basic introduction to Git. It assumes no prior knowledge of Git or any other version control system. We will use VSCode and it's built in terminal in this tutorial. I will use a Mac for this tutorial but you can also use a Windows PC. It is possible to set up Git on a Linux machine but I will not cover Linux in this tutorial.

What Is Git

Git is a version control system that helps teams and individual developers keep track of code changes in a project. It is the most popular version control system right now.

Git is a distributed version control system. Each team member "clones" a project (repository) to their local computer in its entirety. If you've ever experienced that pain of trying to update a shared Word document that is "locked" because your co-worker forgot to close it after saving you know why having your own copy is important.

How to Install Git

Git is very simple to install and setup. If you already have Git installed please skip this step.

To check if Git is installed on your machine run git --version in your terminal. If Git is installed you will see a version #. If its not installed you will see a message that says the git command is not found.

Mac

Homebrew

If you have Homebrew installed on your Mac (if you don't go install it now. Trust me its a huge timesaver) you can install Git easily. Run brew install git and Homebrew will take care of the install for you.

Download and run the installer

Windows

Download and run the installer

Working with Git

There are several different tools you can use to work with Git. I prefer to use the terminal and Git CLI. Using Git with the command line lets you see more feedback and gives you more control of your repository. All of the Git terminal commands were installed when you downloaded Git in the previous section.

Using Git with the terminal is also a good way to get comfortable using the command line.

This tutorial will use the VSCode IDE. It's the only editor I use now and I highly recommend switching if you haven't already. Its free and it comes with built in Git tools and a built in terminal. None of the commands here are specific to VS Code though.

Configure Git

Just a bit of housekeeping. Before we set up our first Git repository we need to configure a name and email. You will use the same name and email when you set up your GitHub account.

git config

Set your name and email

git config --global user.name "John Doe" git config --global user.email johndoe@example.com

Your First Repo

We can set up a simple website as your first git project. We will use this sample project to learn the most common git commands.

Open VSCode and add 3 files. index.html styles.css and README.md. Don't add anything to the files yet. Just leave them empty.

In the next part of this tutorial we will build our simple website using a few simple commands. These commands will cover most of your daily git workflow. You will probably memorize these commands if you work with git every day.

Git Commands

Initialize Your Repository

Open the build in terminal in VSCode. To initiate your new git repository run git init.

This will set up an empty git folder. You may see a .git folder in your project. You may also notice that the files in the sidebar changed color. This is because git knows that you have files that have been modified.

Git Ignore

A .gitignore file tells git which files to ignore. It always belongs in the root directory of your repository. These files will are not added to your repository and will not get copied over to other team member's machines. Sometimes we don't want to store these files because we can download them ourselves. Sometimes these files may contain passwords and keys that need to be secure. You also don't want to add build files to your repo because they just take up space and get out of date.

Never add node_modules, build files and .env files to your repo.

Lets add a basic .gitignore to your repository. Create a file called .gitignore in the root directory of your site. Add the following lines.

/build
node_modules
.env

Right now this won't do anything but it is a good practice to always add a gitignore file to every project.

Now add a file called ignore.html. Also add another line to your .gitignore file. ignore.html After you save your gitignore file you will notice that ignore.html turns grey. Now you can add anything to the file but it will not be added to your git repository.

Stage Files

To get modified files ready to commit we need to stage them. We can either stage all of the files or one file at a time. Run git add index.html in your terminal. Now run git status. This will let us see which files in our repository are "staged" for commit. If we were to make a commit to our git repository right now we would only commit one file. This can be useful when you only want to commit small changes.

Most often you will want to stage all modified files for commit. To do this run git add . in your terminal. Now all of your files except ignore.html are staged for commit.

Commit

Now its time to make your first commit. Run git commit in your terminal. You will probably see a somewhat strange screen appear in your terminal. This is the Vim editor and it may be a little confusing. The first time I saw this screen I totally freaked out. Go ahead and type initial commit. Now to finish your commit and close Vim hit esc, type :wq and hit return.

Congratulations you just learned how to close Vim and made your first git commit!

Now if you don't want to use Vim to make your commits there is a handy shortcut. Running git commit -m 'initial commit' will do the exact same thing.

Let's break down this command into its parts. git commit is your command. Most commands take flags as arguments. -m is one flag you can add to the git commit command. 'initial commit' is added as an argument to the -m flag.

Now if you want an even better shortcut git commit -a -m 'initial commit' will stage all modified files and commit them with your message. Now this is a great command but be careful with it. Make sure that you actually want to add all of your changes to a single commit before you run this command.

Using Branches

Now we'll dig into the real power of git. Branching.

When you create a new git repository you automatically get one branch named main. Usually this is the branch that contains your "production" code. This is the code that you will push to the live website. Sometimes a company may automatically publish new commits to main on the live website.

Creating a new branch

Now let's say you want to add a new feature but you don't want your website visitors to see a feature before it's completed and approved. You want to create a "feature" branch.

We want to start building our home page.

Run git branch HomePage. This creates a new copy of the main branch named HomePage. Now run git branch --list.

You may notice that the main branch is still highlighted. We haven't actually checked out our new branch. Run git checkout HomePage. Now if you run git branch --list again HomePage will be selected. Now any commits you make will be a part of the HomePage branch.

Now if you want to skip the extra checkout step git checkout -b HomePage will create and checkout the branch.

Now lets add some HTML and CSS for a simple (very simple) home page. Feel free to copy/paste. This isn't an HTML or CSS tutorial.

To index.html add the following HTML.

<!DOCTYPE html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title></title>
    <meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" href="">
  </head>
  <body>
    <h1>Hi from example website</h1>
  </body>
</html>

to styles.css add the following CSS

body {
  width: 100%;
}

h1 {
  font-size: 24px;
  color: #333;
}

and finally to README.md add

# Git Introduction

Now if you run git status you should see that you have 3 files with changes not staged for commit. Now before we commit these changes we may decide that HomePage isn't a very good name for this branch. We're adding a lot of changes that could affect out entire site. If we had more than one page.

Let's rename our branch using git branch -m NewStyles. That will rename the current branch (HomePage) to NewStyles. If you run git branch --list again you will see that NewStyles is highlighted.

Now its time to commit our changes using git commit -a -m 'add some content'

Merging

So now you're probably wondering how we can get the changes from NewStyles into our main branch. Well there are 2 ways but we will only cover one in this tutorial. We will "merge" NewStyles into main.

Go ahead the checkout the main branch (git checkout main). We can view a list of all of our commits using git log --oneline --graph.

Now run git merge NewStyles to merge NewStyles into main. Now you should see a message that says updating Fast-forward and a list of the files that were merged. Now if you run git log --oneline --graph again you will still see both branches but now your will see HEAD -> main, NewStyles. This means that main and NewStyles are the same.

Now that we merged all of our changes we can remove the NewStyles branch. Generally it's a good idea to remove feature branches after you merge them into main.

Run git branch -d NewStyles to remove the NewStyles branch. Now you will see a message letting you know that NewStyles was removed. Keep in mind that if you delete a branch you cannot recover it. Git will help you out if you try to remove a branch that isn't fully merged. You will get a warning message and you will have to rerun the remove command with an uppercase D instead. git branch -D <branchName>. This will let git know you really want to remove the branch even with unmerged changes.

Now if you run git branch --list again you will only see main. You cannot remove the main branch.

Best Practices

Here are some best practices based on my experience using Git on enterprise and personal projects. It can be tempting to let best practices slide on personal projects. Building good habits on your personal projects will carry into your professional projects.

Create new branches for each feature

On most projects you will need to fix issues on your live site while you also work on new features. Keeping branches for each feature helps you to isolate features still in development from your production ready code. If you're in the middle of adding a new feature and your manager asks you to quickly fix a bug on the live site you can easily create a new branch and fix the bug without accidentally releasing an incomplete feature to the live site.

I recommend using multiple branches even on your personal projects. This way you can get experience managing multiple branches and build good habits.

Tip: Make sure you always create new branches from your default Git branch. Usually this will be main, main or develop.

Always clean up old branches

When you merge your feature branch code into your main branch your will need to clean up your merged code. This will keep your repository nice and easy to manage.

I usually remove all feature branches after merging into main instead of keeping long-lived feature branches. If I need to make additional changes to a feature after merging into main I create a new branch.

Write informative commit messages

Writing descriptive and informative commit messages will help when you need to review your project's history.

Keep your commits small and focused

Keeping your commits focused will help you stay organized. Resist the urge to lump new features and code cleanup together in one commit. It gets confusing when there are a lot of unrelated changes in a single commit. You can work on multiple features at once but create feature branches.

Do not commit broken code

If you need to switch branches while you're still fixing broken code use git stash or commit with wip: as a prefix to your commit message'

Follow your team's recommended practices

If you're on a team git repository find out your company's best practices for making commits.

This introduction should get you up and running with Git. In my next article I will cover remote Git repositories with GitHub.

More Resources

This article is just an overview of the most frequently used Git commands. It barely scratches the surface of what you can do with Git. Here are some more resources that discuss advanced Git features.

Need Help with Your Website

If you need help with your website contact me here.

© 2023, Elizabeth Rogers All Rights Reserved