Este artigo vai tratar sobre o uso do EGit no Eclipse. O EGit, e sua camada de biblioteca JGit, está em fase de desenvolvimento por muito tempo, e em junho foi lançado como versão 1.0, juntamente com o lançamento do Eclipse Indigo. Esta é a primeira vez que qualquer coisa, fora o CVS, que é enviada, por padrão, sem ser empacotado pelo Eclipse. 

Além de essa ser uma boa notícia para o Git, também é para o Eclipse. A transição em direção ao DVCS tem sido longa, e o EGit é apenas o começo.

Originalmente, o Eclipse era lançado somente com suporte a CVS, mas enquanto plugins adicionais poderiam ser usados para acessar o Subversion, nenhum deles era lançado com o pacote padrão devido a problemas de licenças. Tanto o Subclipse quanto o Subversive precisavam de binários adicionais para funcionar. O fato de o Subclipse não enviar um cliente OSX pré-empacotado, no momento em que o OSX estava ganhando espaço – como o laptop, para conferências e para desenvolvimento,- não ajudou muito seu caso. Até hoje, o Subclipse não é lançado com drivers para Windows 64-bit, e essa é uma plataforma que vem se tornando cada vez mais comum.

O que causou a morte o Eclipse no Subversion foi o Git e o GitHub. Independentemente de quais sejam as suas preferências do (D)VCS, não há dúvida de que o GitHub transformou a indústria ao adotar o DVCS, e mais especificamente, o Git. Não apenas isso, mas com o Eclipse sendo atraído pelo Git, e o Apache lendo apenas os seus espelhos, está claro que a maioria das bases estão se aproximando do suporte para o Git. O código do Google continua isolado com o Hg, em partes, devido a sua implementação em Python – mas, no futuro, o código do Google irá suportar o Git também.

O EGit é o conjunto de bibliotecas Eclipse UI que se integra com a equipe de fornecedores, enquanto se apóia em uma reimplementação do núcleo das bibliotecas Git em Java, JGit. Além de suportar o EGit, o JGit também garante a execução dentro do Gerrit, uma ferramenta popular de revisão, bem como uma porta para o Android na forma de Agit.

Uma das vantagens do JGit é que o formato de disco do Git é bem documentado e compreendido. Na verdade, é esse formato de disco que resultou na maioria das bibliotecas e ferramentas adicionais que estão disponíveis: em vez de ter que chamar por uma biblioteca específica (como fazem o SVN e o Hg), um cliente Git é capaz de criar sua própria árvore de conteúdo em um repositório Git existente. Praticamente toda ferramenta Git lê, processa e gera árvores de objetos e referências para elas.

Usando o EGit

A maior parte dos pacotes de lançamento do Eclipse Indigo já tem o EGit pronto; mas, se não tiver, é fácil ir ao Eclipse Marketplace para fazer o download. Enquanto o Helios enviava com uma versão 0.12 no lançamento do serviço 2, o Indigo envia com a versão 1.0 – apesar de que ela também pode ser instalada durante o tempo de execução fo Helio, se você quiser adicionar o site de atualização ao seu tempo de execução.

Existe muita documentação boa na EGit wiki, o que inclui o Git para usuários do Eclipse, que fornece uma boa base em Git para aqueles que não têm tanto conhecimento. Mas existem, também, muitos exemplos para te mostrar como fazer as coisas direitinho.

Diferentemente dos repositórios CVS/SVN, um repositório Git irá existir na sua máquina e seu projeto será hospedado fora dela. Não é recomendado criar repositórios Git sob o diretório da sua área de trabalho – o Eclipse não está acostumado com isso. Quando você criar um novo repositório Git (a partir da visualização de repositórios Git, ou de um projeto recentemente compartilhado), ele irá, por padrão, colocá-lo em ~/.git. Você pode, então, criar projetos sob esse local, ou compartilhar um projeto e escolher aquele repositório Git.

Outro aspecto a se observar é que todos os projetos em um repositório Git compartilham o mesmo branch. Se você tiver dois projetos, ambos em master, então você muda o branch em um projeto (digamos, release37) os de ambos projetos serão modificados. Se você não quiser isso, você pode criar um clone do repositório Git localmente, e remapear o projeto para o clone local. No entanto, isso pode gerar confusão se fizer isso normalmente.

Uma vez que você compartilhou seu projeto (ou o importou de um repositório Git previamente criado), então usá-lo é bem parecido com qualquer outro provedor no Eclipse – você pode dar commit, merge, branch, compare etc, como sempre.

A única diferença significativa é que as operações de commit são locais (por exemplo, afetam seu próprio repositório local). Portanto, outros não visualizarão suas mudanças, a não ser que você dê um git push para o servidor. Da mesma maneira, se você quiser receber mudanças de outras pessoas, você precisa dar um git pull.

Se você estiver usando o fluxo de trabalho Gerrit, então vale a pena permitir o (não documentado) gerrit.createchangeid flag, que habilita a criação automática do campo Change-Id. Isso é acionado para quando você clonar um repositório Git, mas não tem a opção de configurá-lo depois. 

Se você não estiver usando o Gerrit, então ter um clone com uma política configurada em “rebase” é a mais comum, e você encontrará para emulação dos fluxos de trabalhos tradicionais. Você pode configurá-lo ao clonar o projeto inicialmente, mas, se não fizer isso, você sempre pode configurar git config branch.autosetuprebase, seguido pela configuração das branches que você deu saída com a configuração git branch.name.rebase verdadeira.

A migração começa

Muitos projetos já migraram para o Git no Eclipse – a lista completa está aqui, e grandes projetos como CDT e EclipseRT estão no processo de se juntar aos outros, como Virgo e ECF, que já fizeram a transição.

Ainda existem questões a serem trabalhadas, tanto no EGit quanto no Git contributions policy. Mas ter o suporte para enviar sem empacotamento para o Git dentro de todos os processos de execução do Eclipe, e o fato de os projetos estarem dando um passo para migrar para o Git significa que a ferramenta estará sob exame minucioso e constante melhora nos próximos meses e anos.

***

Texto original disponível em: http://alblue.bandlem.com/2011/06/git-tip-of-week-egit.html