Mudanças entre as edições de "Controle de versão"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(45 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
O controle de versão, também chamado controle de revisão, refere-se ao [http://en.wikipedia.org/wiki/DRCS controle de alterações de documentos], permitindo assim um ambiente para a produção colaborativa de conteúdo.
+
__TOC__
 +
=O que é=
 +
O controle de versão, também chamado controle de revisão, refere-se ao [http://en.wikipedia.org/wiki/DRCS controle de alterações de documentos], permitindo assim um ambiente para a produção colaborativa de conteúdo. Está presente em várias ferramentas, como por exemplo Microsoft Office (com [http://office.microsoft.com/en-gb/windows-sharepoint-services-help/introduction-to-versioning-HA010021576.aspx SharePoint]), [http://docs.google.com/support/bin/answer.py?hl=pt-br&answer=92199 Google Docs], a plataforma  [https://www.sharelatex.com?r=d418c690&rm=d&rs=b Sharelatex], e até [http://wiki.sj.ifsc.edu.br/index.php?title=Controle_de_vers%C3%A3o&action=history esta página do wiki].
  
 
Por ser bastante utilizando no desenvolvimento de sistemas, possui significativa documentação disponível. Entretanto, cabe aqui destacar alguns conceitos importantes:
 
Por ser bastante utilizando no desenvolvimento de sistemas, possui significativa documentação disponível. Entretanto, cabe aqui destacar alguns conceitos importantes:
Linha 7: Linha 9:
 
** '''Quem?''': o autor da alteração;
 
** '''Quem?''': o autor da alteração;
 
** '''Quando?''': data e hora para gerar a linha histórica de alterações.
 
** '''Quando?''': data e hora para gerar a linha histórica de alterações.
* Linha mestre (''baseline''): linha histórica principal do repositório. Pode haver ramificações, ou variantes da linha principal.
+
* Linha mestre (''trunk'' ou ''baseline''): linha histórica principal do repositório. Pode haver ramificações, ou variantes da linha principal.
 
* Ramificação (''branch''): conjunto de alterações que divergem da linha mestre. Utilizada geralmente para testes e experimentos. Cabe ressaltar que é possível mesclar ramificações, gerando assim novas versões.
 
* Ramificação (''branch''): conjunto de alterações que divergem da linha mestre. Utilizada geralmente para testes e experimentos. Cabe ressaltar que é possível mesclar ramificações, gerando assim novas versões.
 
* Marcação (''tag''): uma vez a linha mestre e mesmo as ramificações podem se estender por várias versões, é recomendado marcar ''pontos'' ao longo da história dos documentos. Tais pontos auxiliam os editores no controle das alterações, e é comum utilizar um [http://en.wikipedia.org/wiki/Software_versioning padrão numérico] para tal.
 
* Marcação (''tag''): uma vez a linha mestre e mesmo as ramificações podem se estender por várias versões, é recomendado marcar ''pontos'' ao longo da história dos documentos. Tais pontos auxiliam os editores no controle das alterações, e é comum utilizar um [http://en.wikipedia.org/wiki/Software_versioning padrão numérico] para tal.
 
+
<!--
 
<center><graphviz>
 
<center><graphviz>
 
digraph RCS
 
digraph RCS
Linha 34: Linha 36:
 
}
 
}
 
</graphviz></center>
 
</graphviz></center>
 
+
-->
 
Há várias implementações de controle de versão, desde sistemas centralizados como [http://www.nongnu.org/cvs/ CVS] e [http://subversion.tigris.org/ Subversion] até distribuídos como [http://git-scm.com/ Git], [http://bazaar.canonical.com/en/ Bazaar] e [http://mercurial.selenic.com/ Mercurial]. Para este semestre de 2011, foi adotado o Git como ferramenta padrão para os projetos de [[Trabalho de Conclusão de Curso I|TCC I]]. O [http://tele.sj.ifsc.edu.br/blog/projetos/ sistema já está em produção] para projetos de pesquisa e trabalhos de conclusão de curso.
 
Há várias implementações de controle de versão, desde sistemas centralizados como [http://www.nongnu.org/cvs/ CVS] e [http://subversion.tigris.org/ Subversion] até distribuídos como [http://git-scm.com/ Git], [http://bazaar.canonical.com/en/ Bazaar] e [http://mercurial.selenic.com/ Mercurial]. Para este semestre de 2011, foi adotado o Git como ferramenta padrão para os projetos de [[Trabalho de Conclusão de Curso I|TCC I]]. O [http://tele.sj.ifsc.edu.br/blog/projetos/ sistema já está em produção] para projetos de pesquisa e trabalhos de conclusão de curso.
  
=Dicionário de operações=
+
=Dicionário de operações do Git Hub=
 
O Git possui mais de uma centena de operações para manipular repositórios de arquivos. A seguir, os mais utilizados:
 
O Git possui mais de uma centena de operações para manipular repositórios de arquivos. A seguir, os mais utilizados:
 
{| border=1  
 
{| border=1  
 
|-
 
|-
| align=center | '''Comando''' || align=center width="75%" | '''Descrição''' || align=center | '''Exemplos de uso'''
+
| align=center | '''Comando''' || align=center | '''Descrição''' || align=center | '''Exemplo de uso'''
 +
|-
 +
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-init.html git init]</tt> || Criação de um novo repositório local. || <tt>git init</tt>
 +
|-
 +
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html git checkout]</tt> || Atualiza os arquivos para uma determinada versão. Pode ser utilizado para verificar se o diretório de trabalho possui alterações não catalogadas (''versionadas''). || <tt>git checkout</tt>
 
|-
 
|-
| <tt>git init</tt> || Criação de um novo repositório local. || <tt>git init</tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-add.html git add]</tt> || Adição de novos arquivos para controle de versão.|| <tt>git add monografia.tex</tt>
 
|-
 
|-
| <tt>git checkout</tt> || Atualiza os arquivos para uma determinada versão. Pode ser utilizado para verificar se o diretório de trabalho possui alterações não catalogadas (''versionadas''). || <tt>git checkout</tt><br><tt>git checkout v1.0</tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-commit.html git commit]</tt> || Aplica as últimas alterações no repositório. || <tt>git commit -a -m "Revisado o primeiro capítulo."</tt>
 
|-
 
|-
| <tt>git add</tt> || Adição de novos arquivos para controle de versão.|| <tt>git add monografia.tex</tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-tag.html git tag]</tt> || Marca uma versão para facilitar a sua localização. || <tt>git tag -a v1.0</tt>
 
|-
 
|-
| <tt>git commit</tt> || Aplica as últimas alterações no repositório. || <tt>git commit -a -m "Primeiro capítulo."</tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-log.html git log]</tt> || Lista as versões aplicadas no repositório. || <tt>git log</tt>
 
|-
 
|-
| <tt></tt> || || <tt></tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-revert.html git revert]</tt> || Pode retroceder na linha histórica de versões, podendo reescrevê-la a partir de um dado ponto.  || <tt>git revert HEAD~4</tt>
 
