Diferença entre autor e committer no Git?


237

Estou tentando fazer um commit como

git commit --author="John Doe <john@doe.com>" -m "<the usual commit message>"

onde John Doe é algum usuário em cujo nome eu quero fazer o commit.

Aparece bem git log. No entanto, quando eu faço a gitk, o nome do autor está correto, mas o nome do committer é escolhido nas minhas configurações globais de configuração do git (e, portanto, é definido como meu nome / email).

Questões

  1. Qual é a diferença entre os dois (committer x autor)?

  2. Devo estar definindo o committer também para o outro usuário?

  3. Se sim, como?




O commit do Git é colocado no arquivo .gitconfig. Se você --author for o mesmo nome .gitconfig, você receberá apenas o autor na mensagem de confirmação. Se eles são diferentes, você recebe os dois.
poGUIst

Respostas:


216

O pôster original pergunta:

Qual é a diferença entre os dois (Committer x autor)?

O autor é a pessoa que originalmente escreveu o código. O autor, por outro lado, é considerado a pessoa que cometeu o código em nome do autor original. Isso é importante no Git porque o Git permite reescrever o histórico ou aplicar patches em nome de outra pessoa. O livro Pro Git online GRATUITO explica assim:

Você pode estar se perguntando qual é a diferença entre autor e committer . O autor é a pessoa que originalmente escreveu o patch, enquanto o committer é a última pessoa que aplicou o patch. Portanto, se você enviar um patch para um projeto e um dos membros principais aplicá-lo, os dois receberão crédito - você como autor e o membro principal como committer.

O pôster original pergunta:

Devo estar definindo o committer também para o outro usuário?

Não, se você quiser ser honesto, não deve definir o autor como autor, a menos que o autor e o autor sejam realmente a mesma pessoa.


1
Eu ainda estou confuso sobre isso. Isso aconteceu e, no meu caso, até onde sei, nenhuma reescrita de patch ou histórico jamais ocorreu (a menos que alguns comandos git criem e apliquem patches, opaca, "sob o capô"). Essas são realmente as únicas duas maneiras de algo assim acontecer?
cowlinator

2
Além disso, chamar o autor de "pessoa que escreveu o código" não faz sentido. Como o git saberia quem o escreveu? Quando você define git config usere então git adde git commit, então o git sabe quem adicionou e quem cometeu, mas ainda não sabe quem o escreveu.
cowlinator

1
@ cowlinator Não sabe quem escreveu o código. É por isso que você precisa contar, se não é você. Lembre-se de que o sistema de controle de versão distribuído anterior antes da criação do git estava enviando ao Linus o e-mail do mantenedor do projeto com correções para aplicar. Essa funcionalidade existe para que o mantenedor possa aplicar seu patch enquanto ainda credita a você de uma maneira 'oficial', em vez de apenas ad-hoc na mensagem de confirmação.
Fund Monica's Lawsuit

92

A lista de discussão + git format-patch+ git applypode gerar author! = Committer

Em projetos como o kernel Linux, onde os patches são:

gerando um único novo commit com autor e commit diferentes:

  • o autor é quem escreveu o patch
  • o responsável é quem é o mantenedor do projeto e quem mesclou o patch

Veja, por exemplo, este patch selecionado aleatoriamente e o commit correspondente:

Interfaces da web Git como GitHub e GitLab podem ou não gerar author! = Committer

Como o Git (Hub | Lab) mantém os repositórios upstream e fork na mesma máquina, eles podem fazer automaticamente tudo o que você também pode fazer localmente, incluindo:

  • Crie uma consolidação de mesclagem.

    Não gera autor! = Committer.

    Mantém o SHA ou o novo commit intacto e cria um novo commit:

    * Merge commit (committer == author == project maintainer)
    |\
    | * Feature commit (committer == author == contributor)
    |/
    * Old master (random committer and author)
    

    Historicamente, esse foi o primeiro método disponível no GitHub.

    Localmente, isso é feito com git merge --no-ff.

    Isso produz duas confirmações por solicitação de recebimento e mantém uma bifurcação no histórico do git.

  • rebase em cima de master

    O GitHub também corta os commits para definir o commit == quem pressionou o botão de mesclagem. Isso não é obrigatório e nem mesmo é feito por padrão localmente git rebase, mas dá responsabilidade ao mantenedor do projeto.

    A árvore git agora se parece com:

    * Feature commit (committer == maintainer, author == contributor)
    |
    * Old master (random committer and author)    
    

    exatamente igual ao dos git applypatches de email.

No GitHub atualmente:

  • você escolhe o método ao mesclar através da lista suspensa no botão mesclar
  • métodos podem ser ativados ou desativados nas configurações de recompra pelo proprietário

https://help.github.com/articles/about-merge-methods-on-github/

Como definir o commit de um novo commit?

O melhor que pude encontrar foi usar as variáveis ​​de ambiente para substituir o commit:

GIT_COMMITTER_NAME='a' GIT_COMMITTER_EMAIL='a' git commit --author 'a <a>'

Como obter a data do commit e commit de um determinado commit?

Somente os dados do autor são exibidos por padrão em git log.

Para ver a data do committer, você pode:

  • formate o log especificamente para isso:

    git log --pretty='%cn %cd' -n1 HEAD
    

    onde cne cdrepresentam Committer NameeCommitter Date

  • use o fullerformato predefinido:

    git log --format=fuller
    

    Consulte também: Como configurar o 'git log' para mostrar a 'data de confirmação'

  • vá para baixo nível e mostre todos os dados de confirmação:

    git cat-file -p HEAD
    

Como definir a data do commit de um novo commit?

git commit --date define apenas a data do autor: para a data do commit, o melhor que pude encontrar foi com a variável de ambiente:

GIT_COMMITTER_DATE='2000-01-01T00:00:00+0000' git commit --date='2000-01-01T00:00:00+0000'

Veja também: Qual é a diferença entre autor e committer no Git?

Como o Git armazena o autor x o committer internamente?

Consulte: Qual é o formato do arquivo de um objeto de confirmação git?

Basicamente, o commit é um arquivo de texto e contém dois campos separados por linha:

author {author_name} <{author_email}> {author_date_seconds} {author_date_timezone}
committer {committer_name} <{committer_email}> {committer_date_seconds} {committer_date_timezone}

Isso deixa claro que ambas são duas entradas de dados completamente independentes no objeto de confirmação.


1
Observe que, mesmo com GIT_COMMITTER_*substituições, o git ainda se recusará a executar uma confirmação se você não tiver definido um commit padrão usando git config.
Adelphus

1
@adelphus em Git 2.5, ela não funciona se você definir tantoGIT_{COMMITTER,AUTHOR}_EMAIL
Ciro Santilli郝海东冠状病六四事件法轮功

3

@Ciro Santilli propôs usar

GIT_COMMITTER_NAME='a' GIT_COMMITTER_EMAIL='a' git commit --author 'a <a>'

Para evitar repetir o nome e o email, você pode reutilizá-los

GIT_COMMITTER_NAME='a'; GIT_COMMITTER_EMAIL='a'; git commit --author "$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"

que primeiro define as variáveis ​​em comandos separados e depois as utiliza para a git commitchamada (observe os parênteses duplos).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.