Git makes software development, well, easier

Three tips to make Git fit into your agile workflow (and vice versa)

Laura Daly Laura Daly

Git is the de facto standard for agile software development when it comes to version control systems. This well-supported open source project is flexible enough to support a range of workflows that suit the needs of any given software team. Its distributed -- rather than centralized – nature gives it superior performance characteristics and allows developers the freedom to experiment locally and publish their changes only when they're ready for distribution to the team.

Além dos benefícios da flexibilidade e da distribuição, há funções fundamentais do Git que dão suporte e aprimoram o desenvolvimento ágil. Pense no Git como um componente do desenvolvimento ágil. As alterações podem ser movidas pelo pipeline de implementação mais rapidamente do que ao trabalhar com liberações monolíticas e sistemas de controle de versão centralizados. O Git trabalha do modo que a equipe trabalha (e deve se esforçar para trabalhar). 

Pro Tip:

Git is Distributed Version Control System (DVCS). Unlike CVS or Subversion (SVN) repositories, Git allows developers to create their own, personal copy of the team's repository, hosted alongside the main codebase. These copies are called forks and when work is complete on a fork, it's easy to bring changes back to the main codebase.

Ramificação Git | Coach Agile Atlassian

Tip 1: Start thinking about tasks as Git branches

Git comes into play after features have been fleshed out, added to a product roadmap, and the development team is ready. But to take a step back here is a quick crash course in agile feature development: product, design, quality assurance (QA), and engineering hold a feature kick-off meeting to come up with a shared understanding of what a feature will be (think requirements), scope of the project, and what tasks that the feature needs to be broken down into to complete it. These tasks – are also known as user stories – are then assigned to individual developers.

Git starts fitting into your agile workflow at this point. At Atlassian, we create a new branch for every single issue. Whether it's a new feature, a bug fix, or a small improvement to some existing code, every code change gets its own branch.

A ramificação é simples e permite que as equipes colaborem facilmente dentro de uma base de código central. Quando um desenvolvedor cria uma ramificação, ele tem, efetivamente, sua própria versão isolada da base de código na qual fazer alterações. Para uma equipe ágil isso significa que, ao dividir recursos em histórias de usuários e, depois, em ramificações, a equipe de desenvolvimento tem a capacidade de lidar com tarefas individualmente e trabalhar de modo mais efetivo no mesmo código, mas em repositórios diferentes. Não há duplicação de trabalho, pois as pessoas conseguem se focar em partes pequenas de trabalho em repositórios separados do repositório principal, não havendo tantas dependências reduzindo a velocidade do processo de desenvolvimento.  

Pro Tip:

Há outros tipos de ramificação Git além da ramificação de tarefa e eles não são mutuamente exclusivos. É possível criar ramificações para uma liberação, por exemplo. Isso permite que os desenvolvedores estabilizem e melhorem o trabalho programado para uma liberação específica, sem a necessidade de esperar outros desenvolvedores que estão trabalhando em liberações futuras.

 

Assim que tiver criado uma ramificação de liberação, será necessário mesclá-la regularmente em sua ramificação principal para garantir que seu recurso seja usado em liberações futuras. Para minimizar a sobrecarga, é melhor criar a ramificação de liberação o mais próximo possível da data programada para a liberação. 

Visão detalhada da ramificação Git | Coach Agile Atlassian

Dica 2: várias ramificações são testáveis individualmente, então aproveite

Assim que as ramificações são consideradas concluídas e prontas para as revisões de código, o Git executa outra função principal em um fluxo de trabalho de desenvolvimento ágil: o teste. As equipes ágeis bem-sucedidas realizam revisões de código e configuram testes automatizados (integração contínua ou desenvolvimento contínuo). Para ajudar com o teste e as revisões de código, os desenvolvedores podem notificar facilmente o restante da equipe de que a ramificação está pronta para revisão e que precisa ser revisada por meio de uma solicitação pull. De modo mais simples, uma solicitação pull é um modo de pedir que outro gerente mescle suas ramificações na ramificação principal e de que tudo esteja pronto para o teste.

Com as ferramentas certas, seu servidor de integração contínua pode compilar e testar suas solicitações pull antes da mesclagem. Isso proporciona confiança de que sua mesclagem não terá problemas. Essa confiança facilita o redirecionamento de correções de erros e conflitos em geral, pois o Git sabe a diferença entre ramificação e código principal, pois as ramificações divergiram. 

Pro Tip:

A long running feature branch that is not merged to the master branch may hurt your ability to be agile and iterate. If you have a long running feature branch remember that you effectively have two divergent versions of your code base, which will result is more bug fixes and conflicts. But the best solution is to have short-lived feature branches. This can be achieved through decomposing user stories into smaller tasks, careful sprint planning, and merging code early to ship as dark features. 

Dica 3: o Git fornece transparência e qualidade ao desenvolvimento ágil

The Git/agile story is one about efficiency, testing, automation, and overall agility. Once you’ve merged a branch to the master branch, your agile workflow is done. Likewise, merging code through pull requests means that when code is done, you have the documentation to confidently know that your work is green, that other team members have signed off on the code, and that it is ready to release. This keeps agile teams moving at a speed and with confidence to release often: a sign of a great agile team.

Pro Tip:

Adotar uma frequência regular de liberação é fundamental para o desenvolvimento ágil. Para fazer o Git funcionar em seu fluxo de trabalho ágil, é necessário garantir que sua ramificação principal esteja sempre verde. Isso significa que, se um recurso não estiver pronto, você deve esperar até a próxima liberação. Se praticar ciclos de liberação mais curtos, isso não será um problema.