Ostacoli all'uso di Git Flow in Subversion

10

Il mio team al lavoro sta avviando un nuovo progetto, utilizzando Subversion come VCS (puoi considerare questo insieme in pietra ai fini di questa domanda). Siamo ancora nelle prime fasi del progetto e stiamo cercando di concordare un modello di ramificazione. Il nostro progetto precedente era basato su un modello di versione non standard che ha portato a problemi durante la gestione delle correzioni rapide e delle patch alle versioni esistenti.

Ho trovato diversi modelli di ramificazione piuttosto complicati, ma un modello che capisco abbastanza chiaramente è git flow . Sono curioso di quanto sia difficile / indesiderabile implementare una variazione di questo in Subversion. Ovviamente ci sarebbe qualche differenza in termini di persone che collaborano nelle filiali. I rami di funzionalità dovrebbero essere centralizzati piuttosto che limitarsi ai repository locali, ma gli altri concetti del modello dovrebbero essere riproducibili in Subversion come capisco.

Quali sarebbero gli inconvenienti o le sfide a questo approccio. Quello che ho sentito è che in SVN "la fusione è costosa" rispetto a Git. Ma non sono del tutto chiaro su cosa questo significhi in pratica o su come potrebbe influenzare la nostra capacità di usare un flusso git come un modello di ramificazione.

Quali sarebbero le maggiori preoccupazioni con questo approccio. Esiste un approccio altrettanto chiaro che è più naturale in Subversion?

    
posta Ben McCormick 12.12.2013 - 03:34
fonte

1 risposta

12

Gitflow si basa sulle migliori pratiche di controllo delle versioni e diramazioni del codice sorgente. Un ottimo articolo su questo è Advanced SCM Branching Strategies

Il punto che Vance fa nell'articolo collegato è che diversi rami hanno differenti ruoli . Identifica i ruoli di:

  1. Linea principale (tutti i rami da qui)
  2. Sviluppo (in cui viene svolto il lavoro di sviluppo)
  3. Manutenzione (in cui sono stati eseguiti interventi di manutenzione)
  4. Accumulazione (mettere insieme le cose in preparazione per il rilascio)
  5. Packaging (impacchettare la build per il rilascio)

In gitflow, questi sono:

  1. Sviluppare
  2. feature branches
  3. Rami di aggiornamento rapido
  4. Rilascia rami
  5. Master

L'articolo sulla ramificazione è stato scritto con Perforce in mente. Perforce è un VCS centralizzato, molto simile a svn is. Gli schemi di ramificazione che descrive si adattano perfettamente a svn.

La chiave per capire è che non è come gitflow viene portato in svn, ma piuttosto come applicare gli stessi concetti fondamentali di ramificazione e i ruoli dei rami a diverse strutture VCS.

Vorrei strongmente consigliare di leggere l'articolo, non posso far molto credito ad esso. Il modo in cui sono descritte le cose si basa su una filosofia di compilazione di trunk / mainline che ti consentirà di mappare facilmente svn in.

    
risposta data 12.12.2013 - 03:53
fonte

Leggi altre domande sui tag