Gerrit/Eğitim

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Gerrit/Tutorial and the translation is 39% complete.
Outdated translations are marked like this.
Other languages:

Bu, Git ve Gerrit'in Wikimedia gelişimi için nasıl kullanılacağını açıklayan bir öğreticidir.

  • Zaman kazanmak ve teknoloji meraklısıysanız, bunun yerine çok kısa nasıl yapılır kılavuzunu kullanın: Gerrit/Eğitim/tl;dr
  • Uzman kullanıcılar için Gerrit/Advanced usage ek belgelere sahiptir.
  • Yalnızca Gerrit ile oynamak ve "gerçek" bir Wikimedia yazılım projesi için bir yama yazmak istemiyorsanız, bunun yerine Gerrit test örneğimizi kullanın.

Bu öğreticide, kutudaki dolar işareti ile başlamak için aşağıdaki gibi komutlar: command. $ önekini girmeyin.
Komut ayrıca kendinizi değiştirmeniz gereken bir değişken de içeriyorsa, değişken kırmızı renkte gösterilir: command variable.

Git nedir?

Git ücretsiz ve açık bir kaynaktır dağıtılmış sürüm kontrol sistemi. “Dağıtılmış”, deponun merkezi bir kopyası olmadığı anlamına gelir. Git ile, depoyu klonladıktan sonra, tüm dallar ve etiketli sürümler elinizin altında olacak şekilde kaynak kodunun tam olarak çalışan bir kopyasına sahip olursunuz.

Gerrit nedir?

Gerrit Git ile entegre olan ücretsiz, web tabanlı bir ortak kod inceleme aracıdır.

