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.45.1 → 2.47.0 no changes
- 2.45.0 04/29/24
- 2.43.1 → 2.44.2 no changes
- 2.43.0 11/20/23
- 2.35.1 → 2.42.3 no changes
- 2.35.0 01/24/22
- 2.31.1 → 2.34.8 no changes
- 2.31.0 03/15/21
- 2.27.1 → 2.30.9 no changes
- 2.27.0 06/01/20
- 2.25.2 → 2.26.3 no changes
- 2.25.1 no changes
- 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
- 2.1.4 → 2.3.10 no changes
- 2.0.5 12/17/14
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 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 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.
-
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çalhoencoding
. 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. -
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 comi18n.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.
GIT
Parte do conjunto git[1]