Translate complete hooks.asc

book/08-customizing-git/sections/hooks.asc

@@ -30,97 +30,97 @@ Bu bölüm, katkı iş akışı kancalarını, e-posta iş akışı betiklerini
 Eğer bu betiklerle bir politika uygulamak gibi bir amacınız varsa, muhtemelen bunu sunucu tarafında yapmak isteyeceksiniz. Bunun için <<ch08-customizing-git#_an_example_git_enforced_policy>> bölümündeki örneğe bakın.
 ====
 
-===== Committing-Workflow Hooks
+===== Katkı-İşakışı Kancaları
 
-The first four hooks have to do with the committing process.
+İlk dört kancanın hepsi katkı süreci ile ilgilidir.
 
-The `pre-commit` hook is run first, before you even type in a commit message.
-It's used to inspect the snapshot that's about to be committed, to see if you've forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.
-Exiting non-zero from this hook aborts the commit, although you can bypass it with `git commit --no-verify`.
-You can do things like check for code style (run `lint` or something equivalent), check for trailing whitespace (the default hook does exactly this), or check for appropriate documentation on new methods.
+`pre-commit` kancası siz daha katkı mesajını bile yazmadan önce çalıştırılır.
+Yapılacak olan katkıyı incelemek, bir şey unutup unutmadığınızı görmek, testlerin çalıştırılıp çalıştırılmadığını kontrol etmek veya kod içinde incelemek istediğiniz herhangi bir şeyi kontrol etmek için kullanılır.
+Bu kancadan sıfırsız (non-zero) çıkış yapmak katkıyı iptal eder, ancak `git commit --no-verify` ile bunu atlayabilirsiniz.
+Bununla, kod stili kontrol etmek (lint veya bir benzerini çalıştırmak), sondaki boşlukları kontrol etmek (varsayılan kanca tam olarak bunu yapar) veya yeni metodlarda uygun belgelendirmenin olup olmadığını kontrol etmek gibi şeyler yapabilirsiniz.
 
-The `prepare-commit-msg` hook is run before the commit message editor is fired up but after the default message is created.
-It lets you edit the default message before the commit author sees it.
-This hook takes a few parameters: the path to the file that holds the commit message so far, the type of commit, and the commit SHA-1 if this is an amended commit.
-This hook generally isn't useful for normal commits; rather, it's good for commits where the default message is auto-generated, such as templated commit messages, merge commits, squashed commits, and amended commits.
-You may use it in conjunction with a commit template to programmatically insert information.
+`prepare-commit-msg` kancası, katkı mesajı düzenleyici başlatılmadan önce, ancak varsayılan mesaj oluşturulduktan sonra çalıştırılır.
+Katkı yazarı mesajı görmeden önce varsayılan mesajı düzenlemenize izin verir.
+Bu kancanın birkaç parametresi vardır: şimdiye kadar katkı mesajını tutan dosyanın yolu, katkının türü ve eğer bu düzeltilmiş bir katkıysa katkı SHA-1'i gibi.
+Bu kanca genellikle normal katkılar için kullanışlı değildir; bunun yerine, varsayılan mesajın otomatik olarak oluşturulduğu katkılarda, örneğin şablonlu katkı mesajları, birleştirme katkıları, sıkıştırılmış katkılar ve düzeltilmiş katkılarda iyidir.
+Programlı olarak bilgi eklemek için bunu bir katkı şablonuyla birlikte kullanabilirsiniz.
 
-The `commit-msg` hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.
-If this script exits non-zero, Git aborts the commit process, so you can use it to validate your project state or commit message before allowing a commit to go through.
-In the last section of this chapter, we'll demonstrate using this hook to check that your commit message is conformant to a required pattern.
+`commit-msg` kancası, yine geliştirici tarafından yazılan katkı mesajını içeren geçici bir dosyanın yolunu içeren bir parametre alır.
+Bu betik sıfırsız olarak çıkarsa, Git katkı sürecini iptal eder. Bunu bir katkının gerçekleşmesine izin vermeden önce, proje durumunuzu veya katkı mesajınızı doğrulamak için kullanabilirsiniz.
+Bu bölümün sonunda, bu kancayı katkı mesajınızın gerekli bir modelle uyumlu olup olmadığını kontrol etmek için nasıl kullanacağımızı göstereceğiz.
 
