Git 🌙
Français â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-http-backend last updated in 2.43.0

NOM

git-http-backend - Implémentation cÎté serveur de Git sur HTTP

SYNOPSIS

git http-backend

DESCRIPTION

Un simple programme CGI pour servir le contenu d’un dĂ©pĂŽt Git aux clients Git qui accĂšdent au dĂ©pĂŽt via les protocoles http:// et https://. Le programme supporte les clients qui rĂ©cupĂšrent des donnĂ©es en utilisant Ă  la fois le protocole HTTP intelligent et le protocole HTTP muet rĂ©trocompatible, ainsi que les clients qui poussent des donnĂ©es en utilisant le protocole HTTP intelligent. Il supporte Ă©galement le protocole "v2" de Git, plus efficace, s’il est correctement configuré ; voir la discussion sur GIT_PROTOCOL dans la section ENVIRONNEMENT ci-dessous.

Il vĂ©rifie que le rĂ©pertoire possĂšde le fichier magique "git-daemon-export-ok", et il refusera d’exporter tout rĂ©pertoire Git qui n’a pas Ă©tĂ© explicitement marquĂ© pour l’exportation de cette maniĂšre (Ă  moins que la variable d’environnement GIT_HTTP_EXPORT_ALL ne soit dĂ©finie).

Par défaut, seul le service upload-pack est activé, qui sert les clients git fetch-pack et git ls-remote, qui sont invoqués à partir de git fetch, git pull, et git clone. Si le client est authentifié, le service receive-pack est activé et sert les clients git send-pack, qui sont invoqués à partir de git push.

SERVICES

Ces services peuvent ĂȘtre activĂ©s/dĂ©sactivĂ©s grĂące au ficher de configuration par dĂ©pĂŽt :

http.getanyfile

Ceci sert les clients Git plus anciens que la version 1.6.6 qui ne sont pas en mesure d’utiliser le service de tĂ©lĂ©versement de paquet. Lorsqu’il est activĂ©, les clients sont capables de lire n’importe quel fichier dans le dĂ©pĂŽt, y compris les objets qui ne sont plus accessibles depuis une branche mais qui sont toujours prĂ©sents. Il est activĂ© par dĂ©faut, mais un dĂ©pĂŽt peut le dĂ©sactiver en mettant cet Ă©lĂ©ment de configuration Ă  false.

http.uploadpack

Cela sert aux clients git fetch-pack et git ls-remote. Il est activé par défaut, mais un dépÎt peut le désactiver en définissant cet élément de configuration sur false.

http.receivepack

Ceci sert les clients git send-pack, permettant de pousser. Il est dĂ©sactivĂ© par dĂ©faut pour les utilisateurs anonymes, et activĂ© par dĂ©faut pour les utilisateurs authentifiĂ©s par le serveur web. Il peut ĂȘtre dĂ©sactivĂ© en mettant cet Ă©lĂ©ment Ă  false, ou activĂ© pour tous les utilisateurs, y compris les utilisateurs anonymes, en le mettant Ă  true.

TRADUCTION D’URL

Pour dĂ©terminer l’emplacement du dĂ©pĂŽt sur le disque, git http-backend concatĂšne les variables d’environnement PATH_INFO, qui est dĂ©finie automatiquement par le serveur web, et GIT_PROJECT_ROOT, qui doit ĂȘtre dĂ©finie manuellement dans la configuration du serveur web. Si GIT_PROJECT_ROOT n’est pas dĂ©fini, git http-backend lit PATH_TRANSLATED, qui est Ă©galement dĂ©fini automatiquement par le serveur web.

EXEMPLES

Tous les exemples suivants font correspondre http://$hostname/git/foo/bar.git Ă  /var/www/git/foo/bar.git.

Apache 2.x

Assurez-vous que mod_cgi, mod_alias et mod_env sont activés, définissez GIT_PROJECT_ROOT (ou DocumentRoot) de maniÚre appropriée, et créez un ScriptAlias pour le CGI :

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

# Ce n'est pas strictement nécessaire avec Apache et une version moderne de
# git-http-backend, car le serveur web transmettra l'en-tĂȘte dans l'environnement
# l'environnement en tant que HTTP_GIT_PROTOCOL, et http-backend le copiera dans
# GIT_PROTOCOL. Mais vous pouvez avoir besoin de cette ligne (ou quelque chose de similaire si vous
# utilisez un serveur web différent), ou si vous voulez supporter d'anciennes versions de Git
# qui ne faisaient pas cette copie.
#
# Avoir le serveur web qui met en place GIT_PROTOCOL est tout Ă  fait acceptable mĂȘme avec les
# versions modernes (et aura la priorité sur HTTP_GIT_PROTOCOL,
# ce qui signifie qu'il peut ĂȘtre utilisĂ© pour passer outre la demande du client).
SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0

Pour permettre un accĂšs anonyme en lecture mais un accĂšs authentifiĂ© en Ă©criture, il faut une autorisation Ă  la fois pour l’annonce initiale (que nous dĂ©tectons comme une poussĂ©e via le paramĂštre de service dans la chaĂźne de requĂȘte) et pour l’invocation de receive-pack lui-mĂȘme :

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>

Si vous n’avez pas mod_rewrite disponible pour tester la correspondance de la chaĂźne de requĂȘte, il est suffisant de protĂ©ger git-receive-pack lui-mĂȘme, comme :

<LocationMatch "^/git/.*/git-receive-pack$">
	AuthType Basic
	AuthName "Git Access"
	Require group committers
	...
</LocationMatch>

