From d030fd1f6f95d25a859fc52751e5e1b5a042e3eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 24 Apr 2024 10:30:19 +0200 Subject: [PATCH] Translate policy.asc --- book/08-customizing-git/sections/policy.asc | 207 ++++++++++---------- 1 file changed, 104 insertions(+), 103 deletions(-) diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 852a52ad..6db07754 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -1,25 +1,25 @@ [[_an_example_git_enforced_policy]] -=== An Example Git-Enforced Policy +=== Bir Örnek: Mecburi Git Politikası (((policy example))) -In this section, you'll use what you've learned to establish a Git workflow that checks for a custom commit message format, and allows only certain users to modify certain subdirectories in a project. -You'll build client scripts that help the developer know if their push will be rejected and server scripts that actually enforce the policies. +Bu bölümde, öğrendiklerinizi kullanarak, özel bir katkı mesaj biçimini kontrol eden ve belirli kullanıcıların bir projedeki belirli alt dizinleri değiştirmesine izin veren bir Git iş akışı oluşturacaksınız. +Geliştiricinin itmesinin reddedilip reddedilmeyeceğini bilmesine yardımcı olan istemci betikleri oluşturacak ve politikaları uygulayan sunucu betikleri oluşturacaksınız. -The scripts we'll show are written in Ruby; partly because of our intellectual inertia, but also because Ruby is easy to read, even if you can't necessarily write it. -However, any language will work – all the sample hook scripts distributed with Git are in either Perl or Bash, so you can also see plenty of examples of hooks in those languages by looking at the samples. +Göstereceğimiz betikler (kısmen zihinsel ataletimizden dolayı) Ruby dilinde yazılmıştır, ancak bir diğer sebebi de yazamıyor olsanız bile, Ruby'nin okunması kolay bir dil olmasıdır. +Ancak herhangi bir dil işe yarayacaktır (Git ile birlikte dağıtılan tüm örnek kanca betikleri Perl veya Bash'te yazılmıştır ve örnekleri inceleyerek, bu dillerdeki kancaları görebilirsiniz). -==== Server-Side Hook +==== Sunucu Tarafı Kancası -All the server-side work will go into the `update` file in your `hooks` directory. -The `update` hook runs once per branch being pushed and takes three arguments: +Tüm sunucu tarafı işlemleriniz, `hooks` dizininizdeki `update` dosyasına gidecektir. +`update` kancası, itilen her dal için bir kez çalışır ve üç argüman alır: -* The name of the reference being pushed to -* The old revision where that branch was -* The new revision being pushed +* İtinilen referansın adı +* O dalın eski sürümü +* İtilen yeni sürüm -You also have access to the user doing the pushing if the push is being run over SSH. -If you've allowed everyone to connect with a single user (like ``git'') via public-key authentication, you may have to give that user a shell wrapper that determines which user is connecting based on the public key, and set an environment variable accordingly. -Here we'll assume the connecting user is in the `$USER` environment variable, so your update script begins by gathering all the information you need: +Ayrıca, itmenin SSH üzerinden gerçekleştirilip gerçekleştirilmediğine bağlı olarak iten kullanıcıya da erişiminiz vardır. +Herkesin tek bir kullanıcıyla (örneğin, `git`) genel anahtar kimlik doğrulaması yoluyla bağlanmasına izin verdiyseniz, bu kullanıcıya, hangi kullanıcının genel anahtara dayanarak bağlandığını belirleyen ve buna göre bir ortam değişkeni ayarlayan bir kabuk sarmalayıcı (shell wrapper) vermeniz gerekebilir. +Burada, bağlantı kuran kullanıcının `$USER` ortam değişkeninde olduğunu varsayacağız, bu nedenle güncelleme betiğiniz ihtiyacınız olan tüm bilgileri toplayarak işe başlar: [source,ruby] ---- @@ -34,19 +34,19 @@ puts "Enforcing Policies..." puts "(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" ---- -Yes, those are global variables. -Don't judge – it's easier to demonstrate this way. +Evet bunlar global değişkenler. +Bizi yargılamayın; bu şekilde göstermek daha kolay. [[_enforcing_commit_message_format]] -===== Enforcing a Specific Commit-Message Format +===== Belirli Bir Katkı Mesajı Formatını Zorunlu Hale Getirme -Your first challenge is to enforce that each commit message adheres to a particular format. -Just to have a target, assume that each message has to include a string that looks like ``ref: 1234'' because you want each commit to link to a work item in your ticketing system. -You must look at each commit being pushed up, see if that string is in the commit message, and, if the string is absent from any of the commits, exit non-zero so the push is rejected. +Zorlanacağınız ilk konu, her katkı mesajının belirli bir formata uygun olmasını sağlamaktır. +Sırf bir hedefiniz olsun diye, diyelim ki her katkının iş takip sisteminizde bir iş ögesine bağlanmasını istediğiniz için, her katkı mesajının `ref: 1234` gibi görünen bir dize içermesi şartını koydunuz. +Her itilen katkı mesajında bu dizenin olup olmadığını kontrol etmeli ve eğer dize herhangi bir katkıda yoksa, itmenin reddedilmesi için çıkış yapmalısınız. -You can get a list of the SHA-1 values of all the commits that are being pushed by taking the `$newrev` and `$oldrev` values and passing them to a Git plumbing command called `git rev-list`. -This is basically the `git log` command, but by default it prints out only the SHA-1 values and no other information. -So, to get a list of all the commit SHA-1s introduced between one commit SHA-1 and another, you can run something like this: +`$newrev` ve `$oldrev` değerlerini alıp bunları `git rev-list` adlı bir Git tesisat komutuna ileterek itilen tüm katkıların SHA-1 değerlerinin bir listesini alabilirsiniz. +Bu, temelde `git log` komutudur; ancak varsayılan olarak SHA-1 değerleri dışında hiçbir bilgi yazdırmaz. +Bu nedenle, bir katkı SHA-1 değeri ile diğer bir katkı SHA-1 değeri arasında tanıtılan tüm katkı SHA-1'lerinin bir listesini almak için şöyle bir şey çalıştırabilirsiniz: [source,console] ---- @@ -58,11 +58,11 @@ dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a 17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475 ---- -You can take that output, loop through each of those commit SHA-1s, grab the message for it, and test that message against a regular expression that looks for a pattern. +Bu çıktıyı alıp, her bir katkı SHA-1'i üzerinden dönebilir, onun için mesajı alabilir ve bir model arayan bir düzenli ifadeye karşı test edebilirsiniz. -You have to figure out how to get the commit message from each of these commits to test. -To get the raw commit data, you can use another plumbing command called `git cat-file`. -We'll go over all these plumbing commands in detail in <>; but for now, here's what that command gives you: +Her bir katkı mesajını test etmek için bu katkılardan nasıl katkı mesajını alacağınızı bulmanız gerekmektedir. +Ham katkı verilerini almak için, `git cat-file` adlı başka bir tesisat komutunu kullanabilirsiniz. +Bu tesisat komutlarını detaylı olarak <> bölümünde ele alacağız; ancak şu anda, bu komutun size ne verdiğini aşağıda gösteriyoruz: [source,console] ---- @@ -75,8 +75,8 @@ committer Scott Chacon 1240030591 -0700 changed the version number ---- -A simple way to get the commit message from a commit when you have the SHA-1 value is to go to the first blank line and take everything after that. -You can do so with the `sed` command on Unix systems: +Bir katkının SHA-1 değerine sahipken katkı mesajını almanın basit bir yolu, ilk boş satıra gitmek ve o satırdan sonrasını almaktır. +Bunu Unix sistemlerinde `sed` komutuyla yapabilirsiniz: [source,console] ---- @@ -84,9 +84,9 @@ $ git cat-file commit ca82a6 | sed '1,/^$/d' changed the version number ---- -You can use that incantation to grab the commit message from each commit that is trying to be pushed and exit if you see anything that doesn't match. -To exit the script and reject the push, exit non-zero. -The whole method looks like this: +incantation'ı kullanarak itilmeye çalışılan her katkının mesajını alabilir ve eşleşmeyen herhangi bir şey gördüğünüzde çıkabilirsiniz. +İtmeyi reddederek betiği sonlandırmak için sıfırsız (non-zero) çıkış yapın. +Yöntemin tamamı şöyle görünüyor: [source,ruby] ---- @@ -106,20 +106,19 @@ end check_message_format ---- -Putting that in your `update` script will reject updates that contain commits that have messages that don't adhere to your rule. +Bunu `update` betiğinize koyarak, kuralınıza uymayan mesajları içeren katkıların reddedilmesini sağlayabilirsiniz. -===== Enforcing a User-Based ACL System +===== Kullanıcı Tabanlı bir ACL Sisteminin Uygulanması -Suppose you want to add a mechanism that uses an access control list (ACL) that specifies which users are allowed to push changes to which parts of your projects. -Some people have full access, and others can only push changes to certain subdirectories or specific files. -To enforce this, you'll write those rules to a file named `acl` that lives in your bare Git repository on the server. -You'll have the `update` hook look at those rules, see what files are being introduced for all the commits being pushed, and determine whether the user doing the push has access to update all those files. +Kullanıcıların, hangi projelerin, hangi bölümlerine değişiklik yapmalarına izin verildiğini belirten bir erişim kontrol listesi (ACL) mekanizması eklemek istediğinizi varsayalım. +Bazı kullanıcılar tam erişime sahipken, diğerleri yalnızca belirli alt dizin veya dosyalarad değişiklik yapabilirler. +Bu kısıtlamaları uygulamak için, bu kuralları sunucudaki çıplak Git reponuzda bulunan bir `acl` dosyasına yazacaksınız. `update` kancası bu kurallara bakacaktır: itilen tüm katkılar için tanıtılan dosyaları görecek ve itme işlemini gerçekleştiren kullanıcının tüm bu dosyalara erişiminin olup olmadığını belirleyecektir. -The first thing you'll do is write your ACL. -Here you'll use a format very much like the CVS ACL mechanism: it uses a series of lines, where the first field is `avail` or `unavail`, the next field is a comma-delimited list of the users to which the rule applies, and the last field is the path to which the rule applies (blank meaning open access). -All of these fields are delimited by a pipe (`|`) character. +İlk yapmanız gereken şey ACL'nizi yazmaktır. +Burada, CVS ACL mekanizmasıyla oldukça benzer bir biçim kullanacaksınız: İlk alan `avail` veya `unavail`; bir sonraki alan, kuralın uygulandığı kullanıcıların virgülle ayrılmış bir listesi, ve son alan ise kuralın uygulandığı dizin (boşluk karakteri açık erişim anlamına gelir) şeklinde bir dizi satır kullanılır. +Tüm bu alanlar bir boru (`|`) karakteri ile ayrılmıştır. -In this case, you have a couple of administrators, some documentation writers with access to the `doc` directory, and one developer who only has access to the `lib` and `tests` directories, and your ACL file looks like this: +Senaryomuzda, birkaç yönetici, `doc` dizinine erişimi olan bazı belge yazarları ve yalnızca `lib` ve `tests` dizinlerine erişimi olan bir geliştiriciniz var ve ACL dosyanız şöyle görünüyor: [source] ---- @@ -129,9 +128,9 @@ avail|schacon|lib avail|schacon|tests ---- -You begin by reading this data into a structure that you can use. -In this case, to keep the example simple, you'll only enforce the `avail` directives. -Here is a method that gives you an associative array where the key is the user name and the value is an array of paths to which the user has write access: +Bu veriyi, onu kullanabileceğiniz bir yapıya okuyarak başlıyorsunuz. +Bu örneği basit tutmak için sadece `avail` direktiflerini uygulayacaksınız. +İşte, kullanıcı adının anahtar olduğu ve kullanıcının yazma erişimine sahip olduğu yol dizinini içeren ilişkisel bir dizi (array) veren bir yöntem: [source,ruby] ---- @@ -151,7 +150,7 @@ def get_acl_access_data(acl_file) end ---- -On the ACL file you looked at earlier, this `get_acl_access_data` method returns a data structure that looks like this: +Önceki incelediğiniz ACL dosyasına göre, bu `get_acl_access_data` yöntemi aşağıdaki gibi bir veri yapısı döndürür: [source,ruby] ---- @@ -165,9 +164,9 @@ On the ACL file you looked at earlier, this `get_acl_access_data` method returns "ebronte"=>["doc"]} ---- -Now that you have the permissions sorted out, you need to determine what paths the commits being pushed have modified, so you can make sure the user who's pushing has access to all of them. +İzinleri düzenledikten sonra, itilen katkıların değiştirdiği yolları belirlemeniz gerekiyor. Böylece iten kullanıcının hepsine erişimi olduğundan emin olabilirsiniz. -You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command (mentioned briefly in <>): +`git log` komutuna `--name-only` seçeneğini ekleyerek, tek bir katkıda hangi dosyaların değiştirildiğini oldukça kolayca görebilirsiniz (<> bölümünde bundan kısaca bahsedilmektedir): [source,console] ---- @@ -177,7 +176,7 @@ README lib/test.rb ---- -If you use the ACL structure returned from the `get_acl_access_data` method and check it against the listed files in each of the commits, you can determine whether the user has access to push all of their commits: +`get_acl_access_data` yönteminden dönen ACL yapısını kullanarak ve her bir katkıda listelenen dosyaları bu yapıyla karşılaştırarak, kullanıcının tüm katkılarını itmek için erişime sahip olup olmadığını belirleyebilirsiniz: [source,ruby] ---- @@ -209,14 +208,14 @@ end check_directory_perms ---- -You get a list of new commits being pushed to your server with `git rev-list`. -Then, for each of those commits, you find which files are modified and make sure the user who's pushing has access to all the paths being modified. +Sunucunuza itilen yeni katkıların bir listesini `git rev-list` kullanarak alırsınız. +Ardından, bu katkıların her biri için değiştirilen dosyaları bulur ve iten kullanıcının değiştirilen tüm yollara erişimi olduğundan emin olursunuz. -Now your users can't push any commits with badly formed messages or with modified files outside of their designated paths. +Artık kullanıcılarınız, kötü biçimlendirilmiş mesajlara veya belirlenmiş yolların dışında değiştirilmiş dosyalara sahip katkıları itemezler. -===== Testing It Out +===== Deneme -If you run `chmod u+x .git/hooks/update`, which is the file into which you should have put all this code, and then try to push a commit with a non-compliant message, you get something like this: +`chmod u+x .git/hooks/update` komutunu çalıştırırsanız, bu kodları yerleştirmeniz gereken dosya olan `.git/hooks/update` dosyasına erişim izni verirsiniz. Ardından, uyumsuz bir mesajla bir katkı itmeye çalıştığınızda, aşağıdakine benzer bir çıktı alırsınız: [source,console] ---- @@ -236,8 +235,8 @@ To git@gitserver:project.git error: failed to push some refs to 'git@gitserver:project.git' ---- -There are a couple of interesting things here. -First, you see this where the hook starts running. +Burada birkaç ilginç şey var. +Öncelikle kancanın çalışmaya başladığı yeri görüyorsunuz. [source,console] ---- @@ -245,10 +244,10 @@ Enforcing Policies... (refs/heads/master) (fb8c72) (c56860) ---- -Remember that you printed that out at the very beginning of your update script. -Anything your script echoes to `stdout` will be transferred to the client. +Bunu güncelleme komut dosyanızın en başında yazdırdığınızı unutmayın. +Komut dosyanızın `stdout` 'a yansıttığı her şey istemciye aktarılacaktır. -The next thing you'll notice is the error message. +Bir sonraki fark edeceğiniz şey hata mesajıdır. [source,console] ---- @@ -257,8 +256,8 @@ error: hooks/update exited with error code 1 error: hook declined to update refs/heads/master ---- -The first line was printed out by you, the other two were Git telling you that the update script exited non-zero and that is what is declining your push. -Lastly, you have this: +İlk satır sizin tarafınızdan yazdırıldı, diğer ikisi Git'in size güncelleme komut dosyasının sıfırsız (non-zero) bir durumdan çıktığını ve gönderiminizi reddeden şeyin bu olduğunu söylemesiydi. +Son olarak şunu görürsünüz: [source,console] ---- @@ -267,31 +266,30 @@ To git@gitserver:project.git error: failed to push some refs to 'git@gitserver:project.git' ---- -You'll see a remote rejected message for each reference that your hook declined, and it tells you that it was declined specifically because of a hook failure. +Her reddedilen referans için bir "uzak repo reddedildi" mesajı göreceksiniz ve bu mesaj kancanın başarısız olması nedeniyle özellikle reddedildiğini size bildirir. -Furthermore, if someone tries to edit a file they don't have access to and push a commit containing it, they will see something similar. -For instance, if a documentation author tries to push a commit modifying something in the `lib` directory, they see +Dahası, birinin erişim izni olmayan bir dosyayı düzenlemeye ve içeren bir katkıyı itmeye çalıştığında, benzer bir şey görürler. Örneğin, bir belge yazarı, `lib` dizininde bir şeyi değiştiren bir katkıyı itmeye çalışırsa, aşağıdakine benzer bir çıktı alır: [source,console] ---- [POLICY] You do not have access to push to lib/test.rb ---- -From now on, as long as that `update` script is there and executable, your repository will never have a commit message without your pattern in it, and your users will be sandboxed. +Artık o `update` betiği orada ve çalıştırılabilir olduğu sürece, repo hiçbir zaman istediğiniz biçimde olmayan bir katkı mesajı içermeyecek ve kullanıcılarınız izole edilecekler. -==== Client-Side Hooks +==== İstemci Tarafı Kancaları -The downside to this approach is the whining that will inevitably result when your users' commit pushes are rejected. -Having their carefully crafted work rejected at the last minute can be extremely frustrating and confusing; and furthermore, they will have to edit their history to correct it, which isn't always for the faint of heart. +Bu yaklaşımın dezavantajı, kullanıcıların katkı itmelerinin reddedilmesiyle kaçınılmaz olarak ortaya çıkacak olan şikayetlerdir. +Dikkatle hazırladıkları çalışmalarının son anda reddedilmesi, son derece sinir bozucu ve kafa karıştırıcı olabilir. Ayrıca, bunu düzeltmek için geçmişlerini düzenlemeleri gerekeceğinden, uygulaması her zaman kolay değildir. -The answer to this dilemma is to provide some client-side hooks that users can run to notify them when they're doing something that the server is likely to reject. -That way, they can correct any problems before committing and before those issues become more difficult to fix. -Because hooks aren't transferred with a clone of a project, you must distribute these scripts some other way and then have your users copy them to their `.git/hooks` directory and make them executable. -You can distribute these hooks within the project or in a separate project, but Git won't set them up automatically. +Bu ikileme çözüm, kullanıcıların sunucunun muhtemelen reddedeceği bir şey yaptıklarında onları bilgilendirmek için çalıştırabilecekleri bazı istemci tarafı kancaları sağlamaktır. +Böylece, katkı işlemeden önce ve bu sorunlar daha zor çözülebilir hale gelmeden önce o sorunu düzeltebilirler. +Kancalar bir projenin kopyasıyla aktarılmadığından, bu betikleri başka bir şekilde dağıtmanız ve ardından kullanıcılarınızın bunları `.git/hooks` dizinlerine kopyalamalarını ve çalıştırılabilir hale getirmelerini sağlamanız gerekir. +Bu kancaları projenin içinde veya ayrı bir projede dağıtabilirsiniz, ancak Git bunları otomatik olarak kurmaz. -To begin, you should check your commit message just before each commit is recorded, so you know the server won't reject your changes due to badly formatted commit messages. -To do this, you can add the `commit-msg` hook. -If you have it read the message from the file passed as the first argument and compare that to the pattern, you can force Git to abort the commit if there is no match: +Öncelikle, her katkı kaydedilmeden hemen önce katkı mesajınızı kontrol etmelisiniz, böylece sunucunun kötü biçimlendirilmiş katkı mesajları nedeniyle değişikliklerinizi reddetmeyeceğini bilirsiniz. +Bunu yapmak için, `commit-msg` kancasını ekleyebilirsiniz. +İlk argüman olarak geçirilen dosyadan mesajı okuyup, bunu modele karşılaştırırsanız; eşleşme yoksa Git'i katkıyı iptal etmeye zorlayabilirsiniz: [source,ruby] ---- @@ -307,7 +305,7 @@ if !$regex.match(message) end ---- -If that script is in place (in `.git/hooks/commit-msg`) and executable, and you commit with a message that isn't properly formatted, you see this: +Eğer o betik (`.git/hooks/commit-msg` içinde) yerinde ve çalıştırılabilir durumdaysa ve düzgün biçimlendirilmemiş mesajlı bir katkı işlerseniz, şunu görürsünüz: [source,console] ---- @@ -315,8 +313,8 @@ $ git commit -am 'test' [POLICY] Your message is not formatted correctly ---- -No commit was completed in that instance. -However, if your message contains the proper pattern, Git allows you to commit: +Bu durumda hiçbir katkı tamamlanmaz. +Ancak, mesajınız uygun modeli içeriyorsa, Git katkıyı işlemenize izin verir: [source,console] ---- @@ -325,8 +323,8 @@ $ git commit -am 'test [ref: 132]' 1 file changed, 1 insertions(+), 0 deletions(-) ---- -Next, you want to make sure you aren't modifying files that are outside your ACL scope. -If your project's `.git` directory contains a copy of the ACL file you used previously, then the following `pre-commit` script will enforce those constraints for you: +Sonraki adım olarak, ACL kapsamınız dışındaki dosyaları değiştirmediğinizden emin olmak isterseniz. +Projenizin `.git` dizini, önceki kullandığınız ACL dosyasının bir kopyasını içeriyorsa, aşağıdaki `pre-commit` betiği bu kısıtlamaları sizin için uygulayacaktır: [source,ruby] ---- @@ -358,50 +356,53 @@ end check_directory_perms ---- -This is roughly the same script as the server-side part, but with two important differences. -First, the ACL file is in a different place, because this script runs from your working directory, not from your `.git` directory. -You have to change the path to the ACL file from this +Bu betik, sunucu tarafı kısmıyla hemen hemen aynıdır, ancak iki önemli fark vardır: +İlk olarak, ACL dosyası farklı bir yerde bulunur, çünkü bu betik `.git` dizininizden değil, çalışma dizininizden çalıştırılır. +Bu nedenle ACL dosyasının yolunu değiştirmeniz gerekmektedir. + +Bundan: [source,ruby] ---- access = get_acl_access_data('acl') ---- -to this: +şuna: [source,ruby] ---- access = get_acl_access_data('.git/acl') ---- -The other important difference is the way you get a listing of the files that have been changed. -Because the server-side method looks at the log of commits, and, at this point, the commit hasn't been recorded yet, you must get your file listing from the staging area instead. -Instead of +Diğer önemli fark, değiştirilen dosyaların bir listesini nasıl elde ettiğinizdir. +Sunucu tarafı yöntemi, katkı günlüğüne bakar ama bu noktada katkı henüz kaydedilmemiş olduğundan, dosya listenizi izlem alanından almanız gerekir. + +şunun yerine: [source,ruby] ---- files_modified = `git log -1 --name-only --pretty=format:'' #{ref}` ---- -you have to use +bunu kullanmalısınız: [source,ruby] ---- files_modified = `git diff-index --cached --name-only HEAD` ---- -But those are the only two differences – otherwise, the script works the same way. -One caveat is that it expects you to be running locally as the same user you push as to the remote machine. -If that is different, you must set the `$user` variable manually. +Bu ikisi aradaki yegane farklılıklardır, bunlar dışında, betik aynı şekilde çalışır. +Bir diğer önemli not: sizden yerel makinenizde çalışırken veya uzak makineye iterken aynı kullanıcı adıyla çalışmanız beklenir. +Bu ikisi farklıysa, `$user` değişkenini manuel olarak ayarlamanız gerekir. -One other thing we can do here is make sure the user doesn't push non-fast-forwarded references. -To get a reference that isn't a fast-forward, you either have to rebase past a commit you've already pushed up or try pushing a different local branch up to the same remote branch. +Burada yapabileceğimiz başka bir şey, kullanıcının ileri-sarmasız (non-fast-forwarded) referanslar itmemesini sağlamaktır. +ileri-sarmasız bir referans almak için, zaten ittiğiniz bir katkıyı tekrar düzenlemek veya aynı uzak dal üzerine farklı bir yerel dalı itmek zorundasınız. -Presumably, the server is already configured with `receive.denyDeletes` and `receive.denyNonFastForwards` to enforce this policy, so the only accidental thing you can try to catch is rebasing commits that have already been pushed. +Otomatik olarak, sunucunun zaten bu politikayı uygulamak için `receive.denyDeletes` ve `receive.denyNonFastForwards` ile yapılandırıldığını varsayıyoruz, bu yüzden yakalamaya çalışabileceğiniz tek kaza, zaten itilmiş katkıları yeniden temellendirilmesidir. -Here is an example pre-rebase script that checks for that. -It gets a list of all the commits you're about to rewrite and checks whether they exist in any of your remote references. -If it sees one that is reachable from one of your remote references, it aborts the rebase. +İşte bu durumu kontrol eden bir yeniden temellendirme öncesi betiği örneği: +Yeniden yazacağınız tüm katkıların bir listesini alır ve bunların herhangi birinin, herhangi bir uzak referansta var olup olmadığını kontrol eder. +Bir uzak referanstan ulaşılabilir birini görürse, yeniden temellendirme işlemini iptal eder. [source,ruby] ---- @@ -428,16 +429,16 @@ target_shas.each do |sha| end ---- -This script uses a syntax that wasn't covered in <>. -You get a list of commits that have already been pushed up by running this: +Bu betik, <> bölümünde ele alınmayan bir sözdizimi kullanır. +Zaten yukarı itilmiş katkıları almak için şunu çalıştırarak bir liste alabilirsiniz: [source,ruby] ---- `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}` ---- -The `SHA^@` syntax resolves to all the parents of that commit. -You're looking for any commit that is reachable from the last commit on the remote and that isn't reachable from any parent of any of the SHA-1s you're trying to push up – meaning it's a fast-forward. +`SHA^@` sözdizimi, bu katkının tüm öncellerinde çözülür. +Ulaşılabilir herhangi bir katkı arıyorsunuz ve bu katkı, itmeye çalıştığınız SHA-1'lerin herhangi birinin herhangi bir öncelinden ulaşılamadığı anlamına gelir. Yani ileri-sarma (fast-forward)'dır. -The main drawback to this approach is that it can be very slow and is often unnecessary – if you don't try to force the push with `-f`, the server will warn you and not accept the push. -However, it's an interesting exercise and can in theory help you avoid a rebase that you might later have to go back and fix. +Bu yaklaşımın başlıca dezavantajı çok yavaş olabilmesi ve genellikle gereksiz olmasıdır. Zorla itme (forced push) işlemi yapmazsanız, sunucu sizi uyaracak ve itmeyi kabul etmeyecektir. +Ancak, bu ilginç bir egzersizdir ve teorik olarak daha sonra geri dönüp düzeltmeniz gerekebilecek bir yeniden temellendirme işleminden kaçınmanıza yardımcı olabilir.