Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Introdução ao GIT e Exercícios

Introdução aos conceitos de Controle de Versão Centralizado, principais conceitos e comandos do Git, mostrando inclusive nas telas do TortoiseGit.
by

Marcio Rosner

on 7 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Introdução ao GIT e Exercícios

reconhecido pelo mercado:
seja
diferente!
mas completamente
um
- vcs classico
clientes
repositorio
- vcs distribuído
muitos
repositórios
muitos
clientes
ágil
@
em qualquer lugar da JE
muitos
home
Tribunal
@
@
sourcetree
ide
clientes
smartgit
windows
osx
trabalhe
distribuído
em determinado Tribunal
local
feito para ser rápido
excelente
~30x
grandes
compressão
from atlassian - free!
tortoisegit
egit
integrated
source control provider
console
bash completion
colorized
superb help
conexão ssh, https, git, local
autenticação com chave privada
Explorando
Filosofias
a ferramenta
git
svn....
é como o
é um sistema de controle de versão para gerenciar seu código.
mais de perto
vamos olhar
desconectado
da rede
sem
não importa
da justiça
eleitoral
zona eleitoral?
secure
clientes tem só uma
copia de trabalho
cliente tem um


sincronizar para qualquer outro
multiplos remotos? sem problema!
repositorio git completo
mais rápido que o svn
feito para
repositórios
Obs: em média (devido a crompressão e operações locais). Não perceptível para redes rápidas e/ou projetos pequenos.
historic linux kernel:
~175MB pack for 63428 commits
um clone git é um pouco maior que uma cópia de trabalho do svn - mas com um HISTÓRICO COMPLETO!
Pegue o GIT:
fast branching
efficient merging
"snapshot" view
working on features
fast copy
"file & folder" view
working on "trunk"
Introdução ao Git
em uso no CNJ/PJE
NO FUTURO...
Controle de versão centralizado
Controle de versão distribuído
(ideal para Fábrica)
Outras Vantagens
Identifica versões por Hash SHA-1, garantindo também a integridade: não é possível modificações ou corromper arquivos sem o git saber
Experimentação descartável:testar novas idéias de forma independente.
Reversão do commit remoto
Edição e correção do commit local
Mudança de tarefa instantânea: Área de stash (trabalho incompleto)
Rastreamento de revisões: MERGE fácil e automático (3-way merge)
Integra com o SVN se necessário
As principais diferenças
o projeto inteiro é versionado, não os arquivos individualmente
Criar branch's é barato e o merge é extremamente rápido
Acesso aos arquivos sem repositório central ou conexão
Maior parte das operações são locais: sem consumir rede ou processamento no servidor remoto.
O repositório local possui o histórico completo
Sincronização parcial entre colaboradores
Permite desenvolvimento orientado a tarefa: uma branch por tarefa (cada mudança reflete uma tarefa)
Controle de versão distribuído
Exercícios:
http://try.github.com
http://git-scm.com
Conceitos e Comandos básicos
Manual do GIT:
http://git-scm.com/book/pt-br
Configurando
git config --global user.name "Marcio Rosner"
git config --global user.email "marcio.rosner@tse.jus.br"
Help
git help "comando"
Alguns comandos básicos
git init :
para criar um repositório na pasta atual
ou
git clone :
cria uma cópia local de um repositório remoto (na pasta atual).
git add . :
adiciona todos os arquivos (fora do controle de versão e os modificados) ao stage
git commit -m "primeiro commit" :
faz o commit
git status :
mostra o status dos arquivos na pasta local
git diff :
visualiza as modificações
git diff --cached :
visualiza o que foi modificado e está staged
git commit -am "mensagem" :
comita diretamente sem passar pelo staging area
git log :
exibe o histórico com informações dos commits
git log --oneline :
exibe o histórico em uma linha (resumido)
git checkout <branch> :
move o ponteiro de HEAD para o destino, neste caso, muda para a branch informada (se já existe).
git rm (--cached) <arquivo> :
remove um arquivo do repositório (cached = também do stage)
git checkout -b <branch> =
git branch <nome> :
cria uma nova branch (a partir do commit atual, ie, apontado pela HEAD)
git branch + git checkout
HEAD =
referência (ponteiro) para onde estamos (branch, commit ou tag)
git checkout <hash> -- <arquivo> :
traz o "arquivo" no commit "hash"
git tag <nome>:
git tag <nome> <hash>:
git tag <nome> -a -m "msg"
cria uma tag (à partir do commit apontado por HEAD). se for passado também o <commit>, cria a tag para este. "-a" = tag anotada.
git reset <commit> :
seta a HEAD da branch atual para o commit informado. Com --hard, atualiza os arquivos locais. Ou seja, está voltando no histórico !
git diff <hash1> <hash2> :
compara 2 commits
git merge <outraBranch> :
faz o merge na branch atual do conteúdo da outraBranch
Comandos Especiais
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
README | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
"Fast forward"

