Translate client-hg.asc

book/09-git-and-other-scms/sections/client-hg.asc

@@ -1,19 +1,19 @@
-==== Git and Mercurial
+==== Git ve Mercurial
 
 (((Interoperation with other VCSs, Mercurial)))
 (((Mercurial)))
-The DVCS universe is larger than just Git.
-In fact, there are many other systems in this space, each with their own angle on how to do distributed version control correctly.
-Apart from Git, the most popular is Mercurial, and the two are very similar in many respects.
+DVCS evreni yalnızca Git'ten ibaret değildir.
+Aslında bu alanda, dağıtılmış sürüm kontrolünün doğru şekilde nasıl yapılacağı konusunda her birinin kendi bakış açısı olan birçok sistem daha vardır.
+Git'ten sonra en popüler olanı Mercurial'dır ve bu ikisi birçok yönden çok benzer.
 
-The good news, if you prefer Git's client-side behavior but are working with a project whose source code is controlled with Mercurial, is that there's a way to use Git as a client for a Mercurial-hosted repository.
-Since the way Git talks to server repositories is through remotes, it should come as no surprise that this bridge is implemented as a remote helper.
-The project's name is git-remote-hg, and it can be found at https://github.com/felipec/git-remote-hg[].
+Git'in istemci tarafı davranışını tercih ediyorsanız ancak kaynak kodu Mercurial tarafından kontrol edilen bir projeyle çalışıyorsanız; iyi haber, Git'i Mercurial tarafından barındırılan bir reponun istemcisi olarak kullanmanın bir yolu vardır.
+Git'in sunucu repolarıyla iletişim kurma şekli uzak repolar aracılığıyla olduğu için, bu köprünün bir uzak yardımcı olarak uygulandığı şaşırtıcı olmamalıdır. 
+Projenin adı git-remote-hg'dir ve https://github.com/felipec/git-remote-hg[] adresinde bulunabilir.
 
 ===== git-remote-hg
 
-First, you need to install git-remote-hg.
-This basically entails dropping its file somewhere in your path, like so:
+Öncelikle git-remote-hg'yi kurmanız gerekiyor.
+Bu, temel olarak dosyasını yolunuzun üzerinde bir yere bırakmayı gerektirir:
 
 [source,console]
 ----
@@ -22,35 +22,35 @@ $ curl -o ~/bin/git-remote-hg \
 $ chmod +x ~/bin/git-remote-hg
 ----
 
-…assuming `~/bin` is in your `$PATH`.
-Git-remote-hg has one other dependency: the `mercurial` library for Python.
-If you have Python installed, this is as simple as:
+…'~/bin' öğesinin '$PATH' dizininizde olduğunu varsayıyoruz.
+Git-remote-hg'nin başka bir bağımlılığı daha var: Python için "Mercurial" kütüphanesi.
+Python'u yüklediyseniz, bu şu kadar basittir:
 
 [source,console]
 ----
 $ pip install mercurial
 ----
 
