Jump to content

Gerrit/מדריך

From mediawiki.org
This page is a translated version of the page Gerrit/Tutorial and the translation is 33% complete.
Outdated translations are marked like this.
אם יש לך ניסיון כלשהו עם שורת הפקודות ו־Git, אפשר להשתמש במדריך המקוצר במקום.

המדריך הזה יסביר איך להתקין את Git ולהשתמש בו כדי ליצור ולשנות בקשות לשינוי ב־Gerrit.

  • לתיעוד סימוכין על משימות מסוימות, כדאי לפנות אל Gerrit/Advanced usage במקום.
  • אם מעניין אותך לתרגל איך להשתמש ב־Gerrit בלי לכתוב טלאי למיזם תוכנה „אמיתי” של ויקימדיה, אפשר להשתמש בעותק ה־Gerrit לבדיקות שלנו במקום.

במדריך הזה, הפקודות לביצוע מתחילות בדולר בתוך תיבה, באופן הזה: פקודה. אין להוסיף את הקידומת $.
אם פקודה כוללת משתנה שצריך לשנות בעצמך, אז המשתנה יופיע באדום: פקודה משתנה.

מה זה Git?

Git היא מערכת בקרת גרסאות מבוזרת חופשית ובקוד פתוח. המשמעות של „מבוזרת” היא שאין עותק מרכזי של המאגר. עם Git, לאחר ששיבטת את המאגר, יש לך עותק מתפקד לחלוטין של קוד המקור, עם כל הענפים והמהדורות המתיוגות לרשותך.

יצירת חשבון פיתוח בוויקימדיה

אם אין לך עדיין חשבון פיתוח בוויקימדיה עדיין, אפשר ליצור אחד. אותו שם המשתמש והסיסמה ישמשו אותך להיכנס ל־Gerrit שלהלן.

הגדרת Git

ההנחיות האלו תסברנה לך איך להתקין את Git ככלי שורת פקודות (חלון מסוף). אם יותר נוח לך לעבוד עם ממשק משתמש גרפי (GUI) במקום שורת הפקודות, אפשר לפנות אל רשימת תוכנות הלקוח שמתוחזקות על ידי מיזם Git. להנחיות התקנה חלופיות ניתן לפנות לתיעוד הרשמי.

התקנה

יש לעקוב אחר ההנחיות תחת התקנת Git כדי ללמוד איך להתקין את Git על מערכת ההפעלה שלך.

הגדרת Git

כדי להציג את כל משתני ההגדרות ש־Git משתמש בהן, יש להריץ את הפקודה git config -l.

עכשיו כש־Git מותקן, הגיע הזמן להגדיר את הפרטים האישיים שלך. צריך לבצע את זה רק פעם אחת. אפשר גם לשנות את הפרטים האישיים שלך בכל עת על ידי הרצת הפקודות האלה שוב.

Git עוקב אחר הגורמים שמבצעים את כל אחד מהקיבועים על ידי בדיקת השם והדוא״ל של המשתמש. בנוסף, הפרטים האלו משמשים לשיוך הקיבועים שלך לחשבון ה־Gerrit שלך.

יש להריץ את שתי הפקודות שלהלן כדי להגדיר את שם המשתמש ואת כתובת הדוא״ל שלך.

  • gerrituser@example.comיש להחליף את $2 בכתובת הדוא״ל שלך.
  • My NameThe name Git records as the author of your commits. This does not have to match your Wikimedia Developer account username.
  • shell_userוגם, להחליף את $3 בשם המעטפת (shell - בחרת אותו כשיצרת את חשבון הפיתוח שלך בוויקימדיה):
  • Gerrituserיש להחליף את $1 בשם המשתמש של חשבון הפיתוח שלך בווקימדיה (לשעבר נודע בתור שם משתמש ב־„Wikitech”,‏ „Gerrit” או „LDAP”, כולם מתייחסים לאותו הדבר).

git config --global user.email "gerrituser@example.com"

git config --global user.name "My Name"

