]>
Commit | Line | Data |
---|---|---|
e6580020 TLSC |
1 | gittutorial(7) |
2 | ============== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova) | |
7 | ||
8 | SYNOPSIS | |
9 | -------- | |
10 | git * | |
11 | ||
12 | DESCRIPTION | |
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 | If, 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 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 | é: | |
43 | ||
44 | ------------------------------------------------ | |
45 | $ git config --global user.name "Seu Nome Vem Aqui" | |
46 | $ git config --global user.email voce@seudominio.exemplo.com | |
47 | ------------------------------------------------ | |
48 | ||
49 | ||
50 | Importando um novo projeto | |
51 | ----------------------- | |
52 | ||
53 | 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. | |
55 | ||
56 | ------------------------------------------------ | |
57 | $ tar xzf project.tar.gz | |
58 | $ cd project | |
59 | $ git init | |
60 | ------------------------------------------------ | |
61 | ||
62 | Git irá responder | |
63 | ||
64 | ------------------------------------------------ | |
65 | Initialized empty Git repository in .git/ | |
66 | ------------------------------------------------ | |
67 | ||
68 | Você agora iniciou seu diretório de trabalho--você deve ter notado um | |
69 | novo diretório criado, com o nome de ".git". | |
70 | ||
71 | A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os | |
72 | arquivos sob o diretório corrente (note o '.'), com 'git-add': | |
73 | ||
74 | ------------------------------------------------ | |
75 | $ git add . | |
76 | ------------------------------------------------ | |
77 | ||
78 | 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 | |
80 | conteúdo do índice no repositório com 'git-commit': | |
81 | ||
82 | ------------------------------------------------ | |
83 | $ git commit | |
84 | ------------------------------------------------ | |
85 | ||
86 | Isto vai te pedir por uma mensagem de commit. Você agora gravou sua | |
87 | primeira versão de seu projeto no git. | |
88 | ||
89 | Fazendo mudanças | |
90 | -------------- | |
91 | ||
92 | Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao | |
93 | índice: | |
94 | ||
95 | ------------------------------------------------ | |
96 | $ git add file1 file2 file3 | |
97 | ------------------------------------------------ | |
98 | ||
99 | Você está agora pronto para fazer o commit. Você pode ver o que está | |
100 | para ser gravado usando 'git-diff' com a opção --cached: | |
101 | ||
102 | ------------------------------------------------ | |
103 | $ git diff --cached | |
104 | ------------------------------------------------ | |
105 | ||
106 | (Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças | |
107 | que você tenha feito mas ainda não adicionou ao índice.) Você também | |
108 | pode obter um breve sumário da situação com 'git-status': | |
109 | ||
110 | ------------------------------------------------ | |
111 | $ git status | |
112 | # On branch master | |
113 | # Changes to be committed: | |
114 | # (use "git reset HEAD <file>..." to unstage) | |
115 | # | |
116 | # modified: file1 | |
117 | # modified: file2 | |
118 | # modified: file3 | |
119 | # | |
120 | ------------------------------------------------ | |
121 | ||
122 | Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então, | |
123 | adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas | |
124 | mudanças com: | |
125 | ||
126 | ------------------------------------------------ | |
127 | $ git commit | |
128 | ------------------------------------------------ | |
129 | ||
130 | Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e, | |
131 | então, gravar a nova versão do projeto. | |
132 | ||
133 | Alternativamente, ao invés de executar 'git-add' antes, você pode usar | |
134 | ||
135 | ------------------------------------------------ | |
136 | $ git commit -a | |
137 | ------------------------------------------------ | |
138 | ||
139 | o que irá automaticamente notar quaisquer arquivos modificados (mas não | |
140 | novos), adicioná-los ao índices, e gravar, tudo em um único passo. | |
141 | ||
142 | Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa | |
143 | idéia começar a mensagem com uma simples e curta (menos de 50 | |
144 | caracteres) linha sumarizando a mudança, seguida de uma linha em branco | |
145 | e, então, uma descrição mais detalhada. Ferramentas que transformam | |
146 | commits em email, por exemplo, usam a primeira linha no campo de | |
147 | cabeçalho Subject: e o resto no corpo. | |
148 | ||
149 | Git rastreia conteúdo, não arquivos | |
150 | ---------------------------- | |
151 | ||
152 | 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 | |
154 | comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é | |
155 | usado tanto para arquivos novos e arquivos recentemente modificados, e | |
156 | em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena | |
157 | o conteúdo no índice, pronto para inclusão do próximo commit. | |
158 | ||
159 | Visualizando história do projeto | |
160 | ----------------------- | |
161 | ||
162 | Em qualquer ponto você pode visualizar a história das suas mudanças | |
163 | usando | |
164 | ||
165 | ------------------------------------------------ | |
166 | $ git log | |
167 | ------------------------------------------------ | |
168 | ||
169 | Se você também quer ver a diferença completa a cada passo, use | |
170 | ||
171 | ------------------------------------------------ | |
172 | $ git log -p | |
173 | ------------------------------------------------ | |
174 | ||
175 | Geralmente, uma visão geral da mudança é útil para ter a sensação de | |
176 | cada passo | |
177 | ||
178 | ------------------------------------------------ | |
179 | $ git log --stat --summary | |
180 | ------------------------------------------------ | |
181 | ||
182 | Gerenciando "branches"/ramos | |
183 | ----------------- | |
184 | ||
185 | Um simples repositório git pode manter múltiplos ramos de | |
186 | desenvolvimento. Para criar um novo ramo chamado "experimental", use | |
187 | ||
188 | ------------------------------------------------ | |
189 | $ git branch experimental | |
190 | ------------------------------------------------ | |
191 | ||
192 | Se você executar agora | |
193 | ||
194 | ------------------------------------------------ | |
195 | $ git branch | |
196 | ------------------------------------------------ | |
197 | ||
198 | você vai obter uma lista de todos os ramos existentes: | |
199 | ||
200 | ------------------------------------------------ | |
201 | experimental | |
202 | * master | |
203 | ------------------------------------------------ | |
204 | ||
205 | 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 | |
207 | o ramo em que você está atualmente; digite | |
208 | ||
209 | ------------------------------------------------ | |
210 | $ git checkout experimental | |
211 | ------------------------------------------------ | |
212 | ||
213 | para mudar para o ramo experimental. Agora edite um arquivo, grave a | |
214 | mudança, e mude de volta para o ramo master: | |
215 | ||
216 | ------------------------------------------------ | |
217 | (edita arquivo) | |
218 | $ git commit -a | |
219 | $ git checkout master | |
220 | ------------------------------------------------ | |
221 | ||
222 | Verifique que a mudança que você fez não está mais visível, já que ela | |
223 | foi feita no ramo experimental e você está de volta ao ramo master. | |
224 | ||
225 | Você pode fazer uma mudança diferente no ramo master: | |
226 | ||
227 | ------------------------------------------------ | |
228 | (edit file) | |
229 | $ git commit -a | |
230 | ------------------------------------------------ | |
231 | ||
232 | 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 | |
234 | master, execute | |
235 | ||
236 | ------------------------------------------------ | |
237 | $ git merge experimental | |
238 | ------------------------------------------------ | |
239 | ||
240 | Se as mudanças não conflitam, está pronto. Se existirem conflitos, | |
241 | marcadores serão deixados nos arquivos problemáticos exibindo o | |
242 | conflito; | |
243 | ||
244 | ------------------------------------------------ | |
245 | $ git diff | |
246 | ------------------------------------------------ | |
247 | ||
248 | vai exibir isto. Após você editar os arquivos para resolver os | |
249 | conflitos, | |
250 | ||
251 | ------------------------------------------------ | |
252 | $ git commit -a | |
253 | ------------------------------------------------ | |
254 | ||
255 | irá gravar o resultado da unificação. Finalmente, | |
256 | ||
257 | ------------------------------------------------ | |
258 | $ gitk | |
259 | ------------------------------------------------ | |
260 | ||
261 | vai mostrar uma bela representação gráfica da história resultante. | |
262 | ||
263 | Neste ponto você pode remover seu ramo experimental com | |
264 | ||
265 | ------------------------------------------------ | |
266 | $ git branch -d experimental | |
267 | ------------------------------------------------ | |
268 | ||
269 | Este comando garante que as mudanças no ramo experimental já estão no | |
270 | ramo atual. | |
271 | ||
272 | Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode | |
273 | sempre remover o ramo com | |
274 | ||
275 | ------------------------------------- | |
276 | $ git branch -D crazy-idea | |
277 | ------------------------------------- | |
278 | ||
279 | Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar | |
280 | alguma coisa. | |
281 | ||
282 | Usando git para colaboração | |
283 | --------------------------- | |
284 | ||
285 | Suponha que Alice começou um novo projeto com um repositório git em | |
286 | /home/alice/project, e que Bob, que tem um diretório home na mesma | |
287 | máquina, quer contribuir. | |
288 | ||
289 | Bob começa com: | |
290 | ||
291 | ------------------------------------------------ | |
292 | bob$ git clone /home/alice/project myrepo | |
293 | ------------------------------------------------ | |
294 | ||
295 | 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 | |
297 | própria cópia da história do projeto original. | |
298 | ||
299 | Bob então faz algumas mudanças e as grava: | |
300 | ||
301 | ------------------------------------------------ | |
302 | (editar arquivos) | |
303 | bob$ git commit -a | |
304 | (repetir conforme necessário) | |
305 | ------------------------------------------------ | |
306 | ||
307 | Quanto está pronto, ele diz a Alice para puxar as mudanças do | |
308 | repositório em /home/bob/myrepo. Ela o faz com: | |
309 | ||
310 | ------------------------------------------------ | |
311 | alice$ cd /home/alice/project | |
312 | alice$ git pull /home/bob/myrepo master | |
313 | ------------------------------------------------ | |
314 | ||
315 | Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice. | |
316 | Se Alice fez suas próprias mudanças no intervalo, ela, então, pode | |
317 | precisar corrigir manualmente quaiquer conflitos. (Note que o argumento | |
318 | "master" no comando acima é, de fato, desnecessário, já que é o padrão.) | |
319 | ||
320 | O comando "pull" executa, então, duas operações: ele obtém mudanças de | |
321 | um ramo remoto, e, então, as unifica no ramo atual. | |
322 | ||
323 | 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 | |
325 | com o que Alice fez desde que suas histórias se ramificaram, Alice irá | |
326 | usar seu diretório de trabalho e o índice para resolver conflitos, e | |
327 | mudanças locais existentes irão interferir com o processo de resolução | |
328 | de conflitos (git ainda irá realizar a obtenção mas irá se recusar a | |
329 | unificar --- Alice terá que se livrar de suas mudanças locais de alguma | |
330 | forma e puxar de novo quando isso acontecer). | |
331 | ||
332 | Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando | |
333 | "fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo | |
334 | especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa | |
335 | que vale puxar, assim: | |
336 | ||
337 | ------------------------------------------------ | |
338 | alice$ git fetch /home/bob/myrepo master | |
339 | alice$ git log -p HEAD..FETCH_HEAD | |
340 | ------------------------------------------------ | |
341 | ||
342 | Esta operação é segura mesmo se Alice tem mudanças locais não gravadas. | |
343 | 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. | |
347 | ||
348 | Se Alice quer visualizar o que Bob fez desde que suas história | |
349 | ramificaram, ela pode disparar o seguinte comando: | |
350 | ||
351 | ------------------------------------------------ | |
352 | $ gitk HEAD..FETCH_HEAD | |
353 | ------------------------------------------------ | |
354 | ||
355 | Isto usar a mesma notação de intervaldo que vimos antes com 'git log'. | |
356 | ||
357 | Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela | |
358 | pode usar a forma com três pontos ao invés da forma com dois pontos: | |
359 | ||
360 | ------------------------------------------------ | |
361 | $ gitk HEAD...FETCH_HEAD | |
362 | ------------------------------------------------ | |
363 | ||
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". | |
368 | ||
369 | Por favor, note que essas notações de intervalo podem ser usadas tanto | |
370 | com gitk quanto com "git log". | |
371 | ||
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 | |
374 | tem alguma coisa que Alice precisa imediatamente, Alice pode optar por | |
375 | separar seu trabalho em progresso primeiro, fazer um "pull", e, então, | |
376 | finalmente, retomar seu trabalho em progresso em cima da história | |
377 | resultante. | |
378 | ||
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 | |
381 | repositório remoto antes de tudo, você pode fazê-lo mais facilmente: | |
382 | ||
383 | ------------------------------------------------ | |
384 | alice$ git remote add bob /home/bob/myrepo | |
385 | ------------------------------------------------ | |
386 | ||
387 | Com isso, Alice pode executar a primeira parte da operação "pull" usando | |
388 | o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo, | |
389 | usando: | |
390 | ||
391 | ------------------------------------- | |
392 | alice$ git fetch bob | |
393 | ------------------------------------- | |
394 | ||
395 | Diferente da forma longa, quando Alice obteve de Bob usando um | |
396 | 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: | |
398 | ||
399 | ------------------------------------- | |
400 | alice$ git log -p master..bob/master | |
401 | ------------------------------------- | |
402 | ||
403 | mostra uma lista de todas as mudanças que Bob fez desde que ramificou do | |
404 | ramo master de Alice. | |
405 | ||
406 | Após examinar essas mudanças, Alice pode unificá-las em seu ramo master: | |
407 | ||
408 | ------------------------------------- | |
409 | alice$ git merge bob/master | |
410 | ------------------------------------- | |
411 | ||
412 | Esse `merge` pode também ser feito puxando de seu próprio ramo remoto, | |
413 | assim: | |
414 | ||
415 | ------------------------------------- | |
416 | alice$ git pull . remotes/bob/master | |
417 | ------------------------------------- | |
418 | ||
419 | Note que 'git pull' sempre unifica ao ramo atual, independente do que | |
420 | mais foi dado na linha de comando. | |
421 | ||
422 | Depois, Bob pode atualizar seu repositório com as últimas mudanças de | |
423 | Alice, usando | |
424 | ||
425 | ------------------------------------- | |
426 | bob$ git pull | |
427 | ------------------------------------- | |
428 | ||
429 | Note que ele não precisa dar o caminho do repositório de Alice; quando | |
430 | 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 | |
432 | para puxar: | |
433 | ||
434 | ------------------------------------- | |
435 | bob$ git config --get remote.origin.url | |
436 | /home/alice/project | |
437 | ------------------------------------- | |
438 | ||
439 | (A configuração completa criada por 'git-clone' é visível usando `git | |
440 | config -l`, e a página de manual linkgit:git-config[1] explica o | |
441 | significado de cada opção.) | |
442 | ||
443 | Git também mantém uma cópia limpa do ramo master de Alice sob o nome | |
444 | "origin/master": | |
445 | ||
446 | ------------------------------------- | |
447 | bob$ git branch -r | |
448 | origin/master | |
449 | ------------------------------------- | |
450 | ||
451 | Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode | |
452 | executar clones e puxar usando o protocolo ssh: | |
453 | ||
454 | ------------------------------------- | |
455 | bob$ git clone alice.org:/home/alice/project myrepo | |
456 | ------------------------------------- | |
457 | ||
458 | Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou | |
459 | http; veja linkgit:git-pull[1] para detalhes. | |
460 | ||
461 | 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]. | |
464 | ||
465 | Explorando história | |
466 | ----------------- | |
467 | ||
468 | 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 | |
471 | dá o nome para o commit: | |
472 | ||
473 | ------------------------------------- | |
474 | $ git log | |
475 | commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 | |
476 | Author: Junio C Hamano <junkio@cox.net> | |
477 | Date: Tue May 16 17:18:22 2006 -0700 | |
478 | ||
479 | merge-base: Clarify the comments on post processing. | |
480 | ------------------------------------- | |
481 | ||
482 | Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este | |
483 | commit. | |
484 | ||
485 | ------------------------------------- | |
486 | $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 | |
487 | ------------------------------------- | |
488 | ||
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: | |
492 | ||
493 | ------------------------------------- | |
494 | $ git show c82a22c39c # os primeiros caracteres do nome são o bastante | |
495 | # usualmente | |
496 | $ git show HEAD # a ponta do ramo atual | |
497 | $ git show experimental # a ponta do ramo "experimental" | |
498 | ------------------------------------- | |
499 | ||
500 | Todo commit usualmente tem um commit "pai" que aponta para o estado | |
501 | anterior do projeto: | |
502 | ||
503 | ------------------------------------- | |
504 | $ git show HEAD^ # para ver o pai de HEAD | |
505 | $ git show HEAD^^ # para ver o avô de HEAD | |
506 | $ git show HEAD~4 # para ver o trisavô de HEAD | |
507 | ------------------------------------- | |
508 | ||
509 | Note que commits de unificação podem ter mais de um pai: | |
510 | ||
511 | ------------------------------------- | |
512 | $ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^) | |
513 | $ git show HEAD^2 # mostra o segundo pai de HEAD | |
514 | ------------------------------------- | |
515 | ||
516 | Você também pode dar aos commits nomes seus; após executar | |
517 | ||
518 | ------------------------------------- | |
519 | $ git tag v2.5 1b2e1d63ff | |
520 | ------------------------------------- | |
521 | ||
522 | você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende | |
523 | 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 | |
525 | assiná-lo; veja linkgit:git-tag[1] para detalhes. | |
526 | ||
527 | Qualquer comando git que precise conhecer um commit pode receber | |
528 | quaisquer desses nomes. Por exemplo: | |
529 | ||
530 | ------------------------------------- | |
531 | $ git diff v2.5 HEAD # compara o HEAD atual com v2.5 | |
532 | $ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado | |
533 | # em v2.5 | |
534 | $ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de | |
535 | # trabalho a seu estado em HEAD^ | |
536 | ------------------------------------- | |
537 | ||
538 | Seja cuidadoso com o último comando: além de perder quaisquer mudanças | |
539 | 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 | |
542 | publicamente visível de onde outros desenvolvedores puxam, já que vai | |
543 | forçar unificações desnecessárias para que outros desenvolvedores limpem | |
544 | a história. Se você precisa desfazer mudanças que você empurrou, use | |
545 | 'git-revert' no lugar. | |
546 | ||
547 | O comando 'git-grep' pode buscar strings em qualquer versão de seu | |
548 | projeto, então | |
549 | ||
550 | ------------------------------------- | |
551 | $ git grep "hello" v2.5 | |
552 | ------------------------------------- | |
553 | ||
554 | procura por todas as ocorreências de "hello" em v2.5. | |
555 | ||
556 | 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 | |
558 | ||
559 | ------------------------------------- | |
560 | $ git grep "hello" | |
561 | ------------------------------------- | |
562 | ||
563 | é uma forma rápida de buscar somente os arquivos que são rastreados pelo | |
564 | git. | |
565 | ||
566 | 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': | |
569 | ||
570 | ------------------------------------- | |
571 | $ git log v2.5..v2.6 # commits entre v2.5 e v2.6 | |
572 | $ git log v2.5.. # commits desde v2.5 | |
573 | $ git log --since="2 weeks ago" # commits das últimas 2 semanas | |
574 | $ git log v2.5.. Makefile # commits desde v2.5 que modificam | |
575 | # Makefile | |
576 | ------------------------------------- | |
577 | ||
578 | Você também pode dar ao 'git-log' um "intervalo" de commits onde o | |
579 | primeiro não é necessariamente um ancestral do segundo; por exemplo, se | |
580 | as pontas dos ramos "stable" e "master" divergiram de um commit | |
581 | comum algum tempo atrás, então | |
582 | ||
583 | ------------------------------------- | |
584 | $ git log stable..master | |
585 | ------------------------------------- | |
586 | ||
587 | irá listas os commits feitos no ramo "master" mas não no ramo | |
588 | "stable", enquanto | |
589 | ||
590 | ------------------------------------- | |
591 | $ git log master..stable | |
592 | ------------------------------------- | |
593 | ||
594 | irá listar a lista de commits feitos no ramo "stable" mas não no ramo | |
595 | "master". | |
596 | ||
597 | O comando 'git-log' tem uma fraquza: ele precisa mostrar os commits em | |
598 | uma lista. Quando a história tem linhas de desenvolvimento que | |
599 | divergiram e então foram unificadas novamente, a ordem em que 'git-log' | |
600 | apresenta essas mudanças é insignificante. | |
601 | ||
602 | 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, | |
605 | ||
606 | ------------------------------------- | |
607 | $ gitk --since="2 weeks ago" drivers/ | |
608 | ------------------------------------- | |
609 | ||
610 | permite você navegar em quaisquer commits desde as últimas duas semanas | |
611 | de commits que modificaram arquivos sob o diretório "drivers". (Nota: | |
612 | você pode ajustar as fontes do gitk segurando a tecla control enquanto | |
613 | pressiona "-" ou "+".) | |
614 | ||
615 | Finalmente, a maioria dos comandos que recebem nomes de arquivo | |
616 | te permitirão opcionalmente preceder qualquer nome de arquivo por um | |
617 | commit, para especificar uma versão particular do arquivo: | |
618 | ||
619 | ------------------------------------- | |
620 | $ git diff v2.5:Makefile HEAD:Makefile.in | |
621 | ------------------------------------- | |
622 | ||
623 | Você pode usar 'git-show' para ver tal arquivo: | |
624 | ||
625 | ------------------------------------- | |
626 | $ git show v2.5:Makefile | |
627 | ------------------------------------- | |
628 | ||
629 | Próximos passos | |
630 | ---------- | |
631 | ||
632 | Este tutorial deve ser o bastante para operar controle de revisão | |
633 | distribuído básico para seus projetos. No entanto, para entender | |
634 | plenamente a profundidade e o poder do git você precisa entender duas | |
635 | idéias simples nas quais ele se baseia: | |
636 | ||
637 | * A base de objetos é um sistema bem elegante usado para armazenar a | |
638 | história de seu projeto--arquivos, diretórios, e commits. | |
639 | ||
640 | * O arquivo de índica é um cache do estado de uma árvore de diretório, | |
641 | usado para criar commits, restaurar diretórios de trabalho, e | |
642 | compreender as várias árvores involvidas em uma unificação. | |
643 | ||
644 | Parte dois deste tutorial explica a base de objetos, o arquivo de | |
645 | índice, e algumas outras coisinhas que você vai precisar pra usar o | |
646 | máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7]. | |
647 | ||
648 | Se você não quer continuar do jeito certo, algumas outras disgressões | |
649 | que podem ser interessantes neste ponto são: | |
650 | ||
651 | * 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 | |
654 | enviados por email. | |
655 | ||
656 | * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma | |
657 | 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 | |
660 | busca próxima da ótima mesmo no caso de uma história complexa | |
661 | não-linear com muitos ramos unificados. | |
662 | ||
663 | * link:everyday.html[GIT diariamente com 20 e tantos comandos] | |
664 | ||
665 | * linkgit:gitcvs-migration[7]: Git para usuários de CVS. | |
666 | ||
667 | Veja Também | |
668 | -------- | |
669 | linkgit:gittutorial-2[7], | |
670 | linkgit:gitcvs-migration[7], | |
671 | linkgit:gitcore-tutorial[7], | |
672 | linkgit:gitglossary[7], | |
673 | linkgit:git-help[1], | |
674 | link:everyday.html[git diariamente], | |
675 | link:user-manual.html[O Manual do Usuário git] | |
676 | ||
677 | GIT | |
678 | --- | |
679 | Parte da suite linkgit:git[1]. |