Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[pt-br] Chapter 2: 'Git Basics' translated #119

Closed
wants to merge 8 commits into from

5 participants

@fernandoalmeida

Translated 3 final sections.

@omailson

Despite a few grammar mistakes, this translation of chapter 2 seems better than the one sent by tarciosaraiva

@rogeriopradoj

Hello, @fernandoalmeida . I'd like to contribute with the translation of @progit into [pt-br].

However I'm seeing that a long long time has passed and your Pull Request is not accepted yet...

What is your opinion about this repo? The owners aren't so friendly to receive contributions?

@schacon, do I must follow some standard procedures to submit my translations?

@fernandoalmeida

I dont know why this pull request was not accepted yet, my other contributions were quickly accepted:
https://github.com/progit/progit/commits/master?author=fernandoalmeida

@schacon
Owner

I apologize - I've been working on a big rewrite of the git-scm.com site and I would like to incorporate Pro Git content into it, so I've been a bit preoccupied with that. I will merge this soon.

@rogeriopradoj

Don',t worry @schacon, I appreciate you answered.

Anyway, do you think it's possible yet to contribute for the pt-br translation, or it's better to wait a little?

@jnavila
Collaborator

This PR does not apply correctly on master. If it is still alive, please can you rebase and modify it.

@jnavila
Collaborator

Hi @fernandoalmeida This Pull Request does not apply cleanly. Can you rebase and check it?

@fernandoalmeida

Hi @jnavila, yes i will do that.

@jnavila
Collaborator

No life around this PR.

@jnavila jnavila closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 14, 2011
  1. @fernandoalmeida
  2. @fernandoalmeida
  3. @fernandoalmeida
  4. Pequeno erro reparado

    Lafaiet authored
Commits on Jul 15, 2011
  1. HTTP/S protocol done

    Lafaiet authored
Commits on Jul 19, 2011
  1. @fernandoalmeida
  2. @fernandoalmeida

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

    fernandoalmeida authored
    Conflicts:
    	pt-br/03-git-branching/01-chapter3.markdown
