Como devo controlar as versões do meu projeto no GitHub

Atualmente, estou tentando gastar o máximo de tempo possível no GitHub (mesmo sendo a única pessoa em equipe no trabalho) para realmente sentir como será um aplicativo corporativo do mundo real.

Uma pergunta que estou tendo é controlar a versão . Digamos que começamos um projeto. Em seguida, os membros da equipe criaram alguns ramos e se desenvolveram lá. Quando estamos prontos para a produção, mesclamos todos os ramos com os masterramos. No final, vamos ao vivo com a versão 1.0.

Agora essa versão 1.0está ativa e temos alguns problemas arquivados para essa versão desse software. Gostaríamos de começar a desenvolver a versão 1.1para corrigir os problemas que introduzimos acelerando o projeto.

Agora, a questão é esta:

Como devemos controlar o controle de versão aqui?

Devemos criar uma nova ramificação para v1.0e manter a versão 1.0do software lá e desenvolver em algumas ramificações (ou não), fundi-las com master, ir ao vivo com a versão 1.1?

Existe convenção por aí para esse tipo de situação?

— tugberk
fonte

Respostas:

Encontrei (e comecei a adotar) o seguinte modelo de filial :

Imagem de nvie.com

^{(imagem do artigo)}

Existem muitas práticas excelentes e regras estritas descritas nesse artigo, eu recomendo.

Pontos de interesse:

O ramo principal é onde você codifica suas versões. Nenhum desenvolvimento acontece aqui. No caso de um bug implantado na produção, você o corrige em uma ramificação de hotfix, volta e marca uma nova versão.
O desenvolvimento acontece nos ramos de desenvolvimento e recursos. Pessoalmente, faço correções de bugs no ramo devel e recursos nos ramos de recursos.
Quando o software começa a chegar a uma versão, eu ramifico para lançar a ramificação. O ramo de lançamento é onde eu faço os retoques finais. Bump números de versão, alterar metadados etc. E pequenas correções. Quando terminar, mesclo para dominar, marcar e chamar de versão.
Os dois ramos principais: o mestre é o "ramo sagrado"; sua cabeça é sempre o código de produção mais recente e o desenvolvimento é o ramo noturno; seu HEAD sempre reflete as mais recentes (mas possíveis instáveis) adições ao código.

No seu caso específico, as etapas dependem de quão apressada foi essa versão. Se os recursos foram deixados de fora, eu voltaria ao release de desenvolvimento e faria tudo novamente. Se houver erros na versão implantada, gostaria de ramificar para um ramo de hotfix, corrigi-los, mesclar novamente e marcar a v1.1. Se são os dois, eu corrigi os erros primeiro e depois adicionei os recursos conforme descrito.

— Tamás Szelei
fonte

Muito informativo e detalhado. E também uma prática perfeita. Também faz muito sentido. Ter mestre para o produto apenas facilita a manutenção. Não estou familiarizado com a marcação de uma ramificação (ou confirmação?). Você pode me dar alguns detalhes sobre isso? como podemos fazer de acordo com o modelo acima?

— tugberk

No git, o alvo da marcação é um commit. Isso significa que você diz: "aqui está esse commit, e eu chamo de 'v1.3' a partir de agora". Na prática, isso significa que você alterna para o ramo principal, mescla no ramo de desenvolvimento (agora estável), confirme e marque. Em seguida, você pode listar todas as tags, reverter para esse código, caso precise ver o que entrou em produção em uma versão anterior. Há um pouco mais de tags do que isso (o que é útil para o desenvolvimento distribuído em larga escala, como o kernel do linux). Se você estiver interessado, sugiro o livro progit .

— Tamás Szelei

O ProGit é um dos livros que definitivamente vou ler do zero. Por enquanto, estou apenas lendo as partes que estou interessado em fazer o trabalho. Até agora, desenvolvemos no ramo principal e acho que devo manter isso. Mas vou abrir outro ramo chamado productione usá-lo como masterramo de acordo com o modelo acima.

— tugberk

Enquanto estou experimentando esse modelo, uma coisa que estou enfrentando é a seguinte: existem alguns ramos de suporte, conforme discutido no artigo, ramos de recursos e versões. pode haver várias ramificações futuras. Por exemplo, FeedbackForm é uma ramificação futura e ContactForm é outra. Isso está ok para este modelo, eu acho? Também deve haver vários ramos de lançamento? e se sim, como devo nomeá-los?

— tugberk

Primeiro de tudo, você não precisa segui-lo à risca, apenas estabeleceu regras que você mantém. Faça o que for melhor para você e para o estilo de sua equipe. Segundo, sim, vários ramos de recursos e versões são normais, a menos que você tenha um projeto de curta duração com um recurso e uma versão :). A nomeação, de acordo com o artigo, é release- * e feature- *. Eu acho que você colocou o número da versão futura no lugar do asterisco para o lançamento e a identificação do rastreador de problemas no caso de ramificações do recurso.

— Tamás Szelei

O que eu testemunhei na maioria das vezes é:

Master é para você produto. Eventualmente, toda a sua versão futura x.0 estará no master.
Você cria uma tag / ramificação para cada versão em produção, para poder apoiá-las para qualquer cliente que precise.
A mesclagem de correções de uma ou de outra é para lidar caso a caso.

— xsace
fonte

obrigado! então você acha que é razoável manter um ramo chamado v1.0, v1.2 é razoável?

— tugberk

@tugberk Enquanto o software correspondente existir nessa versão, faz sentido manter as ramificações por perto, para que você possa separá-las rapidamente se precisar de uma ramificação de hotfix específica. Quando o software não existe mais nessa versão (não é mais suportado para que não haja mais trabalho), pode fazer sentido fazer uma mesclagem final da ramificação e excluí-la. Você pode até criar uma confirmação final vazia (eu faço isso frequentemente no início da ramificação), apenas para dizer "Fechando ramificação XXXX", caso contrário você não manterá o histórico da ramificação (o reflog pode ajudar um pouco, mas isso é por repositório)

— Patrick Mevzek 13/11/19