07a4a3b496 · matheusbsbs/matheus-bagliano

@@ -16,7 +16,7 @@ Este tutorial explica como importar um novo projeto para o git,

16 adicionar mudanças a ele, e compartilhar mudanças com outros

17 desenvolvedores.

18

19 -If, ao invés disso, você está interessado primariamente em usar git para

19 +Se, ao invés disso, você está interessado primariamente em usar git para

20 obter um projeto, por exemplo, para testar a última versão, você pode

21 preferir começar com os primeiros dois capítulos de

22 link:user-manual.html[O Manual do Usuário Git].

@@ -37,9 +37,8 @@ $ git help log

37 Com a última forma, você pode usar o visualizador de manual de sua

38 escolha; veja linkgit:git-help[1] para maior informação.

39

40 -É uma boa idéia se introduzir ao git com seu nome e endereço público de

41 -email antes de fazer qualquer operação. A maneira mais fácil de fazê-lo

42 -é:

40 +É uma boa idéia informar ao git seu nome e endereço público de email

41 +antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é:

42

43 ------------------------------------------------

44 $ git config --global user.name "Seu Nome Vem Aqui"

@@ -51,7 +50,7 @@ Importando um novo projeto

50 -----------------------

51

52 Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.

54 -Você pode colocá-lo sob controle de revisão git como a seguir.

53 +Você pode colocá-lo sob controle de revisão git da seguinte forma:

54

55 ------------------------------------------------

56 $ tar xzf project.tar.gz

@@ -76,7 +75,7 @@ $ git add .

75 ------------------------------------------------

76

77 Este instantâneo está agora armazenado em uma área temporária que o git

79 -chama de "index" ou índice. Você pode permanetemente armazenar o

78 +chama de "index" ou índice. Você pode armazenar permanentemente o

79 conteúdo do índice no repositório com 'git-commit':

80

81 ------------------------------------------------

@@ -142,7 +141,7 @@ novos), adicioná-los ao índices, e gravar, tudo em um único passo.

141 Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa

142 idéia começar a mensagem com uma simples e curta (menos de 50

143 caracteres) linha sumarizando a mudança, seguida de uma linha em branco

145 -e, então, uma descrição mais detalhada. Ferramentas que transformam

144 +e, então, uma descrição mais detalhada. Ferramentas que transformam

145 commits em email, por exemplo, usam a primeira linha no campo de

146 cabeçalho Subject: e o resto no corpo.

147

@@ -150,7 +149,7 @@ Git rastreia conteúdo, não arquivos

149 ----------------------------

150

151 Muitos sistemas de controle de revisão provêem um comando `add` que diz

153 -ao sistema para começar a rastrear mudanças em um novo arquivo. O

152 +ao sistema para começar a rastrear mudanças em um novo arquivo. O

153 comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é

154 usado tanto para arquivos novos e arquivos recentemente modificados, e

155 em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena

@@ -183,7 +182,7 @@ Gerenciando "branches"/ramos

182 -----------------

183

184 Um simples repositório git pode manter múltiplos ramos de

186 -desenvolvimento. Para criar um novo ramo chamado "experimental", use

185 +desenvolvimento. Para criar um novo ramo chamado "experimental", use

186

187 ------------------------------------------------

188 $ git branch experimental

@@ -203,14 +202,14 @@ você vai obter uma lista de todos os ramos existentes:

202 ------------------------------------------------

203

204 O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o

206 -ramo padrão que foi criado pra você automaticamente. O asterisco marca

205 +ramo padrão que foi criado pra você automaticamente. O asterisco marca

206 o ramo em que você está atualmente; digite

207

208 ------------------------------------------------

209 $ git checkout experimental

210 ------------------------------------------------

211

213 -para mudar para o ramo experimental. Agora edite um arquivo, grave a

212 +para mudar para o ramo experimental. Agora edite um arquivo, grave a

213 mudança, e mude de volta para o ramo master:

214

215 ------------------------------------------------

