Secondo ramo principale per abbandonare l'abuso di controllo del codice sorgente?

1

Ho appena saputo di Source Control questa settimana e mi sono reso conto che il mio team lo usa chiaramente.

  • Una riga principale per il commit del codice da vivere. Nessun altro ramo; questo è tutto.
  • Funzioni di ramificazione disattivate per tutti tranne amministratore
  • Le persone creano backup di file manuali e li lasciano sparpagliati, perché non ci sono branching
  • Directory di lavoro su unità condivisa: tutti modificano gli stessi file
  • Il checkout è sempre esclusivo, forse in base alla progettazione dei file di unità condivisi

  • Il flusso di lavoro è in genere Edit-Checkout-ImmediateCheckin a causa dei blocchi esclusivi. Dio non voglia che qualcuno abbandoni un progetto per lavorare su qualcos'altro e lo lascia a metà finito sull'unità condivisa

Lo stigma è che il controllo del codice sorgente viene messo in atto per ragioni di responsabilità piuttosto che per la cronologia delle revisioni: il check-in nell'unico ramo attivo richiede un ticket di supporto "quindi non abbiamo un altro spazio ufficio". Il nostro sistema di test è molto più gratuito: compilare il file dall'area dev e rilasciarlo in posizione nell'area di staging (anche una cartella condivisa) e vedere se funziona. Alla gente piace questa libertà.

Stiamo attualmente migrando le nostre applicazioni console alla GUI, quindi molte cose vengono riscritte. Immagino che questo sia il momento migliore per introdurre un cambiamento.

Stavo pensando di aggiungere una seconda linea principale per il nostro nuovo codice che "farai bene questa volta", piuttosto che ripulire il casino che abbiamo ora:

  • una nuova mainline per codice live (se solo per i nuovi programmi)
  • un ramo Baseline di test sotto questa nuova linea principale per build stabili
  • rami di lavoro su richiesta per nuove funzionalità e correzioni di errori

Ho parlato con due dei quattro sviluppatori e ho ricevuto qualche riscontro da loro, ma sono preoccupati delle complicazioni e dei passaggi aggiuntivi che potrebbero portare al loro flusso di lavoro perché non hanno mai usato la ramificazione.

Usiamo Surround SCM accoppiato con TestTrack per i ticket di richiesta di modifica, se questo è importante. Sto proponendo di effettuare il check-in solo nelle filiali private dell'area di lavoro, quindi di promuovere i rami fino alla mainline come meglio crediamo.

    
posta Bret 01.04.2015 - 16:24
fonte

1 risposta

3

Non è necessario avviare un nuovo repository, basta iniziare la ramificazione.

Dai ai leader il permesso di unirsi al tronco, tutti gli altri devono creare un ramo e impegnare il loro lavoro lì. l'unica complicazione in più è quella di dover creare un ramo (per ticket, consigliato) e passare la copia di lavoro al ramo piuttosto che al trunk. A questo punto puoi sbarazzarti delle casse esclusive.

Questo renderà le cose più facili per gli sviluppatori, e ti darà anche molta più tracciabilità di ciò che è in una versione - saranno solo quei rami che sono stati uniti al tronco. Una volta rilasciato il giorno di rilascio, puoi anche creare un ramo dal tronco e chiamarlo qualcosa di speciale in modo da avere un'istantanea di una versione che potresti modificare con quelle correzioni di emergenza.

    
risposta data 01.04.2015 - 17:32
fonte

Leggi altre domande sui tag