Kyle M. Perkins

My Journey

My journey to discovering git was not an easy one. Since git was not covered in my formal programming lessons, I had to learn "version control" the hard way - the very hard way.

When I started learning HTML back in 2001, I learned to save and modify local files only. In 2002, I learned PHP and MySQL by working on a team server, but version control was not introduced (git was introduced to the world in 2005, but options like CVS or SVK weren't taught). My first local server came in 2004, when I learned to FTP files, instead of testing local files only.

I quickly updated to SSH'ing into the server and editing the direct code, and backuped the files using a combination of file extensions (such as .bak, date stamps like.20150515, and "Backup 20140523" folders).

...and I used this method up to about a year ago, when I took a git intro course online. Unfortunatly, I didn't quite understand the purpose of git because the demos kept talking about files that either already existed, or branches that were made by someone else - never really diving into the underlying purpose of git, which was version control.

I also couldn't get used to the idea of uploading my database login information (along with other private code) to the public site GitHub, which is great for open-sourced projects (see mine here), but not great for a company version control backup. So I dabbled in git for a while, until it hit me about a month ago: I could use git on my own server(s) and not have to deal with private repositories on GitHub (or the prices).

So, I started using git on my server for backups of projects site-wide. Then, I wanted to deal with errors on a non-production server basis (I didn't want the world to see my error testing, because that would be unprofessional). After getting a local Apache server, and MySQL server, and installing PHP (on Windows), I thought that I could use the GitHub software to create backups - but that was only for the GitHub site; I needed something to work with my own existing servers. Therefore, I installed Cygwin and got the Linux-enabled commands with git to my production server.

Overall, this is what I learned, and I hope it helps others:

Usage

(If you don't already have git set up on your remote server, then please do so by installing it - I recommend sudo apt-get install -y git. Otherwise, this won't work, and it's just a bunch of lines of code)

The Setup

Remote (seperate from production folder):

mkdir [dir].git && cd $_
 
git init --bare
 
cp ~/post-receive.sample hooks/post-receive

The hooks folder deals with webhooks to automatically catch incoming files and do something with them (or at least, that's what I've discovered). To make the hooks run properly, you need a post-receive file, and this is what it should look like:

post-receive.sample

#!/bin/sh
 
GIT_WORK_TREE=[absolute path to production] git checkout -f

Once you have that set up, you can work on your local machine to create and modify files.

Local development machine

# If files do not exist
 
git clone user@server:[dir].git 
 
cd [dir]
 
# If files DO exist/update
 
cd [dir]
 
git pull
 

 
# Time for editing
 
vim [file]
 
[...]
 
[work on files, test on development machine]
 
[...]
 
(Ready to upload to production server)
 
git add [file(s) - * works as well]
 
git commit -m "Relevant message to update"
 
git push

One important note: As I have learned, your Git folder is not your production folder. I had my .git folder in my production folder of a project, and it was good for local editing, but not remote pulling. If your project folder (example: project.git) is somewhere else, like your home folder, then you can use the post-receive webhook to automatically pull committed files to the production area

Bonus: SSH Login w/o PW

Unless you want to type in your login information every time you git push, I recommend setting it up so your local machine/development server can automatically upload to the production server. If you are running a Linux system (and I recommend you do), then you can do the following:

SSH Password-less Login

On your local machine (hopefully a Cygwin or Linux/Mac Terminal)

ssh keygen -t rsa
 
ssh user@B 'mkdir -p .ssh'
 
cat .ssh/id_rsa.pub | ssh user@B 'cat >> .ssh/authorized_keys'

B = Remote server

Summary

There is still quite a lot I don't understand about git (like branches, merging, etc), but I am getting better. I've been using this guide as a resource, as many other guides are very technical for a non-git person.

My takeaway: Better integration into team development instead of just "solo development"