Sobre Git Workflow

[dougaraujos]

Galera que usa GIT para versionamento, qual o seu workflow atual?

Implementei há 1 ano atrás um workflow baseado nesse Git Branching Model e algumas adaptações serão necessárias. Gostaria de conhecer outras implementações.

[felquis]

Uso uma branch development que é a branch principal do projeto, vários branchs derivadas de features e correções que posteriormente quando completas são mergiadas na development, quando a development está pronta para produção após os testes de qualidade, fazemos um merge da branch development na master, e é criada uma tag desse deploy/envio há produção.

Uso apenas isso, quando há complicações, meu workflow gira em turno dos comandos git reflog, git reset, git rebase, git merge, git checkout, git add, git commit.

Também uso o GitHub Client no Mac, para facilitar a visualização de diffs e para fazer commits parciais de arquivos.

[willycamargo]

Faço das palavras do @felquis as minhas, com excessão do GitHub Client que não usamos por aqui. Mas usamos o SourceTree com a mesma finalidade (Bitbucket - Atlassian).

[felipefialho]

Perfeito seu workflow @felquis

[dougaraujos]

Bom, utilizo o mesmo fluxo, mas a minha treta é um pouco específica. Vou tentar explanar:

O problema é que temos vários devs trabalhando ao mesmo tempo, e nem sempre as features são testadas e liberadas na ordem que foram finalizadas (mergeadas no branch develop). Sendo assim, algumas features não serão implementadas no mesmo release, mesmo que já estejam no develop antes de outras. Só que nesse fluxo atual, não existe uma maneira simples para criar um release, já que preciso de commits de merge de algumas features isoladas.

A minha ideia inicial era implementar um pull request para o branch develop, manter o branch da feature ativo até que o teste seja realizado (no branch do release). Logo que concluisse, o branch do release seria mergeado no master e no develop, e o branch da feature seria excluído.

Não sei se ficou claro a treta, mas agradeço as contribuições!

[bernardodiasc]

Alguns projetos chamam o branch develop de integration, que é o branch que recebe os trabalhos dos outros devs. O processo é o mesmo que o @felquis comentou.

Uma dica é ter uma issue associada ao branch de trabalho, onde contém mais informações sobre a demanda e como ele irá ser solucionada, onde outros devs podem trocar ideias sobre aquele trabalho, dessa forma cada branch tem um proposito e depois que foi pro master e resolveu a issue, fecha a issue e apaga o branch (no caso de não usar forks).

Costumo tambem usar nomemclatura upstream e origin, sendo origin o meu fork e upstream o repo original (eh pois eh). Dessa forma sempre mando as paradas no meu fork (origin) e depois que o PR é mesclado no upstream eu mantenho os branchs no meu fork, mas no upstream ficam somente branchs importantes (master, develop e alguma feature especial que mais pessoas estejam trabalhando).

[dougaraujos]

@bernardodiasc Esse fork seria um para cada desenvolvedor ?

[bernardodiasc]

Sim, cada um trabalha no seu fork, o upstream é o oficial onde centraliza tudo.

[dougaraujos]

Entendi, mas no caso de você ter uns 30 projetos e 10 developers, você ficaria com pelo menos 330 repos? (30 forks * 10 developers + 30 upstreams)

[bernardodiasc]

Hmm, é exatamente isso. Mas cada developer gerencia seus próprios forks, então não faz sentido fazer essa somatória por que nem é perceptível esse número. 30 projetos são 30 repos da organização e cada dev com seus 30 forks.

[bernardodiasc]

Note que as issues e wikis são usadas apenas nos upstreams. Ocorre algumas vezes, mas é incomum, de enviar PR de um fork pro outro, quando devs estão colaborando em alguma tarefa, vão somando trabalho até ficar redondo e então abrir o PR para o upstream com o trabalho pronto.

Isso funciona bem pois no upstream ficam apenas os branchs importantes (master, dev, e alguns outros temporários, se for necessario). Dessa forma existe 1 fonte da verdade pra cada projeto.

[lagden]

no meu o master é o dev
os releases são tags do master
e o resto são branch que podem ou não serem mesclados com o master ex. new-features, bug-fix, lab, etc...

[lagden]

faltou...
e fecho issues via commit!

[dougaraujos]

@bernardodiasc
1 - Entendi, e como tem feito o padrão de nomenclatura dos repos, visto que a quantidade é expressiva?

2 - Pela sua experiência com esse fluxo, quais seriam as vantagens/desvantagens de usar o mesmo fluxo, só que ao invés de forks, utilizasse branchs locais, e quando necessário, publicasse o branch para outros developers trabalharem na mesma feature?

@lagden Isso ae, só não consigo utilizar as issues porque elas são centralizadas em outro sistema aonde clientes e outras áreas tem acesso.

[lagden]

@dougaraujos o interessante é tentar levar para o Github via API.
Aqui os programadores utilizam a issue diretamente e o gerente, diretor, etc fica de olho via o https://zube.io/

[bernardodiasc]

1 - Não sei se entendi, o numero não é expressivo. São 30 projetos somente, o fork recebe o mesmo nome, o nome do projeto, simples assim. Esse formato vale pra projetos com organização (me refiro à "org", como empresa por exemplo), se o projeto original é na sua conta não é esse modelo, esse modelo é pra trabalho em equipe ou projetos open sources que possuem organização (org, empresa, centralização). Enquanto dev, você passa longe dos forks dos outros devs a maior parte do tempo. Se voce é mantenedor, ai vai ter que gerenciar o upstream e os seus forks (os seus apenas), são 60 repos no caso, mas na sua maquina são só os 30 projetos cada qual com 2 remotes, ou mais se quiser ter remotes dos outros devs na sua maquina, tranquilamente.

2 - A desvantagem é que é mais lento do que jogar tudo sem controle nenhum em um repo apenas. É mais lento pois adiciona burocracia, burocracia mais que necessaria pra projetos e equipes grandes manterem qualidade no fluxo de trabalho. Já tive que trabalhar jogando código direto no upstream e chega uma hora que fica zuado, vários branchs criados por todo mundo, muito material incompleto no lugar que deveria ser confiável, uns branchs "mortos" mesmo sem mesclar que se dá bobeira o tempo passa e fica super dificil de rastrear se ainda é util, qualquer dev novo da de cara com um monte de coisa desnecessaria para o trabalho dele, entre outros problemas. O que entendi da sua pergunta é sobre ter um repo apenas e só mandar branchs pra lá quando finalizados, certo? Mas e se voce precisar de um peer review de um trabalho incompleto, vai ter que publicar um branch incompleto, no formato de upstream o upstream fica limpinho, voce manda o branch incompleto pro peer review a partir do seu fork, no seu fork pode estar zuando que não afeta a qualidade do trabalho geral.

Faz sentido isso? Nunca consigo explicar bem isso, mas é mais simples do que parece. Se tiver mais duvidas manda ae. :)

[bernardodiasc]

Exemplo, digamos que o projeto é o https://github.com/frontendbr/forum/

Temos frontendbr sendo a organização mantenedora do projeto forum.

Nós dois fazemos forks do projeto forum na nossa conta, então os forks são:

• https://github.com/bernardodiasc/forum/
• https://github.com/dougaraujos/forum/

Na minha máquina vou clonar o meu fork (por padrão o clone cria o remote com nome origin), então adiciono o upstream manualmente em seguida e se quiser posso adicionar o seu fork tambem nos meus remotes (git remote add [nome do remote] [endereço do git]). Ex:

$ git remote -v
origin  [email protected]:bernardodiasc/forum.git (fetch)
origin  [email protected]:bernardodiasc/forum.git (push)
upstream    [email protected]:frontendbr/forum.git (fetch)
upstream    [email protected]:frontendbr/forum.git (push)
dougaraujos [email protected]:dougaraujos/forum.git (fetch)
dougaraujos [email protected]:dougaraujos/forum.git (push)

Sempre que precisar, faço fetch + merge ou rebase do upstream pra ficar sempre com meu local atualizado com o repo principal, onde todo mundo ta jogando código. Posso fazer o mesmo do seu fork se precisar.

Trabalho na minha máquina num determinado branch, mando pro meu fork (git push origin [nome do branch]) e de lá abro um PR para o develop do upstream. Meu branch ta só no meu fork, outros devs não vão ve-lo no upstream, pois no upstream só tem o que precisa ter.

Vai ser comum ter ambientes de publicação (deploy) sincronizados com os branchs no upstream, por exemplo, o que ta no master é o que ta em produção, o que ta no develop é o que ta no staging, e por ai vai. As publicações não ocorrem dos forks e sim do repo principal.

Acho que é isso, tem mais detalhes no workflow, mas essa seria a visão geral da coisa.

[bernardodiasc]

@lagden aqui temos usado o https://waffle.io/, bem legal tambem :)

[dougaraujos]

@lagden Sim, só que usamos o Bitbucket e a escolha das ferramentas foi um consenso de N fatores. Mas concordo que a integração de ambas ferramentas seria essencial.

@bernardodiasc Entendi, ficou claro. A vantagem é o upstream limpo, sem branchs pendentes. Fica bem organizado. Para isso, a única exigência é a cautela, trabalhando com N remotos no mesmo repositório, Assim, é necessário uma maturidade dos developers. Não vejo como problema, muito pelo contrário.

Esse fluxo me agrada. Ainda preciso averiguar com a equipe e dar um check no plano do Bitbucket.
Mas valeu pela grande ajuda!

[felipefialho]

Gostei muito @bernardodiasc.

[tarciozemel]

git-flow. Sempre!

http://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html