git-commit - Online na nuvem

PROGRAMA:

NOME

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

SINOPSE

git commit [-a | --interactive | --patch] [-s] [-v] [-u ] [- alterar]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author = ]
[--data = ] [--cleanup = ] [- [sem-] status]
[-i | -o] [-S [ ]] [-] [ ...]

DESCRIÇÃO

Armazena o conteúdo atual do índice em um novo commit junto com uma mensagem de log do
usuário descrevendo as mudanças.

O conteúdo a ser adicionado pode ser especificado de várias maneiras:

1. usando git adicionar para incrementar "adicionar" mudanças ao índice antes de usar o commit
comando (Nota: mesmo os arquivos modificados devem ser "adicionados");

2. usando git rm para remover arquivos da árvore de trabalho e do índice, novamente antes
usando o commit comando;

3. listando arquivos como argumentos para o commit comando, caso em que o commit irá
ignorar as alterações preparadas no índice e, em vez disso, registrar o conteúdo atual do
arquivos listados (que já devem ser conhecidos pelo Git);

4. usando o switch -a com o commit comando para "adicionar" automaticamente as alterações de todos
arquivos conhecidos (ou seja, todos os arquivos que já estão listados no índice) e automaticamente
arquivos "rm" no índice que foram removidos da árvore de trabalho e, em seguida, execute
o commit real;

5. usando as opções --interactive ou --patch com o commit comando para decidir um
por um quais arquivos ou pedaços devem fazer parte do commit, antes de finalizar o
Operação. Consulte a seção “Modo interativo” de git-add(1) para aprender como operar
esses modos.

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

Se você fizer um commit e encontrar um erro imediatamente depois disso, você pode se recuperar do
com git redefinir.

OPÇÕES

-a, --todos
Diga ao comando para preparar automaticamente os arquivos que foram modificados e excluídos, mas
novos arquivos que você não informou ao Git não são afetados.

-p, --patch
Use a interface de seleção de patch interativa para escolher quais alterações confirmar. Ver
git-add(1) para obter detalhes.

-C , --reuse-message =
Pegue um objeto de confirmação existente e reutilize a mensagem de log e a autoria
informações (incluindo o carimbo de data / hora) ao criar o commit.

-c , --reedit-message =
Como -C, mas com -c o editor é invocado, para que o usuário possa editar ainda mais o
enviar mensagem.

--fixup =
Constrói uma mensagem de confirmação para usar com rebase --autosquash. A mensagem de confirmação irá
ser a linha de assunto do commit especificado com um prefixo "fixup!". Ver git-
rebase(1) para obter detalhes.

--squash =
Constrói uma mensagem de confirmação para usar com rebase --autosquash. A mensagem de confirmação
a linha de assunto é retirada do commit especificado com um prefixo "squash!". Pode ser
usado com opções de mensagem de confirmação adicionais (-m / -c / -C / -F). Ver git-rebase(1) para
Detalhes.

--reset-autor
Quando usado com -C / -c / - opções de alteração, ou ao confirmar após um conflito
escolha certa, declare que a autoria do commit resultante agora pertence ao
committer. Isso também renova o carimbo de data / hora do autor.

--baixo
Ao fazer uma simulação, forneça a saída no formato curto. Ver status do git(1) para
detalhes. Implica --dry-run.

--filial
Mostre a ramificação e as informações de rastreamento, mesmo em formato curto.

--porcelana
Ao fazer uma simulação, forneça a saída em um formato pronto para porcelana. Ver status do git(1)
para detalhes. Implica --dry-run.

--grande
Ao fazer uma simulação, forneça a saída no formato longo. Implica --dry-run.

-z, --nulo
Ao mostrar a saída de status curto ou porcelana, encerre as entradas na saída de status
com NUL, em vez de LF. Se nenhum formato for fornecido, implica no formato de saída --porcelain.

-F , --file =
Pegue a mensagem de confirmação do arquivo fornecido. Usar - para ler a mensagem do
entrada padrão.

--author =
Substitua o autor do commit. Especifique um autor explícito usando o AU Thor padrão
<[email protegido]> formato. De outra forma é considerado um padrão e é usado
para procurar um commit existente desse autor (ie rev-list --all -i
--author = ); o autor do commit é então copiado do primeiro commit encontrado.

--date =
Substitua a data do autor usada no commit.

-m , --message =
Use o dado como a mensagem de confirmação. Se várias opções -m forem fornecidas, seus
os valores são concatenados como parágrafos separados.

-t , --template =
Ao editar a mensagem de confirmação, inicie o editor com o conteúdo do arquivo fornecido.
A variável de configuração commit.template é freqüentemente usada para dar esta opção
implicitamente ao comando. Este mecanismo pode ser usado por projetos que desejam orientar
participantes com algumas dicas sobre o que escrever na mensagem e em que ordem. Se o
o usuário sai do editor sem editar a mensagem, o commit é abortado. Isso não tem
efeito quando uma mensagem é fornecida por outros meios, por exemplo, com as opções -m ou -F.

