0a85441cdb · matheusbsbs/matheus-bagliano

@@ -1,675 +0,0 @@

1 -gittutorial(7)

2 -==============

3 -

4 -NOME

5 -----

6 -gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)

7 -

8 -SINOPSE

9 ---------

10 -git *

11 -

12 -DESCRIÇÃO

13 ------------

14 -

15 -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 -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].

23 -

24 -Primeiro, note que você pode obter documentação para um comando como

25 -`git log --graph` com:

26 -

27 -------------------------------------------------

28 -$ man git-log

29 -------------------------------------------------

30 -

31 -ou:

32 -

33 -------------------------------------------------

34 -$ git help log

35 -------------------------------------------------

36 -

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 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"

45 -$ git config --global user.email voce@seudominio.exemplo.com

46 -------------------------------------------------

47 -

48 -

49 -Importando um novo projeto

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

51 -

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

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

54 -

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

56 -$ tar xzf project.tar.gz

57 -$ cd project

58 -$ git init

59 -------------------------------------------------

60 -

61 -Git irá responder

62 -

63 -------------------------------------------------

64 -Initialized empty Git repository in .git/

65 -------------------------------------------------

66 -

67 -Agora que você iniciou seu diretório de trabalho, você deve ter notado que um

68 -novo diretório foi criado com o nome de ".git".

69 -

70 -A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os

71 -arquivos sob o diretório atual (note o '.'), com 'git-add':

72 -

73 -------------------------------------------------

74 -$ git add .

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

76 -

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

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

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

80 -

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

82 -$ git commit

83 -------------------------------------------------

84 -

85 -Isto vai te pedir por uma mensagem de commit. Você agora gravou sua

86 -primeira versão de seu projeto no git.

87 -

88 -Fazendo mudanças

89 ---------------

90 -

91 -Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao

92 -índice:

93 -

94 -------------------------------------------------

95 -$ git add file1 file2 file3

96 -------------------------------------------------

97 -

98 -Você está agora pronto para fazer o commit. Você pode ver o que está

99 -para ser gravado usando 'git-diff' com a opção --cached:

100 -

101 -------------------------------------------------

102 -$ git diff --cached

103 -------------------------------------------------

104 -

105 -(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças

106 -que você tenha feito mas ainda não adicionou ao índice.) Você também

107 -pode obter um breve sumário da situação com 'git-status':

108 -

109 -------------------------------------------------

110 -$ git status

111 -# On branch master

112 -# Changes to be committed:

113 -# (use "git reset HEAD <file>..." to unstage)

114 -#

115 -# modified: file1

116 -# modified: file2

117 -# modified: file3

118 -#

119 -------------------------------------------------

120 -

121 -Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,

122 -adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas

123 -mudanças com:

124 -

125 -------------------------------------------------

126 -$ git commit

127 -------------------------------------------------

128 -

129 -Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,

130 -e, então, irá gravar a nova versão do projeto.

131 -

132 -Alternativamente, ao invés de executar 'git-add' antes, você pode usar

133 -

134 -------------------------------------------------

135 -$ git commit -a

136 -------------------------------------------------

137 -

138 -o que irá automaticamente notar quaisquer arquivos modificados (mas não

139 -novos), adicioná-los ao índices, e gravar, tudo em um único passo.

140 -

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

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 -

148 -Git rastreia conteúdo, não arquivos

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

150 -

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

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

156 -o conteúdo no índice, pronto para inclusão do próximo commit.

157 -

158 -Visualizando a história do projeto

159 ------------------------

160 -

161 -Em qualquer ponto você pode visualizar a história das suas mudanças

162 -usando

163 -

164 -------------------------------------------------

165 -$ git log

166 -------------------------------------------------

167 -

168 -Se você também quiser ver a diferença completa a cada passo, use

169 -

170 -------------------------------------------------

171 -$ git log -p

172 -------------------------------------------------

173 -

174 -Geralmente, uma visão geral da mudança é útil para ter a sensação de

175 -cada passo

176 -

177 -------------------------------------------------

178 -$ git log --stat --summary

179 -------------------------------------------------

180 -

181 -Gerenciando "branches"/ramos

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

183 -

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

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

186 -

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

188 -$ git branch experimental

189 -------------------------------------------------

