Git Your Feet Wet

Starting out with version control from the command line

Photo by Roman Synkevych on Unsplash

(I originally started/planned this Git intro guide post over a year ago, after a month into my first developer job. But it turned into an abandoned project, as projects do. Now, I’m helping to mentor intro students over at Code the Dream, and the topic is back in my life with increasing frequency. So it’ll be easier to refer to this article than typing it into Slack and Zoom repeatedly. 👋 Hi, students!)

Learning to code keeps getting easier, coming in the form of games and phone apps and some rather robust Web IDEs that make it so you only have to be able to use a browser to get started. But if you choose to write your own larger projects locally on a computer, especially in groups, learning to use a version control system like Git becomes essential. And if you’re like me, you also have to conquer some deep-rooted fear of the command line.

But it’s going to be okay. If for no other reason than the fact that part of why Git was created was to make it really really hard to make irrevocable mistakes.

Note: This is not meant to be a particularly comprehensive beginner’s guide to Git. These just happen to be the most useful commands I’ve used in my exact journey, including bootcamp. This also assumes you have already installed Git for your operating system and are going to be using GitHub to host your projects. (Guide here.) Let’s go!

What is Git?

Git is a version control system (VCS) which is useful in tracking and managing changes in code. It does similar things you are familiar with when editing any document, like saving to files and undoing changes, but with a lot more tracking and documentation that makes it easy to see the history of the code and work asynchronously with a team. Git also allows you to easily revert your code to a previous (perhaps functional) state, without having to do things like save “MyCode-draft 1” and “MyCode-draft 2” and “MyCode-final” and “MyCode-final final” and so forth into different files, trying to remember which is which.

But it’ll take a little practice. You’ll learn to like it, I promise. (Especially the first time it gets you out of a jam. You’ll feel like a wizard.)

A little more conceptual background

Before getting into the commands, if you’re new, let’s try and grok some of the concepts and learn the vocabulary.

All of your code for a project will live in a code repository, or repo for short. A repository is like any other folder containing all of your code files (and that’s how it will look when you navigate through it), but it should have other things like documentation and a VCS like Git set up so the history of the code changes are also tracked. It’s a very powerful file folder.

One of a Git repo’s superpowers is the ability to save changes in the form of a commit. A commit captures a snapshot of your repo — the file structure and contents — along with other data like the code author, timestamp, and your commit message. They enable you to keep a history of your changes without saving draft after draft under different names, along with a note from the code author that describes the changes made. Note that each commit doesn’t contain all of your code, per se, but rather all of the changes since the previous commit. This is an important concept to keep in mind. The commits build on top of each other, and are structured so they can be reordered or even moved to a different branch entirely.

Another superpower is the ability to contain branches. Every repo has a default branch, which will likely be called main, or master in some older repositories. Think of this branch as the best representative and public face of your code. At any point in the development of your codebase, you may make other branches that come off of the main branch.

Think of each circle as a commit. Image from Openclipart

Branches are useful because you can experiment, break, test, and fix your code without touching the main branch. (Which is hopefully the most stable of your branches.) If you’d like to keep the changes you’ve made in a branch, you can merge them into the main branch, making mainbetter than ever!

To recap: a Git repo is a special folder for your code, where its changes are captured in the form of commits, like in a timeline. Git also allows you to seamlessly form branches of alternate timelines in the same folder, making it easy to compare the them and incorporate the differences.

Excited? Here’s your survival guide!

(Again, disclaimer: I will be focusing on specific use cases in this post that will most likely come up in a bootcamp setting while working alone. I won’t go into too much detail, and will cover some of the basics of working with others in a different post. And if you’re in my class, please still do the assigned Git readings first. 😄)

Starting out, you are most likely going to fork a repo on Github’s web interface to create your own copy. Go to your forked copy and then click on the green Code button and copy your HTTPS URL.

When you clone this repository to your machine, you will be creating a folder with its name. Navigate to where you’d like this folder to live. To clone enter:

$ git clone <URL>

After it is done successfully, you should be able to find your repository by using the ls command.

$ ls
some-other-folder          your-repository-name           download.jpg            

Navigate into your repository just like any other folder.

$ cd your-repository-name

And now you’re in!

Optional detour: Are you going to work on a different branch than the default?

# To create a new branch and immediately switch to it 
$ git checkout -b your-new-branch-name

# To switch back to another branch
$ git checkout branch-name
# e.g. git checkout main

(This is where we part ways for a bit and you open the repo in whatever code editor you have chosen and do your thing. I use VS Code and so I’d just use code . to open the directory. You can also open the editor first and open the folder. Anyway, code away, and save your amazing work.)

Now we are going to check on your changes, make sure all the files you want are tracked, stage the changes you want to keep, and them commit. All of these commands are run where we left off, in the main folder of your repository.

# To check to see what files you have changed or are untracked:
$ git status

# To check on the specific changes you've made:
$ git diff 

I usually do both of these. I set my code editor to autosave often so it’s possible for my cat to do some edits that I have to find. Giving a look also helps to find any code breaks or console logging that were long forgotten.

At least some of the changes look good? Let’s stage those changes to a commit. (You get to pick and choose!)

# To add everything (in tracked files):
$ git add .

# To add only specific files (including any of them that are new and untracked):
$ git add <filepath>
# You can just copy and paste the paths given in 'git status'

# To add only specific changes (and not entire files), follow the prompts after:
$ git add -p

You might want to double check git status one more time. Now to the commit the changes!

# To save them to a commit:
$ git commit -m "<your descriptive message here>"

# To skip the adding step above if you are absolutely sure you want to include all the changes you've made:
$ git commit -am "<your descriptive message here>"

It is in your best interest to write a clear commit message. It will help you and anyone reviewing your code understand the changes. (You can commit without a message, or commit and change it later, or write a commit with a subject line + body format, but for now I suggest you practice one liners.) It is common convention to say what this commit will achieve when applied and not use past tense. For example, “Add biographical information to About page” or “Fix broken links in the menu”.

Let’s make sure this is all backed up to GitHub.

# To push up a brand new branch
$ git push -u origin <your-branch-name>

# To push back to GitHub if there is already a branch of that name:
$ git push
# You can always try `git push` on its own first and it will help you push a new branch

Merging your branches

In a solo project, once you are sure you’d like all of the work in your branch incorporated to your main branch, you can merge easily via the command line.

$ git checkout main # make sure you're in the receiving branch
$ git merge incoming-branch

If you are doing this as part of coursework, it’s common to submit a pull request before merging, which gives a space for comments or discussion. This is best done back on the GitHub website.

Navigate back to the page for your repo and click on “Pull Requests”.

From the pull requests page, click on the green “Create Pull Request” button and follow the prompts. There will be an option to merge from the resulting pull request.

Merging is more complicated when you are checking for changes from a collaborator, but we’ll cover that later.

A few more useful commands

If you find that you’ve been working on the wrong branch but already saved some work (but not committed it), you can cut and paste like this:

$ git stash
$ git checkout desired-branch-name
$ git stash apply

If you want to change the your most commit and haven’t pushed it yet:

# To amend the message or the files
$ git commit --amend

# To just undo the commit but keep the changes saved locally
$ git reset --soft HEAD~1
# This can undo mulitple, but let's keep it simple! Check 'git status' here and make your changes and recommit.

If you want to see your commit history:

$ git log
# Hint: Type "q" when you are done browsing.

# For a more compact version:
$ git log --oneline

That should help you muddle through a few solo projects! Let me know if there’s anything I should add, or what I should include in a followup post. To practice some git commands without working on your own project yet, here’s a great web-based tutorial.

Happy coding, everyone!