Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers

I apologize if this is obvious or easy, I have looked at a good number of git/github tutorials and read other articles, but I want to make sure what I'm doing is right.

I want to incorporate VC (for obvious reasons) into my development team and process.

Current development process (using Dreamweaver):
* Receive a ticket (or work order)
* Download file on Development server
* Make changes to the file
* Upload file back to development server
* Changes tested/verified
* Send to production server

I'm trying to figure out how to make our new development process with using Git.

I am switching over to PHPStorm (which is an actual PHP IDE with direct integration with Git).

Would it be something like

• Receive a ticket (or work order)
• Checkout/Update/Download file(s)
• Change Files
• Upload file (which I assume is also the current working directory...?)
• At the end of the day, do a commit
• Have build script send data to testing server (nightly build)

Or would it be better to do something like

• Receive a ticket (or work order)
• Checkout/Update/Download file(s)
• Change Files
• Upload file/commit
• Have build script send data to testing server (nightly build)

Or is there another way? Having a bit of trouble understanding what would be the optimal flow?

Any help would be greatly appreciated.

Edit

I'm trying see if it is best to have a version of the server locally (every developer), and if so, how does that work if you have 7 or so branches?

If not, how do you deal with 7 or so branches with them on the web? Do you FTP files up or use Git Hooks to make them auto update?

Update 07/26/2012

After working successfully with Git for quite a while now I've been following this branching model with great success: A Successful Git Branching Model

The answer to the above was yes -- should definitely have a local version of the server.

Assuming you have a live server and a development server I would do something along these lines.

Before even starting with a development cycle I would at least have two branches:

1. Master - the development server runs on this branch
2. Stable - the live server runs on this branch.

So if a developer gets a ticket or a work order he/she will perform the following actions:

1. git pull origin master
2. git branch featureBranch (named as the ticket id or as a good description for the work order)
3. git checkout featureBranch
4. Make changes which will accomplish the desired change. Commit as often as is necessary. Do this because you will create valuable history. For instance you can try an approach to a problem and if it doesn't work, abandon it. If a day later you see the light and want to re-apply the solution, it is in your history!
5. When the feature is fully developed and tested locally, checkout master.
6. git merge featureBranch
7. git push origin master
8. Test the pushed changes on your development server. This is the moment to run every test you can think of.
9. If all is working out, merge the feature or fix into the stable branch. Now the change is live for your customers.

Getting the code on the server

The updating of servers shouldn't be a problem. Basically I would set them up as users just like you're developers are. At my company we've setup the servers as read-only users. Basically that means the servers can never push anything but can always pull. Setting this up isn't trivial though, so you could just as well build a simple webinterface which simply only allows a git pull. If you can keep your developers from doing stuff on live implementations you're safe :)

[EDIT]

In response to the last questions asked in the comments of this reaction:

I don't know if I understand your question correctly, but basically (simplified a bit) this is how I would do this, were I in you shoes.

The testing machine (or the webroot which acts as testing implementation) has it source code based in a git repository with the master branch checked out. While creating this repository you could even remove all other references to all other branches so you'll be sure no can checkout a wrong branch in this repository. So basically the testing machine has a Git repository with only a master branch which is checked out.

For the live servers I would do exactly the same, but this time with the stable branch checked out. Developer should have a local repository cloned in which all branches exist. And a local implementation of the software you guys build. This software gets its source from a the local git repository. In other words: from the currently checked out branch in this repository.

Actual coding

When a new feature is wanted, a local feature branch can be made based on the current master. When the branch is checked out the changes can be made and checked locally by the developer (since the software is now running on the source of the feature branch).

If everything seems to be in order, the changes get merged from feature branch to master and pushed to your "git machine". "your github" so to speak. Testing can now pull the changes in so every test necessary can be done by QA. If they decide everything is ok, the developer can merge the changes from master to stable and push again.

All thats left now is pulling form your live machines.