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
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 "[email protected]"
git commit -am "Segundo commit" // aglutina os comandos "add" e "commit -m"git whatchanged // lista os arquivos alterados
git whatchanged -p // lista os arquivos alterados com as linhas alteradas também
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
git clone URL
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
- Merge automático se alterado em linhas diferentes
- Não gera conflito
- Merge manual se alterada a mesma linha/bloco
- Gera conflito
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
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
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
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
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)
-
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
-> Code review
- Complete Visibility
- No per Dev remotes required
- Manage codebase maturity
- X(cross) department and 3rd parties
- Dev to Dev interactions (without sending to center server)
- What happens to CI with git
- An explosion of branches
- Performance degradation of build sys
- Build everithing is expensive
- Automatically build stable and master
- Manually trigger feature branch builds
- 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)