Update: Fancy a video course? I made my first one on Skillshare, go check it out.
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.
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.
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 (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. One other popular VCS, that’s still used to some extent today is Subversion. You can see a detailed list of Version Control Systems here.
Git was made by the ever so slightly genius Linus Torvalds, the father of Linux:
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 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 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. You click the link, and you see something like this:
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:
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:
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:
Now, click on the Compare & pull request button.
Here you can add some comment summarizing your pull request:
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:
Finally, click the Delete branch button as it’s a good practice to not keep the merged branches in the remote repo:
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. ?
