Trovare un equilibrio tra deprecating repository e deprecating branches

3

(Questa domanda potrebbe essere eccessivamente ampia e certamente non ha una risposta "giusta".)

Sto riscrivendo alcuni piccoli progetti integrati per un'azienda. Piuttosto che immergermi nel codice preesistente, sto ricominciando da capo. Il codice originale è stato scritto dagli studenti per un progetto di ricerca e mentre ha dimostrato il punto, ha dei bug profondi e non è stato scritto o mantenuto in modo professionale.

Nessuna lamentela qui, cappello a loro per dimostrare che era possibile in primo luogo. Tuttavia, ciò significa che non ha senso cercare di salvare il codice originale. È molto meglio iniziare da zero e creare da un elenco di funzionalità e da un documento di progettazione concordati.

Ora che ho questi nuovi progetti già operativi, qual è la migliore pratica per riportarli in azienda? Dovrei

  1. Effettua un commit che clobbers efficacemente tutto il vecchio codice e lo sostituisce con il mio?
  2. O dovrei archiviare il repository esistente e creare un nuovo repository?

Pros per il numero 1: chiunque controlli il codice ottiene la cronologia completa. Se qualcuno sta cercando una vecchia funzionalità, può trovarla facilmente. Contro il n. 1: perché dovresti mai pensare di cercare nella cronologia git di questi dati? I coder originali non sono particolarmente versati in git e non sono propensi a pensare di cercare il codice in questo modo

Pros per il n. 2: tutto è pulito Contro il 2: Mantenere vecchi oggetti archiviati attorno alle build cruft, ed è difficile sapere qual è il suo valore quando lo si incontra 5 anni dopo. Qualcuno potrebbe addirittura usarlo accidentalmente.

    
posta Kenn Sebesta 01.03.2018 - 16:11
fonte

1 risposta

4

In generale, direi mai roba da eliminare. Il che è un po 'quello che stai facendo con il nuovo repository. "archiviare" è difficile, e in genere le persone intendono "conservare una copia da qualche parte ma non occuparsene".

Hai un caso speciale, ma ancora una volta, "Generalmente" ti aspetteresti di dover mantenere la versione 1 e la versione 2 di qualsiasi prodotto software per un periodo di modifica.

Ciò significa che potrebbe essere necessario rilasciare una v 1.1 dopo aver rilasciato 2.0.

Git rende questo super facile, puoi taggare e diramarti da un commit storico, apportare modifiche e costruire ..... Finché hai mantenuto il commit.

Se stai solo facendo un nuovo repository per "pulizia", puoi potenzialmente spararti nel piede se perdi il repository.

Direi che dipende da chi ha la responsabilità di quel vecchio codice.

Se non sei tu, quindi vai avanti, stai creando un nuovo prodotto, usa un nome diverso, un nuovo repository, una nuova lingua. non fare una versione 2.

Se sei tu, allora puoi tenere il repository o archiviarlo correttamente con piani di manutenzione e simili.

    
risposta data 01.03.2018 - 16:26
fonte

Leggi altre domande sui tag