如何在不引入大量开销的情况下将git添加到我的工作流程中？

Question

Currently my web development workflow for live sites is pretty broken and I am looking to improve the process. I have no version control and am more often than not doing direct edits over FTP to the live site. Because of that, this is a new workflow I am thinking of implementing and would love your feedback. Along the same lines, feel free to let me know "that workflow is stupid... you should do X instead".

Goals/hopes/dreams:

• No requirement for local box to have a full dev environment (WAMP, etc)
• Uses Git
• Minimal overhead (I'm a one man shop and don't want to have a million branches to deal with, etc)

Proposed Workflow:

• Two sites:
  • site.com - My live site lives here
  • beta.site.com - Copy of my site lives here
• All work is done remotely over FTP on the beta.site.com site. This allows me to use my web server as my "dev box"
• Once the change/feature I am working on is complete, I perform a commit to my only branch ("live")
• The live branch has a post-hook that copies the changes over to the live site at site.com
• If I run into any issues I can simply rollback the live branch which will in turn re-deploy the last working version of the site

I know this isn't the most ideal workflow as I technically don't have a true staging environment, etc but seeing as I am just a one person dev team I feel like this may be sufficient. Also, since I'm coming from live FTP edits to the site, I know that if I introduce too much overhead I'll end up just editing the site again after a short period and I want to make sure I stick with this new method.

Anywho, anyone have any thoughts or suggestions on this approach? Would love to hear the feedback of the more seasoned devs here.

Answer 1

Above everything else, I'd like to stress one thing. If you take nothing else from this answer, please think about this. Regardless of your workflow, you should always use some form of version control. Using version control has many benefits, not the least of which is providing you some piece of mind that your code is safe, but it will also allow you to develop code faster. I don't have the book in front of me, so I can't provide an exact reference, but Steve McConnell's book "Rapid Development: Taming Wild Software Schedules" hits on the topic again and again if you need some convincing that version control will actually save you time instead of "introducing extensive overhead."

Why did I start out an answer to a question about a workflow like this? Regardless of what else you change in your workflow, you can begin integrating git immeadiatly with very little overhead. Adding git to your site is as simple as navigating to your working directory and typing git init . That's it, you now have a git repository that you can check code into.

I won't pretend that there isn't a little bit of a learning curve to git. One of the programs biggest drawbacks in my opinion is that it isn't very user-friendly to those unfamiliar with it. Don't let that daunt you though, once you sort of grok git, all of the commands make sense and actually accomplishing stuff will be pretty straight forward. For help with finding that "AH-HA!" moment, please see think-like-a-git or the excellent git internals book.

Now on to the good part, Improving your workflow. Generally, I like the workflow you've suggested, and I bet it will be a big improvement over what you are doing now. I don't think you should do anything radically different from what you suggested. Instead, lets turn it up to 11 !

Here are my suggestions:

• Don't worry too much about only having one branch in git. Branches are super easy to create and manage in git, much much easier than they are in something like subversion. I'd recommend you use something like the git-flow strategy , with your master branch representing the code that gets pushed over to your live and beta servers.
• If you can ssh into your server and install git on it, you can actually use git to replace the ftp part of your workflow. By "pulling" from your development machine to your live server, you could more precisely control what code is deployed there, and rolling back errors would be as easy as doing new git checkout .
• I'd recommend using some sort of external service to backup your git repository. This provides a layer of security in case of a disaster. This is a bit grim, but remember that if your house burns down, backups to an external hard drive won't save you. Bitbucket.org provides free private git repository hosting for small groups of people, which would be ideal for your situation. If nothing else, you could use a service like Dropbox or SpiderOak to backup your working directory.

As a final note, I'd recommend that you checkout Atlassian's Source Tree git software. In my opinion, this is the best windows git client out there. It even provides tools for doing git-flow!