Quale richiede più spazio su disco? Come tieni traccia delle correzioni dei bug (stiamo usando Jira)? Come fai a sapere quale ramo o repository ha la correzione del bug? ci devono essere altri vantaggi/svantaggi per repository vs branch?git branch vs. git repository, quale dovrei usare?
La tua domanda non ha molto senso. I repository contengono sempre almeno un ramo e non è possibile avere un ramo senza un repository. Quindi, ovviamente, un ramo è più piccolo di un repository. I due non sono cose davvero comparabili.
Quindi, parliamo per un momento di ciò che in realtà un repository Git contiene. Ci sono alcune cose principali:
lavoro albero - questo è lo stato attuale di tutti i file, quelli che stai lavorando. Questo può richiedere una discreta quantità di spazio.
oggetti - questi sono la strada interna Git cose - blob per rappresentare il contenuto dei file, alberi per rappresentare struttura di directory, si impegna a rappresentare le istantanee della struttura di lavoro. Questa è l'altra cosa che prende davvero spazio.
rif. - abbreviazione di referenze: rami o tag. Sono molto, molto leggeri - sono solo indicatori di particolari commit. Prendono un po 'di spazio, ma è così piccolo che dovresti pensarli completamente liberi. I tag sono riferimenti fissi; puntano a un commit per sempre, e sono usati per cose come le versioni di marcatura. I rami sono riferimenti mobili; con uno estratto, avanza mentre ti impegni. Sono quelli che utilizzerai per rappresentare linee di sviluppo: un ramo stabile, un ramo per una particolare correzione o caratteristica, lo chiami.
Ci sono altre cose all'interno della directory .git oltre a oggetti e riferimenti, ma ora non ti preoccupare molto di loro.
Come monitorare le correzioni dei bug (stiamo utilizzando Jira)?Come fai a sapere quale ramo o repository ha la correzione del bug?
Questo è gentile a voi. Generalmente le persone finiscono per incorporare alcune informazioni nei loro messaggi di commit per indicare che affrontano alcuni bug/problemi particolari. Probabilmente dovresti avere un flusso di lavoro definito, in cui inserisci i tuoi bugfix sui propri rami (o forse un ramo di manutenzione su una versione precedente), e uniscili nel tuo attuale ramo di sviluppo, condividendo in tal modo i bugfix con la versione futura. Dovresti essere in grado di dire qualcosa come "i rami master e manutenzione hanno sempre tutte le correzioni dei bug" - anche se vuoi controllare, puoi fare qualcosa come git log --grep='bug 1234', assumendo che tu abbia messo quella stringa nel tuo messaggio di commit!
In generale, non è necessario disporre di più cloni dello stesso repository del progetto. Probabilmente ne avrai uno centrale, e ciascuno sviluppatore ne avrà uno proprio, ma quando uno sviluppatore pubblica il suo lavoro, lo metteranno in quello centrale, ed è lì che dovrebbe essere tutto importante.
Per me, un repository dovrebbe ospitare un progetto distinto. Un ramo è un "percorso" di sviluppo del progetto. Quindi potresti avere un ramo di sviluppo, un ramo di produzione e alcuni rami di funzionalità e alcuni rami di correzione di bug. Le filiali possono essere unite l'una con l'altra, se necessario, e infine unite nello sviluppo e nella produzione.
Spazio su disco: un intero repository è più grande della creazione di un ramo, poiché un ramo è effettivamente solo un puntatore quando viene creato per la prima volta, mentre un intero repository deve memorizzare tutti i file git da capo.
Un ramo costa sempre praticamente nulla da creare all'interno dello stesso repository (tecnicamente parlando dipende da cosa si è inserito nel ramo, ma sono sicuro che all'inizio era chiaro).
Quando si clona il repository, si potrebbe finiscono con il doppio dei requisiti di archiviazione (sia per i pacchetti e per l'albero di lavoro). Tuttavia, questo potrebbe portarti a credere che i repository di clonazione siano necessariamente una cosa non ottimale. Lasciate che vi dica perché non è sempre vero/
Un repo è in realtà solo una raccolta di riferimenti di ramo. Un ramo in realtà (come in deep-copy) accetta quanto un repository, tranne che per i BLOB in commit unici per un ramo specifico. (Di solito non c'è molta differenza lì).
Localmente, è possibile clonare un repository praticamente senza costi aggiuntivi perché può essere collegato (all'interno dello stesso file system, ovvero). Anche il costo sostenuto dall'avere un altro albero di lavoro può essere evitato clonando in un repository nudo (ad esempio usando git clone --mirror).
all'interno di un progetto
A mio parere, un pronti contro termine corrisponde ad un 'giocatore' in flusso di lavoro distribuito. I giocatori possono essere "persone fisiche" o "proxy di ruolo". Ho
In pratica solo 3-4 tipi di rami sono condivisi Acros s tutti i repo (master, maint, testing, unstable).
FUORI UN PROGETTO
Naturalmente, un progetto di fornire in loco il proprio repo (la maggior parte del tempo). Sto iniziando ad inclinarmi all'utilizzo dei sottomoduli perché sembra più flessibile dei rami eterogenei (ad es.diversi progetti in rami separati dello stesso repository)
Un grande vantaggio di disporre di un unico repository è che sarà molto semplice passare da un ramo all'altro dell'albero di lavoro associato. Per essere onesti questa differenza può essere lavorato arounnd in due direzioni:
vedete, quando si guarda in questo modo, un repo comincia ad essere una raccolta di rami, con un'associazione più o meno convential a un singolo albero di lavoro. Le convenzioni sono dove emergono le vere differenze: voi di solito usate i pronti contro termine per gestire serie di filiali e diversi alberi di lavoro.
Un ramo richiede tanto quanto un repo? Hai usato git? – Cascabel
Come fai tu :) tyvm, io uso esclusivamente git; perché dovresti esprimerlo in modo diverso? A tutti gli effetti, su un filesystem locale non c'è molta differenza tra 'git branch bla' o' git clone. ../ blo' tranne che per gli alberi funzionanti in depositi non nudi; perché ti piacerebbe esprimerlo in modo diverso? – sehe
Er, l'albero di lavoro non è abbastanza importante? E se per qualsiasi motivo i repository non si trovano sullo stesso filesystem, raddoppierete anche il resto. (E questo è solo lo spazio su disco - ci vorrà anche del tempo umano per tenerli sincronizzati!) Penso che dato il fatto che l'OP abbia posto questa domanda, devi essere un po 'più attento. La creazione di un ramo è fondamentalmente sempre gratuita; clonare un repo non lo è. Se riesci a modificare quella prima frase, ti accontenterò volentieri del mio downvote - il resto della tua risposta è grandioso, ho appena trovato l'apertura estremamente fuorviante. – Cascabel
I rami all'interno di un repository hanno vantaggi anche al di là degli altri commenti. Molti strumenti grafici (o UI di testo) possono mostrarti informazioni su commit/tag/etc sui rami all'interno di un repository. Questi dati non sarebbero disponibili se si fosse creato un nuovo repository ogni volta che si voleva rompere lo sviluppo.
Avrete anche un tempo più semplice per esprimere le relazioni tra filiali e filiali quando viene utilizzata la ramificazione interna. È naturale lì, mentre con i repository aggiuntivi devi tracciare e gestire la relazione esternamente.
La ragione per cui la sto chiedendo è che ho partecipato ad alcuni corsi di git recentemente, e l'istruttore stava mostrando un flusso di lavoro in cui ci sono 2 repository. Uno è per dev sul ramo principale. Questo repository è costruito e testato e quindi i commit vengono inseriti nel repository "golden" per essere utilizzati dal QA. Stiamo cercando di eliminare le ragioni per l'utilizzo di questo modello, rispetto all'utilizzo di filiali. Grazie per tutti i commenti. Sto imparando molto come al solito. :-) – user561638
Se il repository clonato si trova sullo stesso disco e utilizza collegamenti fisici, potrebbe non utilizzare molto più spazio. Più di un semplice puntatore, che utilizza tutto il ramo, ma non necessariamente copie di tutti i file. – bstpierre
La ragione per cui la sto chiedendo è che recentemente ho partecipato ad alcuni corsi di git e l'istruttore stava mostrando un flusso di lavoro in cui ci sono 2 repository. Uno è per dev sul ramo principale. Questo repository è costruito e testato e quindi i commit vengono inseriti nel repository "golden" per essere utilizzati dal QA. Stiamo cercando di eliminare le ragioni per l'utilizzo di questo modello, rispetto all'utilizzo di filiali. Grazie per tutti i commenti. Sto imparando molto come al solito. :-) – user561638