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

NOME

git-commit - Grava as alterações feitas no repositório

RESUMO

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])…​] [-S[<keyid>]]
	   [--] [<pathspec>…​]

DESCRIÇÃO

Cria um novo commit que tenha todos os conteúdos atuais do índice e a mensagem informada no registro log descrevendo as alterações. Um novo commit é um herdeiro direto do HEAD que em geral é o topo do ramo atual e o ramo é atualizado para apontar para ele (a menos que nenhum ramo seja associado com a árvore de trabalho onde no caso o HEAD esteja desanexado como descrito em git-checkout[1]).

O conteúdo a ser feito o commit pode ser definido de diferente maneiras:

  1. ao usar git-add[1] para ir incrementando mudanças com "add" para o índice antes de usar o comando (Nota: devem ser "adicionados" até mesmo os arquivos modificados);

  2. ao usar git-rm[1] para remover os arquivos da árvore de trabalho e do índice, novamente, antes de usar o comando commit;

  3. ao listar os arquivos como argumentos para o comando commit (sem usar as opções --interactive ou --patch), nesse caso, o commit ignorará as alterações organizadas no índice e em vez disso registrará o conteúdo atual dos arquivos listados (que já devem ser informados pelo Git );

  4. ao usar a opção -a com o comando commit para "adicionar" automaticamente as alterações de todos os arquivos informados (ou seja, todos os arquivos que já estão listados no índice) e "rm" para remover os arquivos automaticamente da árvore de trabalho e assim executar o commit de fato;

  5. usando as opções --interactive ou --patch com o comando commit para decidir um por um quais os arquivos ou os blocos devem fazer parte do commit além do conteúdo do índice, antes de finalizar a operação. Consulte a seção “Modo Interativo” do git-add[1] para aprender como operar estes modos.

A opção --dry-run pode ser utilizada para obter um resumo do que está incluído em qualquer uma das opções acima para o próximo commit, fornecendo o mesmo conjunto de parâmetros (opções e caminhos).

Caso faça um commit e imediatamente encontre um erro logo em seguida, é possível recuperá-lo com o comando git reset.

OPÇÕES

-a
--all

Diz ao comando para preparar automaticamente os arquivos que foram modificados e excluídos, porém os novos arquivos que você não informou ao Git não são afetados.

-p
--patch

Utilize a interface interativa do patch para selecionar quais as alterações serão aplicadas ao commit. Para mais detalhes, consulte git-add[1].

-C <commit>
--reuse-message=<commit>

Pega um objeto commit existente e o reutiliza na mensagem do registro log, assim como as informações da autoria (incluindo o registro de data e hora) durante a criação de um commit.

-c <commit>
--reedit-message=<commit>

Como -C, porém com -c o editor é chamado para que o usuário possa editar ainda mais a mensagem do commit.

--fixup=[(amend|reword):]<commit>

Crie um novo commit que "corrija" o <commit> quando for aplicado com o comando git rebase --autosquash. Somente a opção --fixup=<commit> cria um "fixup!" (correção) que altera o conteúdo de um <commit> contudo deixa a mensagem de registro intacta. --fixup=amend:<commit> é semelhante, porém, cria um commit "amend!" que também substitui a mensagem do registro do <commit> pela mensagem de registro do commit "amend!". A opção --fixup=reword:<commit> cria um commit "amend!" que substitui a mensagem do registro do <commit> por sua própria mensagem de registro, mas não faz quaisquer alterações no conteúdo do <commit>.

O commit criado somente com a opção --fixup=<commit> tem o assunto da mensagem composto por "fixup!" seguido pela linha do assunto do <commit>, também é reconhecido especialmente através do comando git rebase --autosquash. A opção -m pode ser usada para complementar o registro da mensagem do commit criado, porém o comentário adicional será jogado fora assim que o commit "fixup!" for aplicado ao <commit> através do comando git rebase --autosquash.

O commit criado através da opção --fixup=amend:<commit> é semelhante porém seu assunto é prefixado com "amend!". A mensagem do log do <commit> é copiada para a mensagem de log do commit "amend!" e aberto em um editor para que possa ser refinado. Quando o comando git rebase --autosquash comprime o commit "amend!" no <commit>, a mensagem de log do <commit> é substituída pela mensagem de log refinada do commit "amend!". É considerado um erro quando o registro da mensagem do commit "amend!" esteja vazia, a menos que a opção --allow-empty-message seja definida.

