Melhorar Fluxo Git

[marcusvcribeiro]

Olá Galera, estou com um problema no trabalho e tenho que achar uma alternativa para melhorar o fluxo de trabalho.

O que está acontecendo, Tenho um ambiente com jenkins+Git automatizado, porem o que acontece aqui é o seguinte, como o projeto é antigo, nao consigo colocar um gitflow para melhorar o fluxo, pois aqui temos a Master, Homolog e as Branchs, só que quando temos o merge das branchs com a Homolog, sao criadas Tags para cada Branch, o problema disso é que como temos uma quantidade grande de desenvolvedores, alguns arquivos acabam sendo sobreescritos em alguns merges, pois a quantidade de merge é gigantesca tambem.
Queria dicas para solucionar esse problema, pois o gitflow seria perfeito, só que nao consigo implantar, pois existe uma defasagem de Branch gigantescas, pois tem branch numero 18 sendo desenvolvida e branch numero 1070 sendo desenvolvida ao mesmo tempo.

[jmurowaniecki]

Daê @marcusvcribeiro, tranquilo?

Tchê, tem bastante material disponível, acredito que esse aqui sirva bem ao teu propósito.

Mas em síntese, uma ramificação que esteja em progresso deve receber atualizações da sua branch de origem/destino - tanto no intuito de minimizar conflitos futuros quanto de aproveitar os fixes realizados no ambiente enquanto a feature vai sendo desenvolvida - resolvendo dessa forma os problemas de conflito na própria ramificação da feature.

Background: recentemente passamos por turbulência referente ao fato de um cliente não flexibilizar e adotar uma cultura de versionamento e entregas organizadas - realizando deploys por FTP, movendo pastas inteiras para os ambientes de homologação e produção.
Além do fato de que os ambientes não estavam devidamente acompanhando o histórico do repositório - muitos códigos/recursos em produção não estavam sequer versionados o que acabou por comprometer seriamente uma entrega grande gerada por uma pequena demanda.

A solução, no fim das contas, foi versionar o código do ambiente de produção como master e assumir ele como novo HEAD e daí então realizar o merge com as features pretendidas.

O resultado foi que muita coisa ainda assim foi perdida - algumas tarefas realizadas no passado voltaram, foi necessário refazer alguma coisa (ou recuperar no repositório) e a tensão com o time do cliente aumentou consideravelmente visto termos implantado a força deploy automatizado e versionamento dos ambientes.

"Toda mudança de cultura em um ambiente indisposto é dolorosa - e quem vai sentir a martelada mais forte vai ser, com toda certeza, quem deu início e fim ao processo."

[rsmelo]

Dae @marcusvcribeiro,
já passei por problema parecido a uns anos atrás, na empresa onde trabalho. Migramos de um SVN onde nem se usava feature branches para hoje estar no git, rodando gitflow em todos os projetos.
Todo esse processo pra todo mundo usar demorou mais de um ano, desde a saida do svn até a adoção total do gitflow.
Acontece que a maior parte do problema não está na ferramenta utilizada e sim fazer o pessoal seguir o padrão definido, no caso o gitflow. Pra isso uma das abordagens foi ministrar um treinamento interno pra ensinar o pessoal como funciona e também pro pessoal conseguir compreender os benefícios da mudança. Um material bacana pra passar pra quem ainda não entende muito dos workflows é o da Atlassian https://www.atlassian.com/git/tutorials/comparing-workflows, esse material explica de forma bem didática (na minha opinião).
Agora focando na parte pratica, tem algumas coisas que podem te ajudar a reduzir o numero de conflitos.
Você já usa feature branch, então boa parte do problema você já resolveu. Como o @jmurowaniecki citou, os feature branches que estão sendo desenvolvidos devem receber merge do develop sempre que possível, desse modo reduzindo o impacto que seria caso você fosse fazer esse merge develop > feature branch apenas no final do desenvolvimento da funcionalidade.
Outra pratica que ajuda é a utilização de branches de Hotfix, que ajudam a propagar a correção de bugs para o develop e master de forma mais organizada.
Optar pelo versionamento semântico (http://semver.org/) também ajuda a longo prazo, facilitando saber qual o nível de impacto das versões no software como um todo.
Outro ponto importante é ter alguém responsável para ajudar as pessoas quando elas enfrentarem problemas com o git, seja algum conflito ou duvidas de como executar o gitflow corretamente. Tentando evitar que os problemas ocorram ao invés de tentar consertar após já ter dado problema.
No mais acho que vai do dia a dia você identificar quais barreiras o pessoal está tendo para seguir o workflow, se é esquecimento de fazer merges frequentes, ou falta de conhecimento do flow etc.

[dougaraujos]

@marcusvcribeiro, assim que eu tiver um tempo vou compartilhar nossa experiência aqui.

[marcusvcribeiro]

Então @rsmelo , estava pensando em ensinar o pessoal a usar REBASE até achar um solução adequada para isso.
Porque um dos problemas em ministrar palestras para o pessoal aprender é que não é somente 1 empresa no projeto, são varias. A ideia é achar uma saída para poder colocar o gitflow, porque do jeito que está, estamos tendo que fazer merge de arquivo por arquivo para ver se nao deu alguma coisa, nao consigo fazer um merge request de varios arquivos, pois quase sempre da alguma treta sinistra.
Com o rebase, a pessoa teria que solucionar os problemas, pois diferente do merge que joga a alteração na frente de tudo, o rebase joga atras e confere os merge da frente, se tiver ok, ele joga na frente, pelo menos é isso que eu acho que é. rsrs

@dougaraujos Pois nao esqueça de compartilhar rsrs.

Querendo ou não, nem todos os profissionais sabem usar o git afundo, só sabem o basico do basico. Muito raramente sabem o que um stash faz rsrs.

[rsmelo]

@marcusvcribeiro pois é, infelizmente é comum o pessoal não ter total compreensão do que tá fazendo e acabar fazendo algo errado. Tentar nivelar o conhecimento acho que é uma das formas de evitar isso.

Outra abordagem que não sei se se aplica ao seu caso, seria só ter merge de features no develop através de Pull request, é bem mais burocrático, já que alguém tem que fazer o review etc. Porem você conseguiria evitar de alguem quebrar o develop e master. Desse modo nem todo mundo teria acesso para commitar em develop, o que já dá uma certa segurança de integridade se usado corretamente.

Aqui já tentamos usar PR (na verdade merge request, pois usamos gitlab, mas são equivalente). Só que vimos que acaba atrasando o processo, já que o PR fica aguardando o review e aprovação. Dai vai de cada caso, aqui ainda pretendemos usar no futuro, você teria que analisar a situação ai.