-After the entire commit process is completed, the `post-commit` hook runs.
-It doesn't take any parameters, but you can easily get the last commit by running `git log -1 HEAD`.
-Generally, this script is used for notification or something similar.
+Tüm katkı süreci tamamlandıktan sonra, `post-commit` kancası çalışır.
+Bu, herhangi bir parametre almaz, ancak `git log -1 HEAD` komutunu çalıştırarak en son katkıyı kolayca alabilirsiniz.
+Genellikle, bu betik bildirim veya benzeri bir şey için kullanılır.
 
 [[_email_hooks]]
-===== Email Workflow Hooks
+===== E-posta İş-akışı Kancası
 
-You can set up three client-side hooks for an email-based workflow.
-They're all invoked by the `git am` command, so if you aren't using that command in your workflow, you can safely skip to the next section.
-If you're taking patches over email prepared by `git format-patch`, then some of these may be helpful to you.
+E-posta tabanlı bir iş akışı için üç istemci tarafı kancası kurabilirsiniz.
+Hepsi `git am` komutu tarafından çağrılır, bu yüzden iş akışınızda bu komutu kullanmıyorsanız, güvenle bir sonraki bölüme geçebilirsiniz.
+E-posta aracılığıyla hazırlanan `git format-patch` ile yama alıyorsanız, bunlardan bazıları size yardımcı olabilir.
 
-The first hook that is run is `applypatch-msg`.
-It takes a single argument: the name of the temporary file that contains the proposed commit message.
-Git aborts the patch if this script exits non-zero.
-You can use this to make sure a commit message is properly formatted, or to normalize the message by having the script edit it in place.
+Çalıştırılan ilk kanca `applypatch-msg`dir.
+Tek bir argüman alır: önerilen katkı mesajını içeren geçici dosyanın adı.
+Bu betik sıfırsız olarak çıkarsa, Git yamayı iptal eder.
+Bunu, bir katkı mesajının düzgün biçimlendirilmiş olup olmadığını veya betiği yerinde düzenleyerek mesajı normalleştirmek için kullanabilirsiniz.
 
-The next hook to run when applying patches via `git am` is `pre-applypatch`.
-Somewhat confusingly, it is run _after_ the patch is applied but before a commit is made, so you can use it to inspect the snapshot before making the commit.
-You can run tests or otherwise inspect the working tree with this script.
-If something is missing or the tests don't pass, exiting non-zero aborts the `git am` script without committing the patch.
+`pre-applypatch` kancası `git am` ile yamaları uygularken çalıştırılan bir sonraki kancadır.
+Biraz kafa karıştırıcı bir şekilde, yama uygulandıktan _sonra_ ancak bir katkı yapılmadan önce çalışır. Bu nedenle katkı işlemeden önce görüntüyü incelemek için kullanılabilir.
+Bu betikle çalışma ağacını test edebilir veya başka şekilde inceleyebilirsiniz.
+Eğer bir şey eksikse veya testler geçmezse, sıfırsız (non-zero) çıkış yaparak `git am` betiğini katkı işlemeden durdurabilirsiniz.
 
-The last hook to run during a `git am` operation is `post-applypatch`, which runs after the commit is made.
-You can use it to notify a group or the author of the patch you pulled in that you've done so.
-You can't stop the patching process with this script.
+`post-applypatch` bir `git am` işlemi sırasında çalıştırılan son kancadır , katkı işlendikten sonra çalışır.
+Bunu, içine çektiğiniz yamayı oluşturan grubu veya yazarı bildirmek için kullanabilirsiniz.
+Bu betikle yama işlemini durduramazsınız.
 
 [[_other_client_hooks]]
-===== Other Client Hooks
+===== Diğer İstemci Kancaları
 