=
merge de um commit com outro que pode ser alcançado seguindo o histórico do primeiro, o Git move o ponteiro adiante
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).

$ git checkout master
$ git merge iss53
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Obs.: Se for o caso, use
git status
para ver os conflitos
.
Integrando com Rebase
Criando 1 branch:
Relembrando com merge:
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
Com rebase:
Agora é possível fazer merge fast-foward no master:
Outro exemplo:
$ git rebase --onto master server client
Obs.: Em caso de conflito use o git diff para localizá-los
Trabalhando com repositórios remotos
master =
branch de desenvolvimento default
origin =
repositório remoto default (Origin é uma convenção para o primeiro remote). Ex.:
git.tse.jus.br
Criado por
Márcio Rosner


Aumentando o Buffer
git config --global http.postBuffer 524288000
[http]
postBuffer = 52428800
Instalação no Windows
1 - Instalação do Git
2 - Instalação do TortoiseGit
Controle de Versão
Apóia o desenvolvimento com:
Histórico
Quem fez o quê, quando e onde.
Colaboração
Vários trabalham em paralelo (sem sobrescrever o trabalho do outro)
Variações no projeto
Linhas diferentes de evolução do mesmo projeto.
Projetos Distribuídos
PAE
Desenvolvimento
Mobile

FÁBRICA DE SOFTWARE
Controle de Versão
Topologia em estrela (cliente-servidor).
Único repositório central e várias cópias de trabalho.
Centralizado x Distribuído
múltiplos repositórios locais em vez de apenas um único central.
o acesso a rede só é necessário para sincronização.
o trabalho continua mesmo sem conexão: maior parte das operações (e processamento) são locais.
a conexão ao repo central é pré-requisito para o trabalho: a comunicação de 2 áreas de trabalho passa pelo servidor.
grandes projetos + muitos acessos = deteriora acesso ao servidor (+banda, + processamento).
Vantagens do modelo distribuído
Maior rapidez
Autonomia
Ramos privados sem interferir nos demais
Facilidade na mesclagem
Maior confiabilidade
Redução de custos no servidor
ramos são criados no repo central
ramos privados são locais: permite desenvolvimento orientado à tarefa com experimentação descartável.
mesclagem automática por DAG (Grafo Acíclico Direcionado) - 3-way-merge
repo central = processador central das requisições
os repositórios dos desenvolvedores são backup
Centralizado
Distribuído
Obs.:
- alterações no Master podem ser sobrescritas por um pull
- e um conflito no Master paralisa seu trabalho
- Erro comum do usuário do Tortoise SVN: no pull e push (marca apenas conflitos resolvidos, esquecendo dos outros arquivos alterados)
git clone repo pasta
(Clona um repositório e add o repo como origin na pasta)
git remote add origin repo
(Adiciona um repositório como remoto)
git push origin <branch>
(Envia os commits locais para o repositório remoto em um
determinado branch)
git pull
(Atualiza a partir do repositório remoto default, o origin)
Similar a usar "fecth" + "merge")
Repositório Remoto
Repositório Local
Pasta de trabalho
git fetch
git fetch origin
(Traz as mudanças do repositório remoto, mas não integra ao HEAD)
git push origin master
git push origin v1.0
(Envia a tag v1.0)
git push --tags
(Envia todas as tags)
Repositório Remoto
Repositório Local
git push
Help:
git help <comando>
Branch
MASTER
Branch
STABLE
Tag 1.0
Tag 1.1
Fluxo Git padrão com a Fábrica do TSE
Branch Local
(desenvolvedor)
HOTFIX
BUG !
Merge
de release
Merge
de release
Estratégias de ramificações
Manutenção caótica (organização imatura)
Estratégias de ramificações
Objetivos de uma estratégia de ramificação:
Desenvolvimento em paralelo

