Git and Templates saved as file

Question

I am playing around with Git together with an EE install and I think that I have almost nailed it (aka found my workflow).

There is just one small unclarity remaining with Templates being saved as files:

I have a local clone of my install and a central Bitbucket repo. Yesterday I made some changes in my local repo and pushed them to Bitbucket which in turn triggered a post-update hook that updates the files in Production. All fine until here.

But now when I sshed into production and ran "git status" git told me that the two files I have just pushed are modified. I was puzzled at first but then realized that I was connected to the (live) remote DB when editing the template files locally.

So, am I assuming right that this is something I shouldn't do with Git (being connected to remote DB) because a change and save to a file locally will in turn also update a.) the db in Production and b.) the file in Production?

Thanks and Cheers!

EDIT/UPDATE: I now did another run with a fresh copy of the db running locally. I am using FTPloy together with Bitbucket so that whenever I push something to BB the changes are being deployed to my Production file system.

So: changed two files locally, pushed them to BB and the Production site got updated with FTPloy. However, I still get these two files as being modified when I run "git status" on the Production server.

On one site it seems totally logical to me because the two files were modified of course. But then again how I can I prevent this behaviour? When I try to pull from Origin I'll get "error: Your local changes to the following files would be overwritten by merge". When I run discard the changes and then pull from Origin it works.

Now I am thinking that it would best be to not have Git running at all on my Production server but what if I (or somebody) has to make changes to the live site in an emergencylike situation?

Don't know how to better describe this. I hope someone will understand my problem.

Answer 1

I normally use a shared database between development and staging servers and a separate database for the live one. This prevents issues like this from happening and makes sure that your changes only go live when you intend them to.

Of course, this also introduces the age-old database sync issue, forcing you to manually replicate database changes across environments for things like channel and field structure changes and content update.

Answer 2

Coming back to this months later (trying to be a good SE user and marking threads as answered):

The question was from my early days of trying to get a grip with Git. The behaviour I experienced as being arkward turned out to be perfectly correct and Git just did what Git does. Changes in the filesystem will be changes in the filesystem and must be watched by Git.

So, I just didn't understand that and tried to combine Git with updating files via FTP, whereas I had to decide: either update files one way with FTP (dev > prod) or pull changes into production from the central repo.

I settled with the FTP deployment method which brings the restriction that no changes should ever be made on the production server - which isn't a good idea anyways, so everything's fine.