So now you’ve gotten Git installed and your first repo set up, its time to make something! And by something, I really do mean anything! Git tracks file changes exceedingly closely, so most anything you want to work on and backup can be tracked in Git. Images, documents, video, code - whatever you need to keep track of, Git can manage it.
For the sake of brevity, our wondrous masterpiece in need of version control will be a humble markdown file,
$ touch README.md
So now we’ve created a new file, but did Git notice? Let’s check in with the most-used command in your CLI Git repetoire. Try running
git status and you should see something like so:
$ git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)
When you run
git status, Git will report back to you everything you need to know in order to know what to do next. In our case, we want to track our new README file. So let’s follow Git’s advice and run
git add README.md then run
git status again to see what’s changed:
$ git add README.md $ git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md
Okay, so Git’s tracking our new file, but what does it mean to commit something? Do you want to unstage stuff? What does
On branch master mean? Its time to talk about how exactly Git tracks your work and how you can tell Git what to track and when.
First, let’s talk about how Git tracks your work. Git ‘sees’ your work in 4 different ways:
- Untracked work
- Tracked work that hasn’t been changed
- Tracked work that has been changed
- Tracked work that’s been changed & is ready to be saved
git add path/to/file will allow you to take untracked work and tracked work that has changed and get it ready to be saved. Git calls this staging the file - and you can see which changes are staged with
git status, where Git will tell us that we have a change to be committed - our new README file!
$ git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md
In Git, saving your work is called committing work, with each save being called a commit. Git then tracks these units of saved work, commits, and lets you rearrange, replay, and manipulate commits over the course of time - think of it like a log of your code’s history that can be amended or edited. For now, let’s commit our new README file with a short message:
$ git commit -m "Added README file" [master (root-commit) 0a55ef3] Added README file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md
Stuff happened! Holy crackers! Lets take this one line at a time. The
master keyword on the line
[master (root-commit) 0a55ef3] Added README file indicates what branch you’re on. Seeing
master here means we’re committing (saving) our work to the primary version of our repository. Git supports multiple versions of a single repo, known as branches, but we’ll go over that in-depth in a different article soon.
root-commit means that this commit is the first of the repository. Changing the root-commit later is a little tricky, so try and make sure your first commit in any new repository is small and lightweight.
0a55ef3 is the last 7 characters of your new commit’s unique ID number. Each commit is given a long string of letters and numbers known as a hash. Think of it like your commit’s fingerprint - something that Git can use to identify it easily. Sadly, humans don’t parse hashes quite as fast as Git, generally speaking, so Git makes it easier to identify commits by presenting their last 7 digits as the ID. You won’t need to remember this, generally speaking, unless you’re trying to do advanced Git operations and want to target a specific set of commits.
After the hash is your commit message, then a summary of the changes. Git measures changes in lines of code, so it will let you know how many files were changed, and how many lines were added (inserted) and removed (deleted). After that, it’ll give a short message on how it committed your code - in this case the
create mode 100644 which specifies what internal operations Git was running to commit your code. You most likely won’t have to worry about that for now.
Alright! Great job! Let’s check in using
git status to see how the commit went:
$ git status On branch master nothing to commit, working tree clean
Looks good! But this may seem a bit… perfunctory. All that work just to save your code to your local computer? Why even bother with Git?
The answer lies in how you collaborate with others, and to do that, we need to move our code off of our computer into a shared place. To that end, we need to add what’s known as a remote, a destination for our code that isn’t on our computer. Remotes are really just specialized URLs, web addresses we can tell Git to send our code to. They come in two types: HTTPS and SSH. For today, I’ll be showing you HTTPS remotes using GitHub, but we’ll revisit using Git with SSH soon.
To get our remote, we’ll need to create a repository on GitHub. If you haven’t signed up for GitHub, head on over to github.com and create a free account. Once you’re logged in, click the
+ button in the top right corner and then click ‘New repository’.
Now you’ll want to create an empty repository that you’ll be able to push your code up to. Make sure to name it the same as your local repository, and don’t add any default files.
You should see a page similar to this:
HTTPS git address - it should be
htttps://github,com/[your username]/studious-gator.git Now we’ll be following GitHub’s helpful advice under the ‘push an existing repository from the command line’ header by adding our new GitHub repository as a remote:
$ git remote add origin htttps://github.com/[your username]/studious-gator.git # We've added our remote, now lets see what we added by listing all remotes $ git remote -v origin htttps://github.com/[your username]/studious-gator.git (fetch) origin htttps://github.com/[your username]/studious-gator.git (push)
git remote -v will list out all of the remotes attached to your repo locally. In this case, we have permission for downloading code (fetching) and uploading code (pushing) for our github repository.
Now that we have our remotes set, lets push up our code to GitHub!
$ git push -u origin master Counting objects: 3, done. Writing objects: 100% (3/3), 219 bytes | 219.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/[your username]/studious-gator.git * [new branch] master -> master
So what did we just do? We used the
git push command to send code to
origin is the name of the remote we added -
origin is a common name to give to the primary remote in a repo, and is usually considered standard on most projects.
master is the name of the branch, or version, of your code. The
-u option tells Git to create the branch
origin if it doesn’t exist, which is only required the first time you push up code to a branch.
Heck yeah, friend! You’ve successfully sent your work up to a remote repo that other people can collaborate with you on. To review, today we learned about:
- How to use
git statusto review where we are with version control
- How Git tracks changes in your code
- How to stage and commit your code changes
- Managing remotes in Git, including how to add a remote GitHub repo
- How to push committed code changes up to a remote repository
Next time, we’ll go over branches in-depth so you can learn how to skillfully weave your code changes in with other people’s changes!