Isolamento entre desenvolvedores e equipes
customização para diferentes clientes ou plataformas
outros...
ramo principal com evoluções e correções
impossível separar correção de evolução
usuários de uma versão recebem nova funcionalidade junto com correção
Estratégias de ramificações
Manutenção em série
ramo principal com evoluções
ramos auxiliares com correções
foco em cliente único
Estratégias de ramificações
Uma branch por feature
ramo principal para integração
ramos auxiliares com features
permite a identificação de cada feature
possibilita a remoção de uma feature
trabalho em paralelo e independente
Obs.: integração deve ser frequente
funcionalidade, correção de bug, tarefa, história ou qualquer segmento de trabalho.
agrupa o trabalho a ser feito de forma funcional
permite o desacoplamento das features
builds e testes independentes: um commit de um desenvolvedor não quebra o trabalho do outro
tem vários commits
toda a feature é integrada, e não commits individuais.
cada feature pode gerar uma release para produção
RAMIFICAÇÕES
Alterando Merge, conflitos e histórico
Estratégias de merge
Estratégia Octopus
resolve casos com mais de 2 heads (exceto conflitos que exija resolução manual). É o default para pull e merge com mais de 1 branch (atual + 2).
Estratégia Ours:
Resolve qualquer quantiadade de heads, considerando sempre como resultado a head atual, isto é, ignorando as mudanças de todas as outras branches. (Diferente da opção ours da estratégia recursive).
Estratégias de merge
Estratégia Subtree
Esta é uma modificação da estratégia "recursive": Quando tenta fazer o merge de duas árvores A e B, se B é uma sub-árvore de A, B primeiramente é ajustado para ter a mesma estrutura de A, ao invés de ler as duas árvores no mesmo nível. Esse mesmo ajuste é feito na árvore ancestral em comum.
git cherry-pick
Melhor opção quando as branchs divergem (e o merge não interessa)
git cherry-pick <hash do commit>
: cria um novo commit
git cherry-pick -n <hash do commit>
: não cria um novo commit
git cherry-pick -x <hash do commit>
: cria o commit com uma msg indicando de onde a mudança original veio
Aplicando um commit em outra branch
git cherry-pick C D E
Resolvendo Conflitos
identificando o conflito
resolvendo o conflito manualmente:
$git commit -am "conflito resolvido"
vendo o conteúdo do arquivo com conflito
resolvendo o conflito graficamente:
$git mergetool"
Sugestão: instale o KDiff3 e altere o .gitconfig para:
escolha uma versão para sobrescrever o conflito:
$git checkout --theirs (--ours) -- teste.txt
Estratégias de merge
Para git merge e git pull:
git <merge/pull> -s <estratégia> -X<opção da estratégia>
Estratégia "resolve":
resolve apenas 2 heads (a branch atual e de onde foi feito o pull) usando o algoritmo 3-way merge.
Estratégia "recursive":
resolve apenas 2 heads usando o algoritmo 3-way merge. Quando tem mais de um ancestral, faz um merge dos ancestrais e usa o resultado com o referência para o 3-way merge. Detecta "renames". É a estratégia default. Tem as seguintes opções:
Theirs
- ao contrário da Ours.
Ours
- resolve os conflitos em "favor" da "nossa" versão.
... mais 9 opções:
https://github.com/git/git/blob/master/Documentation/merge-strategies.txt
Mudando o histórico
$git rebase -i HEAD~N ou <commit>
- Permite editar/excluir/trocar os últimos N commits:
Obs.: Não inclua nenhum commit que você já enviou a um servidor central — fazer isso irá confudir outros desenvolvedores fornecendo uma versão alternativa da mesma alteração
p, pick = use commit
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
f, fixup = like "squash", but discard this commit's log message
x, exec = run command (the rest of the line) using shell
Efeito máquina do tempo
Eliminando o commit "D":
Juntando os commits "C" e "D":
Trabalhando no Projeto
1-
Clonar o projeto (é criada a branch MASTER)
2-
Crie uma nova branch com o nome da DEMANDA para fazer o trabalho (com vários commits)
3-
Volte a branch MASTER e atualize-a (PULL)
4-
Se houve mudanças na Master, volte a branch da DEMANDA para atualizá-la com o REBASE
5-
Envie a branch da DEMANDA para o servidor: PUSH
6-
Entre no site do Gitlab (http://git.tse.jus.br) e crie um MERGE REQUEST
http://www.wei-wang.com/ExplainGitWithD3
http://pcottle.github.io/learnGitBranching/
http://www.ndpsoftware.com/git-cheatsheet.html
DICAS:
UNGIT - Ferramenta visual para Git
EXERCÍCIO 1 - Configurações Iniciais
1) Abra o terminal do Git (Git Bash) pelo ícone e verifique em que pasta ele abre por default
2) Realize as configurações iniciais de nome e email (globalmente) no Git
3) Aumente o buffer inicial do Git para 50 Mb
4) Gerar o par de chaves público/privado e averiguar em que pasta os arquivos são gerados. Identifique também o nome dos arquivos.
Dicas:
Use o comando:
ssh-keygen -t rsa -C "seu-email@tse.jus.br"
E dê <Enter> em todas as opções
pwd : /"Unidade"/Users/"seu_usuario"
git config --global user.name "Márcio Rosner"
git config --global user.email "marcio.rosner@tse.jus.br"
git config --global http.postBuffer 52428800
Pasta: "Unidade"/Users/"seu_usuario"/.ssh
Arquivos: id_rsa e id_rsa.pub
Configurações Especiais
1) arquivo
.gitignore
especifica quais arquivos fora do controle de versão o Git deve ignorar.
arquivos já no controle de versão não são afetados
2)