This page is out of date. Refresh to see the latest.
View
130 pt-br/02-git-basics/01-chapter2.markdown
@@ -521,7 +521,7 @@ Outra opção realmente útil é `--pretty`. Esta opção muda a saída do log p
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
-The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git:
+A opção mais interessante é `format`, que permite a você especificar seu próprio formato de saída. Isso é especialmente útil quando você está gerando saída para parsing - porque vocẽ especifica o formato explicitamente, você sabe que ele não vai mudar com as atualizações do Git:
$ git log --pretty=format:"%h - %an, %ar : %s"
ca82a6d - Scott Chacon, 11 months ago : changed the verison number
@@ -742,7 +742,7 @@ Isso significa que podemos puxar contribuições de qualquer um desses usuários
### Adicionando Repositórios Remotos ###
-Eu mencionei e deu algumas demonstrações de adição de repositórios remotos nas seções anteriores, mas aqui está como fazê-lo explicitamente. Para adicionar um novo repositório remto no Git com um nome curto para que você possa fazer referência facilmente, execute `git remote add [nomecurto] [url]`:
+Eu mencionei e deu algumas demonstrações de adição de repositórios remotos nas seções anteriores, mas aqui está como fazê-lo explicitamente. Para adicionar um novo repositório remoto no Git com um nome curto para que você possa fazer referência facilmente, execute `git remote add [nomecurto] [url]`:
$ git remote
origin
@@ -751,7 +751,7 @@ Eu mencionei e deu algumas demonstrações de adição de repositórios remotos
origin git://github.com/schacon/ticgit.git
pb git://github.com/paulboone/ticgit.git
-Agora você pode usar a string pb na linha de comando em lugar da URL completa. Por exemplo, se você quer fazer o fetch de todos os dados que Paul que você ainda não tem no seu repositório, você pode executar git fetch pb:
+Agora você pode usar a string pb na linha de comando em lugar da URL completa. Por exemplo, se você quer fazer o fetch de todos os dados que Paul tem e você ainda não tem no seu repositório, você pode executar git fetch pb:
$ git fetch pb
remote: Counting objects: 58, done.
@@ -776,17 +776,17 @@ Se você clonou um repositório, o comando automaticamente adiciona o remoto com
Se você tem um branch configurado para acompanhar um branch remoto (veja a próxima seção e o Capítulo 3 para mais informações), você pode usar o comando `git pull` para automaticamente fazer o fetch e o merge de um branch remoto no seu branch atual. Essa pode ser uma maneira mais fácil ou confortável pra você; e por padrão, o comando `git clone` automaticamente configura seu branch local master para acompanhar o branch remoto master do servidor de onde você clonou (desde que o remoto tenha um branch master). Executar `git pull` geralmente busca os dados do servidor de onde você fez o clone originalmente e automaticamente tenta fazer o merge dele no código que você está trabalhando atualmente.
-### Pushing to Your Remotes ###
+### Enviando Para Seus Remotos ###
-When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: `git push [remote-name] [branch-name]`. If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push your work back up to the server:
+Quando você tem seu projeto no ponto que vocẽ quer compartilhar, você tem que envia-lo para o upstream. O comando para isso é simples: `git push [nome-do-remoto] [nome-do-branch]`. Se você quer enviar seu branch master para seu servidor `origin` (denovo, clonagem geralmente define ambos estes nomes para você automaticamente), então você pode rodar isso para enviar seu trabalho de volta para o servidor:
$ git push origin master
-This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push. See Chapter 3 for more detailed information on how to push to remote servers.
+Este comando funciona somente se vocẽ clonou de um servidor que você tem permissão de escrita e se ninguém enviou nesse meio tempo. Se vocẽ e outro alguém clonam ao mesmo tempo e ele envia para o upstream e então você envia para o upstream, seu envio será certamente regeitado. Você terá que baixar os trabalhos dele primeiro e incorporá-lo aos seus antes de você ser permitido a enviar. Veja capítulo 3 para informação mais detalhada sobre como enviar para servidores remotos.
### Inspecting a Remote ###
-If you want to see more information about a particular remote, you can use the `git remote show [remote-name]` command. If you run this command with a particular shortname, such as `origin`, you get something like this:
+Se você quer ver mais informações sobre um remoto em particular, você pode usar o comando `git remote show [nome-do-remoto]`. Se você executar este comando com um nome em particular, como `origin`, você terá algo como isso:
$ git remote show origin
* remote origin
@@ -797,9 +797,9 @@ If you want to see more information about a particular remote, you can use the `
master
ticgit
-It lists the URL for the remote repository as well as the tracking branch information. The command helpfully tells you that if you’re on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. It also lists all the remote references it has pulled down.
+Ele lista a URL para o repositório remoto assim como informações sobre seus branches. O comando fala a você que se vocẽ está no branch master e vocẽ executar `git pull`, ele automaticamente mesclará o branch master do remoto depois que ele buscar todas as referênciar. Ele ainda lista todas as referências do remoto que ele baixou.
-That is a simple example you’re likely to encounter. When you’re using Git more heavily, however, you may see much more information from `git remote show`:
+Aqui está um exemplo simples do que você pode encontrar. Quando vocẽ estiver usando Git mais a fundo, contudo, você poderá ver muito mais informações com `git remote show`
$ git remote show origin
* remote origin
@@ -823,20 +823,20 @@ That is a simple example you’re likely to encounter. When you’re using Git m
Local branch pushed with 'git push'
master:master
-This command shows which branch is automatically pushed when you run `git push` on certain branches. It also shows you which remote branches on the server you don’t yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`.
+Este comando mostra qual branch será automaticamente enviado quando você executar `git push` em certos branches. Ele ainda mostra a você quais branches remotos do servidor você ainda não tem, quais branches remotos você tem que foram removidos do servidor, e múltiplos branches que vocẽ automaticamente mesclou quando executou `git pull`.
-### Removing and Renaming Remotes ###
+### Removendo e Renomeando Remotos ###
-If you want to rename a reference, in newer versions of Git you can run `git remote rename` to change a remote’s shortname. For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`:
+Se você quer renomear uma referência, na mais nova versão do Git você pode executar `git remote rename` para mudar o nome do remoto. Por exemplo, se você quer renomear `pb` para `paul`, vocẽ pode faze-lo com `git remote rename`:
$ git remote rename pb paul
$ git remote
origin
paul
-It’s worth mentioning that this changes your remote branch names, too. What used to be referenced at `pb/master` is now at `paul/master`.
+Isto merece ser mencionado que estas muda os nomes dos seus branches remotos, também. O que era referenciado em `pb/master` agora é em `paul/master`
-If you want to remove a reference for some reason — you’ve moved the server or are no longer using a particular mirror, or perhaps a contributor isn’t contributing anymore — you can use `git remote rm`:
+Se você quer remover uma referência por alguma razão — você moveu o servidor ou não está mais usando um espelho em particular, ou aconteceu de um contribuidor não estar mais contribuindo — você pode usar `git remote rm`:
$ git remote rm paul
$ git remote
@@ -844,19 +844,19 @@ If you want to remove a reference for some reason — you’ve moved the server
## Tagging ##
-Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). In this section, you’ll learn how to list the available tags, how to create new tags, and what the different types of tags are.
+Como muitos SCVs, Git tem a abilidade de usar tag em pontos específicos no histórico como sendo importante. Geralmente, pessoas usam esta funcionalidade para marcar pontos de versões (v1.0, e assim sucessivamente). Nesta sessão, você aprenderá como listar as tags disponíveis, como criar novas tags, e o que os diferentes tipos de tags são.
-### Listing Your Tags ###
+### Listando Suas Tags ###
-Listing the available tags in Git is straightforward. Just type `git tag`:
+Listar as tags disponíveis no Git é natural. Simplesmente digite `git tag`:
$ git tag
v0.1
v1.3
-This command lists the tags in alphabetical order; the order in which they appear has no real importance.
+Este comando lista as tags em ordem alfabética; a ordem na qual elas aparecem não tem importância real.
-You can also search for tags with a particular pattern. The Git source repo, for instance, contains more than 240 tags. If you’re only interested in looking at the 1.4.2 series, you can run this:
+Você pode ainda buscar por tags com o padrão particular. O repositório dos fontes do Git, por exemplo, contém mais de 240 tags. Se vocẽ está interessado somente em ver as da séria 1.4.2, vocẽ pode executar isso:
$ git tag -l v1.4.2.*
v1.4.2.1
@@ -864,13 +864,13 @@ You can also search for tags with a particular pattern. The Git source repo, for
v1.4.2.3
v1.4.2.4
-### Creating Tags ###
+### Criando Tags ###
-Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It’s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information, lightweight tags are available too.
+Git usa dois tipos de tags: leves e anotadas. Uma tag leve é muito mais como um branch que não muda — é simplesmente um apontador para um commit específico. Tags anotadas, contudo, são armazenadas como objetos completos no banco de dados do Git. Possuem checksum; contém o nome do criador da tag, email e data; tem uma mensagem de tag; e pode ser assinada e verificada com GNU Privacy Guard (GPG). Geralmente é recomendado que você crie tags anotadas para que vocẽ possa ter todas essas informações; mas se você quer uma tag temporária ou por alguma razão não quer manter as outras informações, tags leves também estão disponíveis.
-### Annotated Tags ###
+### Tags Anotadas ###
-Creating an annotated tag in Git is simple. The easiest way is to specify `-a` when you run the `tag` command:
+Criando uma tag anotada no Git é simples. O caminho mais fácil é especificar `-a` quando vocẽ executar o comando `tag`:
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
@@ -878,9 +878,9 @@ Creating an annotated tag in Git is simple. The easiest way is to specify `-a` w
v1.3
v1.4
-The `-m` specifies a tagging message, which is stored with the tag. If you don’t specify a message for an annotated tag, Git launches your editor so you can type it in.
+O `-m` especifica a mensagem de tag, que é armazenada com a tag. Se vocẽ não especificar uma mensagem para uma tag anotada, Git lança seu editor para que você possa digitá-la.
-You can see the tag data along with the commit that was tagged by using the `git show` command:
+Você pode ver os dados da tag com o commit que foi criada a tag usando o comando `git show`:
$ git show v1.4
tag v1.4
@@ -895,18 +895,20 @@ You can see the tag data along with the commit that was tagged by using the `git
Merge branch 'experiment'
-That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information.
+Isso mostra as informações do criador da tag, a data que
-### Signed Tags ###
+That shows the tagger information, a data do commit que foi criada a tag, e a mensagem de anotação antes de mostrar informações do commit.
-You can also sign your tags with GPG, assuming you have a private key. All you have to do is use `-s` instead of `-a`:
+### Tags Assinadas ###
+
+Você pode ainda assinar suas tags com GPG, assumindo que você tem uma chave privada. Tudo que você tem que fazer é usar `-s` em vez de `-a`:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gee-mail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
-If you run `git show` on that tag, you can see your GPG signature attached to it:
+Se você executar `git show` nesta tag, vocẽ pode ver sua assinatura GPG anexada a ela:
$ git show v1.5
tag v1.5
@@ -928,11 +930,11 @@ If you run `git show` on that tag, you can see your GPG signature attached to it
Merge branch 'experiment'
-A bit later, you’ll learn how to verify signed tags.
+Um bit depois, você aprenderá como verificar tags assinadas.
-### Lightweight Tags ###
+### Tags Leves ###
-Another way to tag commits is with a lightweight tag. This is basically the commit checksum stored in a file — no other information is kept. To create a lightweight tag, don’t supply the `-a`, `-s`, or `-m` option:
+Outro caminho para usar tags em commits é com tag leve. Este é basicamente o checksum do commit em um arquivo — nenhuma outra informação é mantida. Para criar uma tag leve, não informe a opção `-a`, `-s`, ou `-m`:
$ git tag v1.4-lw
$ git tag
@@ -942,7 +944,7 @@ Another way to tag commits is with a lightweight tag. This is basically the comm
v1.4-lw
v1.5
-This time, if you run `git show` on the tag, you don’t see the extra tag information. The command just shows the commit:
+Nesta hora, se você executar `git show` na tag, você não verá as informações extra da tag. O comando simplesmente mostra o commit:
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
@@ -952,9 +954,9 @@ This time, if you run `git show` on the tag, you don’t see the extra tag infor
Merge branch 'experiment'
-### Verifying Tags ###
+### Verificando Tags ###
-To verify a signed tag, you use `git tag -v [tag-name]`. This command uses GPG to verify the signature. You need the signer’s public key in your keyring for this to work properly:
+Para verificar uma tag assinada, você usa `git tag -v [nome-da-tag]`. Este comando usa GPG para verificar a assinatura. Você precisa da chave pública do assinante para isso funcionar adequadamente:
$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
@@ -970,15 +972,15 @@ To verify a signed tag, you use `git tag -v [tag-name]`. This command uses GPG t
gpg: aka "[jpeg image of size 1513]"
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
-If you don’t have the signer’s public key, you get something like this instead:
+Se você não tem a chave pública do assinante, você terá algo como isso:
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.4.2.1'
-### Tagging Later ###
+### Criando Tags Depos ###
-You can also tag commits after you’ve moved past them. Suppose your commit history looks like this:
+Você pode ainda criar tags em commits depois de vocẽ ter passado por eles. Suponha que seu histórico de commits é como este:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
@@ -992,11 +994,11 @@ You can also tag commits after you’ve moved past them. Suppose your commit his
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
-Now, suppose you forgot to tag the project at v1.2, which was at the "updated rakefile" commit. You can add it after the fact. To tag that commit, you specify the commit checksum (or part of it) at the end of the command:
+Agora, suponha que você esqueceu de criar a tag em v1.2 no projeto, que foi no commit "updated rakefile". Você pode adicioná-la depois do fato. Para criar a tag para aquele commit, vocẽ especifica o checksum do commit (ou parte dele) no fim do comando
$ git tag -a v1.2 9fceb02
-You can see that you’ve tagged the commit:
+Você pode ver que foi criada a tag para o commit:
$ git tag
v0.1
@@ -1019,9 +1021,9 @@ You can see that you’ve tagged the commit:
updated rakefile
...
-### Sharing Tags ###
+### Compartilhando Tags ###
-By default, the `git push` command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches – you can run `git push origin [tagname]`.
+Por padrão, o comando `git push` não transfere tags para servidores remotos. Você terá que explicitamente enviar as tags para o servidor compartilhado depois que vocẽ as criou. Este processo é simplesmente como compartilhar branches – você pode executar `git push origin [nome-da-tag]`.
$ git push origin v1.5
Counting objects: 50, done.
@@ -1031,7 +1033,7 @@ By default, the `git push` command doesn’t transfer tags to remote servers. Yo
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
-If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. This will transfer all of your tags to the remote server that are not already there.
+Se você tem muitas tags que você quer enviar de uma vez, você pode ainda usar a opção `--tags` no comando `git push`. Isso irá transferir todas as tags para seu servidor remoto que ainda não estão lá.
$ git push origin --tags
Counting objects: 50, done.
@@ -1045,61 +1047,61 @@ If you have a lot of tags that you want to push up at once, you can also use the
* [new tag] v1.4-lw -> v1.4-lw
* [new tag] v1.5 -> v1.5
-Now, when someone else clones or pulls from your repository, they will get all your tags as well.
+Agora, quando outro alguém colnar ou baixar do seu repositório, ele pegará todas as suas tags também.
-## Tips and Tricks ##
+## Dicas e Truques ##
-Before we finish this chapter on basic Git, a few little tips and tricks may make your Git experience a bit simpler, easier, or more familiar. Many people use Git without using any of these tips, and we won’t refer to them or assume you’ve used them later in the book; but you should probably know how to do them.
+Antes de nós finalizarmos este capítulo de Git básico, algumas pequenas dicas e truques podem fazer sua experiência com Git um bit mais simples, mais fácil, ou mais familiar. Muitas pessoas usam Git sem usar qualquer dessas dicas, e nós não vamos nos referir a elas ou assumir que você as usa depois no livro; mas você provavelmente deve saber como usa-las.
-### Auto-Completion ###
+### Auto-Complettar ###
-If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download the Git source code, and look in the `contrib/completion` directory; there should be a file called `git-completion.bash`. Copy this file to your home directory, and add this to your `.bashrc` file:
+Se você usa o shell Bash, Git vem com um lindo script de auto-completar habilitado para você. Baixe os fontes do Git, e olhe no diretório `contrib/completion`; deve ter um arquivo chamado `git-completion.bash`. Copie este arquivo no seu diretório home, e adicione-o ao seu arquivo `.bashrc`
source ~/.git-completion.bash
-If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the `/opt/local/etc/bash_completion.d` directory on Mac systems or to the `/etc/bash_completion.d/` directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.
+Se você quer definir que Git tenha automaticamente auto-completar para todos os usuários, copie este script para o diretório `/opt/local/etc/bash_completion.d` em sistemas Mac ou para o diretório `/etc/bash_completion.d/` em sistemas Linux. Este é o diretório de scripts que o Bash automaticamente carrega para prover este recurso.
-If you’re using Windows with Git Bash, which is the default when installing Git on Windows with msysGit, auto-completion should be preconfigured.
+Se você está usando Windows com Git Bash, que é a instalação padrão do Git no Windows com msysGit, o auto-completar deve estar pré-configurado.
-Press the Tab key when you’re writing a Git command, and it should return a set of suggestions for you to pick from:
+Pressione a tecla Tab quando você estiver escrevendo comando Git, e ele deve retornar uma série de sugestões para você escolher:
$ git co<tab><tab>
commit config
-In this case, typing git co and then pressing the Tab key twice suggests commit and config. Adding `m<tab>` completes `git commit` automatically.
+Neste caso, digitando git co e então pressionando a tecla Tab duas vezes ele sugere commit e config. Adicionando `m<tab>` completa `git commit` automaticamente.
-This also works with options, which is probably more useful. For instance, if you’re running a `git log` command and can’t remember one of the options, you can start typing it and press Tab to see what matches:
+Isso ainda funciona com opções, que é provavelmente mais útil. Por exemplo, se você está executando um comando `git log` e não lembra uma das opções, você pode comecar digitando-a e pressionar a tecla Tab para ver o que casa:
$ git log --s<tab>
--shortstat --since= --src-prefix= --stat --summary
-That’s a pretty nice trick and may save you some time and documentation reading.
+É um truque muito bom e pode te economizar algum tempo e leitura de documentação.
-### Git Aliases ###
+### Apelidos Git ###
-Git doesn’t infer your command if you type it in partially. If you don’t want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`. Here are a couple of examples you may want to set up:
+Git não infere seus comandos se você digitá-lo parcialmente. Se vocẽ não quer digitat o texto inteiro de cada um dos comandos do Git, você pode facilmente definir um apelido para cada comando usando `git config`. Aqui está alguns dos exemplos que você pode querer definir:
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
-This means that, for example, instead of typing `git commit`, you just need to type `git ci`. As you go on using Git, you’ll probably use other commands frequently as well; in this case, don’t hesitate to create new aliases.
+Isso significa que, por exemplo, em vez de digitar `git commit`, você simplesmente precisa digitar `git ci`. Quando vocẽ esiver usando Git, vocẽ provavelmente usará outros comandos frequentemente também; neste caso, não hexite em criar novos apelidos.
-This technique can also be very useful in creating commands that you think should exist. For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git:
+Esta técnica pode ainda ser útil na criação de comandos que você acha que deve existir. Por exemplo, para corrigit um problema de usabilidade que você encontrou com o comando para tirar um arquivo do stage, você pode adicionar seu próprio apelido ao comando do Git:
$ git config --global alias.unstage 'reset HEAD --'
-This makes the following two commands equivalent:
+Isso torna os dois comandos seguintes equivalentes:
$ git unstage fileA
$ git reset HEAD fileA
-This seems a bit clearer. It’s also common to add a `last` command, like this:
+Isso parece um bit mais claro. É ainda comum, adicionar um comando last, como este:
$ git config --global alias.last 'log -1 HEAD'
-This way, you can see the last commit easily:
+Com isso, você pode ver os último commit facilmente.
$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
@@ -1110,10 +1112,10 @@ This way, you can see the last commit easily:
Signed-off-by: Scott Chacon <schacon@example.com>
-As you can tell, Git simply replaces the new command with whatever you alias it for. However, maybe you want to run an external command, rather than a Git subcommand. In that case, you start the command with a `!` character. This is useful if you write your own tools that work with a Git repository. We can demonstrate by aliasing `git visual` to run `gitk`:
+Como você pode dizer, Git simplesmente substitui o novo comando com o apelido que você der para ele. No entanto, talvez você queira executar um comando externo, em vez de um subcomando do Git. Nesse caso, você inicia o comando com um caracter `!`. Isso é útil se você escrever suas próprias ferramentas que trabalham com um repositório Git. Podemos demonstrar, através do apelido `git visual` para executar `gitk`:
$ git config --global alias.visual "!gitk"
-## Summary ##
+## Resumo ##
-At this point, you can do all the basic local Git operations — creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. Next, we’ll cover Git’s killer feature: its branching model.
+Neste ponto, você pode fazer todas as operações básicas do Git local - criar ou clonar um repositório, fazer alterações, staging e commit dessas mudanças, e visualizar o histórico de todas as mudanças que o repositório tem recebido. A seguir, vamos cobrir um excelente recurso do Git: seu modelo de ramificação (branches).
View
58 pt-br/03-git-branching/01-chapter3.markdown
@@ -8,7 +8,7 @@ Algumas pessoas se referem ao modelo de ramificação em Git como sua caracterí
Para compreender realmente a forma como o Git cria branches, precisamos dar um passo atrás e examinar como o Git armazena seus dados. Como você pode se lembrar do capítulo 1, o Git não armazena dados como uma série de mudanças ou deltas, mas sim como uma série de snapshots.
-Quando você faz um commit no Git, o Git guarda um objeto commit que contém um ponteiro para o snapshot do conteúdo que você colocou na área de seleção, o autor e os metadados da mensagen, zero ou mais ponteiros para o commit ou commits que são pais deste commit: nenhum pai para o commit inicial, um pai para um commit normal e múltiplos pais para commits que resultem de um merge de dois ou mais branches.
+Quando você faz um commit no Git, o Git guarda um objeto commit que contém um ponteiro para o snapshot do conteúdo que você colocou na área de seleção, o autor e os metadados da mensagem, zero ou mais ponteiros para o commit ou commits que são pais deste commit: nenhum pai para o commit inicial, um pai para um commit normal e múltiplos pais para commits que resultem de um merge de dois ou mais branches.
Para visualizar isso, vamos supor que você tenha um diretório contendo três arquivos, e colocou todos eles na área de seleção e fez o commit. Colocar na área de seleção cria o checksum de cada arquivo (o hash SHA-1 que nos referimos no capítulo 1), armazena esta versão do arquivo no repositório Git (o Git se refere a eles como blobs), e acrescenta este checksum à área de seleção (staging area):
@@ -144,7 +144,7 @@ No entanto, antes de fazer isso, note que seu diretório de trabalho ou área de
$ git checkout master
Switched to branch "master"
-Nesse ponto, o diretório do seu projeto está exatamente do jeito que estava antes de você começar a trabalhar na tarefa #53, e você se concentra na correção do erro. É importante lembrar desse ponto: Git restabelece seu diretório de trabalho para ficar igual ao snapshot do commit que o branch que você criou aponta. Ele adiciona, remove, e modifica arquivos automaticamente para garantir que sua cópia é o que o branch parecia no seu último commit nele.
+Nesse ponto, o diretório do seu projeto está exatamente do jeito que estava antes de você começar a trabalhar na tarefa #53, e você se concentra na correção do erro. É importante lembrar desse ponto: Git reestabelece seu diretório de trabalho para ficar igual ao snapshot do commit que o branch que você criou aponta. Ele adiciona, remove, e modifica arquivos automaticamente para garantir que sua cópia é o que o branch parecia no seu último commit nele.
Em seguida, você tem uma correção para fazer. Vamos criar um branch para a correção (hotfix) para trabalhar até a conclusão (veja Figura 3-13):
@@ -167,7 +167,7 @@ Você pode rodar seus testes, tenha certeza que a correção é o que você quer
README | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
-Você irá notar a frase "Fast forward" no merge. Em razão do branch que você fez o merge apontar para o commit que está diretamente acima do commit que você se encontra, Git avança o ponteiro adiante. Em outras palavras, quando você tenta fazer o merge de um commit com outro que pode ser alcançado seguindo o histórico do primeiro, Git simplifica as coisas movendo o ponteiro adiante porque não existe modificações divergente para fazer o merge because — isso é chamado de "fast forward".
+Você irá notar a frase "Fast forward" no merge. Em razão do branch que você fez o merge apontar para o commit que está diretamente acima do commit que você se encontra, Git avança o ponteiro adiante. Em outras palavras, quando você tenta fazer o merge de um commit com outro que pode ser alcançado seguindo o histórico do primeiro, Git simplifica as coisas movendo o ponteiro adiante porque não existe modificações divergente para fazer o merge — isso é chamado de "fast forward".
Sua modificação está agora na snapshot do commit apontado pelo branch `master`, e você pode fazer o deploy (veja Figura 3-14).
@@ -179,7 +179,7 @@ Depois que a sua super importante correção foi enviada, você está pronto par
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
-Agora você pode voltar para o trabalho incompleto no branch da tafera #53 e continuar a trabalhar nele (veja Figura 3-15):
+Agora você pode voltar para o trabalho incompleto no branch da tarefa #53 e continuar a trabalhar nele (veja Figura 3-15):
$ git checkout iss53
Switched to branch "iss53"
@@ -341,9 +341,9 @@ Agora que você sabe o básico sobre criação e merge de branches, o que você
### Branches de longa duração ###
-Por o Git usar um merge de três vias, fazer o merge de um branch em outro várias vezes em um período longo é geralmente fácil de fazer. Isto significa que você pode ter vários branches que ficam sempre abertos e que são usados em diferentes estágios do seu ciclo de desenvolvimento; você pode regularmente fazer o merge de alguns deles em outros.
+Por o Git usar um merge de três vias, fazer o merge de um branch em outro várias vezes em um período longo é geralmente fácil. Isto significa que você pode ter vários branches que ficam sempre abertos e que são usados em diferentes estágios do seu ciclo de desenvolvimento; você pode regularmente fazer o merge de alguns deles em outros.
-Muitos desenvolvedores Git tem um fluxo de trabalho que adotam essa abordagem, como ter somente código completamente estável em seus branches `master` — possivelmente somente código que já foi ou será liberado. Eles têm outro branch paralelo chamado develop ou algo parecido em que eles trabalham ou usam para testar estabilidade — ele não é necessariamente sempre estável, mas quando ele chega a tal estágio, pode ser feito o merge com o branch `master`. Ele é usado para puxar (pull) branches tópicos (topic, branches de curta duração, como o seu branch `iss53` anteriormente) quando eles estão prontos, para ter certeza que eles passam em todos os testes e não acresentam erros.
+Muitos desenvolvedores Git tem um fluxo de trabalho que adotam essa abordagem, como ter somente código completamente estável em seus branches `master` — possivelmente somente código que já foi ou será liberado. Eles têm outro branch paralelo chamado develop ou algo parecido em que eles trabalham ou usam para testar estabilidade — ele não é necessariamente sempre estável, mas quando ele chega a tal estágio, pode ser feito o merge com o branch `master`. Ele é usado para puxar (pull) branches tópicos (topic branches, de curta duração, como o seu branch `iss53` anteriormente) quando eles estão prontos, para ter certeza que eles passam em todos os testes e não acrescentam erros.
Na realidade, nós estamos falando de ponteiros avançando na linha de commits que você está fazendo. Os branches estáveis estão muito atrás na linha histórica de commits, e os branches de ponta (que estão sendo trabalhados) estão a frente no histórico (veja Figura 3-18).
@@ -355,19 +355,19 @@ Normalmente é mais fácil pensar neles como um contêiner de trabalho, onde con
Insert 18333fig0319.png
Figura 3-19. Pode ser mais útil pensar em seus branches como contêineres.
-Você pode continuar fazendo isso em vários níveis de estabilidade. Alguns projetos grandes podem ter um branch 'sugerido' (`proposed`) ou 'sugestões atualizadas' (`pu`, proposed updates) que contém outros branches integrados que podem não estar prontos para ir para o próximo (`next`) ou branch `master`. A ideia é que seus branches estejam em vários níveis de estabilidade; quando eles atigem um nível mais estável, é feito o merge no branch acima deles.
+Você pode continuar fazendo isso em vários níveis de estabilidade. Alguns projetos grandes podem ter um branch 'sugerido' (`proposed`) ou 'sugestões atualizadas' (`pu`, proposed updates) que contém outros branches integrados que podem não estar prontos para ir para o próximo (`next`) ou branch `master`. A ideia é que seus branches estejam em vários níveis de estabilidade; quando eles atingem um nível mais estável, é feito o merge no branch acima deles.
Repetindo, ter muitos branches de longa duração não é necessário, mas geralmente é útil, especialmente quando você está lidando com projetos muito grandes ou complexos.
-### Branches tópicos (topic) ###
+### Branches tópicos (topic branches) ###
Branches tópicos, entretanto, são úteis em projetos de qualquer tamanho. Um branch tópico é um branch de curta duração que você cria e usa para uma funcionalidade ou trabalho relacionado. Isso é algo que você provavelmente nunca fez com um controle de versão antes porque é geralmente muito custoso criar e fazer merge de branches. Mas no Git é comum criar, trabalhar, mesclar e apagar branches muitas vezes ao dia.
-Você viu isso na seção anterior com os branches `iss53` e o `hotfix` que você criou. Você fez commits neles e os apagou depois que fez o merge com seu branch principal. Tecnicamente isso lhe permite mudar completamente e rapidamente o contexto — por seu trabalho estar separado em contêineres onde todas as modificações naquele branch estarem relacionadas ao tópico, é fácil ver o que aconteceu durante a revisão de código. Você pode manter as mudanças la por minutos, dias, ou meses, e mesclá-las quando estivem prontas, não importando a ordem que foram criadas ou trabalhadas.
+Você viu isso na seção anterior com os branches `iss53` e o `hotfix` que você criou. Você fez commits neles e os apagou depois que fez o merge com seu branch principal. Tecnicamente isso lhe permite mudar completamente e rapidamente o contexto — por seu trabalho estar separado em contêineres onde todas as modificações naquele branch estarem relacionadas ao tópico, é fácil ver o que aconteceu durante a revisão de código. Você pode manter as mudanças la por minutos, dias, ou meses, e mesclá-las quando estiverem prontas, não importando a ordem que foram criadas ou trabalhadas.
-Condisere um exemplo onde você está fazendo um trabalho (no `master`), cria um branch para um erro (`iss91`), trabalha nele um pouco, cria um segundo branch para testar uma nova maneira de resolver o mesmo problema (`iss91v2`), volta ao seu branch principal e trabalha nele por um tempo, e cria um novo branch para trabalhar em algo que você não tem certeza se é uma boa ideia (`dumbidea`). Seu histórico de commits irá se parecer com a Figura 3-20.
+Considere um exemplo onde você está fazendo um trabalho (no `master`), cria um branch para um erro (`iss91`), trabalha nele um pouco, cria um segundo branch para testar uma nova maneira de resolver o mesmo problema (`iss91v2`), volta ao seu branch principal e trabalha nele por um tempo, e cria um novo branch para trabalhar em algo que você não tem certeza se é uma boa ideia (`dumbidea`). Seu histórico de commits irá se parecer com a Figura 3-20.
Insert 18333fig0320.png
-Figura 3-20. Seu histórico de commits com multiplos branches tópicos.
+Figura 3-20. Seu histórico de commits com múltiplos branches tópicos.
Agora, vamos dizer que você decidiu que sua segunda solução é a melhor para resolver o erro (`iss91v2`); e você mostrou seu branch `dumbidea` para seus colegas de trabalho, e ele é genial. Agora você pode jogar fora o branch original `iss91` (perdendo os commits C5 e C6) e fazer o merge dos dois restantes. Seu histórico irá se parecer com a Figura 3-21.
@@ -397,19 +397,19 @@ Para sincronizar suas coisas, você executa o comando `git fetch origin`. Esse c
Insert 18333fig0324.png
Figura 3-24. O comando git fetch atualiza suas referências remotas.
-Para demostrar o uso de multiplos servidores remotos e como os branches remotos desses projetos remotos parecem, vamos assumir que você tem outro servidor Git interno que é usado somente para desenvolvimento por um de seus times. Este servidor está em `git.team1.ourcompany.com`. Você pode adicioná-lo como uma nova referência remota ao projeto que você está atualmente trabalhando executando o comando `git remote add` como discutimos no capítulo 2. Dê o nome de `teamone`, que será o apelido para aquela URL (veja Figura 3-25).
+Para demostrar o uso de múltiplos servidores remotos e como os branches remotos desses projetos remotos parecem, vamos assumir que você tem outro servidor Git interno que é usado somente para desenvolvimento por um de seus times. Este servidor está em `git.team1.ourcompany.com`. Você pode adicioná-lo como uma nova referência remota ao projeto que você está atualmente trabalhando executando o comando `git remote add` como discutimos no capítulo 2. Dê o nome de `teamone`, que será o apelido para aquela URL (veja Figura 3-25).
Insert 18333fig0325.png
Figura 3-25. Adicionando outro servidor remoto.
-Agora, você pode executar o comando `git fetch teamone` para obter tudo que o servidor tem e você ainda não. Por esse servidor ter um subcojunto dos dados que seu servidor `origin` tem, Git não obtém nenhum dados, somente cria um branch chamado `teamone/master` que faz referência ao commit que `teamone` tem no `master` dele (veja Figura 3-26).
+Agora, você pode executar o comando `git fetch teamone` para obter tudo que o servidor tem e você ainda não. Por esse servidor ter um subconjunto dos dados que seu servidor `origin` tem, Git não obtém quaisquer dados, somente cria um branch chamado `teamone/master` que faz referência ao commit que `teamone` tem no `master` dele (veja Figura 3-26).
Insert 18333fig0326.png
Figura 3-26. Você consegue uma referência local para a posição do branch master do teamone.
### Enviando (Pushing) ###
-Quando você quer compatilhar um branch com o mundo, você precisa enviá-lo a um servidor remoto que você tem acesso. Seus branches locais não são automaticamente sincronizados com os remotos - você tem que explicitamente enviar (push) os branches que quer compartilhar. Desta maneira, você pode usar branches privados para o trabalho que não quer compartilhar, e enviar somente os branches tópicos que quer colaboração.
+Quando você quer compartilhar um branch com o mundo, você precisa enviá-lo a um servidor remoto que você tem acesso. Seus branches locais não são automaticamente sincronizados com os remotos - você tem que explicitamente enviar (push) os branches que quer compartilhar. Desta maneira, você pode usar branches privados para o trabalho que não quer compartilhar, e enviar somente os branches tópicos que quer colaboração.
Se você tem um branch chamado `serverfix` e quer trabalhar com outros, você pode enviá-lo da mesma forma que enviou seu primeiro branch. Execute o comando `git push (remote) (branch)`:
@@ -423,7 +423,7 @@ Se você tem um branch chamado `serverfix` e quer trabalhar com outros, você po
Isso é um atalho. O Git automaticamente expande o branch `serverfix` para `refs/heads/serverfix:refs/heads/serverfix`, que quer dizer, "pegue meu branch local serverfix e envie para atualizar o branch serverfix no servidor remoto". Nós vamos ver a parte de `refs/heads/` em detalhes no capítulo 9, mas em geral você pode deixar assim. Você pode executar também `git push origin serverfix:serverfix`, que faz a mesma coisa - é como, "pegue meu serverfix e o transforme no serverfix remoto". Você pode usar esse formato para enviar (push) um branch local para branch remoto que tem nome diferente. Se você não quer chamá-lo de serverfix no remoto, você pode executar `git push origin serverfix:awesomebranch` para enviar seu branch local `serverfix` para o branch `awesomebranch` no projeto remoto.
-Na próxima vez que um dos seus colaboradores obter dados do servidor, eles irão ter uma referência para onde a versão do servidor de serverfix está no branch remoto `origin/serverfix`:
+Na próxima vez que um dos seus colaboradores obtiver dados do servidor, eles irão ter uma referência para onde a versão do servidor de serverfix está no branch remoto `origin/serverfix`:
$ git fetch origin
remote: Counting objects: 20, done.
@@ -433,7 +433,7 @@ Na próxima vez que um dos seus colaboradores obter dados do servidor, eles irã
From git@github.com:schacon/simplegit
* [new branch] serverfix -> origin/serverfix
-É importante notar que quando você obtém dados que traz novos branches remotos, você não tem automaticamente copias locais e editáveis. Em outras palavras, nesse caso, você não tem um novo branch `serverfix` — você tem somente uma referência a `origin/serverfix` que você não pode modificar.
+É importante notar que quando você obtém dados que trazem novos branches remotos, você não tem automaticamente copias locais e editáveis. Em outras palavras, nesse caso, você não tem um novo branch `serverfix` — você tem somente uma referência a `origin/serverfix` que você não pode modificar.
Para fazer o merge desses dados no branch que você está trabalhando, você pode executar o comando `git merge origin/serverfix`. Se você quer seu próprio branch `serverfix` para trabalhar, você pode se basear no seu branch remoto:
@@ -514,12 +514,12 @@ Note que o snapshot apontado pelo o commit final, o último commit dos que viera
### Rebases mais interessantes ###
-Você também pode fazer o rebase em um local diferente do branch de rebase. Veja o histórico na Figura 3-31, por exemplo. Você criou um branch tópico (`server`) no seu projeto para adicionar uma funcionalidade no lador do servidor e fez o commit. Então, você criou outro branch para fazer mudanças no lado do cliente (`client`) e fez alguns commits. Finalmente, você voltou ao ser branch server e fez mais alguns commits.
+Você também pode fazer o rebase em um local diferente do branch de rebase. Veja o histórico na Figura 3-31, por exemplo. Você criou um branch tópico (`server`) no seu projeto para adicionar uma funcionalidade no lado do servidor e fez o commit. Então, você criou outro branch para fazer mudanças no lado do cliente (`client`) e fez alguns commits. Finalmente, você voltou ao ser branch server e fez mais alguns commits.
Insert 18333fig0331.png
Figura 3-31. Histórico com um branch tópico a partir de outro
-Digamos que você decide fazer um merge das mudanças entre seu branch com mudanças do lado do cliente na linha de trabalho principal para lançar uma versão, mas quer segurar as mudanças do lado do servidor até que elas sejam testadas mais. Você pode pegar as mudanças que não estão no servidor (C8 e C9) e incluí-las nos seu branch master usando a opção `--onto` option of `git rebase`:
+Digamos que você decide fazer um merge das mudanças entre seu branch com mudanças do lado do cliente na linha de trabalho principal para lançar uma versão, mas quer segurar as mudanças do lado do servidor até que elas sejam testadas mais. Você pode pegar as mudanças que não estão no servidor (C8 e C9) e incluí-las nos seu branch master usando a opção `--onto` do `git rebase`:
$ git rebase --onto master server client
@@ -550,7 +550,7 @@ Em seguida, você pode avançar seu branch base (`master`):
$ git checkout master
$ git merge server
-Você pode apagar os branches `client` e `server` pois todo o trabalho ja foi integrado e você não precisa mais deles, deixando seu histórico de todo esse processo parecendo com a Figura 3-35:
+Você pode apagar os branches `client` e `server` pois todo o trabalho foi integrado e você não precisa mais deles, deixando seu histórico de todo esse processo parecendo com a Figura 3-35:
$ git branch -d client
$ git branch -d server
@@ -560,38 +560,38 @@ Figura 3-35. Histórico final de commits.
### Os perigos do Rebase ###
-Ahh, mas apesar dos beneficios do rebase existem os incovenientes, que podem ser resumidos em um linha:
+Ahh, mas apesar dos beneficios do rebase existem os inconvenientes, que podem ser resumidos em uma linha:
-**Não faça rebase de commits que você enviou para um reposítorio público.**
+**Não faça rebase de commits que você enviou para um reposítório público.**
Se você seguir essa regra você ficará bem. Se não seguir, as pessoas odiarão você, e você será desprezado por amigos e familiares.
-Quando você faz o rebase, você está abandonando commits existentes e criando novos que são similares mas diferentes. Se fizer o push de commits em algum lugar e outros pegarem e fazerem trabalho baseado neles, e você reescreve esses commits com `git rebase` e faz o push novamente, seus colaborares terão que fazer o merge novamente do trabalho deles e as coisas ficarão bagunçadas quando você tentar trazer o trabalho deles de volta para o seu.
+Quando você faz o rebase, você está abandonando commits existentes e criando novos que são similares mas diferentes. Se fizer o push de commits em algum lugar e outros pegarem e fizerem trabalho baseado neles, e você reescreve esses commits com `git rebase` e fizer o push novamente, seus colaborares terão que fazer o merge novamente do trabalho deles e as coisas ficarão bagunçadas quando você tentar trazer o trabalho deles de volta para o seu.
Vamos ver um exemplo de como o rebase trabalha e dos problemas que podem ser causados quando você torna algo público. Digamos que você faça o clone de um servidor central e faça algum trabalho em cima dele. Seu histórico de commits parece com a Figura 3-36.
Insert 18333fig0336.png
Figura 3-36. Clone de um repositório e trabalho a partir dele.
-Agora, outra pessoa faz modificações que inclui um merge, e envia (push) esse trabalho para o servidor central. Você o obtem e faz o merge do novo branch remoto no seu trabalho, fazendo com que seu histórico fique como na Figura 3-37.
+Agora, outra pessoa faz modificações que inclui um merge, e envia (push) esse trabalho para o servidor central. Você o obtém e faz o merge do novo branch remoto no seu trabalho, fazendo com que seu histórico fique como na Figura 3-37.
Insert 18333fig0337.png
-Figura 3-37. Obtem mais commits e faz o merge deles no seu trabalho.
+Figura 3-37. Obtém mais commits e faz o merge deles no seu trabalho.
-Em seguida, a pessoa que envio o merge voltou atrás e fez o rebase do seu do seu trabalho; eles executam `git push --force` para sobrescrever o histórico no servidor. Você então obtém os dados do servidor, trazendo os novos commits.
+Em seguida, a pessoa que envio o merge voltou atrás e fez o rebase do seu trabalho; eles executam `git push --force` para sobrescrever o histórico no servidor. Você então obtém os dados do servidor, trazendo os novos commits.
Insert 18333fig0338.png
Figura 3-38. Alguém envia commits com rebase, abandonando os commits que você usou como base para o seu trabalho.
-Nesse ponto, você tem que fazer o merge dessas modificações novamente, mesmo que você ja o tenha feito. Fazer o rebase muda o código hash SHA-1 desses commits então para o Git eles são commits novos, porém você ja tem as modificações de C4 no seu histórico (veja Figura 3-39).
+Nesse ponto, você tem que fazer o merge dessas modificações novamente, mesmo que você o tenha feito. Fazer o rebase muda o código hash SHA-1 desses commits então para o Git eles são commits novos, porém você tem as modificações de C4 no seu histórico (veja Figura 3-39).
Insert 18333fig0339.png
Figura 3-39. Você faz o merge novamente das mesmas coisas em um novo commit.
-Você tem que fazer o merge desse trabalho em algum momento para se manter atualizado em relação ao outro desenvolvedor no futuro. Depois de fazer isso, seu histórico de commits terá tanto o commit C4 quanto C4', que tem código hash SHA-1 diferentes mas tem as mesmas modificações e a mesma mensagem de commit. Se você executar `git log` quando seu histórico está dessa forma, você verá dois commits que terão o mesmo autor, data e mensagem, que será confuso. Além disso, se você enviar (push) esses histórico de volta ao servidor, você irá inserir novamente todos esses commits com rebase no servidor central, o que pode mais tarde confudir as pessoas.
+Você tem que fazer o merge desse trabalho em algum momento para se manter atualizado em relação ao outro desenvolvedor no futuro. Depois de fazer isso, seu histórico de commits terá tanto o commit C4 quanto C4', que tem código hash SHA-1 diferentes mas tem as mesmas modificações e a mesma mensagem de commit. Se você executar `git log` quando seu histórico está dessa forma, você verá dois commits que terão o mesmo autor, data e mensagem, que será confuso. Além disso, se você enviar (push) esses histórico de volta ao servidor, você irá inserir novamente todos esses commits com rebase no servidor central, o que pode mais tarde confundir as pessoas.
-Se você tratar o rebase como uma maneira de manter limpo e trabalhar com commits antes de enviá-los, e se você faz somente rebase de commits que nunca foram disponíveis publicamente, você ficará bem. Se você faz o rebase de commits que já foram enviados publicamente, e as pessoas podem ter se baseado neles para o trabalho delas, então você poderá ter problemas frustrantes.
+Se você tratar o rebase como uma maneira de manter limpo e trabalhar com commits antes de enviá-los, e se você faz somente rebase de commits que nunca foram disponibilizados publicamente, você ficará bem. Se você faz o rebase de commits que já foram disponibilizados publicamente, e as pessoas podem ter se baseado neles para o trabalho delas, então você poderá ter problemas frustrantes.
## 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 ser sentir confortável para criar 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
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 ##
Something went wrong with that request. Please try again.