|-
 
|-
| <tt></tt> || || <tt></tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-branch.html git branch]</tt> || Cria ramos alternativos à linha mestre. || <tt>git branch teste</tt>
 
|-
 
|-
| <tt></tt> || || <tt></tt>
+
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-clone.html git clone]</tt> || Copia um repositório remoto para outro, local. || <tt>git clone http://servidor/repo</tt>
 +
|-
 +
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-pull.html git pull]</tt> || Sincroniza repositórios (versões) no sentido remoto->local. || <tt>git pull</tt>
 +
|-
 +
| <tt>[http://www.kernel.org/pub/software/scm/git/docs/git-push.html git push]</tt> || Sincroniza repositórios (versões) no sentido local-> remoto. || <tt>git push</tt>
 
|-
 
|-
 
|}
 
|}
 +
 +
==Usando pela primeira vez==
 +
Um cenário comum é o de múltiplos repositórios. Vamos usar como exemplo o [http://tele.sj.ifsc.edu.br/blog/projetos/ ambiente de projetos de Tele]: é criado um repositório remoto vazio para produção colaborativa de conteúdo.
 +
 +
# Como o ambiente possui controle de acesso e HTTPS, é preciso criar dois arquivos no seu diretório pessoal:
 +
## Usuário e senha para autenticação em [http://tele.sj.ifsc.edu.br/arquivos/publicos/.netrc ~/.netrc].
 +
## Nome completo do usuário, email e permissão de certificado autoassinado em  [http://tele.sj.ifsc.edu.br/arquivos/publicos/.gitconfig ~/.gitconfig]. 
 +
# Copiar o repositório remoto: <tt>git clone <nowiki>https://tele.sj.ifsc.edu.br/projetos/</nowiki><nome_do_projeto></tt>. O professor da disciplina de TCC I informará o nome do projeto para cada equipe.
 +
 +
==Usando no dia a dia==
 +
# Uma vez que várias pessoas participam dos projetos, é recomendado (porém não obrigatório) sincronizar o repositório local a partir do remoto: <tt>git pull</tt>.
 +
# Crie um ou mais arquivos e adicione-os ao controle: <tt>git add <arquivo></tt>. Em diretórios, o processo é recursivo.
 +
# Edite os arquivos a vontade, com qualquer editor disponível.
 +
# Uma vez que há arquivos modificados (visíveis com o comando: <tt>git checkout</tt>), pode-se criar versões a partir desse novo conteúdo: <tt>git commit -a -m "<mensagem>"</tt>.
 +
# Se esta última versão adicionada ao repositório é importante, como a versão final de um documento ou apresentação, é extremamente recomendado marcá-lo para facilitar a sua localização. Para isso, use o comando: <tt>git tag -a <tag> -m "<mensagem>"</tt>. No caso do TCC I, '''somente as versões marcadas''' com:
 +
## <tt>meta1</tt>;
 +
## <tt>meta2</tt>;
 +
## <tt>meta3</tt> e
 +
## <tt>meta4</tt> serão consideradas versões finais para cada meta correspondente. '''Na ausência da marcação, a meta não será atingida'''.
 +
# Por último, pode-se sincronizar o repositório remoto a partir do local com: <tt>git push/tt>. Assim como <tt>git pull</tt>, esse comando não é obrigatório, mas agilizará na disseminação das versões para todos os colaboradores do projeto. Cabe destacar que se várias pessoas editarem arquivos ao mesmo tempo, haverá uma mescla (''merge'') do produto final, sem perdas. ATENÇÃO: a primeira que for digitar <tt>git push</tt> é preciso informar a origem, através do comando:
 +
<syntaxhighlight lang=bash>
 +
git push origin master
 +
</syntaxhighlight>
 +
na primeira vez. Depois, todos os outros ''pushes'' se dão apenas com:
 +
<syntaxhighlight lang=bash>
 +
git push
 +
</syntaxhighlight>
 +
Porém, quando houver um ''commit'' com marcador associado (''tag''), esse comando deve adicionar o argumento:
 +
<syntaxhighlight lang=bash>
 +
git push --tags
 +
</syntaxhighlight>
 +
 +
===Ferramentas gráficas/Web===
 +
Há várias ferramentas gráficas e Web para manipular o repositório, e destacam-se:
 +
* [http://www.kernel.org/pub/software/scm/git/docs/gitk.html gitk]: aplicativo gráfico em Tcl/Tk.
 +
* [http://git.gnome.org/browse/gitg/ gitg]: aplicativo gráfico para Gnome.
 +
* [http://cola.tuxfamily.org/ git-cola]: aplicativo gráfico feito em Python.
 +
* [https://git.wiki.kernel.org/index.php/Gitweb gitweb]: ambiente Web. [https://tele.sj.ifsc.edu.br/cgi-bin/gitweb.cgi Disponível para os professores] acompanharem todos os projetos e TCCs.
  
 
=Referências=
 
=Referências=
 
* LOELIGER, J. [http://www.amazon.com/Version-Control-Git-Collaborative-Development/dp/0596520123/ref=sr_1_1?ie=UTF8&qid=1300929789&sr=8-1 '''Version Control with Git''': Powerful Tools and Techniques for Collaborative Software Development]. O'Reilly Media. 2009.
 
* LOELIGER, J. [http://www.amazon.com/Version-Control-Git-Collaborative-Development/dp/0596520123/ref=sr_1_1?ie=UTF8&qid=1300929789&sr=8-1 '''Version Control with Git''': Powerful Tools and Techniques for Collaborative Software Development]. O'Reilly Media. 2009.
 
* CHACO, S. [http://progit.org '''Pro Git''']. Apress. 2009.
 
* CHACO, S. [http://progit.org '''Pro Git''']. Apress. 2009.
 
+
* LIVINGSTON-GRAY, S. '''[http://think-like-a-git.net/ Think Like (a) Git]'''. Acessado em: 03/11/2011.
 +
* DUDLER, R. '''[http://rogerdudler.github.io/git-guide/index.pt_BR.html git - guia prático]'''. Acessado em 16/11/2015.
  
 
Este material foi produzido para a discplina [[Trabalho de Conclusão de Curso I|TCC I]].
 
Este material foi produzido para a discplina [[Trabalho de Conclusão de Curso I|TCC I]].

Edição atual tal como às 22h12min de 11 de novembro de 2020

O que é

O controle de versão, também chamado controle de revisão, refere-se ao controle de alterações de documentos, permitindo assim um ambiente para a produção colaborativa de conteúdo. Está presente em várias ferramentas, como por exemplo Microsoft Office (com SharePoint), Google Docs, a plataforma Sharelatex, e até esta página do wiki.

Por ser bastante utilizando no desenvolvimento de sistemas, possui significativa documentação disponível. Entretanto, cabe aqui destacar alguns conceitos importantes:

  • Repositório: é o local de armazenamento para onde convergirão as alterações dos documentos. Deve, portanto, possuir um mecanismo para atender operações concorrentes, tratando tais operações ao longo de uma linha temporal. Os documentos em sua versão final são, portanto, o resultado das várias alterações desde a sua criação até o seu estado corrente.
  • Versão (ou revisão): é uma alteração de um ou mais documentos a partir do seu estado (versão/revisão) anterior. Por tratar-se de uma ferramenta colaborativa e, portanto, multiusuário, deve registrar informações como:
    • O quê?: o conteúdo da alteração;
    • Quem?: o autor da alteração;
    • Quando?: data e hora para gerar a linha histórica de alterações.
  • Linha mestre (trunk ou baseline): linha histórica principal do repositório. Pode haver ramificações, ou variantes da linha principal.
  • Ramificação (branch): conjunto de alterações que divergem da linha mestre. Utilizada geralmente para testes e experimentos. Cabe ressaltar que é possível mesclar ramificações, gerando assim novas versões.
  • Marcação (tag): uma vez a linha mestre e mesmo as ramificações podem se estender por várias versões, é recomendado marcar pontos ao longo da história dos documentos. Tais pontos auxiliam os editores no controle das alterações, e é comum utilizar um padrão numérico para tal.

Há várias implementações de controle de versão, desde sistemas centralizados como CVS e Subversion até distribuídos como Git, Bazaar e Mercurial. Para este semestre de 2011, foi adotado o Git como ferramenta padrão para os projetos de TCC I. O sistema já está em produção para projetos de pesquisa e trabalhos de conclusão de curso.

Dicionário de operações do Git Hub

O Git possui mais de uma centena de operações para manipular repositórios de arquivos. A seguir, os mais utilizados:

Comando Descrição Exemplo de uso
git init Criação de um novo repositório local. git init
git checkout Atualiza os arquivos para uma determinada versão. Pode ser utilizado para verificar se o diretório de trabalho possui alterações não catalogadas (versionadas). git checkout
git add Adição de novos arquivos para controle de versão. git add monografia.tex
git commit Aplica as últimas alterações no repositório. git commit -a -m "Revisado o primeiro capítulo."
git tag Marca uma versão para facilitar a sua localização. git tag -a v1.0
git log Lista as versões aplicadas no repositório. git log
git revert Pode retroceder na linha histórica de versões, podendo reescrevê-la a partir de um dado ponto. git revert HEAD~4
git branch Cria ramos alternativos à linha mestre. git branch teste
git clone Copia um repositório remoto para outro, local. git clone http://servidor/repo
git pull Sincroniza repositórios (versões) no sentido remoto->local. git pull
git push Sincroniza repositórios (versões) no sentido local-> remoto. git push

Usando pela primeira vez

Um cenário comum é o de múltiplos repositórios. Vamos usar como exemplo o ambiente de projetos de Tele: é criado um repositório remoto vazio para produção colaborativa de conteúdo.

  1. Como o ambiente possui controle de acesso e HTTPS, é preciso criar dois arquivos no seu diretório pessoal:
    1. Usuário e senha para autenticação em ~/.netrc.
    2. Nome completo do usuário, email e permissão de certificado autoassinado em ~/.gitconfig.
  2. Copiar o repositório remoto: git clone https://tele.sj.ifsc.edu.br/projetos/<nome_do_projeto>. O professor da disciplina de TCC I informará o nome do projeto para cada equipe.

Usando no dia a dia

  1. Uma vez que várias pessoas participam dos projetos, é recomendado (porém não obrigatório) sincronizar o repositório local a partir do remoto: git pull.
  2. Crie um ou mais arquivos e adicione-os ao controle: git add <arquivo>. Em diretórios, o processo é recursivo.
  3. Edite os arquivos a vontade, com qualquer editor disponível.
  4. Uma vez que há arquivos modificados (visíveis com o comando: git checkout), pode-se criar versões a partir desse novo conteúdo: git commit -a -m "<mensagem>".
  5. Se esta última versão adicionada ao repositório é importante, como a versão final de um documento ou apresentação, é extremamente recomendado marcá-lo para facilitar a sua localização. Para isso, use o comando: git tag -a <tag> -m "<mensagem>". No caso do TCC I, somente as versões marcadas com:
    1. meta1;
    2. meta2;
    3. meta3 e
    4. meta4 serão consideradas versões finais para cada meta correspondente. Na ausência da marcação, a meta não será atingida.
  6. Por último, pode-se sincronizar o repositório remoto a partir do local com: git push/tt>. Assim como git pull, esse comando não é obrigatório, mas agilizará na disseminação das versões para todos os colaboradores do projeto. Cabe destacar que se várias pessoas editarem arquivos ao mesmo tempo, haverá uma mescla (merge) do produto final, sem perdas. ATENÇÃO: a primeira que for digitar git push é preciso informar a origem, através do comando:
git push origin master

na primeira vez. Depois, todos os outros pushes se dão apenas com:

git push

Porém, quando houver um commit com marcador associado (tag), esse comando deve adicionar o argumento:

git push --tags

Ferramentas gráficas/Web

Há várias ferramentas gráficas e Web para manipular o repositório, e destacam-se:

Referências

Este material foi produzido para a discplina TCC I.