arquivo
.gitattributes
3) Alias: Pseudônimos
4) Hooks: scripts personalizados para determinado evento (.git/hooks).
para customizar o Git, aplicando algumas configurações específicas para algumas pastas ou conjunto de arquivos
Ex.: manual.pdf merge=ours
*.bpl binary (-crlf -diff -merge)
*.dfm text -whitespace
*.png diff=exif
(git config diff.exif.textconv exiftool)
Ex.: __history/
*.~*
*.dcu *.class
git config --global alias.co checkout
Ex.: post-checkout => git clean -f -X (apaga do .gitignore)
EXERCÍCIO 2
1) Crie uma pasta com o nome "exercicio2" e crie um repositório git nesta pasta
$ mkdir exercicio2 && cd exercicio2
$ git init
2) Crie um arquivo teste.txt e adicione-o ao index
$ echo '' > teste.txt
5) Verifique o status do projeto
$ git status
(changes to be commited:)
3) verifique o status do projeto
4) adicione o arquivo ao index
$ git add teste.txt ou git add -A ou git add .
$ git status
(Untracked files:)
6) Realize o commit
$ git commit -m "arquivo de texto criado"
7) Altere o arquivo teste.txt colocando o texto "Exercicio2" como conteúdo.
$ echo 'Exercicio2' > teste.txt
8) Verifique o status do projeto
$ git status
(Changes not staged for commit:)
9) Faça um diff
$ git diff ou git diff -- teste.txt
10) Adicione ao index
$ git add .
11) Veja novamente o diff e também o diff -cached
$ git diff
$git diff --cached
12) Realize o commit e veja o log
$ git commit -m "arquivo alterado"
$ git log OU git log --oneline
13) compare os 2 commits do log
$git diff HEAD~1 HEAD (a ordem é importante)
14) remova o arquivo teste.txt do controle de versão
$ git rm teste
15) Verifique o status do projeto
$ git status
Assinatura de commits
GPG = Gnu PGP (implementação free do OpenPGP )
PGP = Pretty Good Privacy
https://www.gnupg.org/download/index.html
Muito utilizado para assinar e criptografar emails
Gerando a chave gpg:
gpg --gen-key
listando as chaves:
gpg --list-secret-keys
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Marcio Rosner
Email address: marcio.rosner@tse.jus.br

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

