Filiale per caratteristica: quali sono i benefici (e rischi) effettivi? [chiuso]

I vantaggi sono ovvi: si lavora sulle funzionalità in modo indipendente e quindi non influenzano mai il lavoro di nessun altro finché non arriva il momento di unire. Puoi eseguire revisioni del codice e test mirati sul ramo della funzione senza trattenere nessuno se c'è un problema.

Gli svantaggi: in primo luogo, devi unire e mentre non è un problema con strumenti come Subversion, git o simili, può essere un dolore giusto con alcuni strumenti. Devi anche considerare che anche con strumenti che supportano la fusione, non è necessariamente un processo senza problemi. Se devi unire file binari (ad esempio immagini, icone, ecc.) O unire file che sono stati modificati, dovrai dedicare un po 'più di tempo alla gestione dell'unione.

L'altro svantaggio è che potresti aggiungere qualcosa a un ramo di funzionalità che vorresti utilizzare, oppure unire il ramo di funzione a quello attuale o aspettare che venga unito a trunk (e quindi unirlo it), quindi c'è spazio per essere un po 'obsoleti rispetto ad altri lavori.

Entrambi gli svantaggi non sono particolarmente onerosi finché non ci si aspetta che i rami delle feature vengano elaborati e lasciati a lungo prima di unirli nuovamente al tronco. Penso che siano probabilmente un modo migliore di lavorare rispetto al modello di sviluppo / principale / rilascio, e in particolare al modello "work on trunk", caratterizzato da strumenti come Sourcesafe.

Detto questo, non c'è motivo per non aggiustare qualcosa che non sia rotto. Se il tuo team è adatto al tuo processo attuale e non hai problemi con esso, continua a utilizzarlo.

Supponiamo che tu stia lavorando su una funzione in un ramo separato. Quindi per qualche ragione, devi fare una modifica completamente non correlata da qualche altra parte; dì che stai aggiustando la build.

Con i rami funzione, puoi semplicemente impegnare il tuo lavoro corrente nella tua filiale, passare all'impostazione predefinita, correggere e tornare indietro.

Senza feature branch, devi scegliere in maniera molto selettiva quali file vuoi impegnare (cosa che può andare storto molto facilmente), o devi mettere da parte il tuo lavoro corrente (ma gli stashes possono essere pignoli), o devi solo spingere cose non finite (puoi immaginare le potenziali conseguenze).

Un altro scenario utile è dove devi fare del lavoro che toccherà un sacco di codice, qualcosa su cui avresti lavorato per qualche tempo. Di solito questi sono grandi refactoring.
Se fai questo genere di cose in un ramo, puoi lavorare da solo, senza disturbare gli altri con le tue modifiche, ma continui a impegnarti e sincronizzarti con il ramo predefinito.

I rami forniscono una buona rete di sicurezza e posso dire che abbiamo avuto meno conflitti di fusione e frizione generale da quando abbiamo iniziato ad usarli. Ma il tuo chilometraggio può variare.

Dipende da quale sistema di controllo sorgente stai usando. In alcuni sistemi di controllo del codice sorgente distribuiti come i rami Git e Mercurial sono molto leggeri e di solito creo branch per feature mentre utilizzo uno di questi sistemi. È molto conveniente e relativamente facile da mantenere. Puoi facilmente fare diversi esperimenti con il tuo codice sorgente e condividere questi risultati con altri.

Anche la ramificazione è utile quando si lavora su una funzione di grandi dimensioni e occorre eseguire alcune attività di supporto con il codice esistente. È possibile passare facilmente dal ramo di funzione al ramo predefinito, correggere il ramo predefinito, tornare indietro e continuare a lavorare sulla funzione. Ovviamente dovresti prendere periodicamente le modifiche dal ramo predefinito.

Tuttavia, alcuni sistemi di controllo del codice sorgente non supportano i rami leggeri e copiano l'intera directory con il codice sorgente. In questo caso la ramificazione per funzionalità è davvero dolorosa quando la codebase ha dimensioni grandi.

I principali vantaggi sono che potresti avere una squadra di dimensioni troppo grandi, o voler lavorare troppe ore al giorno, per tenerti occupato fornendo solo la funzionalità richiesta.

Questo problema viene risolto aggiungendo rami di funzionalità longevi. Questo moltiplica le dimensioni effettive del tuo codice base per il numero di tali rami, creando un lavoro adeguato per tutti i membri del team. E a differenza della semplice aggiunta di ulteriori funzionalità, questo evita di complicare il software o di perdere opportunità per entrate future. Tutti sono impegnati a digitare (o almeno fare clic) in modo visibile, quindi nessuno sembra avere problemi di gestione.

Un altro vantaggio è che evita di dover imparare come utilizzare correttamente un moderno sistema di controllo delle versioni distribuito come git per adattarsi a circostanze diverse, come un cambio di contesto non pianificato, la necessità di applicare patch a una versione precedente o annullare un brutto cambiamento . Invece, una tecnica si adatta a tutti gli imprevisti e tutto può essere spinto centralmente proprio come se si stesse usando un Visual SourceSafe più veloce.