This week on Server Side Sunday, we are going to show you Git through a small tutorial. So let’s stop Git-ing around and get to Git. For starters, Git is a version control system for multi-user working on a project together. It is an important tool for any developer no matter the size of your group!
This is going to be a three part tutorial. To start, this tutorial is going over the installation, setting up the config file, and how to initialize a local repository. Next time we will go into setting up remote repositories using online servers and how to handle multi-users. Finally, we are going to show how to use git on your website or production server. Before beginning, you should be familiar with the terminal and shell commands to understand what is going and not just copying and pasting codes into your terminal. There are a lot of resources on this but drop us a line if you would like a tutorial on the terminal.
Okay, let’s get started with installing and configure git. If you are on mac, you may already have it installed. To test, open your terminal and run:
$ git --version
If it’s not install, you can download the package from git-scm/mac. On windows, the newest version of git is available at git-scm/win. Another way that we use is through gitforwindows. So go ahead and install the package on your computer. Then come back!
All installed? Good, let’s start by running the base command. So go to your terminal and type:
If you see a bunch of text and sample codes for what you can do with Git, this is good! If at this point you get some type of an error, go back and make sure you have Git installed properly before moving on. Okay, now let configure your Git setting. It is important to set this since everytime you commit, there will be a name and email associated. Working on solo projects, no big deal, but with larger projects accountability is important. You can access the global Git file configure file by typing in your terminal:
$ git config
Let’s just set your signature, use the following two commands:
$ git config --global user.name “Patrick McVey”
$ git config --global user.email “-firstname.lastname@example.org”
Now you are ready to start using Git for your project. This will save you from having a folder filled with “v12_final_really_this_is_the_last” added to the file name. Be honest, we have all done that.
Okay, let’s run through setting up your first repository. Back to the terminal, we will create a new folder called helloGit, add a README.txt file (it is good practice to had a readme file just to describe the repository, file structure, etc.), and initialize the repository. Here are the commands:
$ cd ~ $ mkdir helloGit $ cd helloGit $ touch README.txt $ git init
There you go, it’s that simple and now we have a new repository. What does this actually mean? In the helloGit directory, we created a repository to track files. But… We are not actually tracking anything. We need to update the Git repository what we want to follow. We do this by adding files, at the moment we have only the readme file created easier. But before, let’s run a command to view the status of our repository:
$ git status
The first line shows you which branch you are on. Branches are pretty cool and the advantage of using git. By creating a branch, you can try new features, break the application, or perform updates before adding it to the main repository. We will get back to this later on. At this moment, we are on the master branch. There will be a list of untracked files in RED. This ties back to what we said earlier about how there are no files being tracked.
$ git add README.txt
Now if we run $ git status again, we will see the file is in GREEN and therefore it is tracked. The file is now in the staging area, which is a state that we can store a code before we fully commit it to the project. The commit is an official version that will be shared to everyone in the project. Generally, it is a good idea to run $ git status every once and a while to see what is going on within the project.
Okay, next let’s quickly update the file to give a description and commit that as our starting point. It is always good to have a ground zero, it’s an easy and quick way to get everyone connected to the repository. Open the readme.txt file in your prefered text editor (Recently discovered Atom and love it.) and add a brief description to the file.
Now if we run status, we will see two important things. First, the readme file highlighted in green that we added before hand and the same file in red. What this means, if we commit at this point, the changes made to the readme file will not be tracked. So let’s add these changes:
$ git add README.txt
Now we are ready to commit the file to the repository. As mentioned before, your name and email are tagged to each commit but there is another tag that must also be include, the message. This tag give everyone else the ability to see why a commit was made, keep it short and generally in the present tense for simplicity. So for this one we could use “Initialize repository with a readme file.” Putting it all together, we have:
$ git commit -m “Initial Commit - Initialize repository with a readme file”
There will be a summary of all the changes made and the mode was created. Each time a file is added to the repository, a new mode is created to track it. The $ git commit command takes everything that is in our staging area (the green files when we look at the status) and lock it into a new version.
And there you have it. Next time on Server Side Sundays we will go over how to use a service like Github for managing multi-user and some problems and solution that may arise. As a little extra, here are Seven Server Side Sunday tips:
is an asset for visualizing file structures through the terminal. It can be install for mac by running “$brew install tree”. Then you are ready to use it!.