--fixup=reword:<commit> é uma abreviação para --fixup=amend:<commit> --only. Isso cria um commit "amend!" com apenas uma mensagem log (ignorando quaisquer alterações preparadas no índice). Quando é comprimido através do comando git rebase --autosquash, ele substitui a mensagem do log do <commit> sem fazer quaisquer outras alterações.

Nem os commits "fixup!" tampouco os commits "amend!" alteram a autoria do <commit> quando aplicadas através do comando git rebase --autosquash. Para mais detalhes consulte git-rebase[1].

--squash=<commit>

Constrói a mensagem de um commit para utilizar com rebase --autosquash. A linha do assunto da mensagem do commit é retirada de um determinado commit com um prefixo "squash! ". Pode ser usado com as opções adicionais das mensagens dos commits (-m/-c/-C/-F). Para mais detalhes, consulte git-rebase[1].

--reset-author

Quando utilizado com as opções -C/-c/--amend, ou ao fazer o commit após uma escolha seletiva conflitante, declare que a autoria do commit resultante agora pertence a quem fez o commit. Isso também renova o registro de data e hora do autor.

--short

Ao executar um ensaio, informe a saída no formato curto. Para mais detalhes, consulte git-status[1]. Implica no uso da opção --dry-run.

--branch

Exibe o ramo e a informação de rastreio quando estiver em formato curto.

--porcelain

Ao executar um ensaio, informe a saída no formato porcelana. Para mais detalhes, consulte git-status[1]. Implica no uso da opção --dry-run.

--long

Ao executar um ensaio, informe a saída no formato curto. Implica no uso da opção --dry-run.

-z
--null

Ao exibir a condição de saída short ou porcelain, imprima o nome do arquivo literalmente e termine as entradas com um NUL, em vez do LF. Caso nenhum formato de saída seja informado, implica no uso da opção --porcelain. Sem a opção -z, os nomes dos arquivos com caracteres "incomuns" serão citados conforme explicado nas variáveis de configuração core.quotePath (consulte git-config[1]).

-F <arquivo>
--file=<arquivo>

Pega a mensagem de commit vindo de um determinado arquivo. Utilize - para ler a mensagem da entrada padrão.

--author=<autor>

Sobrescreva o commit do autor. Defina o autor de forma explicita usando o formato padrão Chiquinha <chiquinha@examplo.com>. Caso contrário, assume-se que a predefinição seja <autor> que é usado para localizar um commit já existente feito através deste autor (ou seja, rev-list --all -i --author=<autor>); o autor do commit é copiado a partir do primeiro commit que for encontrado.

--date=<data>

Substitua a data do autor que foi utilizada no commit.

-m <msg>
--message=<msg>

Usa <msg> como uma mensagem de commit. Caso múltiplas opções -m sejam usadas, o seu conteúdo será disposto em parágrafos separados.

A opção -m é utilizado em conjunto exclusivamente com -c, -C e -F.

-t <arquivo>
--template=<arquivo>

Ao editar a mensagem do commit, inicie o editor com o conteúdo do arquivo informado. A variável de configuração commit.template é frequentemente utilizada para fornecer esta opção de forma implícita ao comando. Esse mecanismo pode ser utilizado por projetos que desejam orientar os participantes com algumas dicas sobre o que escrever na mensagem e em qual ordem. Aborte o commit caso o usuário saia do editor sem editar a mensagem. Não qualquer efeito quando uma mensagem é dada por outros meios, por exemplo, com as opções -m ou -F.

-s
--signoff
--no-signoff

