-
1. Primeiros Passos
- 1.1 Sobre Controle de Versão
- 1.2 Uma Breve História do Git
- 1.3 O que é Git?
- 1.4 A Linha de Comando
- 1.5 Instalando o Git
- 1.6 Configuração inicial do Git
- 1.7 Obtendo Ajuda
- 1.8 Resumo
-
2. Fundamentos do Git
-
3. Ramificação (Branching) no Git
-
4. Git no Servidor
- 4.1 Os Protocolos
- 4.2 Colocando o Git em um Servidor
- 4.3 Gerando a sua Chave Pública SSH
- 4.4 Configurando o Servidor
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Opções de Hospedagem de Terceiros
- 4.10 Resumo
-
5. Git Distribuído
-
6. GitHub
-
7. Ferramentas do Git
- 7.1 Seleção de Revisão
- 7.2 Área de Stage Interativa
- 7.3 Fazendo Stash e Limpando
- 7.4 Assinando Seu Trabalho
- 7.5 Pesquisando (Searching)
- 7.6 Reescrevendo o Histórico
- 7.7 Reset Desmistificado
- 7.8 Merging Avançado
- 7.9 Rerere
- 7.10 Depurando com Git
- 7.11 Submódulos
- 7.12 Empacotando (Bundling)
- 7.13 Substituir (Replace)
- 7.14 Armazenamento de Credenciais
- 7.15 Resumo
-
8. Customizando o Git
- 8.1 Configuração do Git
- 8.2 Atributos do Git
- 8.3 Hooks do Git
- 8.4 Uma Política de Exemplo Imposta pelo Git
- 8.5 Resumo
-
9. Git e Outros Sistemas
- 9.1 Git como Cliente
- 9.2 Migrando para o Git
- 9.3 Resumo
-
10. Git Internals (Por Dentro do Git)
- 10.1 Encanamento e Porcelana (Plumbing and Porcelain)
- 10.2 Objetos do Git
- 10.3 Referências do Git
- 10.4 Arquivos de pacote (Packfiles)
- 10.5 Refspec
- 10.6 Protocolos de Transferência
- 10.7 Manutenção e Recuperação de Dados
- 10.8 Variáveis de Ambiente
- 10.9 Resumo
-
A1. Appendix A: O Git em Outros Ambientes
- A1.1 Interfaces Gráficas
- A1.2 Git no Visual Studio
- A1.3 Git no Visual Studio Code
- A1.4 Git no IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git no Sublime Text
- A1.6 Git no Bash
- A1.7 Git no Zsh
- A1.8 Git no PowerShell
- A1.9 Resumo
-
A2. Appendix B: Incorporando o Git nos seus Aplicativos
- A2.1 Linha de Comando do Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Comandos do Git
- A3.1 Configuração e Ajustes
- A3.2 Obtendo e Criando Projetos
- A3.3 Snapshots Básicos
- A3.4 Branches e Merges
- A3.5 Compartilhando e Atualizando Projetos
- A3.6 Inspeção e Comparação
- A3.7 Depuração
- A3.8 Patches
- A3.9 E-mail
- A3.10 Sistemas Externos
- A3.11 Administração
- A3.12 Comandos de Encanamento
4.8 Git no Servidor - GitLab
GitLab
O GitWeb é bem simplista, no entanto. Se você está procurando um servidor Git moderno e completo, há várias soluções de código aberto que você pode instalar. Como o GitLab é um dos mais populares, vamos abordar a sua instalação e uso como exemplo. Isso é mais difícil que a opção GitWeb e exigirá mais manutenção, mas é uma opção completa.
Instalação
O GitLab é uma aplicação web com suporte a banco de dados (database-backed), então a sua instalação é mais complexa do que a de alguns outros servidores Git. Felizmente, esse processo é bem documentado e suportado. O GitLab recomenda fortemente a instalação do GitLab no seu servidor através do pacote oficial Omnibus GitLab.
As outras opções de instalação são:
-
Gráfico (chart) GitLab Helm, para uso com o Kubernetes.
-
Pacotes GitLab em Docker para uso com o Docker.
-
A partir dos arquivos fonte (source files).
-
Provedores de nuvem como AWS, Google Cloud Platform, Azure, OpenShift e Digital Ocean.
Para mais informações, leia o leia-me (readme) do GitLab Community Edition (CE).
Administração
A interface de administração do GitLab é acessada pela web.
Basta apontar o seu navegador para o hostname ou endereço IP onde o GitLab está instalado e fazer o login como o usuário root.
A senha dependerá do seu tipo de instalação, mas por padrão, o Omnibus GitLab gera automaticamente uma senha e a armazena em /etc/gitlab/initial_root_password por pelo menos 24 horas.
Siga a documentação para mais detalhes.
Depois de logar, clique no ícone “Admin area” (área de Administração) no menu superior direito.
Usuários
Todo mundo que usa o seu servidor GitLab deve ter uma conta de usuário.
As contas de usuário são bem simples, elas contêm principalmente informações pessoais anexadas aos dados de login.
Cada conta de usuário tem um namespace, que é um agrupamento lógico de projetos que pertencem a esse usuário.
Se a usuária jane tivesse um projeto chamado project, a URL desse projeto seria http://server/jane/project.
Você pode remover uma conta de usuário de duas maneiras: “Bloquear” (Blocking) um usuário o impede de fazer login na instância do GitLab, mas todos os dados sob o namespace daquele usuário serão preservados, e os commits assinados com o endereço de e-mail daquele usuário ainda estarão vinculados ao seu perfil.
“Destruir” (Destroying) um usuário, por outro lado, o remove completamente do banco de dados e do sistema de arquivos. Todos os projetos e dados no namespace dele são removidos, e quaisquer grupos que ele possua também serão removidos. Esta é obviamente uma ação muito mais permanente e destrutiva, e você raramente precisará dela.
Grupos
Um grupo do GitLab é uma coleção de projetos, juntamente com dados sobre como os usuários podem acessar esses projetos.
Cada grupo tem um namespace de projeto (da mesma forma que os usuários), então se o grupo training tem um projeto materials, a sua URL seria http://server/training/materials.
Cada grupo está associado a um número de usuários, cada um dos quais tem um nível de permissões para os projetos do grupo e para o próprio grupo. Estes variam de “Convidado” (Guest - apenas issues e chat) a “Proprietário” (Owner - controle total do grupo, seus membros e seus projetos). Os tipos de permissões são numerosos demais para serem listados aqui, mas o GitLab tem um link útil na tela de administração.
Projetos
Um projeto do GitLab corresponde aproximadamente a um único repositório Git. Cada projeto pertence a um único namespace, seja de um usuário ou de um grupo. Se o projeto pertencer a um usuário, o proprietário do projeto tem controle direto sobre quem tem acesso ao projeto; se o projeto pertencer a um grupo, as permissões de nível de usuário do grupo entrarão em vigor.
Cada projeto tem um nível de visibilidade, que controla quem tem acesso de leitura às páginas e ao repositório desse projeto.
Se um projeto for Privado, o proprietário do projeto deve conceder acesso explicitamente a usuários específicos.
Um projeto Interno é visível para qualquer usuário logado, e um projeto Público é visível para qualquer pessoa.
Observe que isso controla tanto o acesso git fetch quanto o acesso à UI web para esse projeto.
Ganchos (Hooks)
O GitLab inclui suporte para ganchos (hooks), tanto no nível de projeto quanto de sistema. Para qualquer um desses, o servidor GitLab executará um HTTP POST com algum JSON descritivo sempre que eventos relevantes ocorrerem. Essa é uma ótima maneira de conectar os seus repositórios Git e a instância do GitLab ao resto da sua automação de desenvolvimento, como servidores de CI, salas de bate-papo (chat rooms) ou ferramentas de implantação (deployment).
Uso Básico
A primeira coisa que você vai querer fazer com o GitLab é criar um novo projeto. Você pode fazer isso clicando no ícone “+” na barra de ferramentas. Você será solicitado a informar o nome do projeto, a qual namespace ele deve pertencer e qual deve ser o seu nível de visibilidade. A maior parte do que você especifica aqui não é permanente e pode ser alterada posteriormente através da interface de configurações. Clique em “Criar Projeto” (Create Project), e você está pronto.
Depois que o projeto existir, você provavelmente desejará conectá-lo a um repositório Git local.
Cada projeto é acessível via HTTPS ou SSH, qualquer um dos quais pode ser usado para configurar um remoto Git.
As URLs são visíveis no topo 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://server/namespace/project.gitSe você não tiver uma cópia local do repositório, pode simplesmente fazer isto:
$ git clone https://server/namespace/project.gitA interface web fornece acesso a várias visualizações úteis do próprio repositório. A página inicial de cada projeto mostra a atividade recente, e os links na parte superior o levarão a visualizações dos arquivos e do log de commits do projeto.
Trabalhando Juntos
A maneira mais simples de trabalhar junto em um projeto do GitLab é dando a cada usuário acesso direto de push ao repositório Git. Você pode adicionar um usuário a um projeto acessando a seção “Membros” (Members) das configurações desse projeto e associando o novo usuário a um nível de acesso (os diferentes níveis de acesso são discutidos um pouco em Grupos). Ao dar a um usuário um nível de acesso “Desenvolvedor” (Developer) ou superior, esse usuário pode fazer o push de commits e branches diretamente para o repositório.
Outra forma de colaboração, mais desacoplada, é usar merge requests (solicitações de mesclagem).
Esse recurso permite que qualquer usuário que possa ver um projeto contribua com ele de forma controlada.
Usuários com acesso direto podem simplesmente criar um branch, fazer o push de commits para ele e abrir um merge request de seu branch de volta para a master ou qualquer outro branch.
Os usuários que não têm permissão de push para um repositório podem fazer o “fork” dele para criar sua própria cópia, fazer o push de commits para a cópia deles e abrir um merge request de seu fork de volta para o projeto principal.
Esse modelo permite que o proprietário tenha controle total sobre o que entra no repositório e quando, ao mesmo tempo em que permite contribuições de usuários não confiáveis.
Os merge requests e os issues (problemas/tarefas) são as principais unidades de discussão de longa duração no GitLab. Cada merge request permite uma discussão linha por linha da alteração proposta (o que suporta um tipo leve de revisão de código), bem como um tópico de discussão geral (discussion thread). Ambos podem ser atribuídos a usuários ou organizados em marcos (milestones).
Esta seção é focada principalmente nos recursos do GitLab relacionados ao Git, mas como um projeto maduro, ele fornece muitos outros recursos para ajudar a sua equipe a trabalhar em conjunto, como wikis de projeto e ferramentas de manutenção do sistema. Um benefício do GitLab é que, uma vez que o servidor esteja configurado e funcionando, você raramente precisará ajustar um arquivo de configuração ou acessar o servidor via SSH; a maior parte da administração e do uso geral pode ser feita por meio da interface no navegador.