Jamie Danielson

How To: Git

This is a relatively basic overview of a common git workflow that is sufficient for a majority of use cases. It doesn't get into the nitty-gritty, doesn't go through merge conflicts, etc. Those will be a longer post at a later time. For now, this is intended to cover the basics of using git with Github.

First, remember that git and Github are not the same. Git is used for version control, and Github is a place to store that code. Another popular alternative to Github is Bitbucket. While some aspects of Bitbucket differ from Github, in most ways that matter they are very much the same thing.

This post is directed primarily toward Windows users. Pro-tip: There's a TL;DR at the bottom.

Git

There are many ways to get Git on your computer. My personal setup involves installing the full Cmder software package from cmder.net. The full package includes a console emulator and Git for Windows.

VSCode

There are many editors out there. Sublime is a commonly used one, and there is certainly nothing wrong with it... but VS Code has far surpassed all other editors in terms of popularity and ecosystem. There are so many plugins, ongoing support and features, and it's just become a delight to work with. I converted from Sublime and will never look back. We will use VSCode for some of our git commands purely because the UI makes things so much easier to visualize and work with.

Github

Create an account with Github. 'nuff said?

SSH

SSH is a protocol for connecting and authenticating for access to remote servers. Using an SSH key with Github allows you to more quickly and easily make updates, without needing to provide your username and password over and over.

Use Github's docs for generating a new SSH key and adding it to he ssh-agent because I can't write it any better.

They also provide docs on adding your SSH key to Github. Essentially you need to click on your face in the top right corner, click Settings, click SSH and GPG keys, click New SSH key, and add in your info. Voila, life is now simpler (at least in pushing and pulling changes with Github).

Create

When logged into Github, click on "Repositories", and click New. Enter a repository name, e.g. "portfolio-website". Choose whether to make it public or private. You can also add a README and a .gitignore here, though I often do that separately, and choose a license. Then click Create Repository.

One great thing about Github here is it tells you some notes on getting started with this. You may be able to read this and be good to go but I'll break it down a little bit here.

You'll want to open your terminal and navigate to a folder where you want this code to be stored, e.g. C:\users\jamie\code\portfolio-website. Make sure you are in your new (empty) folder at command line before going any further. If you just created it but aren't in there, make sure to cd into there.

The first line of instructions starting with echo is saying to create a new file called README.md, with the copy # portfolio-website, or whatever the name of your folder/repository is. This is also giving you your first file for the project.

Just a note: anything you do with git is going to start with git, so let's get used to writing it and seeing it.

git init is the critical piece that says "Initialize this for git".

git add README.md is what you'll write if you did the echo line and created a README.md, and did nothing else. You are adding the file to git for tracking.

git commit -m "first commit" is staging the file for a commit, with a message of "first commit".

git remote add origin <link here> is you saying that these files will be stored in this remote location.

git push -u origin master is actually pushing your files to the origin (from previous step), and -u is there so it always knows that's what origin means when pushing from this repository.

If you now refresh that page in Github, you will see your README.md file. Congratulations! You've made your first repository.

...but what if you want to make changes?

Process Flow

Finally! What you've been waiting for. It's time to make a change to that repository.

Start by cding into that directory from your terminal. You'll probably notice (if you didn't in the previous step) that next to your path you can see (master -> origin). master is typically the main branch and often you don't want to make changes directly to master until you're confirmed and approved and ready to merge in your changes. So we start with a branch for our changes.

git checkout -b my-name. This here says you are checking out a branch called "my-name", instead of working directly in master. This can be done several different ways, but this is the short way I prefer. Checking out a branch means that is the one you are working on. This can also be done by entering git branch my-name, then git checkout my-name. But I like to save a few keystrokes.

Since we're using VSCode, we can simply type code . andt his will open the folder in VSCode. If you look in the bottom left corner you can actually see the name of the branch with a little git symbol next to it.

Make your changes, e.g. create new files, make changes to files, etc. Typically you want your branch to encompass a specific feature or set of changes. It's better to have smaller and more frequent commits than to do a ton of work al lin one giant commit and one giant branch. There are several reasons for this. It is easier for you (or whoever is reviewing your code) to review the changes made without getting overwhelmed; you can more easily revert any changes you've made if necessary; you can stay more focused on the task on hand... etc. There are lots of reasons. So if I just created a branch called "my-name" in my project called "portfolio-website"... well maybe I should just focus on adding my name into this site for starters.

On the left menu of your VSCode, the third icon down should be a git symbol. Assuming you've been saving your work and have finished what you're working on and saved again (ctrl+s all day every day), click into here to see a summary of changes you've made. If you click on the files with changes you can actually see a working tree that highlights the diffs (differences) between the file before and after you made your changes. Take your time looking through these changes to make sure it all looks good.

A nice thing about VSCode here is we can shorten up the process a little bit - instesad of separately adding and then committing, we can do them together. In the mesasge section write a short but meaningful commit message that briefly describes the purpose of the changes (e.g. "Add name to portfolio"). Then ctrl+enter will add and commit it with the message.

Now go back to your terminal and type git push origin my-name. Here you are pushing your branch "my-name" to the origin (your github repo), where it will show up as a separate branch. Nice!

In Github, you will see changes have been made and you have the option to create a pull request with those changes. This means you are essentially providing a suggestion for a merge into the master branch. Github is fabulous because it will check for any potential merge conflicts. If there are none (and it is your repo), you can click to merge into master. This is a good time to indicate that you want to delete the branch after merging. Otherwise you will have a bunch of branches hanging out for no reason and it can get confusing and unwieldy over time.

When that's all set, go back to your terminal where you should still be in your branch. Type git checkout master to get back to the master branch. Then git fetch to get the changes from the remote master into your local master, and git pull to get updated. Finally, git branch -d my-name will delete the local copy of the "my-name" branch. CONGRATULATIONS! You just created a repo, created a branch, made a commit, created a pull request, merged a branch into master, fetched changes, and deleted a branch.

When looking at the whole thing it actually looks quite complicated, doesn't it? It can be. Don't be intimidated. I hate to add the note that there is a TON that we didn't cover here, but it's true. Start small and practice. I literally follow this general workflow for practice projects as well, and even did this for tiny changes for the pure sake of learning and getting more comfortable with git. Thankfully there are some great resources out there if you ever get stuck (or do something silly like push your node modules or password) because guess what? You are not the only one who has done this.

TLDR

Setup

Do the things

  • Create a new repository
  • Navigate to a new folder at command line
  • git init to initialize for git
  • git remote add origin <github account> Link Github repo
  • git checkout -b my-branch Create a branch
  • code . to open that branch in VS Code
  • Make all your changes, do all the things
  • Click the git icon or type ctrl+shift+g to review your changes
  • Write a meaningful commit message and ctrl+enter to commit
  • git push -u origin my-branch to push your new branch and set origin
  • Open a pull request in Github
  • Merge your changes and delete source branch in Github
  • git checkout master to get back to master
  • git fetch to fetch the changes
  • git pull to update your local master
  • git branch -d my-branch to delete your other branch
  • Celebrate!

Resources for further learning

← Back to blog