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
RESUMO
git check-ref-format [--normalize] [--[no-]allow-onelevel] [--refspec-pattern] <refname> git check-ref-format --branch <branchname-shorthand>
DESCRIÇÃO
Verifica se um determinado refnome é aceitável e sai com um status diferente de zero, se não for.
Uma referência é usada no Git para definir as ramificações e as tags. Um
cabeçalho de um ramo é armazenado dentro da hierarquia refs/heads
,
enquanto uma tag é armazenada na hierarquia refs/tags
do espaço de nomes
da ref (geralmente nos diretórios $GIT_DIR/refs/heads
e no
$GIT_DIR/refs/tags
ou nas entradas do arquivo no $GIT_DIR/packed-refs
caso a "ref" tenha sido empacotada através do comando git gc
).
O Git impõe as seguintes regras sobre como as referências são nomeadas:
-
Eles podem incluir slash
/
para agrupamento hierárquico (diretório), nenhum componente separado por barras pode começar com um ponto.
ou terminar com a sequência.lock
. -
Eles devem ter pelo menos um
/
. Isto reforça a presença de uma categoria comoheads/
,tags/
etc. Porém os nomes reais não são restritos. Caso a opção--allow-onelevel
seja utilizada, esta regra será dispensada. -
Eles não podem ter dois pontos consecutivos
..
em qualquer lugar. -
Eles não podem ter caracteres de controle ASCII (ou seja, bytes cujos valores são menores que \040, ou \177
DEL
), espaço, til `~ `, circunflexo `^ `ou dois pontos `: `em qualquer lugar. -
Eles não podem ter ponto de interrogação
?
, asterisco*
, ou colchete aberto[
em qualquer lugar. Consulte a opção--refspec-pattern
abaixo para uma exceção a esta regra. -
Eles não podem iniciar ou terminar com uma barra
/
ou conter múltiplas barras consecutivas (veja a opção--normalize
abaixo para uma exceção a esta regra) -
Eles não podem terminar com um ponto
.
. -
Eles não podem conter uma sequência
@{
. -
Eles não podem ser o único caractere
@
. -
Eles não podem conter um
\
.
Estas regras facilitam para as ferramentas com base em script shell a analise das referências dos nomes, a expansão de um nome do caminho pelo shell quando um nome de referência é utilizado sem aspas (por engano) e também para evitar as ambiguidades em certas expressões dos nomes das referências (consulte gitrevisions[7]) :
-
Um ponto duplo
..
é freqüentemente utilizado como em` ref1..ref2` e, em alguns contextos, essa notação significa^ref1 ref2
(isto é, não em` ref1` e emref2
). -
Um til
~
e um caractere circunflexo^
são utilizados para introduzir a operação do postfix nth parent e peel onion. -
Os dois pontos
:
são usados nosrcref:dstref
no sentido de "use o valor do srcref\ e armazene-o no dstref" nas operações "fetch" e "push". Também para ser usado para selecionar um objeto em específico como com o comandogit cat-file
: "git cat-file blob v1.3.3:refs.c". -
at-open-brace
@{
é utilizado como uma notação para acessar uma entrada de reflog.
Com a opção --branch
, o comando pega um nome e verifica se ele pode ser
utilizado como o nome de um ramo válido (por exemplo, ao criar uma nova
ramificação). Mas tenha cuidado ao usar a sintaxe de checkout anterior que
pode se referir a um estado HEAD
desanexado. A regra que o git
check-ref-format --branch $name
implementa pode ser mais rigorosa do que
git check-ref-format refs/heads/$name
diz (por exemplo, um traço pode
aparecer no início de um componente "ref" porém é explicitamente proibido no
início do nome de um ramo). Quando executada com a opção --branch
em um
repositório a entrada é expandida primeiro para “previous checkout syntax”
@{-n}
. Por exemplo, @{-1}
é uma maneira de consultar a última coisa que
foi retirada utilizando a operação "git switch" ou "git checkout". Essa
opção deve ser utilizada pelas porcelanas para aceitar essa sintaxe em
qualquer lugar em que um nome do ramo seja esperado para que eles possam
agir como se você digitasse o nome do ramo. Como uma exceção observe que a
``operação de checkout anterior" pode resultar em um nome do objeto de
commit quando a enésima última coisa verificada não for um ramo.
OPÇÕES
- --[no-]allow-onelevel
-
Controla se os refnames com um nível serão aceitos (isto é, refnames que não tenham vários componentes separados por
/
). A predefinição é--no-allow-onelevel
. - --refspec-pattern
-
Interprete o <refname> como um padrão do nome para um refspec (conforme é utilizado com os repositórios remotos). Caso esta opção esteja ativada, o <refname> poderá conter um único
*
no refspec (como por exemplo,foo/bar*/baz
oufoo/bar*baz/
mas nãofoo/bar*/baz*
). - --normalize
-
Normalize refname removendo quaisquer caracteres iniciais com barra (
/
) e reduzindo as execuções das barras adjacentes entre os nomes dos componentes em uma única barra. Caso o refname normalizado seja válido, imprima-o na saída padrão e encerre com a condição 0, caso contrário encerre com uma condição diferente de zero. (a opção--print
é uma maneira obsoleta de soletrar--normalize
.)
EXEMPLOS
-
Imprima o nome da coisa anterior registrada:
$ git verifique-o-formato-ref --branch @{-1}
-
Determine o nome de referência a ser utilizado para uma nova ramificação:
$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")|| { echo "nós não gostamos do '$newbranch' como um nome do ramo." >&2 ; exit 1 ; }
GIT
Parte do conjunto git[1]