Flusso di lavoro GIT per sviluppatori singoli (passaggio da FTP semplice)

Sto cercando di decidere se il passaggio a VCS è ragionevole per me. Sono un singolo sviluppatore web in una piccola organizzazione (5 persone). Sto pensando a VCS (Git) per questi motivi: controllo della versione, backup offsite, repository di codice centralizzato (può accedere da casa).

Al momento lavoro su un server live in generale. Ho FTP in, faccio le mie modifiche e le salvo, quindi ricaricare e aggiornare. Le modifiche sono in genere su file di temi / plugin per CMS (ad esempio concrete5 o Wordpress). Funziona bene ma non fornisce alcun backup e nessun controllo di versione.

Mi chiedo come integrare al meglio VCS in questa procedura. Immaginerei di configurare un server Git sul server Web dell'azienda, ma non sono chiaro come inviare le modifiche agli account dei client (di solito VPS sullo stesso server) - al momento accedo semplicemente a SFTP con i loro dettagli e realizzo le modifiche direttamente.

Inoltre, non sono sicuro di cosa rappresenterebbe sensibilmente un repository: il sito Web di ogni cliente ne otterrebbe uno proprio?

Qualsiasi approfondimento o esperienza sarebbe davvero utile. Non credo di aver bisogno della piena potenza di Git in alcun modo, ma il controllo di versione di base e l'accesso al cloud di fatto sarebbero davvero utili.

EDIT: l' ho ridotto alle due opzioni che sembrano più sensate. Il primo si basa sulla risposta di ZweiBlumen , in base alla quale le modifiche vengono apportate sul server live e trasferite da lì al server Git (esterno). Questo ha il vantaggio che il mio flusso di lavoro non cambierà molto (c'è un passaggio in più per effettuare i commit, ma per il resto è identico).

La seconda opzione è lavorare localmente usando XAMPP, quindi eseguire il commit delle modifiche dal computer locale. Solo quando il sito viene pubblicato, carico l'articolo finito sul server Web dal computer locale (immediatamente dopo il commit finale su Git). In teoria questo sembra a posto, ma se in seguito il sito richiede modifiche e le faccio sul server live (come faccio di solito), allora dovrò copiare manualmente i file modificati nel mio repository locale, quindi eseguire il commit di tali modifiche nel Server Git. Questo sembra eccessivamente complesso ed è forse troppo lontano dal mio attuale flusso di lavoro.

Penso che a conti fatti darò l'opzione n. 1 e vedrò come andrò avanti.

Quello che faccio (con Subversion, ma funzionerà anche con Git) è il commit di tutto in un repository Subversion, ma ovviamente diviso in progetti, rami, tag se necessario. Quindi controllo questi repository sul server live. Pertanto, quando apporto una modifica alla mia macchina di sviluppo e la commetto nel repository, spesso è semplicemente un caso di aggiornamento della copia estratta sul server live per rendere attive le modifiche. Il vantaggio aggiuntivo è che se devo apportare una correzione rapida sul server live, lo commetto nel repository dal server e aggiorno la copia funzionante sul mio computer di sviluppo.

Sono sicuro che ci sono altri modi per gestirlo, ma lo trovo abbastanza semplice e mi trovo esattamente nella stessa situazione di te: singolo sviluppatore in una piccola organizzazione (4 persone).

È piuttosto semplice creare un post-updatehook , che aggiorna automaticamente ( git archivesi preferisce esportare con per motivi di sicurezza) la directory dei dati del web server quando si passa a un ramo specifico.

Quindi avere un repository git impostato da qualche parte (per motivi di sicurezza lo metterei su un server diverso rispetto al web) con tale hook. Avrai ovviamente bisogno di un server di prova per testare modifiche più grandi, che possono essere sul tuo computer locale o aggiornate spingendo verso un ramo diverso. In entrambi i casi, puoi ignorarlo per errori di ortografia e correzioni CSS semplicemente eseguendo il commit e il push.

Seguirei questi passaggi:

1. Configurare il server remoto con una coppia di chiavi pubblica / privata appropriata per push / pull remoti
2. Impostare due rami test e rilascio
3. Sviluppa localmente con un ambiente di test nel ramo di testing
4. Quando sei soddisfatto, unisciti al ramo di rilascio e spingi sul server remoto
5. Agganciare il server remoto per aggiornare all'ultima versione di rilascio

Imposta un repository per sito Web, per evitare che si confondano a vicenda. I rami separati ti consentono di evitare che l'attuale blocco della "buona" versione passi a ciò su cui stai attualmente lavorando, che potrebbe funzionare o meno.