Adicione uma linha Signed-off-by de quem fez o commit no final da mensagem de registro do commit. O significado de uma aprovação depende do projeto onde você está fazendo o commit. Por exemplo, ele pode certificar que quem fez o commit tem o direito de enviar o trabalho sob a licença do projeto ou concorda com alguma representação do contribuinte, como um certificado de origem do desenvolvedor. (Consulte https://developercertificate.org para saber qual é a usada pelo kernel do Linux e pelos projetos Git). Consulte a documentação ou a liderança do projeto para onde está contribuindo para compreender como as assinaturas são usadas nesse projeto.

A opção --no-signoff pode ser usada para contra-ordenar uma opção --signoff anterior na linha de comando.

--trailer <token>[(=|:)<valor>]

Determine um par (<token>, <valor>) que deve ser aplicado como um caracteres de resposta. (por exemplo, git commit --trailer "Auxiliado por:C O Mitter \ <committer@example.com>" --trailer "Auxiliado por:C O Mitter \ <committer@example.com>" será atrelado o "Auxiliado por" e o "Auxiliado por" à mensagem do commit.) A variável de configuração do trailer.* (git-interpret-trailers[1]) pode ser usado para definir se um atrelado duplicado será omitido, onde na rodada de atrelados cada atrelado apareceria em conjunto com outros detalhes.

-n
--[no-]verify

É predefinido que os ganchos pre-commit e commit-msg sejam executados. Quando qualquer uma das opções --no-verify ou -n são usadas, elas são ignoradas. Consulte também githooks[5].

--allow-empty

Geralmente, ao gravar um commit que tenha exatamente a mesma árvore como se fosse a sua origem, é um erro, o comando impede que você faça um commit desta natureza. Esta opção ignora a segurança e deve ser utilizada principalmente por scripts SCM externos.

--allow-empty-message

Como a opção --allow-empty, este comando é principalmente para uso por scripts de interface SCM externos. Permite criar um commit com uma mensagem vazia sem usar os comandos de "encanamento" como git-commit-tree[1].

--cleanup=<modo>

Esta opção determina como a mensagem que foi informada ao commit deve ser limpa antes do commit ser feito. O <modo> pode ser strip, whitespace, verbatim, scissors ou default.

strip (tirar/remover)

Retira as linhas vazias no inicio e no final, e os rastros dos espaços finais, os comentários e reduza as linhas vazias consecutivamente.

whitespace (espaço)

O mesmo que strip, exceto que o #comentário não é removido.

verbatim (íntegra)

Não altera a mensagem de forma alguma.

scissors (tesouras)

O mesmo que whitespace (espaço), exceto que tudo incluindo a linha encontrada abaixo seja truncada caso a mensagem precise ser editada. "#" pode ser personalizada com core.commentChar.

# ------------------------ >8 ------------------------
default

O mesmo que strip caso a mensagem esteja para ser editada. Caso contrário, whitespace (espaço).

A predefinição pode ser alterada através da variável de configuração commit.cleanup (consulte git-config[1]).

-e
--edit

A mensagem obtida do arquivo com a opção -F, da linha de comando com a opção -m e do objeto commit com -C é normalmente utilizada como a mensagem de registro log do commit não modificado. Esta opção permite editar ainda mais a mensagem retirada destas fontes.

--no-edit

Utilize a mensagem do commit selecionado sem rodar um editor. Por exemplo, git commit --amend --no-edit altera um commit sem alterar o conteúdo da mensagem do mesmo.

--amend

Substitua o cume do ramo atual criando um novo commit. A árvore gravada é preparada como de costume (incluindo a aplicação das opções -i e -o; e pathspec explicitamente), a mensagem do commit original é utilizada como um ponto de partida, em vez de uma mensagem vazia. Quando nenhuma outra mensagem é utilizada na linha de comando através de opções como -m, -F, -c, etc. O novo commit possuirá as mesmas origens e seu respectivo autor como o atual (a opção --reset-author pode ser utilizada para mudar isso).

É grosseiramente um equivalente para:

	$ git reset --soft HEAD^
	$ ... faça qualquer outra coisa para encontrar a árvore certa ...
	$ git commit -c ORIG_HEAD

mas pode ser utilizado para corrigir a mesclagem de um commit.

Você deve entender as implicações de sobrescrever o histórico caso corrija um commit que já tenha sido publicado. (Consulte a seção "RECUPERANDO DO UPSTREAM REBASE" no git-rebase[1].)

--no-post-rewrite

Ignore o gancho de reescrita de postagem.

-i
--include

Antes de fazer um commit dos conteúdos preparados até o momento, prepare também o conteúdo dos caminhos utilizados na linha de comando. Isso geralmente não é o que você quer, a menos que esteja concluindo um mesclagem conflitante.

-o
--only

Faça um commit utilizando o conteúdo atualizado da árvore de trabalho dos caminhos definidos na linha de comando, desconsiderando qualquer outro conteúdo que tenha sido preparado para os outros caminhos. Essa é a maneira predefinida de operação do comando git commit caso algum outro caminho tenha sido informado na linha de comando; nesse caso, essa opção poderá ser omitida. Caso esta opção seja utilizada junto com --amend, nenhum outro caminho precisará ser informado, o que pode ser utilizado para alterar o último commit sem confirmar as alterações que já foram preparadas. Se utilizado junto com a opção`--allow-empty` também não são necessários e um commit vazio será criado.

--pathspec-from-file=<arquivo>

O "pathspec" é passado com <arquivo> em vez dos argumentos da linha de comando. Caso o <arquivo> seja exatamente -, a entrada padrão será utilizada. Os elementos do "pathspec" são separados por caracteres de término de linha LF ou CR/LF. Os elementos do "pathspec" podem ser citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]). Consulte também opção --pathspec-file-nul e o global --literal-pathspecs.

--pathspec-file-nul

Só faz algum sentido caso seja utilizado junto com a opção --pathspec-from-file. Os elementos "pathspec" são separados com caracteres NUL e todos os outros caracteres são considerados de forma literal (incluindo as novas linhas e as citações).

-u[<modo>]
--untracked-files[=<modo>]

Exibe arquivos sem rastreamento.

O parâmetro mode é opcional, a predefinição retorna para all (todos), sendo utilizado para determinar a manipulação dos arquivos que não foram rastreados; quando a opção -u não for utilizada, a predefinição volta para normal, ou seja, exibe os arquivos e os diretórios que não foram rastreados.

As opções disponíveis são:

  • no - Não exibe quaisquer arquivos que não tenham sido rastreados

  • normal - Exibe todos os arquivo e diretórios que não foram rastreados

  • all - Exibe todos os arquivos individualmente nos diretórios não rastreados.

All usual spellings for Boolean value true are taken as normal and false as no. The default can be changed using the status.showUntrackedFiles configuration variable documented in git-config[1].

-v
--verbose

Exibe as diferenças unificadas entre o commit no HEAD e o que seria feito o commit na parte inferior do modelo da mensagem do commit para ajudar o usuário a descrever o commit lembrando quais as alterações que o commit possui. Note que esta saída "diff" não tem suas linhas prefixadas com #. Este "diff" não fará parte da mensagem do commit. Consulte a configuração da variável commit.verbose em git-config[1].

Caso seja utilizado duas vezes exibirá além do diferencial unificado entre o que seriam feitos os commits e os arquivos da árvore de trabalho, ou seja, as alterações não-estáticas nos arquivos rastreados.

-q
--quiet

Suprimir a mensagem de resumo do commit.

--dry-run

Não crie um commit porém exiba uma lista dos caminhos onde os commits devem ser feitos, os caminhos com as alterações locais onde os commits serão deixados de lado e os caminhos que não serão rastreados.

--status

Inclua a saída do git-status[1] na mensagem do commit ao usar um editor para preparar a mensagem do commit. A predefinição retorna para ligado, porém pode ser utilizado para substituir a variável de configuração commit.status.

--no-status

Não inclua a saída do git-status[1] no modelo da mensagem do commit ao utilizar um editor para preparar a mensagem predefinida do commit.

-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; caso seja utilizado, deve estar anexado a opção e sem espaço. A opção --no-gpg-sign é útil para revogar a variável de configuração commit.gpgSign e a anterior --gpg-sign.

--

Não interprete mais argumentos como opções.

<pathspec>…​

Quando o pathspec é utilizado na linha de comando, faça o commit do conteúdo dos arquivos que correspondem ao pathspec sem registrar as alterações já adicionadas ao índice. O conteúdo desses arquivos também é preparado para o próximo commit, além do que já foi preparado anteriormente.

Para mais detalhes sobre a sintaxe, consulte a entrada pathspec em gitglossary[7].

EXEMPLOS

Ao gravar o seu próprio trabalho, o conteúdo dos arquivos modificados na sua árvore de trabalho é temporariamente armazenado em uma área intermediária chamada "índice" com git add. Um arquivo pode ser revertido para o último commit com git restore --staged apenas no índice mas não na árvore de trabalho, que reverte efetivamente o git add e impede que as alterações nesse arquivo façam parte do próximo commit. Após criar a condição a ser feito o commit incrementalmente com esses comandos, o git commit (sem nenhum parâmetro pathname) é utilizado para registrar o que foi preparado até o momento. Essa é a forma mais básica do comando. Um exemplo:

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

Em vez de disponibilizar arquivos após cada alteração individual, você pode dizer ao git commit para observar as alterações nos arquivos cujo conteúdo é rastreado na sua árvore de trabalho e faz os comandos correspondentes git add e git rm para você. Ou seja, este exemplo faz o mesmo que o exemplo anterior, se não houver outra alteração na sua árvore de trabalho:

$ edit hello.c
$ rm goodbye.c
$ git commit -a

O comando git commit -a primeiro olha para a sua árvore de trabalho, nota que você modificou o hello.c e removeu o goodbye.c e executa os comandos necessários git add e git rm para você.

Após preparar as mudanças em muitos arquivos, você pode alterar a ordem em que as alterações são registradas ao encaminhar pathnames para git commit. Quando pathnames são utilizados, o comando faz um commit que registra apenas as alterações feitas nos caminhos informados:

$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile

Isso faz um commit que registra a modificação no arquivo Makefile. As mudanças preparadas para hello.c e hello.h não são incluídas no commit resultante. No entanto as suas mudanças não se perdem, elas ainda são preparadas e meramente retidas. Após a sequência acima, se fizer:

$ git commit

este segundo commit registraria as alterações em hello.c e hello.h conforme o esperado.

Depois que uma mesclagem (iniciada pelo comando git merge ou git pull) é interrompida por causa de conflitos, os caminhos mesclados de maneira limpa já são preparados para serem confirmados para você, e os caminhos em conflito são deixados num estado inalterado. Você precisaria primeiro verificar quais são os caminhos que estão em conflito com o comando git status e após corrigi-los manualmente em sua árvore de trabalho, você prepararia o resultado como de costume com o comando git add:

$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c

Após resolver os conflitos e organizar o resultado, o git ls-files -u deixaria de mencionar o caminho conflitado. Quando terminar, execute git commit para finalmente registrar a mesclagem:

$ git commit

Como no caso de registrar as suas próprias alterações, você pode usar a opção -a para salvar a digitação. Uma diferença é que durante uma resolução da mesclagem, você não pode utilizar o comando git commit com o pathnames para alterar a ordem onde as alterações dos commits foram realizados porque a mesclagem deve ser registrada como um commit. De fato, o comando se recusa a ser executado quando recebem os nomes do caminho (consulte a opção -i).

INFORMAÇÃO DO COMMIT

A informação do autor e de quem fez o commit são extraídas das seguintes variáveis do ambiente, se definido:

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(nb "<", ">" e "\n"s serão removidos)

É de praxe utilizar um nome pessoal como sendo os nomes dos autores e de quem fez os commits (isto é, um nome pela qual outros humanos usam para se referir a você), no entanto o Git não impõem ou requer qualquer forma em particular. Um unicode arbitrário pode ser utilizado e é sujeito às restrições listadas acima. Este nome não tem nenhum efeito na autenticação; para isso consulte a variável credential.username em git-config[1].

Caso (algumas dessas) variáveis de ambiente não sejam definidas, as informações são obtidas dos itens da configuração user.name e user.email ou caso não haja, na variável de ambiente EMAIL ou se também não existir ou tenha sido definida, o nome de usuário do sistema e nome do host (hostname) utilizado pelo email enviado (extraído de /etc/mailname e retornando ao nome completo do host quando esse arquivo não existir).

O author.name e committer.name e suas respectivas opções de email correspondentes substituem o user.name e user.email caso sejam configurados e são substituídos pelas variáveis do ambiente.

O uso típico é definir apenas as variáveis user.name e user.email; as outras opções são informadas para casos de uso mais complexos.

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.

Além de reconhecer todos os formatos da data acima, a opção --date também tentará dar sentido aos outros formatos para que sejam legíveis, como "ontem" ou "a última sexta-feira ao meio-dia".

DISCUSSÃO

Embora não seja obrigatório, é uma boa ideia iniciar a mensagem do commit com uma única linha curta (não mais que 50 caracteres) resumindo a alteração, seguida por uma linha em branco e em seguida, uma descrição mais completa. O texto até a primeira linha em branco numa mensagem do commit é tratado como o título do commit e esse título é utilizado através de todo o Git. Por exemplo, o git-format-patch[1] transforma um commit num email e usa o título na linha de assunto e o restante do commit no corpo da mensagem.

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.

VARIÁVEIS DE AMBIENTE E CONFIGURAÇÃO

O editor usado para editar a mensagem do registro log do commit que será escolhido entre a variável de ambiente GIT_EDITOR, a variável de configuração core.editor, a variável de ambiente VISUAL ou a variável de ambiente EDITOR (nesta ordem). Para mais detalhes, consulte git-var[1].

Warning

Missing pt_BR/includes/cmd-config-section-rest.txt

See original version for this content.

Warning

Missing pt_BR/config/commit.txt

See original version for this content.

GANCHOS

Este comando pode executar os ganchos commit-msg, prepare-commit-msg, pre-commit, post-commit e post-rewrite. Para mais informações consulte githooks[5].

ARQUIVOS

$GIT_DIR/COMMIT_EDITMSG

Este arquivo contém a mensagem do commit de um commit em andamento. Caso o git commit encerre devido a um erro antes da criação do commit, qualquer mensagem do commit que tenha sido utilizada pelo usuário (por exemplo, numa sessão do editor) estará disponível neste arquivo, mas será substituída pela próxima invocação do comando git commit.

GIT

Parte do conjunto git[1]

scroll-to-top