Um sistema de controle de versão gerencia as diferentes versões de documentos ao longo do tempo, permitindo recuperar versões antigas e analisar o histórico de desenvolvimento. Git é um sistema de controle de versão distribuído criado para o desenvolvimento do kernel Linux, que oferece rápidas ramificações, merges e visualização do histórico não-linear. Comandos como git add, commit, push e pull permitem adicionar, confirmar, enviar e obter atualizações de arquivos no repositório local e remoto.

1. {
Intervalo Técnico
TREINAMENTO DE GIT

2. O que é um sistema de controle de versão?

3. 
Um sistema de controle de versão é um software que tem a responsabilidade de gerenciar as diferentes versões de qualquer documento. Ou seja, ele armazena as diversas revisões de um determinado ao longo do ciclo de vida do projeto.

Há ferramentas de versionamento gratuitas e privadas que podem ser usadas tanto para pequenos projetos pessoais como grandes projetos empresariais.

Exemplos de software de versionamento: SVN, Mercurial, Git, CVS, SourceSafe, Clearcase.

4. Quais as vantagens de se usar um sistema de controle de versão?

5. 
As principais vantagens de se utilizar um sistema de controle de versão para rastrear as alterações feitas durante o desenvolvimento de software são:

Controle do histórico: facilidade em desfazer e possibilidade de analisar o histórico do desenvolvimento, como também facilidade no resgate de versões mais antigas e estáveis. A maioria das implementações permite analisar as alterações com detalhes, desde a primeira versão até a última.

6. 
Trabalho em equipe: um sistema de controle de versão permite que diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao mesmo tempo e minimiza o desgaste provocado por problemas com conflitos de edições. É possível que a implementação também tenha um controle sofisticado de acesso para cada usuário ou grupo de usuários.

7. 
Criação e resgate de versões estáveis: a maioria dos sistemas permite marcar onde é que o documento estava com uma versão estável, podendo ser facilmente resgatado no futuro.

Ramificação de projeto: a maioria das implementações possibilita a divisão do projeto em várias linhas de desenvolvimento, que podem ser trabalhadas em paralelo, sem que uma interfira na outra.

8. O que é o Git? Quem fez?

9. 
Git é um sistema de controle de versão distribuído com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.

Cada diretório de trabalho do Git é um repositório com um histórico completo e possui habilidade total de acompanhamento das revisões, sem depender de acesso a uma rede ou a um servidor central.

O Git é um software livre, distribuído sob os termos da versão 2 da GNU General Public License. Sua manutenção é atualmente supervisionada por Junio Hamano.

10. Porque escolhemos o Git?

11. 
O Git suporta rápidas criações de branches e merges, e inclui ferramentas específicas para visualização e navegação de históricos de desenvolvimento não-lineares.

O Git dá a cada desenvolvedor uma cópia local completa de todo o histórico de desenvolvimento, e as mudanças são copiadas de um único repositório para outro. Estas mudanças são importadas como branches adicionais de desenvolvimento, e podem sofrer um merge da mesma forma que uma branch de desenvolvimento local.

Repositórios podem ser publicados por HTTP, FTP, rsync, um protocolo Git sobre uma porta conhecida ou por ssh. O Subversion pode utilizar os repositórios diretamente com o git-svn.

12. 
Obter o histórico das revisões salvos em repositórios locais é duas vezes mais rápido que obtê-los de um servidor remoto. Um detalhe interessante é que o Git não fica mais lento com o aumento do histórico do projeto, como acontece com o SVN.

O histórico do Git é salvo de uma maneira que o nome de uma determinada revisão (um "commit") depende de todo o histórico de desenvolvimento que leva até este commit. Uma vez publicado, não é possível mudar as versões antigas sem passar despercebido.

13. 
O repositório local do git possui 3 árvores:

Working tree: é onde estão os arquivos de fato e onde o desenvolvedor os manipula.

Index: é uma área temporária onde os arquivos são armazenados antes de serem enviados para o HEAD.

HEAD: local onde ficam salvas as revisões de todos os arquivos do repositório.

Há também o remote, que é um alias (atalho) para o endereço do servidor onde os arquivos foram clonados, ou serão enviados. Não é obrigatório ter um remote cadastrado, mas é altamente recomendável.

14. 
O Git implementa várias estratégias de merge que podem ser utilizadas pelo desenvolvedor:

resolve: o tradicional algoritmo de merge em três vias.

recursive: Este é o padrão durante o clone ou é feito um merge numa branch que possui mais de uma branch de origem em comum.

octopus: Este é o padrão quando efetuado merge em mais de duas heads.

15. O que é a branch “Master”?

16. 
Master é a branch principal de um repositório. É a primeira branch que é criada quando o repositório é iniciado e é onde o código mais atualizado é mantido.

O desenvolvimento de um software geralmente ocorre na branch master e é a partir dela que outras branches e tags são criadas.

17. O que é uma branch?

18. 
Uma branch é uma ramificação da branch principal (geralmente master) criada para isolar o desenvolvimento de uma determinada funcionalidade.

As alterações feitas numa branch qualquer não afetam nenhuma outra do repositório, permitindo que várias funcionalidades sejam desenvolvidas em paralelo.

As branches também permitem que um time de desenvolvedores trabalhem simultaneamente no mesmo projeto e até mesmo no mesmo arquivo sem que ocorram problemas de acesso e conflito de manipulação.

19. O que é uma tag?

20. 
Uma tag define uma versão estável e testada de um software. Ao fechar uma tag, está implícito que as funcionalidades que foram planejadas para aquela determinada função foram finalizadas e que um novo conjunto de funcionalidades deve começar a ser implementado.

21. 
git clone [options] <repository> [dir]

git checkout [options] <branch>

git add [options] [filename]

git commit [options]

git push [options] <server alias> <branch>

git pull [options] <serveralias> <branch>
Comandos básicos do git

22. 
git clone [options] <repository> [dir]

Esse comando é utilizado para se obter uma nova cópia do repositório especificado. Através dele, o desenvolvedor obtém o repositório completo com acesso local e remoto.

A opção que será mais utilizada é --recursive que faz com que o repositório seja copiado incluindo todas as suas dependências (submodules).

<repository> é uma url para um repositório. Ex.: http://git.cw/x5.repo.git

[dir] é opcional e é o diretório onde o repositório ficará armazenado. Caso não seja fornecido, o git usará o nome do repositório como diretório.

23. 
git checkout [options] <branch>

Esse comando é utilizado para trocar a branch ativa do repositório. Somente uma branch pode estar ativa por vez.

A opção mais utilizada com esse comando é –b que permite criar uma branch e torná-la ativa com apenas um comando. Ex.: git checkout –b nova_branch

<branch> é o nome da branch que ficará ativa. A branch deve ter sido criada antes ou é necessário o uso da opção –b.

Ex.: Mudar para a branch teste: git checkout teste Voltar para a branch master: git checkout master

24. 
git add [options] [filename]

Esse comando é utilizado para adicionar arquivos no repositório. Ao utilizar esse comando, os arquivos são enviados para o Index.

Pode-se especificar os arquivos que serão adicionados separados por espaço. Ex: git add arquivo1 arquivo2 arquivo3

É possível adicionar todos os arquivos de uma só vez com a opção –A (precisa ser A maiúscula). Ex.: git add –A

Git add adiciona tanto arquivos novos como arquivos modificados.

25. 
git commit [options]

Esse comando é utilizado para salvar uma nova revisão no repositório. Ao utilizar esse comando, os arquivos que foram enviados para o Index com o git add, são enviados para o HEAD e uma nova revisão é criada.

As opções mais utilizadas com esse comando são:

-a (minúsculo): adiciona os arquivos no Index que por algum motivo não tenham sido enviados anteriormente com git add. Essa opção só adiciona arquivos que foram modificados. Arquivos novos devem ser obrigatoriamente adicionados através do comando git add.

Ex.: git commit -a

26. 
-m: Essa opção permite cadastrar uma mensagem explicativa ao commit. É necessário fornecer a mensagem envolvida em aspas.

Ex.: git commit –m “Mensagem do commit”

É possível usar as duas opções em conjunto, adicionando os arquivos modificados ao Index e enviando-os para o HEAD com um só comando.

Ex.: git commit –am “Adicionando e enviando os arquivos de uma so vez”

Ao utilizar a opção –a em conjunto com a opção –m, é obrigatório seguir a ordem –am, caso contrário o git retornará uma mensagem de erro.

27. 
Padrão CW de mensagem de commit

Por padrão é necessário informar na mensagem de commit, o número da tarefa (ticket) que aquele commit se refere, assim o gerenciador de projetos (Redmine) consegue capturar e exibir as mensagens nas tarefas, facilitando o acompanhamento e gerenciamento das atividades.

O formato da mensagem é: “#0000 mensagem”, onde #0000 é o número do ticket aberto no Redmine.

Ex.: git commit –am “#1234 Ticket de número 1234 no Redmine”

28. 
git push <remote> <branch>

Esse comando é utilizado para enviar as revisões feitas no repositório local para o repositório remoto.

Caso o repositório tenha sido obtido através do comando git clone, o remote é configurado automaticamente. Um remote é formado por um nome e um endereço. Por padrão o git atribui o nome “origin” aos remotes.

Se um remote não for configurado, o desenvolvedor deve informar o endereço completo do repositório no servidor.

<branch> é o nome da branch que será enviada ou atualizada no servidor remoto.

Ex.: git push origin master

29. 
git pull <remote> <branch>

Esse comando é utilizado para obter a versão mais atual do repositório armazenado no servidor remoto. Simplificando, é o comando que atualiza seu repositório local com as atualizações do repositório remoto.

Se um remote não for configurado, o desenvolvedor deve informar o endereço completo do repositório no servidor remoto.

<branch> é o nome da branch que será atualizada no repositório local.

Ex.: git pull origin master

É muito comum confundir o comando push (envio) com o comando pull (recebimento).

30. Git submodules vs subtree

31. 
Git Submodule é uma funcionalidade do git que permite adicionar um outro repositório completo como dependência do projeto.

Git Submodule é utilizado quando uma dependência adicionada ao projeto precisará sofrer modificações durante o desenvolvimento do projeto. Geralmente é adicionado como submódulo plugins, extensões e/ou componentes desenvolvido pela CW.

Como um submódulo possui o repositório completo dentro do projeto, o desenvolvedor tem possibilidade de fazer alterações, criar branches, fazer push e tudo mais que um repositório git permite.

32. 
Todos os comandos do git funcionam com submodule.

git pull <remote> <branch> para atualizar o submódulo.

git checkout <branch> para mudar para outra branch.

git add [-A] [filename] para adicionar arquivos ao Index.

git commit -[a]m [message] para criar uma nova revisão.

git push <remote> <branch> para enviar as revisões locais para o servidor remoto.

33. 
Para adicionar um repositório como submódulo basta utilizar o comando: git submodule add [options] <remote> <dir>

Uma opção que pode ser usada é a –b <branch>, que permite adicionar um repositório como submóbulo determinando qual será a branch ativa ao fazer o clone. Ex.: git submodule add –b teste http://git.cw/repo.git components/teste

Ao adicionar um submódulo, o git salva a informação do commit mais recente daquele repositório como o commit ativo. É feito um clone do submódulo no estado HEADless, onde o checkout é definido no próprio commit e não na branch tenha ela sido especificada ou não.

34. 
Caso o desenvolvedor necessite fazer alterações no submódulo, é imprescindível que o mesmo execute um git checkout antes informando que branch irá utilizar para o desenvolvimento. Ex.: git checkout master

Caso não seja feito o checkout para uma branch, toda e qualquer modificação feita no submódulo será perdida ao atualizar o submódulo.

O git também armazena nas configurações do repositório do projeto dados sobre o submódulo como o endereço do repositório, o diretório em que está localizado e o commit da última alteração.

35. 
Após ter feito uma alteração no código do submódulo, o desenvolvedor deverá executar um commit e um push, para salvar uma revisão no repositório local e enviar para o servidor remoto: git commit –am “#1234 Salvando alterações ” git push origin master

Isso fará com que o submódulo possua um novo commit como o mais recente. Essa informação precisa ser repassada para o repositório do projeto principal.

Para isso, basta na linha de comando, mudar para a raiz do projeto e executar novamente um commit e um push. Assim, caso outro desenvolvedor faça clone do projeto, seus submódulos virão atualizados com o commit mais recente.

36. 
Para fazer um clone de um projeto que possui submódulos, basta adicionar a opção --recursive no comando. Ex.: git clone --recursive <remote> <dir>

Há duas formas de atualizar submódulos:

1 – git submodule update --recursive

2 – git submodule foreach git pull <remote> <branch>

A diferença entre os dois comandos é que o submodule update, força o checkout no commit mais recente, obrigando o desenvolvedor a executar um git checkout <branch> para mudar a branch ativa. O segundo comando, atualiza todos os submódulos executando um git pull em cada um deles, atualizando a branch informada sem realizar checkout no commit. O segundo comando é o mais indicado.

37. 
Caso o desenvolvedor tenha esquecido de adicionar a opção --recursive no git clone é possível obter os submódulos das seguintes formas:

1 – git submodule init --recursive

2 – git submodule update --init --recursive

O primeiro comando inicializa os submódulos mas não executa o clone, obrigando o desenvolvedor a utilizar o git submodule update sem a opção --init para baixar os arquivos.

Já a segunda opção baixa todos os submódulos recursivamente inicializando-os quando necessário. Lembrando que submodule update executa um checkout no commit, sendo necessário executar um git checkout <branch> para definir a branch de desenvolvimento.

38. 
Git Subtree é uma funcionalidade do git que permite adicionar um outro repositório como dependência do projeto.

Git Subtree é utilizado quando é necessário adicionar uma dependência de terceiros ao projeto. Pode ser adicionado um plugin, componente ou biblioteca e estes não sofrem modificações durante o ciclo de vida do projeto.

A dependência adicionada como subtree pode ou não possuir log (histórico) e não é permitido fazer commits. O objetivo é obter arquivos para o projeto sendo que os mesmos não serão alterados.

39. 
Git Subtree permite que a dependência seja atualizada através do comando: git subtree pull -P <dir> --squash <remote> <branch>

Para adicionar uma dependência basta utilizar o comando: git subtree add -P <dir> --squash <remote> <branch>

A opção -P <dir>, indica onde a dependência ficará localizada. Ela pode também ser especificada como --prefix. Ex.: git subtree add --prefix <dir> --squash <remote> <branch>

A opção --squash é utilizada para impedir que o git insira o log da dependência no log do projeto. Utilizando essa opção, será inserido no log do projeto apenas uma entrada informando a inserção de uma dependência. É aconselhável sempre usar esta opção.

40. 
<remote> é o endereço do repositório. Caso seja necessário, é possível adicionar o endereço da dependência como remote do projeto e utilizá-lo como alias no comando git subtree.

<branch> indica a branch que será baixada para o diretório especificado. OBS.: git subtree não permite trabalhar com tags, apenas branches.

Um detalhe interessante sobre subtree é que seus arquivos são baixados automaticamente durante o clone, não necessitando de comandos ou opções extras.

Ex.: git subtree add –P vendor/plugins/teste –squash http://git.cw/plugin.teste.git master Adiciona o plugin teste no diretório vendor/plugins/teste.

41. Diferenças entre git e svn

42. 
Repositório local vs Repositório remoto (svn)

Checkout parcial (svn) vs Git Clone

Merge automático em versões defasadas (mais de um desenvolvedor no mesmo projeto)

43. 
Livro do Git em português: http://git-scm.com/book/pt-br

Documentação do Git em inglês:

http://git-scm.com/docs

Guia prático de início ao Git em português:

http://rogerdudler.github.io/git- guide/index.pt_BR.html

Google e StackOverflow
Referências