A Quick Introduction to Git

Photo by Roman Synkevych on Unsplash. Fun Fact: Instead of “Octocat,” Github had originally planned on calling their mascot the “Octopuss.”

You can probably learn Git in about 15 minutes, thanks to Roger Dudler — at work we love directing newcomers to his guide, which is the most useful and succinct tutorial I have ever found on the matter. Can you really understand Git by reading this guide alone? Probably not…but you will hit the ground running and you will quickly have something to show for your efforts.

The only things I wish Roger Dudler had added to his guide:

• Your workflow should probably not consist of using git add *. You should use git status to view a list of what files have changed, to ensure that you are not adding “garbage.” You would not believe how much crap my coworkers gave me for trying to push up everything.
• Master has mostly been replaced with main.
• Your commit messages should describe what you did in terms of what you added or modified — it should be a little bit like logging features. If anything goes wrong, you can later use your git log in order to find out where the bug likely occurred. Your git log should not read like a diary…mine used to, and it was weird.

And, though it kind of goes without saying, StackOverflow is a great resource for all Git questions…especially the really common ones.

There are a million tutorials on Git; it is almost as if every blogger who uses the “coding” tag feels obligated to add their own one to the mix. What I linked above is my favorite, though it does mostly just cover a few commands without really explaining what Git is and why we use it.

Now, if anyone asks me something like this again in the comments, like someone had on my BetterProgramming article:

Yeesh.

See this git repo? If you click it, you will notice that it exists.

In all seriousness, though, you can find some really in-depth guides on Git. This page, for example, lists a bunch of Git courses you can take. Had my repo above not simply been a place where I shared code the way I probably should have done with Codepen or Gist, it would have also included multiple branches, a well-formated README, and multiple contributors.

Using Git to simply push changes is easy. What makes Git complicated is when things go wrong — when you have a merge conflict, or when you need to work with other people in a non-trivial code base.

Why do we use Git?

In short, we use Git because it is one of the most widely-used version control systems in the software industry. Aside from the fact that it was developed by Linus Torvalds, a lot of Git’s success is probably related to Github. You can use Github to easily view open source projects (there are also proprietary versions you can use for internal company code), collaborate with others, and find out exactly who wrote the bug that it took three hours to fix.

In college, we used Git because we had to. A professor had his own system for code submissions, and you had to use Git for them. Back then, Git seemed really easy — this is simply because we all submitted solo projects, and there was no sort of collaboration in the code itself.

Version Control Software vs. The Alternative

Before we used Git, we tried a number of extremely stupid things instead. In one project we tried using Google Drive — not Google Drive for developers, just a bunch of text documents. There was no easy recovery mechanism. There was no merging. It was just a backup system.

We also tried saving a million versions of our files. We would add timestamps to them, and all “merging” just took place by hand. It was awful.

Then there was a time we just used nothing. At all. We wrote code, we messed up code, and then when someone accidentally lost our files we were narrowly saved by a Linux snapshot. All of these situations could have been avoided with Git.

Git vs. The Alternatives

Though not everyone will agree, I think you will really appreciate Git after you try using one of the version control software alternatives. I do not want to call out the thing we used to use at my current company, but it was not intuitive at all.

How do we use Git?

https://xkcd.com/1597/. XKCD is licensed under Creative Commons

I will be referring a lot to the Roger Dudler guide on this:

• Download and install Git. Follow one of the links on Roger Dudler’s guide (this, for example, is the link for Windows)
• Create a new directory, cd into it, and use git init to create a new repository. Make sure you are in the right place…using this command in the wrong place will make things confusing (though this can easily be undone)
• Use git clone path/to/repository or, if the repo is on Github, use the instructions here
• Use git add (preferably after git status) to propose files you will change.
• Use git commit -m “Commit message”
• Use git push origin main. If this is a new project, you will need to first do git remote add origin <server>. If you want to commit to change, you are going to have to push for it. The reason I made up this dumb mnemonic is that a lot of people will commit and forget to push.

Branching

• Use git checkout -b feature_x to create and switch to a new branch
• Use git checkout main to switch back

The guide does not really explain it, but the idea here is that multiple developers will pull from the main branch, work on individual features, and submit pull requests. Some people do all their merging on a development branch.

• Use git pull to pull in the latest changes. This is a combination of fetch and merge
• Use git merge <branch> to synchronize another branch with yours. Typically this will result in conflicts. On a nice code editor like VSCode there are built-in tools for easily resolving merge conflicts, but if you are one of those purists who does everything on a Linux machine using nothing but Vim and a single monitor, you can grep for git conflict markers

Is that it?

See this Stackoverflow question on how to revert to a previous commit? See how it has more than 7000 upvotes? You are going to find a lot of Stackoverflow posts like this one. It is always good to check things out before carrying out some fix.

For example, using git reset hard can be dangerous — this is why the post recommends first using git stash.

If you are going to use Git, then you are going to use Git for quite a few things. Maybe you will also use Github, and appreciate how you can look through your code base during past commits like an archaeologist uncovering the secret of how the heck your former coworker wrote his test cases. Maybe you love the backup system. Maybe this is a big resume booster.

Or maybe you think the entire thing is confusing, and frustrating. If that is the case, you are not alone. One secret confession I have is that I occasionally keep files in a place called PrimitiveBackups. If anything goes wrong with Git, this just has important files saved off.

What are cool things I can do with Git/Github?

You can use Github Pages for free web hosting. I think this is awesome. You can even use a framework like Vue.js or Bootstrap and build out your website that way.

The caveat is that you cannot use this for any server-side stuff. This is why the CORGICorporation website errors out if you try to use the contact form. I thought it would be funny to leave the contact form in, anyway.

You can also publish a “gitbook.” I think these are really cool. Someone on Hackernoon demonstrated publishing an “online book” in this way, and it looks great. Would probably be great for documentation, too.