git --controle-de-versão-rápido

ráp ido
rsã o-
d e- ve
tro le-
--con iza do
ent ral
ov o-c
o -é- o-n
rib uid
--d ist uro --fáci l-br
anch

- -seg

@helmedeiros l-m erge
-- fáci
-lo cal
--tudo-é

Git é sistema de controle de versão distribuído
livre e de código aberto, projetado para lidar com
tudo, de pequenos a grandes projetos, com
velocidade e eﬁciência.

http://git-scm.com/

Considerando a visão de LINUS TORVALDS

“cvs ou baseado “controle de
em suas
versão do jeito que
primitivas?”
ele realmente
deveria ser”

TALVEZ, NÃO SEJA UM BOM PONTO DE PARTIDA...
BLASFEMAR SOBRE OS SISTEMAS DE CONTROLE DE VERSÃO
USADOS... MAS... HUMMM...
PRECISAMOS IR EM FRENTE!

branching e pequeno e garantia de
distribuido
merging rápido integridade

área de
gratuito código aberto
conferência

Quais são as vantagens?


trunk
cria
tag
local branch
usando SIM avisou?
SIM trunk? trunk
dev reintegrate

cria
trunk
TAG? branch
trunk NÃO tag prod

cria homol
NÃO restaura

tag trunk ok?

#1 BRANCHING E MERGING
Git permite e incentiva a criação de vários branchs locais,
que podem ser totalmente independentes um do outro.

BRANCHING E MERGING
Alternância de contexto sem atrito
Criar um branch para testar uma idéia, comitar algumas vezes, voltar para onde você iniciou, aplicar um patch, voltar para
onde você estava experimentando, e mesclá-los!

Linhas de versionamento especiﬁca
Ter uma linha de versionamento que sempre contém apenas o que vai para a produção, outra que você mescle para testes,
e várias outras menores para o dia a dia de trabalho.

Workﬂow baseado em funcionalidades
Criar um novo branch para cada nova funcionalidade que vai trabalhar, para que você possa facilmente alternar entre eles,
em seguida, exclua cada linha de versionamento quando essa funcionalidade for incorporada a sua linha principal.

Experimentação descartável
Criar um branch para experimentar, perceber que não resolverá o problema, e apenas excluí-lo - abandonar o trabalho sem
que ninguém tenha o visto.

#2 PEQUENO E RÁPIDO
Git é rápido. Com o Git, quase todas as operações são realizadas localmente, dando-lhe
uma vantagem enorme

PEQUENO E RÁPIDO
Commit Arquivos(A) Commit Imagens(B) Diff Local
Add, commit e push 113 arquivos Add, commit e push de 1000 imagens de Diff de 187 arquivos alterados locais
modificados 1Kb contra o último commit.
1.09
3 2.6 30 24.7 1.1
2.25 22.5 0.825
1.5 15 0.55
0.64 0.25
0.75 7.5 1.53 0.275
0 0 0
git svn git svn git svn
Diff Arquivos Update
Diff Tags
Diff entre versão atual e outra 4 commits Pull do cenário do Commit A
Diff entre duas tags (v1.9.1.0/v1.9.3.0 )
atrás (269 alterados) (113 arquivos alterados)
3.99 83.57 2.82
4 90 3
3 67.5 2.25
2 45 1.5 0.9
1 0.25 22.5 1.17
0.75
0 0 0

PEQUENO E RÁPIDO
Log (Todos) Log (Arquivo)
Log (50)
Log de todos os commits Log do histórico de um arquivo (array.c -
Log dos últimos 50 commits
(26.056 commits) 483 revissões)
200 0.4 0.38 90 82.84
169.2
150 0.3 67.5
100 0.2 45
50 0.1 0.01 22.5
0.52 0.6
0 0 0

Blame
Anotações em um único arquivo (array.c)

4 3.04
3
1.91
2
1
0
git svn

PEQUENO E RÁPIDO
Commit ÁPIDO QUE O SVN Local
Commit Arquivos(A) É MAIS RImagens(B)
O GIT Diff
Add, commit e push 113 arquivos Add, commit e push de 1000 imagens de Diff de 187 arquivos alterados locais
modificados 1Kb contra o último commit.
1.09
3 2.6 30 24.7 1.1
2.25 22.5 0.825
1.5 15 0.55

4x 16x 4x
0.64 0.25
0.75 7.5 1.53 0.275
0 0 0
Diff Arquivos Update
Diff Tags
Diff entre versão atual e outra 4 commits Pull do cenário do Commit A
Diff entre duas tags (v1.9.1.0/v1.9.3.0 )
atrás (269 alterados) (113 arquivos alterados)
3.99 83.57 2.82
4 90 3
3 67.5 2.25