-(If you don't have Python installed, visit https://www.python.org/[] and get it first.)
+(Python yüklü değilse https://www.python.org/[] adresini ziyaret edin ve önce onu kurun.)
 
-The last thing you'll need is the Mercurial client.
-Go to https://www.mercurial-scm.org/[] and install it if you haven't already.
+İhtiyacınız olan son şey Mercurial istemcisidir.
+https://www.mercurial-scm.org/[] adresine gidin ve henüz yapmadıysanız yükleyin.
 
-Now you're ready to rock.
-All you need is a Mercurial repository you can push to.
-Fortunately, every Mercurial repository can act this way, so we'll just use the "hello world" repository everyone uses to learn Mercurial:
+Artık dansa hazırsınız.
+İhtiyacınız olan tek şey, itebileceğiniz bir Mercurial reposudur.
+Neyse ki, her Mercurial reposu bu şekilde davranır, bu nedenle herkesin Mercurial'ı öğrenmek için kullandığı "merhaba dünya" reposunu kullanacağız:
 
 [source,console]
 ----
 $ hg clone http://selenic.com/repo/hello /tmp/hello
 ----
 
-===== Getting Started
+===== Başlarken
 
-Now that we have a suitable ``server-side'' repository, we can go through a typical workflow.
-As you'll see, these two systems are similar enough that there isn't much friction.
+Artık uygun bir “sunucu tarafı” repomuz olduğuna göre, tipik bir iş akışını gerçekleştirebiliriz.
+Göreceğiniz üzere, bu iki sistem fazla sürtünme olmayacak kadar benzerdir.
 
-As always with Git, first we clone:
+Git'te her zaman olduğu gibi önce repoyu kopyalarız:
 
 [source,console]
 ----
@@ -61,13 +61,13 @@ $ git log --oneline --graph --decorate
 * 65bb417 Create a standard "hello, world" program
 ----
 
-You'll notice that working with a Mercurial repository uses the standard `git clone` command.
-That's because git-remote-hg is working at a fairly low level, using a similar mechanism to how Git's HTTP/S protocol is implemented (remote helpers).
-Since Git and Mercurial are both designed for every client to have a full copy of the repository history, this command makes a full clone, including all the project's history, and does it fairly quickly.
+Mercurial reposuyla çalışmanın standart "git clone" komutunu kullandığını fark edeceksiniz.
+Bunun nedeni, git-remote-hg'nin Git'in HTTP/S protokolünün uygulanmasına (uzaktan yardımcılar) benzer bir mekanizma kullanarak oldukça düşük bir düzeyde çalışmasıdır.
+Git ve Mercurial'ın her ikisi de her kullanıcının repo geçmişinin tam bir kopyasına sahip olması için tasarlandığından, bu komut tüm projenin geçmişini içeren tam bir kopya oluşturur ve bunu çok hızlı bir şekilde yapar.
 
-The log command shows two commits, the latest of which is pointed to by a whole slew of refs.
-It turns out some of these aren't actually there.
-Let's take a look at what's actually in the `.git` directory:
+Log komutu, en sonuncusu bir dizi referans tarafından işaret edilen iki işlemi gösterir.
+Bunlardan bazılarının aslında orada olmadığı ortaya çıktı.
+`.git` dizininde gerçekte ne olduğuna bir bakalım:
 
 [source,console]
 ----
@@ -91,13 +91,13 @@ $ tree .git/refs
 9 directories, 5 files
 ----
 
-Git-remote-hg is trying to make things more idiomatically Git-esque, but under the hood it's managing the conceptual mapping between two slightly different systems.
-The `refs/hg` directory is where the actual remote refs are stored.
-For example, the `refs/hg/origin/branches/default` is a Git ref file that contains the SHA-1 starting with ``ac7955c'', which is the commit that `master` points to.
-So the `refs/hg` directory is kind of like a fake `refs/remotes/origin`, but it has the added distinction between bookmarks and branches.
+Git-remote-hg işleri daha deyimsel olarak Git benzeri hale getirmeye çalışır, ancak aslında birbirinden biraz farklı iki sistem arasındaki kavramsal eşlemeyi yönetir.
+'refs/hg' dizini gerçek uzak referansların saklandığı yerdir.
+Örneğin, "refs/hg/origin/branches/default", "master"ın işaret ettiği katkı olan "ac7955c" ile başlayan SHA-1'i içeren bir Git ref dosyasıdır.
+Yani 'refs/hg' dizini bir nevi sahte 'refs/remotes/Origin' gibidir, ancak yer imleri ve dallar arasında ek bir ayrım vardır.
 
-The `notes/hg` file is the starting point for how git-remote-hg maps Git commit hashes to Mercurial changeset IDs.
-Let's explore a bit:
+'notes/hg' dosyası, git-remote-hg'nin Git katkı karmalarını Mercurial değişiklik kümesi kimlikleriyle nasıl eşlediğinin başlangıç noktasıdır.
+Hadi biraz araştıralım:
 
 [source,console]
 ----
@@ -119,28 +119,28 @@ $ git cat-file -p ac9117f
 0a04b987be5ae354b710cefeba0e2d9de7ad41a9
 ----
 
-So `refs/notes/hg` points to a tree, which in the Git object database is a list of other objects with names.
-`git ls-tree` outputs the mode, type, object hash, and filename for items inside a tree.
-Once we dig down to one of the tree items, we find that inside it is a blob named ``ac9117f'' (the SHA-1 hash of the commit pointed to by `master`), with contents ``0a04b98'' (which is the ID of the Mercurial changeset at the tip of the `default` branch).
+Yani 'refs/notes/hg', Git nesne veritabanında adları olan diğer nesnelerin listesi olan bir ağaca işaret eder.
+'git ls-tree' bir ağacın içinde yer alan öğeler için: mod, tür, nesne karması ve dosya adını verir.
+Ağaç öğelerinden birini incelediğimizde, içinde ``ac9117f'' ("master" ile gösterilen katkının SHA-1 karması) adında ve ``0a04b98'' içeriğine sahip bir blob olduğunu görürüz (bu, 'varsayılan' dalın ucundaki Mercurial değişiklik kümesinin kimliğidir).
 
-The good news is that we mostly don't have to worry about all of this.
-The typical workflow won't be very different from working with a Git remote.
+Güzel olan şu ki, çoğunlukla tüm bunlar için endişelenmemize gerek yoktur.
+Tipik iş akışı Git uzaktan reposuyla çalışmaktan çok farklı olmayacaktır.
 
-There's one more thing we should attend to before we continue: ignores.
-Mercurial and Git use a very similar mechanism for this, but it's likely you don't want to actually commit a `.gitignore` file into a Mercurial repository.
-Fortunately, Git has a way to ignore files that's local to an on-disk repository, and the Mercurial format is compatible with Git, so you just have to copy it over:
+Devam etmeden önce ilgilenmemiz gereken bir şey daha var: yoksayılanlar.
+Mercurial ve Git bunun için çok benzer bir mekanizma kullanır, ancak muhtemelen bir `.gitignore` dosyasını Mercurial reposuna işlemek istemezsiniz.
+Neyse ki Git'in diskteki bir repoda yerel olan dosyaları yok saymanın bir yolu var ve bu Mercurial formatı Git ile uyumludur; dolayısıyla onu kopyalamanız yeterli:
 
 [source,console]
 ----
 $ cp .hgignore .git/info/exclude
 ----
 
-The `.git/info/exclude` file acts just like a `.gitignore`, but isn't included in commits.
+`.git/info/exclude` dosyası tıpkı `.gitignore` gibi davranır ancak katkılara dahil edilmez.
 
-===== Workflow
+===== İş Akışı
 
-Let's assume we've done some work and made some commits on the `master` branch, and you're ready to push it to the remote repository.
-Here's what our repository looks like right now:
+Diyelim ki 'master' dalında bazı değişiklikler yaptık ve bazı katkılar işledik ve siz de bunu uzak repoya göndermeye hazırsınız.
+Repomuz şu anda şöyle görünüyor:
 
 [source,console]
 ----
@@ -151,8 +151,8 @@ $ git log --oneline --graph --decorate
 * 65bb417 Create a standard "hello, world" program
 ----
 
-Our `master` branch is two commits ahead of `origin/master`, but those two commits exist only on our local machine.
-Let's see if anyone else has been doing important work at the same time:
+Bizim 'master' dalımız, `Origin/master` 'dan iki katkı ileridedir, ancak bu iki katkı yalnızca yerel makinemizde mevcuttur.
+Bakalım aynı anda, başka biri de önemli işler yapıyor mu:
 
 [source,console]
 ----
@@ -171,9 +171,9 @@ $ git log --oneline --graph --decorate --all
 * 65bb417 Create a standard "hello, world" program
 ----
 
-Since we used the `--all` flag, we see the ``notes'' refs that are used internally by git-remote-hg, but we can ignore them.
-The rest is what we expected; `origin/master` has advanced by one commit, and our history has now diverged.
-Unlike the other systems we work with in this chapter, Mercurial is capable of handling merges, so we're not going to do anything fancy.
+`--all` bayrağını kullandığımız için, git-remote-hg tarafından dahili olarak kullanılan ``notes`` referanslarını görüyoruz, ancak onları görmezden gelebiliriz.
+Gerisi beklediğimiz gibidir; 'Origin/master' tek bir katkı ilerledi ve artık geçmişimiz ayrıştı.
+Bu bölümde üzerinde çalıştığımız diğer sistemlerden farklı olarak; Mercurial, birleştirme işlemlerini gerçekleştirebilir, dolayısıyla havalı bir şey yapmayacağız.
 
 [source,console]
 ----
@@ -193,8 +193,8 @@ $ git log --oneline --graph --decorate
 * 65bb417 Create a standard "hello, world" program
 ----
 
-Perfect.
-We run the tests and everything passes, so we're ready to share our work with the rest of the team:
+Mükemmel.
+Testleri yapıyoruz ve her şey başarılı oluyor, böylece çalışmalarımızı ekibin geri kalanıyla paylaşmaya hazırız:
 
 [source,console]
 ----
@@ -203,8 +203,8 @@ To hg::/tmp/hello
    df85e87..0c64627  master -> master
 ----
 
-That's it!
-If you take a look at the Mercurial repository, you'll see that this did what we'd expect:
+Bu kadar!
+Mercurial reposuna bakarsanız, bunun beklediğimiz şeyi yaptığını göreceksiniz:
 
 [source,console]
 ----
@@ -228,16 +228,16 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
      Create a standard "hello, world" program
 ----
 
-The changeset numbered _2_ was made by Mercurial, and the changesets numbered _3_ and _4_ were made by git-remote-hg, by pushing commits made with Git.
+_2_ numaralı değişiklik seti Mercurial tarafından, _3_ ve _4_ numaralı değişiklik seti ise Git-remote-hg tarafından Git ile yapılan katkıların itilmesiyle yapıldı.
 
-===== Branches and Bookmarks
+===== Dallar ve Yer İmleri (Bookmarks)
 
-Git has only one kind of branch: a reference that moves when commits are made.
-In Mercurial, this kind of a reference is called a ``bookmark,'' and it behaves in much the same way as a Git branch.
+Git'in yalnızca tek bir tür dalı vardır: katkılar işlendiğinde hareket eden bir referans.
+Mercurial'da bu tür bir referansa ``yer imi`` (bookmark) adı verilir ve Git dalıyla hemen hemen aynı şekilde davranır.
 
-Mercurial's concept of a ``branch'' is more heavyweight.
-The branch that a changeset is made on is recorded _with the changeset_, which means it will always be in the repository history.
-Here's an example of a commit that was made on the `develop` branch:
+Mercurial'ın ``dal`` kavramı daha ağırdır.
+Değişiklik kümesinin yapıldığı dal, değişiklik kümesiyle birlikte kaydedilir. Bu da her zaman repo geçmişinde yeralacağı anlamına gelir.
+`develop` dalında yapılan bir katkı örneği:
 
 [source,console]
 ----
@@ -250,11 +250,11 @@ date:        Thu Aug 14 20:06:38 2014 -0700
 summary:     More documentation
 ----
 
-Note the line that begins with ``branch''.
-Git can't really replicate this (and doesn't need to; both types of branch can be represented as a Git ref), but git-remote-hg needs to understand the difference, because Mercurial cares.
+``branch`` ile başlayan satıra dikkat edin.
+Git bunu gerçekten kopyalayamaz (her iki dal türü de Git referansı olarak temsil edilebildiği için gerek de yoktur zaten), ancak Mercurial bunu önemsediği için git-remote-hg'nin farkı anlaması gereklidir.
 
-Creating Mercurial bookmarks is as easy as creating Git branches.
-On the Git side:
+Mercurial yer imleri oluşturmak Git dalları oluşturmak kadar kolaydır.
+Git tarafında:
 
 [source,console]
 ----
@@ -265,8 +265,8 @@ To hg::/tmp/hello
  * [new branch]      featureA -> featureA
 ----
 
-That's all there is to it.
-On the Mercurial side, it looks like this:
+Hepsi bu kadardır.
+Mercurial tarafında ise şöyle görünür:
 
 [source,console]
 ----
@@ -295,10 +295,10 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
      Create a standard "hello, world" program
 ----
 
-Note the new `[featureA]` tag on revision 5.
-These act exactly like Git branches on the Git side, with one exception: you can't delete a bookmark from the Git side (this is a limitation of remote helpers).
+Revizyon 5'teki yeni `[featureA]` etiketine dikkat edin.
+Bunlar, bir istisna dışında Git tarafındaki Git dalları gibi davranır (Git tarafından bir yer işaretini silemezsiniz: bu, uzak yardımcılara yönelik bir sınırlamadır).
 
-You can work on a ``heavyweight'' Mercurial branch also: just put a branch in the `branches` namespace:
+Ayrıca ``ağır'' bir Mercurial dalı üzerinde de çalışabilirsiniz: ``branches`` ad alanına (namespace) bir dal koymanız yeterlidir:
 
 [source,console]
 ----
@@ -311,7 +311,7 @@ To hg::/tmp/hello
  * [new branch]      branches/permanent -> branches/permanent
 ----
 
-Here's what that looks like on the Mercurial side:
+Mercurial tarafın şöyle görünür:
 
 [source,console]
 ----
@@ -344,11 +344,11 @@ o    changeset:   5:bd5ac26f11f9
 [...]
 ----
 
-The branch name ``permanent'' was recorded with the changeset marked _7_.
+``permanent`` (kalıcı) dal adı, _7_ işaretli değişiklik kümesiyle kaydedildi.
 
-From the Git side, working with either of these branch styles is the same: just checkout, commit, fetch, merge, pull, and push as you normally would.
-One thing you should know is that Mercurial doesn't support rewriting history, only adding to it.
-Here's what our Mercurial repository looks like after an interactive rebase and a force-push:
+Git açısından bakıldığında, bu dal stillerinden herhangi biriyle çalışmak aynıdır: normalde yaptığınız gibi yalnızca geçiş yapın, kaydedin, getirin, birleştirin, çekin ve itin.
+Bilmeniz gereken bir şey de Mercurial'ın tarihin yeniden yazılmasını desteklememesidir. Ona yalnızca ekleme yapabilirsiniz.
+Etkileşimli bir yeniden temelleme (rebase) ve zorla itme (forced push) sonrasında Mercurial repomuz şu şekilde görünür:
 
 [source,console]
 ----
@@ -387,11 +387,10 @@ o  0   0a04b987be5a   2005-08-26 01:20 -0700   mpm
      Create a standard "hello, world" program
 ----
 
-Changesets _8_, _9_, and _10_ have been created and belong to the `permanent` branch, but the old changesets are still there.
-This can be *very* confusing for your teammates who are using Mercurial, so try to avoid it.
+_8_, _9_ ve _10_ değişiklik kümeleri oluşturuldu ve `permanent` dalına aitler, ancak eski değişiklik kümeleri hâlâ duruyor.
+Bu, Mercurial kullanan takım arkadaşlarınız için *çok* kafa karıştırıcı olabilir, bu yüzden bundan kaçınmaya çalışın.
 
+===== Özetle Mercurial
 
-===== Mercurial Summary
-
-Git and Mercurial are similar enough that working across the boundary is fairly painless.
-If you avoid changing history that's left your machine (as is generally recommended), you may not even be aware that the other end is Mercurial.
+Git ve Mercurial, sınırın ötesinde çalışmanın oldukça sancısız olmasını sağlayacak kadar benzerdir.
+(Genellikle önerildiği üzere) makinenizden kalan geçmişi değiştirmekten kaçınırsanız, diğer ucun Mercurial olduğunun farkına bile varmazsınız.