O documento apresenta um minicurso sobre o sistema de controle de versão Git. Resume os principais tópicos a serem abordados como instalação, conceitos básicos, áreas de trabalho, commits, branches, tags e boas práticas. Fornece também informações sobre o palestrante e links para referências adicionais.

1. Minicurso GIT
Danilo Pinotti

2. Observações

3. Danilo Pinotti
- contato@danilopinotti.com.br
- danilopinotti.com.br
- github.com/danilopinotti
Tecnólogo em Sistemas para Internet (UTFPR
- Guarapuava, 2017)
Administrador de sistemas na Faculdade
Guarapuava (2017)
Desenvolvedor Sênior na empresa Lets
Sistemas (Atualmente)
Desenvolvedor Sênior na N1 Digital
(Atualmente)
Co-fundador e Desenvolvedor Web/IoT na
Trigy (Atualmente)

4. Roteiro
● Sistema de controle de versão (VCS)
● Comparativo
● Sobre o Git
● Instalação
● GitHub
● Primeiros passos
● Gerenciamento de índice
● Branches
● Stashes
● Boas práticas
● Repositórios online

5. Por que usar sistema
para controle de
versão ?

6. Por que usar sistema para controle de
versão ?

7. Por que usar sistema para controle de versão ?
● Versionamento
● Armazenamento e Segurança contra perda de informações
● Trabalho Simultâneo
● Contar a História

8. Organizar o desenvolvimento de software
● Visualizar as mudanças ocorridas em cada arquivo;
● Visualizar o estado do projeto em etapas anteriores;
● Desfazer mudanças;
● Desenvolver funcionalidades em paralelo.

9. Compartilhar projetos
Utilizar Dropbox, pen drives ou afins para compartilhar código muitas
vezes resulta em dor de cabeça.

10. ● Trabalhos da faculdade/curso
● Controlar arquivos pessoais
● Exemplos e exercícios feitos
● Iniciar o seu portfólio na web
Outras utilizações da ferramenta

11. Comparativo

12. Comparativo

13. Comparação de Desempenho entre Subversion, Mercurial e
Git
Versões Usadas na Comparação
06/2012 07/2016
Subversion 1.7.5 1.9.3
Mercurial 2.2.1 3.8.4
Git 1.7.10 2.9.1

14. Operações Avaliadas
1. Criação/clonagem de um repositório.
2. Adição de arquivos
3. Consolidação
4. Visualização do estado, histórico e das diferenças
5. Mesclagem (Merge)
6. Comunicação entre repositórios (pull e push)

16. Análise dos Resultados
Segundo Jakob Nielsen, há três limites de tempo de resposta que percebemos:
● Abaixo de 100ms. Percebido como resposta instantânea.
● Abaixo de 1s. Nota-se o atraso, mas o usuário mantém o fluxo de pensamento.
● Até 10s. Depois disso, os usuários tendem a executar outras atividades enquanto esperam a
operação terminar.
Nenhuma das três ferramentas apresentou um tempo de resposta demorado o suficiente para que
o desenvolvedor tenha motivo para se distrair com outras coisas.

17. Sobre o
Git

18. O que é GIT
➔ Sistema de controle de versão de arquivos.
➔ Projetos na qual diversas pessoas podem contribuir simultaneamente
➔ Sem risco de suas alterações serem sobrescritas pela ferramenta.

19. GIT
O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o
desenvolvimento do kernel Linux
● Git começou em 3 de Abril de 2005;
● Anunciado em 6 de Abril de 2005;
● Tornou-se auto-hospedeiro no dia 7 de Abril de 2005;
● A primeira mescla de arquivos (merge) em múltiplos ramos (branches) foi
realizado em 18 de Abril;
● Torvalds alcançou seus objetivos de performance; em 29 de Abril;
● 16 de Junho, a entrega do kernel 2.6.12 foi gerenciada pelo Git.

20. Independência de Plataforma

21. Quem usa GIT ?

22. Conceitos
básicos
GIT