-The `pre-rebase` hook runs before you rebase anything and can halt the process by exiting non-zero.
-You can use this hook to disallow rebasing any commits that have already been pushed.
-The example `pre-rebase` hook that Git installs does this, although it makes some assumptions that may not match with your workflow.
+`pre-rebase` kancası, herhangi bir şeyi yeniden temellemeden (rebase) önce çalışır ve sıfırsız (non-zero) çıkış yaparak işlemi durdurabilir.
+Bu kancayı kullanarak zaten itilmiş olan herhangi bir katkının yeniden temellenmesini engelleyebilirsiniz.
+Git'in kurduğu örnek `pre-rebase` kancası bunu yapar, ancak iş akışınızla eşleşmeyebilecek bazı varsayımlarda bulunur.
 
-The `post-rewrite` hook is run by commands that replace commits, such as `git commit --amend` and `git rebase` (though not by `git filter-branch`).
-Its single argument is which command triggered the rewrite, and it receives a list of rewrites on `stdin`.
-This hook has many of the same uses as the `post-checkout` and `post-merge` hooks.
+`post-rewrite` kancası, `git commit --amend` ve `git rebase` gibi katkıları değiştiren komutlar tarafından çalıştırılır (ancak `git filter-branch` tarafından değil).
+Tek bir argümanı, yeniden yazmayı tetikleyen komutu alır ve `stdin` üzerinden yeniden yazılara bir liste alır.
+Bu kancanın `post-checkout` ve `post-merge` kancalarıyla aynı kullanımları vardır.
 
-After you run a successful `git checkout`, the `post-checkout` hook runs; you can use it to set up your working directory properly for your project environment.
-This may mean moving in large binary files that you don't want source controlled, auto-generating documentation, or something along those lines.
+`post-checkout` kancası başarılı bir `git checkout` işleminden sonra çalışır; projenizin ortamı için çalışma dizinini uygun şekilde ayarlamak için kullanabilirsiniz.
+Kaynak kontrol edilmemesini istediğiniz büyük ikilik dosyaları taşımak, otomatik belge oluşturmak veya buna benzer şeyler için kullanılabilir.
 
-The `post-merge` hook runs after a successful `merge` command.
-You can use it to restore data in the working tree that Git can't track, such as permissions data.
-This hook can likewise validate the presence of files external to Git control that you may want copied in when the working tree changes.
+`post-merge` kancası başarılı bir `merge` komutundan sonra çalışır.
+Git'in izleyemediği (örneğin izin verileri gibi) çalışma dizinindeki verileri geri yüklemek için kullanabilirsiniz.
+Bu kancayı, çalışma dizini değiştiğinde içeri alınmasını istediğiniz Git kontrolü dışındaki dosyaların varlığını doğrulamak için de kullanabilirsiniz.
 
-The `pre-push` hook runs during `git push`, after the remote refs have been updated but before any objects have been transferred.
-It receives the name and location of the remote as parameters, and a list of to-be-updated refs through `stdin`.
-You can use it to validate a set of ref updates before a push occurs (a non-zero exit code will abort the push).
+`pre-push` kancası `git push` sırasında (uzak referanslar güncellendikten sonra, ancak nesneler aktarılmadan önce) çalışır.
+Parametreler olarak uzak reponun adı ve konumu ile güncellenecek referansların bir listesini `stdin` üzerinden alır.
+Bir itme gerçekleşmeden önce bir referans kümesini doğrulamak için kullanabilirsiniz (bir çıkış kodu sıfır olmayan bir çıkış kodu itme işlemini iptal eder).
 
-Git occasionally does garbage collection as part of its normal operation, by invoking `git gc --auto`.
-The `pre-auto-gc` hook is invoked just before the garbage collection takes place, and can be used to notify you that this is happening, or to abort the collection if now isn't a good time.
+Git, normal işleminin bir parçası olarak `git gc --auto` komutunu çağırarak, zaman zaman artık toplar (garbage collection).
+`pre-auto-gc` kancası artık toplama gerçekleşmeden hemen önce çağrılır ve çöp topladığını bildirmek veya şu anda iyi bir zaman olmadığını belirterek toplamayı iptal etmek için kullanılabilir.
 
-==== Server-Side Hooks
+==== Sunucu Tarafı Kancaları
 
