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.31.1 → 2.34.1 no changes
- 2.31.0 03/15/21
- 2.27.1 → 2.30.2 no changes
- 2.27.0 06/01/20
- 2.25.2 → 2.26.3 no changes
- 2.25.1 02/17/20
- 2.22.1 → 2.25.0 no changes
- 2.22.0 06/07/19
- 2.14.6 → 2.21.4 no changes
- 2.13.7 05/22/18
- 2.12.5 no changes
- 2.11.4 09/22/17
- 2.10.5 no changes
- 2.9.5 07/30/17
- 2.7.6 → 2.8.6 no changes
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
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 uma quantidade qualquer de pais. Com exatamente um pai, é um commit comum. Ter mais de um pai torna o commit uma mesclagem entre as várias linhas do histórico. As confirmações iniciais (raiz) não têm pais.
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
, 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 com bate no UTC. O CET por exemplo (onde é 1 hora à frente do UTC ) é+0100
. - RFC 2822
-
O formato de e-mail padrão, conforme descrito pela RFC 2822, por exemplo,
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 caractereT
. O analisador aceita um espaço em vez do caractereT
também. As partes fracionadas de um segundo serão ignoradas, logo2005-04-07T22:13:13.019
por exemplo, será tratada como2005-04-07T22:13:13
.NoteAlém disso, a parte da data é aceita nos seguintes formatos: YYYY.MM.DD
,MM/DD/YYYY
eDD.MM.YYYY
.
Discussão
O Git é, até certo ponto, um codificador de caracteres agnóstico.
-
O conteúdo dos objetos blob são sequências de bytes não interpretados. Não há tradução de codificação no nível principal.
-
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 nível básico trata os nomes dos caminhos simplesmente como sequências de bytes não
NUL
, não há conversões de codificação dos nomes dos caminhos (exceto no Mac e no Windows). Portanto, o uso dos nomes do caminhos que não sejamASCII
funcionará principalmente em plataformas e sistemas de arquivos que se utilizem de codificações ASCII estendidas e herdadas. No entanto, os repositórios criados nestes sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (por exemplo, Linux, Mac, Windows) e vice-versa. Além disso, muitas ferramentas baseadas em Git simplesmente assumem nomes do caminho como UTF-8 e falharão ao exibir outros tipos de 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 log do commit sejam codificadas em UTF-8, a Porcelana do Git e seu núcleo foram projetados para não impor a utilização do UTF-8 nos projetos. Caso todos os participantes de um projeto em particular achem mais conveniente usar as codificações herdadas, o Git não o proibirá. Porém, há algumas coisas a serem consideradas.
-
Ambos os comandos git commit" e "git commit-árvore emitem um aviso caso a mensagem do registro log do commit utilizada não se parecer com uma string UTF-8 válida, a menos que explicitamente queira que seu projeto utilize uma codificação do legado. A melhor maneira de usar isso é ter uma variável
i18n.commitencoding
em um arquivo.git/config
, como este:[i18n] commitEncoding = ISO-8859-1
Os objetos commit que foram criados com a configuração acima registram o valor
i18n.commitEncoding
em seu cabeçalhoencoding
. Isso é para auxiliar as outras pessoas que olharão para eles mais tarde. A falta deste cabeçalho implica que a mensagem do registro log do commit seja codificado em UTF-8. -
Os comandos git log, git show, git blame e relacionados fazem vista para o cabeçalho
encoding
de um objeto commit e tentam codificar novamente a mensagem do registro log em UTF-8 a menos que seja definido de outra maneira. É possível especificar a codificação da saída desejada com a variáveli18n.logOutputEncoding
no arquivo.git/config
, assim:[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.
GIT
Parte do conjunto git[1]