23. Primeiros passos: Conceitos básicos
Git != Github
Áreas do Git
● Working area - Ambiente de trabalho
● Staging area - Área de índice
● Local repository - Repositório local

24. Primeiros passos: Estrutura de um commit

25. Primeiros passos: Sistema de Snapshot

26. Primeiros passos: Sistema de Snapshot

27. Vamos à prática !

28. Instalação

29. Instalação do GIT: Linux
Fedora:
#> yum install git-core
Debian/Ubuntu:
#> apt-get install git

30. Instalação do GIT: Windows
http://msysgit.github.com
https://git-scm.com/downloads

31. Primeiros
Passos

32. Configurações Iniciais
$> git config --global user.name “Bilbo”
$> git config --global user.email “bilbo@condado.tm”
$> git config --global color.ui true
$> ssh-keygen -C “seu@email.com.br”

33. GitHub

34. GitHub
● Social Network;
● Free para Open Source Projects;
● Compatível com Mercurial,
Subversion;
● Github educacional;
● Comprado pela Microsoft em 2018;
● CI/CD, Boards, Copilot, etc

35. GitHub
1. Criar conta;
2. Configurar conta;
3. Criar repositório;
4. Clonar repositório.

36. Primeiros passos
● Pasta .git
● Arquivos .gitignore e .gitkeep
● Ler mensagens fornecidas pelo git.
● Oh-my-zsh

37. Primeiros passos
Inicializando um repositório git:
$> git init
Comando para ajuda:
$> git help <comando>
$> git help init

38. Primeiros passos: Commits
Verificar estado dos arquivos do projeto:
$> git status
Adicionar modificações na área de staging:
$> git add <files/directories>
Remover modificações da área de índice:
$> git restore --staged <files/directories>

39. Primeiros passos: Commits
Realizar um commit e enviar modificações para o repositório local:
$> git commit -m “Descrição do commit”
Verificar histórico de commits:
$> git log

40. Áreas de trabalho do git

41. Áreas de trabalho do git: $> git add

42. Áreas de trabalho do git: $> git restore --staged

43. Áreas de trabalho do git: $> git commit

44. Gerenciamento
de índice

45. Gerenciamento de índice
Refazer um commit:
$> git add <modificações para serem incluídas>
$> git commit -m “first commit” --amend
Ou
$> git commit -a -m “created scaffold for posts” --amend
Cuidado! Não refazer um commit em caso de já tê-lo enviado para o servidor
remoto.

