Git has become a version control standard and for good reason. Its ability to branch projects, track and roll back changes makes development MUCH easier!
The Gap Between Git and FTP
When developing at some point you upload your work to a server. FTP usually does the trick and there's a couple of ways to deploy your work:
A) Upload ALL the files.
Sure, everything gets uploaded, but it can be time consuming and sometimes files get overwritten that shouldn't.
B) Only upload changed files.
That makes more sense except keeping track of which files have been changed can be messy.
Git knows which files have changed and you've been working with it the whole time, can't we just use Git to FTP?
No, it doesn't work that way. Git is a version tracker not a file manager. You could install Git on the live server, but sometimes that's not practical. With Git, FTP is out of reach.
Git-ftp: Bridging the Gap
This is where Git-ftp comes in. It's a plug-in that adds a set of commands to Git allowing you to upload your changed files via FTP.
As its website says:
If you use Git and you need to upload your files to an FTP server, Git-ftp can save you some time and bandwidth by uploading only those files that changed since the last upload.
It keeps track of the uploaded files by storing the commit id in a log file on the server. It uses Git to determine which local files have changed.
You can easily deploy another branch or go back in the Git history to upload an older version.
Well, that covers it, now doesn't it?
The git-ftp website: https://git-ftp.github.io/
Note: Git-ftp Is Not A Repo On Your Server
Git-ftp doesn't make your server a proper repository! Git is not installed on your server, git-ftp simply tracks changed files and uploads them. You can upload different branches (which is great!), but you can't pull changed files from your server.
Honestly, I've never found these restriction to be a problem.
Think of git-ftp as a way to manage ftp uploads not version control.
How to Use git-ftp in Your Work Flow
I've been using git-ftp for a while, and found it smooths out the work flow. For example, let's say I'm adding a new code called FeatureA to an existing project.
Create a new branch called 'FeatureA' in development
There's no need to pull from the server since it's not a repository. The official repository is in development.
Build and test in development.
The code works like a charm!
Deploy to the live server.
A simple command: git ftp push will send the new branch files to the server.
Test on the live server
Uh-oh! Doesn't work as expected, un-do this quick!
Reinstate the 'master' branch
Push the branch 'master' to the live server. Branch 'FeatureA' is gone. Back to the drawing board.
Fix the problem, try again.
Push branch 'FeatureA' to live server and test.
It works! Happy Dance!
- Reinstate the 'master' branch
Merge with 'master'
I have a personal rule that the live server only uses the 'master' branch.
I found if I had another branch live, it was too easy to lose track of which branch was being used. So, now I'll upload another branch for testing only, but once it checks out, it gets merged into 'master' and 'master' get pushed to the live server.
If there is a problem I can still roll 'master' back to before the last merge.
Client review and approval
I keep branch 'FeatureA' on hand until the client has signed-off on it.
Even after it's approved, I'll re-name the branch to something like 'FeatureA_done'. That keeps the branch around in case I have to go back to it, but the '_done' tells me it is disposable. I usually get rid of it when I'm sure the change is good.
Although this process may not be ideal for all cases, I have used it for a while and it works for me. I can use Git functionality and deploy through FTP with minimal friction. The other thing I like, is it's a sure thing. If you're working with a new server, as long as you can FTP, it should work. You don't have to spend time configuring the server to run Git etc. Just focus on your code!