-
1. Começando
- 1.1 Sobre Controle de Versão
- 1.2 Uma Breve História do Git
- 1.3 O Básico do Git
- 1.4 A Linha de Comando
- 1.5 Instalando o Git
- 1.6 Configuração Inicial do Git
- 1.7 Pedindo Ajuda
- 1.8 Sumário
-
2. Fundamentos de Git
-
3. Branches no Git
-
4. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
5. Distributed Git
-
6. GitHub
- 6.1 Configurando uma conta
- 6.2 Contribuindo em um projeto
- 6.3 Maintaining a Project
- 6.4 Managing an organization
- 6.5 Scripting GitHub
- 6.6 Summary
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Funcionamento Interno do Git
- 10.1 Encanamento e Porcelana
- 10.2 Objetos do Git
- 10.3 Referências do Git
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Variáveis de ambiente
- 10.9 Sumário
-
A1. Appendix A: Git em Outros Ambientes
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Resumo
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
3.4 Branches no Git - Fluxo de Branches
Fluxo de Branches
Agora que você tem o básico sobre branches e merges, o que você pode ou deve fazer com eles? Nesta seção, cobriremos alguns fluxos de trabalho comuns que o branch torna possível, para que você possa decidir se deseja incorporá-los em seu próprio ciclo de desenvolvimento.
Branches de longa duração
Como o Git usa uma mesclagem simples de três vias, mesclar de um branch para outro várias vezes durante um longo período é geralmente fácil de fazer. Isso significa que você pode ter vários branches que estão sempre abertos e que você usa para diferentes estágios do seu ciclo de desenvolvimento; você pode mesclar regularmente alguns deles com outros.
Muitos desenvolvedores Git têm um fluxo de trabalho que adota essa abordagem, como ter apenas código totalmente estável em seu branch master
- possivelmente apenas código que foi ou será lançado.
Eles têm outro branch paralelo chamado developers
ou next
, a partir do qual trabalham ou usam para testar a estabilidade - nem sempre é necessariamente estável, mas sempre que chega a um estado estável, pode ser mesclado com o master
.
É usado para puxar branches de tópico (de curta duração, como seu anterior iss53
) quando eles estão prontos, para garantir que eles passem em todos os testes e não introduzam bugs.
Na realidade, estamos falando sobre indicadores que aumentam a linha de commits que você está fazendo. Os branches estáveis estão mais abaixo na linha em seu histórico de commit, e os branches mais avançados estão mais adiante no histórico.
![A linear view of progressive-stability branching.](png/lr-branches-1.png)
Geralmente é mais fácil pensar neles como silos de trabalho, onde conjuntos de commits passam para um silo mais estável quando são totalmente testados.
![A ``silo'' view of progressive-stability branching.](png/lr-branches-2.png)
Você pode continuar fazendo isso por vários níveis de estabilidade.
Alguns projetos maiores também têm um ramo proposto
ou pu
(proposed updates) que tem branches integrados que podem não estar prontos para ir para o branch next
ou master
.
A ideia é que seus ramos estejam em vários níveis de estabilidade; quando eles atingem um nível mais estável, eles são mesclados no ramo acima deles.
Novamente, não é necessário ter vários branches de longa duração, mas geralmente é útil, especialmente quando você está lidando com projetos muito grandes ou complexos.
Branches por tópicos
Branches de tópicos, no entanto, são úteis em projetos de qualquer tamanho. Um branch de tópico é um branch de curta duração que você cria e usa para um único recurso específico ou trabalho relacionado. Isso é algo que você provavelmente nunca fez com um VCS antes porque geralmente é muito difícil para criar e mesclar branches. Mas no Git é comum criar, trabalhar, mesclar e excluir branches várias vezes ao dia.
Você viu isso na última seção com os branches iss53
e hotfix
que você criou.
Você fez alguns commits neles e os deletou diretamente após fundi-los em seu branch principal.
Esta técnica permite que você mude de contexto de forma rápida e completa - porque seu trabalho é separado em silos onde todas as mudanças naquele branch têm a ver com aquele tópico, é mais fácil ver o que aconteceu durante a revisão de código.
Você pode manter as alterações lá por minutos, dias ou meses e mesclá-las quando estiverem prontas, independentemente da ordem em que foram criadas ou trabalhadas.
Considere um exemplo de como fazer algum trabalho (no master
), ramificando para um problema (iss91
), trabalhando nisso um pouco, ramificando o segundo branch para tentar outra maneira de lidar com a mesma coisa (iss91v2
), voltando ao seu branch master
e trabalhando lá por um tempo, e então ramificando para fazer algum trabalho que você não tem certeza se é uma boa ideia (branch dumbidea
).
Seu histórico de commits será parecido com isto:
![Multiple topic branches.](png/topic-branches-1.png)
Agora, digamos que você decida que prefere a segunda solução para o seu problema (iss91v2
); e você mostrou o branch dumbidea
para seus colegas de trabalho, e acabou sendo um gênio.
Você pode descartar o branch iss91
original (perdendo commits C5
e C6
) e mesclar os outros dois.
Seu histórico será assim:
![History after merging `dumbidea` and `iss91v2`.](png/topic-branches-2.png)
dumbidea
and iss91v2
Iremos entrar em mais detalhes sobre os vários fluxos de trabalho possíveis para seu projeto Git em [ch05-distributed-git], portanto, antes de decidir qual esquema de ramificação seu próximo projeto usará, certifique-se de ler esse capítulo.
É importante lembrar quando você estiver fazendo tudo isso, que esses branches são completamente locais. Quando você está ramificando e mesclando, tudo está sendo feito apenas em seu repositório Git - nenhuma comunicação de servidor está acontecendo.