@@ -230,14 +229,14 @@ $ git commit -a

229 ------------------------------------------------

230

231 neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em

233 -cada um. Para unificar as mudanças feitas no experimental para o

232 +cada um. Para unificar as mudanças feitas no experimental para o

233 master, execute

234

235 ------------------------------------------------

236 $ git merge experimental

237 ------------------------------------------------

238

240 -Se as mudanças não conflitam, está pronto. Se existirem conflitos,

239 +Se as mudanças não conflitarem, estará pronto. Se existirem conflitos,

240 marcadores serão deixados nos arquivos problemáticos exibindo o

241 conflito;

242

@@ -245,7 +244,7 @@ conflito;

244 $ git diff

245 ------------------------------------------------

246

248 -vai exibir isto. Após você editar os arquivos para resolver os

247 +vai exibir isto. Após você editar os arquivos para resolver os

248 conflitos,

249

250 ------------------------------------------------

@@ -273,7 +272,7 @@ Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode

272 sempre remover o ramo com

273

274 -------------------------------------

276 -$ git branch -D crazy-idea

275 +$ git branch -D ideia-louca

276 -------------------------------------

277

278 Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar

@@ -293,7 +292,7 @@ bob$ git clone /home/alice/project myrepo

292 ------------------------------------------------

293

294 Isso cria um novo diretório "myrepo" contendo um clone do repositório de

296 -Alice. O clone está no mesmo pé que o projeto original, possuindo sua

295 +Alice. O clone está no mesmo pé que o projeto original, possuindo sua

296 própria cópia da história do projeto original.

297

298 Bob então faz algumas mudanças e as grava:

@@ -305,7 +304,7 @@ bob$ git commit -a

304 ------------------------------------------------

305

306 Quanto está pronto, ele diz a Alice para puxar as mudanças do

308 -repositório em /home/bob/myrepo. Ela o faz com:

307 +repositório em /home/bob/myrepo. Ela o faz com:

308

309 ------------------------------------------------

310 alice$ cd /home/alice/project

@@ -314,14 +313,14 @@ alice$ git pull /home/bob/myrepo master

313

314 Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice.

315 Se Alice fez suas próprias mudanças no intervalo, ela, então, pode

