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.

A gente está migrando para o Git e descobriu como usar o git-flow e o Maven juntos em um fluxo de trabalho de desenvolvimento eficiente. Antes de entrar na aparência atual do fluxo de trabalho, é importante saber de onde a gente partiu.

Há 10 anos, Linus Torvalds começou a escrever código para um novo sistema de controle de versão distribuído em um domingo e apenas alguns dias depois, o mundo recebeu o presente do Git.

Recentemente, fiz algumas viagens durante a segunda etapa do tour Getting Git Right. Tem sido incrível conhecer tantos desenvolvedores de todo o mundo. Tem sido particularmente incrível ver o quanto a adoção do Git cresceu entre os participantes nos poucos meses desde a primeira etapa do tour. Na apresentação de julho, quase todos os participantes levantaram a mão quando a gente perguntou "Quem está usando o Git?"

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).

O git é uma escolha fantástica para acompanhar a evolução da sua base de código e colaborar de forma eficiente com seus colegas. Mas o que acontece quando o repositório que você quer rastrear é muito grande?

A Internet está repleta de artigos sobre por que você não deve usar os submódulos do Git. Eu concordo com quase tudo, embora eu não seja tão duro na minha avaliação. Como expliquei em uma publicação anterior, os submódulos são úteis para alguns casos de uso, mas têm várias desvantagens.

Enquanto o Mercurial tem uma API bem definida (embora interna) que pode ser usada para escrever extensões que ampliam a funcionalidade do Mercurial, o modelo de extensão do Git segue a filosofia Unix de compor programas pequenos e simples para obter um efeito semelhante. Ou seja: as "extensões" do Git podem ser escritas em qualquer linguagem, e, seguindo algumas regras simples, ainda é possível adicionar comandos que aparecem como se fossem integrados.

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.

O git é uma ferramenta avançada. Ele apresenta uma filosofia valiosa para mim: tratar os desenvolvedores como pessoas inteligentes e responsáveis. Ou seja: você tem muito poder nas suas mãos. Inclusive o poder de dar um tiro no próprio pé (certamente com um colete de titânio, mas atirar em si mesmo assim).

O webinar recente que a gente fez com as estrelas de produtos Jens Schumacher e Ken Olofsen deu uma ótima visão geral dos fluxos de trabalho do git. Os fluxos de trabalho de ramificação vão de simples a complexos, robustos e defensivos. Qual é o nível de complexidade e proteção necessário para sua empresa? Esta publicação aborda o ajuste entre agilidade e robustez, com algumas diretrizes para escolher sua própria aventura git e lições aprendidas dentro da Atlassian.

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.

Adoro vasculhar as notas de lançamento das minhas ferramentas favoritas em busca de preciosidades escondidas (ou não tão escondidas). É um pouco como o Natal. Eu tenho aquela sensação agradável de expectativa e curiosidade quando são lançadas novas versões do meu fiel gerenciador de janelas de código aberto OSX Slate, no Rails, no Django, no CoffeeScript e, claro, no Git e muitos outros.

Seja usando git na linha de comando ou por meio de uma ferramenta que você escolha, como o Sourcetree; seja hospedando seu código no Bitbucket Cloud ou no Stash (agora chamado de Bitbucket Server) atrás do firewall da sua empresa — se você for como eu, hehe, é sempre uma festa quando uma nova versão do git sai.

Enquanto o próximo grande lançamento do git, que vai trazer algumas atualizações relevantes, não chega, a gente pode explorar as notas do último lançamento pontual: o 1.8.5 está chegando!

Sei que vocês estão ocupados com maratonas de saques no DayZ, mas tenham paciência comigo. Vale a pena conferir algo hoje. A última versão pontual do git (1.9) foi lançada!

Este grande lançamento do git está sendo produzido há muito tempo, e estou animado para ir à caça no Changelog para encontrar coisas incríveis. Como de costume, se você quiser acompanhar as versões anteriores do git, eu faço esse exercício há um tempo, confira: 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.9.