dvcs - “clonar para ramificar” um fluxo de trabalho comum?

Estive discutindo recentemente os dvcs com um colega de trabalho, porque nosso escritório está começando a considerar a mudança do TFS (somos uma loja da MS). No processo, fiquei muito confuso porque ele disse que, embora ele use o Mercurial, ele não tinha ouvido falar de um comando "branch" ou "checkout", e esses termos não lhe eram familiares. Depois de se perguntar como era possível que ele não os conhecesse e de explicar como as ramificações do dvcs funcionam "no lugar" em seus arquivos locais, ele ficou bastante confuso.

Ele explicou que, semelhante à maneira como o TFS funciona, quando ele deseja criar um "ramo", ele faz isso por clonagem, para que ele tenha uma cópia inteira de seu repositório. Isso me pareceu realmente estranho, mas o benefício, que tenho que admitir, é que você pode olhar ou trabalhar em dois ramos simultaneamente, porque os arquivos são separados.

Ao pesquisar neste site, para ver se isso foi perguntado antes de eu ver um comentário, muitos recursos on-line promovem essa metodologia de "clonagem para ramificação", para desgosto do pôster. Isso é realmente comum na comunidade dvcs? E quais são alguns dos prós e contras de seguir esse caminho? Eu nunca faria isso, já que não preciso ver várias ramificações de uma só vez, a troca é rápida e não preciso de todos os clones que preenchem meu disco.

Além da vantagem / desvantagem geral de poder ver os dois ramos, acho que há uma vantagem específica do Mercurial em fazer isso.

Se você clonar para criar uma ramificação, poderá excluí-lo mais tarde se não desejar manter suas alterações. Se você decidir mesclá-las, o fato de ter decidido separar suas alterações dessa maneira não será visível para mais ninguém.

Por outro lado, se você costuma hg branchcriar uma nova ramificação nomeada, o nome da ramificação é registrado no histórico quando você confirma, é visível para todos os outros e precisa ser bastante exclusivo para evitar possíveis confusões mais tarde. Isso pode não ser apropriado se sua ramificação for para o desenvolvimento de algum recurso experimental ou para uma alteração que pode ser pequena.

Se você usar ramificações nomeadas para manter as versões lançadas do seu software e também usá-las para desenvolver recursos de curto prazo ou correções, é fácil ficar confuso porque não há como (além das convenções de nomenclatura) manter esses dois tipos de ramificações separados.

http://mercurial.selenic.com/wiki/StandardBranching explica isso em mais detalhes. Também vale ressaltar que, desde o Mercurial 1.8, é possível criar um marcador ( hg bookmark) - um nome descartável para um ramo de vida curta. Os marcadores podem ser empurrados, puxados, movidos e excluídos.

Toda vez que você efetua um commit em um DVCS, tecnicamente está criando um branch na história, toda vez que o envia de volta ao repositório abençoado e o integra, aqui vem a parte interessante:

• Se ninguém fez uma alteração durante o seu commit, ele não parecerá uma ramificação no DAG (gráfico acíclico direcionado)
• Se alguém fez uma alteração durante o seu commit, ele parecerá uma ramificação no DAG, apenas sem nome

Lembre-se do botão "fork" no Bitbucket / github ?, o bifurcação pode ser considerado um sinônimo de ramificação, e o que o botão "fork" faz é apenas um clone desse repositório para sua conta.

A única vantagem da "clonagem para ramificação" é poder trabalhar simultaneamente em dois pontos da história e, ironicamente, para seu colega de trabalho, é um fluxo de trabalho comum para trabalhar em ramificações diferentes ao mesmo tempo (sem ter que ir e voltar) )

Diga ao seu colega de trabalho para aprender como ramificar , é muito fácil, aqui, tenha um 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

"Clonagem para ramificação" faz sentido quando você trabalha em ramificações diferentes ao mesmo tempo ou quando deseja experimentar um experimento sem criar uma ramificação permanente no histórico e ainda poder integrá-lo a uma ramificação já existente. .

Pessoalmente, não gosto dessa prática e prefiro fazer ramos e fechá-los, se necessário. Aqui, é assim que você faz:

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)

Espero que isso esclareça suas dúvidas de ramificação do DVCS, aqui as ramificações não são mais assustadoras.

Pessoalmente, eu não me preocuparia com o código preenchendo meu disco ... primeiro, é apenas código e, segundo, você não manterá todos os seus clones para sempre.

Essa metodologia é promovida em muitos recursos online, especialmente para Hg. Eu nunca vi isso usado na produção, em ambientes de CI é muito mais comum ter ramificações de recursos de vida curta do que clones de repositório adicionais. Não vejo a vantagem de fazer isso, se algo tornar sua história mais confusa, não menos, e também não ganhar nada. Se você deseja examinar seu novo código lado a lado com o código antigo, pode usar uma ferramenta diff / merge para examinar os dois commits próximos um do outro, com a vantagem adicional de ver as alterações destacadas.