190 -

191 -Se você executar agora

192 -

193 -------------------------------------------------

194 -$ git branch

195 -------------------------------------------------

196 -

197 -você vai obter uma lista de todos os ramos existentes:

198 -

199 -------------------------------------------------

200 - experimental

201 -* master

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

203 -

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

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 -

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 -------------------------------------------------

216 -(edita arquivo)

217 -$ git commit -a

218 -$ git checkout master

219 -------------------------------------------------

220 -

221 -Verifique que a mudança que você fez não está mais visível, já que ela

222 -foi feita no ramo experimental e você está de volta ao ramo master.

223 -

224 -Você pode fazer uma mudança diferente no ramo master:

225 -

226 -------------------------------------------------

227 -(edit file)

228 -$ git commit -a

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

230 -

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

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

233 -master, execute

234 -

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

236 -$ git merge experimental

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

238 -

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 -

243 -------------------------------------------------

244 -$ git diff

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

246 -

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

248 -conflitos,

249 -

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

251 -$ git commit -a

252 -------------------------------------------------

253 -

254 -irá gravar o resultado da unificação. Finalmente,

255 -

256 -------------------------------------------------

257 -$ gitk

258 -------------------------------------------------

259 -

260 -vai mostrar uma bela representação gráfica da história resultante.

261 -

262 -Neste ponto você pode remover seu ramo experimental com

263 -

264 -------------------------------------------------

265 -$ git branch -d experimental

266 -------------------------------------------------

267 -

268 -Este comando garante que as mudanças no ramo experimental já estão no

269 -ramo atual.

270 -

271 -Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode

272 -sempre remover o ramo com

273 -

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

275 -$ git branch -D ideia-louca

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

277 -

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

279 -alguma coisa.

280 -

281 -Usando git para colaboração

282 ----------------------------

283 -

284 -Suponha que Alice começou um novo projeto com um repositório git em

285 -/home/alice/project, e que Bob, que tem um diretório home na mesma

286 -máquina, quer contribuir.

287 -

288 -Bob começa com:

289 -

290 -------------------------------------------------

291 -bob$ git clone /home/alice/project myrepo

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

293 -

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

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:

299 -

300 -------------------------------------------------

301 -(editar arquivos)

302 -bob$ git commit -a

303 -(repetir conforme necessário)

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

305 -

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

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

308 -

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

310 -alice$ cd /home/alice/project

311 -alice$ git pull /home/bob/myrepo master

312 -------------------------------------------------

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

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

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

327 -de conflitos (git ainda irá realizar a obtenção mas irá se recusar a

328 -unificar --- Alice terá que se livrar de suas mudanças locais de alguma

329 -forma e puxar de novo quando isso acontecer).

330 -

331 -Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando

332 -"fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo

333 -especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa

334 -que vale puxar, assim:

335 -

336 -------------------------------------------------

337 -alice$ git fetch /home/bob/myrepo master

338 -alice$ git log -p HEAD..FETCH_HEAD

339 -------------------------------------------------

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 é

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 -

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 -

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:

358 -

359 -------------------------------------------------

360 -$ gitk HEAD...FETCH_HEAD

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

362 -

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 -

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 -

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 -------------------------------------------------

381 -alice$ git remote add bob /home/bob/myrepo

382 -------------------------------------------------

383 -

384 -Com isso, Alice pode executar a primeira parte da operação "pull" usando

385 -o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,

386 -usando:

387 -

388 --------------------------------------

389 -alice$ git fetch bob

390 --------------------------------------

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 é

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

398 --------------------------------------

399 -

400 -mostra uma lista de todas as mudanças que Bob fez desde que ramificou do

401 -ramo master de Alice.

402 -

403 -Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:

404 -

405 --------------------------------------

406 -alice$ git merge bob/master

407 --------------------------------------

408 -

409 -Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,

410 -assim:

411 -

412 --------------------------------------

413 -alice$ git pull . remotes/bob/master

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

415 -

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

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

421 -

422 --------------------------------------

423 -bob$ git pull

424 --------------------------------------

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

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

429 -para puxar:

430 -

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

432 -bob$ git config --get remote.origin.url

433 -/home/alice/project

434 --------------------------------------

435 -

