Copias de seguridad de servidor web

#1 desde el servidor web puedes hacer pushes a un remoto. Git es distribuído, por lo que es tan servidor el repositorio de tu casa como el de GitHub. Ni siquiera el de GitHub es un servidor central/autoritativo/maestro. Todos los repositorios para un proyecto son "hermanos" (aunque vivan en lineas temporales paralelas.)

Por lo que he entendido que quieres hacer, podrías también tener un remoto en tu propio servidor web, así desde web puedes hacer los commits sobre el servidor y luego pushearlo al remoto que te venga bien. De hecho uno de los servidores cloud que he usado, para hacer los deploys, no es más que un remoto Git cuyo "master" es producción.

Lo de que tu herramienta haga los commits automáticos es MALO. Ni lo pienses (no tengo tiempo para explicar por qué, pero piensa que la herramienta es "tonta" y grabaría cualquier pequeño cambio por lo que acabarías inundado de commits.) Aparte de que los commits deben ser auto-contenidos, es decir, si planto un commit debe llevar todos los cambios necesarios para X, no hacer 10 commits que juntos hagan X (por comodidad, si la has cagado, ¡sólo tienes que deshacer un commit! Menos problemático y más fácil de seguir la historia temporal de tu proyecto.)

No entiendo muy bien qué quieres hacer de todas formas, ¿puedes expresarlo como un diagrama de flujo/pasos-1-2-3 o algo así? Lo de que Git sea distribuído da mucha libertad, así que a lo mejor si lo explicas un poco más detallado podemos dar con un workflow que se ajuste a tu forma de trabajar. Creo que estás intentando hacer un workflow inverso, lo mejor sería que tu remoto en el servidor web sea el que hace coincider master con producción.

Y sobre todo, ¿por qué desarrollar en el server?

#3 es basura xD Supongo que no pasa nada por que tu web se caiga, pero imagínate eso en un entorno real. La cagas y a la mierda todos los usuarios que tengas en ese momento en la web (¡si tienes suerte y no lías una más gorda aún!)

En efecto, yo lo que haría sería montarme dos remotos (tres si quieres publicar en GitHub también.) Remoto "casa" y remoto "server". Tus commits los haces en "casa", sin plugin FTP ni leches y probando con XAMPP. Cuando lo tengas todo OK en local, push al servidor y listo, tu entorno en producción a la última con un sólo click.

Para esto es importante que tengas dos branches, "devel" y "master" (por ejemplo.) En "devel" pueden ir commits a medias, funcionalidad sin probar, etc. mientras que en "master" sólo debe haber código estable, así puedes hacer un push en cualquier momento a "server" sin miedo a meter código de "devel" ya que sólo entraría "master" y sin embargo si en algún momento necesitas hacer un hotfix o algo así, cambias lo que sea en "master" y tu rama de desarrollo queda sin tocar. Cuando "devel" se convierta en estable, mergeas con "master" y listo.

Lo malo de esto es que no sé si 1and1 (o lo que sea) te dejará meter tu propio servidor Git y enlazarlo con producción. Sé que hay formas de hacerlo a través de HTTP entre otros protocolos, pero todo depende de tu hosting. A muy malas puedes quedarte con sólo el remoto "casa" y hacerte un script que suba por FTP todo lo que hay en "master" de "casa" con un click.

#5 para servir! He hecho algún edit al comentario, no sé si lo habrás leído todo o sólo lo anterior.

#7 para profundizar, te propongo este branching model (a mí es el que más sencillo/útil me parece):

1. Por cada feature/experimento/whatever creas un branch desde "devel" (este branch no tienes ni por qué subirlo a GitHub, te lo puedes dejar en local para trabajar tú sólo.) En esta rama es donde harás tus commits para esa feature en concreto.
2. En "devel" cero commits (o commits MUY cortos para los que no merezca la pena crear un branch propio) y todo el trabajo se hace sólo con merges de branches hermanas (ojo, como hagas un merge de branches que estén lejanas o tengan varias ramas intermedias la has cagado xD)
3. En "master" cero commits (o commits de hotfixes realmente urgentes) y sólo merges periódicos desde "devel" cuando esté estable.

Con este sistema puedes tener varias features experimentales que dependen de "devel" y trabajar en ellas en paralelo sin molestarse unas a otras. Te aseguro que esto es importantísimo, me ha pasado MIL VECES con SVN de tener que hacer commits guarros con varias features por no haber brancheado (y con SVN no puedes "volver atrás" tan fácil como con Git.) Luego, cuando me he arrepentido de una feature o algo así, resulta dificilísimo deshacer los commits mezclados sin romper TODO.

Como regla de oro, si vas a hacer más de un commit, créate un branch temporal de "devel". Cuando termines lo mergeas (o borras/ignoras la rama si no te ha salido bien el experimento) y fin. Yo no suelo borrar branches porque así puedo volver a verlas aunque la haya cagado.

Quizá es rizar mucho el rizo, sobre todo cuando estás empezando (ahora mismo con una sóla rama irás sobrado para hacerte a ella), pero está bien que conozcas alternativas sobre todo para que vayas cazando PARA QUÉ sirven las ramas. Git mola porque es muy libre en cuanto al flujo de trabajo permitido, SVN se mete mucho entre mí y mi flujo de trabajo (y acabo haciendo GUARRADAS como copiar el proyecto entero a otra carpeta para hacer half-commits.)

Yo soy el primero que se pasa estas cosas por el forro cuando estoy de lone-developer, pero también soy el primero que se acaba arrepintiendo de no hacerse caso a sí mismo xD

a ver a ver a ver...
Yo hago mas o menos como #1, aunque a lo mejor hasta soy mas....manual xD
con el filezilla busco el fichero y lo edito desde ahí, que lo que hace es bajarselo en una carpeta temp y lo abro con el Notepad++.
No tengo ni idea de githubs ni hostias, todo siempre a pelo.

No sé si me entero mucho de lo que decís, alguien se podría currar algo de como programar "bien"...
supongo que es algo que no te enseñan cuando aprendes programacion autodidacta