3.3 Controle de Versão do Projeto
Last updated
Was this helpful?
Last updated
Was this helpful?
Sistemas de controle de versão se popularizaram e são ferramentas de fundamental importância na gerência de projetos e gestão de configurações de software.
Um dos mais populares atualmente é o , que conta com diversas plataformas que o utiliza e oferece outras funcionalidades, como o , por exemplo, que oferece recursos de colaboração entre equipes.
Nesta seção, é apresentado como podemo utilizar o Git para controlar as versões do nosso software em desenvolvimento e integrar tudo no GitHub para facilitar a colaboração em nosso projeto.
Para que o Git possa controlar as alterações feitas em nossos arquivo é necessário indicar a ele qual será a pasta que irá corresponder ao nosso repositório local. No nosso exemplo, utilizaremos como base a pasta que contém o arquivo manage.py. Ela está localizada em $HOME/superlists/superlists.
Entretanto, primeiramente vamos mover nosso arquivo de teste (functional_tests.py) para essa pasta. Atualmente ele está localizado um nível abaixo, em $HOME/superlists. Em seguida, basta entrar na pasta que sera utilizada como nosso diretório de trabalho, e a qual desejamos colocar sobre controle de versão, para inicializar nosso repositório com o comando git init.
O próximo passo é decidirmos o que iremos colocar sobre controle de versão. O conteúdo atual da pasta é esse:
db.sqlite3 é um arquivo de banco de dados e não queremos que ele seja mantido sobre controle de versão. Também vimos anteriormente o arquivo geckodriver.log , que é um arquivo de log de execução do Selenium, e também podemos descartar esse arquivo do controle de versão. Para fazer isso no Git, basta criarmos na raiz do repositório, um arquivo denominado especial denominado .gitignore. O seu conteúdo indica ao Git o que deve ser ignorado do controle de versão. Os comandos abaixo foram utilizados para a criação do arquivo .gitignore. Você também pode utilizar um editor de texto qualquer para essa mesma finalidade.
Decidido o que ignorar, os demais arquivos, em princípio, podem ser adicionados ao controle de versão. Para isso, usamos o comando git add, conforme abaixo. Para consultar o que foi adicionado ao controle de versão, basta usar o comando git status.
Como podemos observar, além dos arquivos .gitignore, functional_tests.py e manage.py, todos os arquivos do subdiretório superlists também foram incluídos mas, alguns deles não desejamos colocar sobre controle de versão, como é o caso dos arquivos da pasta __pycache__. Para isso, basta pedirmos ao Git que remova tais arquivos do controle de versão e adicionarmos os mesmos no arquivo .gitignore, conforme mostrado abaixo.
Verificando o status de nosso repositório tudo parece ok, exceto que como modificamos o arquivo .gitignore, ele precisa ser adicionado novamente ao repositório (linha 22) e, em seguida, as modificações precisam ser confirmadas com o comando git commit (linha 23).
Caso se observe o erro acima, bast aexecutar os comando abaixo que será resolvido e repetir o comando de commit.
Observe que ao executar o comando git commit utilizamos o parâmetro -m "<MENSAGEM>"uma vez que toda confirmação exige uma mensagem explicando as alterações realizadas. Se o parâmetro -m for omitido, o Git irá abrir o editor de texto padrão para que uma mensagem seja digitada. Tais mensagens servem para orientar a equipe sobre quais alterações são propostas pelo referido commit.
Assumindo que você já tenha criado sua conta no GitHub, a criação do token pode ser feita clicando sobre sua foto na conta e escolhendo a opção Settings, conforme imagem abaixo:
Em seguida, no menu da lateral esquerda, selecione a opção Developer Settings.
Dentre as opções exibidas, escolha a Personal Access Token, e clique em Generate New Token.
Na janela que irá abrir você deve fornecer um nome qualquer do token (TokenCMD no exemplo abaixo) e escolher as permissões que o mesmo terá. Para a gestão dos repositórios, basta selecionar o primeiro grupo de permissões (repo) e, navegar até o final e clicar em Generete token, conforme telas a seguir.
Feito isso, será apresentado o token a você. Copie e cole em um arquivo texto pois você não será mais capaz de visualizá-lo assim que sair dessa tela. Se esquecer o número do token terá que criar outro.
Para enviarmos o repositório local para o repositório remoto precisamos ainda criar um repositório vazio no GitHub. Para isso, basta clicar sobre sua foto e escolher a opção Your repositories. Em seguida, clicar no botão New, dar um nome para o repositório (superlists no exemplo), escolher a visibilidade desejada (public no exemplo) e clicar em Create repository.
Enviando Arquivos do Repositório Local para o Remoto
Ao final da janela acima (não visível na figura), o GitHub apresenta as instruções para conectar um repositório local já existente com este que acabamos de criar. A sequência de comandos que ele sugere é essa:
Desse mode modo, estamos prontos para enviar os arquivos do diretório local para o repositório remoto. Para isso, usaremos o comando git push, conforme ilustrado abaixo. Durante a execução desse comando precisamos da URL do repositório no GitHub, do nome do usuário no GitHub e do token de acesso que foi gerado.
O primeiro passo (linha 1) é adicionar os dados do repositório remoto à origem do nosso repositório. Em seguida, para enviar os dados do repositório local para o remoto utilizamos o comando da linha 2, git push.
Ao executar esse comando, o Git irá solicitar nosso login (aurimrv no exemplo) e a senha que deve ser o token criado anteriormente.
A figura a seguir ilustra o repositório atualizado no GitHub com os arquivos que estavam apenas no nosso repositório local.
Como podemos observar na tela acima, no GitHub aparece uma mensagem de que não criamos o arquivo README.md, que explica o conteúdo do repositório. Para adicionar tal arquivo ao projeto, basta clicarmos no botão Add a README que podemos editá-lo dentro do próprio GitHub, conforme ilustrado a seguir.
Finalizada a edição, basta realizarmos a confirmação das mudanças (Commit new file) para que o arquivo seja salvo em nosso projeto.
A tela a seguir agora exibe a descrição do projeto na tela inicial do repositório.
Uma vez que criamos o arquivo README.md remotamente, ele não está presente no nosso diretório local. Para atualizar nossa cópia local podemos utilizar o comando da linha 1 e manter tudo sincronizado (git pull).
A execução do git status conforma que os repositórios estão sincronizados e o arquivo README.md já está presente no repositório local.
Para evitar conflitos em repositórios é importante manter a sincronização. Desse modo, uma das práticas recomendadas no desenvolvimento é a realização de commits frequentes.
Até o momento, estamos utilizando a ferramenta Git para gerenciar as mudanças em nossa pasta local, mas podemos sincronizar nosso repositório local com repositórios remotos, na nuvem. Existem diversas alternativas para o caso do Git. Uma das mais populares é o . Nele é possível você ter uma conta gratuita para criação de repositórios.
Desse modo, para que possamos sincronizar o repositório local com o remoto, é importante que você crie uma conta no e, após isso, crie um token para permitir que o comando Git se comunique com seu repositório remoto no .
Criado o repositório é importante anotar também a URL de acesso do mesmo, que aparece em destaque na imagem acima. No exemplo essa URL é a .
