Ostacoli all'uso di Git Flow in Subversion


10

Il mio team al lavoro sta iniziando un nuovo progetto, usando Subversion come nostro VCS (potresti considerare questo set 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 precedente progetto si basava su un modello di versione non standard che portava a problemi nella gestione di hotfix e patch per le versioni esistenti.

Ho trovato diversi modelli di ramificazione per essere piuttosto complicati, ma un modello che capisco abbastanza chiaramente è git flow . Sono curioso di sapere 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 delle caratteristiche dovrebbero essere centralizzati piuttosto che limitati ai repository locali, ma gli altri concetti del modello dovrebbero essere riproducibili in Subversion come lo capisco.

Quali sarebbero gli svantaggi o le sfide di questo approccio. Quello che ho sentito è che in SVN "la fusione è costosa" rispetto a Git. Ma non sono completamente chiaro su cosa significhi in pratica o su come influenzerebbe 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?

Risposte:


12

Gitflow si basa sulle migliori pratiche di versioning e branching del codice sorgente. Un ottimo articolo su questo è Advanced SCM Branching Strategies

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

  1. Mainline (tutte le filiali da qui)
  2. Sviluppo (dove viene svolto il lavoro di sviluppo)
  3. Manutenzione (dove vengono eseguiti i lavori di manutenzione)
  4. Accumulazione (Riunire le cose in preparazione per il rilascio)
  5. Imballaggio (impacchettare la build per il rilascio)

In gitflow, questi sono:

  1. Sviluppare
  2. rami delle caratteristiche
  3. Rami dell'aggiornamento rapido
  4. Rilasciare i rami
  5. Maestro

L'articolo sulla ramificazione è stato scritto pensando a Perforce. Perforce è un VCS centralizzato, proprio come svn. Gli schemi di ramificazione che descrive perfettamente mappano su svn.

La chiave da capire è che non è come si fa il porting di gitflow su svn, ma piuttosto come applicare gli stessi concetti fondamentali di branching e ruoli dei branch a differenti strutture VCS.

Consiglio vivamente di leggere l'articolo, non posso fare molto credito ad esso. Il modo in cui le cose sono descritte qui si basano su una filosofia di costruzione trunk / mainline alla quale è facile mappare svn.


1
Tornare alle idee che guidano il design di gitflow è un intelligente miglioramento della domanda originale!
user40989

@ user40989 Non sono sicuro che Vincent Driessen (nvie) abbia letto l'articolo o meno che abbia presentato questo concetto di ramificazione o se lo abbia riscoperto da solo. In entrambi i casi, il riconoscimento di quali ruoli necessari per un flusso di lavoro attraverso il controllo di versione rendono facile vedere le somiglianze tra gli approcci e le migliori pratiche.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.