Learn Git fast as if your job depends on it
Tags: git, branching, sourcecontrol, vcs
Published: 2017-12-17 13:49:51

---
title: Learn Git fast as if your job depends on it
published: true
description: This article covers the minimum number of Git commands that you need to learn in order to start being productive and get that code from your machine to the company Git server. Also, a bit of theory and Git installation is covered as well.
tags: git, branching, source control, vcs
---

![](https://thepracticaldev.s3.amazonaws.com/i/fd17sya3is4g5q2pcl0t.jpg)

_Update: Fancy a video course? I made my first one on [Skillshare, go check it out](https://skl.sh/2qE11BP)._

_Originally published on [my blog](http://www.nikola-breznjak.com/blog/miscellaneou/learn-git-fast-job-depends/)_

## TL;DR
In this post, with a grain of humor, I'm going to show you the minimum number of Git commands that you need to learn in order to start being productive and get that code from your machine to the company Git server. Also, I'll cover a bit of theory and Git installation as well.

## Disclaimer
> ⚠️ Nobody in this story, and no outfit or corporation, thank God, is based upon an actual person or outfit in the real world. But I can tell you this; as my journey through the software jungle progressed, I came to realize that, by comparison with the reality, my story was as tame as a holiday postcard. ~ John le Carré

## Setting the stage
So, let's set a scene; it's your first day as a junior developer straight out of college. You get to work, greet your superior that's supposed to be responsible for you, and since he's too busy with putting down some fire that just popped up, he, conversely, while you're trying to keep up walking aside him tells you something like:

> I've set the Git access for you to my website project.
>
> You have a ticket in our project management tool assigned to you. No worries, it's just some simple stuff that needs to be changed.
>
> Just check the email details, and you can start immediately.
>
> I'm aware that you may not be familiar with Git. I'm not trying to be an asshole, but just deal with it, learn it, OK? Don't they, like, teach you kids nothing in school these days?
>
> Ah, I gotta run.
>
> Oh, and one more thing, look up branching and do not EVER, and I repeat - EVER, commit to master; do a PR instead! Good luck and see ya later!

OK. You sit down at your cubicle, open up your email client, log in, and there you see the email (without the subject line, of course) with the contents:

> [Here's a link to the Git repo on Github](https://github.com/Hitman666/MrSupervisorWebsite).
>
> Good luck,
> Mr. Superior

## Reality sets in
> ⚠️ This, in and of itself is a poor onboarding if you ask me, but I personally have seen it way too many times, so here are the things you need to do to get productive fast and learn the ropes as fast as you can.

So now you're, in lack of better words, screwed (you know the exact word, but we're not supposed to be using profanity here, ae?).

You're lost. You heard about Git before, but you never used it. Now you're kicking yourself for not learning it properly yourself. But, it is what it is, and since you're really determined to make it in this 'programming' world, you're ready to do what it takes.

![](https://i.imgur.com/YZ4W1Ao.jpg)

_I would question the fact that if you are 'so into it', how come you haven't learned it yet, but as Mr. Superior said, I'm not trying to be an asshole_ 😉

Therefore, buckle up young padawan, you're in for a ride!

## What is this Git thing?
First, let me start off with a few problems:

+ Say you're writing a seminar and you make some changes, save them, go out of the text editor, come back, and you want to see all of your changes that you did last in the file. Or, for example, you want to undo some changes that you did last night (writing a seminar after returning from a party is a noble act, but not a very smart one!).
+ While writing this seminar you create several versions of the same file and you don't even know what's changed in which version; you would really love to know what was, for example, changed in this current version based on the, say, a version from a few days ago.
+ You're working on a group project and someone deletes your changes 'by accident'.

[VCS](https://en.wikipedia.org/wiki/Version_control) (Version Control Systems) tends to solve these problems. And, let me start off by saying that no, you don't need to use VCS _only_ for writing code (thus the seminar example). You can use it for any textual project. One of VCS solutions is [Git](https://git-scm.com/). One other popular VCS, that's still used to some extent today is [Subversion](https://subversion.apache.org/). You can see a detailed list of Version Control Systems [here](https://en.wikipedia.org/wiki/List_of_version_control_software).

Git was made by the ever so slightly genius Linus Torvalds, the father of Linux:

![](https://i.imgur.com/ESoSiQq.jpg)

Git is a distributed version control system (VCS).

**Version control** means that you use it to store versions of your documents. True, it seems it's very popular among developers, but designers and other people (that are a bit more tech savvy) also use it to track versions of their files.

This whole **distributed** part is one of the things that makes it different from other VCS. Rather than have only one single place for the full version history of the software, as is common in once-popular VCS like CVS or Subversion, in Git every developer's working copy is also a repository that can contain the **full history of all changes**.

## OK, but what is Github?
> Something like Dropbox, but customized for Git.

[Github](https://github.com/) is a hosting service for Git projects, with some additional batteries included that we're not going to get into at this point, as you're short on time. Think of it as a place where you store your Git 'stuff'.

## Installing Git
To install Git, go to the [official website](https://try.github.io/) and download the executable for your machine. I'm not going into the installation details as they're really just a bunch of `Next, Next, Next, yes to malware, Finish` set of steps. _I'm kidding about the malware OFC_.

To make sure your installation was successful, run the following command in your Terminal/Command prompt:

`git --version`

You should get something like:

`git version 2.10.1`

## Fetching the repo
OK, so let's finally get some action. In your email, you received an URL to the Git repository. It was this: [https://github.com/Hitman666/MrSupervisorWebsite](https://github.com/Hitman666/MrSupervisorWebsite). You click the link, and you see something like this:

![](https://i.imgur.com/nvz9ulq.png)

Click the `Clone or download` button, make sure you see the `Use SSH` in the top right corner of a popup and copy the link.

To get this repository to your computer, you have to execute the following command in your Terminal/Command prompt (I'll use Terminal in the rest of the post):

`git clone https://github.com/Hitman666/MrSupervisorWebsite.git`

The output of the command should look something like this:

```
Cloning into 'MrSupervisorWebsite'...
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 7 (delta 0), reused 7 (delta 0), pack-reused 0
Receiving objects: 100% (7/7), done.
```

## Checking out the code
Now, go into the newly created `MrSupervisorWebsite` folder and open it in your editor.

You should see three files: `index.htmnl`, `style.css`, and `README.md`.

You quickly go and click to open the `README.md` file, but all you see is this:

```
# MrSupervisorWebsite
```

Hmm, so, no help there.

You open up the `index.html` file and you see:

```
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>MrSupervisorWebsite</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1 class="title">Welcome to MrSupervisorWebsite!</h1>
</body>
</html>
```

OK, finally something that you're familiar with! You also open up the `style.css` file, and you see:

```
.title {
    color: blue;
}
```

Next, you take a look at the ticket assigned to you in the project management tool that Mr.Superior mentioned, and it looks something like:

![](https://i.imgur.com/UV33DqY.png)

You take a deep breath, finally something that you know how to handle! 💪

You're a bit taken aback by the 'manly color', so you go and ask Google:

![](https://i.imgur.com/lgoY0Ui.png)

You pick the `4872A2,` and you're happy. You think to yourself: OK, now I just need to change this color in the `style.css` file, somehow add this to this Git thing and 'publish' it.

You're right, but not so fast! You remember that note from Mr.Supervisor that you shouldn't commit to master, EVER?

## Creating a new branch
So, what is this `master` anyway? You go online, and you find that:

> Git has branches, and its main one is called `master`. You can create as many of them as you want, based on any other existing one.

Also, you read a bit about the PR, and you learn that:

> PR is short for Pull Request. Pull requests let you tell others about changes you've pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.

So, this is smart, right? You can add your code to the Git repo without breaking any existing stuff on the `master` branch, and through this PR you can then ask a more experienced developer to do a CR (code review) on your PR and accept it or not.

You're smart; you see the huge benefit of this vs. just committing something to `master` and potentially breaking something in production.

Now, to circle back a bit and explain how could it be that you would break something!? Well, there's a thing called CI (Continuous Integration) and CD (Continuous Deployment), and you can read more about it, but in essence, it's this:

> Every time someone pushes a new commit to `master` branch, a whole set of deploy scripts are being triggered, and essentially the new code that's pushed is going to appear in production.

What this means is that if you change that color and you commit it to `master` (you'll learn in a minute how to actually do this `commit` action), it will 'automagically' appear in the production on the website.

⚠️ Of course, the premise is that the service is set like that in the first place.

So, you get the point and value of additional branches, and you **create a new branch** by executing the following command in your Terminal:

`git checkout -b poppingTitle`

The upper command is a shortcut for two commands:

```
git branch poppingTitle
git checkout poppingTitle
```

The first one creates a new branch called `poppingTitle` from the current branch that you're on (in our case that's `master`). The second one 'checks it out'. Meaning, it places you on that branch.

## Adding some code
Now you're finally ready to add some code!

Open up the `style.css` file, change the color, and save the file. It should look like this now:

```
.title {
    color: #4872A2;
}
```

One useful command that you'll use a lot is `git status`, which will you tell you the status of your git project. If you execute that in your Terminal you will see that the `style.css` file was modified:

```
On branch poppingTitle
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   style.css

no changes added to commit (use "git add" and/or "git commit -a")
```

As you can see, in the instructions from the output, these changes are not yet added to the commit. To do that, execute the command `git add style.css`. Of course, if you were to have multiple files you would not have to list each and every one of them, you would just use `git add .` command.

If you run the `git status` command again, you'll see that we have changes that are ready to be committed: 

```
On branch poppingTitle
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   style.css
```

## Committing code
To commit (one could use words like save or apply here for better clarity) the added changes to your local repository, just run:

`git commit -m "Changed the title color"`

Of course, the commit message can be anything, but please do yourself a favor and write meaningful commit messages.

If you run the `git status` command again, you'll see that we have a clean repository:

```
On branch poppingTitle
nothing to commit, working tree clean
```

## Pushing to a remote repository
So, great, at this point you have the change locally in your repository, but you'd like to get this back to Github (the so-called remote repository, or `origin` as it's usually referred to).

For that you have to execute the following command:

`git push origin poppingTitle`

You should get an output similar to this:

```
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:Hitman666/MrSupervisorWebsite.git
 * [new branch]      poppingTitle -> poppingTitle
```

## Doing a PR
If you check Github now, you'll see that we've pushed this new branch:

![](https://i.imgur.com/hoaLPE4.png)

Now, click on the `Compare & pull request` button.

Here you can add some comment summarizing your pull request:

![](https://i.imgur.com/NZDFScl.png)

Finally, click the `Create pull request` button.

And now (if we're playing by the book) someone else from your team would come and review your code. At this point, you could let someone know about this via your Project Management Tool (JIRA, Trello, Leankit, Kanbanflow, etc...) by putting this task/card in the appropriate column.

## Your PR is accepted
When the pull request is approved (you get a notification from Github when someone approves or rejects it), you as the author go back to Github and just click on the `Merge pull request` button, and that's it:

![](https://i.imgur.com/oDzK7ZE.png)

Finally, click the `Delete branch` button as it's a good practice to not keep the merged branches in the remote repo:

![](https://i.imgur.com/2XZfov5.png)

## You get to live another day
Your merge to `master` goes well, it's auto-deployed, you check the website and all is cool. You update the ticket in your ticketing system by placing it in the 'Deployed' column (or some similarly named column). 

It's 17:12, you close your laptop and cheerfully go home to learn more about this awesome Git thingy. 💪

![](https://i.imgur.com/0jaodld.jpg)