Enter passphrase:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
......................+++++
.......+++++
gpg: key 2AE02E3D marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2016-03-21
pub 4096R/2AE02E3D 2015-03-22 [expires: 2016-03-21]
Key fingerprint = 150A B2DC B24B 3F69 908F 3343 89AB C62B 2AE0 2E3D
uid Marcio Augusto Alves Rosner <marcio.rosner@tse.jus.br>
sub 4096R/D6457CC7 2015-03-22 [expires: 2016-03-21]
sec 4096R/2AE02E3D 2015-03-22 [expires: 2016-03-21]
uid Marcio Augusto Alves Rosner <marcio.rosner@tse.jus.br>
ssb 4096R/D6457CC7 2015-03-22
exportando a chave pública para um arquivo ascii (para enviar por email)
gpg --export -a "User Name" > public.key
enviando sua chave para o servidor de chaves padrão do gnupg
gpg --keyserver hkp://pgp.mit.edu--send-key 2AE02E3D
KEYNAME = ID da chave.
importando a chave pelo arquivo ascii
gpg --import public.key
usando a chave no Git
git config --global user.signingkey 2AE02E3D
Assinando um commit:
git commit -S -m 'meu primeiro commit assinado'
Vendo a assinatura no log
git log --show-signature
commit cf43808e85399467885c444d2a37e609b7d9e99d
gpg: Signature made Sat 20 Mar 2015 11:59:01 PM EDT using RSA key ID 2AE02E3D
gpg: Good signature from "Marcio Rosner <marcio.rosner@tse.jus.br>"
Author: Marcio Rosner marcio.rosner@tse.jus.br>
Date: Sat Mar 21 23:59:01 2015 -0300
Gerando um certificado de revogação
gpg --output revoke.asc --gen-revoke KEYNAME
Revogando uma Chave
gpg --import revoke.asc
gpg --keyserver
hkp://pgp.mit.edu--send-key
--send KEYNAME
Exercício 3
1) Crie uma pasta com o nome "exercicio3" e crie um repositório git nesta pasta
$ mkdir exercicio3 && cd exercicio3
$ git init
2) crie o arquivo teste com o texto "exercicio3" e faça o primeiro commit:
$ echo "exercicio3" > teste.txt
$ git commit -am "
3) crie uma branch "exercicio3", mude para esta, altere o texto do arquivo teste.txt e faça o segundo commit:
$ git checkout -b exercicio3
$ echo "exercicio3 item 3" > teste.txt
$ git add .
$ git commit -m "segundo commit"
4) Volte a branch master e faça o merge
$ git checkout master
$ git merge exercicio3
5) Verifique o resultado. Foi um merge fast-forward ?
6) Crie uma nova branch "alteracoes" a partir do primeiro commit e crie o arquivo teste2.txt
$ git checkout -b alteracoes HEAD~1
$ echo "alterações" > teste2.txt
7) Volte a branch master e faça o merge com a branch alteracoes. Verifique o resultado. Qual a estratégia de merge ocorreu ?
8) Volte a branch master para o segundo commit.
$ git reset --hard HEAD~1
9) Faça o rebase da master na branch alterações
$ git checkout alteracoes
$ git rebase master
10) volte a branch master e faça o merge com a branch alteracoes. Veja o resultado. Que tipo de merge aconteceu ?
$ git checkout master
$ git merge alteracoes
Configurações Especiais: Sparse Checkout
1) Crie a pasta do projeto e inicialize um repositório git
$ mkdir projetoTeste && cd projetoTeste && git init
2) Configure para Sparse Checkout
$ git config core.sparsecheckout true
3) Informe que pasta(s) do projeto você quer
$ echo 02_fontes/ > .git/info/sparse-checkout
4) Adicione o projeto remoto
$ git remote add origin
"link do projeto"
5) Pegue os arquivos
$ git pull origin master
Obs.:
Se já tinha realiado clone do projeto, ao invés do pull, dê o comando:
git read-tree -m -u HEAD
Exercício: Faça o sparse checkout de um projeto
sim
recursive
Exercício 4: 2 pessoas
Pessoa1
: Crie o repositório remoto no http://git_clone.tse.jus.br com o nome Exercicio4 (no seu usuario) e adicione a segunda pessoa como "developer"
Pessoa1
: Clone o projeto
Pessoa2
: Clone o projeto
Pessoa1
: crie o arquivo pessoa1.txt com qualquer conteúdo, realize o commit e faça o push.
Pessoa2
: crie o arquivo pessoa2.txt com qualquer conteúdo, realize o commit, faça o fetch e realize o diff. Após faça o merge com o origin/master e faça o push.
Pessoa1
: altere o arquivo pessoa1.txt, faça o commit e realize o Pull.
http://sourceforge.net/projects/kdiff3/files/kdiff3/
git config --global merge.tool kdiff3

