Différence entre auteur et committer dans Git?

237

J'essaye de faire un commit comme

git commit --author="John Doe <[email protected]>" -m "<the usual commit message>"

où John Doe est un utilisateur au nom duquel je veux faire le commit.

Cela apparaît bien git log. Cependant, lorsque je fais un gitk, le nom de l'auteur est correct, mais le nom du committer est choisi dans mes paramètres de configuration git globaux (et est donc défini sur mon nom / email).

Des questions

  1. Quelle est la différence entre les deux (committer vs author)?

  2. Dois-je également définir le committer pour l'autre utilisateur?

  3. Si oui, comment?

git git-config gitk mu 無
la source
4
jasonnoble.org/2009/04/github-set-authorcommitter.html voici une courte description.
René Höhle
Duplication possible de Quelle est la différence entre l'auteur et le committer dans Git?
Marcin Armatys
Git committer est placé dans le fichier .gitconfig. Si vous --author est le même que le nom .gitconfig, vous obtenez uniquement l'auteur dans le message de validation. S'ils sont différents, vous obtenez les deux.
poGUIst

Réponses:

216

L'affiche originale demande:

Quelle est la différence entre les deux (Committer vs auteur)?

L'auteur est la personne qui a initialement écrit le code. Le committer, d'autre part, est supposé être la personne qui a commis le code au nom de l'auteur original. Ceci est important dans Git car Git vous permet de réécrire l'historique ou d'appliquer des correctifs au nom d'une autre personne. Le livre GRATUIT Pro Git en ligne l' explique comme ceci:

Vous vous demandez peut-être quelle est la différence entre l' auteur et le committer . L' auteur est la personne qui a écrit à l' origine le patch, alors que le validateur est la dernière personne qui a appliqué le patch. Donc, si vous envoyez un patch à un projet et que l'un des membres principaux applique le patch, vous obtenez tous les deux du crédit - vous en tant qu'auteur et le membre principal en tant que committer.

L'affiche originale demande:

Dois-je également définir le committer pour l'autre utilisateur?

Non, si vous voulez être honnête, vous ne devez pas définir le committer sur l'auteur, à moins que l'auteur et le committer ne soient en fait la même personne.


la source
1
Je suis toujours confus à ce sujet. Je l'avais fait, et dans mon cas, pour autant que je sache, aucun correctif ou réécriture de l'historique ne s'est produit (à moins que certaines commandes git ne créent et n'appliquent des correctifs, de manière opaque, "sous le capot"). Est-ce vraiment les deux seules façons pour que quelque chose comme ça se produise?
Cowlinator
2
Aussi, appeler l'auteur "la personne qui a écrit le code" n'a pas de sens. Comment git saurait-il qui l'a écrit? Quand vous définissez git config useret puis git addet git commit, alors git saurait qui a ajouté et qui a commis, mais il ne sait toujours pas qui l'a écrit.
cowlinator
1
@cowlinator Il ne sait pas qui a écrit le code. C'est pourquoi tu dois le dire, si ce n'est pas toi. Gardez à l'esprit que l'ancien système de contrôle de version distribué avant l'invention de git envoyait ~~ Linus ~~ les courriels du responsable du projet avec les correctifs à appliquer. Cette fonctionnalité est là pour que ~~ Linus ~~ le responsable puisse appliquer votre correctif tout en vous le créditant de manière «officielle», plutôt que juste ad-hoc dans le message de validation.
Fund Monica's Lawsuit
92

La liste de diffusion + git format-patch+ git applypeut générer un auteur! = Committer

Dans des projets comme le noyau Linux où les correctifs sont:

générer un nouveau commit unique avec différents auteurs et committers:

  • l'auteur est l'auteur du patch
  • le committer est qui est un mainteneur de projet et qui a fusionné le patch

Voir par exemple ce patch sélectionné au hasard et le commit correspondant:

Les interfaces Web Git comme GitHub et GitLab peuvent générer ou non author! = Committer

Étant donné que Git (Hub | Lab) détient à la fois les référentiels amont et fork sur une même machine, ils peuvent automatiquement faire tout ce que vous pouvez faire localement, y compris:

  • Créez un commit de fusion.

    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, cela se fait avec git merge --no-ff.

    Cela produit deux validations par demande de tirage et conserve une fourchette dans l'historique git.

  • rebaser au-dessus de master

    GitHub pirate également les commits pour définir committer == celui qui a appuyé sur le bouton de fusion. Ce n'est pas obligatoire, et ce n'est même pas fait par défaut localement par git rebase, mais cela donne la responsabilité au responsable du projet.

    L'arbre git ressemble maintenant à:

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

    qui est exactement comme celui des git applypatchs de messagerie.

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 sur les paramètres de mise en pension par le propriétaire

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

Comment définir le commit d'un nouveau commit?

Le mieux que j'ai pu trouver était d'utiliser les variables d'environnement pour remplacer le committer:

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

Comment obtenir le commit et la date de commit d'un commit donné?

Seules les données d'auteur s'affichent par défaut git log.

Pour voir la date de validation, vous pouvez soit:

  • formatez le journal spécifiquement pour cela:

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

    où cnet cdreprésenter Committer NameetCommitter Date

  • utilisez le fullerformat prédéfini:

    git log --format=fuller

    Voir aussi: Comment configurer 'git log' pour afficher la 'date de validation'

  • passer au niveau inférieur et afficher toutes les données de validation:

    git cat-file -p HEAD

Comment définir la date de validation d'un nouveau commit?

git commit --date ne définit que la date de l'auteur: pour la date de validation, le mieux que j'ai pu trouver était avec la variable d'environnement:

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

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

Comment Git stocke l'auteur vs committer en interne?

Voir: Quel est le format de fichier d'un objet git commit?

Fondamentalement, la validation est un fichier texte et contient deux champs séparés par des lignes:

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

Cela montre clairement que les deux sont deux entrées de données complètement indépendantes dans l'objet commit.

Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
la source
1
Notez que même avec des GIT_COMMITTER_*substitutions, git refusera toujours d'effectuer une validation si vous n'avez pas défini de commit par défaut à l'aide de git config.
adelphus
1
@adelphus sur Git 2.5, cela fonctionne si vous définissez les deuxGIT_{COMMITTER,AUTHOR}_EMAIL
Ciro Santilli 法轮功 冠状 病 六四 事件 法轮功
3

@Ciro Santilli 新疆 改造 中心 六四 事件 法轮功 a proposé d'utiliser

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

Pour éviter de répéter le nom et l'e-mail, vous pouvez les réutiliser

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

qui définit d'abord les variables dans des commandes distinctes, puis les utilise pour l' git commitappel (notez les doubles parenthèses).

serv-inc
la source