317 -precisar corrigir manualmente quaiquer conflitos. (Note que o argumento

316 +precisar corrigir manualmente quaisquer conflitos. (Note que o argumento

317 "master" no comando acima é, de fato, desnecessário, já que é o padrão.)

318

319 O comando "pull" executa, então, duas operações: ele obtém mudanças de

320 um ramo remoto, e, então, as unifica no ramo atual.

321

322 Note que, em geral, Alice gostaria que suas mudanças locais fossem

324 -gravadas antes de iniciar este "pull". Se o trabalho de Bobo conflita

323 +gravadas antes de iniciar este "pull". Se o trabalho de Bob conflita

324 com o que Alice fez desde que suas histórias se ramificaram, Alice irá

325 usar seu diretório de trabalho e o índice para resolver conflitos, e

326 mudanças locais existentes irão interferir com o processo de resolução

@@ -341,18 +340,18 @@ alice$ git log -p HEAD..FETCH_HEAD

340

341 Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.

342 A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é

344 -alcançável de FETCH_HEAD mas exclua tudo que é alcançável de HEAD. Alcie

345 -já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob tem

346 -em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.

343 +alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD.

344 +Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob

345 +tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.

346

348 -Se Alice quer visualizar o que Bob fez desde que suas história

347 +Se Alice quer visualizar o que Bob fez desde que suas histórias se

348 ramificaram, ela pode disparar o seguinte comando:

349

350 ------------------------------------------------

351 $ gitk HEAD..FETCH_HEAD

352 ------------------------------------------------

353

355 -Isto usar a mesma notação de intervaldo que vimos antes com 'git log'.

354 +Isto usa a mesma notação de intervalo que vimos antes com 'git log'.

355

356 Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela

357 pode usar a forma com três pontos ao invés da forma com dois pontos:

@@ -361,23 +360,21 @@ pode usar a forma com três pontos ao invés da forma com dois pontos:

360 $ gitk HEAD...FETCH_HEAD

361 ------------------------------------------------

362

364 -Isto significa "mostre tudo que é alcançavel de qualquer um, mas exclua

365 -tudo que é alcançavel a partir de ambos".

366 -This means "show everything that is reachable from either one, but

367 -exclude anything that is reachable from both of them".

363 +Isto significa "mostre tudo que é alcançável de qualquer um deles, mas

364 +exclua tudo que é alcançável a partir de ambos".

365

366 Por favor, note que essas notações de intervalo podem ser usadas tanto

367 com gitk quanto com "git log".

368

372 -Apoós inspecionar o que Bob fez, se não há nada urgente, Alice pode

373 -decidir continuar trabalhando sem puxar de Bob. Se a história de Bob

369 +Após inspecionar o que Bob fez, se não há nada urgente, Alice pode

370 +decidir continuar trabalhando sem puxar de Bob. Se a história de Bob

371 tem alguma coisa que Alice precisa imediatamente, Alice pode optar por

372 separar seu trabalho em progresso primeiro, fazer um "pull", e, então,

373 finalmente, retomar seu trabalho em progresso em cima da história

374 resultante.

375

379 -Quanto você está trabalhando em um pequeno grupo unido, não é incomum

380 -interagir com o mesmo repositório várias e várias vezes. Definindo um

376 +Quando você está trabalhando em um pequeno grupo unido, não é incomum

377 +interagir com o mesmo repositório várias e várias vezes. Definindo um

378 repositório remoto antes de tudo, você pode fazê-lo mais facilmente:

379

380 ------------------------------------------------

@@ -394,7 +391,7 @@ alice$ git fetch bob

391

392 Diferente da forma longa, quando Alice obteve de Bob usando um

393 repositório remoto antes definido com 'git-remote', o que foi obtido é

397 -armazenado um ramo remoto, neste caso `bob/master`. Então, após isso:

394 +armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso:

395

396 -------------------------------------

397 alice$ git log -p master..bob/master

@@ -417,7 +414,7 @@ alice$ git pull . remotes/bob/master

414 -------------------------------------

415

416 Note que 'git pull' sempre unifica ao ramo atual, independente do que

420 -mais foi dado na linha de comando.

417 +mais foi passado na linha de comando.

418

419 Depois, Bob pode atualizar seu repositório com as últimas mudanças de

420 Alice, usando

@@ -428,7 +425,7 @@ bob$ git pull

425

426 Note que ele não precisa dar o caminho do repositório de Alice; quando

427 Bob clonou seu repositório, o git armazenou a localização de seu

431 -repositório na configuração do repositório, e essa localização é usada

428 +repositório na configuração do mesmo, e essa localização é usada

429 para puxar:

430

431 -------------------------------------

@@ -459,15 +456,15 @@ Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou

456 http; veja linkgit:git-pull[1] para detalhes.

457

458 Git pode também ser usado em um modo parecido com CVS, com um

462 -repositório central para o qual que vários usuários empurram

463 -modificações; veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].

459 +repositório central para o qual vários usuários empurram modificações;

460 +veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].

461

462 Explorando história

463 -----------------

464

465 A história no git é representada como uma série de commits

469 -interrelacionados. Nós já vimos que o comando 'git-log' pode listar

470 -esses commits. Note que a primeira linha de cama entrada no log também

466 +interrelacionados. Nós já vimos que o comando 'git-log' pode listar

467 +esses commits. Note que a primeira linha de cada entrada no log também

468 dá o nome para o commit:

469

470 -------------------------------------

@@ -486,9 +483,9 @@ commit.

483 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

484 -------------------------------------

485

489 -Mas há outras formas de se referir a commits. Você pode usar qualquer

490 -parte inicial do nome que seja longo o bastante para unicamente

491 -identificar o commit:

486 +Mas há outras formas de se referir aos commits. Você pode usar qualquer

487 +parte inicial do nome que seja longo o bastante para identificar

488 +unicamente o commit:

489

490 -------------------------------------

491 $ git show c82a22c39c # os primeiros caracteres do nome são o bastante

@@ -497,7 +494,7 @@ $ git show HEAD # a ponta do ramo atual

494 $ git show experimental # a ponta do ramo "experimental"

495 -------------------------------------

496

500 -Todo commit usualmente tem um commit "pai" que aponta para o estado

497 +Todo commit normalmente tem um commit "pai" que aponta para o estado

498 anterior do projeto:

499

500 -------------------------------------

@@ -513,19 +510,19 @@ $ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)

510 $ git show HEAD^2 # mostra o segundo pai de HEAD

511 -------------------------------------

512

516 -Você também pode dar aos commits nomes seus; após executar

513 +Você também pode dar aos commits nomes à sua escolha; após executar

514

515 -------------------------------------

516 $ git tag v2.5 1b2e1d63ff

517 -------------------------------------

518

522 -você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende

519 +você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende

520 compartilhar esse nome com outras pessoas (por exemplo, para identificar

524 -uma versão de lançamento), você deve criar um objeto "tag", e talvez

521 +uma versão de lançamento), você deveria criar um objeto "tag", e talvez

522 assiná-lo; veja linkgit:git-tag[1] para detalhes.

523

524 Qualquer comando git que precise conhecer um commit pode receber

528 -quaisquer desses nomes. Por exemplo:

525 +quaisquer desses nomes. Por exemplo:

526

527 -------------------------------------

528 $ git diff v2.5 HEAD # compara o HEAD atual com v2.5

@@ -537,8 +534,8 @@ $ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de

534

535 Seja cuidadoso com o último comando: além de perder quaisquer mudanças

536 em seu diretório de trabalho, ele também remove todos os commits

540 -posteriores desse ramo. Se esse ramo é o único ramo contendo esses

541 -commits, eles serão perdidos. Também, não use 'git-reset' num ramo

537 +posteriores desse ramo. Se esse ramo é o único ramo contendo esses

538 +commits, eles serão perdidos. Também, não use 'git-reset' num ramo

539 publicamente visível de onde outros desenvolvedores puxam, já que vai

540 forçar unificações desnecessárias para que outros desenvolvedores limpem

541 a história. Se você precisa desfazer mudanças que você empurrou, use

@@ -551,10 +548,10 @@ projeto, então

548 $ git grep "hello" v2.5

549 -------------------------------------

550

554 -procura por todas as ocorreências de "hello" em v2.5.

551 +procura por todas as ocorrências de "hello" em v2.5.

552

553 Se você deixar de fora o nome do commit, 'git-grep' irá procurar

557 -quaisquer dos arquivos que ele gerencia no diretório corrente. Então

554 +quaisquer dos arquivos que ele gerencia no diretório corrente. Então

555

556 -------------------------------------

557 $ git grep "hello"

@@ -564,8 +561,7 @@ $ git grep "hello"

561 git.

562

563 Muitos comandos git também recebem um conjunto de commits, o que pode

567 -ser especificado de um bom número de formas. Aqui estão alguns exemplos

568 -com 'git-log':

564 +ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log':

565

566 -------------------------------------

567 $ git log v2.5..v2.6 # commits entre v2.5 e v2.6

@@ -584,7 +580,7 @@ comum algum tempo atrás, então

580 $ git log stable..master

581 -------------------------------------

582

587 -irá listas os commits feitos no ramo "master" mas não no ramo

583 +irá listar os commits feitos no ramo "master" mas não no ramo

584 "stable", enquanto

585

586 -------------------------------------

@@ -594,26 +590,26 @@ $ git log master..stable

590 irá listar a lista de commits feitos no ramo "stable" mas não no ramo

591 "master".

592

597 -O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em

593 +O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em

594 uma lista. Quando a história tem linhas de desenvolvimento que