Temel olarak: Önerilen yazılım değişikliğinizi (Gerrit'te "changeset" olarak adlandırılır) yeni bir dal olarak gönderirsiniz. İlk sürüm ("patchset 1") henüz mükemmel değilse, o dalda ("patchset 2" vb.) daha fazla değişiklik yapabilirsiniz ("amend"). Bir yama seti bir "+2" incelemesi aldığında, kabul edilir ve kod deposunun ana dalında birleştirilir (genellikle "master" olarak adlandırılır). Birleştirme, birisi bu kod deposunu teslim aldığında veya indirdiğinde, yaptığınız değişikliğin varsayılan olarak dahil edileceği anlamına gelir.

Wikimedia geliştirici hesabı oluşturun

Henüz bir Wikimedia geliştirici hesabınız yoksa, wikitech.wikimedia.org sayfasına gidin ve bir hesap oluşturun. Aynı kullanıcı adı ve parola aşağıdaki Gerrit'te oturum açmak için kullanılacaktır.

Git'i kurun

Bu talimatlar Git'in komut satırı (terminal penceresi) aracı olarak nasıl kurulacağını açıklar. Komut satırı yerine grafik kullanıcı arabirimi (GUI) tercih ederseniz, Git projesi tarafından tutulan istemcilerin listesini denetleyin. Alternatif kurulum talimatları için resmi belgelere bakın.

Kurulum

Font Awesome 5 brands linux.svg Linux

  • git paketini kurmak için Linux dağıtımınızın grafiksel yazılım paketi yönetim aracını kullanın.
  • Git dağıtımınız tarafından paketlenmemişse, lütfen dağıtımınızın destek forumuna sorun.

Font Awesome 5 brands windows.svg Windows

  • Windows için Git ile https://gitforwindows.org/ üzerinden yükleyin. Bu size Git'e ek olarak bu talimatlardaki komut satırlarının çoğunun Windows üzerinde çalışmasına izin veren "Git Bash" adlı bir kabuk verir.
Windows kabuğuyla ek entegrasyon istiyorsanız, Gerrit/TortoiseGit tutorial sayfasına bakın.

Apple logo black.svg macOS

  • Homebrew paket yöneticisini kurun ve sonra brew install git komutunu çalıştırın – Diğer paketlerin kolay güncellenmesine ve kolayca kurulmasına izin verdiği için bu önerilir.
  • Alternatif olarak, tek başına Git for Mac yükleyebilirsiniz.

Git'i yapılandırın

Git'i yüklediğinize göre artık kişisel bilgilerinizi yapılandırma zamanı. Bunu sadece bir kez yapmanız gerekir. Ayrıca bu komutları tekrar çalıştırarak kişisel bilgilerinizi istediğiniz zaman değiştirebilirsiniz.

Git, kullanıcının adını ve e-postasını kontrol ederek her işlemi yapanları izler. Ayrıca, bu bilgi taahhütlerinizi Gerrit hesabınızla ilişkilendirmek için kullanılır.

Kullanıcı adınızı ve e-posta adresinizi ayarlamak için aşağıdaki iki komutu girin. gerrituser ile kendi Gerrit kullanıcı adınızla değiştirin ve gerrituser@example.com ile kendi e-posta adresinizle değiştirin:

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

git config --global user.name "gerrituser"

Git'in nasıl davrandığını kontrol eden mevcut yapılandırma değişkenlerinizi görmek için git config -l kullanın.

Gerrit'te SSH Anahtarlarını Ayarla

Bilgisayarınız ve Gerrit arasında güvenli bir bağlantı kurmak için bir SSH anahtarı kullanıyoruz. Yepyeni bir anahtar oluşturmanız gerekip gerekmediğinden emin olmak için, sisteminizde zaten bir SSH anahtarı olup olmadığını kontrol edelim. Bu komutu bir terminalde çalıştırın:

ls ~/.ssh

Komut, (gizli) .ssh dizinindeki dosyaları listeler. Dizin sisteminizde zaten varsa ve çıkışta id_rsa.pub adlı bir dosya listeleniyorsa, doğrudan #SHH Genel anahtarınızı kopyalayın bölümüne gidebilirsiniz.

Yeni bir SSH anahtarı oluşturun

Yeni bir SSH anahtarı oluşturmak için aşağıdaki komutu girin ve gerrituser@example.com yerine kendi e-posta adresinizi yazın. Varsayılan ayarları istiyoruz, bu nedenle anahtarı kaydetmek için bir dosya girmeniz istendiğinde, enter tuşuna basın.

ssh-keygen komutunun çıkışı

ssh-keygen -t rsa -C "gerrituser@example.com"

Güçlü ve benzersiz bir parola girin ve [Enter] tuşuna basın.

Why do passphrases matter?
Passwords aren’t very secure. If you use one that’s easy to remember, it’s easier to guess or brute-force. If you use one that’s random it’s hard to remember, so you might write the password down. Both are very bad. This is why you’re using ssh keys. But using an ssh key without a passphrase is basically the same as writing down that random password in a file on your computer. Anyone who gains access to your drive has gained access to every system you use that key with. That's why you also add a passphrase. To not enter a long passphrase every time you use the key, there’s a tool called ssh-agent. It can save your passphrase securely. If you use macOS or Linux, then your keys can be saved in the system’s keychain to make your life even easier.

The ssh-keygen command will create 2 files in ~/.ssh directory:

  • ~/.ssh/id_rsa : your private SSH key (for identification)
  • ~/.ssh/id_rsa.pub : your public SSH key

SSH Genel anahtarınızı kopyalayın

Genel anahtar dosyanızın içeriğini (örneğin, id_rsa.pub) panonuza kopyalayın:

Bir seçenek, ortak anahtar dosyanızı en sevdiğiniz metin düzenleyicisiyle (Notepad, TextEdit, gedit vb.) açmaktır. Metin düzenleyicinizin dosya seçici iletişim kutusunda, dosyayı bulmak için “Gizli dosyaları görüntüle”'yi açmanız gerekebilir, çünkü .ssh dizini gizlidir. Bazen "Gizli dosyaları görüntüle" seçeneği, dosya seçici iletişim kutusuna sağ tıklayarak kullanılabilir.

Diğer seçenekler:

  • On Linux, run cat ~/.ssh/id_rsa.pub and manually copy the output to the clipboard.
  • On Windows, you can open Git GUI, go to Help 🡒 Show Key, and then press "Copy To Clipboard" to copy your public key to your clipboard.
  • On macOS, you can run pbcopy < ~/.ssh/id_rsa.pub to copy the contents of the your public key file to your clipboard.

It’s important you copy your SSH Public key exactly as it is written, without adding any newlines or whitespace. Copy the full text, including the "ssh-rsa" prefix, the key itself, and the email address suffix.

Gerrit hesabınıza SSH Genel anahtarı ekleyin

  • Log into the web interface for Gerrit. The username and password for your Gerrit are the same as for your Wikimedia Developer account.
  • Click on your username in the top right corner, then choose "Settings".
  • Click "SSH Public Keys" in the menu on the left.
  • Paste your SSH Public Key into the corresponding field and click "Add".

Git ile kullanmak için SSH Özel anahtarı ekleyin

Git Bash komut satırını başlatın.

  • Get ssh-agent running using
eval `ssh-agent`
Be sure to use the accent `, not the single quote '. (You could copy and paste from this page if you cannot easily enter this special character.)
  • Add your private key to the agent.[1] If you followed the steps above and your key has the default name id_rsa, then the command is:
ssh-add .ssh/id_rsa
  • Connect to the Gerrit server via ssh to check if everything works as expected. Replace gerrituser by your username as shown in your Gerrit settings:
ssh -p 29418 gerrituser@gerrit.wikimedia.org
  • Be paranoid and compare that the "RSA key fingerprint" is the same as the SSH fingerprint for gerrit.wikimedia.org:29418. If it is the same, answer "Yes" to "Are you sure you want to continue connecting?". Then enter the passphrase for your key.
  • You should get a message "Welcome to Gerrit Code Review". The last line should show "Connection to gerrit.wikimedia.org closed."
  • If you run into problems, use ssh -p 29418 -v gerrituser@gerrit.wikimedia.org (replace gerrituser by your username). The -v will provide verbose output to help find problems. Then read Gerrit Troubleshooting.

An example Gerrit SSH connection success message looks like this:

Tournesol.png Example:

Git'i kullanarak kod indirin

"Sandbox" adlı deposu indirerek ("cloning" denir) pratik yapalım. Git Bash komut satırı üzerinde aşağıdakileri çalıştırın:

git clone ssh://gerrituser@gerrit.wikimedia.org:29418/sandbox (Replace gerrituser by your Gerrit username. And make sure the URL begins with ssh: and not https:).

Bu işlem, "sandbox" uzantı deposunun tüm geçmişini ve kod tabanını makinenize kopyalar. Uzantının ana dalının (genellikle "git master" olarak da bilinir) bir çalışma dizinine sahip olursunuz. Yeni dizini girin (cd sandbox komutu ile). Artık koda bakıp düzenlemeye başlayabilirsiniz.

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 how to download MediaWiki Core, extensions, skins, or any other project repository hosted at gerrit.wikimedia.org from Git.

Gerrit ile çalışmaya hazırlanın

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.

git-review yükleme

Wikimedia Gerrit'in git-review 1.27 veya daha yeni bir sürümünü gerektirdiğini unutmayın.

Daha fazla bilgi için lütfen #Kurulum bölümüne bakın.

Font Awesome 5 brands linux.svg Linux

Font Awesome 5 brands windows.svg Windows

Apple logo black.svg 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.

git-review yapılandırma

Git'in varsayılan uzak ana bilgisayar adı "origin". Bu ad Wikimedia projeleri tarafından da kullanılır. Bu konağı kullanabilmek için git-review söylememiz gerekiyor. gerrituser yerine Gerrit kullanıcı adınızı yazın:

git config --global gitreview.remote origin

git config --global gitreview.username gerrituser

git-review ayarlama

Bir depoyu indirdikten ("cloning") sonra, git-review için ayarlamanız gerekir. Bu, bir taahhüdü ilk kez göndermeye çalıştığınızda otomatik olarak gerçekleşir, ancak bunu klonlamadan hemen sonra yapmak genellikle daha iyidir. Klonladığınız projenin dizininde olduğunuzdan emin olun (aksi takdirde "hata: Git deposu değil" hatası alırsınız). Ardından şu komutu çalıştırın:

git review -s --verbose

Çıkışının sonuna doğru, şöyle bir şey görmelisiniz:

Tournesol.png Example:

Bu, kullandığınız kabuk kullanıcı adından farklıysa git kullanıcı adınızı isteyebilir.

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

Bir yama gönderin

Make sure that you cloned the code repository that you are interested in (see here).

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

Güncelleme yöneticisi

Ana dalınızın (depoyu ilk kez klonladığınızda oluşturulan dal) güncel olduğundan emin olun:

git pull origin master

However, note that a few repositories use different terms (for example, the operations/puppet repository has a production instead of a master branch).

Bir dal oluştur

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

git checkout -b BRANCHNAME origin/master

Tournesol.png Example:

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

Değişikliklerinizi yapın

Yerel kodunuzda değişiklik yapın. Tercih ettiğiniz metin düzenleyiciyi kullanın ve bir dosyayı değiştirin. Aşağıdaki örnekte, README.md dosyasını düzenliyoruz ve bir kelime ekliyoruz.

Ardından metin düzenleyicinizi kapatın ve son işlemden bu yana, dosya(lar) ve dizin içinde yaptığınız değişiklikleri kontrol edin:

git diff

Tournesol.png 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.

Bir taahhüt için değişikliklerinizi yapın

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.

İstediğiniz zaman, git status çalıştırarak önceden hazırlanmış değişiklikleri her zaman gözden geçirebilirsiniz. git add çalıştırdıktan sonra git status "artık taahhütte değişiklik yapılmadı" satırını göstermeyecek.
Ayrıca hangi değişikliklerin hazırlandığını ve bir sonraki işleme geçeceğini görmek için git diff --cached kullanabilirsiniz. Çıkış, yukarıdaki git diff komutuyla aynı görünecektir.

Aşamalı değişikliklerinizi yapın

git add yoluyla eklenen değişikliklerin listesinden memnun olduğunuzda, bu değişiklikleri kullanarak yerel deponuzdaki bir taahhüde dönüştürebilirsiniz.

git commit

Tournesol.png sandbox/.git/COMMIT_EDITMSG:

You will then be asked in your text editor to add a descriptive summary for your commit. You must follow the Commit message guidelines. This is what other people will see when looking at the history of changes in the code repository.

İşleme mesajını kaydedin ve metin düzenleyicinizi kapatın. Bir özet (tamamlama kimliği, konu satırınız, değiştirilen dosyalar ve satırlar) görüntülenir.

Ana dalı itmek istediğiniz bir dizi değişiklik olana kadar bu adımı tekrar tekrar yapabilirsiniz.

git commit geldiğinizde, yerel kopyanızı taahhüt ediyorsunuz.

Bu, projedeki başka bir geliştirici için işleri potansiyel olarak bozmadan istediğiniz sıklıkta iş yapabileceğiniz anlamına gelir.

Taahhüdünüzü Gerrit'e aktarmaya hazırlanın

Değişiklik kümenizi, çalışırken ana dalda olabilecek tüm değişikliklerle senkronize edin ("yeniden basma"). Dalınızdan şunları çalıştırın:

git pull --rebase origin master

Tournesol.png Example:
git pull --rebase origin master uzaktan yeni taahhütler getirecek ve daha sonra yerel taahhütlerinizi bunlara yeniden temellendirecektir.

Şubenizde yaptığınız değişiklikleri geçici olarak bir kenara bırakır, master'da gerçekleşen tüm değişiklikleri çalışma şubenize uygular, sonra da şubeye yaptığınız tüm değişiklikleri birleştirir (tavsiye eder). Bunu yapmak, gelecekteki birleşme çakışmalardan kaçınmanıza yardımcı olacaktır.

Ayrıca, değişikliklerinizi master'daki en son koda karşı test etme fırsatı verir.

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 -R

The -R option tells git-review not to perform a rebase before submitting the change to Gerrit.

Tournesol.png 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!

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'in diff algoritması (jGit) git'in varsayılan diff algoritmasından biraz farklıdır. Gerrit tarafından görüntülenen farklar Git tarafından makinenizde görüntülenen farklılıklara benzemeyebilir.

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.

Rebase ile birkaç taahhüdü tek bir taahhütte toplayın

İncelemeye gönderilmeyi istemeden önce yerel deponuza ilgili birkaç taahhütte bulunduysanız, bu taahhütleri tek bir taahhütte ezmeniz (birleştirmeniz) gerekir.

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.

Önce git'i ne kadar geri çekmek istediğinizi söylemelisiniz. Şubenizdeki tüm değişikliklerin bir listesini almak için:

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

Bu komutu yazdıktan sonra, metin düzenleyiciniz taahhütlerinizi ters sırayla ve kullanılabilir komutların bir listesini görüntüler:

Tournesol.png 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:

Tournesol.png Example:

Özet mesajınızı (güncellenmiş) işleme koymayı unutmayın. Bu durumda yeni özet mesaj şöyle olacaktır:

(mingle-fr-2012-69) Adding a custom filter for risky countries.
Kullanmak istediğiniz Change-Id ile ilgili olarak, mevcut bir taahhüde (zaten Gerrit'te olan) bir taahhütte bulunmak için, yeni bir patchset göndermek istediğinize ait olan Change-Id ile seçmeniz gerekir (hayatta kalma taahhüt). Taahhütleriniz yeniyse ve Gerrit'te değilse, hangi Change-Id'yi seçtiğiniz önemli değildir.

Her şey yolunda giderse, başarılı bir rebase mesajı görmelisiniz:

Tournesol.png Example:

Daha sonra yamanızı incelemeye gönderin:

git review

Git incelemenizin Gerrit'e gittiğini gösteren bir mesaj görmelisiniz (bu örnekte https://gerrit.wikimedia.org/r/7187):

Tournesol.png Example:

Amending a change (your own or someone else's)

Sometimes, you might need to amend a submitted change. You can amend a change as long as the change hasn't been merged yet.

You can amend your own changes. To amend changes submitted by someone else, you need to be a member of Gerrit's Trusted-Contributors group. To become a member of Trusted-Contributors, find someone who is a member and ask them to add you. The group is viral in that members can add new members, use your powers responsibly.

Rebase to bring your local branch up to date with the remote. It's best to make rebase updates a separate patch, so that your code reviewers have an easy time seeing what changes you've made. Assuming you are using Gerrit, you can do this by clicking the "Rebase Change" button when viewing your patch in Gerrit's web interface.

Hard reset and checkout the change with this command: (BEWARE: git review -d performs a hard reset that destroys all local changes. Stash or commit changes first which you wish to preserve!)

git review -d changenumber For example: git review -d 9332

Yerel deponuzda bir dalda zaten değişiklik varsa, bunun yerine sadece kontrol edebilirsiniz:

git checkout BRANCHNAME For example: git checkout review/gerrituser/2012/bug12345

Ardından, favori metin düzenleyicinizle bazı değişiklikler yapın.

git add the files as needed, then commit the change (ensuring you are amending the commit):

git add Example/Example.body.php

git commit --amend --all

Bir taahhüt özeti belirtmek için -m işaretini KULLANMAYIN: bu önceki özeti geçersiz kılar ve Change-Id yeniden oluşturur. Bunun yerine, taahhüt özetini değiştirmek için metin düzenleyicinizi kullanın (gerekirse .git/COMMIT_EDITMSG dosyasında ve Change-Id satırını olduğu gibi bırakın.

Değişiklikliği push yapın:

git review -R

The -R is important here. It tells git-review to not rebase your change against master, which clutters diffs between patch set 1 and 2.

Push to a branch different than master

Above, the commit was pushed to the master branch. The branch name only appeared as the topic of the commit in the Gerrit UI. If you really want to push to a different branch than master, you have to push via git review <branch name>.

Editing via the web-interface

If you're logged in to Gerrit, you can also create code changes directly within the web interface. This can be useful for making small patches, or for non-developers to contribute small fixes.

  1. Go to https://gerrit.wikimedia.org/r/admin/projects and choose the code repository that you want to edit.
  2. Select "Commands" in the sidebar
  3. Click "Create Change"
  4. Set branch to "master" (if you don't want to use master branch you can use the other branches available for that project)
  5. Set the topic to something of your choosing (e.g. "copy-edit" - must be all-one-string) (optional)
  6. Write a description ("commit summary") in the big text field by following message guidelines. (Example)
  7. Click "Create"
  8. In the upper right corner, click the "Edit" button
  9. Under "Files", click "ADD/OPEN/UPLOAD" button
  10. Type the folder/file path for the file you wish to edit (e.g. i18n/en.json) and click "Open"
  11. Find the line(s) you want to change, and change them.
  12. Click "Save"
  13. Click "Close"
  14. Click "Publish edit"
  15. Click the button "Start Review"

Done!

If you need to change the commit message of an existing changeset, you can use these steps:

  1. Go to the changeset itself. Example URL: https://gerrit.wikimedia.org/r/c/1234567890 (replace the ID at the end)
  2. In the "Files" section, click "Commit message"
  3. In the upper right corner, click the "Edit" button
  4. Make changes to the commit summary.
  5. In the upper right corner, click "Save"
  6. In the upper right corner, click "Close"
  7. In the upper right corner, click "Publish edit"

How code is reviewed in Gerrit

Code review is an essential part of our contribution workflow. The principle is basic: any patch must be reviewed by others before being merged.

This means that your code will need reviewers. Check our advice for getting reviews.

Review before merge

It's important to us to have a review-before-merge workflow for MediaWiki core and also for any extension we deploy. We will also offer that option to any extension author who wants it for their extension. The one exception is localisation and internationalisation commits, which will be able to be pushed without review.

Who can review? Gerrit project owners

After creating a Developer account, anyone can comment on commits and express criticism and approvals. Anyone can give a nonbinding "+1" to any commit. However, for any given repository ("Gerrit project"), only a small group of people will have the ability to approve code within Gerrit and merge it into the repository. This superapproval is a "+2" even though that's a misleading name, because two +1 approvals DO NOT add up to a +2. These people are "Gerrit project owners".

How to comment on, review, and merge code in Gerrit

A freshly uploaded sample changeset in Gerrit's web interface
Side-by-side diff in Gerrit's web interface

Anyone can comment on code in Gerrit.

Viewing and commenting on code

  • Make sure that you have a developer account.
  • Log in to Gerrit. If you know the changeset you want to look at (URL will look like https://gerrit.wikimedia.org/r/#/c/23939/), go to that. Otherwise, use the search box. You can search by author ("Owner"), Gerrit project, branch, changesets you've starred, etc. The Gerrit search documentation covers all of the different search operators you can use.
  • The changeset has a few fields, links and buttons:
    • Assignee. An optional field to make a single person responsible for handling reviewing the changeset. This should only be set if the assignee has agreed.
    • Reviewers. 'jenkins-bot' is the autoreviewer that auto-verifies anything that passes the Jenkins tests. It will report a red or green mark depending on whether the build passes.
    • The "Add reviewer" button under Reviewers: in the upper left corner manually request review from someone. It'll show up in their Gerrit dashboard.
    • Under Files, Expand All opens the diff for each file below. You can double-click on a line and then press the C key to comment on that line, then click "Save" to save the draft comment. Then, at the top of the page click the "Reply" button to publish your comment.
    • Reply adds your comments to a changeset, including an overall comment and/or inline comments you added (see above).
      • If, upon code review, you approve, use "Code-Review: +1" under "Reply"; otherwise, use "Code-Review: -1" to disapprove. These numbers are nonbinding, won't cause merges or rejections, and have no formal effect on the code review.
    • Abandon (you'll see this if you wrote this diff). This action removes the diff from the list to review, but leaves it in Gerrit for archival purposes.
  • The "Only Comments" switch allows to hide reviews by non-human bots. See https://phabricator.wikimedia.org/T48148#6294913 for an example.

Comparing patch sets

Every time you amend your commit and submit it for review, a new patch set is created. You can compare the different patch sets like this:

  • Under Files, select either Expand All or choose a specific file listed to open that file.
  • On the left side under Patch Set, Base is preselected. On the right of the screen under Patch Set, the latest patch set is preselected. Adjust the selected patch sets to your needs.

Formally reviewing and merging or rejecting code

If you are one of the Gerrit project owners, you'll also see:

  • Abandon button
  • under Reply, additional Code-Review options to +2 (approve) or -2 (veto) a diff, and a Post button (publish your comment and merge diff into the branch, in 1 step)
  • Submit button (merge -- only useful if you or someone else has already given a +2 approval to the diff, but not merged it)

And once you've merged something into the example Gerrit project you'll see it in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/examples/. If you merged a commit that references a task in Phabricator and that commit is supposed to fix that task completely, please go to that task and change its status to "Resolved" (via the Add Action… 🡒 Change Status dropdown). Also reference the merge ID if gerritbot has not already posted it in that task.

Sorun giderme

For problems and how to solve them, see Gerrit/Troubleshooting.

Ayrıca bakınız

Also useful are these pages:

Third party guides to Git

Historical documents

Kaynakça

  1. If as a Ubuntu user you have a "Permission denied (publickey)" message, please check on this help page