Tout d’abord, faites la différence entre l’approbation et la signature. @nightfire a expliqué la signature. Laissez-moi vous expliquer (traduire) le sens de la signature.
Je n'ai pas vu « de nombreux projets open source nécessitent » l'approbation. Le plus connu est le noyau Linux. Sa documentation dit ceci :
11) Signez votre œuvre
Pour améliorer le suivi de qui a fait quoi, en particulier avec les correctifs qui peuvent s'infiltrer jusqu'à leur lieu de repos final dans le noyau à travers plusieurs couches de responsables, nous avons introduit une procédure de « signature » sur les correctifs qui sont envoyés par courrier électronique.
Parce que pendant le processus de développement de Linux, ils n'utilisent pas la "pull request" créée par GitHub, mais envoient des correctifs par courrier électronique (distribué) (git a donc un assez bon support pour le courrier électronique). Lorsque des correctifs sont envoyés dans les deux sens, vous devez les suivre, sinon cela sera mauvais comme l'a connu BSD et affectera le développement. « Signé par » est en fait une déclaration selon laquelle vous garantissez que le correctif que vous envoyez est conforme aux points du « Certificat d'origine du développeur 1.1 ».
Quelqu'un sur StackOverflow a déclaré qu'il ne s'agissait que d'une exigence pour quelques projets, et que la plupart des projets n'utilisent pas de signature.
PS : Si vous regardez les commits du noyau, vous pouvez parfois voir un commit avec une longue liste de signatures. Comment un seul contributeur et un seul auteur peuvent-ils suffire dans ce cas ?
La réponse simple est à vous de prouver que vous êtes vous !
Généralement, lors de la soumission, il y aura deux informations : l'auteur et le committer, généralement une seule personne (projet privé, dépôt central partagé).
À l'époque d'avant Github (par exemple, Git a d'abord été utilisé pour le développement collaboratif de Linux Core), la pull request à laquelle tout le monde est désormais habitué n'est pas si simple à gérer. À cette époque, les correctifs étaient souvent utilisés pour le développement distribué. Par exemple, vous envoyiez votre soumission (les informations sur l'auteur étaient générées à ce moment-là) au chef de projet/mainteneur sous forme de pièce jointe à un e-mail, puis il la fusionnait dans la bibliothèque centrale. (Ce sont les informations générées par le committer)......
Cependant, ni l'auteur ni l'auteur ne peuvent essentiellement prouver que la « personne » est la véritable personne qui a fait cette chose. Parce qu'il est trop facile de connaître le nom et l'email d'un développeur. Un patch envoyé en pièce jointe d'un email peut-il prouver que l'auteur est vous ? La personne qui reçoit l'e-mail et le fusionne peut-elle être sûre qu'elle est bien l'auteur du commit ? (En supposant qu'un projet a plusieurs gestionnaires/mainteneurs)
Ainsi, les personnes qui apprécient cela utiliseront les clés GPG pour les signatures sécurisées, c'est ce que vous avez demandé à propos de Sign Off. Il s'agit en fait d'une signature électronique. De nombreux clients de messagerie utilisent également cette méthode pour créer des signatures numériques.
J'ai essayé de le rendre aussi simple et clair que possible, mais en fait il y a plus de détails que vous ne l'imaginez. Si vous êtes intéressé, vous pouvez lire cet article : Une histoire d'horreur Git : intégrité du référentiel avec des validations signées, et ceci. article L'article n'a pas encore fini de parler de tout ce qui concerne Sign Off.
Un autre point de préoccupation est le suivant : de nombreux projets auront des licences, n'est-ce pas ? Mais vous pouvez utiliser du code tiers dans votre projet, et il est possible que les politiques de licence de ces codes s'excluent mutuellement/entrent en conflit avec la licence de ce projet. S'il s'agit d'un projet open source (comme vous l'avez demandé), vous accorderez plus d'attention à cet aspect (voulez-vous que d'autres vous poursuivent en justice ?). La Sign Off de Git peut être précise à la ligne, ce qui est une vérification de la véritable source du code (bien que la fiabilité soit discutable, c'est mieux que rien...). Je n’entrerai pas dans les détails, j’en ai juste entendu un peu parler.
Pour utiliser une signature, vous devez suivre les trois étapes les plus simples (basées sur Mac) :
Vous avez besoin du programme gunpg, Mac peut utiliser homebrew pour installer :
Vous devez générer votre clé GPG. Le processus est omis. Il se trouve dans l'article ci-dessus, une fois généré, cela ressemblera à ceci : <.>
Vous devez indiquer à Git quel est votre identifiant de clé (car vous pouvez avoir plusieurs clés en même temps) :
`git config --global user.signingkey KEY_ID`
这个 ID 就在第二步列表里可以找到
D'accord, désormais, si vous ajoutez
(notez la majuscule) à la commande git commit, votre signature numérique sera automatiquement attachée lorsque vous la soumettrez. Vous êtes qui vous êtes et refusez d'être contrefait ! -S
Selon l'astuce de @Evian, il y a une différence entre --sign-off et --gpg-sign Cela a des raisons historiques. Si vous êtes intéressé, vous pouvez lire les commentaires dans sa réponse. Les citations suivantes tirées des réponses de recherche Google :
-s ajoute un champ "signé par" au commit. -S en fait, GPG signe le commit, qui a été ajouté dans git 1.7.9. De plus, cela ne signe pas tous les commits, mais uniquement ceux qui. sont effectués par l'utilisateur directement à l'aide de la commande git c. Dans un rebase, lorsque de nouveaux commits sont créés, cela ne signera pas (ou ne signera pas PGP) les commits, sauf si vous effectuez un rebase interactif et validez manuellement chaque modification.
-S Vous pouvez faire les deux en même temps, c'est pourquoi cette option est recommandée dans la réponse précédente. Donc --sign-off n'est qu'une signature, et --gpg-sign est une signature utilisant une clé GPG.
OK, encore faux... -S Vous ne pouvez pas faire les deux en même temps Si vous voulez à la fois signature et signature, vous devez utiliser les deux ensemble.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Tout d’abord, faites la différence entre l’approbation et la signature. @nightfire a expliqué la signature. Laissez-moi vous expliquer (traduire) le sens de la signature.
Je n'ai pas vu « de nombreux projets open source nécessitent » l'approbation. Le plus connu est le noyau Linux. Sa documentation dit ceci :
Parce que pendant le processus de développement de Linux, ils n'utilisent pas la "pull request" créée par GitHub, mais envoient des correctifs par courrier électronique (distribué) (git a donc un assez bon support pour le courrier électronique). Lorsque des correctifs sont envoyés dans les deux sens, vous devez les suivre, sinon cela sera mauvais comme l'a connu BSD et affectera le développement. « Signé par » est en fait une déclaration selon laquelle vous garantissez que le correctif que vous envoyez est conforme aux points du « Certificat d'origine du développeur 1.1 ».
Quelqu'un sur StackOverflow a déclaré qu'il ne s'agissait que d'une exigence pour quelques projets, et que la plupart des projets n'utilisent pas de signature.
PS : Si vous regardez les commits du noyau, vous pouvez parfois voir un commit avec une longue liste de signatures. Comment un seul contributeur et un seul auteur peuvent-ils suffire dans ce cas ?
La réponse simple est à vous de prouver que vous êtes vous !
Généralement, lors de la soumission, il y aura deux informations : l'auteur et le committer, généralement une seule personne (projet privé, dépôt central partagé).
À l'époque d'avant Github (par exemple, Git a d'abord été utilisé pour le développement collaboratif de Linux Core), la pull request à laquelle tout le monde est désormais habitué n'est pas si simple à gérer. À cette époque, les correctifs étaient souvent utilisés pour le développement distribué. Par exemple, vous envoyiez votre soumission (les informations sur l'auteur étaient générées à ce moment-là) au chef de projet/mainteneur sous forme de pièce jointe à un e-mail, puis il la fusionnait dans la bibliothèque centrale. (Ce sont les informations générées par le committer)......
Cependant, ni l'auteur ni l'auteur ne peuvent essentiellement prouver que la « personne » est la véritable personne qui a fait cette chose. Parce qu'il est trop facile de connaître le nom et l'email d'un développeur. Un patch envoyé en pièce jointe d'un email peut-il prouver que l'auteur est vous ? La personne qui reçoit l'e-mail et le fusionne peut-elle être sûre qu'elle est bien l'auteur du commit ? (En supposant qu'un projet a plusieurs gestionnaires/mainteneurs)
Ainsi, les personnes qui apprécient cela utiliseront les clés GPG pour les signatures sécurisées, c'est ce que vous avez demandé à propos de Sign Off. Il s'agit en fait d'une signature électronique. De nombreux clients de messagerie utilisent également cette méthode pour créer des signatures numériques.
J'ai essayé de le rendre aussi simple et clair que possible, mais en fait il y a plus de détails que vous ne l'imaginez. Si vous êtes intéressé, vous pouvez lire cet article : Une histoire d'horreur Git : intégrité du référentiel avec des validations signées, et ceci. article L'article n'a pas encore fini de parler de tout ce qui concerne Sign Off.
Un autre point de préoccupation est le suivant : de nombreux projets auront des licences, n'est-ce pas ? Mais vous pouvez utiliser du code tiers dans votre projet, et il est possible que les politiques de licence de ces codes s'excluent mutuellement/entrent en conflit avec la licence de ce projet. S'il s'agit d'un projet open source (comme vous l'avez demandé), vous accorderez plus d'attention à cet aspect (voulez-vous que d'autres vous poursuivent en justice ?). La Sign Off de Git peut être précise à la ligne, ce qui est une vérification de la véritable source du code (bien que la fiabilité soit discutable, c'est mieux que rien...). Je n’entrerai pas dans les détails, j’en ai juste entendu un peu parler.
Pour utiliser une signature, vous devez suivre les trois étapes les plus simples (basées sur Mac) :
Vous avez besoin du programme gunpg, Mac peut utiliser homebrew pour installer :
Vous devez générer votre clé GPG. Le processus est omis. Il se trouve dans l'article ci-dessus, une fois généré, cela ressemblera à ceci :
<.>
D'accord, désormais, si vous ajoutez(notez la majuscule) à la commande
git commit, votre signature numérique sera automatiquement attachée lorsque vous la soumettrez. Vous êtes qui vous êtes et refusez d'être contrefait !-SSelon l'astuce de @Evian, il y a une différence entre
--sign-offet--gpg-signCela a des raisons historiques. Si vous êtes intéressé, vous pouvez lire les commentaires dans sa réponse. Les citations suivantes tirées des réponses de recherche Google :-SVous pouvez faire les deux en même temps, c'est pourquoi cette option est recommandée dans la réponse précédente. Donc--sign-offn'est qu'une signature, et--gpg-signest une signature utilisant une clé GPG.OK, encore faux...
-SVous ne pouvez pas faire les deux en même temps Si vous voulez à la fois signature et signature, vous devez utiliser les deux ensemble.