Esta é uma publicação de convidado de Matt Shelton, da Nuance Healthcare. Esta é a primeira publicação de uma série sobre a mudança da sua equipe do Subversion para o Git, o motivo da mudança e o que foi encontrado ao longo do caminho. Matt também falou sobre esse tópico no Atlassian Summit 2015. Esta série vai mostrar tudo o que ele não pôde dizer em sua palestra de 30 minutos, com mais contexto.

Então, a gente está migrando para o Git e gosta do git-flow. E agora? Hora de testar tudo! Minha equipe é ótima. Eles reuniram uma lista de resultados de fluxos de trabalho de desenvolvedores no Confluence, tudo baseado no que a gente estava fazendo como equipe e em todas as coisas estranhas que eles pensaram que a gente poderia ter que fazer no futuro. Então, em uma estrutura de projeto que espelhava a que a gente tinha (mas sem código nela — apenas um pom.xml), testaram todos os fluxos de trabalho.

Os fluxos de trabalho de DVCS (sistema de controle de versão distribuído) empresariais estão se estabelecendo e os padrões se consolidando. A flexibilidade que o Git oferece às equipes é tão ampla que, mesmo dentro de uma única empresa, equipes diferentes podem usar abordagens diversas para compartilhamento e colaboração de código.

Existem muitos e também alguns guias úteis sobre como manter suas bifurcações atualizadas em relação aos repositórios upstream (e se você está se perguntando por que gostaria de usar bifurcações em um ambiente corporativo, confira alguns motivos aqui). Neste blog, vou apresentar alguns aspectos de como a bifurcação interage com o upstream: o básico, as pegadinhas e uma dica legal. Para completar, vou fazer você ficar com muita inveja, ou muito ansioso, a escolha é sua. Gostou? Leia mais.

Após o lançamento do Git 2.0.0 há dois meses e meio, a gente recebeu uma nova versão secundária do Git, 2.1.0, com uma série de novos recursos interessantes!

Incluir submódulos como parte do desenvolvimento do Git permite que você inclua outros projetos em sua base de código, mantendo o histórico deles separado, mas sincronizado com o seu. É uma maneira conveniente de resolver a biblioteca do fornecedor e os problemas de dependência. Como de costume com tudo do git, a abordagem é opinativa e incentiva um pouco de estudo antes que possa ser usada com proficiência. Já existem informações boas e detalhadas sobre os submódulos, então não vou repetir o que já foi dito. O que vou fazer aqui é compartilhar algumas coisas interessantes que vão ajudar você a aproveitar ao máximo esse recurso.

A pergunta é simples: em uma equipe de software que usa git e ramificação de recursos, qual é a melhor maneira de incorporar o trabalho finalizado de volta à linha principal de desenvolvimento? É um daqueles debates recorrentes em que ambos os lados têm opiniões fortes, e conversas conscientes às vezes podem ser difíceis (para outros exemplos de debates acalorados, consulte: A Internet).

Hoje em dia, aplicar uma correção a um projeto é tão fácil quanto criar uma bifurcação (que evoca uma cópia remota completa do projeto para você hackear): é só selecionar o arquivo que quer alterar, pressionar Editar e fazer o commit das correções.

Imagine as seguintes questões. Como você lida com as dependências do projeto com o git? O projeto é composto por vários repositórios interdependentes. No momento, eles são gerenciados com svn:externals. Qual é a melhor maneira de lidar com esse caso com o git? Como você divide um repositório muito grande em componentes menores usando o git? Estes são alguns exemplos das perguntas mais frequentes que a gente recebeu na etapa europeia do tour Getting Git Right.

Muitas equipes já migraram para o git e muitas outras estão fazendo a transição agora. Além de treinar desenvolvedores individuais e nomear Entusiastas para ajudar na adoção, é essencial escolher uma prática de colaboração de código simples e agradável que não complique muito as coisas. Com o git, com certeza é possível conjurar fluxos de trabalho muito complicados, eu vi casos assim em primeira mão.

Antes de entrar na Atlassian, eu estava trabalhando em vários projetos que ainda usavam o Subversion (SVN) como seu sistema de controle de versão. Eu já havia mudado para o Git anos antes e queria continuar usando esse sistema o máximo possível.