-
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 Instalar o Git
- 1.6 Configuração Inicial do Git
- 1.7 Pedindo Ajuda
- 1.8 Resumo
-
2. Noções Básicas do Git
- 2.1 Obtendo um Repositório Git
- 2.2 Recording Changes to the Repository
- 2.3 Veja o Histórico de Confirmação
- 2.4 Desfazer Coisas
- 2.5 Working with Remotes
- 2.6 Tagging
- 2.7 Alias Git
- 2.8 Resumo
-
3. Ramificação do Git
- 3.1 Branches in a Nutshell
- 3.2 Basic Branching and Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Remote Branches
- 3.6 Rebasing
- 3.7 Resume
-
4. Git no Servidor
- 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 Opções Hospedadas de Terceiros
- 4.10 Resumo
-
5. Git Distribuído
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Resumo
-
6. GitHub
-
7. Ferramentas do Git
- 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 Resumo
-
8. Personalizar o Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Resumo
-
9. O Git e Outros Sistemas
- 9.1 O Git como Cliente
- 9.2 Migrar para o Git
- 9.3 Resumo
-
10. Internos do Git
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Resumo
-
A1. Appendix A: Git em Outros Ambientes
- A1.1 Graphical Interfaces
- A1.2 Git no Visual Studio
- A1.3 Git no Eclipse
- A1.4 Git in Bash
- A1.5 Git no Zsh
- A1.6 Git no Powershell
- A1.7 Resumo
-
A2. Appendix B: Incorporar o Git nos teus Aplicativos
- A2.1 Linha de comando 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
1.1 Começando - Sobre Controle de Versão
Este capítulo falará sobre como começar com o Git. Começaremos por explicar alguns antecedentes sobre as ferramentas de controle de versão, em seguida avançamos para como obter o Git em execução no teu sistema e finalmente como configurá-lo para começar a trabalhar. No final deste capítulo, tu deves ficar a perceber por que o Git está por perto, por que deves usá-lo e deves estar preparado para fazê-lo.
Sobre Controle de Versão
O que é “controle de versão”, e porque deverias-te importar? O controle de versão é um sistema que registra alterações num arquivo ou conjunto de arquivos ao longo do tempo para que te possas lembrar as versões específicas mais tarde. Para os exemplos neste livro tu irás usar o código-fonte de software como os arquivos que estão sendo versão controlada, embora na realidade podes fazer isto com quase qualquer tipo de arquivo num computador.
Se és um designer gráfico ou web designer e queres manter todas as versões de uma imagem ou layout (o que certamente deverias querer), um Sistema de Controle de Versão (VCS) é a coisa correta a ser usada. Ele permite que revertas os arquivos de volta para um estado anterior, reverte todo o projeto de volta para um estado anterior, compara as mudanças ao longo do tempo, vê quem por último modificou algo que pode estar a causar um problema, quem introduziu um problema, quando, e muito mais. Usar um VCS também significa que se tu estragares tudo ou perderes arquivos, podes facilmente recuperar. Além disso, tens tudo isto por muito pouca sobrecarga.
Sistemas Locais de Controle de Versão
O método de controle de versão de muitas pessoas é copiar os arquivos para outro diretório (talvez um diretório com carimbo de tempo, se eles forem espertos). Esta abordagem é muito comum, porque é tão simples, mas também é incrivelmente propenso a erros. É fácil esquecer em qual diretório te encontras e acidentalmente sobreescreveres o arquivo errado ou copiar arquivos que não queres.
Para lidar com este problema, programadores há muito tempo desenvolveram VCSs locais que tem uma base de dados simples que mantêm todas as alterações nos arquivos sob controle de revisão.
Uma das ferramentas VCS mais populares foi um sistema chamado RCS, que ainda nos dias de hoje é distribuído com muitos computadores.
Até mesmo o popular sistema operacional Mac OS X inclui o comando rcs quando instalas as Ferramentas de Desenvolvimento.
RCS funciona mantendo conjuntos de alterações (ou seja, as diferenças entre os arquivos) num formato especial no disco; ele pode, em seguida, re-criar como qualquer arquivo se parecia em qualquer ponto no tempo, adicionando-se todas as alterações.
Sistemas Centralizados de Controle de Versão
A próxima questão importante que as pessoas encontram é que elas precisam colaborar com desenvolvedores em outros sistemas. Para lidar com este problema, foram desenvolvidos Sistemas Centralizados de Controle de Versão (CVCSs). Estes sistemas, tais como CVS, Subversion e Perforce, têm um único servidor que contém todos os arquivos de controle de versão, e um número de clientes que usam arquivos a partir desse lugar central. Por muitos anos, este tem sido o padrão para controle de versão.
Esta configuração oferece muitas vantagens, especialmente sobre VCSs locais. Por exemplo, todo a gente sabe, até um certo ponto o que toda a ente está a fazer no projeto. Os administradores têm controle refinado sobre quem pode fazer o que; e é muito mais fácil de administrar um CVCS do que lidar com bases de dados locais em cada cliente.
No entanto, esta configuração também tem algumas desvantagens graves. O mais óbvio é o ponto único de falha que o servidor centralizado representa. Se este servidor der problemas por uma hora, durante esta hora ninguém pode colaborar ou guardar as alterações da versão para o que quer que eles estejam a trabalhar. Se o disco rígido da base de dados central for corrompido, e backups apropriados não foram mantidos, tu perdes absolutamente tudo - toda a história do projeto, exceto imagens pontuais que os desenvolvedores possam ter nas suas máquinas locais. Sistemas VCS locais sofrem com este mesmo problema - sempre que tu tenhas toda a história do projeto num único lugar, há o risco de perder tudo.
Sistemas Distribuídos de Controle de Versão
É aqui que os Sistemas Distribuídos de Controle de Versão (DVCS) entram em cena. Num DVCS (como Git, Mercurial, Bazaar ou Darcs), os clientes não somente usam o estado mais recente dos arquivos: eles duplicam localmente repositório completo. Assim, se qualquer servidor morrer, e estes sistemas estiverem a colaborar por meio dele, qualquer um dos repositórios de clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada clone é de fato um backup completo de todos os dados.
Além disso, muitos destes sistemas trabalham muito bem com os vários repositórios remotos, tal que possas colaborar em diferentes grupos de pessoas de maneiras diferentes ao mesmo tempo dentro do mesmo projeto. Isso permite que configures vários tipos de fluxos de trabalho que não são possíveis em sistemas centralizados, como modelos hierárquicos.
