Quelle est la différence entre auteur et committer dans Git?

je viens de rencontrer la Commission suivante sur GitHub: https://github.com/felixge/node-formidable/commit/0a0b150668daa3c6f01626d2565b898e5da12392

Comment faire pour avoir plusieurs auteurs sur le même comité comme ça?

41
demandé sur Ciro Santilli 新疆改造中心 六四事件 法轮功 2011-07-20 04:51:51

4 réponses

ce n'est pas vraiment deux auteurs - c'est un auteur et un committer. Les deux champs ont des significations différentes. L'auteur est celui qui a créé le contenu, et le livreur est celui qui l'a commis. Quand vous faites un commit normal, vous êtes les deux. (Et les deux viennent avec un email associé et horodatage.)

mais ils peuvent devenir différents de quelques façons clés:

  • git format-patch / git am - cette paire vous permet de transformer les propagations en correctifs, généralement soumis par courriel, puis de demander à quelqu'un d'autre de les appliquer. Vous restez l'auteur; la personne qui les applique est le livreur. C'est ce qui s'est passé sur github.

  • git commit --amend , git rebase , git filter-branch - il s'agit essentiellement de variantes sur la réécriture de l'histoire, allant de la simple s'engager à l'histoire d'une branche à l'ensemble de l'histoire. Ils peuvent potentiellement modifier les informations du committer - en particulier, ils réécrivent toujours le committer timestamp . L'auteur original reste en place (dans les modes de fonctionnement par défaut), et si l'auteur est aussi celui qui fait la réécriture, son nom et son email restent, mais l'horodatage est naturellement différent.

50
répondu Cascabel 2018-06-25 18:09:16

il n'y a pas plusieurs auteurs associés à ce commit (il n'est pas non plus actuellement possible d'attribuer plusieurs auteurs à un seul commit). Dans ce cas, gliese1337 était auteur , et felixge était le committer . Très probablement, cela s'est produit parce que gliese1337 a soumis une demande de pull qui a été acceptée et ensuite engagée par felixhe (le propriétaire du dépôt). Ce flux est assez courant sur GitHub. C'est également utile pour les instances lorsqu' un responsable de projet reçoit un patch par e-mail, de sorte que l'auteur du patch lui-même reçoit toujours du crédit pour le patch, même s'il n'a pas l'accès commit au projet.

quelques liens apparentés:

courte section Wiki sur l'attribution d'auteur

une demande de fonctionnalité auteur multiple dans git core

6
répondu peterjmag 2011-07-20 01:04:22

il ne s'agit pas d'auteurs multiples. L'un est l'auteur et l'autre est le commettant.

si vous faites un clone, vous pouvez le voir clairement: 

$ git cat-file -p 0a0b150668daa3c6f016
tree 91edcb411b7cd0708c1f5bb05621846146c9425a
parent 6b9ffe3653fe59f035b01ba1f46b5f2650be00ca
author Logan Kearsley <chronosurfer@gmail.com> 1308937685 -0700
committer Felix Geisendo╠Иrfer <felix@debuggable.com> 1309117893 +0200

Slight but definite & consistent performance boost.
4
répondu Ivan Danilov 2011-07-20 00:55:03

interface web Git comme GitHub et GitLab

dans de tels systèmes, lors de la fusion d'un patch, l'auteur peut ou non être différent du committer en fonction des paramètres repo.

étant donné que Git(Hub|Lab) détient à la fois les dépôts en amont et les dépôts à fourche sur une même machine, il peut faire automatiquement tout ce que vous pouvez faire localement:

  • créer une fusion engager.

    ne génère pas d'auteur != committer.

    conserve le sha ou le nouveau commit intact, et crée un nouveau commit: 

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

    historiquement, C'était la première méthode disponible sur GitHub.

    localement, c'est fait avec git merge --no-ff .

    cela produit deux commits par pull request, et garde une fourchette dans l'histoire git.

  • rebase en haut de master

    bien que cela ne soit pas obligatoire en principe, et même pas fait localement par défaut par git rebase , GitHub pirate également les commits to set committer == quiconque a appuyé sur le bouton merge.

    la raison de faire cela, est qu'il donne la responsabilité au mainteneur de projet.

    L'arbre git ressemble maintenant à: 

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

    , qui est exactement comme celle de la git apply e-mail patches.

sur GitHub actuellement:

  • vous choisissez la méthode lors de la fusion via le menu déroulant sur le bouton de fusion
    • Les méthodes
  • peuvent être activées ou désactivées par le propriétaire sur les paramètres de repo.""

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

1
répondu Ciro Santilli 新疆改造中心 六四事件 法轮功 2018-03-06 03:59:16