-
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
4.8 Git no Servidor - GitLab
GitLab
Embora o GitWeb seja bastante simplista, se estiveres a procurar por um servidor Git mais moderno e completo, existem algumas soluções de código aberto lá fora que podes instalar em vez deste. Como o GitLab é um dos mais populares, vamos cobrir a instalação e usá-lo como um exemplo. Este é um pouco mais complexo do que a opção GitWeb e provavelmente requer mais manutenção, mas é uma opção muito mais completa.
Instalação
O GitLab é um aplicativo da Web baseado em banco de dados, por isso a sua instalação é um pouco mais trabalhosa do que alguns outros servidores Git. Felizmente, este processo é muito bem documentado e apoiado.
Existem alguns métodos que tu podes seguir para instalar o GitLab. Para obter algo em execução rapidamente, podes descarrear uma imagem de máquina virtual ou um instalador de um clique em https://bitnami.com/stack/gitlab e ajustar a configuração para que corresponda ao teu ambiente particular.. Um toque agradável que Bitnami incluiu é o ecrã de login (acedida digitando alt-→); Ele informa o endereço IP e o nome de utilizador e senha padrão para o GitLab instalado.
Para qualquer outra coisa, sigue as orientações no readme do GitLab Community Edition, que pode ser encontrado em https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Lá encontrarás assistência na instalação do GitLab usando receitas do Chef, a máquina virtual no Digital Ocean, e os pacotes RPM e DEB (que, no momento em que este texto foi escrito, estava na versão estável Omnibus, para os sistemas operacionais Ubuntu 14.04, Ubuntu 16.04, Debian 7, Debian 8, CentOS 6, CentOS 7, OpenSUSE 42.1 e Raspberry PI 2 em Raspbian). Há também guias com orientações “não oficiais” para que o GitLab funcione em sistemas operacionais e bases de dados diferentes dos citados acima, um script para instalação completamente manual e muitos outros tópicos.
Administração
A interface de administração do GitLab é acedida através da web.
Basta apontar o teu navegador para o nome do host ou endereço IP onde o GitLab está instalado e efetuar login como um utilizador admin.
O nome de utilizador padrão é admin@local.host e a senha padrão é 5iveL!fe (que tu serás solicitado a alterar assim que entrares nele).
Depois de efetuares o login, clica no ícone “Área de administração” no menu no canto superior direito.
Utilizadores
Utilizadores no GitLab são contas que correspondem a pessoas.
As contas de utilizador não têm muita complexidade; A conta de utilizador é uma coleção de informações pessoais anexadas aos dados de login.
Cada conta de utilizador vem com um namespace, que é um agrupamento lógico de projetos que pertencem a este utilizador.
Se o utilizador jane tivesse um projeto chamado project, o URL do projeto seria http://servidor/jane/project.
Remoção de um utilizador pode ser feito de duas formas. “Bloquear” um utilizador que os impede de logar na instância do Gitlab, mas todos os dados sob o namespace do utilizador serão preservados, e os commits assinados com o e-mail do utilizador ainda irão direcionar para o perfil do mesmo.
“Destruir” um utilizador, por outro lado, remove o remove completamente da base de dados e do sistema de arquivos. Todos os projetos e dados no namespace são removidos, e qualquer outro grupo que ele possua também será removido. Isto é obviamente uma ação muito mais permanete e destrutiva, e o uso disso é raro.
Grupos
Um grupo GitLab é um conjunto de projetos, juntamente com dados sobre como os utilizadores podem acederr estes projetos.
Cada grupo tem um espaço para nome de projeto (da mesma forma que os utilizadores), então se o grupo training tiver um projeto materials, tua url seria http://servidor/training/materials.
Cada grupo está associado a um número de utilizadores, cada um com um nível de permissões para os projetos do grupo e para o próprio grupo. Estes variam de “Convidado” (problemas e bate-papo somente) a “Proprietário” (controle total do grupo, seus membros e seus projetos). Os tipos de permissões são muito numerosos para listar aqui, mas o GitLab tem um link útil no ecrã de administração.
Projetos
Um projeto GitLab corresponde de grosso modo a um único repositório Git. Cada projeto pertence a um único namespace, a um utilizador ou a um grupo. Se o projeto pertence a um utilizador, o proprietário do projeto tem controle direto sobre quem tem acesso ao projeto; Se o projeto pertence a um grupo, as permissões de nível de utilizador do grupo também terão efeito.
Cada projeto também tem um nível de visibilidade, que controla quem tem acesso de leitura às páginas desse projeto e ao repositório.
Se um projeto for Privado, o proprietário do projeto deve conceder explicitamente acesso a utilizadores específicos.
Um projeto Interno é visível para qualquer utilizador logado, e um projeto Público é visível para qualquer pessoa.
Observa que isto controla tanto o acesso git fetch quanto o acesso à interface web do utilizador a este projeto.
Ganchos
O GitLab inclui suporte para ganchos (hooks), tanto a nível de projeto como de sistema. Para qualquer um destes, o servidor GitLab executará um HTTP POST com algum JSON descritivo sempre que ocorrerem eventos relevantes. Esta é uma ótima maneira de conectar os teus repositórios Git e a instância GitLab ao resto de sua automação de desenvolvimento, como servidores CI, salas de bate-papo ou ferramentas de implantação.
Uso Básico
A primeira coisa que vais querer fazer com o GitLab é criar um novo projeto. Isto é feito clicando no ícone “+” na barra de ferramentas. Ser-te-á pedido o nome do projecto, a qual namespace ele deverá pertencer e que nível de visibilidade deverá ter. A maior parte do que tu especificas aqui não é permanente e pode ser reajustada posteriormente através da interface de configurações. Clica em “Criar projeto” e pronto.
Uma vez que o projeto exista, provavelmente vais querer conectá-lo com um repositório Git local.
Cada projeto é acessível através de HTTPS ou SSH, sendo que ambos podem ser usados para configurar um Git remoto.
As URLs estão visíveis na parte superior da página inicial do projeto.
Para um repositório local existente, este comando criará um remoto chamado gitlab para o local hospedado:
$ git remote add gitlab https://servidor/namespace/project.gitSe não tens uma cópia local do repositório, podes simplesmente fazer isto:
$ git clone https://servidor/namespace/project.gitA interface do utilizador da Web fornece o acesso a várias visualizações úteis do próprio repositório. A página inicial de cada projeto mostra as atividades recentes e os links ao longo do topo levam-te a exibições dos arquivos do projeto e do log de commits.
Trabalhando juntos
A maneira mais simples de trabalhar juntos num projeto GitLab é dar a outro utilizador acesso direto de push (envio de commits) ao repositório Git. Podes adicionar um utilizador a um projeto indo para a seção “Membros” das configurações deste projeto e associando o novo utilizador com um nível de acesso (os diferentes níveis de acesso estão um pouco descritos em Grupos). Ao fornecer a um utilizador um nível de acesso de “Desenvolvedor” ou superior, este utilizador pode empurrar branches e ramificações diretamente para o repositório.
Outra maneira mais dissociada de colaboração é usar solicitações de mesclagem.
Este recurso permite que qualquer utilizador que possa ver um projeto contribua para ele de forma controlada.
Os utilizadores com acesso direto podem simplesmente criar uma ramificação, empurrá-la para ele e abrir uma solicitação de mesclagem do seu ramo de volta para master ou qualquer outra ramificação.
Os utilizador que não têm permissões push para um repositório podem "fork" (criar sua própria cópia), push commit para aquela cópia e abrir uma solicitação de mesclagem de sua bifurcação de volta para o projeto principal.
Este modelo permite que o proprietário esteja no controle total do que entra no repositório e quando, embora permita contribuições de utilizadores não confiáveis.
Os pedidos de mesclagem e os problemas são as principais unidades de discussão de longa duração no GitLab. Cada solicitação de mesclagem permite uma discussão linha a linha da alteração proposta (que suporta um tipo leve de revisão de código), bem como um tópico geral de discussão geral. Ambos podem ser atribuídos a utilizador ou organizados em marcos.
Esta seção é focada principalmente nos recursos relacionados ao Git do GitLab, mas como um projeto maduro, ele fornece muitos outros recursos para ajudar a tua equipa a trabalhar em conjunto, como wikis de projeto e ferramentas de manutenção do sistema. Um benefício para o GitLab é que, uma vez que o servidor está configurado e em execução, tu raramente precisarás ajustar um arquivo de configuração ou aceder o servidor via SSH; A maior parte da administração e o uso geral podem ser realizados através da interface no navegador.
