Documentação do Symfony - versão 3.1
Renderizada do repositório symfony-docs-pt-BR no Github
Tip
Embora este artigo seja especificamente sobre git, os mesmos princípios genéricos aplicam-se caso você estiver armazenando o seu projeto no Subversion.
Uma vez que você leu /book/page_creation e familiarizou-se com o Symfony, já está, sem dúvida, pronto para começar o seu próprio projeto. Neste artigo do cookbook, você aprenderá a melhor maneira de iniciar um novo projeto Symfony2 que será armazenado usando o sistema gerenciador de controle de versão git.
Para começar, você precisa baixar o Symfony e inicializar o seu repositório git local:
Baixe a Edição Standard do Symfony2 sem vendors.
Descompacte a distribuição. Será criado um diretório chamado Symfony com a sua nova estrutura do projeto, arquivos de configuração, etc. Renomeie-o como desejar.
Crie um novo arquivo chamado .gitignore
no raiz de seu novo projeto
(Ex.: junto com o arquivo composer.json
) e cole o conteúdo seguinte nele. Os arquivos
correspondentes a estes padrões serão ignorados pelo git:
1 2 3 4 5 6 /web/bundles/ /app/bootstrap* /app/cache/* /app/logs/* /vendor/ /app/config/parameters.yml
Copie app/config/parameters.yml
para app/config/parameters.yml.dist
.
O arquivo parameters.yml
é ignorado pelo git (veja acima), de modo que as configurações específicas da máquina,
como senhas de banco de dados, não sejam comitadas. Criando o arquivo parameters.yml.dist
,
novos desenvolvedores podem, rapidamente, clonar o projeto, copiar este arquivo para
parameters.yml
, personalizá-lo e iniciar o desenvolvimento.
Inicialize o seu repositório git:
1 $ git init
Adicione todos os arquivos iniciais ao git:
1 $ git add .
Crie um commit inicial para o seu projeto:
1$ git commit -m "Initial commit"
Finalmente, baixe todas as bibliotecas vendor de terceiros executando o composer. Para detalhes, veja Atualizando os Vendors.
Neste ponto, você tem um projeto Symfony2 totalmente funcional que está corretamente comitado com o git. Você pode iniciar imediatamente o desenvolvimento, comitando as novas alterações em seu repositório git.
Você pode continuar acompanhando o capítulo /book/page_creation para saber mais sobre como configurar e desenvolver dentro da sua aplicação.
Tip
A Edição Standard do Symfony2 vem com algumas funcionalidades exemplo. Para remover o código de exemplo, siga as instruções contidas no Readme da Edição Standard.
Cada projeto Symfony usa um grande grupo de bibliotecas “vendor” de terceiros.
Por padrão, estas bibliotecas são baixadas executando o script
php bin/vendors install
. Este script lê o arquivo deps
, e baixa as
bibliotecas ali informadas no diretório vendor/
. Ele também lê o arquivo deps.lock
,
fixando cada biblioteca listada ao respectivo hash do commit git.
Nesta configuração, as bibliotecas vendor não fazem parte de seu repositório git,
nem mesmo como sub-módulos. Em vez disso, contamos com os arquivos deps
e deps.lock
e o script bin/vendors
para gerenciar tudo. Esses arquivos são
parte de seu repositório, então, as versões necessárias de cada biblioteca de terceiros
tem controle de versão no git, e você pode usar o script vendors para trazer
o seu projeto atualizado.
Sempre que um desenvolvedor clona um projeto, ele(a) deve executar o script php bin/vendors install
para garantir que todas as bibliotecas vendor necessárias foram baixadas.
Caution
Há também um comando php bin/vendors update
, mas isso não tem nada
a ver com a atualização do seu projeto e você normalmente não precisará
utilizá-lo. Este comando é usado para congelar as versões de todas as suas bibliotecas vendor
atualizando-as para a versão especificada em deps
e gravando-as
no arquivo deps.lock
.
Além disso, se você deseja simplesmente atualizar o arquivo deps.lock
para o que já tem instalado, então, você pode simplesmente executar php bin/vendors lock
para armazenar os identificadores git SHA apropriados no arquivo deps.lock.
Em vez de usar o sistema composer.json
para gerenciar suas bibliotecas vendor,
você pode optar por usar o git submodules nativo. Não há nada de errado com
esta abordagem, embora o sistema composer.json
é a forma oficial
de resolver este problema e provavelmente mais fácil de lidar. Ao contrário
do git submodules
, o Composer
é esperto o suficiente para calcular
quais bibliotecas dependem de outras bibliotecas.
Agora, você tem um projeto Symfony2 totalmente funcional armazenado com o git. Entretanto, na maioria dos casos, você também vai querer guardar o seu projeto em um servidor remoto tanto para fins de backup quanto para que outros desenvolvedores possam colaborar com o projeto.
A maneira mais fácil para armazenar o seu projeto em um servidor remoto é via GitHub. Repositórios públicos são gratuitos, porém, você terá que pagar uma taxa mensal para hospedar repositórios privados.
Alternativamente, você pode armazenar seu repositório git em qualquer servidor, criando um repositório barebones e, então, enviá-lo. Uma biblioteca que ajuda neste gerenciamento é a Gitolite.