Dans ce mode, le serveur ne demandera pas d’authentification avant que le client ne commence la phase de nĂ©gociation de l’objet de la poussĂ©e, plutĂŽt que lors du contact initial. Pour cette raison, vous devez Ă©galement activer l’option de configuration http.receivepack dans tous les dĂ©pĂŽts qui devraient accepter une poussĂ©e. Le comportement par dĂ©faut, si http.receivepack n’est pas activĂ©, est de rejeter toute poussĂ©e par des utilisateurs non authentifiĂ©s ; la requĂȘte initiale rapportera donc 403 Forbidden au client, sans mĂȘme lui donner l’opportunitĂ© de s’authentifier.

Pour exiger l’authentification Ă  la fois pour les lectures et les Ă©critures, utilisez une directive Location autour du dĂ©pĂŽt ou de l’un de ses rĂ©pertoires parents :

<Location /git/private>
	AuthType Basic
	AuthName "Private Git Access"
	Require group committers
	...
</Location>

Pour servir gitweb Ă  la mĂȘme url, utilisez un ScriptAliasMatch uniquement pour les URLs que git http-backend peut gĂ©rer, et transfĂ©rez le reste Ă  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/

Pour servir plusieurs dépÎts de différents espaces gitnamespaces[7] dans un seul dépÎt :

SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
Apache 2.x statique accéléré

Similaire Ă  ci-dessus, mais Apache peut ĂȘtre utilisĂ© pour renvoyer des fichiers statiques stockĂ©s sur le disque. Sur de nombreux systĂšmes, cela peut ĂȘtre plus efficace car Apache peut demander au noyau de copier le contenu du fichier depuis le systĂšme de fichiers directement sur le rĂ©seau :

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/

Ceci peut ĂȘtre combinĂ© avec la configuration de 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

Assurez-vous que mod_cgi, mod_alias, mod_auth, mod_setenv sont chargĂ©s, puis dĂ©finissez GIT_PROJECT_ROOT de maniĂšre appropriĂ©e et redirigez toutes les requĂȘtes vers le 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" => ""
	)
}

Pour permettre un accÚs anonyme en lecture mais un accÚs authentifié en écriture :

$HTTP["querystring"] =~ "service=git-receive-pack" {
	include "git-auth.conf"
}
$HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
	include "git-auth.conf"
}

oĂč git-auth.conf ressemble Ă  quelque chose comme :

auth.require = (
	"/" => (
		"method" => "basic",
		"realm" => "Git Access",
		"require" => "valid-user"
	       )
)
# ...et configurer auth.backend ici

Pour exiger une authentification Ă  la fois pour les lectures et les Ă©critures :

$HTTP["url"] =~ "^/git/private" {
	include "git-auth.conf"
}

ENVIRONNEMENT

git http-backend s’appuie sur les variables d’environnement CGI dĂ©finies par le serveur web appelant, notamment :

  • PATH_INFO (si GIT_PROJECT_ROOT est dĂ©fini, sinon PATH_TRANSLATED)

  • REMOTE_USER

  • REMOTE_ADDR

  • CONTENT_TYPE

  • QUERY_STRING

  • REQUEST_METHOD

La variable d’environnement GIT_HTTP_EXPORT_ALL peut ĂȘtre passĂ©e Ă  git-http-backend pour contourner la vĂ©rification du fichier "git-daemon-export-ok" dans chaque dĂ©pĂŽt avant d’autoriser l’exportation de ce dĂ©pĂŽt.

La variable d’environnement GIT_HTTP_MAX_REQUEST_BUFFER (ou l’option de configuration http.maxRequestBuffer) peut ĂȘtre dĂ©finie pour changer la plus grande requĂȘte de nĂ©gociation de refs que git traitera pendant une rĂ©cupĂ©ration ; toute rĂ©cupĂ©ration nĂ©cessitant un tampon plus grand n’aboutira pas. Cette valeur n’a normalement pas besoin d’ĂȘtre modifiĂ©e, mais peut ĂȘtre utile si vous rĂ©cupĂ©rez des donnĂ©es d’un dĂ©pĂŽt avec un trĂšs grand nombre de refs. La valeur peut ĂȘtre spĂ©cifiĂ©e avec une unitĂ© (par exemple, 100M pour 100 mĂ©gaoctets). La valeur par dĂ©faut est de 10 mĂ©gaoctets.

Les clients peuvent rechercher des capacitĂ©s optionnelles du protocole (comme le protocole v2) en utilisant l’en-tĂȘte HTTP Git-Protocol. Afin de les prendre en charge, le contenu de cet en-tĂȘte doit apparaĂźtre dans la variable d’environnement GIT_PROTOCOL. La plupart des serveurs web passeront cet en-tĂȘte au CGI via la variable HTTP_GIT_PROTOCOL, et git-http-backend le copiera automatiquement dans GIT_PROTOCOL. Cependant, certains serveurs web peuvent ĂȘtre plus sĂ©lectifs sur les en-tĂȘtes qu’ils passent, dans ce cas ils doivent ĂȘtre configurĂ©s explicitement (voir la mention de Git-Protocol dans la configuration d’Apache dans la section EXEMPLES prĂ©cĂ©dente).

Le processus de backend dĂ©finit GIT_COMMITTER_NAME Ă  $REMOTE_USER et GIT_COMMITTER_EMAIL Ă  ${REMOTE_USER}@http.${REMOTE_ADDR}, s’assurant que tous les reflogs crĂ©Ă©s par git-receive-pack contiennent des informations d’identification de l’utilisateur distant qui a effectuĂ© la poussĂ©e.

Toutes les variables d’environnement CGI sont disponibles pour chacun des crochets invoquĂ©s par git-receive-pack.

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top