In this article, and further tutorials in this series, you will learn about the Git version control system and how it is used for managing source code and text files for a wide variety of applications.
More than conceptual, this article will provide you with a 1-2-3 getting started cheat sheet for running with Git right away.
Git is an open source cross-platform version control system. Every project involving various text files will have a revision history, and Git helps you keep track of it.
You will often hear that Git is a distributed version control system. But what does that mean?
The program provides a suite of commands that help you track changes made to source code over time as well as well as deploy code to local and remote repositories. Git is “distributed” in the sense that there need not be one central repository for source code, but individual users may “clone” the project into their workstations and have all the content they need to do their job. When they’re done, they can submit their work to a shared remote repository so other people can see what they did.
It’s easy to think of Git version control as a journal containing the detailed history of your project.
Those journal entries are kept in the repository. Once you have added files to the staging index, you want to let Git know when to record those changes into the journal. In the Git world, this is called a “commit.”
You can think of it as making a commitment to record the changes you made in your working directory to the permanently recorded history. Once changes have been committed, they go into the repository. And you can later revisit any point of history in the repository. Each “commit” is marked with a unique identifier.
Plus, Git requires that you provide a “commit message” providing some background detail on what this commit consists of. This way, Git forces you to keep your project details, upgrades, bug fixes, and features very well documented.
There are many popular hosting platforms available for Git, such as Github and Bitbucket.
Many of these platforms offer special features and addons built around the base functionality of Git.
Git is free and open source software, so you can host your own Git server if you want to. It also works with just about every operating system.
Some hosted services offer a self-hosted variant. GitLab offers a lot of the features you would see in GitHub but with an optional self-hosted package you could install on a private server.
However, if you are interested in managing your own Git repositories on a private server, this is the tutorial series for you.
There is so much you can do with Git version control and file management that we have chosen to limit this tutorial to the bare essentials.
This means even though there is much more information available about this program, you will be up and running quickly with everything you need to get started using Git right away.
Whether you choose to use a third party Git hosting platform in the future, or if you prefer to manage your own repositories, in this tutorial, you will learn how to build and manage your repositories from the ground up using command line tools you already have available on your computer. We are going to learn how to initiate a repository and track files, commit changes, tag and sign commits, and how to push changes and deploy files.
When first learning how to use Git, you have a choice between using the command line version and a graphical user interface (GUI) version.
In this article, we presume you are interesting in learning the command line variant. There are certain benefits in using the command line version of Git including:
- Wide support across various platforms
- Commands stay the same no matter where you are
- Allows for scripting and aliasing (to run favorite commands faster)
- Helps to solidify the conceptual framework behind Git
But if for any reason you choose to use a GUI, there are many popular open source option including:
While working with Git you will often hear about the working directory, the staging index, and the repository. These concepts are important to grasp from the very beginning in order to get a proper footing in using Git.
The working directory is where everything starts. This is where you do your work. Files that you are working with are located in the working directory on your computer. Likewise, other users will have clones of the project in their working directories.
The staging index is where you add the files you want to track. Tracking files means that Git is watching them for changes in this special staging area. When you add files to the staging index, you are telling Git, “Please include this file in the list of files associated with this project and keep note of all changes made to it.”
You should now see the full progression before you: files start in the working directory, they are added to the staging index, and then they are committed to the repository. As you can see above, files can also be “checked out” from the repository, but this is an advanced topic that will be covered later.
This section will introduce the uninitiated beginner to all the immediate Git fundamentals needed to start work right away. This is a crash course in Git for beginners.
Did you know? You can use your cloud server hosting as a private Git server.
Before getting started, you will just need to install Git. If you’ve already complete the installation then you are ready to begin.
The working directory is the main directory for the project files. As you’re learning more about Git you’ll often hear or read mention of the working directory. It’s basically the directory (or, folder) that contains the files for your project.
The working directory can be altered by Git. For example, you could load previous versions of the project or integrate others’ code from another branch of the project, and your working directory will change. This means you must be careful not to accidentally overwrite files in your working directory.
In order to start using your working directory, all you have to do is create a directory and start adding your files to it.
In the next section, you will find out how to instruct the Git program to start watching this directory for changes.
Before you begin your work you’ll need to “initialize” Git in your working directory, with this command:
This command initializes Git functionality in your working directory. But what does that mean? Git initialization accomplishes the following:
- Sets up a .git directory in your working directory
- This “hidden” directory keeps track of the files and special reference markers needed by the Git program
- As you get more advanced in Git, you can use some of the items in this directory to achieve advanced effects, but not yet
- Opens up your project for Git tracking
- Allows you to start running Git commands
Upon initialization, your Git project is officially up and running. Now you need to let Git know which files to start tracking.
Like the working directory, the staging index is a fundamental concept in Git that you must learn and commit to memory.
You can think of the staging index as a sort of list that tells Git which files (or modifications to files) you want to commit to the repository.
You use the staging index by invoking the git add command, for example:
git add <name-of-file>
git add file1.php
In the diagram below, suppose three files have been created in the working directory. Notice:
- The first file has already been tracked by Git and was modified
- The second file is new to Git but was just added, indicating that it’s a new file for Git to start tracking
- The third file has not been added to the staging index, so Git is not aware of it
This means that even if a file has been previously added to Git for tracking, it must be added to the staging index again every time it is modified, otherwise the changes will not be committed to the repository.
Once you have added the files, and modifications to files, to the staging index, it’s time to create a commit for those changes to add them to the repository.
The repository is the official, logged, and—sometimes—tagged destination for your project files in one state.
You can think of the repository as the place where all the records of the various states of your project are kept. Each note, or mark, is termed a “commit,” because it is basically a commitment to the permanent record of the project. This means if you’re working on something like a software project, the program should be in a solid working condition or at least a somewhat working state when a commit is made.
Git requires that all commits be made with a log entry to briefly notate the nature of the commit.
Some example commit messages might be:
- “Fixed bug on login screen”
- “Updated emphasis font”
- “Added phone number entry to form fields”
In order to start a commit, run this command:
This command, as is, will open your default text editor for writing in your commit message.
To skip over the text editor, use the -m option and put your commit message in quotes, like so:
git commit -m "Fixed bug on login screen"
And, accomplishing more with one command, you can add the -a option to simultaneously add all file modifications to staging index before committing:
git commit -am "Fixed bug on login screen"
The latter command demonstrates how the command line Git variant lets you use various options to chain commands together, thus saving a little time.
Finally, as you are now ready to embark on your journey in discovering the magic of Git, you need to learn about how branches work.
Branches allow for unlimited iteration of your project files. For example, if you want to test a new feature or bit of code, you can create a separate “branch” of the project.
By default, every Git project has a master branch, or “upstream” branch that is meant to reference the final/complete version of your project.
By creating branches you can make unlimited changes to your project, and commit them, without affecting the master copy.
When working with branches you can always switch back to the master branch—or other branches to “checkout” the files or modifications in that branch.
However, one caveat of branches is that you can only “checkout” other branches from a clean state. Which means if you have uncommitted changes in your current branch you cannot checkout other branches. But if you’re unready to commit those changes on your current branch, you can stash them aside for later.
In order to see what branch you’re currently on, you can run the git branch command by itself:
If you haven’t created any alternative branches yet, you will see a listing for the “master” branch, which you’re on by default.
To create a new branch you can run git branch followed by the name of the branch you want to create, like so:
git branch <name-of-branch>
Now when you run git branch you’ll see “master” and the new branch listed. Master will still be selected as your active branch.
In order to “checkout” a different branch, run the git checkout command followed by the name of the branch you want to check out.
git checkout <name-of-branch>
You can check to make sure you’re on the new branch by running git branch again to see that the new branch is selected/highlighted. (It’s always good to check your work.)
Now, notice, if you make changes to the files on this branch, you will not be able to switch back over to the “master” branch unless you commit your changes or stash them.
To stash your changes, run git stash.
When you return to the new branch, you can unstash, or “pop,” your changes. (Actually, you can pop changes on any branch. See the full guide on git stash to learn more.)
Those are the very basics of Git. From there, you can master the entire program because you have grounded yourself in the fundamentals. If you have any issues, or unexpected errors, leave a comment below and the InMotion community team will try to help out.
Explore more Git-related content here:
- What Are The Basics of Git I Should Know?
- Can You Undo a Commit In Git?
- Git Clone Quick Start Guide
- How to Use Git Tags
- Git Hooks (and How They Work)
- Git Config Recommended Settings
- Git Rebase and How It Works
- How To Install and Serve Gitweb on NGINX in Debian
- How to Create Your Own Git Server
- Deploy Files With GitHub Actions for FTP and SCP
- Git Fundamentals Complete Beginner Guide
- How to Git Stash “Apply” to Preserve Stash
- How to Git Stash
- How To Remove Or Unstage Files From Your Git Staging Index
- How to Install Git
- How to Create a Git Repository on Your Reseller VPS
- How to Use Git Version Control in cPanel
- How to Point a Subdomain to GitHub Pages
- How to Publish a Jekyll Site with Git
- How to Use a Custom Domain with GitHub Pages
- How to Host a Static Site with GitHub Pages
- Using Your Github Account
- Connect Local Project to a Github Repository
- How to Create a Repository on GitHub
- Why or Why Not Use Github?
- Using Git to Publish Files
- Using Branches in Git
- Setting Up your Remote Repository with Git
- How to Sign Tags and Commits with Git
- How to Commit Changes in Git
- How to Add Files to Git
- How to Create a New Account with GitHub