436 -(A configuração completa criada por 'git-clone' é visível usando `git

437 -config -l`, e a página de manual linkgit:git-config[1] explica o

438 -significado de cada opção.)

439 -

440 -Git também mantém uma cópia limpa do ramo master de Alice sob o nome

441 -"origin/master":

442 -

443 --------------------------------------

444 -bob$ git branch -r

445 - origin/master

446 --------------------------------------

447 -

448 -Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode

449 -executar clones e puxar usando o protocolo ssh:

450 -

451 --------------------------------------

452 -bob$ git clone alice.org:/home/alice/project myrepo

453 --------------------------------------

454 -

455 -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

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

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 --------------------------------------

471 -$ git log

472 -commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

473 -Author: Junio C Hamano <junkio@cox.net>

474 -Date: Tue May 16 17:18:22 2006 -0700

475 -

476 - merge-base: Clarify the comments on post processing.

477 --------------------------------------

478 -

479 -Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este

480 -commit.

481 -

482 --------------------------------------

483 -$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

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

485 -

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

492 - # usualmente

493 -$ git show HEAD # a ponta do ramo atual

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

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

496 -

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

498 -anterior do projeto:

499 -

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

501 -$ git show HEAD^ # para ver o pai de HEAD

502 -$ git show HEAD^^ # para ver o avô de HEAD

503 -$ git show HEAD~4 # para ver o trisavô de HEAD

504 --------------------------------------

505 -

506 -Note que commits de unificação podem ter mais de um pai:

507 -

508 --------------------------------------

509 -$ 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 -

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

514 -

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

516 -$ git tag v2.5 1b2e1d63ff

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

518 -

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

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

525 -quaisquer desses nomes. Por exemplo:

526 -

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

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

529 -$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado

530 - # em v2.5

531 -$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de

532 - # trabalho a seu estado em HEAD^

533 --------------------------------------

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

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

542 -'git-revert' no lugar.

543 -

544 -O comando 'git-grep' pode buscar strings em qualquer versão de seu

545 -projeto, então

546 -

547 --------------------------------------

548 -$ git grep "hello" v2.5

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

550 -

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

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

555 -

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

557 -$ git grep "hello"

558 --------------------------------------

559 -

560 -é uma forma rápida de buscar somente os arquivos que são rastreados pelo

561 -git.

562 -

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

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

568 -$ git log v2.5.. # commits desde v2.5

569 -$ git log --since="2 weeks ago" # commits das últimas 2 semanas

570 -$ git log v2.5.. Makefile # commits desde v2.5 que modificam

571 - # Makefile

572 --------------------------------------

573 -

574 -Você também pode dar ao 'git-log' um "intervalo" de commits onde o

575 -primeiro não é necessariamente um ancestral do segundo; por exemplo, se

576 -as pontas dos ramos "stable" e "master" divergiram de um commit

577 -comum algum tempo atrás, então

578 -

579 --------------------------------------

580 -$ git log stable..master

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

582 -

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

584 -"stable", enquanto

585 -

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

587 -$ git log master..stable

588 --------------------------------------

589 -

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

591 -"master".

592 -

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'

596 -apresenta essas mudanças é irrelevante.

597 -

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

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 -

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 -

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 --------------------------------------

616 -$ git diff v2.5:Makefile HEAD:Makefile.in

617 --------------------------------------

618 -

619 -Você pode usar 'git-show' para ver tal arquivo:

620 -

621 --------------------------------------

622 -$ git show v2.5:Makefile

623 --------------------------------------

624 -

625 -Próximos passos

626 -----------

627 -

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

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 -

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

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

639 -

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 -

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

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

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 -

659 - * link:everyday.html[GIT diariamente com 20 e tantos comandos]

660 -

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

662 -

663 -VEJA TAMBÉM

664 ---------

665 -linkgit:gittutorial-2[7],

666 -linkgit:gitcvs-migration[7],

667 -linkgit:gitcore-tutorial[7],

668 -linkgit:gitglossary[7],

669 -linkgit:git-help[1],

670 -link:everyday.html[git diariamente],

671 -link:user-manual.html[O Manual do Usuário git]

672 -

673 -GIT

674 ----

675 -Parte da suite linkgit:git[1].

Remove Documentation/pt_BR/gittutorial.txt