Flusso di lavoro del server di produzione / staging Git


108

Attualmente il mio sito web (server di produzione) contiene già molto codice. E ora voglio iniziare a utilizzare Git per i miei progetti e configurare un server di staging per il mio team. Qualcuno può darmi qualche consiglio?

Ecco l'immagine nella mia mente:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

La mia domanda è: come dovrei iniziare?

Ecco alcuni passaggi nella mia mente:

  1. fare un git initserver in produzione (è sicuro?)
  2. clone il repo dalla produzione al server di staging
  3. sviluppatori cloneil repo dallo staging alla loro macchina locale
  4. push file sul server di gestione temporanea al termine della modifica
  5. quando l'allestimento è pronto, pushtutto alla produzione

Questo flusso di lavoro ha senso o esiste un modo migliore per farlo?

E se volessi modificare solo un file?

Origin / master ha qualcosa a che fare con questo in questo processo? Chi è l'origine? finirò per avere origini multiple ??

Inoltre, quando dovrebbe utilizzare uno sviluppatore branchin questo caso?

Risposte:


59

È preferibile utilizzare il ramo principale solo per il ramo di produzione e sviluppo per la gestione temporanea. Ogni sviluppatore dovrebbe creare un ramo locale per aggiungere nuove funzionalità e quindi fondersi con il ramo di sviluppo. Se sei nuovo in un git, prova a usare - http://github.com/nvie/gitflow C'è anche una buona immagine che descrive il modello di ramificazione git - http://nvie.com/posts/a-successful-git- ramificazione-model /


Questa è una risposta migliore. Non avevo molta familiarità con il concetto di ramificazione Git.
kayue

@bUg. Hai un collegamento a qualche risorsa che spiega il ramo di sviluppo -> invia al sistema di staging e al ramo principale -> invia al server di produzione in modo più dettagliato? Il superbo articolo Un modello di branching Git di successo non menziona quella parte anche se menziona concetti molto buoni di branching e versioning.
Edgar Alloro

19

Il tuo suggerimento sembra corretto, ma non permetterei agli sviluppatori di eseguire il push direttamente sul server di staging. Invece, un integratore dovrebbe esaminare attentamente i rami e incorporarli nel ramo principale (o ramo di sviluppo se si utilizza il modello di flusso git come suggerito da bUg.) * La stessa persona invierebbe il push al server di staging.

* Integratore : " Una persona abbastanza centrale che agisce come integratore in un progetto di gruppo riceve le modifiche apportate da altri, le rivede e le integra e pubblica il risultato affinché altri possano utilizzarlo ... "


1. esegui un git init nel server di produzione (è sicuro?)

Sì, è sicuro, ma ovviamente devi impostare autorizzazioni molto restrittive su questo repository. Probabilmente inizierei curlinserendo l'intero sito web su un disco locale, se non lo ho già.

2. clonare il repository dalla produzione al server di staging

Probabilmente dovresti avere un repository "centrale" separato sia dalla produzione che dal server di staging. Quello può essere clonato e spinto secondo necessità.

3. Gli sviluppatori clonano il repository dallo staging alla loro macchina locale

4. inviare i file al server di gestione temporanea al termine della modifica

5. quando l'allestimento è pronto, spingere tutto alla produzione

Sostituisci "staging" con "central" e penso che tu stia bene, ma un problema più grande è come lavorerai con branch e merging, come sottolinea bUg.


10
1: Per rendere sicuro il repository Git in produzione, assicurati di aggiungere un file .htaccess con "Deny All" all'interno.
kayue

2
2: Il repo "Central" di Felixyz si riferisce al repo nudo. Usa il comando --bare per creare un semplice repository.
kayue

1
@keyue 1: Ancora meglio, aggiungere RedirectMatch 404 /\.gitalla vostra produzione .htaccess per proteggere i .gitignore , .gitattributes e .git cartella.
Leone
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.