Take the 2-minute tour ×

I'm a single developer that has always just developed over FTP to a development server and then moved the files into production when ready. I've been interested in using git and GitHub for quite a while now, and I've finally got a good excuse now with a new project I'm starting. However, it seems tedious to have to do:

git add file1.php
git add file2.php
git commit -m 'updated file1 & 2'
git push origin master

Then after that is in the repo on GitHub, SSH into my server, go to the correct directory, and do:

git pull

each time I make any change to the code. This is apposed to editing in something like Coda and then just clicking command+S.

Is there a better (maybe more automated) way of doing this? I know there is a GitHub for Mac app which is quite nice and helps with the first part, but I still have to login to SSH to update anything, which can get tedious after a few dozen updates in an afternoon.

I've also seen that I can add a post-hook, so I could call a PHP script to execute the git pull on each commit, but I feel like there could be some security issues with that, and not to mention the issue with that script failing since it can't enter the passphrase.

share|improve this question
Git is an SCM (like cvs, svn, hg, bzr, ...) and not an ftp replacement. If you don't need/want source control on your remote box, don't use it on your remote box, just publish as you used to. –  Mat Jun 28 '11 at 20:10
Right, sorry for not clarifying. I wasn't trying to use it as an FTP replacement. Was merely giving the background of how my workflow has been thus far. –  James Simpson Jun 28 '11 at 20:49
add comment

5 Answers

up vote 7 down vote accepted

I strongly suggest you read the ProGit book http://progit.org/

No, there are much faster ways of doing this.

Once you have the files added, you can simple git commit -a -m "Change descriptions"

In order to add the files, you can git add . which will recursively add all non-ignored files.

If you have a tracking relationship set up with your branches, all you need to say is git push. Only if someone else makes a change do you need to git pull

There are of course many IDEs which will help manage git, and git guis of various breeds. https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools

But really there are only a handful of commands you need to know to do it from the command line.

  • Everyday commands

These commands you will be using every single day

git pull --rebase    # Getting changes other people made.  Using rebase is my personal preference
git commit -a -m msg # Committing your work
git push             # Sharing changes with others
git status           # Finding out what you have not committed/pushed
git diff             # Finding out what changed
  • Occasional commands

These commands you will use only on setup or rarely

git init                 # Set up a new git repo
git clone URL            # Set up a git repo from the master source
git add <file/directory> # Mark a change specifically for commit

I would like to reiterate that git is not a web deployment system. However, if you are trying to do something like that, some people have had success with http://toroid.org/ams/git-website-howto

share|improve this answer
An even shorter command is git commit -am "Change descriptions", but that might be a little overkill in the optimization front. :) –  Shauna Jun 28 '11 at 20:18
One thing I miss when switching from Mercurial to git is that I can no longer do hg com. –  Michael Mior Jun 28 '11 at 20:21
You mean use hg com as an alias for hg commit? You can do that with git. git --global config alias.com commit. –  Seth Robertson Jun 28 '11 at 20:30
add comment

Using git and GitHub seems like a lot of extra work, am I looking at this wrong?

I'll argue "yes, you are looking at this wrong" and I think @Mat's comment has the right idea. Git is a version control system. The fact that you can also use it as a deployment tool can be a nice bonus when it is already a part of your workflow.

I think you should be using git, or some other form of version control, because you are producing code (or any other form of digital work) and to attempt to do so without both a history of your changes and the ability to manage concurrent branches is madness. However if I need to sell you on the value of including version control in your workflow then there's no point in worrying about how well git works as a deployment mechanism.

share|improve this answer
You definitely don't need to sell me on that value, I definitely see that, I'm just having trouble figuring out a workflow that makes sense after being used to the one I've used for so long. –  James Simpson Jun 28 '11 at 22:42
Fair enough. I'd suggest keeping versioning and deployment separate at first; checkin code when you think it makes sense, push it to a server as needed. Build on that as you become more comfortable with git. First you might want to create a 'production' branch which you deploy from so you can see which changes are live. Then you might start tagging revisions when you push. Then you might finally feel like that's extra work and add a hook so that the act of pushing or tagging a branch is your deploy and not just representative of it. –  Jonah Jun 29 '11 at 1:11
You might also look at hosting providers like heroku who have git based deployments as part of their existing workflow to try it out and as an example of what you might want to have on your own hosting environment. –  Jonah Jun 29 '11 at 1:12
add comment

The other answers have covered efficiency with the command line - coming from Coda like yourself, it took a little while to get used to, but once you're fluid with it, you're going to love it (especially when you have to do a reset).

Here's how I rolled out my DVCS deployment recently, after doing (essentially) what you are. The only difference is that I use gitolite instead of GitHub for security reasons.

The central git server has a repository - on the master branch, I'll check in a vanilla install if it is an open source project, or the latest working/stable code that I have. Then, I create a branch for each stage - so in your case, there's a branch for Live/Production and your local dev environment.

I do my work off of the dev branch, making feature branches or hotfixes and merging them back up. Once everything is stable, I'll merge with the prod branch. I then use an SSH-based hook to connect to the remote server and initiate the pull, which is an alternative to your PHP script and is quite a bit more secure.

Even if you didn't have the ability to install git on the server, you can still use the hooks to automate your deployment. I had to test extensively to make sure this was secure, so I suggest you do the same. Also, Apache needs to be setup to redirect any requests to the .git directory so that directory isn't readable.

Either way, git isn't the ideal web deployment system if you're not comfortable writing the hooks to get everything in place. If you have any reservations, continue uploading via FTP. At least you have version control now.

share|improve this answer
add comment

If you have enough control over your server, you can host your own central repository on your server. (If not, you might still be able to do the following.)

From there, you can set up post-receive hooks to do a pull, or secure copy (scp) into your live section/server automatically. Gitolite can help with the security concerns, as can SSH key authentication.

Also, as DyInuge mentioned, you don't have to push after every change. You can do a single push of multiple commits with no problem.

Finally, in addition to Seth's recommendations, I also add Git Immersion to your reading list. It's a step-by-step tutorial aimed at helping you understand how Git works and what you can do in it.

share|improve this answer
add comment

You don't have to git pull everywhere you have a local branch after every single commit, git pull will gladly pull multiple changes. Also you can use git add . or git commit -a to add/commit all changes without going git add file{1,2}.php dir/otherfile.txt or equivalent. Just make sure to use git status before so you don't mistakenly add and commit something you don't want.

The point of using git is to have revision control. It's an extremely robust tool for source code management, but it's not meant to be used just as a file transfer mechanism. If all you want/need is FTP, use (S)FTP.

share|improve this answer
add comment

Your Answer


