This is actually not changing the files on production but for using a development server. In my case, we don't have local servers. We have development servers that are identical to production servers.
I manage my changes from my local so I can use any editor I want in the mean time this script uploads all my changes to development server.
This is what vagrant was built for, so that you can run a full development environment locally and then push changes to staging/production server using git (and hooks, if you want to automate the process), when you have something working and want to show it off.
Using this technique you're stuck, because only one person can develop on the same project without interfering with each other. Also, git-hooks are not /that/ hard to use, you should really look into it, as it solves two problems: You have version control and you have easy deployment.
Oh no, you misunderstood. On our project we use git, and git hooks. however we use githooks only for linting and such. We deploy using a different system.
We have development servers for each developer like 'username.dev.myapp.com' so you don't have to install the application on your machine. Most people work on the server using 'ssh: screen/tmux - vi/emacs', but I want to work on my local because it's faster. So I needed a system to upload my changes to my remote box. and commit my changes from local.
Most companies use this technique so that you know how your code will behave on production while developing it, because it has the same exact architecture.
I hope it's more clear now. It's funny that you would think I don't use a version control system :) what year is this.
Comments
This is actually not changing the files on production but for using a development server. In my case, we don't have local servers. We have development servers that are identical to production servers.
I manage my changes from my local so I can use any editor I want in the mean time this script uploads all my changes to development server.
I think this is the general use case.
This is what vagrant was built for, so that you can run a full development environment locally and then push changes to staging/production server using git (and hooks, if you want to automate the process), when you have something working and want to show it off.
Using this technique you're stuck, because only one person can develop on the same project without interfering with each other. Also, git-hooks are not /that/ hard to use, you should really look into it, as it solves two problems: You have version control and you have easy deployment.
Oh no, you misunderstood. On our project we use git, and git hooks. however we use githooks only for linting and such. We deploy using a different system.
We have development servers for each developer like 'username.dev.myapp.com' so you don't have to install the application on your machine. Most people work on the server using 'ssh: screen/tmux - vi/emacs', but I want to work on my local because it's faster. So I needed a system to upload my changes to my remote box. and commit my changes from local.
Most companies use this technique so that you know how your code will behave on production while developing it, because it has the same exact architecture.
I hope it's more clear now. It's funny that you would think I don't use a version control system :) what year is this.