WEB DEVELOPMENT
AGILE COACH
PRODUCT OWNER
FE/BE/FS
(DEVS)
UI DEV
QA
DEVOPS
UX
Slide 9
Slide 9 text
SOBRE O MINICURSO
Slide 10
Slide 10 text
BÁSICO
● SISTEMA DE CONTROLE DE VERSÃO (VCS)
● O QUE É O GIT?
● CONCEITOS BÁSICOS
● FORMAS DE TRABALHO
● PASTA .GIT
● .GITIGNORE
● ESTÁGIOS
● COMANDOS: STATUS, ADD, COMMIT, LOG,
DIFF, RESET, BLAME
● REPOSITÓRIOS REMOTOS
● COMANDOS: REMOTE, PUSH, PULL
● CLONANDO UM REPOSITÓRIO
● COMANDOS: CLONE
INTERMEDIÁRIO
● BRANCHING (CONCEITO)
● COMANDO: BRANCH
● CHECKOUT (CONCEITO)
● COMANDO: FETCH, CHECKOUT, STASH
● MERGE (CONCEITO)
● COMANDO: MERGE
● CONFLITOS
● BRANCHES REMOTAS
● REBASING (CONCEITO)
● COMANDOS: REBASE
● TAGGING (CONCEITO)
● COMANDOS: TAG
● PULL REQUEST
AVANÇADO
● VERSIONAMENTO SEMÂNTICO
● WORKFLOWS
Slide 11
Slide 11 text
COMANDOS
ETAPA
EXERCÍCIOS
10
Slide 12
Slide 12 text
YURI REIS
DEV FULL STACK
KOERICH ENGENHARIA
GESTÃO EM TI
FILHAS MARAVILHOSAS
TDC, AGILE TESTERS CONFERENCE
RPG, RTS, FIGHTING
FRONTEND, PYTHON, TESTES
Slide 13
Slide 13 text
YURI REIS
DEV FULL STACK
KOERICH ENGENHARIA
ANGULAR, ANGULARJS, GULP,
SASS, BOOTSTRAP 4
FLASK, EXPRESS, .NET CORE
PYTHON, C#, TYPESCRIPT,
HTML, CSS, JAVASCRIPT
MYSQL, MONGO (NOSQL)
DOCKER
Slide 14
Slide 14 text
SISTEMAS DE CONTROLE DE VERSÃO (VCS)
{ CVS, SVN }
Slide 15
Slide 15 text
GIT
SISTEMA DE CONTROLE DE
VERSÃO DISTRIBUÍDO
DISTRIBUÍDO, RÁPIDO E NATURAL
CARACTERÍSTICAS:
Slide 16
Slide 16 text
CONCEITOS BÁSICOS
TIME
CAPSULE
BRANCH
COMMIT
WORKING
TREE
REPO
Slide 17
Slide 17 text
CLI
INTERFACE DE LINHA DE COMANDO
CLI
INTERFACE GRÁFICA DE USUÁRIO
FORMAS DE TRABALHO
Slide 18
Slide 18 text
10
Slide 19
Slide 19 text
1) Criar pasta para o projeto
2) Abrir a pasta do projeto com o VSCODE
3) Inicializar o repositório (comando: git init)
4) Configuração de usuário local:
a) git config --global user.name "seu username"
b) git config --global user.email “[email protected]”
(criar conta, realizar o set up de usuário e inicializar o repositório local)
3
Slide 20
Slide 20 text
.git
Slide 21
Slide 21 text
.gitignore
Slide 22
Slide 22 text
ESTÁGIOS
Slide 23
Slide 23 text
COMMIT: DESCREVER O COMANDO AQUI
STATUS: apresenta o nome da branch que você está, além de listar os arquivos
que foram modificados na “WORKING TREE” (separados por estágios)
git status
ADD: apresenta o nome da branch que você está, além de listar os arquivos que
foram modificados na “WORKING TREE”
git add -A
Slide 24
Slide 24 text
COMMIT: Cada vez que você salva ou consolida o estado do seu projeto
git commit -m “mensagem clara e curta”
-- AMEND: adiciona os arquivos alterados (ou novos) que estão na staging
area ao último commit
git commit --amend
Slide 25
Slide 25 text
LOG: apresenta todos os commits (e responsável por eles), começando do mais novo
git log
DIFF: apresenta o antes e o depois dos arquivos que foram modificados na
“WORKING TREE”
git diff
Slide 26
Slide 26 text
RESET HEAD: faz a reversão do estágio do(s) arquivo(s) para a “STAGING
AREA”
git reset HEAD
--HARD: acrescentando esse parâmetro, faz a reversão do estágio do(s)
arquivo(s) para a “WORKING AREA”
git reset --hard HEAD
BLAME: quem realizou as alterações em um determinado arquivo e quando
git blame <>
Slide 27
Slide 27 text
1) Criar um arquivo do tipo .txt
2) Executar o comando git status (arquivo do tipo .txt deverá aparecer
na “WORKING AREA”)
3) Criar o arquivo .gitignore
4) Editar o arquivo .gitignore e colocar o seguinte texto: *.txt
5) Executar o comando git status (o arquivo txt não deverá aparecer na
“WORKING AREA”)
6) Adicionar o arquivo .gitignore para a STAGING AREA (git add -A)
7) Realizar o commit com a seguinte frase: “Ignorando arquivos txt da
pasta raiz”
(realizar o primeiro commit)
10
REMOTE: adiciona a referência a um repositório remoto através de um alias
git remote add origin <>
PUSH: empurra as alterações para a nuvem
git push origin master
PULL: “puxa” as atualizações existentes em relação a branch que você referenciar
git pull origin master
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
1) Realizar cadastro no GITHUB
2) Criar um repositório
3) Copiar o link com o protocolo https
4) Adicionar o host remoto (git remote add origin <>)
5) Realizar o push da branch master para a nuvem
6) Atualizar o repositório remoto e verificar se o código está lá.
(disponibilizar o código na nuvem)
10
Slide 32
Slide 32 text
CLONANDO UM REPOSITÓRIO
LOCAL NUVEM
Slide 33
Slide 33 text
CLONE: realiza a cópia de um repositório remoto para a máquina local
git clone <>
Slide 34
Slide 34 text
1) Excluir o repositório local
2) Realizar o clone do projeto
(realizar o processo de clone)
2
Slide 35
Slide 35 text
BRANCHING
FEATURE/1
FIRST COMMIT
COMMIT 1 COMMIT 2
MASTER
FEATURE BRANCH: NOVAS FUNCIONALIDADES/CORREÇÕES/REFACTORY
Slide 36
Slide 36 text
BRANCH: lista as branches existentes (localmente)
git branch
<>: cria uma branch nova (localmente) com
base na branch que você está “checado”
git branch <>
-D: remove a branch (é necessário dar checkout da mesma, ou seja, não
estar nela) localmente
git branch -D <>
Slide 37
Slide 37 text
CHECKOUT
>>
USUÁRIO REPOSITÓRIO
REMOTO
REPOSITÓRIO
LOCAL
1. Usuário faz
checkout
1.1 Possui branch e
permite o checkout
1.2.1 possui branch e
permite checkout
1.2 não possui branch
localmente
1.2.2 não possui branch
e não permite checkout
Slide 38
Slide 38 text
FETCH: sincroniza as informações locais com o que está no remoto
git fetch
CHECKOUT: sai de uma branch e vai para outra
git checkout <>
STASH: guarda todo o conteúdo da “WORKING AREA” e da “STAGING AREA” em
uma pilha (stash)
git stash
Slide 39
Slide 39 text
MERGE
MASTER BRANCH “A”
MASTER = (MASTER U BRANCH “A”)
BRANCH PARA O “MERGE”
BRANCH A SER “MERGEADA”
Slide 40
Slide 40 text
MERGE: processo de...
git merge <>
Slide 41
Slide 41 text
1) Dar checkout da master para a branch feature/1
2) Criar um arquivo novo com algum conteúdo dentro
3) Realizar o commit deste arquivo
4) Dar checkout novamente para a master
5) Realizar o merge da branch feature/1 na master (localmente)
6) Verificar com o comando log se o commit da feature/1 está na master
(ver pela mensagem)
7) Dar o push da master para a nuvem
(realizar o merge localmente)
10
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
CONFLITOS!
O QUE É?
- Duas pessoas alteram
o mesmo arquivo, na
mesma linha.
COMO LIDAR?
- Melhorar a qualidade
dos conflitos.
- Diminuir a frequência
em que ocorrem.
- Não realizar commits
diretamente em
branches “longevas”.
- Manter o histórico
linear. (sem commits
de merge)
- Realizar Rebase
Slide 44
Slide 44 text
BRANCHES REMOTAS
● São referências ao estado de seus branches
no seu repositório remoto.
● São branches locais que você não pode
mover, eles se movem automaticamente
sempre que você faz alguma comunicação via
rede.
O QUE SÃO? UTILIDADE
● Branches remotos agem como
marcadores para lembrá-lo onde
estavam seus branches no seu
repositório remoto na última vez que
você se conectou a eles.
● Também servem para comparação com
as branches de base para merge
● Permite visualização para code review
Slide 45
Slide 45 text
PUSH: empurra as alterações para a nuvem
git push origin <>
Slide 46
Slide 46 text
1) Dar checkout para a master (caso não esteja)
2) Criar uma branch nova a partir da master (feature/2)
3) Dar o push da branch nova para a nuvem
(disponibilizar uma branch nova na nuvem)
5
REBASE: realinha a história de uma branch em relação a sua branch base
(possívelmente o alvo para merge)
git rebase master
Slide 49
Slide 49 text
1) Dar checkout para a master localmente
2) Criar uma branch nova a partir da mesma (feature/3)
3) Adicionar um arquivo novo com algum conteúdo
4) Realizar o commit deste arquivo
5) Dar checkout para a master
6) Realizar o merge da nova branch (feature/3) na master
7) Dar checkout para a feature/2
8) Realizar o rebase com a master
9) Dar push da feature/2 para a nuvem
(realizar o rebase)
10
Slide 50
Slide 50 text
TAGGING
- commit (hash)
- branch (HEAD)
- tag
3x CHECKOUT
TAG: marcar uma hash de uma maneira legível para humanos
Slide 51
Slide 51 text
TAG: realiza a listagem de tags (locais)
git tag
<>: realiza a marcação da hash de commit com um nome
git tag <>
PUSH <>: disponibiliza a tag na nuvem
git push origin <>
Slide 52
Slide 52 text
PULL REQUEST
● Envolve a branch base e a branch de
comparação
● Processo fornecido pelos serviços de
repositório
● Permite a comparação entre as branches
O QUE É?
Slide 53
Slide 53 text
1) Dar push da master para a nuvem
2) Fazer checkout da master para uma nova branch (feature/4)
3) Modificar o conteúdo dos arquivos existentes na branch
4) Adicionar alguns arquivos e conteúdo dentro dos mesmos
5) Realizar o commit
6) Dar push da branch nova para a nuvem
7) Ir até o serviço de repositório remoto e criar o pull request
8) Validar as alterações e fazer o merge na modalidade fast-foward
9) Verificar os commits da master da nuvem e se certificar de que os
commits estão na mesma
(realizar merge através de pull request)
15
Slide 54
Slide 54 text
VERSIONAMENTO SEMÂNTICO
MAJOR: versão que marca uma quebra de compatibilidade com a anterior
MINOR: versão que adiciona uma funcionalidade que tem compatibilidade com a versão major
PATCH: versão que marca uma correção compatível com a versão minor
MAJOR.MINOR.PATCH
(v0.0.0)
Slide 55
Slide 55 text
FLUXOS DE TRABALHO
CENTRALIZED WORKFLOW
- Centrado na master
FEATURE BRANCH WORKFLOW
- Master é sagrada!
- Funcionalidades são
desenvolvidas em
branches separadas,
sem incomodar o código
principal
- Permite discussões
acerca da branch
GIT FLOW
- Foi apresentado por
Vincent Driessen
- Desenhado para as
releases de projeto
- Para gerenciar projetos
grandes
- Trabalha com duas
branches de longa vida:
master e develop
- Branches de vida curta:
feature, release e hotfix
Slide 56
Slide 56 text
FLUXOS DE TRABALHO
GIT FLOW (COMEÇO)
MASTER
DEVELOP
HEAD
HEAD
(v0.0.0)
Slide 57
Slide 57 text
FEATURE/1
FLUXOS DE TRABALHO
GIT FLOW (FEATURE~DEVELOP)
DEVELOP
COMMIT 1 COMMIT 2
(v0.1.0)
Slide 58
Slide 58 text
FLUXOS DE TRABALHO
GIT FLOW (HOTFIX)
MASTER
DEVELOP
(v0.0.1)
COMMIT 3
HOTFIX/1
(v0.1.0)
COMMIT 3
Slide 59
Slide 59 text
FLUXOS DE TRABALHO
GIT FLOW (RELEASE)
MASTER
DEVELOP
(v0.0.1)
COMMIT 4
RELEASE/1
(0.1.0)
(v0.1.0 ~ HEAD)
(v0.1.0 ~ HEAD)
Slide 60
Slide 60 text
FLUXOS DE TRABALHO
Perguntas:
“ Quando você está avaliando implementar
um
fluxo de trabalho para sua equipe, é mais
importante considerar a cultura da mesma.
Afinal, você quer implementar um
fluxo para
aumentar a efetividade da equipe e não para
ser um
fardo que limita a produtividade. “
- Este fluxo escala para o
tamanho da equipe?
- É simples desfazer os erros
com este fluxo?
- Este fluxo impõe qualquer
carga desnecessário para a
equipe?