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 Gitlab

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 14 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Introdução ao GIT e Gitlab

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
HEAD =
referência (ponteiro) para onde estamos (branch, commit ou tag)
git merge <outraBranch> :
faz o merge na branch atual do conteúdo da outraBranch
Merge no Git
$ 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


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
- um conflito no Master paralisa seu trabalho

git clone repo1 repo2
(Clona um repositório e add o repo1 como origin no repo2)
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
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 issue) para fazer o trabalho (pode ter vários commits)
3-
Volte a branch MASTER e atualize-a (PULL)
4-
Se houve mudanças na Master, volte a branch da issue para atualizá-la com o REBASE
5-
Envie a branch da issue para o servidor: PUSH
6-
Entre no site http://git.tse.jus.br e crie um MERGE REQUEST
Full transcript