Renato Cordeiro Ferreira
Scientific Programmer @ JADS | PhD Candidate @ USP | Co-founder & Coordinator @CodeLab
Git Avançado
Técnicas de como trabalhar com git em times
Renato Cordeiro Ferreira
2019
ATENÇÃO!
Essa não é uma palestra sobre o básico de usar o Git
E
git add
git commit
git push
git clone
git pull
}
}
"The mindless three"
Começando os trabalhos...
E
ATENÇÃO!
Essa é uma palestra sobre como usar Git de verdade
Branching
O poder por trás do Git
Commits são "caixinhas" que guardam metadados sobre as modificações do código
a12b34c5
Cada commit é identificado por checksum SHA-1 que representa um cabeçalho + as mudanças do commit
Commits se ligam como numa lista, apontando para o commit do qual se originaram
a12b34c5
b23c45d6
c34d56e7
Novos commits são criados com a combinação de comandos git add + git commit
A cabeça dessa lista (HEAD) representa o que você visualiza no repositório no momento
a12b34c5
b23c45d6
c34d56e7
HEAD
Como voltar para o passado?
git checkout permite ver versões antigas do código ao mover a HEAD para outros commits
a12b34c5
b23c45d6
c34d56e7
HEAD
HEAD
git checkout b23c45d6
git checkout HEAD^1
git checkout pode voltar para a ponta da lista pois ela é identificada por padrão como main
a12b34c5
b23c45d6
c34d56e7
HEAD
HEAD
main
git checkout main
a12b34c5
b23c45d6
c34d56e7
HEAD
HEAD
git reset modifica a main e a HEAD juntas, tornando um commit inacessível
main
main
git reset b23c45d6
git reset HEAD^1
X
Criando universos paralelos
git commit com a HEAD desconectada da main gera uma árvore de commits
a12b34c5
b23c45d6
main
HEAD
d45e67f8
git commit
git checkout -b permite criar um nome para referenciar esse novo galho da árvore
test
a12b34c5
b23c45d6
main
HEAD
d45e67f8
git checkout -b test
git checkout ainda permite navegar entre commits como desejado
test
a12b34c5
b23c45d6
main
HEAD
d45e67f8
git checkout main
Juntando tudo num lugar só
git merge permite juntar duas branches gerando um commit que registra a junção
test
a12b34c5
b23c45d6
main
HEAD
e56f78a9
d45e67f8
git merge test
Juntando tudo num lugar só (melhorado)
git rebase permite reaplicar uma branch sob outra gerando um histórico linear
test
a12b34c5
b23c45d6
main
HEAD
d45e67f8
git rebase test
git branch -d permite apagar a referência para uma branch pré-existente
git branch -d test
test
X
a12b34c5
b23c45d6
main
HEAD
d45e67f8
Estratégias de branching
a12b34c5
b23c45d6
c34d56e7
e56f78a9
main
d45e67f8
develop
feature
f67a89b0
hotfix
Git Flow propõe uma branch estável, uma de desenvolvimento, várias para funcionalidades e algumas de urgência
a12b34c5
b23c45d6
c34d56e7
e56f78a9
main
d45e67f8
feature-1
feature-2
GitHub Flow propõe uma branch estável e várias para funcionalidades que são integradas via pull requests
a12b34c5
b23c45d6
c34d56e7
e56f78a9
staging
d45e67f8
prod
feature-2
GitLab Flow propõe uma branch para cada ambiente de deploy e para funcionalidades que são disponibilizadas via merge requests
feature-1
Branching
Qual estratégia eu devo usar?
Resposta longa:
Depende, mas no geral, nenhuma...
Resposta curta:
NENHUMA
Contra o branching hell, aplique trunk-based development
git add
git commit
git push
}
"The mindless three"
Se você só tem a branch main e faz commits com frequência, você dilui merges a cada commit
"Branches criam distância entre desenvolvedores e nós não queremos isso"
— Frank Compagner, Guerrilla Games
Single Source of Truth
+
Continuous Integration
+
Continuous Code Review
+
Feature Flags
=
Trunk-Based Development
Mas... Mas... Mas...
Não pode ser tão simples assim!
Resposta longa:
Se o seu projeto é de software livre,
ou seu time é muito grande, ou sua revisão de código é longa, ou seu código integra vários repositórios...
Resposta curta:
Realmente não é...
E isso é verdade inclusive com projetos complexos que têm vários repositórios para as partes de uma arquitetura de microsserviços
Para a maioria dos projetos porém:
keep it simple
Perguntas?
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789Referências
- https://git-scm.com
- https://rogerdudler.github.io/git-guide/
- https://nvie.com/posts/a-successful-git-branching-model/
- https://guides.github.com/introduction/flow/
- https://docs.gitlab.com/ee/workflow/gitlab_flow.html
- https://trunkbaseddevelopment.com
- https://chris.beams.io/posts/git-commit/
Git Avançado
Técnicas de como trabalhar com git em times
Renato Cordeiro Ferreira
2019
Git Avançado
By Renato Cordeiro Ferreira
Git Avançado
Palestra sobre técnicas de git avançadas, apresentada na USPCodeLab Summer Tech Talks 2019
