Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.33.1 → 2.34.1 no changes
- 2.33.0 08/16/21
- 2.31.1 → 2.32.0 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.2 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.27.1 → 2.28.1 no changes
- 2.27.0 06/01/20
- 2.25.1 → 2.26.3 no changes
- 2.25.0 01/13/20
- 2.23.1 → 2.24.4 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.19.1 → 2.21.4 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.17.0 → 2.17.6 no changes
- 2.16.6 12/06/19
- 2.15.4 12/06/19
- 2.14.6 no changes
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.6.7 → 2.7.6 no changes
- 2.5.6 05/05/17
- 2.4.12 05/05/17
- 2.3.10 no changes
- 2.2.3 09/04/15
- 2.1.4 12/17/14
DESCRIÇÃO
Muitos comandos porcelana do Git utilizam uma mistura de opções (ou seja, parâmetros que começam com um traço -) e os parâmetros destinados ao comando git rev-list subjacente que eles utilizam internamente, as opções e os parâmetros para os outros comandos que utilizam na produção final do 'git rev-list '. Este comando é utilizado para se distinguir entre eles.
OPÇÕES
Modos de Operação
Cada uma destas opções deve aparecer primeiro na linha de comando.
- --parseopt
-
Utilize o comando git rev-parse no modo de análise de opções (consulte a seção "PARSEOPT" abaixo).
- --sq-quote
-
Utilize o comando git rev-parse em modo de citação shell (consulte a seção "SQ-QUOTE" abaixo). Ao contrário da opção
--sq
abaixo, este modo apenas cita. Nada mais é feito para comandar a entrada.
As opções para --parseopt
- --keep-dashdash
-
Apenas faz sentido no modo
--parseopt
. Informa ao analisador das opções para ecoar o primeiro--
encontrado em vez de ignorá-lo. - --stop-at-non-option
-
Apenas faz sentido no modo
--parseopt
. Permite que o analisador de opções pare no primeiro argumento sem opção. Pode ser usado para analisar os subcomandos que aceitam essas opções. - --stuck-long
-
Apenas faz sentido no modo
--parseopt
. Gere as opções em sua forma longa, caso estejam disponíveis, e com os seus argumentos bloqueados.
Opções para a Saída
- --default <arg>
-
Caso não haja nenhum parâmetro informado pelo usuário, em vez disso utilize
<arg>
. - --prefix <arg>
-
Comporte-se como se o comando git rev-parse fosse invocado no subdiretório
<arg>
da árvore de trabalho. Quaisquer nomes dos arquivos relativos são resolvidos como se fossem prefixados através do<arg>
e serão impressos neste formulário.Pode ser utilizado para converter os argumentos em um comando executado-o em um subdiretório para que eles ainda possam ser utilizados após a mudança para o nível mais alto do repositório. Por exemplo:
prefix=$(git rev-parse --show-prefix) cd "$(git rev-parse --show-toplevel)" # rev-parse provides the -- needed for 'set' eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
- --verify
-
Verifique que exatamente um parâmetro seja informado e se pode ser transformado em um SHA-1 com 20 bytes brutos, que possa ser utilizado para acessar o banco de dados do objeto. Em caso positivo, emita-o para a saída padrão; caso contrário, gere um erro.
Caso queira garantir que a saída realmente nomeie um objeto no banco de dados dos objetos e/ou possam ser utilizados como um tipo específico que você precisa, é possível adicionar o operador de remoção
^{type}
ao parâmetro. Por exemplo,git rev-parse" $VAR^{commit}"
garantirá que$VAR
nomeie um objeto já existente que seja um "commit-ish" (ou seja, um commit ou uma tag anotada que aponte para um commit). Para garantir que o '$VAR` nomeie um objeto já existente de qualquer tipo,git rev-parse "$VAR^{object}"
pode ser utilizado. - -q
- --quiet
-
Apenas faz sentido no modo
--verify
. Não produza uma mensagem de erro caso o primeiro argumento não for um nome válido do objeto; em vez disso, encerre com uma condição diferente de zero silenciosamente. O SHA-1 para os objetos com nomes válidos que são impressos com êxito no stdout. - --sq
-
Normalmente, a saída é feita uma linha por opção e parâmetro. Esta opção gera a saída em uma única linha, devidamente citada para utilização do shell. Útil quando você espera que o seu parâmetro contenha espaços e novas linhas (como, por exemplo, ao utilizar a picareta
S
com git diff-*). Ao contrário da opção--sq-quote
, a entrada do comando ainda é interpretada como de costume. - --short[=comprimento]
-
O mesmo que
--verify
porém encurta o nome do objeto para um prefixo único com pelo menos um`comprimento` determinado de caracteres. A quantidade mínima é de 4 caracteres, o valor é predefinido na variável de configuraçãocore.abbrev
(consulte git-config[1]). - --not
-
Ao exibir os nomes dos objetos, prefixe-os com ^ e retire o prefixo ^ dos nomes dos objetos que já possuam um.
- --abbrev-ref[=(strict|loose)]
-
Para um nome abreviado não ambíguo dos nomes dos objetos. A opção
core.warnAmbiguousRefs
é utilizada para selecionar o modo estrito da abreviação. - --symbolic
-
Normalmente, os nomes dos objetos são emitidos em formato SHA-1 (com possível prefixo ^); essa opção faz com que eles sejam impressos o mais próximo possíveis da entrada original.
- --symbolic-full-name
-
É semelhante ao
--symbolic
, porém omite a entrada que não seja uma refs (como, por exemplo, os nomes dos ramos ou tags; ou de uma forma explicitamente desambiguante "heads/master", quando você quer nomear a o ramo "master" quando houver uma tag com o nome "master") e mostre-os como "refnames" completos (como, por exemplo, "refs/heads/master").
Opções para os Objetos
- --all
-
Exibe todas as refs encontradas em
refs/
. - --branches[=pattern]
- --tags[=padrão]
- --remotes[=padrão]
-
Exibe todos as ramificações, tags ou ramificações monitoradas remotamente, respectivamente (ou seja, as refs encontradas respectivamente em
refs/heads
,refs/tags
ourefs/remotes
).Caso um
padrão
seja informado, apenas as refs coincidentes com o "shell glob" são exibidos. Caso o padrão não contenha um caractere curinga (?
,*
ou[
), este será transformado em um prefixo correspondente ao acrescentar/*
. - --glob=pattern
-
Exiba todos os árbitros que coincidam com o
padrão
(pattern) do "glob". Caso o padrão não comece comrefs /
, isto será anexado automaticamente. Caso o padrão não contenha um caractere curinga (?
,*
ou[
), este será transformado em um prefixo correspondente ao acrescentar/*
. - --exclude=<glob-pattern>
-
Não inclua as refs que coincidam com
<glob-pattern>
em que as próximas opções--all
,--branches
,--tags
,--remotes
ou--glob
considerariam de outra forma. As repetições destas opções acumulam padrões de exclusão até a próxima opção--all
,--branches
,--tags
,--remotes
ou--glob
(outras opções ou argumentos não limpam os padrões acumulados).Os padrões informados não devem começar com
refs/heads
,refs/tags
, ourefs/remotes
quando aplicadas as opções--branches
,--tags
, ou--remotes
respectivamente, e devem começar comrefs/
quando for aplicado ao--glob
ou--all
. Se a intenção for um delimitador /{asterisco}, este deve ser utilizado de forma explicita. - --disambiguate=<prefixo>
-
Exiba todos os objetos cujo nome começa com o prefixo informado. O
<prefixo>
deve ter pelo menos 4 dígitos hexadecimais para evitar ter que listar por engano todos os objetos no repositório.
Opções para os Arquivos
- --local-env-vars
-
Liste as variável de ambiente do GIT_* que são locais no repositório (
GIT_DIR
ouGIT_WORK_TREE
, mas não oGIT_EDITOR
por exemplo). Somente os nomes das variáveis são listadas, não o seu valor, mesmo que estejam definidos. - --git-dir
-
Exibe o
$GIT_DIR
caso seja definido. Caso contrário, exibe o caminho para o diretório .git. O caminho exibido, quando relativo, é relativo ao diretório de trabalho atual.Caso o
$GIT_DIR
não esteja definido e o diretório atual não for detectado como estando em um repositório Git ou na árvore de trabalho, imprima uma mensagem para stderr e encere com uma condição diferente de zero. - --absolute-git-dir
-
Como
--git-dir
, porém sua saída é sempre o caminho absoluto canonizado. - --git-common-dir
-
Exibe o
$GIT_COMMON_DIR
caso seja definido, senão$GIT_DIR
. - --is-inside-git-dir
-
Quando o diretório de trabalho atual estiver abaixo do diretório do repositório, imprima true, caso contrário, false.
- --is-inside-work-tree
-
Quando o diretório de trabalho atual estiver dentro da árvore de trabalho do repositório, imprima true, caso contrário, false.
- --is-bare-repository
-
Quando o repositório for simples imprima true, caso contrário false.
- --is-shallow-repository
-
Quando o repositório é raso, imprima true, caso contrário, false.
- --resolve-git-dir <caminho>
-
Verifique se o <caminho> é um repositório válido ou um gitfile que aponte para um repositório válido e imprima o local do repositório. Caso o <caminho> seja um gitfile, o caminho resolvido para o repositório real será impresso.
- --git-path <caminho>
-
Resolva "$GIT_DIR/<caminho>" e leve em consideração as outras variáveis de realocação do caminho, como
$GIT_OBJECT_DIRECTORY
,$GIT_INDEX_FILE
, etc. Caso$GIT_OBJECT_DIRECTORY
seja definido para /foo/bar por exemplo, então o comando "git rev-parse --git-path objects/abc" returna /foo/bar/abc. - --show-cdup
-
Quando o comando é chamado a partir de um subdiretório, exiba o caminho do diretório do nível mais alto em relação ao diretório atual (geralmente uma sequência de "../" ou uma sequência vazia).
- --show-prefix
-
Quando o comando é invocado a partir de um subdiretório, exiba o caminho do diretório atual em relação ao nível mais alto do diretório.
- --show-toplevel
-
Exibe o caminho absoluto do diretório no nível mais da árvore de trabalho. Caso não haja uma árvore em funcionamento, relate um erro.
- --show-superproject-working-tree
-
Exibe o caminho absoluto da raiz da árvore de trabalho do superprojeto (caso exista) que usa o repositório atual como sendo o seu submódulo. Não produz nada caso o repositório atual não eja usado como um submódulo por nenhum projeto.
-
Exibe o caminho para o arquivo do índice compartilhado no modo de índice dividido ou vazio caso não esteja no modo do índice dividido.
- --show-object-format[=(storage|input|output)]
-
Exiba o formato do objeto (algoritmo hash) usado no repositório para o armazenamento dentro do diretório
.git
, entrada ou saída. Para a entrada, vários algoritmos podem ser impressos, separados por espaço. Caso não seja definido, a predefinição retorna para "storage".
Outras Opções
- --since=datestring
- --after=datestring
-
Analise a cadeia de caracteres da data e exiba o parâmetro --max-age= correspondente para git rev-list.
- --until=datestring
- --before=datestring
-
Analise a cadeia de caracteres da data e exiba o parâmetro
--max-age=
que corresponda para o git rev-list. - <args>…
-
As opções e os parâmetros que serão analisados.
DEFININDO AS REVISÕES
Um parâmetro de revisão <rev> normalmente, mas não necessariamente, dá nome a um objeto commit. Utiliza o que é chamado de uma sintaxe extended SHA-1. Aqui estão as várias maneiras de soletrar os nomes dos objetos. Os listados próximos do final desta lista informam árvores e gotas existentes em um commit.
Note
|
Este documento demonstra a sintaxe "bruta" como vista pelo git. O shell e outras UIs podem exigir citações adicionais para proteger os caracteres especiais e evitar a divisão de palavras. |
- <sha1>, exemplo. dae86e1950b1277e545cee180551750029cfe735, dae86e
-
O nome completo do objeto SHA-1 (a sequência hexadecimal com 40-bytes) ou uma carreira de caracteres que é exclusiva e única no repositório. Por exemplo, dae86e1950b1277e545cee180551750029cfe735 e dae86e informam o mesmo objeto commit caso não haja um outro objeto em seu repositório cujo nome comece com daee.
- <describeOutput>, exemplo. v1.7.4.2-679-g3bee7fb
-
A saída do
git describe
; ou seja, um tag mais próximo opcionalmente seguido por um traço e um número do commit seguido por um traço, um g e um nome abreviado do objeto. - <refname>, exemplo. master, heads/master, refs/heads/master
-
Um nome simbólico
ref
. master por exemplo, significa que o objeto de commit tem referência com refs/heads/master. Caso aconteça de haver ambos os heads/master ou tags/master, você pode explicitamente usar heads/master para informar o Git qual deles quer. Quando ambíguo, um <refname> que desperte dúvidas é interpretado através da primeira coincidência de acordo com as seguintes regras:-
Caso $GIT_DIR/<refname> exista, quando é isso o que você quer dizer (geralmente é apenas útil para
HEAD
,FETCH_HEAD
,ORIG_HEAD
,MERGE_HEAD
eCHERRY_PICK_HEAD
); -
caso contrário, utilize refs/<refname> caso exista;
-
caso contrário, utilize refs/tags/<refname> caso exista;
-
caso contrário, utilize refs/heads/<refname> caso exista;
-
caso contrário, utilize refs/remotes/<refname> caso exista;
-
caso contrário, utilize refs/remotes/<refname>/HEAD caso exista.
HEAD
informa o commit no qual você teve como base as alterações na árvore de trabalho.FETCH_HEAD
registra em qual ramo você buscou no repositório remoto com a sua última invocaçãogit fetch
.ORIG_HEAD
é criado por comandos que movem seu` HEAD` de uma maneira drástica, para registrar a posição doHEAD
antes da sua operação, para que você possa facilmente mudar a ponta do ramo de volta ao estado anterior a sua execução.MERGE_HEAD
registra os commits que você está mesclando no seu ramo quando você executa o comandogit merge
.CHERRY_PICK_HEAD
registra o commit que você está escolhendo quando executa o comandogit cherry-pick
.Observe que em qualquer um dos casos o refs/* acima pode vir do diretório
$GIT_DIR/refs
ou do arquivo`$GIT_DIR/packed-refs`. Embora a codificação do nome de referência não seja especificado, o UTF-8 é o predefinido pois algum processamento de saída pode assumir nomesref
em UTF-8.
-
- @
-
O @ sozinho é um atalho para
HEAD
. - [<refname>]@{<data>}, exemplo. master@{yesterday}, HEAD@{5 minutos atrás}
-
Uma "ref" seguida por um sufixo @ com uma especificação ordinal incluída em um par de chaves (exemplo. {ontem}, {1 mês 2 semanas 3 dias 1 hora 1 segundo atrás} ou {1979-02-26 18:30:00}) determina o valor da "ref" em um momento anterior. Esse sufixo pode ser utilizado imediatamente após um nome "ref" e a "ref" deve ter um registro log que já exista ($GIT_DIR/logs/<ref>). Observe que em um determinado momento a condição geral da sua "ref" local será consultada ; o que estava no seu ramo master na semana passada por exemplo. Caso queira ver quais os commits foram feitos durante determinados períodos de tempo, consulte
--since
e--until
. - <refname>@{<n>}, e.g. master@{1}
-
Uma "ref" seguida pelo sufixo @ com uma especificação ordinal incluída em um par de chaves (exemplo, {1}, {15}) especifica o enésimo valor anterior desta "ref". Por exemplo, master@{1} é o valor anterior imediato de master, enquanto master@{5} é o quinto valor anterior do master. Este sufixo poderá ser utilizado imediatamente após um nome "ref" e o mesmo deve ter um registro log já existente em ($GIT_DIR/logs/<refname>).
- @{<n>}, exemplo. @{1}
-
Você pode usar a construção @ com um
ref
vazio para obter uma entradareflog
do ramo atual. Por exemplo, caso esteja no ramo blabla então @{1} significa o mesmo que blabla@{1}. - @{-<n>}, exemplo, @{-1}
-
O construtor @{-<n>} significa que <n> do ramo/commit foi verificado antes da atual.
- [<nome-do-ramo>]@{upstream}, exemplo, master@{upstream}, @{u}
-
O sufixo @ {upstream} para o nome de uma ramificação (o formato abreviado <nome-do-ramo>@{u}) refere-se ao ramo onde o ramo informado pelo "branchname" esteja definido para construir em cima do
branch.<nome>.remote
ebranch.<nome>.merge
). Em uma ramificação desaparecida a predefinição retorna para a atual. Estes sufixos também são aceitos quando digitados em maiúsculas e significam a mesma coisa, não importa o caso. - [<nome-do-ramo>]@{push}, exemplo, master@{push}, @{push}
-
O sufixo @{push} relata ao ramo "para onde estaremos fazendo impulsionamento" caso
git push
seja executado enquantobranchname
seja verificado (ou oHEAD
atual, caso nenhum nome do ramo tenha sido especificado). Como o nosso impulsionamento foi feito em um repositório remoto, é claro, relatamos o ramo de rastreamento local que tenha correspondência a esse ramo (ou seja, algo emrefs/remotes/
).Aqui um exemplo para deixar mais claro:
$ git config push.default current $ git config remote.pushdefault myfork $ git switch -c mybranch origin/master $ git rev-parse --symbolic-full-name @{upstream} refs/remotes/origin/master $ git rev-parse --symbolic-full-name @{push} refs/remotes/myfork/mybranch
Observe no exemplo que configuramos um fluxo de trabalho triangular, onde fazemos o
pull
(obtenção) de um local e opush
(impulsionamento) para outro. Em um fluxo de trabalho não triangular, o @{push} é igual como o @{upstream} que não é necessário.Esse sufixo também é aceito quando escrito em maiúsculas e significa a mesma coisa, não importa o caso.
- <rev>^[<n>], exemplo, HEAD^, v1.5.1^0
-
Um sufixo ^ para um parâmetro de revisão significa que a primeira origem deste objeto commit. ^<n> significa que é a quantidade <n> da origem (ou seja, <rev>^ é equivamente a <rev>^1). Como regra especial, <rev>^0 significa o commit em si e é utilizado quando <rev> for o nome do objeto de um objeto
tag
que tenha referência a um objeto de commit. - <rev>~[<n>], exemplo, HEAD~, master~3
-
Um sufixo ~ para um parâmetro de revisão significa o que a primeira origem deste objeto commit. Um sufixo ~<n> para um parâmetro de revisão significa que o objeto commit é o <n> do ancestral da geração do objeto commit informado, seguindo apenas os primeiras origens. Ou seja, <rev>~3 é equivalente a <rev>^^^ que é equivalente a <rev>^1^1^1. Veja abaixo uma ilustração do uso deste formato.
- <rev>^{<type>}, exemplo, v0.99.8^{commit}
-
Um sufixo ^ seguido por um tipo de objeto com nome fechado entre chaves significa remover a referência do objeto em <ref> recursivamente até que um objeto do tipo <type> seja encontrado ou não seja mais possível remover a referência do (nesse caso,
barf
). Por exemplo, caso <ref> seja um commit ish, <rev>^{commit} descreve o objeto commit correspondente. Da mesma forma caso <re> seja um ish da árvore <rev>^{tree}, descreve o objeto da árvore correspondente. <rev>^0 é um atalho para <rev>^{commit}.<rev>^{object} pode ser utilizado para ter certeza que os nomes <rev> de um determinado objeto existam, sem requerer que <rev> seja uma tag e sem perder a referência com <rev>; pois
tag
já é um objeto, não a necessidade que seja perdido a referência nenhuma vez para chegar a um objeto.<rev>^{tag} pode ser utilizado para ter certeza que <rev> identifique um objeto
tag
já existente. - <rev>^{}, exemplo, v0.99.8^{}
-
Um sufixo ^ seguido por um par de chaves vazias significa que o objeto pode ser uma tag e perder a referência de uma tag recursivamente, até que um objeto que não seja tag, seja encontrada.
- <rev>^{/<texto>}, exemplo, HEAD^{/fix nasty bug}
-
Um sufixo ^ para um parâmetro de revisão, seguido por um par de chaves que contém um texto liderado por uma barra, é o mesmo que a sintaxe :/fix nasty bug abaixo, exceto que ele retorna o commit coincidente mais jovem que é acessível a partir de <rev> antes de ^.
- :/<texto>, exemplo, :/fix nasty bug
-
Da nome a um commit aqueles que forem seguidos por um traço e por um texto, e a mensagem de commit coincidir à expressão regular especificada. Esse nome retorna o commit coincidente mais jovem, acessível a partir de qualquer referência, incluindo
HEAD
. A expressão regular pode corresponder a qualquer parte da mensagem do commit. Para coincidir mensagens que comecem com uma string, pode-se utilizar :/^foo por exemplo. A sequência especial : /! está reservada para modificadores que tenham coincidências. :/!-foo executa uma coincidência negativa, enquanto :/!!foo coincide com um caractere literal !, seguido por foo. No momento, qualquer outra sequência começando com :/! está reservada. Dependendo do texto informado, as regras de divisão de palavras do shell podem exigir citações adicionais. - <rev>:<caminho>, exemplo, HEAD:README, master:./README
-
Um sufixo : seguido de um caminho nomeia a gota ou a árvore no caminho especificado no objeto da árvore "ish" informado pela parte antes dos dois pontos. Um caminho começando com ./ ou ../ é relativo ao diretório de trabalho atual. O caminho especificado será convertido para ser relativo ao diretório raiz da árvore de trabalho. Isso é mais útil para abordar uma gota ou árvore de um commit ou uma árvore que tenha a mesma estrutura de árvore que uma árvore de trabalho.
- :[<n>:]<caminho>, exemplo, :0:README, :README
-
Os dois pontos opcionalmente seguidos por um número de estágio (0 para 3) e dois pontos, seguidos por um caminho, informam um objeto gota no índice no caminho especificado. Nomeia uma entrada de estágio quando o número estiver ausente (assim como dois pontos que o seguem). Durante uma mesclagem, o estágio 1 é o ancestral comum, o estágio 2 é a versão do ramo de destino (normalmente o ramo atual) e o estágio 3 é a versão do ramo que está sendo mesclado.
Aqui está uma ilustração, de Jon Loeliger. Ambos os nós do commit B e C são as origens dos nós do commit A. Os commits da origem são ordenados da esquerda para a direita.
G H I J \ / \ / D E F \ | / \ \ | / | \|/ | B C \ / \ / A
A = = A^0 B = A^ = A^1 = A~1 C = = A^2 D = A^^ = A^1^1 = A~2 E = B^2 = A^^2 F = B^3 = A^^3 G = A^^^ = A^1^1^1 = A~3 H = D^2 = B^^2 = A^^^2 = A~2^2 I = F^ = B^3^ = A^^3^ J = F^2 = B^3^2 = A^^3^2
DEFININDO OS INTERVALOS
O histórico que atravessa os comandos como o git log
opera em um
determinado conjunto de commits e não apenas em único commit.
Para estes comandos, defina uma única revisão utilizando a notação descrita
na seção anterior, significa que o conjunto dos commits acessíveis
a
partir do commit informado.
O conjunto acessível de um commit é o próprio commit e o commit em sua cadeia de ancestrais.
Notações do Intervalo Pontilhado
- A faixa de notação de intervalo .. (dois pontos)
-
A operação do conjunto ^r1 r2 aparece com tanta frequência que existe uma abreviação para isso. Quando você tem dois commits r1 e r2 (nomeados de acordo com a sintaxe explicada em ESPECIFICANDO REVISÕES acima), você pode solicitar os commits que sejam acessíveis atraés do r2 excluindo aqueles que podem ser acessados através do r1 pelo ^r1 r2 e podem ser escritos como r1..r2.
- A notação da diferença simétrica … (três pontos)
-
Uma notação semelhante r1...r2 é chamada de uma diferença simétrica de r1 e r2 sendo definida como r1 r2 --not $(git merge-base --all r1 r2). É o conjunto dos commits que são acessíveis a partir do r1 (lado esquerdo) ou r2 (lado direito), porém, não de ambos.
Nestas duas notações abreviadas, é possível omitir uma extremidade e
deixá-la como predefinido no HEAD
. Como por exemplo, origin.. é uma
abreviação de origin..HEAD e pergunta "O que eu fiz desde que peguei a
bifurcação no ramo de origem?" Da mesma forma, ..origin é uma abreviação
de HEAD..origin e pergunta "O que a origem fez desde que eu as peguei?"
Observe que .. significaria HEAD..HEAD, que é um intervalo vazio
acessível e inacessível a partir do HEAD
.
Outras <rev>^ Notações Abreviadas dos pais
Existem três outras abreviações, particularmente úteis para a mesclagem dos commits, para nomear um conjunto formado por um commit e o seu pai principal.
A notação r1^@ todos os pais do r1.
A notação r1^! (cursor) inclui o commit r1, mas exclui todos as suas origens. Por si só, essa notação denota o único commit r1.
A notação <rev>^-[<n>] incluí <rev> porém excluí o <n>ésimo pai (ou seja, é uma abreviação para <rev>^<n>..<rev>), com <n> = 1 caso não seja informado. Geralmente é útil para a mesclagem dos commits onde é possível passar <commit>^- para obter todos os commits do ramoq que foi mesclado na mesclagem do commit <commit> (incluindo o próprio <commit>).
Embora <rev>^<n> fosse sobre a especificação do pai de um único commit, estas três notações também consideram os seus pais. Como por exemplo, você pode dizer HEAD^2^@, contudo não poderá dizer HEAD^@^2.
Resumo do Intervalo da Revisão
- <rev>
-
Inclua os commits que são acessíveis através do <ref> (ou seja, <rev> e seus ancestrais).
- ^<rev>
-
Exclua os commits que estejam acessíveis de
<rev>
(<rev> e seus ancestrais por exemplo). - <rev1>..<rev2>
-
Inclua os commits acessíveis a partir do <rev2>, porém exclua aquelas acessíveis a partir do <rev1>. Quando <rev1> ou <rev2> for omitido, a predefinição retorna para
HEAD
. - <rev1>...<rev2>
-
Incluí os commits que sejam acessíveis seja de <rev1> ou <rev2> porém exclua aqueles que sejam acessíveis de ambos. Quando <rev1> ou <rev2> for omitido, a predefinição retorna para
HEAD
. - <rev>^@, e.g. HEAD^@
-
Um sufixo ^ seguido por um sinal de arroba é o mesmo que listar todas as origens de <rev> (ou seja, incluir qualquer coisa acessível das suas origens, mas não o próprio commit).
- <rev>^!, e.g. HEAD^!
-
Um sufixo ^ seguido de um ponto de exclamação é o mesmo que fazer um commit <rev> e em seguida, todos as suas origens prefixam com ^ para excluí-los (assim como seus ancestrais).
- <rev>^-<n>, e.g. HEAD^-, HEAD^-2
-
É o equivalente a <rev>^<n>..<rev>, with <n> = 1 caso nenhum seja informado.
Aqui estão alguns exemplos utilizando a ilustração Loeliger acima, com cada etapa da expansão e da seleção da notação cuidadosamente explicitada:
Args Expanded arguments Selected commits D G H D D F G H I J D F ^G D H D ^D B E I J F B ^D B C E I J F B C C I J F C B..C = ^B C C B...C = B ^F C G H D E B C B^- = B^..B = ^B^1 B E I J F B C^@ = C^1 = F I J F B^@ = B^1 B^2 B^3 = D E F D G H E F I J C^! = C ^C^@ = C ^C^1 = C ^F C B^! = B ^B^@ = B ^B^1 ^B^2 ^B^3 = B ^D ^E ^F B F^! D = F ^I ^J D G H D F
PARSEOPT
No modo --parseopt
, o comando git rev-parse ajuda no processamento das
opções trazendo aos scripts shell as mesmas facilidades integradas que o C
possuí. Funciona como um normalizador das opções (como por exemplo, divide
trocas únicas com valores agregados), quase como o que o getopt(1)
faz.
Ele assume na entrada padrão a definição das opções para analisar e
entender, e ecoa na saída uma sequência adequada para o sh(1)
eval
para
substituir os argumentos por argumentos normalizados. Em caso de erro, ele
gera a utilização do fluxo de erros predefinidos e encerra com o código 129.
Observação: Certifique-se de citar o resultado ao encaminhá-lo para o
eval
. Consulte um exemplo abaixo.
Formato de Entrada
O formato da entrada do comando git rev-parse --parseopt é texto
puro. Possui duas partes, separadas por uma linha que contém apenas --
. As
linhas antes do separador (devem ser uma ou mais) são utilizadas para o
uso. As linhas após o separador definem as opções.
As opções de cada linha possui este formato:
<opt-spec><flags>*<arg-hint>? SP+ help LF
-
<opt-spec>
-
o seu formato é o caractere curto da opção e, em seguida, o nome da opção longa, separado por vírgula. Ambas as partes não são necessárias, embora pelo menos uma seja necessária. Não pode conter nenhum dos caracteres
<flags>
.h,help
,dry-run
ef
são exemplos corretos do<opt-spec>
. -
<flags>
-
<flags>
são do*
,=
,?
ou!
.-
Utilize
=
caso a opção receba um argumento. -
Utilize
?
para dar sentido que a opção aceita um argumento opcional. Você provavelmente quer utilzar o modo--stuck-long
para poder analisar de forma inequívoca o argumento opcional. -
Utilize
*
para indicar que esta opção não deve ser listada no uso gerado para a opção-h
. É exibido para--help-all
conforme documentado em gitcli[7]. -
Utilize
!
para não fazer com que a opção longa que foi negada esteja disponível.
-
-
<arg-hint>
-
Caso
<arg-hint>
seja definido, é usado como um nome do argumento na saída da ajuda, para as opções que aceitem os argumentos. O<arg-hint>
é finalizado através do primeiro espaço. É habitual utilizar um traço para separar as palavras em uma dica de um argumento com várias palavras.
O restante da linha, depois dos espaços removidos, é usado como ajuda associada à opção.
As linhas em branco são ignoradas e as linhas que não coincidam com esta especificação são utilizadas como cabeçalhos dos grupos das opções (inicie a linha com um espaço para criar essas linhas de propósito).
Exemplo
OPTS_SPEC="\ algum-comando [<opções>] <args>... algum-comando faz 'foo' e 'bar'! -- h,help exibe a ajuda foo alguma opção bonita --foo bar= alguma opção bacana --bar com um argumento baz=arg outra opção bacana --baz com um argumento definido qux?path qux talvez tenha um caminho como argumento porém significa ele mesmo Um cabeçalho do grupo de opções C? opção 'C' com um argumento opcional" eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
Texto de uso
Quando "$@"
is -h
ou --help
no exemplo acima, o seguinte texto de
utilização será exibido:
utilização: algum-comando [<opções>] <args>... algum-comando faz 'foo' e 'bar'! -h, --help exibe a ajuda --foo alguma opção bacana --foo --bar ... alguma opção legal --bar com um argumento --baz <arg> outra opção legal --baz com um determinado argumento --qux[=<caminho>] o qux pode utilizar um argumento para o caminho mas significa ele mesmo Um cabeçalho do grupo de opções -C[...] opção C com um argumento opcional
SQ-QUOTE
No modo --sq-quote
, o comando git rev-parse ecoa na saída padrão uma
única linha adequada para sh (1)
eval
. Esta linha é feita normalizando
os argumentos após a opção --sq-quote
. Nada mais é feito além de citar os
argumentos.
Caso queira que o comando de entrada ainda seja interpretada como de costume
pelo comando git rev-parse
antes da saída ser citada pela shell, consulte
a opção --sq
.
EXEMPLOS
-
Imprima o nome do objeto do commit atual:
$ git rev-parse --verify HEAD
-
Imprima o nome do objeto do commit a partir da revisão na variável shell $REV:
$ git rev-parse --verify $REV^{commit}
Isso causará um erro caso $REV esteja vazio ou não seja uma revisão válida.
-
Semelhante ao acima:
$ git rev-parse --default master --verify $REV
porém caso $REV esteja vazia, o nome do objeto do commit vindo do "master" será impresso.
GIT
Parte do conjunto git[1]