16x 71x 3x
2 45 1.5 0.9
1 0.25 22.5 1.17
0.75
0 0 0

PEQUENO E RÁPIDO
Log (Todos)GIT É MAIS RÁPIDO
O QUE O SVN
Log (Arquivo)
Log (50)
Log de todos os commits Log do histórico de um arquivo (array.c -
Log dos últimos 50 commits
(26.056 commits) 483 revissões)
200 0.4 0.38 90 82.84
169.2
150 0.3 67.5
100 0.2 45
50
0 325x
0.52
0.1
0
0.01 31x 22.5
0
0.6 138x

Blame
Anotações em um único arquivo (array.c)

4 3.04
3

1x
1.91
2
1
0
git svn

#3 DISTRIBUIDO
Em vez de fazer um "check-out" da situação atual do código fonte, você faz um "clone" de
todo o repositório.

DISTRIBUÍDO

Backups Múltiplos
Mesmo se você estiver usando um fluxo de trabalho centralizado, Qualquer Fluxo de trabalho
cada usuário terá um backup completo do servidor principal. Cada Por causa da natureza distribuída e do sistema
uma dessas cópias pode substituir o servidor principal em caso de de ramificação do Git, um número quase infinito
um acidente ou de corrupção. Como efeito, não há um ponto único de de fluxos de trabalho pode ser implementado
falha com Git a menos que haja apenas uma única cópia do com relativa facilidade.
repositório.

DISTRIBUÍDO

Fluxo de trabalho ao
estilo Subversion
Um fluxo de trabalho centralizado é muito
comum, especialmente de pessoas
transitando de um sistema centralizado.


DISTRIBUÍDO
C E1
SOUR
OP EN
JE TO
PRO
origem

origem
PR
OJ
ET
OO
PE
NS
OU
RC
Fluxo de trabalho distribuido E2
e descentralizado origem
Para equipes que se sobrepõem a uma estrutura
formal de times, o modelo distribuído permite uma
organização colaborativa simples e organizada. origem

DISTRIBUÍDO

fetch
origem

localhost

merge
PULL
O comando pull realiza as duas operações, realiza
primeiro um fetch trazendo todos os arquivos e em
seguida realiza um merge com o seu repositório
local.
{
origin/master
+
master

DISTRIBUÍDO

push
origem

$git push notebook projeto1

$git push origem projeto1 localhost

PUSH push notebook

O comando push realiza o envio do pacote de
informações do repositório local para o seu par no
servidor desejado. Mesmo que o repositório não
exista no servidor em questão.

#4 GARANTIA DE INTEGRIDADE
É impossível obter qualquer coisa dentro do Git além dos bits exatos que você colocar

GARANTIA DE INTEGRIDADE

Integridade Criptográﬁca
O modelo de dados que o Git usa garante a integridade criptográfica de todos os bits de
seu projeto. Sobre cada arquivo e commit é gerado um checksum e sempre que se for
recuperar e realizada a conferencia. É impossível obter qualquer coisa fora do Git além dos
bits exatos você colocar dentro.


#5 ÁREA DE CONFERÊNCIA
Coomits podem ser formatados e revisados antes de completar a submissão.

ÁREA DE CONFERÊNCIA

Staging Area
Git tem algo chamado de staging area ou índice, que serve como área intermediária onde
os commits podem ser formatados e revisados antes de completar a submissão. Desta
forma é possível rapidamente alterar alguns de seus arquivos e comitá-los sem comitar
todos os outros modificados em seu diretório de trabalho, ou ainda ter que listá-los durante
a confirmação.

#6 GRATUITO
Use o Git em projetos abertos ou proprietários de graça, para sempre.

GRATUITO

Sob licença de software livre GPLv2 é possível
Usar o Git em projetos abertos ou proprietário de graça, para sempre;
Utilizar os binários do Git em programas abertos ou proprietários;


#7 CÓDIGO ABERTO
Baixe, inspecionar e modificar o código-fonte do Git.

CÓDIGO ABERTO

Sob licença de software livre GPLv2 é possível
Baixar, inspecionar e modificar o código-fonte do Git;
Fazer alterações proprietárias no Git que você não redistribua publicamente;
redistribuir publicamente binários do Git com programas abertos ou proprietários
desde que os mesmo sejam públicos;


Fontes:

Obrigado!
Pro Git - Scott Chacon

@helmedeiros
Imagens:

git --controle-de-versão-rápido

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a git --controle-de-versão-rápido (20)

Mais de Hélio Medeiros (20)

git --controle-de-versão-rápido