Git Great at Version Control: A Beginner’s Guide to Git and GitHub
Time travel is real.
Okay, consider this: you’ve thought up a brilliant idea for a new game, it’s fresh and experimental, and you dream of it being an “Editors’ Choice”. It’s going okay so far but being bold breaks the game and slowly your motivation. What made this 4th bug? And how do you go back? This is where the Big Blue Box comes in (I love me some Tenth doctor and Rose Tyler). With the highly popular version control system git you can go back through time, create separate playspaces for new features and see all your changes from your first line of code. And collaborate with no fuss or annoying emails! So scrap version11_i_think.js and check out my git basics guide below.
To keep this post relatively short, I’m going to cover the key git commands in this part. Branches, merging and forking will be covered in an upcoming post. Allons-y!
Git great at version control
1 – A little context
2 – Installing git
8 – Extra Resources
A little context
Git is a local version control tool, tracking changes with each commit you make (checkpoints in space and time that you can go back to during your project). Once you’re ready to “push” your local project to the “cloud”, Github comes in. It’s your git interface, where you can view all your commits, collaborate with other developers and contribute to open-source projects. Without further ado, let’s get it installed!
To get git up and running first open your Mac, Lunix or Windows terminal window. (If you’re unfamiliar with the command line here’s my step by step guide.)
The following is a Mac and Linux guide but here are the steps for Windows.
Step One: Install Homebrew (an open-source software that makes installation a breeze) by executing the following command:
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Step Two: Paste
$ brew install git. You can double check this worked by typing:
$ git --version. If terminal returns git version *insert number here* you’re all set!
$ git --version git version 2.13.1
Configuring you settings
Before creating your first git project configure your working environment with
$ git config --global user.name "Your Name"
$ git config --global user.email email@example.com
NB. To work without entering your password, add your computer as a trusted device by creating a SSH key.
Initialising your project
Now that all the admin’s out of the way let’s create our first git repository (repo). This is where all files and commits are saved. Start by making a new directory (
mkdir <directory> ), going inside it (
cd <directory>) and typing
$ cd Documents $ mkdir gitprojects $ cd gitprojects $ git init Initialized empty Git repository in /Users/Jem/Documents/gitprojects/.git/
The folder is now a git repo (note the line “Initialized empty Git repository in /Users/Jem/Documents/gitprojects/.git/).
Next, add a few files with
touch <file> and check where you’re at with
$ touch index.html styles.css $ git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) index.html styles.css nothing added to commit but untracked files present (use "git add" to track)
Let’s walk through this. We’re on “Initial commit” as we haven’t created our first commit yet. It’s great practice to commit regularly, with every key change.
There are also two “untracked files” as we created an index.html and styles.css but haven’t told git to track them. Let’s do this in the next step.
Creating checkpoints in space and time
Creating commits is a two step process:
git add <file>
git commit -m "Commit message goes here"
We can add any number of files for commit (depending on preference) ie. you may want to add one file at a time. In step one add index.html (
git add index.html) into the “staging area” of “changes to be committed”. This area is the space between your repo and a commit.
$ git add index.html $ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: index.html Untracked files: (use "git add <file>..." to include in what will be committed) styles.css
On to step two:
git commit -m "Commit message goes here".
Note that it is common practice to write your commit messages in the present tense (as a command) e.g. Add index.html. Let’s see this in practice:
$ git commit -m "Add index.html" [master (root-commit) 2e97a1c] Add index.html 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 index.html $ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) styles.css nothing added to commit but untracked files present (use "git add" to track)
Once you’re a few commits in you’ll probably want to check out your previous changes. Cue Big Blue Box.
Travelling Back and Forth
Let’s first set our destination by typing
git log. A list of all your commits will appear, sorted by most recent:
commit 74d74ff1a940b7afb33a45e38131a17b9b060309 (HEAD -> master) Author: Jem <emailaddress> Date: Wed Oct 4 10:19:26 2017 +0100 Add styles.css commit 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 Author: Jem <emailaddress> Date: Wed Oct 4 10:17:35 2017 +0100 Add index.html
You can see two commits listed with a long list of numbers and letters after commit. This is your commit id e.g. 74d74ff1a940b7afb33a45e38131a17b9b060309. To travel back to a previous commit add the chosen id to the
git checkout command:
$ git checkout 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 Note: checking out '2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 2e97a1c... Add index.html
The above is a little daunting and we’re going to cover HEAD in more detail in the next post. The important part is that we’ve moved to our first commit and successfully travelled back in time. Cool right? To travel back to your most recent commit type
git checkout master. Easy peasy.
So what’s the difference?
git diff command is the beauty and power of version control. Say you come across a bug in your game. Checkout your commits and open each version in the browser. Once you’ve found the bug check the differences between the version with the bug and the next commit to find the culprit.
This command takes two arguments: two commit ids. Let’s add a few changes to gitprojects to see this in practice.
$ git log commit c23b4aedfb41f553eeaf799191f90b882f91291b (HEAD -> master) Add boilerplate and list comment commit 74d74ff1a940b7afb33a45e38131a17b9b060309 Add styles.css commit 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 Add index.html $ git diff 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 c23b4aedfb41f553eeaf799191f90b882f91291b diff --git a/index.html b/index.html index e69de29..6505486 100644 --- a/index.html +++ b/index.html @@ -0,0 +1,13 @@ +<!DOCTYPE html> +<html lang="en"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1.0"> + <title>Git Great</title> +</head> + +<body> + <h1>A Git Great Project</h1> + <! --- going to add a list of reasons why git is cool --> +</body> +</html> diff --git a/styles.css b/styles.css new file mode 100644 index 0000000..e69de29 (END)
Above you’ll see I added a boilerplate and comment to index.html, commited it, noted the two ids and included them in the
git diff command ie.
git diff 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 c23b4aedfb41f553eeaf799191f90b882f91291b
The first argument is the first commit id
2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 (“Add index.html”) and the second is
c23b4aedfb41f553eeaf799191f90b882f91291b “Add boilerplate…” . The differences are shown in adds and minuses, with the number of line changes (13). This can save a lot of time in the long run!
Pushing your Changes to the Cloud
When you’re ready to push your local repo to Github (using
git push), begin by creating a new repository on GitHub without a README.md (you can add this in later).
Quick side note: “a remote URL is git’s fancy way of saying ‘the place where your code is stored.'” Source
After clicking create repository you’ll see a page include the following. The https link is your remote repository URL.
To push your local repo onto the remote, first add the remote :
git remote add origin <remote repository URL> and then
git push -u <remote> <branch>.
$ git remote add origin https://github.com/jema28/test.git $ git push -u origin master
You can verify this worked using
git remote -v. Your remote URL should appear after the origin:
$ git remote -v origin https://github.com/jema28/test.git (fetch) origin https://github.com/user/repo.git (push)
And you’re all hooked up!
We’re just getting started so check out more things git in the next few weeks. See you then!
Version control never felt so good! *Cue Tardis swoosh*
Udacity Git and Github Course : A brilliant and in-depth course covering git/version control.
Learning version control completely changes your workflow and is an invaluable resource when working alone and as a team. Let me know how it’s going and how it’s helped in the comments below!