46. Ignorando arquivos
Arquivo .gitignore
Exemplo:
/.bundle.
/db/*.sqlite3
/log/*.log
/tmp
Forçar o arquivo ignorado a ir para a área de índice
$> git add <file> -f

47. Desfazer um commit (hard, não recomendado)
Desta forma será revertido o commit e todas as alterações contidas nele serão
violentamente apagadas.
Voltar um commit (~1)
$> git reset HEAD~1 --hard
$> git status

48. Desfazer um commit (soft, não recomendado)
Desta forma será revertido o commit mas as alterações contidas nele voltarão
para a área de índice.
Voltar um commit (~1)
$> git reset HEAD~1 --soft
$> git status
Retirar modificações do índice
$> git reset HEAD

49. Reverter um commit (recomendado)
Há uma terceira forma de voltar as modificações de um commit, bastando
revertê-lo. Reverter um commit significa aplicar modificações opostas.
$> git revert <hash_do_commit>

50. Alguns comandos básicos
git init Cria um repositório
git status Avalia estado dos arquivos no diretório de trabalho e no
índice
git add Adiciona ao índice
git restore --staged Retira o arquivo/modificação do índice
git checkout Reinicia arquivo modificado fora do índice (passeio pelo
projeto)
git commit Grava conteúdo do índice e coloca no repositório
git log Mostra o histórico dos commits no repositório

51. Fluxo simplificado

52. Tags

53. Tags
- O que são ?
- Para o que servem ?

54. Tags: comandos
Criar Tag
$> git tag <tag_name> -m “<tag_description>”
Ver tags:
$> git tag

55. Tags: comandos
Checkout na tag:
$> git checkout <tag_name>
Enviar tags para o servidor
$> git push origin --tags

56. Branches

57. Branches
O Git permite criar uma linha independente de desenvolvimento no seu projeto.
Isto permite alterações em partes específicas do software sem comprometer o
restante do projeto.
Verificar branches e branch corrente:
$> git branch

58. Branches: Criando ramificações
Comando para criar uma branch:
$> git branch <branch_name>
Ou
$> git checkout -b <branch_name>
A Branch é criada a partir do commit mais recente.

59. Branches: Trocar branch corrente
Para “navegar” entre as branches é usado o comando “checkout” da seguinte
forma:
$> git checkout <branch_name>
PS: O comando “checkout” além de permitir navegar entre os commits do projeto,
também é responsável por alterar a branch corrente.

60. Branches: Unindo ramificações por Pull Request
Quando estamos trabalhando em grupo, é importante termos controle do que será
de fato adicionado à branch principal (master). Para isso, devemos abrir uma PR
(Pull Request) no Github.
- Ver na prática

61. Branches: Unindo ramificações Localmente
Após desenvolver uma funcionalidade separada do fluxo principal, muitas vezes é
interessante incorporar as modificações no branch master.
Para realizar esta tarefa é utilizado o comando “merge” na branch que será usada
como base.
$> git checkout master
$> git merge <branch_name>

62. Branches: Deletando ramificações
Após o merge, muitas vezes a branch não será mais necessária localmente,
podendo assim ser apagada.
$> git branch -d <branch_name>

63. Stashes

64. Situação
Você está desenvolvendo novas funcionalidades;
Surge um bug em outra parte do sistema para resolver;
Você não quer “commitar”, pois ainda não terminou a adição das funcionalidades.

65. Stash
➔ 4ª área do git.
➔ Área temporária.

66. Usando Stashes
Adicionar modificações na área de staging
$> git add .
Mover modificações para uma stash
$> git stash
Ou
$> git stash save “Description”
Re-aplicar modificações movidas para a stash
$> git stash apply
Ou
$> git stash pop

67. Usando Stashes: comandos
Aplicar stash mais recente e apagá-la:
$> git stash pop
Apagar stash:
$> git stash drop stash@{ID} # => Ver ID através do comando $ git
stash list
Transformar stash em branch:
$> git stash branch <branch_name> [<stash>]

68. Usando stashes: comandos
Apagar todos os stashes gravados:
$> git stash clear

69. Boas
Práticas

70. Sobre commits
- Frases descritivas e diretas;
- Não tenha medo de realizar commits;
- Formato:
- Começar com letra maiúscula;
- No máximo 50 caracteres;
- Não colocar ponto no final;
- Nunca em primeira pessoa.
- Commits devem ser mudanças pequenas e completas no código
- Aplicação deve funcionar sem eles.

71. Sobre Branches
- NÃO trabalhar diretamente na branch master, ou seja, os commits nela
registrados são feitos apenas via merge;
- As branches podem ser marcadas de acordo com suas finalidades, por
exemplo:
- hotfix/[número-da-versão]
- feature/new-calculator

72. Repositórios
online

73. Sincronizar
Enviar modificações para o servidor:
$> git push <remote_name> <branch_name>
$> git push origin master
Baixar atualizações do servidor:
$> git pull <remote_name> <branch_name>
$> git pull origin master
OBS: git pull = git fetch + git merge FETCH_HEAD

74. Sublime Merge
Sublime Merge

75. Dúvidas ?

76. Obrigado

77. Contato
contato@danilopinotti.com.br
danilopinotti.com.br
github.com/danilopinotti

78. Referências
https://www.nngroup.com/articles/response-times-3-important-limits/
https://blog.pronus.io/posts/vantagens-e-desvantagens-do-controle-de-versao-distribuido/
https://pronus.io/
https://git-scm.com/