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.46.1 → 2.47.1 no changes
- 2.46.0 07/29/24
- 2.45.1 → 2.45.2 no changes
- 2.45.0 04/29/24
- 2.44.1 → 2.44.2 no changes
- 2.44.0 02/23/24
- 2.43.1 → 2.43.5 no changes
- 2.43.0 11/20/23
- 2.42.1 → 2.42.3 no changes
- 2.42.0 08/21/23
- 2.41.1 → 2.41.2 no changes
- 2.41.0 06/01/23
- 2.39.4 → 2.40.3 no changes
- 2.39.3 04/17/23
- 2.39.1 → 2.39.2 no changes
- 2.39.0 12/12/22
- 2.37.3 → 2.38.5 no changes
- 2.37.2 08/11/22
- 2.33.1 → 2.37.1 no changes
- 2.33.0 08/16/21
- 2.31.1 → 2.32.7 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 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
- 2.0.5 12/17/14
DESCRIÇÃO
Many Git porcelainish commands take a mixture of flags (i.e. parameters that begin with a dash -) and parameters meant for the underlying git rev-list command they use internally and flags and parameters for the other commands they use downstream of git rev-list. The primary purpose of this command is to allow calling programs to distinguish between them. There are a few other operation modes that have nothing to do with the above "help parse command line options".
Unless otherwise specified, most of the options and operation modes require you to run this command inside a git repository or a working tree that is under the control of a git repository, and will give you a fatal error otherwise.
OPÇÕES
Modos de Operação
Cada uma destas opções deve aparecer primeiro na linha de comando.
- --parseopt
-
Use git rev-parse in option parsing mode (see PARSEOPT section below). The command in this mode can be used outside a repository or a working tree controlled by a repository.
- --sq-quote
-
Use git rev-parse in shell quoting mode (see SQ-QUOTE section below). In contrast to the
--sq
option below, this mode only does quoting. Nothing else is done to command input. The command in this mode can be used outside a repository or a working tree controlled by a repository.
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 que não seja uma opção. Isto pode ser utilizado para analisar os subcomandos que recebem as 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>
-
Comporta-se como se o comando
git rev-parse
fosse invocado a partir do subdiretório<arg>
da árvore de trabalho. Quaisquer nomes de arquivos relativos são resolvidos como se fossem prefixados pelo<arg>
e serão impressos desta maneira.Isso pode ser usado para converter argumentos num comando executado num subdiretório, de modo que eles ainda possam ser utilizados após a alteração 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 num 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 ter certeza que o resultado realmente nomeia um objeto em seu banco de dados de objetos e/ou pode ser usado como um tipo específico e necessário do objeto, você pode adicionar o operador
^{type}
ao parâmetro. Por exemplo, comandogit rev-parse "$VAR^{commit}"
garantirá que$VAR
nomeie um objeto já existente que seja um "commit-ish" (ou seja, um commit ou uma etiqueta anotada que aponte para um commit). Para garantir que$VAR
nomeie um objeto existente de qualquer tipo, é possível usar o comandogit rev-parse "$VAR^{object}"
.Note que se você estiver verificando um nome de uma fonte não confiável, é prudente usar a opção
--end-of-options
para que o argumento relacionado ao nome não seja confundido com uma outra opção. - -q
- --quiet
-
Apenas faz sentido no modo
--verify
. Não emita uma mensagem de erro se o primeiro argumento não for um nome de objeto válido; em vez disso, saia silenciosamente com status diferente de zero. O SHA-1 para nomes válidos dos objetos são impressos no stdout quando for bem-sucedido. - --sq
-
Normalmente, a saída é feita numa linha por opção e por parâmetro. Esta opção torna a saída numa única linha, devidamente citada para uso do shell. Útil quando você espera que o seu parâmetro tenha espaços em branco e novas linhas (por exemplo, ao usar o pickaxe
-S
com o comando git diff-*). Em contraste com a opção--sq-quote
, a entrada do comando ainda é interpretada como de costume. - --short[=<length>]
-
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)]
-
Um nome curto não ambíguo do nome do objeto. A opção
core.warnAmbiguousRefs
é usada para selecionar o modo de abreviação estrita. - --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 (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 (por exemplo, "refs/heads/master"). - --output-object-format=(sha1|sha256|storage)
-
Allow oids to be input from any object format that the current repository supports.
Specifying "sha1" translates if necessary and returns a sha1 oid.
Specifying "sha256" translates if necessary and returns a sha256 oid.
Specifying "storage" translates if necessary and returns an oid in encoded in the storage hash algorithm.
Opções para os Objetos
- --all
-
Exibe todas as refs encontradas em
refs/
. - --branches[=<padrão>]
- --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
).Se um
pattern
for fornecido, somente as refs que correspondam a bolha do shell informado serão exibidos. Se o padrão não possuir um caractere de globbing (?
,*
ou[
), ele será transformado numa correspondência do prefixo com a adição de/*
. - --glob=<pattern>
-
Mostra todas as refs que correspondem ao padrão da bolha do shell
pattern
. Se o padrão não começar comrefs/
, ele será automaticamente anexado. Se o padrão não possuir um caractere de globbing (?
,*
ou[
), ele será transformado numa correspondência do prefixo com a adição de/*
. - --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 /*, este deve ser utilizado de forma explicita. -
Não inclua refs que seriam ocultados por
git-fetch
,git-receive-pack
ougit-upload-pack
durante a consulta da configuração apropriada defetch.hideRefs
,receive.hideRefs
ouuploadpack.hideRefs
junto comtransfer.hideRefs
(consulte git-config[1]). Esta opção afeta a próxima opção pseudo-ref--all
ou--glob
e é zerada após o processamento. - --disambiguate=<prefixo>
-
Mostra todos os objetos cujo nome começa com o prefixo informado. O <prefixo> deve ter pelo menos 4 dígitos hexadecimais para evitar a listagem de todos os objetos do repositório por engano.
Opções para os Arquivos
- --local-env-vars
-
Liste as variáveis de ambiente GIT_* que são locais para o repositório (por exemplo,
GIT_DIR
ouGIT_WORK_TREE
, mas nãoGIT_EDITOR
). Somente os nomes das variáveis são listados, não seus valores, ainda que estejam definidos. - --path-format=(absolute|relative)
-
Controla o comportamento de algumas outras opções. Se usado como absoluto, os caminhos impressos por estas opções serão absolutos e canônicos. Se usado como relativo, os caminhos serão relativos ao diretório de trabalho atual, quando isso for possível. A predefinição é específica da opção.
Esta opção pode ser usada várias vezes e afeta apenas os argumentos seguintes na linha de comando, seja no final da linha de comando ou na próxima instância desta opção.
As seguintes opções são modificadas pela opção --path-format
:
- --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 num repositório Git ou na árvore de trabalho, imprima uma mensagem para stderr e encere com uma condição diferente de zero. - --git-common-dir
-
Exibe o
$GIT_COMMON_DIR
caso seja definido, senão$GIT_DIR
. - --resolve-git-dir <caminho>
-
Verifica se o <caminho> é um repositório válido ou um arquivo git que aponte para um repositório válido e imprima o local do repositório. Quando o <caminho> for um arquivo git, 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-toplevel
-
Mostra o caminho (absoluto) do cume do diretório da árvore de trabalho. Caso não haja uma árvore de trabalho, relate um erro.
- --show-superproject-working-tree
-
Mostra o caminho absoluto da raiz da árvore de trabalho do superprojeto (quando houver) que use o repositório atual como seu submódulo. Não produz nada se o repositório atual não for 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.
As seguintes opções não são afetadas pela opção --path-format
:
- --absolute-git-dir
-
Como
--git-dir
, porém sua saída é sempre o caminho absoluto canonizado. - --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.
- --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-object-format[=(storage|input|output)]
-
Mostra o formato do objeto (algoritmo de hash) usado para o repositório para armazenamento dentro do diretório
.git
, entrada ou saída. Para a entrada, os vários algoritmos podem ser impressos, separados por espaço. Se não for especificado, a predefinição serástorage
. - --show-ref-format
-
Mostra o formato da referência de armazenamento usado para o repositório.
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 --min-age= que corresponda para o git rev-list.
- <arg>…
-
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, nomeia um objeto commit. Ele usa o que é chamado de sintaxe SHA-1 estendido. Aqui estão várias maneiras de soletrar os nomes dos objetos. Os listados perto do final desta lista nomeiam as árvores e as bolhas contidas num 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 (string hexadecimal com 40 bytes) ou uma substring principal que seja exclusiva no repositório. Por exemplo, dae86e1950b1277e545cee180551750029cfe735 e dae86e nomeiam o mesmo objeto commit caso não haja nenhum outro objeto em seu repositório cujo nome do objeto também comece com dae86e.
- <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 ref simbólico. Por exemplo, master normalmente significa o objeto commit referenciado por refs/heads/master. Caso tenha heads/master e tags/master, poderá dizer explicitamente heads/master para informar ao Git a que se refere. Quando ambíguo, um <refname> é desambiguado usando a primeira correspondência nas regras a seguir:
-
Se $GIT_DIR/<refname> existir, é isso que você quer dizer (isso geralmente é útil apenas para
HEAD
,FETCH_HEAD
,ORIG_HEAD
,MERGE_HEAD
,REBASE_HEAD
,REVERT_HEAD
,CHERRY_PICK_HEAD
,BISECT_HEAD
eAUTO_MERGE
); -
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
-
nomeia o commit no qual você baseou as alterações na árvore de trabalho.
-
FETCH_HEAD
-
registra o ramo que você obteve de um repositório remoto com a sua última invocação
git fetch
. -
ORIG_HEAD
-
é criado por comandos que movem seu
HEAD
de forma drástica (git am
,git merge
,git rebase
,git reset
), para registrar a posição doHEAD
antes de sua operação, para que você possa alterar facilmente o cume da ramificação de volta ao estado anterior à sua execução. -
MERGE_HEAD
-
registra o(s) commit(s) que está(ão) sendo mesclado(s) no seu ramo quando você executar o
git merge
. -
REBASE_HEAD
-
durante um rebase, registra o commit onde a operação está interrompida no momento, seja por causa de conflitos ou de um comando
edit
num rebase interativo. -
REVERT_HEAD
-
registra o commit que está sendo revertido quando você executa o
git revert
. -
CHERRY_PICK_HEAD
-
registra o commit que você está selecionando quando executa o
git cherry-pick
. -
BISECT_HEAD
-
registra o commit atual a ser testado quando você executa
git bisect --no-checkout
. -
AUTO_MERGE
-
registra um objeto da árvore correspondente ao estado da estratégia de mesclagem ort gravada na árvore de trabalho quando uma operação de mesclagem resultar em conflitos.
-
Observe que qualquer um dos casos refs/* acima pode vir do diretório
$GIT_DIR/refs
ou do arquivo$GIT_DIR/packed-refs
. Embora a codificação do nome da referência não seja especificada, é preferível usar o UTF-8, pois alguns processamentos de saída podem assumir nomes no padrão UTF-8 como referência. -
- @
-
O @ sozinho é um atalho para
HEAD
. - [<refname>]@{<data>}, exemplo. master@{yesterday}, HEAD@{5 minutos atrás}
-
Uma ref seguida pelo sufixo @ com uma especificação de data num par de chaves (por exemplo, {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} ou {1979-02-26 18:30:00}) especifica o valor da ref num momento anterior. Este sufixo só pode ser usado imediatamente após um nome de referência e a referência deve ter um registro existente ($GIT_DIR/logs/<ref>). Observe que isso procura pela condição da sua referência local num determinado momento; por exemplo, o que estava no seu ramo local master na semana passada. Caso queira ver os commits feitos durante determinados períodos, consulte as opções
--since
e--until
. - <refname>@{<n>}, e.g. master@{1}
-
Uma ref seguida pelo sufixo @ com uma especificação ordinal num par de chaves (por exemplo, {1}, {15}) especifica o n-ésimo valor anterior dessa ref. Por exemplo, “master@{1}” é o valor anterior imediato de master, enquanto master@{5} é o quinto valor anterior de master. Este sufixo só pode ser usado imediatamente após um nome ref e a ref já deve ter um registro log existente ($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}
-
Um ramo B pode ser configurado para construir em cima de um ramo X (configurado com
branch.<nome>.merge
) em um R remoto (configurado combranch.<nome>.remote
). B@{u} refere-se ao ramo rastreado remotamente para o ramo X obtido a partir do R remoto, normalmente encontrado emrefs/remotes/R/X
. - [<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 é para @{upstream}, reportamos o ramo rastreado remotamente que corresponda aquela ramificação remotamente.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 ^ num parâmetro de revisão significa a primeira origem desse objeto commit. ^<n> significa o <n>ésimo ramo principal (ou seja, <rev>^ é equivalente a <rev>^1). Como regra especial, <rev>^0 significa o próprio commit e é usado quando <rev> é o nome do objeto de um objeto de etiquetas que se refere a um objeto de commit.
- <rev>~[<n>], exemplo, HEAD~, master~3
-
Um sufixo ~ num parâmetro de revisão significa a primeira origem deste objeto commit. Um sufixo ~<n> num parâmetro de revisão significa o objeto de commit que é o ancestral da <n>ésima geração do objeto de commit mencionado, seguindo apenas as primeiras origens. Ou seja, <rev>~3 é equivalente a <rev>^^^^, que é equivalente a <rev>^1^1^1. Veja abaixo uma ilustração de uso desse formulário.
- <rev>^{<type>}, exemplo, v0.99.8^{commit}
-
Um sufixo ^ seguido por um nome de tipo do objeto entre um par de chaves significa remove a referência do objeto em <rev> recursivamente até que um objeto do tipo <type> seja encontrado ou o objeto não possa mais perder a referência (neste caso, barf). Por exemplo, se <rev> for um commit, <rev>^{commit} descreverá o objeto correspondente do commit. Da mesma maneira, se <rev> for uma árvore, <rev>^{tree} descreverá o objeto correspondente da árvore. <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
-
Dois pontos, seguido de uma barra, seguido de um texto, nomeia um commit cuja mensagem de commit corresponde à expressão regular mencionada. Esse nome retorna o commit correspondente mais novo que pode ser acessado de qualquer ref, incluindo o
HEAD
. A expressão regular pode corresponder a qualquer parte da mensagem do commit. Para corresponder a mensagens que começam com uma string, é possível usar, por exemplo, :/^foo. A sequência especial :/! é reservada para modificadores do que é correspondido. :/!-foo executa uma correspondência negativa, enquanto :/!!foo corresponde a um caractere literal ! seguido de foo. Por enquanto, qualquer outra sequência que comece com :/! está reservada. Dependendo do texto informado, as regras de divisão das palavras do shell podem exigir citações adicionais. - <rev>:<caminho>, exemplo, HEAD:README, master:./README
-
Um sufixo : seguido de um caminho nomeia a bolha ou a árvore no caminho manecionado no objeto em forma de árvore nomeado pela parte antes dos dois-pontos. Um caminho que comece com ./ ou ../ é relativo ao diretório de trabalho atual. O caminho informado será convertido para ser relativo ao diretório raiz da árvore de trabalho. Isso é mais útil para abordar uma bolha ou uma árvore de um commit ou uma árvore que tenha a mesma estrutura de árvore que a á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 bolha 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, feita por Jon Loeliger. Os nós de commit B e C são origens do nó do commit A. Os commits principais 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.
Ao especificar várias revisões significa que o conjunto dos commits acessíveis a partir de qualquer um dos commits informados.
O conjunto acessível de um commit é o próprio commit e o commit em sua cadeia de ancestrais.
Existem várias notações para definir um conjunto de commits associados (chamado de "intervalo de revisão"), ilustrado abaixo.
Notações do Intervalo Pontilhado
- A faixa de notação de intervalo .. (dois pontos)
-
A operação de conjunto ^r1 r2 aparece com tanta frequência que existe uma abreviação para ela. Quando você tem dois commits r1 e r2 (mencionados de acordo com a sintaxe explicada em ESPECIFICANDO REVISÕES acima), você pode solicitar os commits que são acessíveis a partir de r2 excluindo aqueles que são acessíveis a partir de r1 por ^r1 r2 e isso pode ser escrito como r1..r2.
- A notação da diferença simétrica ... (três pontos)
-
Uma notação semelhante r1...r2 é chamada de diferença simétrica entre r1 e r2 e é definida como r1 r2 --not $(git merge-base --all r1 r2). É o conjunto de commits que são acessíveis a partir de um dos r1 (lado esquerdo) ou r2 (lado direito), mas não de ambos.
Nestas duas notações abreviadas, você pode omitir uma extremidade e deixá-la como o HEAD
predefinido. Por exemplo, origin… é uma abreviação de origin..HEAD e questiona "O que eu fiz desde que bifurquei do ramo de origem?" Da mesma maneira, ..origin é uma abreviação de HEAD..origin e questiona "O que a origem fez desde que eu a bifurquei?" Observe que .. significaria HEAD..HEAD, que é um intervalo vazio que pode ser acessado, mas não pode ser acessado a partir de HEAD.
Existem comandos projetados especificamente para usar dois intervalos distintos ("git range-diff R1 R2" para comparar dois intervalos por exemplo), mas eles são exceções. Salvo indicação em contrário, todos os comandos "git" que operam num conjunto de commits funcionam num único intervalo de revisão. Em outras palavras, escrever duas "notações de intervalo de dois-pontos" uma ao lado da outra, por exemplo.
$ git log A..B C..D
Não determina dois intervalos de revisão para a maioria dos comandos. Em vez disso, ele nomeará um único conjunto conectado de commits, ou seja, aqueles que são acessíveis a partir de B ou D, mas não são acessíveis a partir de A ou C. Num histórico linear como esse:
---A---B---o---o---C---D
porque A e B são alcançáveis a partir de C, o intervalo da faixa de revisão definido por estes dois intervalos pontilhados é um único commit D.
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^! inclui o commit r1, mas exclui todos os seus pais. Por si só, essa notação denota o commit único 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 a partir de
<rev>
(<rev> e os seus ancestrais por exemplo). - <rev1>..<rev2>
-
Inclua os commits que podem ser acessados a partir de <rev2>, mas exclua aqueles que podem ser acessados a partir de <rev1>. Quando <rev1> ou <rev2> é omitido, o padrão é
HEAD
. - <rev1>...<rev2>
-
Inclua os commits que são acessíveis a partir de <rev1> ou <rev2>, mas exclua aqueles que são acessíveis a partir de ambos. Quando <rev1> ou <rev2> é omitido, o padrão é
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 todos os seus principais 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 (por exemplo, divide trocas únicas com valores agregados), quase como o que o getopt(1)
faz.
Ele recebe na entrada predefinida a especificação das opções que serão analisadas, compreendidas e mostra na saída predefinida uma string sh(1)
eval
adequada para substituir os argumentos por argumentos normalizados. Em caso de erro, ele mostra como usar na saída de erro predefinida e encerra com o código 129.
Observação: Certifique-se de colocar o resultado entre aspas ao passá-lo para eval
. Veja um exemplo abaixo.
Formato de Entrada
O formato de entrada git rev-parse --parseopt
é totalmente baseado em texto. Possuí duas partes, são separadas por uma linha que contém apenas --
. As linhas antes do separador (deve ser uma ou mais) são usadas. As linhas após o separador descrevem 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, em seguida, o nome longo da opção separado por vírgula. Ambas as partes não são obrigatórias, embora pelo menos uma seja necessária. Não pode conter nenhum dos caracteres
<flags>
. Oh,help
,dry-run
ef
são exemplos de<opt-spec>
corretos. -
<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>
-
Quando o
<arg-hint>
é especificado, é utilizado como um nome do argumento na saída da ajuda para as opções que recebem argumentos. O<arg-hint>
é encerrado pelo primeiro espaço em branco. É comum usar um travessão para separar palavras numa dica de 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! Mostra a ajuda foo alguma opção bacana `--foo bar=` alguma opção bacana `--bar` com um argumento `baz=arg` outra opção bacana `--baz` com um argumento mencionado `qux?path qux` pode receber um argumento de caminho, mas tem significado por si só 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 --[no-]foo alguma opção bacana --foo --[no-]bar ... alguma opção legal --bar com um argumento --[no-]baz <arg> outra opção legal --baz com um determinado argumento --[no-]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 --end-of-options $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 --end-of-options $REV
porém caso $REV esteja vazia, o nome do objeto do commit vindo do "master" será impresso.
GIT
Parte do conjunto git[1]