Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.43.1 → 2.47.1 no changes
- 2.43.0 11/20/23
- 2.34.1 → 2.42.3 no changes
- 2.34.0 11/15/21
- 2.22.1 → 2.33.8 no changes
- 2.22.0 06/07/19
- 2.10.5 → 2.21.4 no changes
- 2.9.5 07/30/17
- 2.5.6 → 2.8.6 no changes
- 2.4.12 05/05/17
- 2.1.4 → 2.3.10 no changes
- 2.0.5 12/17/14
DESCRIÇÃO
Um programa CGI simples para servir o conteúdo de um repositório Git para clientes Git que acessam o repositório pelos protocolos http:// e https://. O programa oferece suporte a clientes que buscam usando o protocolo HTTP inteligente e o protocolo HTTP burro compatível com versões anteriores, bem como a clientes que enviam usando o protocolo HTTP inteligente. Ele também suporta o protocolo "v2" mais eficiente do Git, se configurado corretamente; consulte a discussão sobre GIT_PROTOCOL
na seção AMBIENTE abaixo.
Verifica se o diretório possui o arquivo mágico "git-daemon-export-ok" e se recusará a exportar qualquer diretório Git que não tenha sido explicitamente marcado para exportação (a menos que a variável de ambiente GIT_HTTP_EXPORT_ALL
esteja definida) .
Por padrão, apenas o serviço upload-pack
está ativado, que atende aos clientes git fetch-pack e git ls-remote, que são invocados a partir de git fetch, git pull e git clone. Se o cliente for autenticado, o serviço receive-pack
será ativado e atenderá aos clientes do git send-pack, que é chamado a partir do git push.
SERVIÇOS
Estes serviços podem ser ativados/desativados usando o arquivo de configuração por repositório:
- http.getanyfile
-
Isso serve para clientes Git anteriores à versão 1.6.6 que não conseguem usar o serviço de pacote de upload. Quando ativado, os clientes podem ler qualquer arquivo no repositório, inclusive objetos que não podem mais ser acessados num ramo, mas que ainda estão presentes. É predefinido que ele seja ativado, porém, um repositório pode desativá-lo definindo esse valor de configuração como
false
. - http.uploadpack
-
Isso oferece aos clientes git fetch-pack e git ls-remote. É predefinido que ele seja ativado, porém, um repositório pode desativá-lo definindo esse valor de configuração como
false
. - http.receivepack
-
Isso serve para clientes git send-pack, permitindo o envio. Ele é desativado por padrão para usuários anônimos e ativado por padrão para usuários autenticados pelo servidor da web. Ele pode ser desativado definindo esse item como
false
ou ativado para todos os usuários, inclusive usuários anônimos, definindo-o comotrue
.
TRADUÇÃO DA URL
Para determinar o local do repositório no disco, o git http-backend concatena as variáveis de ambiente PATH_INFO, que é definida automaticamente pelo servidor web, e GIT_PROJECT_ROOT, que deve ser definida manualmente na configuração do servidor Web. Se GIT_PROJECT_ROOT não estiver definido, git http-backend lê o PATH_TRANSLATED, que também é definido automaticamente pelo servidor da web.
EXEMPLOS
Todos os exemplos a seguir mapeiam o http://$hostname/git/foo/bar.git
para /var/www/git/foo/bar.git
.
- Apache 2.x
-
Certifique-se que o mod_cgi, mod_alias e mod_env estejam ativos, defina o
GIT_PROJECT_ROOT
(ou DocumentRoot) adequadamente e crie um "ScriptAlias" para o CGI:SetEnv GIT_PROJECT_ROOT /var/www/git SetEnv GIT_HTTP_EXPORT_ALL ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ # Isso não é estritamente necessário ao usar o apache e uma versão moderna do # git-http-backend, como o servidor web vai passar através do cabeçalho no # ambiente como HTTP_GIT_PROTOCOL e o http-backend vai copiar isso no # GIT_PROTOCOL. Mas você pode precisar desta linha (ou algo semelhante caso # esteja usando um servidor web diferente) ou caso queira que seja compatível com um # git mais antigo que não fizeram essa cópia. # # Ter o servidor web configurado GIT_PROTOCOL é suficiente mesmo com # versões mais modernas (que terá precedência sobre o HTTP_GIT_PROTOCOL, # o que significa que pode ser usado para substituir o pedido do cliente). SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
Para habilitar o acesso de leitura anônima, porém com acesso de gravação autenticado, exija a autorização para o anúncio da "ref" inicial (que detectamos como um "push" por meio do parâmetro "service" na cadeia de consulta) e a própria chamada do pacote de recebimento:
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR] RewriteCond %{REQUEST_URI} /git-receive-pack$ RewriteRule ^/git/ - [E=AUTHREQUIRED:yes] <LocationMatch "^/git/"> Order Deny,Allow Deny from env=AUTHREQUIRED AuthType Basic AuthName "Git Access" Require group committers Satisfy Any ... </LocationMatch>
Caso não tenha o
mod_rewrite
disponível para coincidir com o texto sob consulta é suficiente apenas para proteger o própriogit-receive-pack
, como:<LocationMatch "^/git/.*/git-receive-pack$"> AuthType Basic AuthName "Acesso Git" Require group committers ... </LocationMatch>
Nesse modo, o servidor não solicitará autenticação até que o cliente realmente inicie a fase de negociação de envio (push) do objeto, em vez de durante o contato inicial. Por esse motivo, você também deve ativar a opção de configuração
http.receivepack
em todos os repositórios que devem aceitar um push. O comportamento predefinido, sehttp.receivepack
não estiver definido, é rejeitar qualquer envio por usuários não autenticados; a solicitação inicial, portanto, informará403 Forbidden
ao cliente, sem sequer dar uma oportunidade de autenticação.Para exigir a autenticação para ambas as leituras e gravações, utilize uma diretiva local ao redor do repositório ou um dos seus diretórios upstream:
<Location /git/private> AuthType Basic AuthName "Acesso Git Privado" Require group committers ... </Location>
Para veicular o gitweb na mesma URL, utilize um ScriptAliasMatch apenas para ss URLs que o git http-backend pode manipular e encaminhe o restante para o gitweb:
ScriptAliasMatch \ "(?x)^/git/(.*/(HEAD | \ info/refs | \ objects/(info/[^/]+ | \ [0-9a-f]{2}/[0-9a-f]{38} | \ pack/pack-[0-9a-f]{40}\.(pack|idx)) | \ git-(upload|receive)-pack))$" \ /usr/libexec/git-core/git-http-backend/$1 ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
Para servir os vários repositórios vindos de diferentes gitnamespaces[7] num único repositório:
SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1 ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
- Apache estático acelerado 2.x
-
Semelhante ao anterior, mas o Apache pode ser usado para retornar arquivos estáticos armazenados no disco. Em muitos sistemas, isso pode ser mais eficiente, pois o Apache pode solicitar ao kernel que copie o conteúdo do arquivo do sistema de arquivos diretamente para a rede:
SetEnv GIT_PROJECT_ROOT /var/www/git AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Pode ser combinado com a configuração do gitweb:
SetEnv GIT_PROJECT_ROOT /var/www/git AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 ScriptAliasMatch \ "(?x)^/git/(.*/(HEAD | \ info/refs | \ objects/info/[^/]+ | \ git-(upload|receive)-pack))$" \ /usr/libexec/git-core/git-http-backend/$1 ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
- Lighttpd
-
Certifique-se de que
mod_cgi
,mod_alias
,mod_auth
,mod_setenv
estejam carregados, então defina a variávelGIT_PROJECT_ROOT
adequadamente e redirecione todas as solicitações para o CGI:alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" ) $HTTP["url"] =~ "^/git" { cgi.assign = ("" => "") setenv.add-environment = ( "GIT_PROJECT_ROOT" => "/var/www/git", "GIT_HTTP_EXPORT_ALL" => "" ) }
Para ativar o acesso de leitura anônima porém o acesso de gravação autenticado:
$HTTP["querystring"] =~ "service=git-receive-pack" { include "git-auth.conf" } $HTTP["url"] =~ "^/git/.*/git-receive-pack$" { include "git-auth.conf" }
onde o
git-auth.conf
se parece com:auth.require = ( "/" => ( "method" => "basic", "realm" => "Acesso Git", "require" => "valid-user" ) ) # ...and set up auth.backend here
Para exigir a autenticação tanto para leituras quanto para gravações:
$HTTP["url"] =~ "^/git/private" { include "git-auth.conf" }
VARIÁVEIS DO AMBIENTE
O git http-backend conta com as variáveis do ambiente CGI
definidas pelo servidor da Web que está sendo invocado, incluindo:
-
PATH_INFO
(casoGIT_PROJECT_ROOT
seja definido, caso contrário utilizePATH_TRANSLATED
) -
REMOTE_USER
-
REMOTE_ADDR
-
CONTENT_TYPE
-
QUERY_STRING
-
REQUEST_METHOD
A variável de ambiente GIT_HTTP_EXPORT_ALL
pode ser passada para o comando git-http-backend para ignorar a verificação do arquivo "git-daemon-export-ok" em cada repositório antes de permitir a exportação desse repositório.
A variável de ambiente GIT_HTTP_MAX_REQUEST_BUFFER
(ou a opção de configuração http.maxRequestBuffer
) pode ser definida para alterar a maior solicitação de negociação de referência que o git tratará durante uma busca; qualquer busca que exija um buffer maior não será bem-sucedida. Normalmente, esse valor não precisa ser alterado, mas pode ser útil se você estiver fazendo a busca num repositório com um número extremamente grande de refs. O valor pode ser especificado com uma unidade (100M
para 100 megabytes por exemplo). A predefinição é 10 megabytes.
Os clientes podem sondar por capacidades opcionais do protocolo (como o protocolo v2) utilizando o cabeçalho HTTP Git-Protocol
. Para ser compatível com eles, o conteúdo desse cabeçalho deve aparecer na variável de ambiente GIT_PROTOCOL
. A maioria dos servidores web passará esse cabeçalho para o CGI através da variável HTTP_GIT_PROTOCOL
e o git-http-backend
copiará automaticamente para a variável GIT_PROTOCOL
. Entretanto, alguns servidores web podem ser mais seletivos sobre quais os cabeçalhos eles passarão, nesse caso, eles precisam ser configurados de forma explícita (veja a menção do Git-Protocol
na configuração do Apache, a partir da seção EXEMPLOS mais recentes).
A estrutura define o GIT_COMMITTER_NAME
como $REMOTE_USER e GIT_COMMITTER_EMAIL
como ${REMOTE_USER}@http.${REMOTE_ADDR}, garantindo que quaisquer reflogs que forem criados através do comando git-receive-pack contenham algumas informações de identificação do ramo remoto do usuário que executou o push.
Todas as variáveis do ambiente CGI
estão disponíveis para cada um dos ganchos invocados pelo comando git-receive-pack.
GIT
Parte do conjunto git[1]