GIT Workflow dev and production-dove devo creare i repository?

Question

Ho letto da qualche parte* una configurazione come questa sarebbe bella:

Due rami principali, uno per ogni server.

Spingere al master invia le modifiche al live;

Spingendo a dev / stage (o come lo chiami) invia modifiche alla messa in scena;

Flusso:

• Crea ramo da dev;

• lavora localmente fino a quando non sei pronto per il test;

• torna a dev;

• push to Hub, che invia le modifiche al server dev / staging.

Una volta che sei pronto con quelli per andare in diretta:

• unisci da dev a master,

• quindi spingere master a Hub, che invia tali modifiche al server live.

Due rami principali, uno per ogni server.

Quindi ho un ramo "produzione" su " webroot / myliveapp/" e un altro ramo "sviluppo" su " webroot / devapp/"

Dove dovrebbe essere il repository ?

AGGIORNARE:

Voglio dire:

Avremo, secondo questo flusso:

• Prime repo;

• Bare repo hub;

• Clone;

I rami di sviluppo e produzione dovrebbero appartenere a un repository, giusto ?

Se questo è corretto, allora dovremmo emettere il PRIMO comando git init ?Sul nostro Prime repo?

Quindi avremo:

"webroot / myliveapp /" - ramo di produzione;

"webroot / devapp /" - ramo di sviluppo;

"webroot/.git " - Repository principale;

Ha senso?

O il repository Prime dovrebbe corrispondere alla sede della nostra filiale di produzione ?

*Nota:se hai bisogno di un contesto su quale flusso di lavoro sto cercando di implementare, è questo:http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Grazie per l'aggiornamento sulla tua domanda, è più chiaro ora.

Credo che il problema che stai avendo sia basato su un fraintendimento del flusso di lavoro di Git;Git non equivale directory per i rami, equivale a vista del tuo filesystem ai rami.Questo è potente-ma facile da sparare da soli nel piede.Lascia che ti spieghi.

Git agisce più come un filesystem di tracciamento della cronologia supportato da database, con versioni differenziate.È "sopra" il tuo filesystem, non "parte" di esso.Non usa il tuo filesystem per rappresentare i rami, piuttosto, quando estrai un ramo diverso, tutti i file nel tuo filesystem cambieranno per essere i file in quel ramo.Stai chiedendo a Git di far sì che il tuo filesystem rappresenti la realtà alternativa di quel ramo.

Se siete sul ramo master, e ha un archivio root/foo.txt impegnato, e si controlla ramo experiment, che fa non avere root/foo.txt impegnato, troverai quel file andare quando lo cerchi.È una parte di master, non experiment, e quindi non è presente nel Suo filesystem.Questo è il motivo per cui Git è davvero esigente riguardo al commit del tuo ramo corrente prima che ti permetta di cambiare ramo: se hai modifiche non segnate sul tuo filesystem che Git non conosce, si rifiuta di spazzarle via sovrascrivendole con una realtà diversa.Devi prima intervenire per sistemare le cose.

Quindi, per rispondere al quesiton, non creare sottodirectory per " myliveapp "e" devapp " - crea diversi ramo.Basta avere la tua base di codice sotto "webroot".Quindi, hackerare, ad esempio, il ramo" instabile", commettendo le modifiche come al solito.È quindi possibile passare tutti i file nel repository per essere alla versione dei file del server dev passando al ramo "devapp", e allo stesso modo è possibile tornare a" unstable " in qualsiasi momento.

Quando si desidera aggiornare un ramo, ad es.facendo un aggiornamento del tuo server dev, puoi merge "unstable "in"devapp".Questo renderà tutti i file di " devapp "simili a quelli di" unstable", aggiornandoli.

Un'altra cosa da notare:la differenza tra un repo primo, un repo nudo e cloni è quasi nulla.Non c'è praticamente alcuna differenza nel software;piuttosto, è una convenzione umana dire "il kernel di Linus è il kernel Linux canonico".Con questa comprensione:

• Un repository prime è solo un repository che tutti concordano detiene la versione "canonica" del software.Cioè, ogni volta che uno sviluppatore ha apportato una modifica che vuole che tutti vedano, piuttosto che dire "Estrai la mia versione di devapp", possono dire "Ho pubblicato le mie modifiche al nostro repository prime."È semplicemente una convenzione facile per le persone radunarsi.
• Un clone è una copia di qualche altro repo.Potrei clonare il repository principale, apportare modifiche e poi puoi clonare il mio repository.Se apporti modifiche, puoi spingerle sul repository principale o sul mio, purché l'unione sia valida e tu abbia le autorizzazioni sul computer.
• Un repository nudo semplicemente non ha una "copia di lavoro" - non esiste una directory" webroot " su quel computer.È vuoto con solo il .git directory-che va bene per i server in cui nessuno ha bisogno di modificare i file.

Infine, il .git dir non contiene i file del repository, contiene la configurazione e il database di git.È l'intera cronologia del repository in forma di database, che viene utilizzata per popolare il resto del repository con una particolare versione del software.Ecco perché ho fatto il commento:puoi localmente controlla qualsiasi versione di qualsiasi realtà alternativa del repository, senza comunicazione di rete, in qualsiasi momento - perché è tutto lì nel .git dir.L'unica comunicazione di rete necessaria è per quando si desidera sincronizzazione il tuo repository locale in qualche altro repository, usando push o pull.