595 divergiram e então foram unificadas novamente, a ordem em que 'git-log'

600 -apresenta essas mudanças é insignificante.

596 +apresenta essas mudanças é irrelevante.

597

598 A maioria dos projetos com múltiplos contribuidores (como o kernel

603 -linux, ou o git mesmo) tem unificações frequentes, e 'gitk' faz um

604 -trabalho melhor de visualizar sua história. Por exemplo,

599 +Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um

600 +trabalho melhor de visualizar sua história. Por exemplo,

601

602 -------------------------------------

603 $ gitk --since="2 weeks ago" drivers/

604 -------------------------------------

605

610 -permite você navegar em quaisquer commits desde as últimas duas semanas

611 -de commits que modificaram arquivos sob o diretório "drivers". (Nota:

606 +permite a você navegar em quaisquer commits desde as últimas duas semanas

607 +de commits que modificaram arquivos sob o diretório "drivers". (Nota:

608 você pode ajustar as fontes do gitk segurando a tecla control enquanto

609 pressiona "-" ou "+".)

610

615 -Finalmente, a maioria dos comandos que recebem nomes de arquivo

616 -te permitirão opcionalmente preceder qualquer nome de arquivo por um

611 +Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão

612 +também, opcionalmente, preceder qualquer nome de arquivo por um

613 commit, para especificar uma versão particular do arquivo:

614

615 -------------------------------------

@@ -630,33 +626,33 @@ Próximos passos

626 ----------

627

628 Este tutorial deve ser o bastante para operar controle de revisão

633 -distribuído básico para seus projetos. No entanto, para entender

629 +distribuído básico para seus projetos. No entanto, para entender

630 plenamente a profundidade e o poder do git você precisa entender duas

631 idéias simples nas quais ele se baseia:

632

633 * A base de objetos é um sistema bem elegante usado para armazenar a

634 história de seu projeto--arquivos, diretórios, e commits.

635

640 - * O arquivo de índica é um cache do estado de uma árvore de diretório,

636 + * O arquivo de índice é um cache do estado de uma árvore de diretório,

637 usado para criar commits, restaurar diretórios de trabalho, e

642 - compreender as várias árvores involvidas em uma unificação.

638 + armazenar as várias árvores envolvidas em uma unificação.

639

644 -Parte dois deste tutorial explica a base de objetos, o arquivo de

640 +A parte dois deste tutorial explica a base de objetos, o arquivo de

641 índice, e algumas outras coisinhas que você vai precisar pra usar o

642 máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].

643

648 -Se você não quer continuar do jeito certo, algumas outras disgressões

649 -que podem ser interessantes neste ponto são:

644 +Se você não quiser continuar com o tutorial agora nesse momento, algumas

645 +outras digressões que podem ser interessantes neste ponto são:

646

647 * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem

652 - séries de commits em patches em email, e vice-versa, úteis para

653 - projetos como o kernel linux que dependem pesadamente em patches

648 + séries de commits em patches para email, e vice-versa, úteis para

649 + projetos como o kernel Linux que dependem fortemente de patches

650 enviados por email.

651

652 * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma

653 forma de rastrear um bug é procurando pela história para encontrar o

658 - commit culpado. Git bisect pode ajudar a executar uma busca binária

659 - por esse commit. Ele é inteligente o bastante para executar uma

654 + commit culpado. Git bisect pode ajudar a executar uma busca binária

655 + por esse commit. Ele é inteligente o bastante para executar uma

656 busca próxima da ótima mesmo no caso de uma história complexa

657 não-linear com muitos ramos unificados.

658

@@ -664,7 +660,7 @@ que podem ser interessantes neste ponto são:

660

661 * linkgit:gitcvs-migration[7]: Git para usuários de CVS.

662

667 -Veja Também

663 +VEJA TAMBÉM

664 --------

665 linkgit:gittutorial-2[7],

666 linkgit:gitcvs-migration[7],

Fix typos on pt_BR/gittutorial.txt translation