What is Git?
Git is a Version Control System (VCS for short). VCS provide the ability to keep track of any changes made to a codebase, and usually a way to determine who made them and when. Git is a modern VCS, and it includes some awesome features. If you’ve ever wanted to split a codebase into separate branches, so you could work on something and not have it affect the production version of your code, you can do this with Git Branches. Git is fast and you can do things like “diff” changes, and point the finger of blame when something bad gets contributed to the code. To get you up and running, I’m going to cover a few of the basic features here. Let’s ‘Git started.
Firstly go and install Git, installation is dead simple and shouldn’t take more than a minute or two. This tutorial assumes some familiarity with using a command line, if you don’t you can go and read my command line tutorial to get you started.
Firstly, Git and Git commands should be run from whichever directory is the “root” of your project. For example, if you had a website then the folder that acted as your ‘www’ folder would be considered root. For now, just create a new directory and call it something like “git-test”. Now in your terminal, navigate to this directory. Now we’re ready to issue our first Git command:
$ git init
Congratulations, you have just created a Git repository, simple! Now, let’s create a file called “index.html”, issue the following command:
$ echo "hello world" > index.html
We have now created a file and it has the content “hello world”. Now, issue the following Git command:
$ git status
You should see something like the following displayed:
# On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: index.html # no changes added to commit (use "git add" and/or "git commit -a")
This might look a bit cryptic at first but it’s telling us some useful information. Firstly, it’s telling us we are on a branch called “master”. What’s a branch and who is this master? Well a branch is just a means of creating, for lack of a better word, another version of a given codebase, one which that lives outside of the main codebase but can be “merged” back into it at any time. The main codebase is what is referred to as “master”. Like any all-powerful overlord, master should act as the primary overruling version of a codebase, and the version you will be using for production.
The second line of the git status message says “Changes not staged for commit:” and, after the handy tips about how to commit, a listing of changed files. In this case we can see the file “index.html” was changed. So what do we do next?
It’s time to commit
Now it’s time to commit the changes you made to index.html into your Git repository. First we need to add the files we want to commit, this is known as “staging”:
$ git add index.html
If we look at the status of Git again now you’ll something like the following displayed:
$ git status # On branch staging # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: index.html #
Now you can see that the index.html file has been staged, and is ready to be committed to repository.
Quick tip: if you want to add multiple files at once you can use the command
$ git add --all.
Now it’s time to commit your changes, issue the following command:
$ git commit -m "initial commit" [master 49215a5] initial commit 1 file changed, 3 insertions(+), 1 deletion(-)
As you can see, Git tells us the commit was successful, an identifying hash for the commit and some stats about what changed. You have now made your first commit! When you next make a commit, anything after the
-m between quote marks is for your commit message, so make sure you make it something relevant that you and other people can understand what changes you made and what they were for etc.
So far all the changes and commits you’ve made only exist on your local machine, but this is no good if you want to collaborate with people or do other cool stuff like git pull to remote servers etc. For the sake of this tutorial I am going to use a Git hosting service called Bitbucket, which allows unlimited private repos.
Get started by signing-up for an account, then follow the instructions about creating your first “repo” and uploading your SSH key. Once you have created your repo, you can add your Git repo and push the code up to it with the following command (adapt the remote URL to suit your Bitbucket username and repo name):
$ git remote add origin firstname.lastname@example.org:your_username/your_new_repo.git $ git push origin master
You have now made the Bibucket repo the “origin” for your repo and pushed the code from your local machine up to it. From now this repo should be thought of and act as “the truth” for your codebase.
So now you’ve pushed, it time to
pull. Suppose you’ve made a load of changes to the repo on one computer and pushed it up to your remote server, you now want those latest changes on another computer. You can “pull” those latest changes to any computer so long as it too has access to the remote Git hosting service/private server. It’s as simple as this:
$ git pull
Git will now pull down all the latest changes to files and folders so you are up to date with master.
Over to you
This tutorial only touches the surface of what can be done with Git, but hopefully it will have caught your interest if you’ve never considered using it before. What do you think, do you have any good tips for using Git?