git

This is definitely not best practice, but on some servers I have some server configuration in Git and I deploy and update them manually. Git is used only as versioning system for configuration and not automatic provisioning.

In theory things should be pretty straight forward, but there are two main issue with this approach, both caused by the fact that you have to use git  after you switch to root account (sudo su). 

1. you loose you ssh key chain and you can not pull/push changes
2. if you commit changes, your Git name and email are empty and using git config it's not OK since multiple users might do the same thing

It's possible to fix this using sudo by using something like this:

sudo -Es GIT_AUTHOR_NAME=Your\ Name GIT_COMMITTER_NAME=Your\ Name GIT_COMMITTER_EMAIL=your.email@example.com GIT_AUTHOR_EMAIL=your.email@example.com su

I added an alias for this and whenever you use the alias, you will forward your ssh key chain and set Git username and password by setting temporary environment variables. It's multi user friendly, so multiple admins can use this to do changes as root and commits author name and ssh keys will be set for each individual.

My experience about adding git to a project that had no versioning control system before. The project had two running versions that ended up as branches so changes from one can be merged in the other and a production server where git was added without downtime and now it's used for deployments.

The project I'm working on has inconsistency issues when it comes to coding style. Even though it's a Drupal project, it doesn't follow Drupal's coding standards and on top of that the .php files are saved using various character encoding and line endings. This forced me to develop a workflow that I use before changing legacy files which helped me to keep changes history readable.

Committing together a file encoding change, white-space conversion and a bug-fix will be a source of regret if you ever have to look at that diff again. Most likely you will pull your hair out trying to figure out what is a code change and what's only a code style fix. That's why I separate the coding standard fixes in a single commit before doing anything else. This commits will be easy to ignore when checking history and can provide a cleaner diff for the changes that follow.

The steps I follow are: