Git flow.

eyeglasses in front of laptop computer

Foto por Christina Morillo em Pexels.com

Não basta ter códigos bem organizados e limpos, é necessário ter um versionamento dos seus códigos bem organizados.

Utilizando o método de versionamento Git Flow combinado com o versionamento semântico (Link sobre versionamento semântico) podemos organizar nossos códigos evitando problemas de deploy ou confusão de versionamento.

Principalmente quando estamos trabalhando em equipe, acontece muitas vezes uma certa confusão do que cada um está fazendo e muitas vezes essas confusões ocasionam em retrabalho.

Por essa e outras razões, é muito recomendado trabalhar utilizando o Git Flow.

Utilizando Git Flow, você vai reparar rapidamente que a produtividade vai aumentar e o trabalho em equipe fica muito mais organizado.

Como funciona o Git Flow.

Já percebeu que esse padrão de versionamento é muito importante para os nossos projetos, mas como ele funciona?

Antes, precisamos identificar algumas chaves importantes para utilizar o Git Flow.

Essas chaves importantes são as Branches. Elas devem ser definidas em develop, feature, bugfix, release, hotfix e master.

  • develop: é onde o código mais atual deve estar versionado e é a origem para as ramificações da branch feature;
  • feature: ramificações para criação de novas capacidades;
  • bugfix: essa ramificação deve ser utilizado somente para correção de problemas encontrados nas branches de develop ou release;
  • release: ramificação de lançamento, essa branch deve ser fundida com a versão de develop quando esse estiver finalizada, a branch de release geralmente é utilizada para disponibilizar para homologação antes de ir para produção;
  • master: versão estável que deve ser fundida com a branch de release quando essa estiver homologada;
  • hotfix: essa branch é criada a partir da branch master e é utilizada para correção de bugs de produção, após feita a correção ela deve ser fundida novamente com a branch master e com a develop e essa com a release.

O fluxo deve seguir essa trilha e sempre utilizando o versionamento semântico.

A origem das branches features devem sempre ter como origem a branch de develop, assim os integrantes do time sempre trabalham com o código mais atualizado.

Assim que uma branch de feature e/ou bugfix são finalizados, essas branches devem ser fundidas com a branch de develop.

O passo seguinte é fundir a branch de develop a branch de release e disponibilizar para testes em homologação.

Assim que a branch de release é homologada, a mesma deve ser fundida para a branch master e disponibilizar o sistema para produção.

Caso haja algum bug em produção, é criado de forma emergencial uma branch hotfix a partir da master para correção rápida e logo após a correção é fundida novamente para branch master e para develop.

Conclusão.

Podemos organizar os nossos projetos para evitar retrabalho ou até mesmo um problema de produção quando utilizamos fluxo de versionamento Git Flow. Mesmo que esteja trabalhando sozinho, é uma boa prática utilizar essa metodologia.

Microsoft compra Github, e agora?

Dia 4 de junho de 2018 a Microsoft compra o Github, o valor da compra foi especulado em cerca de US$ 7,5 bi.

Isso fez um barulho e desagradou uma grande parte da comunidade de programadores.

Essa revolta deve-se a incertezas sobre o futuro da ferramenta, mudanças de uso, licença e até sobre alterações na ferramenta.

Segundo a Microsoft, o Github vai continuar do mesmo jeito que era antes da compra.

O motivo da compra ainda é um mistério, mas bem provável seja para absorver os usuários do Github.

Motivo para pânico?

Na minha opinião não. A Microsoft deixou bem claro que não vai mudar as políticas de uso, isso quer dizer que nada vai mudar quanto ao modelo de negócio atual.

Além disso, quando a Microsoft comprou o LinkedIn, a plataforma melhorou muito.

Outro fator positivo é o grande número de produtos Open Source da Microsoft como .Net Framework, Visual Studio Code, Typescript, Xamarin, Kinect, entre outros.

Mesmo assim, se ainda tem dúvidas sobre o futuro do Github, temos a outras opções para migração de ferramenta como Gitlab, Bitbucket, SourceForge, Launchpad e Apache Allura.

Conclusão.

Na minha opinião não há motivos para pânico e migração para outra ferramenta somente pelo motivo da compra do Github pela Microsoft. Além disso as novas políticas da Microsoft me agradam muito e acho que sejam melhores que as políticas duvidosas como da Oracle, Facebook e Google.

 

Para acessar o conteúdo original: https://nakatech.herokuapp.com/article/github.html