Qual è la differenza tra autore e committer in Git?

Mi sono appena imbattuto nel seguente commit su GitHub: https://github.com/felixge/node-formidable/commit/0a0b150668daa3c6f01626d2565b898e5da12392

Come si fa ad avere più autori sullo stesso commit in questo modo?

Non sono proprio due autori: è un autore e un committer. I due campi hanno significati diversi. L’autore è colui che ha creato il contenuto e il committer è colui che l’ha commesso. Quando esegui un commit normale, sei entrambi. (Entrambi sono dotati di email e timestamp associati).

Ma possono diventare diversi in pochi modi:

  • git format-patch / git am – questa coppia ti consente di trasformare i commit in patch, generalmente inviate via email, poi farle applicare da qualcun altro. Rimani l’autore; la persona che li applica è il committer. Questo è sicuramente quello che è successo su Github lì.

  • git commit --amend , git rebase , git filter-branch – Queste sono tutte fondamentalmente varianti della riscrittura della cronologia, che vanno dal singolo commit alla cronologia di un ramo all’intera cronologia. Possono potenzialmente modificare le informazioni del committer, in particolare, riscrivono sempre il timestamp del committer. L’autore originale rimane sul posto (nelle modalità di funzionamento predefinite), e se l’autore è anche quello che sta effettuando la riscrittura, il loro nome e l’e-mail rimangono, ma il timestamp è naturalmente diverso.

Non ci sono più autori associati a quel commit (né è attualmente ansible assegnare più autori a un singolo commit). In questo caso, gliese1337 era l’ autore , e felixge era il committer . Molto probabilmente, questo è accaduto perché gliese1337 ha presentato una richiesta di pull che è stata accettata e poi commessa da felixhe (il proprietario del repository). Quel stream di lavoro è piuttosto comune su GitHub. Ciò è utile anche nei casi in cui un manutentore del progetto riceve una patch via e-mail, quindi l’autore della patch stessa riceve ancora credito per la patch, anche se non ha accesso al progetto.

Un paio di link correlati:

Sezione Wiki Git breve sull’attribuzione dell’autore
Una richiesta di funzionalità per più funzionalità dell’autore in Git core

Non sono più autori. Uno è l’autore e un altro è il committer.

Se faresti un clone potresti vederlo chiaramente:

 $ git cat-file -p 0a0b150668daa3c6f016 tree 91edcb411b7cd0708c1f5bb05621846146c9425a parent 6b9ffe3653fe59f035b01ba1f46b5f2650be00ca author Logan Kearsley  1308937685 -0700 committer Felix Geisendo╠Иrfer  1309117893 +0200 Slight but definite & consistent performance boost. 

Interfaccia web Git come GitHub e GitLab

In tali sistemi, quando si unisce una patch, l’autore può o meno essere diverso dal committer a seconda delle impostazioni del repository.

Poiché Git (Hub | Lab) mantiene sia gli archivi upstream che gli archivi di fork su una stessa macchina, può fare automaticamente qualsiasi cosa tu possa fare anche localmente:

  • Creare un commit di unione.

    Non genera autore! = Committer.

    Mantiene intatto lo SHA o il nuovo commit e crea un nuovo commit:

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

    Storicamente, questo è stato il primo metodo disponibile su GitHub.

    A livello locale, questo è fatto con git merge --no-ff .

    Questo produce due commit per richiesta pull e mantiene un fork nella cronologia git.

  • rebase in cima al master

    Anche se questo non è obbligatorio in linea di principio, e nemmeno eseguito di default localmente da git rebase , GitHub esegue anche il commit dell’impegno per impostare committer == chi ha premuto il pulsante fusione.

    La ragione per fare questo, è che dà responsabilità al manutentore del progetto.

    L’albero git ora sembra:

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

    che è esattamente come quello del git apply patch di posta elettronica.

Attualmente su GitHub:

  • scegli il metodo durante l’unione tramite il menu a discesa sul pulsante di fusione
  • i metodi possono essere abilitati o disabilitati nelle impostazioni repo dal proprietario

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