Developing using Coda 2 & Git – Part 2.5: Background Info & Coda Issues

In Part 2 of my posts on using Coda 2 and git, I promised more info on how to get them working well together. I’ve spent the past few months working on my site and trying to get them working, but, to be honest, I haven’t had much success.

The problem isn’t any config issue, it’s just that Coda 2 only will integrate with locally hosted git repositories. So if you develop your site by running a webserver on your local machine, you’re fine. I don’t know how common this is; it’s certainly something I could do technically but it brings its own technical hurdles: Do you also host your database locally as well? Does everything work the same when you put it back up remotely? I’m not really satisfied with local-hosting my dev work because I don’t have good answers to those questions.

What Coda 2’s git tools really needs in order to be useful to me is support remote git repositories.

One workaround I’ve used is to work on my site within a git repo locally and then frequently upload the content to the remote dev server (which is not tracked by a git repo). The problem with this is you’re constantly saving and then taking another action to push out your changes and see what they look like. Frankly, it’s a pain. It would be much easier if you could tell Coda 2 to just upload your file as soon as it’s saved locally, and indeed this feature is on a Panic Survey for possible future Coda development.

In the meantime, I’ve been learning to manipulate git repositories remotely via the command line (again Pro Git is a good resource here). It’s not as simple as it could/should be but it’s worked decently well. I’ve also got a lot of help from the Gitbox app which makes Git much simpler and easier to understand without sacrificing much power. SourceTree is a free alternative that’s more complex but has a lot more options and tools. However, for beginners and ease of use I think GitBox is worth the money because it will save you valuable time figuring things out.

Anyway, stay tuned for Part 3 eventually.  I’ll discuss Coda 2’s git more and hopefully present a better solution than just using the command line.

Author: Nick Vance

Founder/Creator of

5 thoughts on “Developing using Coda 2 & Git – Part 2.5: Background Info & Coda Issues”

  1. Working on the same issue. I’m at the point where I have my local folder with the .git and I’ve set up my repo on github. I set up the origin url to be my github url. I saved the site config, and was able to clone the repo to my local machine.

    I’m able to make a changes to my file, and I then see the file show as modified in the SCM window. Getting the push/pull to work is my current issue. Coda is saying things like “device not configured” and “no password” but I haven’t found where to set up this stuff just yet.

    Point being that these initial steps were fairly straightforward, but clearly there are some settings that need to be configured that I haven’t learned about/found yet.

    Keeps the updates coming!

  2. About hosting locally: I highly recommend it. Assuming the servers you eventually upload to are Linux/Apache/MySQL/PHP, then you can completely mirror that environment locally on a Mac. Apart from MySQL, it’s all installed for you already, in fact. Install phpmyadmin, and you even have an easy way to administer MySQL. I can set up a new local site by creating a directory, creating a database, and then editing the hosts file and the vhosts config, all in just a couple of minutes.

    It’s especially useful when you are working on a site that is already live, and that must stay up and running. Just copy the whole site and its database down to your local machine, and you have a safe place to experiment.

    I really have no problems with things not working the same locally and on the remote server unless the versions of Apache, PHP or MySQL are wildly different on the local and remote systems.

    1. Thanks for your comment Kevin.

      I’ve looked at locally hosted dev servers and they don’t quite seem to be the best solution for my work. This is primarily because I do dev work from several different locations (home, work, mobile) so having one dev server is more consistant. Plus it makes using Diet Coda easier, since the remote server that will always be available.

      While doing development, I’ve been learning to use Git via the command line and it’s been working pretty well for me. Figuring out the command for how to do something is usually just a quick web search away.

      All that said, a locally hosted dev server is a better fit for many people, especially those with less comfort with the Command Line. So it’s worth considering both options, especially when starting a new project (not that it would be difficult to convert an existing one).


  3. Yep, it comes with a completely new and ulnuabse GUI. Seriously, why dis Panic mess with a good thing? Should have left the GUI untouched and added the new features.

Leave a Reply

Your email address will not be published. Required fields are marked *