Minicurso de Git

Bruno Habermann

Você pode consultar também os seguintes locais para ter uma visão geral sobre o git

Git - Primeiros Passos
Git - Guia Prático

Primeiros Passos

Iniciando um projeto com o GIT

git init // inicializa a pasta para usar o git
git ls-files // arquivos controlados
git status // status de todos os arquivos no diretório
git add . // adiciona os arquivos alterados
git commit -m "Promeiro commit" // versiona a alteração com um comentário

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

git commit -am "Segundo commit" // aglutina os comandos "add" e "commit -m"

Alterações efetuadas

git whatchanged // lista os arquivos alterados
git whatchanged -p // lista os arquivos alterados com as linhas alteradas também

Espelhar repositório na rede e enviar arquivos

git remote // lista os repositorios remotos
git remote add origin URL // o nome origin é uma convenção para nomear o repositório remoto

git push -u origin master // enviar | vincular | qual servidor | qual branch

Clonar um repositório pronto

git clone URL

Branches

git branch // lista branches
git branch nome_da_branch // cria uma nova branch
git checkout nome_da_branch // muda para a branch

git checkout -b nome_da_branch // cria e altera para a branch

git branch // para confirmarmos a branch que estamos (com *)

git branch -r // lista as branches remotas

git branch -t nome_local origin/nome_remoto // vincula a branch local à branch remota

git branch -d nome_da_branch // remove a branch local

Conflitos

Merge automático se alterado em linhas diferentes
- Não gera conflito
Merge manual se alterada a mesma linha/bloco
- Gera conflito

Boas práticas

Rebase

Trabalhar sempre num branch de desenvolvimento local

git checkout -b desenvolvimento // cria e entra na branch desenvolvimeto

Efetuar os trabalhos todos nesta branch local desenvolvimento

git checkout master // mudar para o branch master
git pull // atualizar com as informações do repositório
git checkout desenvolvimento // muda para o branch desenvolvimento
git rebase master [desenvolvimento] // quando se está na branch que receberá o rebase, o último comando é opcional
git checkout master
git merge desenvolvimento
git push

Possíveis problemas

Pode haver algum conflito no momento de efetuar o rebase, neste caso temos que resolver este conflito, de forma semelhante ao merge com o seguinte procedimento:

git rebase master // deu erro

Corrigimos os conflitos e continuamos

git add [arquivos com conflito resolvidos]
git rebase --continue

Controles avançados

Como voltar a versão local de um arquivo?

git checkout "arquivo" // volta arquivo não adicionado (git add)
git reset HEAD "arquivo" // volta arquivo já adicionado (git add)

E se já tiver efetuado o comit?

git reset {HASH} // reseta(desfaz) todos os commits até o indentificador

Mas e se for um comite antigo?

git revert {HASH} // reverte somente o commit passado e cria um novo commit para gravar este reverte

E se eu tiver alterações não commitadas e quiser efetuar alguma alteração e commitar sem que esta seja afetada?

git stash // Salva as alterações atuais e retornar para a versão do INDEX
git stash list // Mostra todas as alterações guardadas no Stash
git stash pop // Devolve a última alteração do Stash para o Working Copy
git stash apply {HAS} // Devolve somente as alterações do {HASH} especificado
git stash drop // Apaga todo o stash

Facilidades

Podemos criar apelidos para os comandos utilizados com frequencia para que não precisemos digitar muita coisa em vários passos, como por exemplo o processo de rebase.

Para criarmos um Alias, basta editar o arquivo .gitconfig na pasta de usuário do sistema e adicionar a seção [alias] com os apelidos desejados.

Por exemplo:

[alias]
	envia = !git checkout master && git pull && git checkout desenvolvimento && git rebase master && git checkout master && git merge desenvolvimento && git push

Git workflow

Models

Anarchy -> Today

Gatekeeper -> Cada um tem um fork e avisa ao "mantenedor" que tem uma alteração, chamada pull request

Dictator and liutenants -> Pirâmide

Centralised -> Todos em um repositório centralisado

Geralmente usado por companhias;
Mais fácil com Issues Trackes e Ferramentas de Integração (CI)

Branching model

Product Releas -> Versão 1, 2, 3 -> Long Term Support 1.1. Central Repository 1.2. One Branch per feature 1.3. One Branch per bugfix 1.4. Stable Branches (LTS) 1.5. master is Alpha / RC 1.6. Pull Request
Continuous Delivery -> Site, sem número de versão Software as a services, on demand Obs.: staging is a name of a branch 2.1. master is in production 2.2. staging is the next version 2.3. new features off staging

Common git Practices

Pull Request

-> Code review

Single Repository vs Remote Forks

Pros of a Single Repo

Complete Visibility
No per Dev remotes required

Fork

Manage codebase maturity
X(cross) department and 3rd parties
Dev to Dev interactions (without sending to center server)

Continuos Integration

Full integration

What happens to CI with git
An explosion of branches
Performance degradation of build sys

Selected Integration

Build everithing is expensive
Automatically build stable and master
Manually trigger feature branch builds

Less Friction and Automation

Code Quaility via pre-commit hooks -> Script running background
Branch from green builds -> with checkout
Automatic merges for the win Ripple merges Server side update hook Or tool support

Conclusion Colaboration Model -> Centralized Branching Model -> Product workflow Adopt Git Practices -> Pull request / Single Repository Automation & CI setup -> hooks (estudar)

bhabermann / minicurso-git