I'm sure you could write a script that would do this for you, or a plugin for your editor of choice. Why would you want to, though?
My usual workflow since I've started using git (which, mind you, was only last week) is to make a logical group of changes, then pause for a moment to add changed files, commit with a concise but clear message of what I've changed, then push to a remote branch. E.g.:
$ git add .
$ git commit -m "Added social media icons to global header."
$ git push origin develop
If you automatically commit and push changes on filesave, you lose this coherency granted by commit messages, which to me is a huge part of why git makes sense for my workflow.
Edited to add: Actually, if you use Sublime Text 2 and the Git plugin, you could probably easily hack that to add this feature, with the above as a base.
Well I had usually the habit to edit the files directly on the server but I thought it would be nice to use git in some way to get the project version controlled.
So I thought this would not change anything to my habit but I get some nice features by using git.
I actually think that the common workflow :
local development
committing the changes to the repo
deploying it to a test server
finally putting it on the actual web server
slows down the working speed, because its not really comfortable to handle php and server side stuff such a database etc. which have to be configured manually.
If you realize that you have a bad habit, why are you trying to preserve it? Why try to make git work exactly like live editing, when live editing is what you're trying to avoid?
If you're not afraid to break something, then you may want to utilize Git for deployment.
I'm pretty much doing this for my own site (because I'm not overly concerned if it breaks) but for client sites, I definitely would NOT take this approach.
For client or work-related work, I would do a master branch, develop branch, and then feature branches to do edits and updates with.
Full Disclaimer: I'm a newb with Git (only 3 weeks in) but I feel like I have a pretty good grasp of the basics. Still lots to learn but I'm starting to get it.
@yeeyang - there's no reaosn to avoid deployment with git. The point is, that normal commits shouldn't automatically be pushed to the production environment.
For example, you might have a master branch, a production branch, and a development branch.
When you start working on something, you'd fork from the development branch, and then push back when you're done.
Once you've completed testing and you're sure everything works fine, push the development branch to the master, and from there to the production branch (i.e., the live site).
The way we do it at work is that any database changes get's applied manually. So, if you're needing to change the Users table, you write the SQL for it locally, update the database using the tested SQL and then push the changes.
@chrisburton Git is very complex, but you don't need to learn all of it for basic use. There are also a few GUI's, github makes one, that simplifies it a bit more. I use git all the time and I only know enough to keep me working, but sometimes not out of trouble :P
@traq, no, I completely understand where you're coming from... what I was getting at was more upon not having a develop and production environment and only a production environment for client work which automatically pulls from the master branch. (like the link posted above in my previous post)
I know and am sure that there are other workflows that you an choose from for git deployment.. just ignorant to them but we'll learn!
@yeeyang - I understand, though I don't agree that having "only a production environment" is ever a good idea.
I like the idea of using git for deployment. The distinction I'm making is that I would never work from the "hub" branch (the branch that is auto-deployed from). That's effectively the same as working on the live site.
Work in a "dev" branch, test,test,test, and then push changes to the "hub" branch when you know everything is ready.
@mottie I like the idea that we can have "versioning" and different environments as stated above (development and production). But for a designer, it just seems completely made for developers, which isn't a bad thing.
Are there any decent step by step tutorials (with a GUI)?
Hello guys, is there a possibility to automatically push the changes made in folder to github, without committing it manually ?
Thanks for your help :)
I'm sure you could write a script that would do this for you, or a plugin for your editor of choice. Why would you want to, though?
My usual workflow since I've started using git (which, mind you, was only last week) is to make a logical group of changes, then pause for a moment to add changed files, commit with a concise but clear message of what I've changed, then push to a remote branch. E.g.:
If you automatically commit and push changes on filesave, you lose this coherency granted by commit messages, which to me is a huge part of why git makes sense for my workflow.
This may help you out, depending on your editor of choice: http://stackoverflow.com/questions/4307192/is-it-possible-to-hook-a-git-commit-to-the-save-on-textmate
Edited to add: Actually, if you use Sublime Text 2 and the Git plugin, you could probably easily hack that to add this feature, with the above as a base.
Sounds like a bad idea, to me.
Well I had usually the habit to edit the files directly on the server but I thought it would be nice to use git in some way to get the project version controlled.
So I thought this would not change anything to my habit but I get some nice features by using git.
I actually think that the common workflow :
slows down the working speed, because its not really comfortable to handle php and server side stuff such a database etc. which have to be configured manually.
If you realize that you have a bad habit, why are you trying to preserve it? Why try to make git work exactly like live editing, when live editing is what you're trying to avoid?
@JoshBlackwood has the right idea with commit messages.
If you're not afraid to break something, then you may want to utilize Git for deployment.
I'm pretty much doing this for my own site (because I'm not overly concerned if it breaks) but for client sites, I definitely would NOT take this approach.
Using Git for Deployment
For client or work-related work, I would do a master branch, develop branch, and then feature branches to do edits and updates with.
Full Disclaimer: I'm a newb with Git (only 3 weeks in) but I feel like I have a pretty good grasp of the basics. Still lots to learn but I'm starting to get it.
@yeeyang - there's no reaosn to avoid deployment with git. The point is, that normal commits shouldn't automatically be pushed to the production environment.
For example, you might have a master branch, a production branch, and a development branch.
When you start working on something, you'd fork from the development branch, and then push back when you're done.
Once you've completed testing and you're sure everything works fine, push the development branch to the master, and from there to the production branch (i.e., the live site).
Damn. Git sounds so much more complicated than I initially thought after reading this.
@traq Sounds logic, but how to work with databases in all this stuff?
The way we do it at work is that any database changes get's applied manually. So, if you're needing to change the Users table, you write the SQL for it locally, update the database using the tested SQL and then push the changes.
@chrisburton Git is very complex, but you don't need to learn all of it for basic use. There are also a few GUI's, github makes one, that simplifies it a bit more. I use git all the time and I only know enough to keep me working, but sometimes not out of trouble :P
...and, if you forget something, references abound.
@traq, no, I completely understand where you're coming from... what I was getting at was more upon not having a develop and production environment and only a production environment for client work which automatically pulls from the master branch. (like the link posted above in my previous post)
I know and am sure that there are other workflows that you an choose from for git deployment.. just ignorant to them but we'll learn!
@yeeyang - I understand, though I don't agree that having "only a production environment" is ever a good idea.
I like the idea of using git for deployment. The distinction I'm making is that I would never work from the "hub" branch (the branch that is auto-deployed from). That's effectively the same as working on the live site.
Work in a "dev" branch, test,test,test, and then push changes to the "hub" branch when you know everything is ready.
@mottie I like the idea that we can have "versioning" and different environments as stated above (development and production). But for a designer, it just seems completely made for developers, which isn't a bad thing.
Are there any decent step by step tutorials (with a GUI)?
@chrisburton - might check out this article.
@chrisburton If you can, definitely learn how to use Git from the command prompt; it is way more powerful. This is what kicked off my relationship with Git: http://try.github.com/levels/1/challenges/1
And when you feel a bit more confident, give this a shot: http://pcottle.github.com/learnGitBranching/
Also, there is version control for designers too! Have a look at LayerVault: http://try.github.com/levels/1/challenges/1
Or Pixelapse: https://www.pixelapse.com/
@traq @joshuanhibbert Appreciate it, guys. Reading them now.
@chrisburton - I'm a huge fan of Tower: http://www.git-tower.com/
Or check out http://www.sourcetreeapp.com, that's pretty much the same for free
Thanks guys. Sorry to hijack the thread.