Git workflow - aconselhe um novato

Question

Git workflow - aconselhe um novato

#1 resposta do (4 votos)
#2 resposta do (-4 votos)

5

Estou começando a trabalhar com o git pela primeira vez e estou tentando criar um fluxo de trabalho que funcione para mim, então pensei em vir e perguntar por aí.

Neste momento, estou em alguns projetos em que sou o único programador e, de fato, o único promotor de origem.

Estou trabalhando assim, onde c é um commit, p é um push e m é uma mesclagem:

              /feature2-c-c-c-c-m-c-c-c-c
             /                 /     \
master-----------------------m-p------m-p
        \                  /           \  
         \-feature1-c-c-c-c-c-c-c-c-c-c-m-c-c

Agora eu percebi que rebasing seria mais "correto" do que aqueles merge master que eu faço nos ramos de recursos, ou pelo menos é assim que parece ... mas eu não tenho certeza se estou fazendo isso certo. O que eu percebi agora é que, ao mesclar o mestre em meus outros ramos, eu bagunço o histórico da minha ramificação e adiciono todos os recursos não relacionados a ele.

Talvez eu deva ramificar mais, pela subtarefa, adicionando um terceiro nível como este:

                 ....................\
master---------------------------m-p--m-p-....
        \                       /         \
         \-feature1------------m-----------m.....
            \                 /             \  
             \-feature11-c-c-c          feature12-c-c-c..

Isso deixa sem resposta o fato de que, às vezes, um recurso é maior do que um ramo deveria ser.

Estes são os meus pensamentos sobre o assunto até agora, por isso estou muito aberto a sugestões sobre qual é o melhor fluxo de trabalho do git em equipes de uma ou duas pessoas.

Espero que os diagramas sejam fáceis de seguir.

git workflows

por Lacrymology 17.06.2011 / 00:39

fonte

2 respostas

-4

Se você é o único desenvolvedor, por que isso é tão complicado? Tenha um único branch master, confirme as alterações localmente e envie somente quando tiver certeza de que o código está funcionando. Se você tentar implementar um recurso e ele não funcionar, reverta para o commit antes de tentar implementá-lo.

por 17.06.2011 / 03:25

fonte

Tags git workflows

Qual é o caminho a percorrer para extrair dados de sites? [fechadas] Como encontrar sub-árvores em árvores não binárias

score 4 · Accepted Answer

TL; DR : o fluxo de trabalho do seu git não é realmente o problema. O problema é que você precisa de mais iterações menores nos recursos que você coloca em suas ramificações tópicas. Isso reduzirá a dor de manter esses ramos tópicos atualizados e integrá-los ao upstream.

Você definitivamente deseja manter os branches desimpedidos atualizados com as alterações em seus upstream, e a rebasing geralmente é a maneira correta de fazer isso.

Seu comentário de que "às vezes um recurso é maior do que o que um ramo deve ter" me leva a acreditar que você tem ramificações tópicas de longa duração que você acha difícil de integrar ao seu ramo de integração. Isso, na minha experiência, é a raiz real da sua dor.

Imagine se suas ramificações tópicas durassem algumas horas e depois fossem mescladas de volta ao ramo de integração. Essas ramificações efêmeras provavelmente serão triviais para se manterem atualizadas e triviais para serem mescladas em sua ramificação de integração. Por outro lado, imagine uma ramificação tópica de longa duração que abrange várias versões do software sem integração. Provavelmente seria muito difícil de integrar. Isso deve levar você a concluir que os ramos tópicos de curta duração que são frequentemente rebaixados contra o mestre são mais fáceis de se trabalhar.

A pergunta, então, torna-se "por que os recursos seriam maiores do que um ramo deveria ser?" Isto é provavelmente porque você está tentando fazer muito de uma vez. A melhor maneira de manter ramos tópicos de curta duração e de tornar a integração indolor é trabalhar de forma iterativa, onde o recurso comercializável mínimo é impiedosamente reduzido a seus fundamentos e o trabalho adicional sobre esse recurso é adicionado em incrementos separados.