Configure corretamente seu projeto com o Git e o Iceberg

6. Configure corretamente seu projeto

Traduzido do capítulo Configure your project nicely with Iceberg do livro Manage Your Code with Git and Iceberg - May 12, 2020. Antes leia Publicando seu primeiro projeto Pharo com Iceberg.

Conteúdo

• 6.1 E se eu não criasse um repositório remoto (remote repository)
  • Criar um novo repositório.
    • Adicionar um repositório remoto
  • Push to the remote.
• 6.2 Definindo uma BaselineOf
• 6.3 Carregamento a partir de um repositório existente
  • Carga manual.
• 6.4 [Opcional] Adicionar um arquivo .gitignore faz com que o Iceberg gerencie automaticamente arquivos como o .gitignore.
• 6.5 Indo mais além: Entendendo a arquitetura
• 6.6 Conclusão

Versionar o código é apenas a primeira parte para garantir que você e outros possam recarregar seu código. Neste capítulo descrevemos como definir uma linha de base (baseline), um mapa do projeto que você usará para definir dependências dentro de seu projeto e dependências para outros projetos. Também mostramos como adicionar um bom arquivo .git-ignore. No próximo capítulo mostraremos como configurar seu projeto para obter mais dos serviços oferecidos dentro do ecossistema Github, como o Travis-ci, para executar automaticamente seus testes.

Começamos mostrando como você pode fazer o commit de seu código se você não criou seu repositório remoto primeiro.

6.1 E se eu não criasse um repositório remoto (remote repository)

No capítulo anterior, começamos por criar um repositório remoto no Github. Depois pedimos ao Iceberg que adicionasse um projeto clonando-o a partir do Github. Agora você pode se perguntar qual é o processo para publicar primeiro seu projeto localmente sem um repositório pré-existente. Na verdade, isto é simples.

Criar um novo repositório.

Ao adicionar um novo repositório, use a opção “New repository”, como mostrado em 6-1.

Adicionar um repositório remoto

Se você quiser fazer um commit a um repositório remoto, você terá que adicioná-lo usando o Repository Browser. Você pode acessar este browser através do item de menu associado ou do ícone. O Repository Browser lhe dá acesso aos repositórios associados ao seu projeto: você pode acessar, gerenciar branches e também adicionar ou remover repositórios remotos. A Figura 6-3 mostra o Repository Browser de nosso projeto.

Pressionar o iconic button “Add remote” adiciona um repositório remoto preenchendo as informações necessárias que você pode encontrar em seu projeto Github. A Figura 6-3 mostra-o para o projeto de exemplo usando SSH e a Figura 6-4 para HTTPS.

Push to the remote.

Agora você pode empurrar suas alterações e versões para o repositório remoto usando o botão Push. Uma vez pressionado, você pode ver que você possui um repositório remoto, como mostrado na Figura 6-5.

Figura 6-3 Adicionando um repositório remoto usando o Repository browser do seu projeto (versão SSH).

6.2 Definindo uma BaselineOf

Uma baseline é uma descrição da arquitetura de um projeto. Você expressará as dependências entre seus pacotes e outros projetos para que todos os projetos dependentes sejam carregados sem que o usuário tenha que entendê-los ou as ligações entre eles.

Uma baseline é expressa como uma subclasse da BaselineOf e incluída em um pacote chamado ‘BaselineOfXXX’ (onde ‘XXX’ é o nome de seu projeto). Portanto, se você não tem dependências, você pode ter algo assim.

BaselineOf subclass: #BaselineOfMyCoolProjectWithPharo 
    ...
    package: 'BaselineOfMyCoolProjectWithPharo'

BaselineOfMyCoolProjectWithPharo >> baseline: spec
    <baseline>
    spec 
        for: #common  
        do: [ spec package: 'MyCoolProjectWithPharo' ]

Uma vez definida sua baseline, você deve adicionar seu pacote ao seu projeto usando o working copy browser, como explicado no capítulo anterior. Você deve obter a seguinte situação mostrada na Figura 6-6. Agora, faça o commit e empurre (push) suas mudanças para seu repositório remoto.

Um recurso web mais elaborado sobre as possibilidades de baseline está disponível em: https://github.com/pharo-open-documentation/pharo-wiki/.

6.3 Carregamento a partir de um repositório existente

Uma vez que você tenha um repositório onde já fez commit e gostaria de carregá-lo em uma nova imagem do Pharo, há duas maneiras de resolver isso.

Carga manual.

• Adicione o projeto como explicado no primeiro capítulo
• Abra o working copy browser clicando duas vezes na linha do projeto no repositories browser.
• Selecione um pacote e carregue-o manualmente.

A segunda maneira é fazer uso do Metacello. Entretanto, isto só funcionará se você já tiver criado uma BaselineOf. Neste caso, você pode simplesmente executar o seguinte trecho:

Metacello new  
    baseline: 'MyCoolProjectWithPharo';  
    repository: 'github://Ducasse/MyCoolProjectWithPharo/src'; load

Para projetos com metadados, como o que acabamos de criar, é só isso. Note que não mencionamos apenas o etapa do Github mas também foi adicionada a pasta de códigos (aqui denominado de src).

6.4 [Opcional] Adicionar um arquivo .gitignore faz com que o Iceberg gerencie automaticamente arquivos como o .gitignore.

# For Pharo 70 and up  
# http://www.pharo.org  
# Since Pharo 70 all the community is moving to git.
    
# image, changes and sources *.changes  
*.sources  
*.image
    
# Pharo Debug log file and launcher metadata PharoDebug.log  
pharo.version  
meta-inf.ston
    
# Since Pharo 70, all local cache files for Monticello package cache, playground, epicea... are under the pharo-local
/pharo-local

# Metacello-github cache
/github-cache 
github-*.zip

6.5 Indo mais além: Entendendo a arquitetura

Como o git é um sistema de versões distribuídas, você precisa de um clone local de seu repositório. Em geral, você edita sua working copy localizada em seu disco rígido e faz o commit para o seu clone local, e de lá você empurra (push) para repositórios remotos como o Github. Explicamos aqui a especificidade de gerenciar o Pharo com git.

Ao codificar no Pharo, você deve entender que não está editando diretamente sua cópia de trabalho local, está modificando objetos que representam classes e métodos que estão residindo no ambiente do Pharo. Portanto, é como se você tivesse uma cópia de trabalho dupla: o próprio Pharo e a working copy do git.

Quando você usa a linha de comando com git, você tem que entender que há o código na imagem e o código na cópia de trabalho (e seu clone local). Para atualizar sua imagem, primeiro você tem que atualizar sua working copy git e depois carregar o código da working copy para a imagem. Para salvar seu código, você tem que salvar o código em arquivos, adicioná-los à sua working copy do git e fazer commit deles para o seu clone.

Agora a parte interessante é que o Iceberg gerencia tudo isso para você de forma transparente. Toda a sincronização entre estas duas cópias de trabalho é feita por trás da cena.

A Figura 6-7 mostra a arquitetura do sistema.

• Você tem seu código na imagem do Pharo.
• Pharo está funcionando como uma working copy (ele contém o conteúdo do repositório local de git).
• Iceberg gerencia a publicação de seu código na working copy do git e no repositório local do git.
• Iceberg gerencia a publicação de seu código para repositórios remotos.
• Iceberg gerencia a re-sincronização de sua imagem com o repositório local git, repositórios remotos git e a working copy do git.

6.6 Conclusão

Mostramos como empacotar seu código correclty. Isto o ajudará a recarregá-lo e a utilizar os serviços que apresentaremos no próximo capítulo.