Git 🌙
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-commit-tree last updated in 2.45.0

NOME

git-commit-tree - Cria um novo objeto commit

RESUMO

git commit-tree <tree> [(-p <origem>)…​]
git commit-tree [(-p <origem>)…​] [-S[<keyid>]] [(-m <mensagem>)…​]
		  [(-F <arquivo>)…​] <árvore>

DESCRIÇÃO

Normalmente, não é o que um usuário final gostaria de usar diretamente. Em vez disso, consulte git-commit[1].

Cria um novo objeto commit com base no objeto da árvore informada e emite a nova ID do objeto commit no stdout. A mensagem do registro log é lido na entrada padrão a não ser que as opções -m ou -F sejam utilizadas.

As opções -m e -F podem ser utilizadas várias vezes e em qualquer ordem. A mensagem do registro log do commit será composta na ordem em que as opções forem utilizadas.

Um objeto commit pode ter qualquer quantidade de origens. Com exatamente um commit principal, ele é um commit comum. Ter mais de uma origem faz com que o commit seja uma mescla entre várias linhas de histórico. Os commits iniciais (raiz) não possuem parentes.

Enquanto uma árvore representa a condição de um diretório de trabalho em específico, um commit representa esta condição em "hora" e explica como chegar até lá.

Normalmente, um commit identifica uma nova condição "HEAD" e embora o Git não se importe onde você salva a nota sobre esse estado, na prática, tendemos apenas a escrever o resultado no arquivo apontado por .git/HEAD para que possamos sempre ver como estava a última condição do commit.

OPÇÕES

<árvore>

Um objeto árvore já existente.

-p <origem>

Cada -p indica o id de uma origem do objeto commit.

-m <mensagem>

Um parágrafo no registro log da mensagem de commit. Isto pode ser usado mais de uma vez, e cada <mensagem> se torna o seu próprio parágrafo.

-F <arquivo>

Leia a mensagem do registro log do commit de um arquivo informado. Utilize - para ler a entrada padrão. Isso pode ser dado mais de uma vez e o conteúdo de cada arquivo se torna seu próprio parágrafo.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

Commits assinados com o GPG O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; se utilizado, deve estar anexado a opção sem espaço. --no-gpg-sign is useful to countermand a --gpg-sign option given earlier on the command line.

Informação do commit

Os encapsulamentos de um commit:

  • ids de todos os objetos da origem

  • nome do autor, email e data

  • nome e o endereço de email da pessoa que faz o commit e o momento em que foi feito.

Um comentário de um commit é lido no stdin. Se uma entrada no changelog não for informada através do redirecionamento "<", o comando git commit-tree esperará apenas que um seja inserido e termine com um ^D.

OS FORMATOS DA DATA

As variáveis de ambiente GIT_AUTHOR_DATE e GIT_COMMITTER_DATE são compatíveis com os seguintes formatos de data:

Formato interno do Git

É <unix-timestamp> <time-zone-offset>, onde desde a época do UNIX <unix-timestamp> é o valor em segundos. O <time-zone-offset> é o desvio positivo ou negativo a partir do UTC. O CET por exemplo (onde é 1 hora à frente do UTC ) é +0100.

RFC 2822

The standard date format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

A data e hora definidas pela norma ISO 8601 2005-04-07T22:13:13 por exemplo. O analisador também aceita um espaço em vez do caractere T. O analisador aceita um espaço em vez do caractere T também. As partes fracionadas de um segundo serão ignoradas, logo 2005-04-07T22:13:13.019 por exemplo, será tratada como 2005-04-07T22:13:13.

Note
Além disso, a parte da data é aceita nos seguintes formatos: YYYY.MM.DD, MM/DD/YYYY e DD.MM.YYYY.

Discussão

O Git é, até certo ponto, um codificador de caracteres agnóstico.

  • O conteúdo dos objetos bolha (blob) são sequências de bytes não interpretadas. Não há uma tradução de codificação no nível do núcleo.

  • Os nomes do caminho são codificados na forma de normalização UTF-8 C. Isso se aplica a objetos nas árvore, arquivos do índice, referência de nomes e nomes do caminho em argumentos da linha de comando, variáveis do ambiente e os arquivos de configuração (.git / config (consulte git-config[1]), gitignore[5], gitattributes[5] e gitmodules[5]).

    Observe que o Git, em seu cerne, trata os nomes do caminho simplesmente como sequências de bytes não NUL; não há conversões de codificação do nome do caminho (exceto no Mac e no Windows). Portanto, o uso de nomes com caminho não ASCII funcionará, em geral, mesmo em plataformas e sistemas de arquivos que usam codificações ASCII estendidas legadas. No entanto, os repositórios criados nesses sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (Linux, Mac, Windows por exemplo) e vice-versa. Além disso, muitas ferramentas com base no Git simplesmente assumem que os nomes de caminho são UTF-8 e não exibem outras codificações corretamente.

  • As mensagens do registro log do commit geralmente são codificadas em UTF-8, porém há compatibilidade para outras codificações ASCII estendidas. Isso inclui ISO-8859-x, CP125x e muitos outros. Porém não há compatibilidade com codificações UTF-16/32, EBCDIC e CJK, codificações de vários bytes (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Embora incentivemos que as mensagens do registro do commit sejam codificadas em UTF-8, tanto o núcleo quanto o Git porcelain foram projetados para não impor o UTF-8 nos projetos. Se todos os participantes de um determinado projeto acharem mais conveniente usar codificações herdadas, o Git não o proibirá. Entretanto, há alguns aspectos que devem ser levados em consideração.

  1. O comando git commit e o git commit-tree emitem um aviso se a mensagem de registro do commit fornecida a ele não se parecer com uma string UTF-8 válida, a menos que você diga explicitamente que o seu projeto usa uma codificação antiga. A maneira de definir isso é ter i18n.commitEncoding no arquivo .git/config, assim:

    [i18n]
    	commitEncoding = ISO-8859-1

    Os objetos criados do commit com a configuração acima, registram o valor i18n.commitEncoding em seu cabeçalho encoding. Isso serve para ajudar as outras pessoas que forem examiná-las mais tarde. A ausência desse cabeçalho implica que a mensagem de registro do commit está codificada em UTF-8.

  2. Os comandos git log, git show, git blame e outros, analisam o cabeçalho encoding de um objeto commit e tentam recodificar a mensagem de registro em UTF-8, a menos que outro seja especificado. Você pode especificar a codificação de saída desejada com i18n.logOutputEncoding no arquivo .git/config, da seguinte maneira:

    [i18n]
    	logOutputEncoding = ISO-8859-1

    Caso não tenha essa variável de configuração, o valor de i18n.commitEncoding é utilizado em seu lugar.

Observe que decidimos deliberadamente não codificar novamente a mensagem do registro log do commit quando um commit for feito para forçar a codificação UTF-8 a nível do objeto commit, porque a re-codificação para UTF-8 não é necessariamente uma operação reversível.

ARQUIVOS

/etc/mailname

GIT

Parte do conjunto git[1]

scroll-to-top