The Junior Developer's Quick Start Guide to Git

Get up and running using Git to version control your work.

Version control is one of those pretty much essential skills for getting a job as a Junior Developer. It doesn’t matter if you code in JavaScript, Python, Java, C# or any other language you can put anything you are working on under version control. Also, when you start working within a team, using a version control system is usually the preferred way of working collaboratively as meultiple developers in your team can all work independently of each other. But what is version control? The simple and short answer is that version control allows you to keep track of changes you make to your code. It provides a way to work on a copy of your code and when you are happy with how it looks (at different points of your project’s development) you can ‘commit’ a version of this. This committed version is like saying “Hey! Here’s what my project looked like at this point in time”. But more than this you can undo changes, create separate versions of your code and work collaboratively together with platforms like GitHub and Bitbucket. I’m going to walk you through your first steps with version control using Git, arguably the most popular version control system today. This is intended to be a quick start guide to get you going and using Git quickly. There’s a lot of functionality of Git we won’t cover in depth but the key things to get you using Git are included here.

Exclusive bonus: Download my Git Cheatsheet to get all the essential Git commands (plus a few more useful ones) in one handy document.

Send me my free cheat sheet

Success! Check your email in the next few minutes for your cheat sheet.

jQuery(function () { jQuery(‘#git_quick_start_top’).submit(function (e) { e.preventDefault(); jQuery(‘#git_quick_start_top’).fadeOut(function () { jQuery(‘#result-top’).fadeIn(); }); // Show success var data = jQuery(‘#git_quick_start_top’).serialize(); jQuery.post(‘https://www.juniordevelopercentral.com/receive.php', data); }); jQuery(‘#git_quick_start_top-optin-open’).on(‘click’, function (e) { e.preventDefault(); jQuery(‘#git_quick_start_top-optin’).modal({ fadeDuration: 100 }); }); });

A basic workflow

Before we get into the nitty gritty of using Git, let’s just take a quick look at what a basic workflow looks like. Here’s a crappy diagram I made. This is what a Git repository looks like - it has three distinct areas. You work on your code files as you normally would, using your text editor, and these are considered to be in your ‘working directory’. When you’ve reached a point that you’re happy with your changes or got to a natural point where you feel you need to make your work more permanent, you add files to your staging area. You can pick and choose which files you want to stage but more often than not this is everything in your working directory. Once staged, you can commit these files to the repository which makes a version of your project, stored with a unique identifier. It’s this identifier that you can use to go to back to a previous point in time or just view what the project looked like at that point. Now that you have a bit of the theory, you are ready to get started using Git. First things first you’ll need to get setup with Git.

Getting Setup

You’ll need to make sure you have Git installed and setup in order to start using the various commands. Installation is a bit different depending on your operating system. For Mac, you can simply open up a terminal and type git - if it isn’t already installed on your system, you will be prompted to install it (and possibly XCode if this isn’t also installed). If you’re on Windows, there’s an install program you can download which will get all of the necessary software setup (including a cool bash prompt!). If you’re on Linux then chances are you have Git installed already but if not you can do this with the command sudo apt install git (if you’re using Ubuntu). See the Git website for more options or put a comment at the end of this post if help if you get stuck installing Git. There are several applications you can install to use Git such as SourceTree, but for the rest of this tutorial you’re going to be using Git from the command line - it’s always good to know how to do things from the command line! You can check your Git installation is working by simply going to a terminal / command prompt and typing git. On Windows you can open up the Git Bash command prompt. The first thing that is worth doing is configuring your user name and email address to identify when you make changes to a repository of code. To set these details you can issue these two commands (replacing name and email with your own details):

git config --global user.name "James Bubb"
git config --global user.email "james@juniordevelopercentral.com"

This information will show up in Git logs and also on commits you push to 3rd party services (like GitHub and Bitbucket).

Creating your first repository

When you’re ready to start using Git you can either create a blank folder or use an existing project you’re working with and initialise it as a Git repository. To do this, in your terminal / command prompt, you need to navigate to the folder where your project is or create a new folder. You can then initialise the folder as a Git repository by running git init Create new folder on your desktop:

cd ~/Desktop
mkdir first-project
cd first-project
git init

You will see a message saying that the folder has been initialised and, depending on which terminal you are using, you may also see an additional bit of text (‘master’) on the end of your prompt. Now that your project is setup as a repository you can use Git commands to move files through the different areas. Start off by checking the status of the repository by running git status You’ll see that message ‘nothing to commit’ as you haven’t added any files yet to the folder. Let’s do that now. It’s usual to have a file that has information about the project so save a new file in your folder called README.md using your text editor. Alternatively, if you’re feeling a bit fancy, using the echo command and redirect it’s output like so:

echo "My first project with Git version control" > README.md

Once you’ve saved the file, run git status again and see the result. See how the file has shown up now? It’s in the ‘working directory’ stage of the Git workflow. So you need to add it to the staging area if you want to save a copy of this file to the repository. You do this by using the git add command.

git add README.md

Run git status again to see the result. At this point your README.md file has been ‘staged’ i.e. it’s ready to be added to the repository. If you’re thinking “What’s the point of the staging area? Why can’t I just add the files to the repository?” then that’s OK. It confused me at first too. Basically, the staging area is where you prepare a commit for your repository. You can pick and choose which files you want to add to a commit to your repository. For example, you might not want to include your CSS files in a commit, just JavaScript files. Why you would do that - I don’t know. But you could. Pretty much 99/100 times you’re going to include everything in your working directory in the staging area. You can do this by just typing git add . rather than typing out every filename. The final part to getting the file into the repository is to run the git commit command to commit the changes to the repository.

git commit -m "Add README file"

You use the -m option on the command line to specify a message for the commit. This writes your changes (adding the README file) to the repository. Try adding a few more files to the folder stage them, using git add (you can run git add . to add all files that are new or have changed in the folder which is what I do pretty much every time I prepare a commit), then commit them using git commit. Committing changes isn’t just limited to adding files though. Open up your README.md file again and add some more lines. Alternatively, you can use echo to append a new line:

echo "Another line in the README file" >> README.MD

You’ll notice that running git status now shows the README.md file as being modified: Add the file with git add . then commit it using git commit -m “Update README.md” or a similar message. You can review what you commit to a repository using the git log command. You’ll see the message, date/time and user who made the commit in the log. You’ll also see the commit hash (the long string of letters and numbers) which gives each commit in a repository a unique identifier. Check out the video for a quick guide to the Basic Git Workflow

Going back to a previous version

The whole point of version control is that you can manage multiple versions of your project and also go back to a previous point in time for your entire project or even just an individual file. There are a few ways to do this in Git but a common task is just to undo a previous commit You can do this using git revert

git revert 7951c

The parameter after the git revert command is the commit hash string of the commit you made. You can see these when you run a git log but you only need the first few characters for git to understand which commit you are on about. You’ll then see something like this: This is actually a text editor program called vi that runs in the terminal and you’re being asked to add a message to explain why you are undoing this commit. This screen has caused loads of users to go running to StackOverflow to find out how to get out of it! To get out of vi press the escape key, then a colon (:) then q then hit enter. You’ll be taken back to the terminal with a message about another commit. If you check your git log then you’ll see another commit has been added with a message explaining that the commit you specified has been reverted. The benefit of using a git revert is that it preserves the history of changes made to the repository by adding this extra commit. The other common way of undoing changes is to use git reset. You may have seen git reset –hard being used in various places. You can use this to remove any files that have been staged and reset the working directory to be the same as the last commit. This is considered to be ‘unsafe’ as you’re going to lose everything you’ve done since the previous commit you stored but is fine as long as you’re happy to remove these changes. Using git reset without the –hard option will remove any files you have staged but won’t change your working directory.

Creating branches

Now that you have some of the basics under your belt, let’s take a look at some of the things you might do within a real project. One such thing is creating and working with branches. Like with a tree, a Git repository has a main ‘trunk’ (the master branch) that contains the main copy of your project code. You can choose to create a branch of this main trunk where you can make and commit changes, without affecting the master branch. This enables you and other developers you are working with to work on new features or parts of the main project independently and without affecting the current version of the project. To create a new branch use the git checkout command.

git checkout -b new_branch

The -b option tells git to make a new branch with the label that follows. You’ll get a message to let you know you’ve switched to the branch and you’ll also see the branch time on your prompt. You can then flip between the two branches by using git checkout master or git checkout new_branch to change to each one respectively. Once you are on the new branch you can carry on making your changes and committing these as you have done before. Go ahead and add some files or make some changes to the existing files. It will come to a point where you have finished making your changes and you want to add the new feature to the main ‘trunk’ of your project. You do this by ‘merging’ the branch into the master branch (It doesn’t have to be the master branch but let’s keep it simple for now). To merge the branch you created into master, first go back to the master branch then use git merge

git checkout master
git merge new_branch

Any changes you made in the new_branch will then be merged into the master branch.

Using GitHub

So unless you’ve been living under a rock forever you’ve probably heard of GitHub and how it can be used to host a portfolio of projects that show off your coding skills. Now you understand the basics of Git and what it is used for you I hope you can appreciate that GitHub simply hosts your Git repositories. Once you’ve committed changes to your master or feature branches you can push these commits to GitHub so other people can see and make use of your code. This effectively adds another layer to your Git workflow by adding a remote area.

Downloading repositories from GitHub

You can download any of the publicly available repositories on GitHub and take an indepth look at the the code on your computer. This process in Git is referred to as cloning and can be done with the git clone command. The easiest way to do this is just to pass in the URL of the repository with .git on the end. For example, the project I just created can be found at https://github.com/codebubb/first-project so you can run:

git clone https://github.com/codebubb/first-project.git

You’ll see a confirmation on your command line that you just downloaded that project to your computer. You will then find the entirety of the code (there’s only a few files so it’s not much) in a folder called first-project which you can find in the directory where you ran the git clone command.

Pushing commits to GitHub

Let’s got through a quick example of how to push the simple example repository you have created so far to GitHub. The first thing you’ll need to do is sign-up for an account over at github.com and then login. You can then create a new remote repository on GitHub by clicking the plus sign (+) at the top of the page and choosing ‘New Repository’. Enter a name then click ‘Create Repository’. On the next page you’ll see the information you need to link the repository you have created on your computer to the GitHub remote repository. If you look at the section ‘push an existing repository from the command line’ there are two commands you need to run. You can copy and paste these to push your local repository to GitHub. In my case this would be:

git remote add origin https://github.com/codebubb/first-project.git
git push -u origin master

You will see a message a bit like this when you run these commands: And if you look at page on GitHub you will see the files you have created and committed along with the output from the README.md file. Pretty cool eh?

Working collaboratively - creating pull requests

Check out the video for how to push and create pull requests with GitHub This is the one thing I didn’t get until I started working as a developer. When you are working within a team of developers, it’s likely that everyone will be working on different parts of a project at the same time. Git allows this to happen with the use of branches which are then merged into a main branch, such as master. When you introduce a Git hosting service like GitHub or Bitbucket, a request is made to make this merge happen. This is known as a pull request. A pull request serves the function of allowing other developers to review the changes you are making to the repository, comment on the changes and either accept or reject the request. Each company will have their own workflow for this but i’m going to quickly cover how you do this for a publicly available open source project on GitHub. The first thing you need to do is to make a copy of the project in your own GitHub account from the original repository. You do this using the fork option from a publicly accessible GitHub repository. Go to the repository in my account at https://github.com/codebubb/first-project and click the fork button to make a copy of the repository in your GitHub account. Once you have a copy of the repository in your account, you need to make some changes. Update the README.md by adding your name and a quick message. You can do this by cloning the repository to your local computer and editing the README.md file, stage and commit the changes and then push them back to your forked version of the repository. Of course you know how to do all of this by following the tutorial this far! Alternatively, you can use the GitHub editing tools to make the changes to the README.md file and save this as a commit. The next step is to create a pull request to merge your changes into my original repository. To do this, go back to my repository and then click on the Pull Requests tab and click the New Pull Request option. You’ll then need to choose the option to ‘compare across forks’ and in the right hand drop down list labelled ‘head fork’ choose your own forked repository. As you might expect, the next step is to click the ‘Create Pull Request’ button. You can then type in a message to the repository owner (me in this case!) and then finally click ‘Create Pull Request’ to start the request. That’s it! You’ll see a summary of the request and if the changes you’ve submitted conflict with anything (which it shouldn’t because the change is pretty simple). I will then receive a request that you want to add something to the repository. If it all looks good, i’ll accept the request. This is what the page looks like: Once the merge is complete, when you visit the original source repository at https://github.com/codebubb/first-project you’ll see the text you added in your forked version appear in the README.md file.

Exclusive bonus: Download my Git Cheatsheet to get all the essential Git commands (plus a few more useful ones) in one handy document.

Send me my free cheat sheet

Success! Check your email in the next few minutes for your cheat sheet.

jQuery(function () { jQuery(‘#git_quick_start_btm’).submit(function (e) { e.preventDefault(); jQuery(‘#git_quick_start_btm’).fadeOut(function () { jQuery(‘#result-btm’).fadeIn(); }); // Show success var data = jQuery(‘#git_quick_start_btm’).serialize(); jQuery.post(‘https://www.juniordevelopercentral.com/receive.php', data); }); jQuery(‘#git_quick_start_btm-optin-open’).on(‘click’, function (e) { e.preventDefault(); jQuery(‘#git_quick_start_btm-optin’).modal({ fadeDuration: 100 }); }); });

Conclusion

There’s a whole lot more to learn about Git but you have learnt about the basics of setting up Git and using a basic workflow to add files to a local repository. You also learnt how to push your code to Github and also how to raise a pull request to merge your code into a collaborative project. Each company might have it’s own slightly different approach to using Git but if you are familiar with the commands and process that you have seen in this tutorial, you’ll be ready to start using Git wherever you work. Go ahead a follow the steps above to raise your pull requests on the above project - i’m looking forward to seeing your message!