Tutorial on using GIT instead of FTP to deploy files

Posted in Tutorials

As of this writing in 2014, many web hosts (especially cloud hosting) are using Git instead of FTP to deploy files to their servers.  Some hosts don’t even allow FTP any more.  While traditional shared webhosting still uses FTP, other specialize hosts (such as WPEngine) allows for both FTP and GIT (although it’s .gitignore file prevents upload of certain files via git).

So if you are in the web industry and are using SFTP (hopefully you are not using FTP anymore), it might be time to learn how to deploy files to your web host server using Git.

As an example for this tutorial, we will start by using Git to edit our GitHub site, because it is free to create and it uses https protocol, which is one of the easier way to access a Git repository.  Other protocols for accessing a git repository is described here.

We showed you how to create a GitHub site in a previous tutorial.

1. Getting Git on your machine

First you have to install Git on your local machine.  If you are on Windows, you can install Git for Windows and it will give you a Git Bash command line interface located in “C:\Program Files (x86)\Git” as shown here…

Actually that is a shortcut to points to “C:\Program Files (x86)\Git\bin\sh.exe” –login -i”

If you are on Mac, you can download the latest git from git-scm.com   Sometimes if you are on a older Mac where the latest Git doesn’t run on the older operating system, you might get “Illegal instruction” when you type “git” in terminal.  In that case, you may have to try older version of Git obtained from here.

For other operating systems, you can get Git from links here.

You want to launch Git Bash (in windows) and Terminal (on Mac) and navigate to an empty working directory.  We use the cd command to go to “c:\tutorials\github”

On Windows the command is “cd /c/tutorials/github”

To check that you have git installed correctly.  Type “git” and you should see the git help page.  If you type “git –version”, that tells you the version of git.

If you need to exit Git Bash or Terminal, type “exit”.

2. Git clone of site

We are now in command line terminal in an empty project working folder.  We want to get a copy of our GitHub site from the server onto our local machine.  We do this by running “git clone” in the Git Bash or Terminal like this …

git clone https://github.com/username/username.github.io.git

(where you replace “username” with your actual GitHub username).

You get the “git url” on you GitHub account from here …

Note the URL looks just like a typical web address except that it ends in “.git”.  The https instead of http indicates that transmission  is encrypted.

After you run the git clone command, it creates a new folder of the form “username.github.io”.  Navigate with “cd” into that folder…

cd username.github.io

This is where it downloaded your GitHub site and this is where it created your local git repository.  If you make your operating system show hidden files, you will see a “.git” folder.  That is the local git repository on your local machine.

3. Use git status to guide your workflow

The command “git status” is your friend.  If you can’t remember what to do next, “git status” will often give you clues.  Try it now…

git status

It should get something like …

If you got the message “fatal: Not a git repository”, then probably you forgot to “cd” change directory into the repository folder first.

It says that you are on the “master branch”, which is the main branch that you will be making changes to.  It says “working directory clean”.  That means that it has not yet detected any additions or modifications to the files in your repository folder yet.

Now using your favorite editor, let’s make a change to the index.html file on your local machine. And then run git status again…

See that it now knows that we modified index.html.  And it suggests using “git add”.   We run this command…

git add index.html

This adds the index.html file so that it is “staged for commit”.  It puts it in a staging area so that it is ready to be committed.  Run git status and it shows the changes to be committed…

It you staged a file that you don’t intend to stage, you can unstage it with the suggested command shown.

But we want to keep our index.html staged so that it can be committed.   It says “changes to be committed”, suggesting that our next step is to “commit” our changed file.  We do this with “git commit” like this…

git commit -m “made change to homepage”

The -m is a “flag” (also known as a “switch”) to the “git commit” command.   It says that a “message” will be following the -m flag.   We put the message “made change to homepage”.  It is a comment or note about this particular commit.

If you get a screen like this…

most likely it is because you only typed “git commit” and forgot to enter an message using the -m flag.  It says that an empty comment will abort the commit, implying that a message is required.   Note that in our case (on Windows Git Bash), it popped open the VIM editor.   If you are not used to the VIM editor, better to exit out of it without entering a message.

You exit the VIM editor and abort all changes without any prompts by typing …

:q!

This exits VIM.  But now git says …

So we type in the “git commit” command correctly like this…

That works.

4. git push to server

And now our git status shows …

It says that “nothing to commit, working directory clean”.  That means all local changes have been committed.  But it has only been committed to the local git repository (on your local machine in the .git folder).  There has been no change on the server.

The above message says “On branch master.  Your branch is ahead of ‘origin/master'”.

That means your local master branch (the branch that you are currently on) is ahead of “origin”.  Think of origin as your server endpoint.  Essentially, it is saying that your local branch has changes that your server do not have yet.

Now is that time to push our changes to the server.  But how?  See the suggestion in the message to say “git push”.  But before we do that, let’s confirm that we are pushing it to the right destination server.   The server is like our “remote”.  We type …

git remote

to see what our remote endpoints are.

Hmmm.  Not too much information.  It just tells us that our remote endpoint is called “origin” (which is often the case, but not always because we can rename it to something else).  “origin” would be part of what we would need to type in later when we do our “git push” command.

But first let’s make it display more “verbose” information by adding the -v switch as shown…

git remote -v

This time it shows us that both the fetch and push endpoints are called origin and shows the actual git URL of the repository on the server…

I typically would always just use “git remote -v” and forget about using “git remote”.   It is tempting to think that “-v” means to “view the remote”.  But “-v” means “verbose”.

After seeing that our endpoints are correct, we perform our git push with this command…

git push origin master

This pushes changes in our master branch (the branch we are currently on) to “origin” (which is our remote server with endpoints of the git URL shown previously).

The order of “origin” and “master” is important.  Think of the command as “git push to origin from master branch”.

When you run this command, it will prompt you for your github username and password.  After all, it doesn’t want just anyone uploading things to your GitHub repository.

git status now shows a message that is very sparse…

Nothing to commit, working directory clean, no suggestion, nothing to do.  We are done.

View your github site and see the change to the homepage has propagated to the server.

We have made a change to a file and pushed it up to the server using git and without touching any FTP.

---