Git Basics - How to Commit & Collaborate

Sarah Robin

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

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)

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 then run git status again to see what’s changed:

$ git add
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:

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:

  1. Untracked work
  2. Tracked work that hasn’t been changed
  3. Tracked work that has been changed
  4. Tracked work that’s been changed & is ready to be saved

Using 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:

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

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 and create a free account. Once you’re logged in, click the + button in the top right corner and then click ‘New repository’.

Using GitHub top-right dropdown menu to create a new repo

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.

Configuring new repo options on GitHub

You should see a page similar to this:

Successfully created repo on GitHub

Copy the 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://[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://[your username]/studious-gator.git (fetch)
origin	htttps://[your username]/studious-gator.git (push)

Using 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[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 master. 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 master on 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 status to 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!

  Tweet It

🕵 Search Results

🔎 Searching...