Coda 2 and Git (totally new to Git) - how do I setup live + testing server?

Discussion in 'Web Design and Development' started by RoboCop001, May 25, 2012.

  1. RoboCop001, May 25, 2012
    Last edited: May 25, 2012

    RoboCop001 macrumors 65816

    Oct 4, 2005
    Toronto, Canada
    Hey all,

    I just purchased Coda 2 after giving it a try yesterday and started playing around with it. I also installed Git for version control.

    I've never used Git or anything like it, I've always done version control manually.

    But Git seems like a great solution.

    Now the only thing I miss from Dreamweaver is the ability to define multiple servers so one can have a development server and a live server. I know that Coda provides a live preview, but because almost every page has at least a PHP include command, I'm getting "stream not found" errors. After searching, it seems it's because it's using the file protocol instead of the http protocol since the files aren't on a web server. I don't really want to install a web server onto my Mac because I want to do the testing and dev on the server I'll actually be launching on.

    How can I go about doing this using the Coda 2 + Git combination with a dev server and a live server?
    I've researched about installing Git and how it works. I get the idea of how it works, but all of the resources I've found are a bit confusing and overwhelming. I've installed it and it seems to work fine on my Mac with Coda 2, but I'm not sure how to go about installing it properly on a web server.

    Usually I set up my servers like this: as the live one as the dev server

    As well, I installed GitHub as the Git GUI. Not sure if that matters or is even necessary.

    Thanks for any help in advance! :)
  2. mfuggle macrumors newbie

    Dec 15, 2010
    I am also trying to determine how best to deploy Coda 2 and git to manage a personal and sporting club website using Drupal. Both sites are hosted in a shared server environment so it is not possible to install a version of git on the server.

    When I was using the previous version of Coda I changed files on the local copy of the website and then published them to the production website after having tested them in the local environment.

    However this did not provide me with version control of the website code base and I was unable to roll back to a previous version. From my research to date (and their is precious little about Coda 2 and git since it is so new) it is possible to run a local git server (under the local website root) and this will enable version management of the local code base. However what I have not yet worked out is how best to manage pushing stuff to the webserver.

    I suppose what I am saying is that I don't yet understand how Coda 2, git, a local development environment and the remote production environment should be set up into a sound workflow.

    I am very new to git (and version control generally, although I understand the principles), have a slightly better understanding of Coda and a much better understanding of Drupal.

    I would appreciate any help I can get.

    Martin Fuggle
  3. TonyK macrumors 6502a


    May 24, 2009
    For myself I use MAMP Pro. There are other programs that will manage multiple web servers so you might try a Google search.

    My concern with MAMP right now deals with a developer not responding to question in the blog. It has been sometime since an update as well.

    Once you have the software you can configure Coda2 to use the URL from the software so you can live preview PHP or other dynamic generated code.

    Take care,
  4. RoboCop001 thread starter macrumors 65816

    Oct 4, 2005
    Toronto, Canada
    Yeah I'm still trying to figure out what the proper setup should be. There's so much documentation on Git, but it's so confusing because there doesn't seem to be a resource that explains how to set it up in a simple web dev environment. I mean, in my case, it's just me. I freelance. But every time I research Git, it turns out solutions that would just be over kill, and never anything specific to a simpler web development setup.

    I'm still trying to figure out how to install it onto my web server, if that's even necessary.

    Hopefully someone around here can point us in the directions we need to go in.

    Thanks for the reply. I was thinking about MAMP, but I would prefer to test directly on the server I'm going to be deploying on instead of installing a web server onto my Mac.
  5. bpaluzzi macrumors 6502a


    Sep 2, 2010
    If you're new to Git and on a Mac, I'd recommend checking out either the GitHub Mac app (if you just want it to work and be done with) or Source Tree. Both are free, and both work very well. Source Tree has a nice option where you can see the "behind-the-scenes" CLI command being run for each GUI command it executes.
  6. Albright macrumors regular

    Aug 23, 2011
    Ah, starting out with Git. Despite what the cheerleaders may say, Git is an incredibly complex tool and it is by no means easy to learn, even if you're familiar with other systems like SVN or CVS. I highly suggest you invest the time and money in picking up a good book on it like O'Reilly's and working your way through it.

    Much of the benefit of systems like Git is that it aids in having multiple people working on a project at the same time, but even if you're a solo dev, there are features of Git which can be invaluable for working with a sufficiently complex site. For example, if you've noticed a bug in your project which didn't used to be there and you're not sure when or where the bug was introduced, the "bisect" feature of Git is invaluable for helping you wander through time in the repo and find when and where the bug appeared.

    SourceTree, mentioned previously, is an invaluable GUI tool for doing routine tasks; I even bought it back when it was $60 or so instead of free…*But I still suggest learning to use the CLI, because there's some things (like bisecting) which either can't be done in SourceTree or are simply less awkward to do with a CLI. Being able to use Git via a SSH connection is also important. To tell the truth, I haven't played with Coda 2's Git features yet, so I don't know how they stand up to SourceTree's, but frankly I doubt there will be much comparison - SourceTree is such a wonderful tool.

    As a vague overview, your workflow will look something like this. First, you initialize a repository, or repo, inside a directory on your local computer or testing server. You add some files, then create your initial commit. A commit basically saves the state of the file system under your repo directory as of the time that commit is made. You then make some changes to those files - add features, fix bugs, etc - and make a new commit. Ideally, every commit is atomic - that means it only does one task. This way, you can easily revert, or undo, commits later without affecting unrelated things. For example, if you have a commit which fixes bug A and a separate commit which adds feature B, and you later want to revert the commit which fixes bug A, you can do so without undoing adding feature B, but if you fix bug A and add feature B in one commit, you can't undo the bug A fix without also removing feature B.

    Eventually, you'll probably want to create another repository on a hosting service such as GitHub or BitBucket and push, or upload, your repository there. Strictly speaking, this isn't necessary, but these services provide such great features that unless your code absolutely cannot touch a server you don't control for privacy or security reasons or something, I highly suggest you give them a look. GitHub is definitely the leader of the pack popularity-wise, but if I recall correctly BitBucket offers more private repositories under their free plan, so you should give them some consideration as well. This hosted repository is usually called the origin repository, and can be thought of as the central server in more traditional source control systems like CVS or SVN, except that you don't have to push any of your local changes to this server unless and until you want to - it's possible and, in some workflows, encouraged to have entire branches of the code base in your own repo which are never pushed to the origin one.

    Finally, assuming your hosting service is decent enough to allow it, you'll shell into your web hosting account and clone the repo from the origin server onto your hosting account.

    Now back on your local server, you get your code to a place where it's ready to go live, and then you create a tag for that most recent commit. A tag is like a special, human-friendly label for a commit in your repo; something like "BETA-1". You push your code to the origin server. Then you shell back into your hosting account, pull your most recent changes, then check out the repo at the BETA-1 tag. Checking out the repo means changing the state of the files in it to that represented by a certain commit; in this case the one labeled BETA-1.

    So then you go back to your dev server, make more changes and commits until you're ready to make a BETA-2 release. Repeat and repeat as necessary.

    I haven't touched on branches much, but I've got to get back to work (using Git!) right now, so maybe later…*But I hope this helps you get a wide view of how it will work for you. If you have any questions, feel free to ask and I'll try to address them - even though, truth be told, I'm not much of an expert myself.
  7. kurzz macrumors 6502


    May 18, 2007
    I use a setup where I develop sites locally and use git to push to the production server. My stack consists of MAMP, Git, Textmate, and some browsers. Although I don't use Coda, my setup works comfortably with it or any IDE. I use git command lines but you could use any other GUI.

    The magic here really lies with git. Instead of using FTP + version control to publish sites, I use git to do both simultaneously. Basically, I have a local website like wordpress that I develop. The entire site is a local git repository. The live site on the remote server is also a git repo. I can do any number of commits locally but when there's a commit that is ready to go live, I just push to the remote repo.

    With this setup, both your local and live site is version controlled. The icing on the cake is that on the live site, I have a separate branch called "maintenance". I simply checkout out that branch if I want the live site to display a particular version of the site or simply a maintenance page. Then I switch back to the master branch when I'm done. Git allows me to easily work on a make-over or a side project and test it locally while easily switching back to the original with a simple command.

    A lot of cutting edge professionals use this kind of setup for rapid web app development and version control. ::cool:
  8. RoboCop001 thread starter macrumors 65816

    Oct 4, 2005
    Toronto, Canada
    Hahah I totally forgot about this thread back in 2012 (I got side tracked I guess) and now in 2018 here I am trying to figure out Git all over again!

    So 6 years later, I set up a Git repository using BitBucket. Coda 2 is set up and connected to it.

    I have 2 sites set up in Coda. They both use the same local Git repository and connect to the same BitBucket repository, but one site connects to the Production server and the other site connects to the Staging server.

    Coda doesn't seem to be able to sync branches between itself and BitBucket. If I create one on BB, I don't see it in Coda. If I make one in Coda, I don't see it on BB. The only branch that works for push/pull is the master branch.

    So my next question is, do I really need branches? It's just me working on the website. But I'm wondering if there's any use in having a staging branch for the staging server, and the master branch for the production server.

Share This Page