Let’s set the scene. Say you are a web freelancer and are almost finished with a client’s new website. Over the years, you have learned the hard way not to edit the files directly over FTP. It’s too easy to make breaking changes with no record of what changed and who did what. Nowadays you are using Git to manage the version of the files.
Why use version control?
There are many benefits of using a version control system for your projects. Even if you’re a very organized person, you still might get confused with a naming system like `index-2017-01-12.html` or `header_image_final_final_v2.svg`. Is it really final? How do you know what exactly is different between these versions and the last?
A version control system (VCS, like Git) enforce that there is only one version of your files at any given time. All past versions of files are neatly packed up inside the VCS. When you need it, you can request any version at any time, and you’ll have a snapshot of the complete project at hand.
Every time you save a new version of your project, your VCS requires you to provide a short description of the changes. Additionally (if it’s a code/text file), you can see exactly what has been modified in the file’s content. The VCS helps you understand how your project evolved between versions.
Deployment / Uploading
As useful as a VCS is, it doesn’t directly help with uploading files to a live website. (We’ll refer to that as deployment.)
Deploying files can be very easy. Use an FTP client (e.g. Transmit) to upload files via FTP or SFTP straight to your server. The initial release of a site is especially easy: just upload all the files.
When you make changes to a site, you also need to upload files. But… which ones? Do you always remember which files you have changed? If your panicked client calls to tell you that the site is broken, do you know what changed the last few times you uploaded files?
If you are using Git, it’s easy to see. But still, Git doesn’t do deployment, and manually checking which files have changed and moving those is error prone and tedious. You still need a smart way to upload and deploy your changed files only.
So what other options do you have for deploying files? One option is also installing Git on the server. Then just like you push and pull from your Git repository locally, you can pull from that repository on the server and the server will pull down the latest changes. This isn’t an option for everyone, though. It will require shell access to the server and that just isn’t possible on many shared hosting solutions.
Another possibility is to rely on third-party cloud services like DeployBot, Springloops, or Beanstalk. None of these choices are bad, but there are potential downsides:
- There are monthly or annual costs to these services, whether you are actively using them at the moment or not.
- Setting up external Git repositories may take some time and can be complicated.
- There is also the increased risk of relying on a third party service. The deployment service can be down at the moment you want to deploy.
- The speed of the deployment is dependent on that service. There may be a long queue of other deployments before yours.
A Look at GitFTP-Deploy
Let’s take a look at my alternative: GitFTP-Deploy. GitFTP-Deploy is a native macOS app that only uploads the changed files (through SFTP, FTP or FTPS) since the last deployment. You don’t have to remember which files you have changed, added, or deleted.
Since GitFTP-Deploy reads what have changed from your local Git repository, you also get in the habit of using a Git for your project: once a file is committed, it’s also ready for deployment.
Another feature which could ease up your deployment is GitFTP-Deploy’s ability to run pre- and post-deployment scripts. Are you using a JavaScript compiler (like Babel) or CSS preprocessor (like Stylus)? Are you concatenating and compressing assets? Running these tasks can be make automatic by the app.
Other times it can be a real time saver just to commit the last changes, and it’s automatically pushed onto the server, just with a single Git commit command.
Getting started
In less than two minutes you can start to deploy your files.
1) Create a new site

2) Point to your local repository and select which commit you want to start deploying from

3) Setup your server connection

4) Click Deploy

Maybe your workflow is a bit more complicated? You need more power?
You can specify scripts to be run both locally and on your server, before and after uploads. For example, before uploading, you may want to run your favorite JavaScript compiler or a Gulp script that concatenates and optimizes your JavaScript files for production.
Or perhaps you are using a workflow with another task runner like Grunt? Grunt can also be configured to help you with optimizing images, compressing scripts, compiling preprocessors, and countless other things.

gulp --production
The ability to run tasks can be quite powerful. For example, even WordPress has WP-CLI, meaning you could script out things like database syncing and settings updates with your deployment.
Other Notes on Usage
If you prefer not to have build files under version control, you can add this folder to “always upload”.

Using GitFTP–Deploy does not mean that you cannot use GitHub or another third-party hosted Git repository service. Just make sure to pull the changes from there before deploying.

Team Usage
While GitFTP–Deploy is not exactly built for teams, you can still use it. The easiest way it that one person handles the deployments. Another more advanced option is to run GitFTP-Deploy on a server.
This way may not work for large teams, and commits are done through many different individuals. However, GitFTP-Deploy will attempt to check which branch and commit that which was last deployed.
This looks pretty cool and better than cloud solutions (I agree with all your cons obviously)
Is it going to be a Mac only thing or do you have plans for a PC version?
Thank you
Hi Nour! Thanks for your comment! Sorry there is no plans for a Windows version.
I was so close to buying this, but then I saw that it doesn’t support submodules, which is crucial for our projects. We currently use DeployHQ which is nice because it’s centralized, but I love GitFTP-Deploy’s ability to upload a compiled asset directory so you can keep it out of source control.
Hi, Dalton! Sorry to hear, I have looked into implementing sub-modules, but I had almost not request from my users. If I get more requests I will certainly look into it.
This looks like a very useful application and the price is fairly accessible as well. There are many apps with monthly subscriptions that cost more.
Is there a Windows version for those of us who don’t use Macs? Any plans to create something like that? Or can you point any alternatives that would do a similar service?
Hi Adrian! Sorry there are no plans for a Windows version. / Jan
Maybe I missed it, but can you keep source file directories out of the uploads? I see that you can specify build files, but I didn’t see how to ignore source files when uploading the repo.
Hi Gurnzbot! Files specified in your .gitignore will not be uploaded unless you add them. You mean you want to diable uploading of certain files that are committed into the repo?
Yes, the latter.
If I have a ‘src’ path that contains all of my source files (un-minified js, sass, etc) and ‘dist’ path the contains all compressed and built files, is there a way to notify GitFTP-Deploy to not upload the src directory?
I would want that in my repo since it contains all of my actual source code.
On the other hand, I would probably have the ‘build’ directory in my .gitignore file. However, I would want that uploaded to the server since it contains the files that my application will be using.
Perhaps I’m misunderstanding how things work! :)
Check for updates. I have just released 2.1.0 where you can ignore files. :-)
Great article, it’s also worth noting, you can set up something similar via BitBucket using their relatively new “Pipelines” feature, all within the FREE plan!
I have set it up on a personal project, but haven’t fully looked into any cost based restrictions, haven’t noticed anything yet though!
Hi, Laurence! Thanks for your comment! You are right you can do this with other services.
I don’t think BitBucket Pipeline has the same target group as GitFTP-Deploy. I see BitBucket Pipeline more as continuous integration-platform and Pipelines does not do simple FTP for example. Also, setting up Pipelines is more complex, and you have to like YAML. You also have to store your repo on BitBucket (for obvious reasons).
You will rely on an external server for pushing. And there are rate limits for pushing (but you are unlikely to hit these for smaller projects).
(BitBucket has also hinted that Pipelines will be a paid feature in the future, even if it’s free now).
Regards,
/ Jan
Would “auto-deploy on push” be possible as an option in the future?
I don’t think I want do deploy on every commit.
Actually, that’s not a bad idea…
+1 for this
There is a beta available with this feature now. Let me know if you want to try it out (https://eastwest.se/support). It will be released in the next upcoming week hopefully.