in un unico repository o due

Question

in un unico repository o due

#1 da (3 voti)

1

Ho una base di codice C che supporta un certo numero di personalità di costruzione, per una data architettura di schede. È principalmente in modalità di manutenzione. Non facciamo nuovi sviluppi attivi su di esso.

Abbiamo una nuova scheda per una generazione 2 del prodotto. La generazione 2 sostituirà la generazione 1 (non stiamo costruendo altre schede Gen 1). La seconda generazione richiederà una buona parte del codice da riscrivere completamente. Direi il 50% di esso. OTOH, c'è un codice che rimarrà lo stesso. Rendere la build modulare per supportare entrambi i tipi non vale la pena per noi. In pratica, stiamo essenzialmente inserendo il progetto in due in modo permanente.

Sto sollecitando l'input su solo

Crea un nuovo repository git, copia il codice dal vecchio al suo interno e decolla e scopri dove ci porterà il futuro.
Conserva lo stesso repository, ma aggiungi solo altri rami.

Attualmente utilizziamo uno schema nel nostro repository per avere un ramo master per le uscite di produzione, un ramo testing dove accumuliamo lavoro "benedetto" e singoli rami per le diverse unità di lavoro che facciamo.

I pro / contro come li vedo sono:

Due repository
- Pro: i rami restano semplici. Costretto ad avere un repository per ogni carico se ho bisogno di confrontare
- Contro: non è possibile selezionare tra i due (raramente lo facciamo però)
Un repository, rami diversi
- Pro: codice tutto rimane nello stesso ramo, forse in grado di sfruttare alcune caratteristiche "cross-branch" di git
- Contro: devi annotare i rami master e testing per le due cose diverse per disambigarli

Che cosa dovremmo fare, e perché?

git

posta Travis Griggs 14.03.2015 - 00:49

fonte

1 risposta

Leggi altre domande sui tag git

Secondo ramo principale per abbandonare l'abuso di controllo del codice sorgente? Perché un'architettura con modelli anemici è conforme allo standard JavaEE?

score 3 · Accepted Answer

Dato che git è così flessibile, probabilmente si può fare una soluzione in ogni caso e quale è la risposta più corretta dipende interamente da come è il flusso di lavoro quotidiano, quindi darò la risposta per il flusso di lavoro I Sono abituato a (che penso sia uno dei "normali").

Il più delle volte sto digitando un comando git o capendo quale comando git scrivere, una delle grandi assunzioni che sto facendo è sempre: "C'è solo un ramo con il codice 'reale' (codice che rotola out to production e rende i soldi del business), ed è master , tutto il resto del codice non è 'reale' fino a quando il suo ramo supera la revisione del codice e viene unito in master . " Anche se git in nessun modo richiede di fare questa ipotesi, penso che sia così che funziona lo sviluppo del mondo reale.

L'unica opzione di repository significa essenzialmente che hai un repository con "due master rami". A meno che non pianifichi di sviluppare e distribuire in parallelo due prodotti diversi che condividono un sacco di codice (che in questo caso non lo sei), penso che sia un po 'poco intuitivo e soggetto a errori rispetto a dare a ciascun prodotto un repository separato. Personalmente, so che sarei sempre un po 'preoccupato di unire per errore "il ramo master sbagliato" per caso se il mio team l'avesse fatto.

Inoltre, come ha detto amon, git non ti impedisce di spostare il codice tra i repository. Alcuni comandi git fetch e git cherry-pick dovrebbero essere tutto ciò che serve per applicare "vecchi" commit a "nuovi" rami di codice. Non è molto più difficile che spostare le cose all'interno di un singolo repository. Sarà diverso, ma probabilmente dovrebbe essere diverso.