git config --global mergetool.kdiff3.cmd '"C:\\Program Files\\KDiff3\\kdiff3" $BASE $LOCAL $REMOTE -o $MERGED'
[merge]
tool = kdiff3
[mergetool "kdiff3"]
cmd = \"C:\\\\Program Files\\\\KDiff3\\\\kdiff3\" $BASE $LOCAL $REMOTE -o $MERGED
ou no .gitconfig:
Exercício 5: 2 pessoas
1) Instale o Kdiff3
2) Pessoa1: use um dos repositórios dos exercícios anteriores e edite algum arquivo texto colocando seu nome na primeira linha. Faça o commit e o push.
3) Pessoa 2: edite o mesmo arquivo e também escreva o seu nome na primeira linha. Faça o commit e em seguida realize o pull.
4) Resolva o conflito
Exercício 6
1) Utilize algum repositório dos exercícios anteriores, crie uma nova branch chamada exercicio6.
2) Faça 3 commits alterando algum arquivo texto
3) Faça o quarto commit criando um novo arquivo.
4) Edite o histórico usando o rebase iterativo, juntando os commits 1 e 2, removendo o commit 3 e mantendo o commit 4.
Exercício 7: 2 pessoas
1) Pessoa1: criar repositório no Gitlab de desenvolvimento (http://git_clone.tse.jus.br) chamada exercicio7 e colocar a outra pessoa como developer.
2)Pessoa1: realizar o clone do repositório, criar um arquivo texto "pessoa1.txt" com seu nome na branch Master e realizar o push.
3) Pessoa2: clonar o repositório, criar uma branch com o nome "chamadoex7", criar um arquivo texto chamado "pessoa2.txt" com seu nome e realizar o push da nova branch. Depois acessar no browser o Gitlab e abrir o merge request.
4) Pessoa1: aprovar o merge request, apagando a branch "chamadoex7" e fazer o pull o projeto localmente.
5) Pessoa2: realizar o pull da branch Master localmente.
OBS.: verificar envio de emails
Full transcript