Git

git-commit last updated in 2.34.1

NOME

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

RESUMO

git commit [-a | --interactive | --patch] [-s] [-v] [-u<modo>] [--amend]
	   [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
	   [-F <arquivo> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<autor>]
	   [--date=<data>] [--cleanup=<modo>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<arquivo> [--pathspec-file-nul]]
	   [-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:

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);
ao usar git-rm[1] para remover os arquivos da árvore de trabalho em do índice, novamente, antes de usar o comando commit;
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 );
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;
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=<commit>

Constrói a mensagem de um commit para utilizar com rebase --autosquash. A mensagem do commit será o assunt da linha a partir de um determinado commit com um prefixo "fixup! ". 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 a <msg> como a 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

Adicionar uma linha assinado pela pessoa que fez o commit no final do registro log do commit assinado. O significado de uma aprovação depende do projeto, porém normalmente certifica que a pessoa que fez o commit tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (consulte http://developercertificate.org/ para obter mais informações).

-n

--no-verify

Esta opção ignora os ganchos dos commits anteriores e os ganchos das mensagens de commit. 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 <modo> é 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 é utilizada a predefinição retorna para normal, ou seja, exibe os arquivos e diretórios que não foram rastreados.

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

no - Não exibe qualquer arquivo 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.

A predefinição pode ser alterada utilizando a variável de configuração status.showUntrackedFiles documentada em 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 <pathspec>, veja 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 em um estado inalterado. Você precisaria primeiro verificar quais são os caminhos que estão em conflito com o comando git status e depois de 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 usar um nome pessoa como 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, GIT_COMMITTER_DATE e a opção --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 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

Embora não seja obrigatório, é uma boa ideia iniciar a mensagem do commit com uma única linha curta (com menos de 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 em uma 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 em um 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 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 sejam ASCII 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çalho encoding. 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ável i18n.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.

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].

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, em uma sessão do editor) estará disponível neste arquivo, mas será substituída pela próxima invocação do comando git commit.

VEJA TAMBÉM

git-add[1], git-rm[1], git-mv[1], git-merge[1], git-commit-tree[1]

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands