dvcs - "clone to branch" è un flusso di lavoro comune?

9

Recentemente ho discusso di dvcs con un collega, perché il nostro ufficio sta iniziando a prendere in considerazione il passaggio da TFS (siamo un negozio MS). Nel processo, mi sono molto confuso perché ha detto che sebbene usa Mercurial, non aveva sentito parlare di un comando "branch" o "checkout", e questi termini non gli erano familiari. Dopo essersi domandato come fosse possibile non conoscerli e aver spiegato come i rami di dvcs funzionano "sul posto" sui file locali, era piuttosto confuso.

Ha spiegato che, analogamente a come funziona TFS, quando vuole creare un "ramo" lo fa clonando, quindi ha un'intera copia del suo repository. Mi è sembrato davvero strano, ma il vantaggio, che devo ammettere, è che puoi guardare o lavorare su due rami contemporaneamente perché i file sono separati.

Cercando questo sito per vedere se questo è stato chiesto prima ho visto un commento che molte risorse online promuovono questa metodologia "clone to branch", con sgomento del poster. Questo è effettivamente comune nella comunità di dvcs? E quali sono alcuni dei pro e contro di andare in questo modo? Non lo farei mai poiché non ho bisogno di vedere più rami contemporaneamente, il passaggio è rapido e non ho bisogno di tutti i cloni che riempiono il mio disco.

workflows dvcs branching

— Tesserex
fonte

7

questo è un blocco dai flussi di lavoro CVS e SVN, ricorda "a un martello tutto sembra un chiodo"

1

@JarrodRoberson - Solo se ti limiti al modo in cui gitfunziona. Con hgquesto è di solito il primo flusso di lavoro insegnato ed è ancora molto utile.

— Mark Booth,

3

A parte il vantaggio / svantaggio generale di poter vedere entrambi i rami, penso che ci sia un vantaggio specifico per Mercurial nel farlo.

Se cloni per creare un ramo, puoi eliminare il clone in un secondo momento se non desideri conservare le modifiche. Se decidi di unirli, il fatto di aver deciso di separare le modifiche in questo modo non è visibile a nessun altro.

Al contrario, se si utilizza hg branchper creare un nuovo ramo denominato, il nome del ramo viene registrato nella cronologia quando si esegue il commit, è visibile a tutti gli altri e deve essere abbastanza unico per evitare potenziali confusioni in seguito. Questo potrebbe non essere appropriato se il tuo ramo è destinato allo sviluppo di alcune funzionalità sperimentali o per un cambiamento che potrebbe rivelarsi piccolo.

Se usi le filiali denominate per mantenere le versioni rilasciate del tuo software e le usi anche per sviluppare funzionalità o correzioni di bug a breve termine, è facile confondersi perché non c'è modo (oltre alle convenzioni di denominazione) di mantenere separati questi due tipi di filiali.

http://mercurial.selenic.com/wiki/StandardBranching spiega questo in modo più dettagliato. Vale anche la pena ricordare che da Mercurial 1.8 è possibile creare un segnalibro ( hg bookmark) - un nome usa e getta per un ramo di breve durata. I segnalibri possono essere spinti, tirati, spostati ed eliminati.

— Benj
fonte

2

Non ho usato molto Mercurial ma Git non ha questo problema. Posso diramare tutto il giorno a livello locale, unirmi allo sviluppo del ramo, spingere e nessuno deve guardare i nomi dei miei rami.

— Andrew T Finnell,

3

@AndrewFinnell: Non si adattava davvero alla domanda, ma volevo dire che non è necessariamente un problema - ci sono anche alcuni vantaggi nel modo in cui le filiali denominate nel lavoro di Mercurial. Ad esempio, puoi vedere su quale ramo è stato originariamente eseguito un commit, che può essere utile sapere.

— benj,

1

@AndrewFinnell - I rami con nome sono qualcosa in cui mi manca moltogit , dopo essermi abituato hg. Inoltre, dover ricordare esplicitamente git branchogni volta che voglio creare un ramo è fastidioso, rispetto alla hgcreazione automatica di rami senza nome.

— Mark Booth,

Puoi comunque usare l'estensione di strip in bundle per eliminare il tuo ramo in hg. Mercurial supporta meglio la modifica della storia in questi giorni attraverso l'uso di "fasi"

— dukeofgaming

2

Ogni volta che effettui un commit in un DVCS stai tecnicamente facendo un ramo nella storia, ogni volta che lo riporti nel repository benedetto lo integri di nuovo, ecco la parte interessante:

Se nessuno ha apportato una modifica durante il commit, non sembrerà un ramo nel DAG (grafico aciclico diretto)
Se qualcun altro ha apportato una modifica durante il commit, sembrerà un ramo nel DAG, solo senza nome

Ricorda il pulsante "fork" in Bitbucket / github ?, il biforcazione può essere considerato un sinonimo di ramificazione e ciò che fa il pulsante "fork" è solo un clone di quel repository sul tuo account.

L'unico vantaggio della "clonazione su ramo" è la capacità di lavorare simultaneamente in due punti della storia e, ironicamente, per il tuo collega, è un flusso di lavoro comune per lavorare su rami diversi contemporaneamente (senza dover andare avanti e indietro ).

Di 'al tuo collega di imparare come ramificare , qui è molto facile avere un tutorial:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

"Clonare su un ramo" ha senso quando lavori contemporaneamente in diversi rami o, quando vuoi provare un esperimento senza creare un ramo permanente nella storia ed essere ancora in grado di integrarlo in un ramo già esistente .

Personalmente non mi piace questa pratica e preferisco fare rami e chiuderli se necessario. Ecco come si fa:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Spero che questo cancella i tuoi dubbi ramificati DVCS, qui i rami non fanno più paura.

— dukeofgaming
fonte

0

Personalmente non mi preoccuperei che il codice riempia il mio disco ... in primo luogo, è solo codice, e in secondo luogo, non manterrai tutti i tuoi cloni per sempre.

Questa metodologia è promossa in molte risorse online, in particolare per Hg. Non l'ho mai visto usato in produzione, in ambienti CI è molto più comune avere rami di funzionalità di breve durata rispetto a cloni di repository aggiuntivi. Non vedo il vantaggio di fare questo, se qualcosa renderà la tua storia più confusa, non meno, e inoltre non ti farà guadagnare nulla. Se vuoi guardare il tuo nuovo codice fianco a fianco con il vecchio codice puoi usare uno strumento diff / merge per guardare i due commit uno accanto all'altro, con l'ulteriore vantaggio di vedere evidenziate le tue modifiche.

— philosodad
fonte

L'ho usato ampiamente in produzione, con hg. Essere in grado di spingere e tirare tra più hgrepository può essere uno strumento collaborativo davvero potente. Solo essere in grado di estrarre da gitrepository non bare può sostanzialmente limitare le opzioni con questo tipo di flusso di lavoro.

— Mark Booth,