Gerrit/Tutoriel
Ceci est un tutoriel qui explique comment utiliser Git pour créer et modifier les corrections dans Gerrit.
- Pour les documents de référence sur les tâches spécifiques, consultez Gerrit/Utilisation avancée à la place.
- si vous voulez juste essayer Gerrit et que vous ne voulez pas écrire un patch pour un projet logiciel Wikimedia réel, utilisez notre instance de test Gerrit à la place.
Dans ce tutoriel, les commandes à entrer commencent par un signe dollar '$' dans une boîte, comme ceci : commande.
N'entrez pas le préfixe $.
Si une commande inclut aussi une variable que vous devez modifier personnellement, alors la variable s'affiche en rouge : commande variable.
Qu'est-ce que Git?
Git est un logiciel gratuit et ouvert de système distribué de contrôle des versions. Distribué signifie qu'il n'existe pas de copie centrale du dépôt. Avec Git, dès que vous avez cloné un dépôt, vous avez à votre disposition une copie complètement fonctionnelle de son code source, avec toutes ses branches et les versions labellisées.
Créer un compte Wikimedia développeur
Si vous n'avez pas encore de compte développeur Wikimedia, créez-le. Le même nom d'utilisateur et le même mot de passe seront utilisés pour vous connecter à Gerrit ci-dessous.
Configurer Git
Ces instructions vous expliquent comment instaler Git comme outil en mode ligne de commande (fenêtre de terminal). Si vous préférez une interface utilisateur graphique (GUI) au lieu de la commande en ligne, cochez la liste des clients maintenus par le projet Git. Pour d'autres instructions d'installation voir la documentation officielle.
Installation
Follow Installing Git to learn how to install git on your operating system.
Configurer Git
git config -l.Maintenant que Git est installé, c'est le moment de configurer vos informations personnelles. Vous n'avez à faire ceci qu'une seule fois. Vous pouvez aussi à tout instant modifier vos informations personnelles en exécutant ces commandes à nouveau.
Git enregistre les utilisateurs qui font des validations (commit) en contrôlant le nom d'utilisateur et son adresse courriel. En plus, cette information est utilisée pour associér vos validations à votre compte Gerrit.
Entrez les deux commandes ci-dessous pour définir votre noms d'utilisateur et votre adresse courriel. Remplacez Gerrituser par votre propre nom d'utilisateur Gerrit, gerrituser@example.com par votre propre adresse courriel, et shell_user par votre nom d'utilisateur tel qu'il est connu de votre shell (choisi quand le compte développeur Wikimedia a été créé) :
git config --global user.email "gerrituser@example.com"
git config --global user.name "Gerrituser"
git config --global url."ssh://shell_user@gerrit.wikimedia.org:29418/".insteadOf "https://gerrit.wikimedia.org/r/"
Définir les clés SSH dans Gerrit
Nous utilisons une clé SSH pour établir une connexion sécurisée entre votre ordinateur et Gerrit.
Depuis août 2021, l'équipe Wikimedia Sécurité recommande que les utilisateurs qui créent des clés SSH, utilisent le type ed25519 pour une sécurité optimale et pour des raisons de performance.
Obtenir votre clé SSH
Follow SSH keys#Generating a new SSH key.
Ajouter sa clé publique SSH à son compte Gerrit
- Connectez-vous à l'interface web de Gerrit. Votre nom d'utilisateur ainsi que le mot de passe de Gerrit sont les mêmes que ceux de votre compte développeur Wikimedia.
- Cliquez sur votre nom d'utilisateur dans le coin supérieur droit puis choisissez « Paramètres »
- Cliquez sur Clés SSH dans le menu de gauche.
- Collez votre clé publique SSH dans le champ correspondant et cliquez sur « ADD NEW SSH KEY ».
Tester la connexion SSH de Gerrit
Connectez-vous au serveur Gerrit via ssh pour vérifier si tout fonctionne correctement.
Remplacez shell_user par votre nom d'utilisateur du shell comme indiqué dans vos paramètres Gerrit :
ssh -p 29418 shell_user@gerrit.wikimedia.org
- Soyez consciencieux et vérifiez que « l'empreinte de la clé ed25519 » est la même que l'empreinte SSH pour gerrit.wikimedia.org:29418. Si c'est la cas, répondez « Yes » à la question « Are you sure you want to continue connecting ? ». Ensuite, entrez la phrase secrète de votre clé.
- Vous devrez obtenir un message « Welcome to Gerrit Code Review ». La dernière ligne doit afficher « Connection to gerrit.wikimedia.org closed. »
- Si vous rencontrez des difficultés, utilisez
ssh -p 29418 -v shell_user@gerrit.wikimedia.org(remplacez shell_user par votre nom d'utilisateur du shell). Le-vva fournir une sortie verbeuse pour aider à résoudre les problèmes. Ensuite lisez les résolutions des problèmes Gerrit.
Un exemple de message de connexion SSH Gerrit réussie ressemble à ceci :
gerrituser@machine:/mw/sandbox$ ssh -p 29418 gerrituser@gerrit.wikimedia.org The authenticity of host '[gerrit.wikimedia.org]:29418 ([208.80.154.85]:29418)' can't be established. ed25519 key fingerprint is dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1. Are you sure you want to continue connecting (yes/no)? yes Warning permanently added '[gerrit.wikimedia.org]:29418 ([208.80.154.85]:29418)' (ed25519) to the list of known hosts. Enter passphrase for key '/home/gerrituser/.ssh/id_ed25519': **** Welcome to Gerrit Code Review **** Hi gerrituser, you have successfully connected over SSH. Unfortunately, interactive shells are disabled. To clone a hosted Git repository, use: git clone ssh://gerrit.wikimedia.org:29418/REPOSITORY_NAME.git Connection to gerrit.wikimedia.org closed. gerrituser@machine:/mw/sandbox$
Télécharger le code avec Git
Bac à sable
Si vous voulez essayer d'utiliser Gerrit, vous pouvez télécharger (en « clonant ») le dépôt utilisé par ce tutoriel et appelé sandbox.
Exécutez ce qui suit, sur la ligne de commande Git Bash.
git clone https://gerrit.wikimedia.org/r/sandbox
Ceci va copier l'historique entière et la base de code du dépôt de l'extension « sandbox » sur votre machine.
Vous obtiendrez un répertoire de travail de la branche principale de l'extension (habituellement appelé « git master »).
Entrez le nouveau répertoire (via la comande cd sandbox)
Maintenant vous pouvez voir le code et commencer à le modifier.
Dépôts existants
En clonant le dépôt de Sandbox vous n'obtiendrez pas la configuration de l'environnement de développement ni une installation opérationnelle de MediaWiki. (Pour cela il vous faudra avoir le noyau MediaWiki et mettre le code que vous avez cloné à un endroit accessible par votre serveur web.) Voir Télécharger de Git comment télécharger le noyau MediaWiki, les extensions, les habillages, ou tout autre dépôt de projet de Git hébergé sur gerrit.wikimedia.org.
Vagrant
Si vous avez téléchargé MediaWiki ou les extensions en utilisant Vagrant, assurez-vous que vous avez configuré Git pour pousser votre code via SSH au lieu de HTTPS.
Se préparer à travailler avec Gerrit
Gerrit nécessite que votre message de validation possède un ID de modification.
Cela ressemble à Change-Id: Ibd3be19ed1a23c8638144b4a1d32f544ca1b5f97 en commençant par I (i majuscule).
A chaque fois que vous amendez une validation pour améliorer un patch existant dans Gerrit, cet ID de modification reste le même, donc Gerrit le conçoit comme un nouvel ensemble de corrections relatif à la même modification de code.
Il existe un greffon Git appelé git-review qui ajoute une ligne avec l'ID de modification à vos validations. L'utilisation de git-review est recommandée. Cela rend plus facile la configuration de votre clone de Git, pour soumettre une modification ou pour en rechercher une qui existe.
Installer git-review
Notez bien que Wikimedia Gerrit nécessite git-review version 1.27 ou plus récent.
Pour d'autres détails, veuillez lire l'installation.
Linux
- Utilisez l'outil graphique de gestion des paquets logiciels de votre distribution Linux pour installer le package
git-review. - Si git-review ne figure as dans votre distribution, allez sur git-review pour voir d'autres possibilités telles que l'installation de git-review en utilisant l'installateur Python de paquets 'pip'.
- Si vous utilisez FreeBSD, installez git-review au travers des ports.
Windows
- Veuillez lire git-review pour Windows.
macOS
- Pour OS X 10.11 El Capitan et ultérieur, appliquez la Méthode 1.
- Dans les versions antérieures à la 10.11, utilisez l'installateur de paquets Python pip en suivant la Méthode 2.
Configurer git-review
L'hôte distant par défaut de Git est « origin ». Ce nom est aussi utilisé par les projets Wikimedia. Il faut dire à git-review d'utiliser cet hôte. Remplacez gerrituser par votre nom d'utilisateur Gerrit :
git config --global gitreview.remote origin
git config --global gitreview.username gerrituser
Paramètrer git-review
Après avoir téléchargé un dépôt (cloné), vous devez l'activer pour git-review. Ceci se fait automatiquement la première fois que vous essayez de soumettre une validation, mais il est en général conseillé de le faire juste après avoir cloné. Vérifiez que vous êtes dans le répertoire du projet que vous avez cloné (sinon vous obtiendrez une erreur « fatal: Not a git repository » indiquant qu'il ne s'agit pas d'un répertoire Git). Puis exécutez cette commande :
git review -s --verbose
Vers la fin de la sortie, vous devriez voir quelque chose comme ceci :
Found origin Push URL: ssh://gerrit.wikimedia.org:29418/PROJECT Fetching commit hook from: scp://gerrit.wikimedia.org:29418/hooks/commit-msg 2019-02-19 12:40:16.712892 Running: scp -P29418 gerrit.wikimedia.org:hooks/commit-msg .git/hooks/commit-msg
Ceci peut vous demander votre nom d'utilisateur Git, s'il est différent du nom de l'utilisateur du shell que vous utilisez.
git-review, pour soumettre une correction, vous pouvez utiliser le téléverseur de patch Gerrit ou le tutoriel Gerrit/Web .Par défaut git-review utilise la branche master.
Si le dépôt sur lequel vous travaillez utilise une autre branche, par exemple main, vous devez définir la variable de configuration gitreview.branch.
Ceci peut être fait à l'aide de la commande suivante (où main est le nom de la branche) :
git config --add gitreview.branch main
Soumettre un patch
Assurez-vous d'avoir cloné le dépôt de code qui vous intéresse (voir le téléchargement via Git ci-dessus).
Vérifiez d'être dans le répertoire du dépôt de code (la commande pwd vous indique où vous vous trouvez exactement).
Mettre à jour la branche principale de développement
Assurez-vous que votre branche principale de développement (la branche créée lorsque vous avez initialement cloné le dépôt) est encore à jour :
git pull origin master
Notez néanmoins que certains dépôts utilisent un noms différent pour leur branche principale de développement (par exemple main au lieu de master, ou le dépôt operations/puppet a une branche production au lieu de master).
Créer une branche
Créez d'abord une branche locale pour votre nouvelle modification.
Remplacez BRANCHNAME ci-dessous par un nom court et suffisamment descriptif (par exemple T1234 si une tâche Phabricator correspondante existe pour vos modifications, cleanup-something, ou badtitle-error).
Les autres personnes utiliseront également ce nom pour identifier votre branche.
git checkout -b BRANCHNAME origin/master
gerrituser@example:~/dev/mw$ git checkout -b cleanup-something origin/master # Switched to a new branch 'cleanup-something' gerrituser@example:~/dev/mw$ git branch * cleanup-something master
Ceci va créer une nouvelle branche (appelée BRANCHNAME) à partir du dernier 'master' et l'ouvrir pour vous.
Dans l'exemple ci-dessus, nous avons appelé cette nouvelle branche cleanup-something.
Faire les modifications
Modifiez votre code local.
Utilisez votre éditeur de texte préféré et modifiez un fichier.
Dans l'exemple ci-dessous, nous modifions le fichier README.md en ajoutant un mot.
Puis fermez votre éditeur de texte et vérifiez les modifications que vous avez faites depuis la dernière validation, dans les fichiers eux-mêmes mais aussi dans le répertoire :
git diff
gerrituser@machine:/mw/sandbox$ git diff diff --git a/README.md b/README.md index 1d25b27..bc54021 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Hello world! -You can make test changes and experiment with Gerrit in this repository! +You can make test changes and experiment with Wikimedia Gerrit in this repository! Don't worry about messing this repository up; it is meant for testing. gerrituser@machine:/mw/examples$
git diff affiche vos modifications dans le format diff unifié: les lignes supprimées sont préfixées par un signe moins (-) et les lignes ajoutées sont préfixées par un signe plus (+).
Ces modifications ne sont pas encore « mises en réserve » (via git add) pour la validation prochaine.
Réserver les modifications avant de valider
Exécuter git status pour décider quels changements devront faire partie de votre validation.
Cela va afficher une liste de tous les fichiers que vous avez modifiés dans le répertoire.
A cette étape, la sortie va afficher « no changes added to commit » sur la dernière ligne.
Utilisez git add pour que le/les fichier(s) que vous avez modifiés fassent partie de votre prochaine validation.
Dans l'exemple ci-dessus nous avons modifié le fichier README.md, donc la commande sera :
git add README.md
Tout fichier modifié que vous n'avez pas passé à git add sera ignoré lorsque vous exécuterez git commit dans la prochaine étape.
git status.
Après avoir exécuté git add, git status ne va plus afficher la ligne « aucun changement ajouté pour la validation ».git diff --cached pour voir quelles modifications sont dans la réserve et qui feront partie de la prochaine validation.
La sortie sera la même que pour la commande git diff ci-dessus.
Valider les modifications en réserve
Dès que vous êtes satisfait des modifications ajoutées via git add, vous pouvez transformer ces modifications en une validation dans votre dépôt local en utilisant
git commit
Short subject line More details. The blank line between the subject and body is mandatory. The subject line is used to represent the commit in code-review emails, search results, git-rebase, and more. Bug: T999999 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch cleanup-something # Your branch is up to date with 'origin/master'. # # Changes to be committed: # modified: README.md
Ensuite, on vous demandera dans votre éditeur de texte d'ajouter un résumé descriptif de votre validation. Vous devez suivre les instructions du message de validation. C'est ce que les autres verront lorsqu'ils liront l'historique des modifications dans le dépôt du code.
Enregistrez le message de validation et fermez votre éditeur de texte. Un sommaire (l'ID de la validation, votre ligne du sujet, les fichiers et les lignes modifiées) sera affiché.
Lorsque vous git commit, vous validez (commit) votre copie locale.
Préparer la publication de la validation dans Gerrit
Synchronisez votre ensemble de corrections avec toute modification qui aurait déjà pu être faite sur la branche maître alors que vous étiez en train de travailler (c'est le rebasing). A partir de votre branche, exécutez :
git pull --rebase origin master
gerrituser@machine:/mw/sandbox$ git pull --rebase origin master From ssh://gerrit.wikimedia.org:29418/sandbox * branch master -> FETCH_HEAD Current branch cleanup-something is up to date. gerrituser@machine:/mw/sandbox$
git pull --rebase origin master va récupérer les nouvelles validations du distant et va les appliquer (rebase) sur vos validations locales.
Cela va temporairement mettre de côté les modifications que vous avez faites dans votre branche, et appliquer à votre branche de travail l'ensemble des modifications apparues sur la branche maître; ensuite cela va fusionner (recommit) toutes les modifications que vous avez faites à nouveau dans la branche. En faisant cela, vous éviterez les conflits lors des fusions à venir.
De plus, cela vous donne une possibilité de tester vos modifications sur le dernier code de la branche maître.Vous êtes maintenant prêt à mettre votre code dans Gerrit pour la relecture de code. Si vous avez fait plusieurs validations liées, vous devez les fusionner en une seule validation pour la revue.
Placer vos validations dans Gerrit
Si vous avez suivi les indications ci-dessus et que vous avez installé git-review et exécuté git review -s, alors la commande pour mettre les modifications dans Gerrit est :
git review -R
L'option -R indique à l'outil git-review de ne pas faire de rebase avant de soumettre la modification à Gerrit.
gerrituser@machine:/mw/sandbox$ git review -R Creating a git remote called 'gerrit' that maps to: ssh://gerrit.wikimedia.org:29418/sandbox.git Your change was committed before the commit hook was installed. Amending the commit to add a gerrit change id. remote: remote: Processing changes: new: 1, done remote: remote: New Changes: remote: https://gerrit.wikimedia.org/r/#/c/sandbox/+/563720 Test for https://www.mediawiki.org/wiki/Gerrit/Tutorial remote: To ssh://gerrit.wikimedia.org:29418/sandbox.git * [new branch] HEAD -> refs/for/master%topic=cleanup-something gerrituser@machine:/mw/examples$
Si tout se passe bien, vous recevrez une confirmation et un lien vers l'ensemble de corrections dans Gerrit. Dans l'exemple ci-dessus, ce lien est : https://gerrit.wikimedia.org/r/#/c/sandbox/+/563720
Bravo ! Votre patch est dans Gerrit et nous l'espérons, sera relu bientôt!
Echec de git review -R
Si on vous demande d'entrer vos données personnelles (nom d'utilisateur et mot de passe) après avoir lancé git review -R, cela signifie que Git n'a pas encore été configuré pour utiliser SSH.
Review the steps at #Set up Git. In particular, run the following command:
git config --global url."ssh://shell_user@gerrit.wikimedia.org:29418/".insteadOf "https://gerrit.wikimedia.org/r/"
Il n'y a pas de problème à le refaire si vous ne vous souvenez pas l'avoir déjà fait. Remplacez shell_user par le nom d'utilisateur du shell pour votre compte développeur Wikimedia.
If you get a Permission denied (publickey). fatal: Could not read from remote repository., review the instructions at Clés SSH to make sure your ssh agent is running and your identity is added. Si vous fermez la fenêtre de votre shell Git Bash, vous serez déconnecté et devrez suivre à nouveau ces instructions.
Afficher les modifications / Etapes suivantes
Ouvrez le lien vers votre ensemble de modifications de Gerrit dans un navigateur web.
Sous « Fichiers », après avoir cliqué sur la flèche vers le bas à l'extrémité droite de chaque fichier de la liste, vous pouvez voir un diff de vos modifications par fichier : les anciennes lignes sont affichées en rouge et vos nouvelles lignes sont en vert.
Si votre validation a généré un ticket dans Phabricator, un commentaire sera automatiquement ajouté dans la tâche Phabricator si vous avez suivi les indications du message de validation. Si vous ne l'avez pas fait, vous pouvez soit corriger votre message de validation (en créant un ensemble de corrections mis à jour), ou en ajoutant manuellement un commentaire sur ce ticket Phabricator qui inclut un lien vers votre ensemble de corrections dans Gerrit.
Autres situations communes
Voir aussi l'usage avancé de Gerrit si votre cas n'est pas traité ici.
Rassembler plusieurs validations en une seule avec rebase
Si vous faites plusieurs validations liées sur votre répertoire local avant de vouloir les soumettre pour relecture, vous devrez rassembler ces validations (merge) dans une validation unique.
L'option --interactive ou -i vous permet de modifier (corriger) l'historique de votre validation.
Pour chaque validation, vous pouvez modifier et changer le message associé, ajouter ou supprimer des fichiers, ou réaliser d'autres modifications.
D'abord vous devez dire à Git jusque où vous voulez remonter en arrière. Pour obtenir une liste de toutes les modifications réalisées sur votre branche :
git rebase -i origin/master
Vous pouvez également limiter la liste des dernières modifications affichées. HEAD~3 signifie retirer les trois dernières validations :
git rebase -i HEAD~3
Après avoir entré cette commande, votre éditeur de texte affichera vos modifications dans l'ordre inverse ainsi qu'une liste de commandes utilisables :
pick aa8cf1d Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. pick 38828e2 Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php pick be33007 Fix a typo # Rebase 95ccd28..be33007 onto 95ccd28 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. #
Si nous voulons seulement envoyer en relecture une seule validation, nous allons inclure les deux dernières validations dans la première. A partir de là, changer tout en « squash » sauf le premier « pick » :
pick aa8cf1d Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. squash 38828e2 Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php squash be33007 Fix a typo
Lorsque vous avez terminé avec les « pick » et les « squash » et que vous avez enregistré le ficher, un autre fichier va s'ouvrir dans votre éditeur de texte pour que vous puissiez modifier et fusionner vos messages de validation. Vérifiez à ne garder qu'une seule des lignes comportant un identificateur de changement tout en bas du message et gardez-la précédée d'une ligne vide.
Les messages correspondants à vos validations précédentes seront automatiquement placés dans ce message :
# This is a combination of 3 commits. # The first commit's message is: (mingle-fr-2012-69) Adding a custom filter for risky countries. Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter. # This is the 2nd commit message: Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php # This is the 3rd commit message: Fix a typo Change-Id: I33e44ec0d93628d9a53c15e08eb89f352b7d5fe0 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: donationinterface.php # modified: gateway_common/gateway.adapter.php #
N'oubliez pas de mettre votre message de résumé (mis à jour) dans la validation. Dans ce cas le nouveau message de résumé sera :
(mingle-fr-2012-69) Adding a custom filter for risky countries.
Si tout se passe bien, vous devriez voir un message rebase de succès :
[detached HEAD 02f5e63] (mingle-fr-2012-69) Adding a custom filter for risky countries. 2 files changed, 92 insertions(+), 3 deletions(-) Successfully rebased and updated refs/heads/mingle-fr-2012-69.
Après cela, envoyez votre patch pour relecture :
git review
Vous devriez voir un message comme celui-ci indiquant que votre revue Git est partie sur Gerrit (dans cet exemple, vers https://gerrit.wikimedia.org/r/7187) :
remote: Resolving deltas: 100% (4/4) remote: (W) 02f5e63: commit message lines >70 characters; manually wrap lines remote: remote: New Changes: remote: https://gerrit.wikimedia.org/r/7187 remote: To ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface.git * [new branch] HEAD -> refs/for/master/mingle-fr-2012-69
Amender une correction (la vôtre, ou celle d'une autre personne)
Quelque fois vous pourriez avoir à amender une modification soumise. Vous pourvez amender une modification tant que celle-ci n'a pas encore été fusionnée.
Vous pouvez amender vos propres modifications. Pour amender les corrections soumises par une autre personne, vous devez être un membre du groupe des contributeurs confirmés (Trusted-Contributors) de Gerrit. Pour faire partie des Trusted-Contributors, recherchez quelqu'un qui est déjà membre de ce groupe et demandez-lui de vous y ajouter. Le groupe est viral dans le sens où les membres eux-mêmes peuvent ajouter les nouveaux candidats; utilisez vos droits sous votre responsabilité.
Commande rebase
Faites un « rebase » pour remettre à jour votre branche locale avec le contenu actuel du distant. Il est mieux de faire la mise à jour d'une correction séparée, à l'aide d'un rebase de sorte à ce que vos relecteurs aient le temps de voir les modifications que vous avez faites. En supposant que vous utilisez Gerrit, vous pouvez faire cela en cliquant sur le bouton de mise à jour par rebase (Rebase Change) lorsque vous affichez votre correction dans l'interface web de Gerrit.
Réinitialiser le matériel et extraire les modifications avec cette commande :
(ATTENTION : git review -d provoque une réinitialisation du système qui fait perdre toutes les modifications locales. Mettez d'abord en réserve ou validez les modifications que vous voulez mettre de côté ! )
git review -d changeNumber Par exemple : git review -d 814356
Voir changeNumber dans Gerrit. Il s'agit du numéro à six chiffres dans l'URL de votre page de revue de code.
Notez que si vous avez déjà la modification présente dans une branche de votre dépôt local, il suffit de l'ouvrir (check out) à la place :
git checkout BRANCHNAME Par exemple : git checkout review/gerrituser/2012/bug12345
Faites vos modifications puis push
Ensuite, faites quelques modifications avec votre éditeur de texte favori.
git add les fichiers si nécessaire, ensuite validez les modifications (en vérifiant de bien amender la validation) :
git add Example/Example.body.php
git commit --amend
-m pour spécifier un résumé de validation : cela va réécraser le résumé précédent et regénérer le Change-Id.
A la place, utilisez l'éditeur de texte pour modifier le résumé de la validation (dans le fichier .git/COMMIT_EDITMSG si nécessaire, et laissez la ligne Change-Id intacte.Validez la modification :
git review -R
Le -R est important ici.
Cela indique à git-review de ne pas faire un rebase de vos modifications sur la branche master , ce qui somme les diff entre les patchs 1 et 2.
Pousser sur une branche différente de la branche master
Ci-dessus, la validation a été poussée sur la branche master.
Seul le nom de la branche apparait comme sujet de la validation dans l'interface utilisateur Gerrit.
Si vous voulez réellement pousser sur une branche différente du master, vous devrez pousser via git review <branch name>.
Résolution des problèmes
Pour les problèmes et la manière de les résoudre, voir Gerrit/Dépannage.
Voir aussi
Les pages suivantes sont également utiles :
Guides tiers à propos de Git
- Tutoriels vidéo sur la manière d'utiliser Git (sur Wikimedia Commons)
- Essayer Git (démonstration interactive)
- GitMagic un guide Git avec des traductions
- Livre de la communauté Git pour vous introduire progressivement aux fonctionnement interne de Git. (Il est difficile de posséder Git tant que l'on en connait pas un peu le fonctionnement interne.)
- Site web de Git avec la documentation
- Un autre guide Git utile de OpenStack (avec un partie GitHub)
- Comprendre le flux de travail de Git par Benjamin Sandofsky
- Utiliser Git sous Eclipse