-In addition to the client-side hooks, you can use a couple of important server-side hooks as a system administrator to enforce nearly any kind of policy for your project.
-These scripts run before and after pushes to the server.
-The pre hooks can exit non-zero at any time to reject the push as well as print an error message back to the client; you can set up a push policy that's as complex as you wish.
+İstemci tarafı kancalarına ek olarak, sistem yöneticisi olarak neredeyse her türlü politikayı uygulamak için bazı önemli sunucu tarafı kancalarını kullanabilirsiniz. 
+Bu betikler sunucuya yapılan itmelerden önce ve sonra çalışır. 
+Ön kancalar, itme işlemini reddetmek ve istemciye bir hata mesajı göndermek için herhangi bir zamanda sıfırsız çıkış yapabilir. Dilediğiniz ölçüde karmaşık bir itme politikası oluşturabilirsiniz.
 
 ===== `pre-receive`
 
-The first script to run when handling a push from a client is `pre-receive`.
-It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted.
-You can use this hook to do things like make sure none of the updated references are non-fast-forwards, or to do access control for all the refs and files they're modifying with the push.
+`pre-receive` kancası bir istemciden yapılan bir itmeyi işlerken çalıştırılacak ilk betiktir. 
+Bu, stdin'den gönderilen itmelerin bir listesini alır: eğer sıfırsız bir çıkış yaparsa, hiçbiri kabul edilmez. 
+Bu kancayı, güncellenen referansların hiçbirinin hızlı olmayan (non-fast-forward) itmeler olmadığından emin olmak veya itmeyi kullanarak değiştirdiğiniz tüm referanslar ve dosyalara erişim kontrolü yapmak gibi şeyler için kullanabilirsiniz.
 
 ===== `update`
 
-The `update` script is very similar to the `pre-receive` script, except that it's run once for each branch the pusher is trying to update.
-If the pusher is trying to push to multiple branches, `pre-receive` runs only once, whereas update runs once per branch they're pushing to.
-Instead of reading from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push.
-If the update script exits non-zero, only that reference is rejected; other references can still be updated.
+`update` betiği, `pre-receive` betiğiyle çok benzerdir, ancak iten kişinin güncellemeye çalıştığı her dal için bir kez çalıştırılır. 
+Eğer iten kişi birden çok dala itmeye çalışıyorsa, `pre-receive` yalnızca bir kez çalışırken; `update`, itilen her dal için bir kez çalışır. 
+Stdin'den okumak yerine, bu betik üç argüman alır: referansın adı (dal), itmeye çalışmadan önce referansın işaret ettiği SHA-1 ve kullanıcının itmeye çalıştığı SHA-1. 
+Eğer güncelleme betiği sıfırsız çıkış yaparsa, yalnızca o referans reddedilir; diğer referanslar hala güncellenebilir.
 
 ===== `post-receive`
 
-The `post-receive` hook runs after the entire process is completed and can be used to update other services or notify users.
-It takes the same stdin data as the `pre-receive` hook.
-Examples include emailing a list, notifying a continuous integration server, or updating a ticket-tracking system – you can even parse the commit messages to see if any tickets need to be opened, modified, or closed.
-This script can't stop the push process, but the client doesn't disconnect until it has completed, so be careful if you try to do anything that may take a long time.
+`post-receive` betiği, işlem tamamlandıktan sonra çalışır ve diğer hizmetleri güncellemek veya kullanıcıları bilgilendirmek için kullanılabilir. 
+Bu betik, `pre-receive` betiğiyle aynı stdin verilerini alır. 
+Örnekler arasında bir listeye e-posta gönderme, sürekli entegrasyon sunucusunu bildirme veya bir bilet izleme sistemi güncelleme bulunur - hatta katkı mesajlarını analiz ederek açılması, değiştirilmesi veya kapatılması gereken herhangi bir bilet olup olmadığını görebilirsiniz. 
+Bu betik itme işlemini durduramaz, ancak itme tamamlanana kadar istemci bağlantısını kesmez. Bu nedenle uzun sürebilecek herhangi bir işlem yapmaya çalışırken dikkatli olun.