From 9be193543fe9b1baa2afc2ed09f6afed4fc65480 Mon Sep 17 00:00:00 2001 From: wellyton-xs Date: Sun, 4 Jan 2026 23:06:37 -0300 Subject: [PATCH 1/2] Ajustes cap 4.1 --- book/04-git-server/sections/protocols.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index a29b0c7..a2b72a3 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -31,7 +31,7 @@ $ git clone file:///srv/git/project.git Git funciona um pouco diferente se você explicitamente especificar `file://` no começo da URL. Se você apenas especificar o caminho, o Git tenta usar caminhos absolutos ou diretamente copiar os arquivos que ele precisa. Se você especificar `file://`, o Git dispara um processo que ele normalmente usa para transferir dados pela rede que normalmente é um método de transferência de dados muito menos eficiente. -O principal motivo para especificar o prefixo `file://` é se você quer uma cópia limpa do repositório com referências estranhar ou objetos deixados de fora – geralmente depois de importar de outro sistema de controle de versão or algo similar (veja <> para tarefas de manutenção). +O principal motivo para especificar o prefixo `file://` é se você quer uma cópia limpa do repositório com referências estranhas ou objetos deixados de fora – geralmente depois de importar de outro sistema de controle de versão or algo similar (veja <> para tarefas de manutenção). Nós vamos usar o caminho normal porque fazendo isso é quase sempre mais rápido. Para adicionar um repositório local em um projeto Git já existente, você pode executar algo assim: @@ -61,7 +61,7 @@ Se você quer enviar do seu notebook quando você estiver em casa , você tem qu É importante mencionar que essa não é necessariamente a opção mais rápida se você está usando montagens compartilhadas de alguma forma. Um repositório local é mais rápido apenas se você tiver acesso aos dados. -Um repositório NFS geralmente é mais lento que um repositório em SSH no mesmo servidor, permitindo que o Git execute discos locais em cada sisteme. +Um repositório NFS geralmente é mais lento que um repositório em SSH no mesmo servidor, permitindo que o Git execute discos locais em cada sistema. Finalmente, este protocolo não prote o repositório contra danos acidentais. Todo usuário tem acesso total no diretório "remoto" pelo shell, e isso não os previne de mudar ou remover arquivos internos do Git e corromper o repositório. @@ -185,7 +185,7 @@ Se você quer permitir acesso anonimo somente leitura para seus projetos e tamb O próximo é o protocolo Git. Esse serviço especial vem empacotado com Git; Ele escuta uma porta dedicada (9418) que provê um serviço parecido com o protocolo SSH, mas absolutamente sem autenticação. Para um repositório ser usado pelo protocolo Git, você precisa criar o arquivo `git-daemon-export-ok` – o serviço não usará o repositório sem que o arquivo esteja nele – mas não há qualquer segurança além disso. -O repositório Git estará disponível para todo mundo para clonar ou não está. +Ou repositório Git estará disponível para todos clonarem ou não está. Isso significa que não haverá download por esse protocolo. Você pode habilitar o acesso para envio; mas dada a falta de autenticação, se você você habilitar o envio, qualquer um na internet poderia encontrar a URL dos seus projetos e enviar para eles. Basta dizer que isso é raro. @@ -196,11 +196,11 @@ O protocolo Git geralmente é o protocolo de rende mais rápido disponível. Se você está usando muito tráfego para um projeto público ou trabalhando em um projeto muito grande que não requer atenticação dos usuários para acesso de leitura, é provável que você quererá definir um serviço Git para seu projeto. Ele usa o mesmo mecanismo de transferência de dados que o protocolo SSH, mas sem sobrecarga de criptografia ou atenticação. -===== Os Contra +===== Os Contras A desvantagem do protocolo Git é a ausência de autenticação. Geralmente, é indesejável que o protocolo Git seja o único acesso ao seu projeto. Geralmente você o usará em conjunto com um acesso SSH ou HTTPS para alguns desenvolvedores que terão acesso para enviar e todos os outros usarão `git://` para acesso somente leitura. Ele também é o provavelmente o protocolo mais difícil de configurar. Ele precisa executar seu próprio serviço, o que requer configuração `xinetd` ou similar, o que não é sempre fácil. -Ele também querer um acesso do firewall à porta 9418, o que não é uma porta que por padrão os firewall corporativos sempre permitem. Grandes firewalls corporativos normalmente comumente bloqueiam essa porta obscura. +Ele também requer um acesso do firewall à porta 9418, o que não é uma porta que por padrão os firewall corporativos sempre permitem. Grandes firewalls corporativos normalmente comumente bloqueiam essa porta obscura. From 94f4cef812e89da93c3958db00e258c7b288acfc Mon Sep 17 00:00:00 2001 From: wellyton-xs Date: Wed, 7 Jan 2026 11:34:29 -0300 Subject: [PATCH 2/2] =?UTF-8?q?Tradu=C3=A7=C3=A3o=20cap=204?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Esse commit traz as traduções das seções: - 4.2 Instalando o Git em um servidor - 4.4 Configurando o servidor - 4.5 Git Daemon - 4.6 Smart HTTP - 4.7 GitWeb - 4.9 Opções hospedadas por terceiros --- book/04-git-server/sections/git-daemon.asc | 41 +++++---- .../sections/git-on-a-server.asc | 87 ++++++++++--------- book/04-git-server/sections/gitweb.asc | 35 ++++---- book/04-git-server/sections/hosted.asc | 15 ++-- .../sections/setting-up-server.asc | 58 ++++++------- book/04-git-server/sections/smart-http.asc | 45 +++++----- book/contributors.txt | 60 +++++++++++++ 7 files changed, 201 insertions(+), 140 deletions(-) create mode 100644 book/contributors.txt diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index c5332a4..01c79b5 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -1,34 +1,34 @@ === Git Daemon (((serving repositories, git protocol))) -Next we'll set up a daemon serving repositories over the ``Git'' protocol. -This is common choice for fast, unauthenticated access to your Git data. -Remember that since it's not an authenticated service, anything you serve over this protocol is public within its network. +Em seguida, configuraremos um daemon que disponibiliza repositórios sobre o protocolo ``Git''. +Esta é uma escolha comumpara acesso rápido e sem autenticação para seus dados Git. +Lembre-se de que, como não é um serviço autenticado, tudo que você disponibiliza através desse protocolo é público dentro da sua rede. -If you're running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. -If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each. +Se você estiver executando isso em um servidor fora do seu firewall, deve somente ser usado para projetos que sejam publicamente visíveis. +Se o servidor que você está executando isso estiver dentro do seu firewall, você pode usá-lo para projetos que um grande número de pessoas ou computadores (integração contínua ou servidores de compilação) tem acesso de apenas leitura, quando você não quer adicionar uma chave SSh para cada um. -In any case, the Git protocol is relatively easy to set up. -Basically, you need to run this command in a daemonized manner:(((git commands, daemon))) +Em todo caso, o protocolo Git é relativamente fácil de configurar. +Basicamente você precisa executar esse comando em modo daemon:(((git commands, daemon))) [source,console] ---- $ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/ ---- -`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. -If you're running a firewall, you'll also need to punch a hole in it at port 9418 on the box you're setting this up on. +`--reuseaddr` permite o servidor reiniciar sem esperar que conexões antigas expirem, a opção `--base-path` permite pessoas clonar o projeto sem especificar o caminho completo e o caminho no final indica ao daemon Git onde procurar por repositórios para exportar. +Se você estiver executando um firewall, você tamém precisará abrir uma conexão na porta 9418 no servidor onde está configurado o serviço. -You can daemonize this process a number of ways, depending on the operating system you're running. -On an Ubuntu machine, you can use an Upstart script. -So, in the following file +Você pode executar esse processo como daemon de várias maneiras, dependendo do sistema operacional que você está executando. +Em uma máquina Ubuntu, você pode usar um script Upstart. +Portanto, no seguinte arquivo: [source,console] ---- /etc/init/local-git-daemon.conf ---- -you put this script: +Você insere esse script: [source,console] ---- @@ -42,21 +42,20 @@ exec /usr/bin/git daemon \ respawn ---- -For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories – you can easily do this by creating a new user 'git-ro' and running the daemon as them. -For the sake of simplicity we'll simply run it as the same 'git' user that `git-shell` is running as. +Por motivos de segurança, é fortemente recomendado ter esse serviço executando como um usuário com permissões de somente leitura para os repositórios - você pode fazer isso facilmente criando um novo usuário 'git-ro' e executar o serviço como ele. +Para simplificar, nós vamos simplesmente executar com o mesmo usuário 'git' que está executando o `git-shell`. -When you restart your machine, your Git daemon will start automatically and respawn if it goes down. -To get it running without having to reboot, you can run this: +Quando você reiniciar sua máquina, seu serviço vai iniciar automaticamente e reiniciar caso seja interrompido. Para executá-lo sem precisar reiniciar, você pode executar o seguinte comando: [source,console] ---- $ initctl start local-git-daemon ---- -On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else – as long as you get that command daemonized and watched somehow. +Em outros sistemas, você pode querer usar o `xinetd`, um script no seu sistema `sysvinit` ou algo similar - contanto que você tenha esse comando em segundo plano e possa monitorá-lo de alguma forma. -Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to. -You can do this in each repository by creating a file named `git-daemon-export-ok`. +Em seguida, você precisa dizer ao Git quais repositórios permitir acesso não autenticado a serviços do servidor Git. +Você pode fazer isso em cada repositório criando um arquivo chamado `git-daemon-export-ok`. [source,console] ---- @@ -64,4 +63,4 @@ $ cd /path/to/project.git $ touch git-daemon-export-ok ---- -The presence of that file tells Git that it's OK to serve this project without authentication. +A presença desse arquivo diz ao Git que está tudo bem servir esse projeto sem autenticação. diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 9fa0af5..aab73b7 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -1,18 +1,18 @@ [[r_git_on_the_server]] -=== Getting Git on a Server +=== Instalando Git em um servidor -Now we'll cover setting up a Git service running these protocols on your own server. +Agora vamos abordar a configuração de um serviço git rodando esses protocolos em seu servidor. [NOTE] ==== -Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux based server, though it's also possible to run these services on Mac or Windows servers. -Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved. +Aqui estaremos demonstrando comandos e passos necessários para fazer instalações básicas e simplificadas em um servidor baseado em linux, embora seja possível rodar esses serviçoes em servidores Mac ou Windows. +Na prática, configurar um servidor de produção dentro da sua infraestrutura certamente irá envolver diferenças nas medidas de segurança ou nas ferramentas do sistema operacional, mas esperamos que isso lhe dê uma ideia geral do que está envolvido. ==== -In order to initially set up any Git server, you have to export an existing repository into a new bare repository – a repository that doesn't contain a working directory. -This is generally straightforward to do. -In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option.(((git commands, clone, bare))) -By convention, bare repository directories end in `.git`, like so: +Para configurar inicialmente qualquer servidor git, você tem que exportar um repositório existente em um novo repositório vazio (bare repository) - um repositório que não contém um diretório de trabalho. +Isso geralmente é fácil de fazer. +Para clonar seu repositório e criar um novo repositório vazio, você roda o comando com a opção `--bare`.(((git commands, clone, bare))) +Por convenção, diretórios vazios terminam com `.git`, como neste exemplo: [source,console] ---- @@ -21,40 +21,41 @@ Cloning into bare repository 'my_project.git'... done. ---- -You should now have a copy of the Git directory data in your `my_project.git` directory. +Agora você deve ter uma cópia do diretório de dados Git em seu diretório `my_project.git`. -This is roughly equivalent to something like +Isso é aproximadamente equivalente a algo como: [source,console] ---- $ cp -Rf my_project/.git my_project.git ---- -There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing. -It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. +Existem algumas pequenas diferenças no arquivo de configuração; mas para o seu propósito é praticamente a mesma coisa. +Ele pega o repositório Git isoladamente, sem um diretório de trabalho e cria um diretório específico apenas pare ele. [[r_bare_repo]] -==== Putting the Bare Repository on a Server +==== Colocando o repositório vazio em um servidor -Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. -Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/srv/git` directory. -Assuming that `/srv/git` exists on that server, you can set up your new repository by copying your bare repository over: +Agora que você tem uma cópia vazia do seu repositório, tudo que você precisa fazer é colocá-lo em um servidor e configurar seus protocolos. +Vamos supor que você configurou um servidor chamado `git.example.com` que você possui acesso via SSH e você quer armazenar todos os seus repositórios Git no diretório /srv/git. +Supondo que `/srv/git` exista no servidor, você pode configurar seu novo repositório copiando seu repositório vazio para ele: [source,console] ---- $ scp -r my_project.git user@git.example.com:/srv/git ---- -At this point, other users who have SSH access to the same server which has read-access to the `/srv/git` directory can clone your repository by running +Neste ponto, outros usuários que tenham acesso SSH para o mesmo servidor e que possuem permissão de leitura para o diretório `/srv/git` pode clonar seu repositório executando o seguinte comando: [source,console] ---- $ git clone user@git.example.com:/srv/git/my_project.git ---- -If a user SSHs into a server and has write access to the `/srv/git/my_project.git` directory, they will also automatically have push access. +Se um usuário acessar um servidor via SSH e tiver acesso ao diretório `/srv/git/my_project.git`, ele também vai automaticamente ter permissão para enviar alterações (push). -Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare))) +Git vai automaticamente adicionar permissões de escrita de grupo a um repositório corretamente se você rodar o comando `git init` +com a opção `--shared`.(((git commands, init, bare))) [source,console] ---- @@ -63,38 +64,38 @@ $ cd /srv/git/my_project.git $ git init --bare --shared ---- -You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. -Now you're ready to collaborate on the same project. +Veja o quão fácil é pegar um repositório Git, criar uma versão vazia e colocá-la em um servidor do qual você e seus colaboradores tem acesso SSH. +Agora vocês estão prontos para colaborar no mesmo projeto. -It's important to note that this is literally all you need to do to run a useful Git server to which several people have access – just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. -You're ready to go – nothing else needed. +É importante notar que isso é literalmente tudo o que você precisa fazer para executar um servidor Git funcional ao qual várias pessoas tenham acesso - basta adicionar contas com acesso SSH em um servidor e colocar um servidor vazio em algum lugar que todos esses usuários tenham acesso de leitura e escrita. Você está pronto - nada mais é necessário. -In the next few sections, you'll see how to expand to more sophisticated setups. -This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs and more. -However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. +Nas próximas seções, você verá como expandir para configurações mais sofisticadas. +Essa discussão irá incluir não ter que criar contas de usuários para cada usuário, adicionar acesso público de leitura para repositórios, configurar interfaces web e muito mais. +No entanto, mantenha em mente que para colaborar com algumas pessoas em um projeto privado, tudo que você _precisa_ é um servidor SSH e um repositório vazio. -==== Small Setups +==== Configurações pequenas -If you're a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. -One of the most complicated aspects of setting up a Git server is user management. -If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit more difficult to arrange. +Se você faz parte de uma pequena empresa ou está experimentanto Git em sua organização e tem poucos desenvolvedores, as coias podem ser simples para você. +Um dos aspectos mais complicados de configurar um servidor Git é o gerenciamento de usuários. +Se você quer que alguns repositórios tenham acesso de somente leitura para certos usuários e leitura/escrita para outros, acesso e permissões podem ser um pouco mais difíceis de configurar. -===== SSH Access +===== Acesso SSH (((serving repositories, SSH))) -If you have a server to which all your developers already have SSH access, it's generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). -If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs. -If you want to place your repositories on a server that doesn't have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them. -We assume that if you have a server with which to do this, you already have an SSH server installed, and that's how you're accessing the server. +Se você tem um servidor do qual todos os seus desenvolvedores já tem acesso SSH, geralmente é mais fácil configurar seu primeiro repositório nele, porque você tem que fazer quase nenhum trabalho (como abordamos na seção anterior). +Se você quer um controle de acesso mais complexo em seus repositórios, você pode gerenciá-las com as permissões normais do sistema de arquivo do sistema operacional que seu servidor executa. -There are a few ways you can give access to everyone on your team. -The first is to set up accounts for everybody, which is straightforward but can be cumbersome. -You may not want to run `adduser` and set temporary passwords for every user. +Se você quer colocar seus servidores em um servidor que não possui contas para todos no seu time que você quer que tenha acesso de escrita, você terá qeu configurar acesso SSH para eles. +Nós assumimos que se você tem um servidor que deseja fazer isso, você já possuam um servidor SSH instalado e que é dessa maneira que você está acessando o servidor. -A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. -At that point, everyone will be able to access that machine via the 'git' user. -This doesn't affect the commit data in any way – the SSH user you connect as doesn't affect the commits you've recorded. +Há algumas maneiras de dar acesso a todos no seu time. +A primeira é configurar contas para todos, que é bem simples, mas pode ser trabalhoso. +Você pode não querer executar `adduser` e definir senhas temporárias para cada usuário. -Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. -As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work. +Um segundo método é criar um único usuário 'git' na máquina, pedir para cada usuário que deve ter acesso de escrita enviar para você uma chave pública SSH e adicionar essa chave no arquivo `~/.ssh/authorized_keys` do seu novo usuário 'git'. +A partir daí, todos vão ser capazes de acessar a máquina através do usuário 'git'. +Isso não afeta os dados de commit de forma alguma - o usuário SSH que você conecta não afeta os commits que você registrou. + +Outra maneira de fazer isso é configurar seu servidor SSH para autenticar a partir de um servidor LDAP ou alguma outra fonte de autenticação que você já tenha configurado. +Contanto que cada usuário possa ter acesso ao shell da máquina, qualquer mecanismo de autenticação SSH que você possa imaginar deve funcionar. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index ca7a46c..67a0374 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -1,17 +1,18 @@ === GitWeb (((serving repositories, GitWeb)))(((GitWeb))) -Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. -Git comes with a CGI script called GitWeb that is sometimes used for this. + +Agora que você tem acesso de leitura/escrita e acesso de somente leitura para seu projeto, você pode querer configurar um visualizador web. +Git vem com um script CGI para isso chamado GitWeb que às vezes é usado para isso. [[rgitweb]] .The GitWeb web-based user interface. image::images/git-instaweb.png[The GitWeb web-based user interface.] -If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. -On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. -If you're running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. -To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.(((git commands, instaweb))) +Se você quiser verificar como Gitweb vai se parecer para o seu projeto, Git vem com um comando para iniciar uma instancia temporária se você tiver um servidor leve no seu sistema como `lighttpd` ou `webrick`. +Em máquinas linux, `lighttpd` costuma ser instalado, então você pode ser capaz de executar isso com o comando `git instaweb` no diretório do seu projeto. +Se você estiver utilizando um Mac, Leopard vem pré-instalado com Ruby, então `webrick` pode ser sua melhor opção. +Para iniciar `instaweb` com um servidor que não seja lighttpd, você pode executar com a opção `--httpd`.(((git commands, instaweb))) [source,console] ---- @@ -20,19 +21,19 @@ $ git instaweb --httpd=webrick [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] ---- -That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. -It's pretty easy on your part. -When you're done and want to shut down the server, you can run the same command with the `--stop` option: +Isso inicia um servidor HTTPD na porta 1234 e então automaticamente inicia um browser web que abre nessa página. +É bem fácil da sua parte. +Quando terminar e quiser desligar o servidor, você pode rodar o mesmo comando com a opção `--stop`: [source,console] ---- $ git instaweb --httpd=webrick --stop ---- -If you want to run the web interface on a server all the time for your team or for an open source project you're hosting, you'll need to set up the CGI script to be served by your normal web server. -Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. -We'll walk through installing GitWeb manually very quickly. -First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: +Se você quiser executar a interface web em um servidor em tempo integral para o seu time ou para um projeto de código aberto que você esteja hospedando, você precisa configurar o script CGI para ser servido pelo seu servidor web normal. +Algumas distribuições tem um pacote `gitweb` que você pode ser capaz de instalar via `apt` ou `yum`, então você pode querer tentar isso primeiro. +Vamos mostrar rapidamente como instalar o GitWeb manualmente. +Primeiro, você precisa obter o código fonte do git, que vem com o GitWeb e gerar o script CGI customizado: [source,console] ---- @@ -47,8 +48,8 @@ make[2]: `GIT-VERSION-FILE' is up to date. $ sudo cp -Rf gitweb /var/www/ ---- -Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. -Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: +Note que você tem que informar ao comando onde encontrar os seus repositórios Git com a variável `GITWEB_PROJECTROOT`. +Agora, você precisa fazer o Apache usar CGI para esse script, para o qual você pode adicionar um host virtual: [source,console] ---- @@ -65,6 +66,4 @@ Now, you need to make Apache use CGI for that script, for which you can add a Vi ---- - -Again, GitWeb can be served with any CGI or Perl capable web server; if you prefer to use something else, it shouldn't be difficult to set up. -At this point, you should be able to visit `http://gitserver/` to view your repositories online. +Novamente, GitWeb pode ser servido com qualquer servidor web capaz de executar CGI ou Perl; se você preferir usar algo diferente, não deve ser difícil de configurar. diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index 6828f64..445c33b 100644 --- a/book/04-git-server/sections/hosted.asc +++ b/book/04-git-server/sections/hosted.asc @@ -1,10 +1,11 @@ -=== Third Party Hosted Options +=== Opções hospedadas por terceiros -If you don't want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. -Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. -Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with. +Se você não quiser passar por todo o trabalho envolvendo configurar seu próprio servidor Git, existem muitas opções para hospedar seus projetos Git em sites externos dedicados a hospedagem. +Fazer isso oferece várias vantagens: um site de hospedagem é geralmente mais rápido e fácil de configurar e fácil de iniciar projetos e nenhuma manutenção ou monitoramento é necessário. +Mesmo que você configure e execute seu próprio servidor internamente, você ainda pode querer usar um site público para hospedar seu projeto de código aberto - geralmente é mais fácil para a comunidade de código aberto encontrar e ajudar você com isso. -These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. -To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[] +Atualmente, você tem um grande numero de opções de hospedagem para escolher, cada uma com diferentes vantagens e desvantagens. +Para ver uma lista atualizada, verifique a pagina na GitHosting na principal wiki Git em: +https://git.wiki.kernel.org/index.php/GitHosting[] -We'll cover using GitHub in detail in <>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server. +Nós vamos cobrir o uso do GitHub em detalhes em <>, já que é o maior serviço de hospedagem Git disponível você pode precisar interagir com projetos hospedados nele de qualquer forma, mas existem dezenas de outras opções para escolher caso você não queira configurar seu próprio servidor Git. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index e24c27b..9fa4c9a 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -1,10 +1,10 @@ [[r_setting_up_server]] -=== Setting Up the Server +=== Configurando o servidor -Let's walk through setting up SSH access on the server side. -In this example, you'll use the `authorized_keys` method for authenticating your users. -We also assume you're running a standard Linux distribution like Ubuntu. -First, you create a `git` user and a `.ssh` directory for that user. +Vamos analisar como configurar acesso SSH no lado do servidor. +Nesse exemplo, você utilizará o método `authorized_keys` para autenticar seus usuários. +Também presumiremos que você está usando uma distribuição Linux padrão, como Ubuntu. +Primeiro, você cria um usuário `git` e um diretório `.ssh` para esse usuário. [source,console] ---- @@ -15,9 +15,9 @@ $ mkdir .ssh && chmod 700 .ssh $ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys ---- -Next, you need to add some developer SSH public keys to the `authorized_keys` file for the `git` user. -Let's assume you have some trusted public keys and have saved them to temporary files. -Again, the public keys look something like this: +Em seguida, você precisa adicionar algumas chaves SSH públicas de desenvolvedor ao arquivo `authorized_keus` do usuário git. +Vamos supor que você tem algumas chaves públicas confiáveis e que você salvou eles em arquivos temporários. +Novamente, as chaves públicas se parecem com algo assim: [source,console] ---- @@ -30,7 +30,7 @@ O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair ---- -You just append them to the `git` user's `authorized_keys` file in its `.ssh` directory: +Basta adicioná-las ao arquivo `authorized_keys` do usuário `git` no diretório `.ssh`: [source,console] ---- @@ -39,7 +39,7 @@ $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys ---- -Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:(((git commands, init, bare))) +Agora, você pode configurar um repositório vazio para eles rodando `git init` com a opção `--bare`, que inicializa um repositório sem nenhum diretório de trabalho:(((git commands, init, bare))) [source,console] ---- @@ -50,10 +50,10 @@ $ git init --bare Initialized empty Git repository in /srv/git/project.git/ ---- -Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. -Note that someone must shell onto the machine and create a bare repository every time you want to add a project. -Let's use `gitserver` as the hostname of the server on which you've set up your `git` user and repository. -If you're running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is (assuming that `myproject` is an existing project with files in it): +Então, John, Josie ou Jessica podem enviar a primeira versão de seus projetos nesse repositório, adicionando-o como um projeto remoto e criando uma branch. +Note que alguém precisa acessar o shell da máquina e criar um repositório vazio toda vez que você quiser adicionar um projeto. +Vamos usar `gitserver` como o nome do host do servidor no qual você configurou seu usuário `git` e o repositório. +Se você estiver executando internamente e configurar um DNS para `gitserver` apontando para esse servidor, então você pode usar os comandos praticamente como estão (considerando que `myproject` seja um projeto existente com arquivos): [source,console] ---- @@ -66,7 +66,7 @@ $ git remote add origin git@gitserver:/srv/git/project.git $ git push origin master ---- -At this point, the others can clone it down and push changes back up just as easily: +Apartir desse ponto, os outros podem cloná-lo e enviar alterações de volta com facilidade: [source,console] ---- @@ -77,15 +77,15 @@ $ git commit -am 'fix for the README file' $ git push origin master ---- -With this method, you can quickly get a read/write Git server up and running for a handful of developers. +Com esse método, você pode rapidamente configurar e executar um Servidor git de leitura/gravação para um pequeno grupo de desenvolvedores. -You should note that currently all these users can also log into the server and get a shell as the `git` user. -If you want to restrict that, you will have to change the shell to something else in the `passwd` file. +É importante notar que, atualmente, todos esses usuários também podem fazer login no servidor e acessar um shell como o usuário `git`. +Se você quiser restringir isso, você deve mudar o shell para alguma outra coisa no arquivo `passwd`. -You can easily restrict the `git` user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. -If you set this as your `git` user's login shell, then the `git` user can't have normal shell access to your server. -To use this, specify `git-shell` instead of bash or csh for your user's login shell. -To do so, you must first add `git-shell` to `/etc/shells` if it's not already there: +Você pode facilmente restringir o usuário `git` para apenas realizar atividades do Git com uma ferramenta de shell limitada chamada `git-shell` que vem com o Git. +Se você configurar isso como o shell de login do seu usuário `git`, então o usuário `git` não pode ter acesso ao shell normal do seu servidor. +Para usar isso, especifique `git-shell` ao invés de bash ou csh para o shell de login do seu usuário. +Para isso, primeiro você precisa adicionar `git-shell` para `/etc/shells` se já não estiver lá: [source,console] ---- @@ -94,15 +94,15 @@ $ which git-shell # make sure git-shell is installed on your system. $ sudo vim /etc/shells # and add the path to git-shell from last command ---- -Now you can edit the shell for a user using `chsh `: +Agora você pode editar o shell para um usuário utilizando `chsh `: [source,console] ---- $ sudo chsh git # and enter the path to git-shell, usually: /usr/bin/git-shell ---- -Now, the `git` user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine. -If you try, you'll see a login rejection like this: +Agora, o usuário do Git só pode usar a conexão SSH para enviar e receber alterações em repositórios Git e não pode acessar o shell da máquina. +Se você tentar, verá uma mensagem rejeitando o login como esta: [source,console] ---- @@ -112,7 +112,7 @@ hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed. ---- -Now Git network commands will still work just fine but the users won't be able to get a shell. -As the output states, you can also set up a directory in the `git` user's home directory that customizes the `git-shell` command a bit. -For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that. -Run `git help shell` for more information on customizing the shell.(((git commands, help))) +Agora, comandos de rede Git irão continuar funcionando bem, mas usuários não serão capazes de conseguir acesso ao shell. +Conforme indicado na saída, você pode configurar um diretório no diretório home do usuário `git` que customiza um pouco o comando `git-shell` +Por exemplo, você pode restringir os comandos que o servidor vai aceitar ou pode customizar a mensagem que usuários veem ao tentar acessar via SSH. +Execute `git help shell` para mais informações de como customizar o shell.(((git commands, help))) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 967fd0e..1bf6dd4 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -1,14 +1,14 @@ === Smart HTTP (((serving repositories, HTTP))) -We now have authenticated access through SSH and unauthenticated access through `git://`, but there is also a protocol that can do both at the same time. -Setting up Smart HTTP is basically just enabling a CGI script that is provided with Git called `git-http-backend` on the server.(((git commands, "http-backend"))) -This CGI will read the path and headers sent by a `git fetch` or `git push` to an HTTP URL and determine if the client can communicate over HTTP (which is true for any client since version 1.6.6). -If the CGI sees that the client is smart, it will communicate smartly with it, otherwise it will fall back to the dumb behavior (so it is backward compatible for reads with older clients). +Agora temos acesso autenticado através de SSH e acesso não autenticado através de `git://`, mas existe um protocolo que pode fazer os dois ao mesmo tempo. +Configurar Smart HTTP consiste basicamente em habilitar um script em CGI que é fornecido com Git, chamado `git-http-backend` no servidor. +Esse CGI irá ler o caminho e os cabeçalhos enviados pelo comando `git fetch` ou `git push` para uma URL HTTP e determinar se o cliente pode se comunicar via HTTP (que é válido para qualquer clientea partir da versão 1.6.6). +Se o CGI ver que o cliente é inteligente, ele continuará a se comunicar inteligentemente com ele, caso contrário vai recorrer ao comportamento padrão (então é compatível para leituras com clientes antigos). -Let's walk through a very basic setup. -We'll set this up with Apache as the CGI server. -If you don't have Apache setup, you can do so on a Linux box with something like this:(((Apache))) +Vamos analisar uma configuração bem básica. +Vamos configurar isso com o Apache como servidor CGI. +Se você não tiver Apache configurado, você pode fazer isso em um sistema linux com algo como isso:(((Apache))) [source,console] ---- @@ -16,16 +16,16 @@ $ sudo apt-get install apache2 apache2-utils $ a2enmod cgi alias env rewrite ---- -This also enables the `mod_cgi`, `mod_alias`, `mod_env`, and `mod_rewrite` modules, which are all needed for this to work properly. +Isso também habilita os módulos `mod_cgi`, `mod_alias`, `mod_env` e `mod_rewrite`, que são todos necessários para que isso funcione corretamente. -You’ll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: +Você também precisa definir o grupo de usuários Unix dos diretórios `/srv/git` para `www-data` para que seu servidor web possa ler e ter acesso de leitura aos repositórios, pois a instância do Apache que executa o CGI estará (por padrão) executando isso como esse usuário: [source,console] ---- $ chgrp -R www-data /srv/git ---- -Next we need to add some things to the Apache configuration to run the `git-http-backend` as the handler for anything coming into the `/git` path of your web server. +Em seguida, nós precisamos adicionar algumas coisas a configuração do Apache para executar o `git-http-backend` como o gerenciador de tudo que chegar para o gaminho `/git` de seu servidor web. [source,console] ---- @@ -34,9 +34,9 @@ SetEnv GIT_HTTP_EXPORT_ALL ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ---- -If you leave out `GIT_HTTP_EXPORT_ALL` environment variable, then Git will only serve to unauthenticated clients the repositories with the `git-daemon-export-ok` file in them, just like the Git daemon did. +Se você omitir a variável de ambiente `GIT_HTTP_EXPORT_ALL`, então o Git irá servir aos clientes não autenticados os repositórios com um arquivo `git-daemon-export-ok`, assim como o serviço Git fez. -Finally you'll want to tell Apache to allow requests to `git-http-backend` and make writes be authenticated somehow, possibly with an Auth block like this: +Por fim, você precisa instruir ao Apache para permitir requisições para o `git-http-backend` e fazer as escritas serem autenticadas de alguma forma, possivelmente com um bloco de autenticação como esse: [source,console] ---- @@ -56,24 +56,25 @@ RewriteRule ^/git/ - [E=AUTHREQUIRED] ---- -That will require you to create a `.htpasswd` file containing the passwords of all the valid users. -Here is an example of adding a ``schacon'' user to the file: +Isso exigirá que você crie um arquivo `.htpaswd` contendo as senhas de todos os seus usuários válidos. +Aqui está um exemplo de como adicionar um usuário ``shacon'' no arquivo: [source,console] ---- $ htpasswd -c /srv/git/.htpasswd schacon ---- -There are tons of ways to have Apache authenticate users, you'll have to choose and implement one of them. -This is just the simplest example we could come up with. -You'll also almost certainly want to set this up over SSL so all this data is encrypted. +Há diversas maneiras de fazer o Apache autenticar usuários, você tem que escolher e implementar uma delas. +Esse é apenas o exemplo mais simples que nós preparamos. +Você provavelmente vai querer configurar isso sobre SSL então todos os dados serão criptografados. -We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs. -The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. -It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. -You can do this with nearly any CGI-capable web server, so go with the one that you know best. +Não queremos ir tão longe nessa toca de coelho de configurações específicas de Apache, já que você pode muito bem estar usando um servidor diferente que tenha diferentes necessidades de autenticação. +A ideia é que o Git vem com um CGI chamado `git-http-backend` que quando é chamado faz toda a negociação para enviar e receber dados via HTTP +Isso não implementa autenticação por si só, mas pode facilmente ser controlado por uma camada do servidor web que faz isso. +Você pode fazer isso com qualquer servidor capaz de executar CGI, então utilize um que você conheça melhor. [NOTE] ==== -For more information on configuring authentication in Apache, check out the Apache docs here: http://httpd.apache.org/docs/current/howto/auth.html[] +Para mais informações de como configurar autenticação no Apache, veja a documentação do Apache aqui: +http://httpd.apache.org/docs/current/howto/auth.html[] ==== diff --git a/book/contributors.txt b/book/contributors.txt new file mode 100644 index 0000000..466d0d9 --- /dev/null +++ b/book/contributors.txt @@ -0,0 +1,60 @@ +Adrien Ollier git-em Paweł Krupiński +Akrom K goekboet Pedro 7úcio +Aleh Suprunovich haripetrov Peter Kokot +Alexandre Garnier Haruo Nakayama petsuter +Alexandre R. Saccol Helmut K. C. Tessarek Philippe Miossec +allen joslin Henrique Serraglia Rafael Rossi +Altemir Pacheco i-give-up rahrah +André Girol iprok Ramon Domingos +Andrei Dascalu Jan Groenewald Ray Chen +André Moreira Jean-Noel Avila Ricky Senft +Andrew MacFie Jean-Noël Avila Rintze M. Zelle +Andrew Murphy Jeroen Oortwijn rmzelle +AndyGee Jim Hill Rob Blanco +AnneTheAgile Johannes Schindelin Robert P. Goldman +Anthony Loiseau johnhar Rogerio Prado de Jesus +Antonino Ingargiola Jon Forrest Rohan D'Souza +Anton Trunov Jon Freed Roman Kosenko +atalakam Joris Valette Ronald Wampler +Atul Varma Joshua Webb Rüdiger Herrmann +AugustoAMendes Justin Clift Sam Ford +axmbo Kaartic Sivaraam Sanders Kleinfeld +Benjamin Dopplinger Kausar Mehmood sanders@oreilly.com +Ben Sima Kenneth Kin Lum Sarah Schneider +Brett Cannon Krzysztof Szumny SATO Yusuke +Cadel Watson Kyrylo Yatsenko Saurav Sachidanand +Carlos Martín Nieto Lars Vogel schacon@gmail.com +Carlos Schults Lazar95 Scott Bronson +Changwoo Park Leonard Laszlo Sean Head +Christopher Wilson Logan Hasson Sebastian Krause +Christoph Prokop Louise Corrigan Sergio Cabral +Cory Donnelly Lucas Barros Shengbin Meng +cupnodes Lucas Oshiro Siarhei Krukau +Cyril Luc Morin Skyper +Damien Tournoud Marcelo Criscuolo Song Li +Daniele Tricoli Marius Žilėnas spacewander +Daniel Shahaf Markus KARG Stephan van Maris +Danny Lin Marti Bolivar Steven Roddis +Dan Schmidt Masood Fallahpoor Sven Selberg +David Rogers Matheus Catarino França Tacini +Denis Costa Matthew Miner Thanix +Denis Savitskiy Matthieu Moy Thomas Ackermann +devwebcl mestihudson Tomoki Aonuma +DiamondeX Michael MacAskill Tom Schady +Dmitri Tikhonov Michael Sheaver twekberg +douglasmoraes Michael Welch un1versal +Douglas Moraes Michiel van der Wulp Vadim Markovtsev +dualsky Mike Charles Vanessa Ribeiro +Fabiano Leite Mike Thibodeau Vangelis Katsikaros +Felix Nehrke mmikeww Van Ribeiro +Fillippe Prata mosdalsvsocld Vinicius Barbosa de Aguiar +Flavio V Filho Niels Widger Vitaly Kuznetsov +flaviovisnardifilho Nils Reuße wellyton-xs +flip111 Owen William Gathoye +flyingzumwalt Pablo Schläpfer xJom +Fornost461 Pascal Berger Yann Soubeyrand +Francilio Araújo Pascal Borreli Yue Lin Ho +Francisco de Assis Boldt patrick96 Yusuke SATO +Frederico Mazzone Patrick Steinhardt zwPapEr +George Tavares Lopes paveljanik ᐯᕮᒪᗝᑕᕮᒣ +Geraldo Pavel Janík 狄卢