diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index dcf6328..a29b0c7 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -1,98 +1,99 @@ -=== The Protocols +=== Os Protocolos -Git can use four major protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. -Here we'll discuss what they are and in what basic circumstances you would want (or not want) to use them. +Git pode usar os quatro principais protocolos de transferência de dados: Local, HTTP, Secure Shell (SSH) e Git. +Aqui nós discutiremos o que eles são e em que circunstâncias você poderia querer (ou não) usá-los. -==== Local Protocol +==== Protocolo Local (((protocols, local))) -The most basic is the _Local protocol_, in which the remote repository is in another directory on disk. -This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. -The latter wouldn't be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. -If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. -To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. -For example, to clone a local repository, you can run something like this: +O mais básico é o _Protocolo Local_, em que o repositório remoto é outro diretório no disco. +Isso é frequentemente usado se todo seu time tem acesso à um sistema de arquivos compartilhado como uma montagem NFS, ou menos provavelmente no caso em que todos acessem o mesmo computador. +O último não seria o ideal, porque todas as intâncias do seu repositório de código ficariam no mesmo computador, fazendo com que uma perda catastrófica seja muito mais provável. + +Se você tem um sistema de arquivos montado e compartilhado, então você pode clonar, enviar e baixar do repositório local. +Para clonar um repositório como esse ou adicionar um como remoto em um projeto existente, use o caminho para o repositório como uma URL. + +Por exemplo, para clonar um repositório local, você pode executar algo assim: [source,console] ---- $ git clone /srv/git/project.git ---- -Or you can do this: +Ou você pode fazer assim: [source,console] ---- $ git clone file:///srv/git/project.git ---- -Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. -If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. -If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. -The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out – generally after an import from another version-control system or something similar (see <> for maintenance tasks). -We'll use the normal path here because doing so is almost always faster. +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). +Nós vamos usar o caminho normal porque fazendo isso é quase sempre mais rápido. -To add a local repository to an existing Git project, you can run something like this: +Para adicionar um repositório local em um projeto Git já existente, você pode executar algo assim: [source,console] ---- $ git remote add local_proj /srv/git/project.git ---- -Then, you can push to and pull from that remote as though you were doing so over a network. +Então, você pode enviar e baixar desse repositório como se você estivesse fazendo pela rede. + +===== Os Prós + +Os prós dos repositórios baseados em arquivos são que eles são simples e usam permissões de arquivo e acessos de rede já existentes. +Se você já tem um sistema de arquivos compartilhado que seu time inteiro tem acesso, configurar um repositório é muito fácil. +Você cola a cópia do repositório vazio (bare repository) em algum lugar que todos tem acesso para ler/escrever permissões como você faria com qualquer outro diretório. -===== The Pros +Nós discutiremos como exportar uma cópia de um repositório vazio (bare repository) para esse propósito em <>. -The pros of file-based repositories are that they're simple and they use existing file permissions and network access. -If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. -You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. -We'll discuss how to export a bare repository copy for this purpose in <>. +Esta é uma boa opção para rapidamente pegar o trabalho do repositório de trabalho de outra pessoa. +Se você ou seu colega de trabalho estão trabalhando no mesmo projeto e ele quiser que você verifique alguma coisa, executar um comando como `git pull /home/john/project` geralmente é mais fácil que enviar para um servidor remoto e baixar. -This is also a nice option for quickly grabbing work from someone else's working repository. -If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you pulling down. +===== Os Contras -===== The Cons +Os contras desse método são que geralmente acesso compartilhado é mais difícil de configurar e acessar de múltiplos locais do que acessos básicos à rede. +Se você quer enviar do seu notebook quando você estiver em casa , você tem que montar uma unidade remota, que pode pode ser mais difícil e lenta comparado ao acesso baseado em rede. -The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. -If you want to push from your laptop when you're at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. +É 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. -It's important to mention that this isn't necessarily the fastest option if you're using a shared mount of some kind. -A local repository is fast only if you have fast access to the data. -A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. +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. -Finally, this protocol does not protect the repository against accidental damage. -Every user has full shell access to the "remote" directory, and there is nothing preventing them from changing or removing internal Git files and corrupting the repository. +==== O Protocolo HTTP -==== The HTTP Protocols +Git pode se comunicar por HTTP em dois jeitos diferentes. -Git can communicate over HTTP in two different modes. -Prior to Git 1.6.6 there was only one way it could do this which was very simple and generally read-only. -In version 1.6.6 a new, smarter protocol was introduced that involved Git being able to intelligently negotiate data transfer in a manner similar to how it does over SSH. -In the last few years, this new HTTP protocol has become very popular since it's simpler for the user and smarter about how it communicates. -The newer version is often referred to as the ``Smart'' HTTP protocol and the older way as ``Dumb'' HTTP. -We'll cover the newer ``smart'' HTTP protocol first. +Antes do Git 1.6.6 havia apenas uma maneira de fazer isso, que era muito simples e geralmente somente leitura. +Na versão 1.6.6 foi introduzido um protocolo novo e mais inteligente, que tornava o Git capaz de inteligentemente negociar a transferência de dados de modo similar ao que faz por SSH. +Nos últimos anos, esse novo protocolo HTTP se tornou muito popular por ser mais simples para o usuário e mais inteligente na forma como se comunica. +A versão mais recente é gerealmente referida como protocolo HTTP "Smart" e a anterior como HTTP "Dumb". +Nós cobriremos o mais novo protocolo HTTP "Smart" primeiro. -===== Smart HTTP +===== HTTP Smart (((protocols, smart HTTP))) -The ``smart'' HTTP protocol operates very similarly to the SSH or Git protocols but runs over standard HTTP/S ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password authentication rather than having to set up SSH keys. -It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the `git://` protocol, and can also be pushed over with authentication and encryption like the SSH protocol. -Instead of having to set up different URLs for these things, you can now use a single URL for both. -If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password. -The same goes for read access. +O protocolo HTTP "Smart" funciona muito semelhantemente ao protocolo SSH ou Git, mas funciona no padrão das portas HTTP/S e pode usar vários mecanismos de autenticação HTTP, isso significa que geralmente é mais fácil para o usuário do que outros, como SSH, já que você pode usar coisas como usuário e senha para autenticação ao invés de ter que configurar chaves SSH. -In fact, for services like GitHub, the URL you use to view the repository online (for example, ``https://github.com/schacon/simplegit[]'') is the same URL you can use to clone and, if you have access, push over. +Ele se tornou provavelmente o jeito mais popular de usar o Git agora, já que pode ser configurado para servir aninomamente como protocolo `git://`, e também pode ser enviado com autenticação e criptografia como o protocolo SSH. +Ao invés de ter que configurar diferentes URLs para essas coisas, você pode usar uma única URL para ambos. +Se você tentar enviar e o repositório requerer autenticação (o que ele normalmente deveria fazer), o servidor pode pedir usuário e senha. +O mesmo vale para acessos de leitura. -===== Dumb HTTP +De fato, para serviços como GitHub, a URL que você vê o repositório online (por exemplo, "https://github.com/schacon/simplegit[]") é a mesma URL que você usa para clonar e, se você tiver acesso, enviar. + +===== HTTP Dumb (((protocols, dumb HTTP))) -If the server does not respond with a Git HTTP smart service, the Git client will try to fall back to the simpler ``dumb'' HTTP protocol. -The Dumb protocol expects the bare Git repository to be served like normal files from the web server. -The beauty of the Dumb HTTP protocol is the simplicity of setting it up. -Basically, all you have to do is put a bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you're done (See <>). -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: + +Se o servidor não responder com serviço Git HTTP Smart, o cliente Git vai tentar voltar para o protocolo mais simples, o HTTP "Dumb". O protocolo Dumb espera que o repositório vazio (bare repository) do Git sirva os arquivos como um servidor web normal. A beleza do protocolo HTTP Dumb é sua simplicidade de configuração. Basicamente, tudo que você tem que fazer é colocar o repositório vazio (bare repository) sob o documento raiz do seu HTTP e configurar um hook `post-update` específico, e você está pronto (Veja <>). Nesse ponto, qualquer um que possa acessar o servidor web no qual você colocou o repositório também pode cloná-lo. Para acessos de leitura para seu repositório por HTTP, faça algo como: [source,console] ---- @@ -103,103 +104,103 @@ $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update ---- -That's all.(((hooks, post-update))) -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 perhaps); then, other people can clone via something like +Isso é tudo.(((hooks, post-update))) +O hook `post-update` que vem com o Git por padrão executa o comando apropriado (`git update-server-info`) para fazer uma busca HTTP e clonagem do trabalho propriamente. +Esse comando executa quando você envia para esse repositório (por SSH talvez); então, outras pessoas podem cloná-lo com algo como [source,console] ---- $ git clone https://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 server – just put the bare repository in its path. -The Git data is served as basic static files (see <> for details about exactly how it's served). +Nesse caso em particular, nós estamos usando o caminho `/var/www/htdocs` que é comum para configurações Apache, mas você pode usar qualquer servidor web estático – apenas colocando o repositório vazio (bare repository) nesse caminho. +Os dados do Git são disponibilizados como simples arquivos estáticos (veja <> para mais detalhes sobre como exatamente eles são disponibilizados). + +Geralmente você escolheria executar um servidor HTTP Smart de leitura/gravação ou simplesmente ter os arquivos acessíveis como somente leitura da maneira burra. +É raro executar uma mistura dos dois serviços. -Generally you would either choose to run a read/write Smart HTTP server or simply have the files accessible as read-only in the Dumb manner. -It's rare to run a mix of the two services. +===== Os Prós -===== The Pros +Nós vamos nos concentrar nos prós da versão Smart do protocolo HTTP. -We'll concentrate on the pros of the Smart version of the HTTP protocol. +A simplicidade de ter uma única URL para todos os tipos de acesso e ter o prompt do servidor apenas quando a autenticação é necessária torna as coisas muito fáceis para o usuário final. +Ser capaz de se autenticar com usuário e senha é também grande vantagem sobre o SSH, já que usuários não precisam gerar uma chave SSH localmente e fazer upload de sua chave pública para o servidor antes de ser capaz de interagir com ele. Para usuários menos sofisticados, os usuários de sistemas onde SSH é menos comum, esta é a maior vantagem na usabilidade. +Ele também é um protocolo muito rápido e eficiente, parecido com o próprio SSH. -The simplicity of having a single URL for all types of access and having the server prompt only when authentication is needed makes things very easy for the end user. -Being able to authenticate with a username and password is also a big advantage over SSH, since users don't have to generate SSH keys locally and upload their public key to the server before being able to interact with it. -For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. -It is also a very fast and efficient protocol, similar to the SSH one. +Você também pode disponibilizar seus repositórios somente-leitura por HTTPS, que significa que você pode encriptar a transferência de conteúdo; ou você pode ir mais longe e fazer os clientes usarem certificados SSL assinados específicos. -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. +Outra coisa legal é que HTTP/S são protocolos tão comumente usado que firewalls corporativos costumam ser configurados para permitir o tráfego por essas portas. -Another nice thing is that HTTP/S are such commonly used protocols that corporate firewalls are often set up to allow traffic through these ports. -===== The Cons +===== Os Contras -Git over HTTP/S can be a little more tricky to set up compared to SSH on some servers. -Other than that, there is very little advantage that other protocols have over the ``Smart'' HTTP protocol for serving Git. +Por HTTP/S o Git pode ser um pouco complicado para configurar comparado com alguns servidores SSH. +Fora isso, há muitas pequenas vantagens que outros protocolos tem sobre o protocolo HTTP "Smart" para servir o Git. -If you're using HTTP for authenticated pushing, providing your credentials is sometimes more complicated than using keys over SSH. -There are however several credential caching tools you can use, including Keychain access on OSX and Credential Manager on Windows, to make this pretty painless. -Read <> to see how to set up secure HTTP password caching on your system. +Se você está usando HTTP para envios autenticados, inserir suas credenciais é algumas vezes mais complicado que usar chaves por SSH. +Há contudo várias ferramentas para armazenar credenciais que você pode usar, incluindo o acesso por Keychain no OSX e o Gerenciados de Credenciais no Windows, para fazer isso bastante indolor. +Leia <> para ver como configurar um gerenciador de credenciais no seu sistema. -==== The SSH Protocol +==== O Protocolo SSH (((protocols, SSH))) -A common transport protocol for Git when self-hosting is over SSH. -This is because SSH access to servers is already set up in most places – and if it isn't, it's easy to do. -SSH is also an authenticated network protocol; and because it's ubiquitous, it's generally easy to set up and use. -To clone a Git repository over SSH, you can specify ssh:// URL like this: +Um protocolo comum de transporte quando o Git está auto hospedado é o SSH. +Isso é porque o acesso SSH para servidores já é configurado na maioria dos lugares – e se não for, é fácil fazê-lo. +SSH também é um protocolo de rede autenticada; e por causa disso ele é onipresente, ele é geralmente mais fácil de configurar e usar. + +Para clonar um repositório Git por SSH você pode especificar a URL ssh:// assim: [source,console] ---- $ git clone ssh://user@server/project.git ---- -Or you can use the shorter scp-like syntax for the SSH protocol: +Ou para encurtar você pode usar a sintáxe scp para o protocolo SSH: [source,console] ---- $ git clone user@server:project.git ---- +Você também pode não especificar o usuário e o Git assumirá que o usuário é o atualmente logado. -You can also not specify a user, and Git assumes the user you're currently logged in as. - -===== The Pros +===== Os Prós -The pros of using SSH are many. -First, SSH is relatively easy to set up – SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. -Next, access over SSH is secure – all data transfer is encrypted and authenticated. -Last, like the HTTP/S, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. +São muitos os prós de usar SSH. +Primeiro, SSH é relativamente fácil de configurar – serviços SSH são comuns, muitos administradores de rede tem experiência com eles, e muitas distribuições de SO são configurados com eles ou tem ferramentas para gerenciá-los. +Depois, acessar por SSH é seguro – toda a transferência de dados é criptografada e autenticada. +Por último, como HTTP/S, Git e o protocolo Local, SSH é eficiente, compactando os dados o quanto possível antes de transferí-los. -===== The Cons +===== Os Contras -The negative aspect of SSH is that you can't serve anonymous access of your repository over it. -People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn't make SSH access conducive to open source projects. -If you're using it only within your corporate network, SSH may be the only protocol you need to deal with. -If you want to allow anonymous read-only access to your projects and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch over. +O aspecto negativo de SSH é que você não pode usar acesso anômino ao seu repositório por ele. +As pessoas precisam ter acesso à sua máquina por SSH para acessá-la, mesmo que seja em modo somente leitura, o que não torna o acesso SSH propício para projetos de código aberto. +Se você está usando ele somente na sua rede corporativa, o SSH pode ser o único protococolo que você precisa para ligar com isso. +Se você quer permitir acesso anonimo somente leitura para seus projetos e também quer usar SSH, você precisará configurar o SSH para você enviar, mas outra coisa para os outros buscarem. -==== The Git Protocol +==== O Protocolo Git (((protocols, git))) -Next is the Git protocol. -This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. -In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file – the daemon won't serve a repository without that file in it – but other than that there is no security. -Either the Git repository is available for everyone to clone or it isn't. -This means that there is generally no pushing over this protocol. -You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project's URL could push to your project. -Suffice it to say that this is rare. - -===== The Pros - -The Git protocol is often the fastest network transfer protocol available. -If you’re serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it’s likely that you'll want to set up a Git daemon to serve your project. -It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. - -===== The Cons - -The downside of the Git protocol is the lack of authentication. -It's generally undesirable for the Git protocol to be the only access to your project. -Generally, you'll pair it with SSH or HTTPS access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. -It's also probably the most difficult protocol to set up. -It must run its own daemon, which requires `xinetd` configuration or the like, which isn't always a walk in the park. -It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow. -Behind big corporate firewalls, this obscure port is commonly blocked. + +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á. +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. + +===== Os prós + +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 + +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. diff --git a/ch04-git-server.asc b/ch04-git-server.asc index a7d1313..1a7a276 100644 --- a/ch04-git-server.asc +++ b/ch04-git-server.asc @@ -1,24 +1,17 @@ [#ch04-git-server] -== Git on the Server +== Git no servidor (((serving repositories))) -At this point, you should be able to do most of the day-to-day tasks for which you'll be using Git. -However, in order to do any collaboration in Git, you'll need to have a remote Git repository. -Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they're working on if you're not careful. -Furthermore, you want your collaborators to be able to access the repository even if your computer is offline – having a more reliable common repository is often useful. -Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. +Nesse ponto, você deve ser capaz de fazer a maioria das suas tarefas diárias usando Git. Contudo, para fazer qualquer colaboração no Git, você precisará de um repositório remoto Git. Embora tecnicamente você possa enviar e baixar alterações de repositórios individuais, isso é desencorajado porque você provavelmente confundirá o que está sendo trabalhando em cada um deles se você não for cuidadoso. -Running a Git server is fairly straightforward. -First, you choose which protocols you want your server to communicate with. -The first section of this chapter will cover the available protocols and the pros and cons of each. -The next sections will explain some typical setups using those protocols and how to get your server running with them. -Last, we'll go over a few hosted options, if you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server. +Além disso, você quer que seus colaboradores sejam capazes de acessar seu repositório mesmo se seu computador estiver offline - geralmente é útil ter um repositório comum mais confiável. Portanto, o método preferido para colaborar com alguém é definir um repositório intermediário que vocês possam enviar e baixar dele. -If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. +Executar um servidor Git é bastante simples. +Primeiro, você escolhe quais protocolos de comunicação que você quer que seu servidor utilize. A primeira seção desse capítulo cobrirá os protocolos disponíveis e seus prós e contras. As próximas seções explicarão algumas configurações típicas usando estes protocolos e como fazer seu servidor executá-las. Por último, nós veremos algumas opções de hospedagem, caso você não se importe de hospedar seu código no servidor de outra pessoa e não quiser lidar com problemas configurando e mantendo seu próprio servidor. -A remote repository is generally a _bare repository_ – a Git repository that has no working directory. -Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it's just the Git data. -In the simplest terms, a bare repository is the contents of your project's `.git` directory and nothing else. +Se você não tem interesse em executar seu próprio servidor, você pode pular para a última seção deste capítulo para ver algumas opções para configurar uma conta hospedada e passar para o próximo capítulo, onde nós discutimos vários prós e contras de trabalhar em ambientes de controle de código distribuídos. + +Um repositório remoto geralmente é repositório vazio (_bare repository_) - um repositório Git que não tem um diretório de trabalho. Porque o repositório é usado apenas como ponto de colaboração, não há razão para ter uma cópia verificada em disco; são apenas dados do Git. Simplificando, o repositório vazio (bare repository) é o conteúdo do diretório `.git` do seu projeto e nada mais. include::book/04-git-server/sections/protocols.asc[] @@ -38,11 +31,9 @@ include::book/04-git-server/sections/gitlab.asc[] include::book/04-git-server/sections/hosted.asc[] -=== Summary - -You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. +=== Sumário +Você tem várias opções para ter um repositório remoto Git executando para que você possa colaborar com outras pessoas e compartilhar seu trabalho. -Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. -If you place your data on a hosted server, it's easy to set up and maintain; however, you have to be able to keep your code on someone else's servers, and some organizations don't allow that. +Executar seu próprio servidor te proporcional muito controle e permite que você execute seu servidor por seu próprio firewall, mas é esse tipo de servidor geralmente requer bastante de seu tempo para configuração e manutenção. Se você colocou seus dados em um servidor hospedado é fácil configurar e manter, contudo, você tem que manter seu código no servidor de terceiros, mas algumas organizações não permitem isso. -It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. +Isso deve ser o bastante para determinar qual solução ou combinação de soluções é apropriada para você e seus colaboradores. \ No newline at end of file diff --git a/status.json b/status.json index 50b652f..dd78bbc 100644 --- a/status.json +++ b/status.json @@ -33,14 +33,14 @@ "sections/workflows.asc": 0 }, "04-git-server": { - "1-git-server.asc": 0, + "1-git-server.asc": 100, "sections/generating-ssh-key.asc": 0, "sections/git-daemon.asc": 0, "sections/git-on-a-server.asc": 0, "sections/gitlab.asc": 0, "sections/gitweb.asc": 0, "sections/hosted.asc": 0, - "sections/protocols.asc": 0, + "sections/protocols.asc": 100, "sections/setting-up-server.asc": 0, "sections/smart-http.asc": 0 },