Browse files

A few changes and translations on the PT-BR version

  • Loading branch information...
1 parent 8647b58 commit fefc64d96b8f8ba1dd343fc14a616f4987c207ec Lafaiet committed Jul 14, 2011
Showing with 8 additions and 8 deletions.
  1. +1 −1 pt-br/03-git-branching/01-chapter3.markdown
  2. +7 −7 pt-br/04-git-server/01-chapter4.markdown
View
2 pt-br/03-git-branching/01-chapter3.markdown
@@ -594,4 +594,4 @@ Se você tratar o rebase como uma maneira de manter limpo e trabalhar com commit
## Sumário ##
-Nós abrangemos o básico do branch e merge no Git. Você deve ser sentir confortável criar e mudar para novos branches, mudar entre branches e fazer o merge de branches locais. Você deve ser capaz de compartilhar seus branches enviando eles a um servidor compartilhado, trabalhar com outros em branches compartilhados e fazer o rebase de seus branches antes de compartilhá-los.
+Nós abrangemos o básico do branch e merge no Git. Você deve se sentir confortável criar e mudar para novos branches, mudar entre branches e fazer o merge de branches locais. Você deve ser capaz de compartilhar seus branches enviando eles a um servidor compartilhado, trabalhar com outros em branches compartilhados e fazer o rebase de seus branches antes de compartilhá-los.
View
14 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,25 +81,25 @@ 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ís 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
$ cd gitproject.git
$ 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 funcionalidaes 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 average — it’s difficult to overload even a small server.

0 comments on commit fefc64d

Please sign in to comment.