git config --global url."ssh://shell_user@gerrit.wikimedia.org:29418/".insteadOf "https://gerrit.wikimedia.org/r/"

git config --global gitreview.remote origin

git config --global gitreview.username Gerrituser

הגדרת מפתחות SSH ב־Gerrit

אנחנו משתמשים במפתח SSH כדי להקים חיבור מאובטח בין המחשב שלך לבין Gerrit. צוות האבטחה של ויקימדיה ממליץ, נכון לאוגוסט 2021, שמשתמש שיוצרים מפתחות SSH ישתמשו בסוג ed25519 לאבטחה וביצועים מיטביים.

השגת מפתח ה־SSH שלך

יש לפעול לפי מפתחות SSH#יצירת מפתח SSH חדש.

הוספת מפתח SSH ציבורי לחשבון ה־Gerrit שלך

  • להיכנס לאתר התפעול של Gerrit. שם המשתמש והסיסמה של ה־Gerrit שלך זהים לאלו של חשבון הפיתוח שלך בוויקימדיה.
  • יש ללחוץ על שם המשתמש שלך בפינה הימנית העליונה, ואז לבחור ב־„Settings”.
  • ללחוץ על „SSH Keys” (מפתחות SSH) בתפריט משמאל.
  • להדביק את מפתח ה־SSH הציבורי שלך לשדה המתאים וללחוץ על „ADD NEW SSH KEY”.

נא לשים לב שחובה להוסיף את מפתחות ה־SSH שלך באתר התפעול של Gerrit דרך gerrit.wikimedia.org אפילו אם כבר הוספת אותם בCloud VPS / מנהל הזהות ב־Toolforge דרך idm.wikimedia.org. אלו מערכות נפרדות ואינן חולקות מפתחות SSH.

בדיקת חיבור ה־SSH ל־Gerrit

אפשר להתחבר לשרת ה־Gerrit דרך ssh כדי לראות אם הכול עובד כמצופה. יש להחליף את shell_user בשם משתמש המעטפת (shell) שלך כפי שמופיע בהגדרות ה־Gerrit שלך:

ssh -p 29418 shell_user@gerrit.wikimedia.org
  • חשוב לשים לב ולהשוות ש„טביעת אצבע מפתח ה־ed25519” זהה ל[$1 טביעת מפתח ה־SSH עבור gerrit.wikimedia.org:29418]. אם הן אותו הדבר, יש לענות „Yes” (כן) על השאלה „Are you sure you want to continue connecting?‎” (להמשיך להתחבר?). לאחר מכן למלא את ביטוי הצופן של המפתח שלך.
  • אמורה להופיע ההודעה „Welcome to Gerrit Code Review”. השורה אחרונה אמורה להיות „Connection to gerrit.wikimedia.org closed.‎” (החיבור אל … נסגר.)
  • אם צצות כל מיני בעיות, יש להשתמש ב־ssh -p 29418 -v shell_user@gerrit.wikimedia.org (להחליף את shell_user בשם משתמש המעטפת/shell שלך). -v יספק פלט מפורט כדי לסייע לך למצוא בעיות. לאחר מכן לקרוא את פתרון בעיות ב־Gerrit.

דוגמה להודעה הצלחת חיבור SSH נראית ככה:

Example:

הורדת קוד עם Git

ארגז חול

If you would like to practise using Gerrit you can download (also called "cloning") the repository this tutorial uses called "sandbox".

Run the following on the Git Bash command line:

git clone https://gerrit.wikimedia.org/r/sandbox

This will copy the entire history and the code base of the "sandbox" extension repository into your machine. You will have a working directory of the extension's main branch (usually also called "git master"). Enter the new directory (via the command cd sandbox). Now you can look at the code and start editing it.

Existing repositories

Cloning the Sandbox repository will not give you a development environment setup or a running MediaWiki installation. (Running will require MediaWiki Core and placing the code you checked out in a location expected by your web server.) See Download from Git for how to download MediaWiki Core, extensions, skins, or any other project repository hosted at gerrit.wikimedia.org from Git.

Vagrant

If you have downloaded MediaWiki or extensions using Vagrant, make sure you have configured Git to push code using SSH instead of HTTPS.

Prepare to work with Gerrit

עמוד ראשי: Gerrit/git-review

Gerrit requires that your commit message must have a "change ID". They look like Change-Id: Ibd3be19ed1a23c8638144b4a1d32f544ca1b5f97 starting with an I (capital i). Each time you amend a commit to improve an existing patch in Gerrit, this change ID stays the same, so Gerrit understands it as a new "patch set" to address the same code change.

There's a Git add-on called git-review that adds a Change-Id line to your commits. Using git-review is recommended. It makes it easier to configure your Git clone, to submit a change or to fetch an existing one.

Installing git-review

For more details, please see Gerrit/git-review#Installation.

Linux

Windows

macOS

  • For OS X 10.11 El Capitan and later, follow Method 1.
  • On versions prior to 10.11, use the pip Python package installer by following Method 2.

Setting up git-review

After downloading ("cloning") a repository, you need to set it up for git-review. This will automatically happen the first time you try to submit a commit, but it's generally better to do it right after cloning. Make sure that you are in the directory of the project that you cloned (otherwise you will get an error "fatal: Not a git repository"). Then run this command:

git review -s --verbose

Towards the end of the output, you should see something like this:

Example:

Or something like this if you are on a newer version of git-review:

Example:

This may ask you for your Git username, if it's different from the shell username you're using.

If you could not install git-review, then you could use the Gerrit patch uploader or Gerrit/Web tutorial to submit a patch.

By default git-review uses the branch master. If the repo you're working on uses another branch, e.g. main, you need to set the config variable gitreview.branch. This can be done with the following command (where main is the branch name):

git config --add gitreview.branch main

Submit a patch

Make sure that you cloned the code repository that you are interested in (see Download code using Git above).

Make sure that you are in the directory of the code repository (the command pwd tells you where exactly you are).

Update the main development branch

Make sure that the main development branch (the branch created when you initially cloned the repository) is up to date:

git pull origin master

However, note that some repositories use a different name for their main development branch (for example main instead of master, or the operations/puppet repository has a production instead of a master branch).

Create a branch

First, create a local branch for your new change. Replace branch-name below by a short but reasonably descriptive name (e.g. T1234 if a corresponding Phabricator task exists for your changes, cleanup-something, or badtitle-error). Other people will also use this name to identify your branch.

git checkout -b branch-name origin/master

Example:

This will create a new branch (called branch-name) from the latest 'master' and check it out for you. In the example above, we called that new branch cleanup-something.

Make your changes

Make changes to your local code. Use your preferred text editor and modify a file. In the example below, we edit the file README.md and add a word.

Then close your text editor and check the changes you have made since the last commit, within the file(s) and within the directory:

git diff

Example:

git diff displays your changes in unified diff format: Removed lines have a minus (-) prefix and added lines have a plus (+) prefix. These changes are not yet "staged" (via git add) for the next commit.

Stage your changes for a commit

Run git status to decide which of your changes should become part of your commit. It will display a list of all file(s) that you have changed within the directory. At this point, the output will display "no changes added to commit" as the last line.

Use git add to make your changed file(s) become part of your next commit. In the example above we modified the file README.md, so the command would be:

git add README.md

Any files you've changed that you have not passed to git add will be ignored when running git commit in the next step.

At any time you can always review the changes already staged by running git status. After you ran git add, git status will not show the line "no changes added to commit" anymore.
You can also use git diff --cached to see which changes are staged and will go into the next commit. The output will look the same as for the git diff command above.

Commit your staged changes

Once you are happy with the list of changes added via git add, you can turn these changes into a commit in your local repository by using

git commit

sandbox/.git/COMMIT_EDITMSG:

You will then be asked in your text editor to add a descriptive summary for your commit. חובה לפעול לפי כללי הודעות הקיבוע. זה מה שאנשים אחרים רואים כשהם מסתכלים על היסטוריית השינויים במאגר הקוד.

יש לשמור את הודעת הקיבוע ולסגור את עורך הטקסט. יוצג תקציר (מזהה הקיבוע, שורת הנושא שלך, הקבצים והשורות שהשתנו).

אפשר לחזור על השלב הזה שוב ושוב עד שיש לך ערכת שינויים שמיועדת למיזוג לענף ה־master.

בעת ביצוע git commit, מתבצע קיבוע לעותק המקומי שלך.

משמעות הדבר היא שאפשר לקבע כמה שרוצים מבלי לדפוק דברים למפתחים אחרים במיזם.

הכנה לדחוף את הקיבוע שלך ל־Gerrit

יש לסנכרן את ערכת השינויים שלך עם שינויים כלשהם שאולי קרו בענף ה־master תוך כדי העבודה שלך („rebasing” - ביסוס מחדש). מתוך הענף שלך, להריץ את הפקודה:

git pull --rebase origin master
Example:
git pull --rebase origin master ימשוך קיבועים חדשים מהצד המרוחק ואז יבסס מחדש (rebase) את הקיבועיים המקומיים שלך על גביהם.

It will temporarily set aside the changes you've made in your branch, apply all of the changes that have happened in master to your working branch, then merge (recommit) all of the changes you've made back into the branch. Doing this will help avoid future merge conflicts.

Plus, it gives you an opportunity to test your changes against the latest code in master.

Now you are ready to push your code to Gerrit for review. If you made several related commits, consider merging them into one single commit for review.

Push your commit to Gerrit

If you followed #Prepare to work with Gerrit above and installed git-review and ran git review -s, then the command to push changes to Gerrit is:

git review

Example:

Upon success, you'll get a confirmation and a link to the changeset in Gerrit. In the example above, that link is: https://gerrit.wikimedia.org/r/#/c/sandbox/+/563720

Congratulations! Your patch is in Gerrit and hopefully will get reviewed soon!

If git review fails

If you are asked to enter your username and password credentials when running git review, it means Git has not yet been configured to use 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/"

This is okay to run again if you're not sure whether you did it already. Replace shell_user with the shell username for your Wikimedia Developer account.

If you get a Permission denied (publickey). fatal: Could not read from remote repository., review the instructions at SSH keys#Add SSH Private key to use with Git to make sure your SSH agent is running and your identity is added. If you close your Git Bash shell, you will be signed out and need to re-follow these instructions each time.

View the Change / Next Steps

Open the link to your Gerrit changeset in a web browser.

Under "Files", after you clicked the down arrow at the very right of any file in the list, you can see a diff of your changes per file: The old lines are shown in red color and your new lines are shown in green color.

Gerrit's diff algorithm (jGit) is slightly different from Git's default diff algorithm. The differences displayed by Gerrit might not look like the differences displayed by Git on your machine.

If your commit addresses a ticket in Phabricator, a comment will be automatically added in the Phabricator task if you followed the Commit message guidelines. If you did not, you could either fix your commit message (by creating an updated patchset), or manually add a comment on that Phabricator ticket which includes a link to your changeset in Gerrit.

Other common situations

Also see Gerrit Advanced usage if your situation is not covered here.

Squash several commits into one single commit via rebase

If you made several related commits to your local repository prior to wanting to submit for review, you should squash (merge) those commits into one single commit.

The --interactive or -i option allows you to change (rewrite) your commit history. For each commit, you can modify and change the commit message, add or remove files, or perform other modifications.

First you need to tell git how far back you want to pull. To get a list of all changes in your branch:

git rebase -i origin/master

You can also limit the displayed list of recent changes. HEAD~3 means pull the last three commits:

git rebase -i HEAD~3

After you type this command, your text editor will display your commits in reverse order and a list of available commands:

Example:

Since we only want to send one commit to review, we will squash the last two commits into the first. Hence change all but the first pick to squash:

pick aa8cf1d Adding method customFilterFunctionGetRiskyCountryCodeScore() to GatewayAdapter.
squash 38828e2 Adding $wgDonationInterfaceCustomFiltersFunctionsRiskyCountries to donationinterface.php
squash be33007 Fix a typo

When you finished picking and squashing and saved the file, another file will open in your text editor to allow you get to edit and merge your commit messages. Be careful to only keep one of the Change-Id lines and have it be at bottom of the message after one empty line.

Your messages from your previous commits will automatically be placed in this message:

Example:

Remember to put your (updated) summary message in the commit. In this case the new summary message will be:

(mingle-fr-2012-69) Adding a custom filter for risky countries.
In regards to which Change-Id you want to use, squashing a commit into an existing commit (one that's already in Gerrit), you need to pick the Change-Id that belongs to the one you meant to submit a new patchset for (the surviving commit). If your commits are new and are not in Gerrit, it does not matter which Change-Id you choose.

If all goes well, you should see a successful rebase message:

Example:

Afterwards, submit your patch for review:

git review

You should see a message like this showing your Git review went to Gerrit (in this example, to https://gerrit.wikimedia.org/r/7187):

Example:

הוספה לשינויים

לפעמים, צריך להוסיף משהו לשינוי שהוגש. אפשר להוסיף לשינוי כל עוד השינוי לא מוזג עדיין.

אפשר להוסיף את השינויים שלך. כדי להוסיף לשינויים שהוגשו על ידי אנשים אחרים, דרושה חברות בקבוצה Trusted-Contirbutors ב־Gerrit. כדי להצטרף לחברות ב־Trusted-Contributors, צריך למצוא מי חבר בקבוצה ולבקש מהם לצרף אותך. הקבוצה היא ויראלית בכך שחברים יכולים להוסיף חברים חדשים, עדיף לנצל את הכוח שלך בחוכמה.

To amend a change you made locally, first navigate to the relevant branch:

git checkout branch-name

To amend an external change, checkout the change directly:

git review -d changeNumber

... where changeNumber is the number suffix in the URL of your Gerrit code review page. Alternatively, git review -d accepts the Change-Id to checkout a change.

Make changes and git add them as needed. Commit the change as an amendment:

git commit --amend

אזהרה אזהרה: Do not use the -m flag to specify a commit summary: that will override the previous summary and regenerate the Change-Id.

דחיפת השינוי:

git review

Rebasing (updating the patch to include other changes)

Sometimes you might want to update your patch to include all of the changes in the repository that have happened since you submitted it. This is called "rebasing". There's usually no need to do it, unless the review has been taking a long time and you want to make sure your changes still work with the latest version of the software, or if Gerrit reports a merge conflict in your change.

You can do it locally using the git rebase command with the right options, but Gerrit's web interface provides a more convenient way to do it.

In the simplest scenario, just click "Rebase", keep the default selection of "Rebase on top of the master branch", and click "Rebase" again to confirm.

If your patch has a merge conflict, you will get an error. You can then check the "Allow rebase with conflicts" option and try again, which will amend your patch with conflict markers, similar to those generated by Git commands. You will then need to amend it yourself, editing the files manually to resolve the conflicts.

Sometimes you might also want update your patch to include changes proposed in another patch (adding a dependency on that patch), but which have not been merged yet. In this case, select "Rebase on a specific change, ref, or commit" instead and provide the change in the input field.

If your patch already has such a dependency, you will also get the option to select "Rebase on top of the master branch (breaks relation chain)" in order to remove it. You will also get the option to check "Rebase all ancestors", which will rebase the patch together with the dependency.

If you use the git rebase command, it's best to make rebase updates a separate patch, so that your code reviewers have an easier time seeing what changes you've made and which changes have happened in other patches.

פתרון בעיות

לבעיות ואופן פתרונן, יש לגשת אל Gerrit/Troubleshooting .

ר' גם

הדפים האלו גם שימושיים:

Third party guides to Git