Flusso di lavoro GIT per singolo sviluppatore (passaggio da semplice FTP)

Naviga le tue risposte
10

Sto cercando di decidere se passare a VCS è sensato 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 (accesso da casa).

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

Mi chiedo come sia meglio integrare VCS in questa procedura. Vorrei prevedere la creazione di un server Git sul server Web dell'azienda, ma non sono chiaro come spingere i cambiamenti verso gli account dei clienti (di solito VPS sullo stesso server) - al momento mi collego semplicemente a SFTP con i loro dettagli e faccio le modifiche direttamente.

Inoltre, non sono sicuro di ciò che rappresenterebbe sensibilmente un repository: il sito Web di ciascun cliente otterrebbe il proprio?

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

EDIT: l'ho ristretto alle due opzioni che sembrano più sensate. Il primo si basa sulla risposta di ZweiBlumen , in cui le modifiche vengono effettuate sul server live e vengono trasferite da lì al ) Server Git. Questo ha il vantaggio che il mio flusso di lavoro non cambierà molto (c'è il passo in più per fare il commit, ma per il resto è identico).

La seconda opzione è di lavorare localmente usando XAMPP, quindi di eseguire il commit delle modifiche dal computer locale. Solo quando il sito è attivo, carico l'articolo finito sul server web dalla macchina locale (immediatamente dopo l'ultimo commit su Git). Questo in teoria sembra accettabile, ma se il sito successivamente richiede modifiche e li faccio sul server live (come faccio di solito), allora dovrò copiare manualmente i file modificati nel mio repository locale, quindi trasferire tali modifiche al 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 vedere come vado.

    
posta melat0nin 27.03.2012 - 11:31
fonte

3 risposte

3

Quello che faccio (con Subversion, ma funzionerà anche con Git) è il commit di tutto in un repository di Subversion, ma ovviamente diviso in progetti, rami, tag come necessario. Quindi eseguo il checkout di questi repository sul server live. Pertanto, quando apporto una modifica alla mia macchina di sviluppo e l'invio al repository, spesso si tratta semplicemente di aggiornare la copia ritirata sul server live per rendere attive le modifiche. Il vantaggio aggiuntivo è che se devo fare una correzione rapida sul server live, lo impongo al repository dal server e aggiorno la copia di lavoro sulla mia macchina dev.

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

    
risposta data 27.03.2012 - 12:00
fonte
2

È piuttosto facile creare un post-update hook , che si aggiorna automaticamente (l'esportazione con git archive è preferita per motivi di sicurezza) la directory dei dati del server web quando si preme su un ramo specifico.

Quindi creare un repository git da qualche parte (per ragioni di sicurezza l'avrei messo su un server diverso dal web) con tale hook. Ovviamente è necessario un server di prova per testare modifiche più grandi, che possono essere sul proprio computer locale o essere aggiornate passando a un altro ramo. In entrambi i casi è possibile aggirarlo per l'ortografia banale e le correzioni dei CSS semplicemente facendo commit e push.

    
risposta data 27.03.2012 - 14:01
fonte
1

Seguirò questi passaggi:

  1. Imposta il server remoto con una coppia di chiavi pubblica / privata appropriata per push / pull remoto
  2. Configura due rami test e rilascia
  3. Sviluppo locale con un ambiente di test nel ramo di test
  4. Quando sei felice, unisci con il ramo di rilascio e invia al server remoto
  5. Collegati al server remoto per aggiornare all'ultima versione di rilascio

Crea un repository per sito web, per evitare che si ingombrino a vicenda. I rami separati consentono di evitare che l'attuale blocco "buono" della versione venga applicato a ciò a cui si sta lavorando, il che può o meno funzionare.

    
risposta data 27.03.2012 - 16:24
fonte

Leggi altre domande sui tag

Best practice con codice sorgente ramificato e ciclo di vita dell'applicazione Tabelle di ricerca: sono una perdita nel modello di dominio?