Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Merge branch 'master' of https://github.com/Lafaiet/progit

Conflicts:
	pt-br/03-git-branching/01-chapter3.markdown
  • Loading branch information...
commit f6e4eaf641f140cc4b76349743ab55e6bd13f159 2 parents b57c907 + 0cb765f
@fernandoalmeida authored
Showing with 11 additions and 11 deletions.
  1. +11 −11 pt-br/04-git-server/01-chapter4.markdown
View
22 pt-br/04-git-server/01-chapter4.markdown
@@ -1,6 +1,6 @@
# Git no Servidor #
-Neste ponto, você deve estar apto a fazer a maior parte das tarefas do dia a dia para as quais estará usando o Git. No entanto, para qualquer colaboração no Git, você precisará ter um repositório remoto de Git. Apesar de que você pode tecnicamente enviar (push) mudanças para e receber (pull) mudanças de repositorios de indivíduos, isto é desencorajado pois você pode facilmente confundir no que eles estão trabalhando se não for cuidadoso. Além disso, você quer que seus colaboradores possam acessar o repositório mesmo quando seu computador estiver offline — ter um repositório comum mais confiável é muitas vezes útil. Portanto, o método preferido para colaborar com alguém é configurar um repositório intermediário que vocês dois podem acessar, enviar para (push to) e receber de (pull from). Nos iremos nos referir a este repositório como um "Servidor Git"; mas você perceberá que geralmente são necessários uma quantidade ínfima de recursos para hospedar um repositório Git, logo você raramente precisará de um servidor inteiro para ele.
+Neste ponto, você deve estar apto a fazer a maior parte das tarefas do dia a dia para as quais estará usando o Git. No entanto, para qualquer colaboração no Git, você precisará ter um repositório remoto de Git. Apesar de que você pode tecnicamente enviar (push) mudanças para e receber (pull) mudanças de repositórios de indivíduos, isto é desencorajado pois você pode facilmente confundir no que eles estão trabalhando se não for cuidadoso. Além disso, você quer que seus colaboradores possam acessar o repositório mesmo quando seu computador estiver offline — ter um repositório comum mais confiável é muitas vezes útil. Portanto, o método preferido para colaborar com alguém é configurar um repositório intermediário que vocês dois podem acessar, enviar para (push to) e receber de (pull from). Nos iremos nos referir a este repositório como um "Servidor Git"; mas você perceberá que geralmente são necessários uma quantidade ínfima de recursos para hospedar um repositório Git, logo você raramente precisará de um servidor inteiro para ele.
Rodar um servidor Git é simples. Primeiro, você escolhe quais protocolos seu servidor usará para se comunicar. A primeira seção deste capítulo cobrirá os protocolos disponíveis e os prós e contras de cada um. As próximas seções explicararão algumas configurações típicas usando estes protocolos e como fazer o seu servidor rodar com eles. Por último, passaremos por algumas opções de hospedagem, se você não se importar em hospedar seu código no servidor dos outros e não quiser passar pelo incômodo de configurar e manter seu próprio servidor.
@@ -81,9 +81,9 @@ O protocolo Git é o mais rápido entre os disponíveis. Se você está servindo
O lado ruim do protocolo Git é a falta de autenticação. É geralmente indesejável que o protocolo Git seja o único acesso ao seu projeto. Geralmente, você o usará em par com um acesso SSH para os poucos desenvolvedores com acesso de envio (push) e todos os outros usariam `git://` para acesso somente leitura.
É também provavelmente o protocolo mais difícil de configurar. Ele precisa rodar seu próprio daemon, que é específico — iremos olhar como configurar um na seção “Gitosis” deste capítulo — ele requer a configuração `xinetd` ou algo similar, o que não é sempre um passeio. Ele requer também acesso a porta 9418 via firewall, o que não é uma porta padrão que firewalls corporativas sempre permitem. Por trás de grandes firewalls corporativas, esta porta obscura está comumente bloqueada.
-### The HTTP/S Protocol ###
+### O protocolo HTTP/S ###
-Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the simplicity of setting it up. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (See Chapter 7 for details on Git hooks). At that point, anyone who can access the web server under which you put the repository can also clone your repository. To allow read access to your repository over HTTP, do something like this:
+Por ultimo nós temos o protocolo HTTP. A beleza do protocolo HTTP ou HTTPS é a simplicidade na configuração. Basicamente, tudo que você deve fazer é colocar o repósitório sobre a raíz do seu documento HTTP e configurar um hook 'post-update', e pronto (ver capítulo 7 para detalhes de Git hooks). Neste ponto, qualquer um que tiver acesso ao servidor web que você colocou o repositório também pode clonar seu repositório. Para permitir acesso de leitura ao seu repositório por meio de HTTP, faça algo assim:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
@@ -91,25 +91,25 @@ Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
-That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like
+Isso é tudo. O hook `post-update` que vem com o GIT por padrão roda o comando apropriado (`git update-server-info`) para fazer requisições e clonagens HTTP corretamente. Este comando é executado quando você envia para este repositório via SSH; logo, outras pessoas podem clonar por meio do comando
$ git clone http://example.com/gitproject.git
-In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web serverjust put the bare repository in its path. The Git data is served as basic static files (see Chapter 9 for details about exactly how it’s served).
+Nesse caso em particular, estamos usando o caminho `/var/www/htdocs` que é comum para as configurações Apache, mas você pode usar servidores web estáticosbasta colocar o repositório nesse caminho. O dado Git è disponibilizado como arquivo estático básico (ver capítulo 9 para detalhes sobre como exatamente isso é feito).
-It’s possible to make Git push over HTTP as well, although that technique isn’t as widely used and requires you to set up complex WebDAV requirements. Because it’s rarely used, we won’t cover it in this book. If you’re interested in using the HTTP-push protocols, you can read about preparing a repository for this purpose at `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. One nice thing about making Git push over HTTP is that you can use any WebDAV server, without specific Git features; so, you can use this functionality if your web-hosting provider supports WebDAV for writing updates to your web site.
+É possível fazer envios Git sobre HTTP também, no entanto essa técnica não é amplamente usada e requer que você configure complexos requisitos WebDAV. Por ser raramente usado, não iremos cobri-lo nesse livro. Se você tiver interese em usar protocolos de envio HTTP, poderá ler como preparar um repositório para esse propósito em `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. Uma coisa legal em se fazer envios HTTP é que você pode usar qualquer servidor WebDAV, sem funcionalidades Git específicas; então, você pode usar essa funcionalidade caso seu hospedador web suportar WebDAV para atualizações de escrita em seu web site.
-#### The Pros ####
+#### Os prós ####
-The upside of using the HTTP protocol is that it’s easy to set up. Running the handful of required commands gives you a simple way to give the world read access to your Git repository. It takes only a few minutes to do. The HTTP protocol also isn’t very resource intensive on your server. Because it generally uses a static HTTP server to serve all the data, a normal Apache server can serve thousands of files per second on averageit’s difficult to overload even a small server.
+A vantagem em se usar protocolo HTTP é a facilidade de configuração. Rodar poucos comandos necessários lhe fornece um jeito simples de dar ao mundo acesso de leitura ao seu repositório Git. Leva apenas alguns minutos para isso. O protocolo HTTP também não é muito oneroso ao servidor. Pelo fato de geralmente usar um servidor HTTP estático para fornecer todos os dados, um servidor Apache normal pode fornecer milhares de arquivos por segundo em médiaé difícil sobrecarregar até mesmo um servidor pequeno.
-You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS.
+Você também pode viabilizar seus repositórios somente para leitura usando HTTPS, o que significa que você pode criptografar a transferência de conteúdo; ou pode até fazer com que os clientes usem certificados de autenticação SSL. Geralmente, se você chega até esse ponto, é fácil usar chaves públicas SSH; mas no seu caso específico, usar certificados SSL ou outro método de autenticação baseada em HTTP para acessos somente de leitura sobre HTTPS pode ser uma solução melhor.
-Another nice thing is that HTTP is such a commonly used protocol that corporate firewalls are often set up to allow traffic through this port.
+Outra coisa legal é que o protocolo HTTP é tão comum de ser usado que firewalls são frequentemente configurados para permitir tráfego nessa porta.
#### The Cons ####
-The downside of serving your repository over HTTP is that it’s relatively inefficient for the client. It generally takes a lot longer to clone or fetch from the repository, and you often have a lot more network overhead and transfer volume over HTTP than with any of the other network protocols. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. For more information about the differences in efficiency between the HTTP protocol and the other protocols, see Chapter 9.
+A desvantagem de se disponibilizar seus repositórios usando HTTP é que isso é relativamente ineficiente para o cliente. Geralmente leva muito mais tempo para clonar ou baixar do repositório, e você frequentemente tem muito mais sobrecarga e volume de transferência com HTTP do que com qualquer outro protocolo de rede. Pelo fato de não ser inteligente ao que diz respeito a tranferir somente o dado que você precisa — não há trabalho dinânimo na parte do servidor nessas transações — O protocolo HTTP é por vezes citado como um protocolo _burro_ . Para mais informações a respeito das diferenças de eficiência entre o procoloco HTTP e outros protocolos, veja o Capítulo 9.
## Getting Git on a Server ##
Please sign in to comment.
Something went wrong with that request. Please try again.