-s, --signoff
Adicione a linha Signed-off-by pelo committer no final da mensagem de log de commit. o
o significado de uma aprovação depende do projeto, mas normalmente certifica que o committer
tem o direito de enviar este trabalho sob a mesma licença e concorda com um desenvolvedor
Certificado de Origem (ver http://developercertificate.org/ para mais informações).

-n, --no-verify
Esta opção ignora os ganchos pre-commit e commit-msg. Veja também gitooks(5).

--permitir-vazio
Normalmente, gravar um commit que tem exatamente a mesma árvore que seu único commit pai é um
erro, e o comando o impede de fazer tal commit. Esta opção ignora
a segurança e é principalmente para uso por scripts de interface SCM estrangeiros.

--permitir-mensagem vazia
Como --allow-empty, este comando é principalmente para uso por scripts de interface SCM estrangeiros.
Ele permite que você crie um commit com uma mensagem de commit vazia sem usar encanamento
comandos como git-commit-tree(1).

--cleanup =
Esta opção determina como a mensagem de confirmação fornecida deve ser limpa antes
cometer. o pode ser tira, espaço em branco, palavra por palavra, tesoura ou padrão.

tira
Retire as linhas vazias iniciais e finais, espaços em branco finais, comentários e
recolher linhas vazias consecutivas.

espaço em branco
O mesmo que strip, exceto #commentary não é removido.

textualmente
Não mude a mensagem de forma alguma.

tesouras
O mesmo que o espaço em branco, exceto que tudo desde (e incluindo) a linha "#
------------------------> 8 ------------------------ "fica truncado se a mensagem
deve ser editado. "#" pode ser personalizado com core.commentChar.

omissão
O mesmo que remover se a mensagem for editada. Caso contrário, espaço em branco.

O padrão pode ser alterado pelo commit.limpeza variável de configuração (ver git-
configuração(1)).

-e, --editar
A mensagem obtida do arquivo com -F, linha de comando com -m e do objeto de confirmação com
-C são geralmente usados ​​como a mensagem de log de confirmação não modificada. Esta opção permite que você ainda mais
edite a mensagem tirada dessas fontes.

--Sem edição
Use a mensagem de confirmação selecionada sem lançar um editor. Por exemplo, git commit
--amend --no-edit corrige um commit sem alterar sua mensagem de commit.

- alterar
Substitua a ponta do branch atual criando um novo commit. A árvore gravada é
preparado como de costume (incluindo o efeito das opções -i e -o e explícita
pathspec), e a mensagem do commit original é usada como ponto de partida,
em vez de uma mensagem vazia, quando nenhuma outra mensagem é especificada na linha de comando
via opções como -m, -F, -c, etc. O novo commit tem os mesmos pais e autor que
o atual (a opção --reset-author pode contra-ordenar).

É um equivalente aproximado para:

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

mas pode ser usado para alterar um commit de mesclagem.

Você deve entender as implicações de reescrever o histórico se alterar um commit que
já foi publicado. (Veja a seção "RECUPERANDO DO UPSTREAM REBASE" em git-
rebase(1).)

- não pós-reescrita
Ignore o gancho pós-reescrita.

-i, --incluir
Antes de fazer um commit do conteúdo testado até agora, teste o conteúdo dos caminhos
fornecido na linha de comando também. Isso geralmente não é o que você quer, a menos que seja
concluindo uma mesclagem conflitante.

-o, --somente
Faça um commit pegando o conteúdo atualizado da árvore de trabalho dos caminhos especificados em
a linha de comando, desconsiderando qualquer conteúdo que tenha sido testado para outros caminhos.
Este é o modo padrão de operação de git commit se algum caminho for dado no
linha de comando, caso em que esta opção pode ser omitida. Se esta opção for especificada
Juntamente com - alterar, então nenhum caminho precisa ser especificado, o que pode ser usado para corrigir
o último commit sem comprometer as mudanças que já foram testadas.

-você[ ], --untracked-files [= ]
Mostrar arquivos não rastreados.

O parâmetro de modo é opcional (o padrão é todos os), e é usado para especificar o tratamento
de arquivos não rastreados; quando -u não é usado, o padrão é normal, ou seja, mostrar não rastreado
arquivos e diretórios.

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

· não - Não mostrar arquivos não rastreados

· normal - Mostra arquivos e diretórios não rastreados

· todos os - Também mostra arquivos individuais em diretórios não rastreados.

O padrão pode ser alterado usando a configuração status.showUntrackedFiles
variável documentada em git-config(1).

-v, --verboso
Mostrar a diferença unificada entre o commit HEAD e o que seria comprometido na parte inferior do
o modelo de mensagem de confirmação para ajudar o usuário a descrever a confirmação, lembrando o que
mudanças que o commit tem. Observe que esta saída diff não tem suas linhas prefixadas
com #. Este diff não fará parte da mensagem de confirmação.

Se especificado duas vezes, mostra além da diferença unificada entre o que seria comprometido
e os arquivos da árvore de trabalho, ou seja, as mudanças não testadas nos arquivos rastreados.

-q, --quieto
Suprimir mensagem de resumo de confirmação.

--funcionamento a seco
Não crie um commit, mas mostre uma lista de caminhos que devem ser confirmados, caminhos com
mudanças locais que não serão confirmadas e caminhos não rastreados.

--status
Inclui a saída de status do git(1) no modelo de mensagem de confirmação ao usar um
editor para preparar a mensagem de confirmação. O padrão é ativado, mas pode ser usado para substituir
variável de configuração commit.status.

--sem status
Não inclua a saída de status do git(1) no modelo de mensagem de confirmação ao usar
um editor para preparar a mensagem de confirmação padrão.

-S [ ], - sinal gpg [= ]
Confirmações de sinal GPG. O argumento keyid é opcional e o padrão é o committer
identidade; se especificado, ele deve ser preso à opção sem um espaço.

- no-gpg-sign
Countermand commit.gpgSign variável de configuração que é definida para forçar todos e cada
comprometa-se a ser assinado.

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

...
Quando os arquivos são fornecidos na linha de comando, o comando confirma o conteúdo do
arquivos nomeados, sem registrar as alterações já testadas. O conteúdo desses arquivos
também são encenados para o próximo commit além do que foi encenado antes.

INFORMAÇÃO FORMATOS

As variáveis ​​de ambiente GIT_AUTHOR_DATE, GIT_COMMITTER_DATE e a opção --date
suporta os seguintes formatos de data:

Formato interno Git
Isto é , Onde é o número de
segundos desde a época do UNIX. é um deslocamento positivo ou negativo
do UTC. Por exemplo, CET (que está 2 horas à frente do UTC) é +0200.

RFC 2822
O formato de e-mail padrão conforme descrito pela RFC 2822, por exemplo Thu, 07 Abr 2005
22:13:13 +0200.

ISO 8601
Hora e data especificadas pelo padrão ISO 8601, por exemplo 2005-04-07T22: 13: 13. o
o analisador também aceita um espaço em vez do caractere T.

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

EXEMPLOS

Ao gravar seu próprio trabalho, o conteúdo dos arquivos modificados em sua árvore de trabalho são
armazenado temporariamente em uma área de teste chamada "índice" com git adicionar. Um arquivo pode ser
revertido, apenas no índice, mas não na árvore de trabalho, para aquele do último commit
com git reset HEAD - , que efetivamente reverte git adicionar e evita as mudanças
para este arquivo de participar do próximo commit. Depois de construir o estado a ser
confirmado de forma incremental com esses comandos, git commit (sem qualquer parâmetro de nome de caminho)
é usado para registrar o que foi encenado até agora. Esta é a forma mais básica do comando.
Um exemplo:

$ editar olá.c
$ git rm adeus.c
$ git add olá.c
$ git commit

Em vez de preparar arquivos após cada mudança individual, você pode dizer ao git commit para notar
as mudanças nos arquivos cujo conteúdo é rastreado em sua árvore de trabalho e fazem
git add e git rm correspondentes para você. Ou seja, este exemplo faz o mesmo que o
exemplo anterior se não houver nenhuma outra mudança em sua árvore de trabalho:

$ editar olá.c
$ rm adeus.c
$ git commit -a

O comando git commit -a primeiro olha para sua árvore de trabalho, percebe que você modificou
hello.c e removido adeus.c, e executa git add e git rm necessários para você.

Depois de preparar mudanças em muitos arquivos, você pode alterar a ordem em que as mudanças são registradas,
dando nomes de caminho ao git commit. Quando nomes de caminho são fornecidos, o comando faz um commit
que registra apenas as alterações feitas nos caminhos nomeados:

$ editar olá.c olá.h
$ git add olá.c olá.h
$ editar Makefile
$ git commit Makefile

Isso faz um commit que registra a modificação no Makefile. As mudanças preparadas para
hello.c e hello.h não estão incluídos no commit resultante. No entanto, suas mudanças são
não perdidos - eles ainda são encenados e apenas retidos. Após a sequência acima, se você
Faz:

$ git commit

este segundo commit registraria as mudanças em hello.c e hello.h conforme o esperado.

Após uma fusão (iniciada por git fundir or git puxar) para por causa de conflitos, de forma limpa
caminhos mesclados já estão preparados para serem confirmados para você, e caminhos em conflito são
deixado no estado não mesclado. Você teria que primeiro verificar quais caminhos estão em conflito com git
estado e depois de corrigi-los manualmente em sua árvore de trabalho, você prepararia o resultado como
usual com git adicionar:

$ git status | grep não mesclado
não mesclado: hello.c
$ editar olá.c
$ git add olá.c

Depois de resolver os conflitos e preparar o resultado, git ls-files -u parava de mencionar
o caminho em conflito. Quando terminar, execute git commit para finalmente registrar a fusão:

$ git commit

Como no caso de registrar suas próprias alterações, você pode usar a opção -a para salvar a digitação. XNUMX
diferença é que durante uma resolução de mesclagem, você não pode usar git commit com nomes de caminho para
alterar a ordem em que as alterações são confirmadas, porque a fusão deve ser registrada como um
commit único. Na verdade, o comando se recusa a ser executado quando dados nomes de caminho (mas veja -i
opção).

DISCUSSÃO

Embora não seja obrigatório, é uma boa ideia começar a mensagem de confirmação com um único
(menos de 50 caracteres) linha resumindo a mudança, seguida por uma linha em branco e, em seguida, um
descrição mais completa. O texto até a primeira linha em branco em uma mensagem de confirmação é
tratado como o título do commit, e esse título é usado em todo o Git. Por exemplo, git-
patch de formato(1) transforma um commit em e-mail, e usa o título na linha de assunto e
o resto do commit no corpo.

O Git é, até certo ponto, agnóstico na codificação de caracteres.

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

· Os nomes de caminho são codificados no formato de normalização UTF-8 C. Isso se aplica a objetos de árvore,
o arquivo de índice, nomes de ref, bem como nomes de caminho em argumentos de linha de comando,
variáveis ​​de ambiente e arquivos de configuração (.git / config (ver git-config(1)), gitignore(5)
gitatributes(5) e módulos git(5)).

Observe que o Git no nível do núcleo trata os nomes de caminho simplesmente como sequências de não NUL
bytes, não há conversões de codificação de nome de caminho (exceto no Mac e Windows).
Portanto, o uso de nomes de caminho não ASCII funcionará principalmente mesmo em plataformas e arquivos
sistemas que usam codificações ASCII estendidas legadas. No entanto, os repositórios criados em
tais 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 que os nomes de caminho são
UTF-8 e não exibirá outras codificações corretamente.

· As mensagens de log de confirmação são normalmente codificadas em UTF-8, mas outras codificações ASCII estendidas
também são suportados. Isso inclui ISO-8859-x, CP125x e muitos outros, mas não
Codificações multibyte UTF-16/32, EBCDIC e CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc).

