dúvida em Branching com Git Flow

[lucassena]

Galera, eu estou começando a usar o Git Flow agora, mas fiquei na dúvida, pois até então a cada feature nova eu criava a partir do master git checkout -b nova-feature.

Mas agora com o Git Flow, parece que ele gera o branch a partir do develop?!? 🤔

Summary of actions:
- A new branch 'feature/dashboard-improvements' was created, based on 'develop'
- You are now on branch 'feature/dashboard-improvements'

Está correto isso? configurei algo errado ou eu que sempre estive errado?

Pois na minha visão, quando você quer criar um branch novo, vc cria a partir do master para mesclar no develop para colocar em Stage e se estiver tudo ok, vc mescla no master. E o develop poderia ter vários branches que ainda não foram aprovados tbm.

Agradeço a atenção,

[wilcorrea]

Olá @lucassena o comportamento que você obteve é o que a ferramenta faz mesmo.

Dá uma olhada nesse mini guia https://danielkummer.github.io/git-flow-cheatsheet/

Por ser baseado em métodos ágeis o git flow espera que você desenvolva e teste cada branch, para em seguida ela ser enviada para a develop (que nunca pode estar quebrada). Em qualquer momento você pode criar uma release (algo como uma RC) e realizar testes de integração nessa fase.

Estando tudo ok, a release é publicada, uma nova tag é criada e a nova versão da master pode seguir para o deploy : )

[lucassena]

Fala @wilcorrea , atualmente, sem utilizar o Git Flow, tenho 2 branches principais: master e develop

Então, sem git flow, usamos o develop como um branch onde seria mesclado todos os branches que precisariam passar pelo nosso ambiente de Stage. Então quando alguém da um merge no develop, ele automaticamente sobe para o Stage. Quando a feature é aprovada, nós mesclamos a branch no master que também faz um deploy automático para Production.

Agora, usando o Git Flow, quando eu executar git flow feature finish MYFEATURE ele irá mesclar apenas no meu develop local, certo?

Quando eu executar git flow feature publish MYFEATURE ele irá para origin/develop?

[wilcorrea]

Na realidade o git flow feature publish MYFEATURE vai apenas fazer um push dela pra origin

[wilcorrea]

Já o comando git flow feature finish MYFEATURE fecha a feature e mescla na develop

[paulofreitas]

Só complementando, o Vincent Driessen tem um excelente artigo chamado A successful Git branching model que demonstra de forma excepcional o funcionamento do workflow Gitflow através do uso normal do git sem a extensão git-flow. Vale a pena estar dando uma conferida, os diagramas são excelentes! 😀

A Atlassian também tem um guia tão bom quanto sobre o Gitflow aqui: Comparing workflows: Gitflow workflow

No Gitflow os feature branches são de fato baseados no branch develop. Neste workflow o branch master representa sempre o estado de produção da aplicação enquanto o branch develop representa sempre o estado das últimas features entregues para o próximo release. O artigo do Vincent te ajudará a entender melhor essa separação. 😄

Note que você não estava fazendo "errado", você só estava usando outro workflow, uma variação do Feature branch workflow. Criar os feature branches à partir do branch develop é uma particularidade do próprio Gitflow. 😉

[aviniciuss]

Quando passei para equipe que trabalho usei esses slides, talvez ajude também.

[lucassena]

Ok, estudei bastante, já entendi o workflow sugerido, mas ainda não sei como posso substituir o meu develop que tinha anteriormente que era usado em Stage para mostrar/testar as novas features.

O que vocês usam e/ou sugerem?

Pensei em criar uma branch features para mesclar o que precisamos testar em Stage.

Sabendo que podem ter grandes mudanças nessas features ainda em fase de testes. Também, podem ter features mais recentes que precisam ser mescladas no master antes de outras mais antigas ou até mesmo podem ter features "canceladas".

Obrigado,

[andreportaro]

Lucas, acho que vai depender do projeto.

Quando no meu emprego anterior, meu chefe e eu discutíamos por vezes sem fim sobre se devíamos ou não ter todas as features no ambiente de staging.

Um dos argumentos contra era:

• e se quisermos publicar o staging, só com as features A e C, e não B (supondo que as três features foram fechadas em staging)?

Ao que o meu argumento era quase sempre o seguinte: se as features A, B e C estão em staging mas não deveriam ser publicadas, onde está o erro? Eu penso que os erros estão muito mais na organização e priorização das tarefas do que no fluxo de versionamento!

Mais uma vez: se no inicio do ciclo planejamos que iriamos subir funcionalidades A, B e C, e agora que estão prontas queremos subir somente A e C, deveríamos dificultar o desenvolvimento, criando branches de features com "grupos" de features?! (branch features_1 terá a combinação das features A e C, branch features_2 as branches B e C... imagina a encrenca na qual vc tá se metendo?!) Para mim fica muito claro que o "gargalo" neste caso não é o gitflow, é no processo (ou falta de processo) de priorização e planejamento dos desenvolvimentos.

Agora vamos lá. Você pode ver que o gitflow não tem ambiente de staging. Só existem duas branches fixas: master (versão de produção) e develop (novas features que já foram fechadas e vão subir no próximo ciclo de deploy)

A única outra branch "fixa" que ele considera é uma branch de release: vocês consideram que o que está em develop está pronto para ser publicado, criam uma branch de release, fazem merge com master, e fazem o debug nesta branch. neste momento, seu ambiente de staging poderia estar virado para esta branch.

No momento em que o release é merjado em master, a sua branch deveria parar de existir, e este release passa a ser uma tag. Master é mesclado de volta com develop, de modo que ambos fiquem idênticos. Após o fechamento da release, minha opinião é que o ambiente de staging deva ser um reflexo de master, e estar inclusive virado para a mesma branch. deveria ser um espelho exato.

Se você quer um ambiente "bleeding edge", vc pode liberar um ambiente "dev" que fica virado para a branch develop e contem a versão com os desenvolvimentos mais recentes.

Em 3 de julho de 2017 12:49, Lucas Martins notifications@github.com escreveu:

Ok, estudei bastante, já entendi o workflow sugerido, mas ainda não sei como posso substituir o meu develop que tinha anteriormente que era usado em Stage para mostrar/testar as novas features.

O que vocês usam e/ou sugerem?

Pensei em criar uma branch features para mesclar o que precisamos testar em Stage.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/laravelbrasil/forum/issues/115#issuecomment-312680596, or mute the thread https://github.com/notifications/unsubscribe-auth/AFObijyxQcB3bq8vGfFRQABsa8eLJqZUks5sKQ2ngaJpZM4OLAB3 .

-- André Portaro Tzermias 55 12 9 9653 1200

[lucassena]

Valeu @andreportaro pelos seus pontos.

O que realmente preciso, é simplesmente de um branch central onde a equipe de desenvolvimento mesclaria suas features nele, para que este branch seja clonado no ambiente de Stage nosso.

A necessidade disso é, além da feature passar por uma análise e testes para ser aprovada, termos a liberdade de subir uma feature testada em momentos diferentes. Uma feature pode ser extremamente importante e outra que está passando por alterações ainda pode ir para Production daqui 1 semana por exemplo.

[wilcorrea]

@lucassena trabalho numa empresa onde temos exatamente esse modelo. Vou tentar descrever brevemente o processo que usamos há mais de um ano e que está rodando liso.

Nosso repositório central é o Gitlab e lá temos a opção de gerenciar Milestones, Issues e Boards. A ferramenta usada na empresa para gerenciar tickets e demandas é o GLPI onde existe os conceitos do ITIL de Changes, Problems e Projects.

Para poder termos uma sincronia entre os dois coletamos changes e problems no GLPI e criamos os projects. No Gitlab criamos Milestones que equivalem semanticamente aos projects e adicionamos issues as milestones para configurá-las da mesma forma que o project correspondente.

Sendo assim criamos uma branch para cada milestone e começamos a codar. Por questão de aproveitamento de ferramenta usamos o recurso de Git Flow do Smargit para prover acesso rápido ao "Integrate Develop" que a ferramenta possui. Se parar para analisar na realidade não trabalhamos com features. Trabalhamos com projects que precisam ser realizados, analisados, testados, ou seja, ter todo o seu clico de vida realizado, antes de ser mesclado a develop. Contudo durante o desenvolvimento de um project é preciso fazer "merge" do que vai sendo produzido enquanto um desses projetos está em andamento, apenas por isso o uso do Git Flow; para poder usar uma ferramenta que simplifique o processo.

Quando uma "feature" dessas é aprovada, o analista a fecha, junta com a develop, e em seguida cria uma release, (que também é apenas para cumprir o protocolo da ferramenta) criando a versão que será enviada para deploy : )

Esse processo de finalização notifica todo mundo, encerra os tickets e é isso. Funciona muito bem numa equipe de 4 a 6 devs e temos amadurecido esse processo praticamente nos últimos 2 anos.

[lucassena]

@wilcorrea, legal, mas vocês tem um "main" branch que é usado para ficar em um ambiente de Stage então, onde tudo é mesclado para testar?

[wilcorrea]

Sim, temos lá algo develop, master, /feature/milestone/[0-9], e, temos um ambiente de stage automatizado onde com um push a branch "feature" cria um sistema para homologação. Na prática temos vários sistemas rodando no staging simultaneamente sendo apreciados e validados pelo QA e pelos setores que demandaram as solicitações.

[lucassena]

Show! Era mais ou menos o que eu tinha pensado mesmo.

Vou conversar aqui com os desenvolvedores e chegar em algo mais consistente.

Valeu à todos!