Embora encorajemos que as mensagens de log de confirmação sejam codificadas em UTF-8, tanto o núcleo quanto
Git Porcelain são projetados para não forçar UTF-8 em projetos. Se todos os participantes de um
projeto particular achar mais conveniente usar codificações legadas, Git não proíbe
isto. No entanto, há algumas coisas a serem lembradas.

1. git commit e git árvore de confirmação emite um aviso se a mensagem de log de confirmação fornecida a ele
não se parece com uma string UTF-8 válida, a menos que você diga explicitamente que seu projeto usa um
codificação legada. A maneira de dizer isso é ter i18n.commitencoding em .git / config
arquivo, assim:

[i18n]
codificação de confirmação = ISO-8859-1

Objetos de commit criados com a configuração acima registram o valor de i18n.commitencoding
em seu cabeçalho de codificação. Isso é para ajudar outras pessoas que olharão para eles mais tarde. Falta de
este cabeçalho implica que a mensagem de log de confirmação está codificada em UTF-8.

2. git log, git mostrar, git culpa e amigos olham para o cabeçalho de codificação de um commit
objeto e tente recodificar a mensagem de log em UTF-8, a menos que seja especificado de outra forma. Vocês
pode especificar a codificação de saída desejada com i18n.logoutputencoding em .git / config
arquivo, assim:

[i18n]
logooutputencoding = ISO-8859-1

Se você não tiver esta variável de configuração, o valor de i18n.commitencoding é
usado em seu lugar.

Observe que escolhemos deliberadamente não recodificar a mensagem de log do commit quando um commit é
feito para forçar UTF-8 no nível do objeto de confirmação, porque a recodificação para UTF-8 não é
necessariamente uma operação reversível.

MEIO AMBIENTE E CONFIGURAÇÃO VARIÁVEIS

O editor usado para editar a mensagem de log do commit será escolhido no GIT_EDITOR
variável de ambiente, a variável de configuração core.editor, o ambiente VISUAL
variável, ou a variável de ambiente EDITOR (nesta ordem). Ver git-var(1) para obter detalhes.

HOOKS

Este comando pode executar ganchos commit-msg, prepare-commit-msg, pre-commit e post-commit.
See gitooks(5) para mais informações.

Use git-commit online usando serviços onworks.net