diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index db30adda..59d5754f 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -70,13 +70,13 @@ Eğer 32-bit'lik bir Windows sistemdeyseniz ya da 64-bit'lik sistemde 64-bit'lik $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" ---- -[NOT] +[NOTE] ==== Vim, Emacs ve Notepad++, Windows, Linux ya da macOS gibi sistemlerde geliştiriciler tarafından sıkça kullanılan popüler editörlerdir. Eğer başka bir editör ya da 32-bit'lik sürüm kullanıyorsanız, favori editörünüzü nasıl kuracağınız hakkında bilgi almak için şurayı okuyabilirsiniz: <> ==== -[UYARI] +[WARNING] ==== Eğer editörlerinizi bu şekilde kurmazsanız, Git çalıştırmak için uğraştığında kendinizi çok kafa karıştırıcı bir durumda bulabilirsiniz. Windows sistemdineki bir örnek, Git tarafından başlatılan bir düzenleme sırasında erken sona eren bir Git işlemi içerebilir. @@ -108,7 +108,7 @@ $ git config user.name John Doe ---- -[NOT] +[NOTE] ==== Git birden fazla dosyadan aynı yapılandırma değişkeni değerlerini okuyabildiği için beklemediğiniz bir değerle karşılaşmanız ve nedenini anlayamamanız olasıdır. Bunun gibi durumlarda Git'i o değerin _kökeniyle_ sorgu yapabilir ve hangi yapılandırma dosyasının o değeri belirlemede son sözü söylediğini öğrenebilirsiniz: diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 689999cc..44e61228 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -4,7 +4,7 @@ Git'i kullanmaya başlamadan önce onu bilgisayarınıza kurmuş olmanız gerekm Halihazırda yüklenmiş olsa bile son sürüm olup olmadığını kontrol etmek, değilse de son sürüme güncellemek faydalı olacaktır. İsterseniz paket olarak, isterseniz başka bir kurucuyla ya da kaynak kodunu indirip kendiniz derleyerek Git'i yükleyebilirsiniz. -[NOT] +[NOTE] ==== Bu kitap Git'in *2.8.0* sürümü temel alınarak yazılmıştır. Kullanacağımız çoğu kod Git'in en eski sürümlerinde bile çalışacak olsa da, eğer eski sürüm kullanıyorsanız bazıları çalışmayabilir ya da beklenenden daha farklı çalışabilir. diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 21994f0e..d81d9e78 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,5 +1,5 @@ -Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu aradığınız bölüm. -Bu bölüm, Git'te zamanınızı harcayacağınız şeylerin büyük çoğunluğunu yapmak için ihtiyacınız olan her temel komutu kapsar. +Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu aradığınız bölümdür. +Bu bölüm, Git'te zamanınızı harcayacağınız şeylerin büyük çoğunluğunu yapmak için ihtiyacınız olan tüm temel komutları kapsar. Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi izleme alıp (stage) uzak repoya kaydedebilecek seviyeye geleceksiniz. Ayrıca Git'i belirli dosyaları ve dosya kalıplarını yok sayacak şekilde nasıl ayarlayacağınızı, hataları hızlı ve kolay bir şekilde nasıl geri alacağınızı, projenizin geçmişine nasıl göz atacağınızı, katkılar (commit) arasındaki değişiklikleri nasıl görüntüleyeceğinizi ve uzak repolarla nasıl kod alışverişi yapacağınızı göstereceğiz. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 2aba4ee3..3d19ad53 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -264,12 +264,12 @@ doc/*.txt doc/**/*.pdf ---- -[İPUCU] +[TIP] ==== Eğer projeniz için bir başlangıç noktasına ihtiyaç duyuyorsanız GitHub, https://github.com/github/gitignore adresinde pekçok farklı proje ve dilde ``.gitignore`` dosya örneklerinin kapsamlı bir listesini tutmaktadır. ==== -[NOT] +[NOTE] ==== Basit projelerde, bir proje kök dizininde, tüm alt dizinler için geçerli olmak üzere tek bir ".gitignore" dosyası bulunur. Yine de alt dizinlerde ek `.gitignore` dosyalarının bulunması da mümkündür. @@ -410,7 +410,7 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -[NOT] +[NOTE] Harici Araçlarda .Git Diff ==== Kitabın geri kalanında `git diff` komutunu çeşitli şekillerde kullanmaya devam edeceğiz. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 140bd3c5..246a4fa7 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -9,7 +9,7 @@ Başkalarıyla işbirliği yapmak, bu uzak repoları yönetmeyi ve işlerinizi p Uzak repoların yönetilmesi; uzak repoların nasıl ekleneceğini, artık geçerli olmayan uzak sunucuların nasıl kaldırılacağını, çeşitli uzak dalların nasıl yönetileceğini, bunların izlenip izlenmediğini nasıl tanımlayacağınızı ve daha fazlasını bilmeyi gerektirir. Bu bölümde bu uzaktan yönetim becerilerinden bazılarını ele alacağız. -[NOT] +[NOTE] .Uzak repolar yerel makinenizde olabilir. ==== Aslında sizinle aynı ana bilgisayar üzerinde olan bir ``uzak`` repoyla çalışıyor olmanız tamamen mümkündür. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 094efd3c..d38f79eb 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -39,7 +39,7 @@ v1.8.5.4 v1.8.5.5 ---- -[NOT] +[NOTE] .Joker etiket karakterlerini listelemek `-l` veya `--list` gerektirir ==== Eğer tüm etiketlerin toplu bir listesini istiyorsanız `git tag` komutunu çalıştırabilirsiniz. @@ -220,7 +220,7 @@ To git@github.com:schacon/simplegit.git Artık başka biri reponuzu kopyaladığında veya reponuzdan bilgi aldığında tüm etiketlerinizi de alacaktır. -[NOT] +[NOTE] .`git push` her iki türde etiketi de iter ==== Etiketleri `git push --tags` kullanarak itmek, hafif ve açıklamalı etiketler arasında bir ayrım yapmaz. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index cedbe9d8..937c0b24 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -31,7 +31,7 @@ $ git commit --amend Bu işlemin sonucunda, ikinci katkınızın ilk katkınızın yerini aldığı tek bir katkı elde edersiniz. -[NOT] +[NOTE] ==== Şunu anlamanız özellikle önemli: Eğer (amend komutuyla) son katkınızı onarırsanız; aslında son katkınızı düzeltmekten ziyade, eski katkınızı ortadan kaldırıp, onun yerine yeni bir katkı işlemektesiniz. Sanki önceki katkı hiç gerçekleşmemiş ve repo geçmişinizde görünmeyecekmiş gibi. @@ -86,7 +86,7 @@ Changes not staged for commit: Komut biraz garip ama neticede işe yarıyor. `CONTRIBUTING.md` dosyası değiştirildi ancak nihai durumda "stage"de (izlemde) değil. -[NOT] +[NOTE] ===== `git reset`in tehlikeli bir komut olabileceği doğrudur, özellikle de `--hard` bayrağını kullanırsanız. Ancak yukarıda açıklanan senaryoda çalışma dizininizdeki dosyaya dokunulmaz, dolayısıyla nispeten güvenlidir. @@ -128,7 +128,7 @@ Changes to be committed: Değişikliklerin geri alındığını görebilirsiniz. -[ÖNEMLİ] +[IMPORTANT] ===== `git checkout -- ` komutunun tehlikeli bir komut olduğunu anlamanız çok önemlidir. Bu dosyada yaptığınız tüm yerel değişiklikler kayboldu! diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index d82178db..9f2426eb 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -248,7 +248,7 @@ Bu komut birçok formatla çalışır: "2008-01-15" gibi belirli bir tarih veya Listeyi, bazı arama kriterleriyle eşleşen katkılara göre de süzebilirsiniz. `--author` seçeneği belirli bir yazara göre süzmenizi sağlar ve `--grep` seçeneği katkı mesajlarındaki anahtar kelimeleri aramanızı sağlar. -[NOT] +[NOTE] ==== Hem `--author` hem de `--grep` arama koşullarının birden fazla örneğini de aynı anda kullanabilirsiniz. Bu katkı çıktısını sadece uygun düşen `--author` ve `--grep` kalıplarıyla eşleşen katkılarla sınırlayacaktır. @@ -300,7 +300,7 @@ b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unbor Bu komutla, Git kaynak kodu geçmişindeki yaklaşık 40.000 katkıdan, bu kıstaslara uyan sadece 6'sını görebilirsiniz. -[İPUCU] +[TIP] .Birleştirme katkılarının gösterilmesini engelleme ==== Reponuzda kullanılan iş akışına bağlı olarak, günlük geçmişinizdeki katkıların büyük bir yüzdesinin yalnızca birleştirme katkıları olması mümkündür ve bunlar genellikle pek bilgilendirici değildir. diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 59da1f52..669186e8 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -269,7 +269,7 @@ Hit return to start merge resolution tool (opendiff): Eğer varsayılan birleştirme aracı dışında bir birleştirme aracı kullanmak istiyorsanız (Eğer komutu Mac işletim sisteminde çalıştırıyorsanaz Git kendisi `opendiff` aracını seçecektir), "one of the following tools" ifadesinin hemen altında desteklenen tüm araçların listesini görebilirsiniz. Kullanmayı tercih ettiğiniz aracın adını yazmanız yeterlidir. -[NOT] +[NOTE] ==== Karmaşık birleştirme çatışmalarını çözmek için daha gelişmiş araçlara ihtiyacınız varsa, daha fazlasını `<>` bölümünde ele alacağız. ==== diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index a1591c0f..011d584a 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -61,7 +61,7 @@ If you are sure you want to delete it, run 'git branch -D testing'. Eğer gerçekten de dalı silmek ve bu çalışmayı kaybetmek istiyorsanız, yardımcı mesajda belirtildiği gibi Git'i `-D` bayrağıyla dalı silmeye zorlayabilirsiniz. -[İPUCU] +[TIP] ==== Eğer bir katkı veya dal adı verilmezse, yukarıda açıklanan seçenekler, sırasıyla _şu anki dala_ (`--merged` kullanılırsa) birleştirilmiş veya (`--no-merged` kullanılırsa) birleştirilmemiş olan dalları gösterir. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 3f178036..59405a3e 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -38,7 +38,7 @@ Git'te varsayılan dal `master` adıyla ifade edilir (anadal). Katkıları işlemeye başladığınızda, en son işlediğiniz katkıyı gösteren bir `master` dalı alırsınız. Her katkı işlediğinizde, `master` dalı işaretçisi otomatik olarak ileri hareket eder. -[NOT] +[NOTE] ==== Git'teki `master` dalı özel bir dal değildir.(((master))) Tam olarak diğer diğer dallar gibi davranır. @@ -135,7 +135,7 @@ Bu komut iki şey yaptı: Bu aynı zamanda, şu andan itibaren yapacağınız değişikliklerin projenin eski bir sürümünden sapacağı anlamına gelir. Bu `testing` dalındaki yaptığınız çalışmayı geri sararak daha farklı bir yöne gidebilmenizi sağlar. -[NOT] +[NOTE] .Dallar arasında geçiş yapmak çalışma dizinindeki dosyaları değiştirir ==== Git'te dallar arasında geçiş yaparken, çalışma dizininizdeki dosyaların değişeceğini unutmamalısınız! @@ -185,7 +185,7 @@ Bu özellikler, geliştiricileri sık sık dallar oluşturmaları ve kullanmalar Haydi, neden bunu yapmanız gerektiğini görelim. -[NOT] +[NOTE] .Tek komutla dal oluşturmak ve o dala geçiş yapmak ==== Yeni bir dal oluşturmak ve aynı anda o yeni dala geçmek sık karşılaşılan bir durumdur. Bunu tek komutla gerçekleştirebiliriz: `git checkout -b `. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index d665730f..852e1c85 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -21,7 +21,7 @@ Eğer bu sunucudan kopyalama işlemi yapıyorsanız, `git clone` komutu otomatik Git ayrıca üzerinde çalışabileceğiniz bir başlangıç noktası olabilmesi için sizin kendi yerel `master` dalınızı da oluşturur. Bu dal da `origin` sunucusunun `master` dalıyla aynı yerden başlar. -[NOT] +[NOTE] .``origin`` özel değildir ==== "Master" dal adının Git'te özel bir anlamı olmadığı gibi, "origin" adı da özel bir anlama sahip değildir. @@ -91,7 +91,7 @@ Bu da 'Lütfen benim `serverfix` dalımı al ve onu uzaktaki `serverfix` dalı y Bu formatı kullanarak, yerel bir dalı farklı bir isimdeki uzak bir dala itebilirsiniz. Eğer uzakta `serverfix` olarak adlandırılmış bir dal istemiyorsanız, bunun yerine yerel `serverfix` dalınızı uzaktaki projedeki `awesomebranch` dalına itmek için `git push origin serverfix:awesomebranch` komutunu çalıştırabilirsiniz. -[NOT] +[NOTE] .Her defasında şifrenizi yazmayın ==== Eğer bir HTTPS URL'si kullanarak itme işlemi yapıyorsanız, Git sunucusu sizden kimlik doğrulaması için kullanıcı adı ve şifrenizi isteyecektir. @@ -181,7 +181,7 @@ $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ---- -[NOT] +[NOTE] .Üstakım (upstream) kısayolu ==== Eğer kurulu bir takip dalınız varsa, onun üst-akım dalını `@{upstream}` veya `@{u}` kısaltmasıyla işaretleyebilirsiniz. diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index b247aaeb..48e2e8b3 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -3,7 +3,7 @@ Şimdi kendi sunucunuzda bu protokoller üzerinde çalışan bir Git servisi kurmayı ele alacağız. -[NOT] +[NOTE] ==== Burada, temel ve basitleştirilmiş kurulumları yapmak için gereken komutları ve adımları Linux tabanlı bir sunucuda göstereceğiz, ancak bu servisleri macOS veya Windows sunucularında çalıştırmak da mümkündür. Aslında altyapınız içinde canlı bir sunucu kurmak, güvenlik önlemlerinde veya işletim sistem araçlarında farklılıkları beraberinde getirecektir, ancak nasıl yapılacağı konusunda genel olarak fikir sahibi olacağınızı umuyorum. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 3a64c720..4de2d0b2 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -5,7 +5,7 @@ Sunucu tarafında SSH erişimini kurma işlemine geçelim. Bu örnekte, kullanıcılarınızı kimlik doğrulamak için `authorized_keys` (yetkili anahtar) yöntemini kullanacaksınız. Ayrıca, Ubuntu gibi standart bir Linux dağıtımını kullandığınızı varsayıyoruz. -[NOT] +[NOTE] ==== Burada açıklanan birçok işlem, ortak anahtarları manuel olarak kopyalamak ve yüklemek yerine `ssh-copy-id` komutunu kullanarak otomatikleştirilebilir. ==== @@ -96,7 +96,7 @@ Bunun için, eğer hali hazırda yoksa, `/etc/shells` dosyasına `git-shell` kom [source,console] ---- -$ cat /etc/shells # see if `git-shell` is already in there. If not... +$ cat /etc/shells # see if `git-shell` is already in there. If ... $ which git-shell # make sure git-shell is installed on your system. $ sudo -e /etc/shells # and add the path to git-shell from last command ---- @@ -114,7 +114,7 @@ Yine de denerseniz, şunun gibi bir giriş reddi görürsünüz: [source,console] ---- $ ssh git@gitserver -fatal: Interactive git shell is not enabled. +fatal: Interactive git shell is enabled. hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed. ---- diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 28293722..76b04814 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -67,7 +67,7 @@ Fikir, Git'in çağrıldığında HTTP üzerinden veri gönderme ve alma işleml Kendi başına kimlik sormaz, ancak kendini çağıran web sunucu katmanında kolayca kontrol edilebilir. Bu neredeyse CGI yetenekli her web sunucusuyla yapılabilir, bu nedenle en iyi bildiğiniz sunucu ile devam edin. -[NOT] +[NOTE] ==== Apache'de kimlik doğrulama yapılandırması hakkında daha fazla bilgi için Apache kılavuzunu buradan kontrol edebilirsiniz: https://httpd.apache.org/docs/current/howto/auth.html[] diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 0a594a33..b45808a3 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -84,7 +84,7 @@ Daha ileri açıklamalar boş satırlardan sonra gelir. Eğer tüm katkı mesajlarınız bu modele uygunsa, işbirliği yaptığınız geliştiriciler ve sizin için her şey çok daha kolay olacaktır. Git projesinin düzgün biçimlendirilmiş katkı mesajları bulunmaktadır (ne kadar güzel biçimlendirilmiş bir proje-katkı geçmişine sahip olduğunuzu görmek için `git log --no-merges` komutunu çalıştırabilirsiniz). -[NOT] +[NOTE] .Dediğimizi yap, yaptığımızı değil! ==== Bu kitaptaki birçok örnekte olduğu gibi, sırf kısa kesmek adına, böyle güzel biçimlendirilmiş katkı mesajları yazmamış olabiliriz. Uzun ve güzel mesajlar yazmak yerine, hemen `git commit` komutuna `-m` bayrağını ekleyip kullandık. @@ -520,7 +520,7 @@ $ git commit $ git commit ---- -[NOT] +[NOTE] ==== İşinizi tek katkı işleyecek şekilde sıkıştırmak veya yamayı inceleyecek bakım görevlisinin işini kolaylaştırmak amacıyla işi katkılar halinde yeniden düzenlemek için `rebase -i` komutunu kullanmak isteyebilirsiniz. Etkileşimli temelleme (interactive rebasing) hakkında daha fazla bilgi için <> bölümüne bakabilirsiniz. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index fe522fc5..f865318e 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,4 +1,4 @@ -=== Hesap Kurulumu ve Yapılandırma + === Hesap Kurulumu ve Yapılandırma (((GitHub, user accounts))) İlk yapmanız gereken şey ücretsiz bir kullanıcı hesabı oluşturmaktır. @@ -12,7 +12,7 @@ GitHub, e-posta adresinizi doğrulamak için size bir e-posta gönderecektir. E-posta ile gönderilen linki tıklayın ve işleme devam edin. Daha sonra göreceğiniz üzere bu çok önemlidir. -[NOT] +[NOTE] ==== Ücretsiz hesaplar Github'ın tüm işlevlerinden faydalanabilir, ancak tüm projeleriniz herkesin okuma erişimine açıktır. Ücretli planların ayrıca özel projeler oluşturma seçeneğini de vardır, ancak bu kitapta o konuyu ele almayacağız. @@ -42,7 +42,7 @@ image::images/ssh-keys.png["SSH keys" (SSH anahtarı) bağlantısı.] Buradan, `Add an SSH key` (Bir SSH anahtarı ekle) düğmesine tıklayın, anahtarınıza bir isim verin, `~/.ssh/id_rsa.pub` (veya adını ne koyduysanız) dosyanızın içeriğini metin alanına yapıştırın ve `Add key` (Anahtarı ekle) düğmesine tıklayın. -[NOT] +[NOTE] ==== SSH anahtarınıza unutmayacağınız bir isim verdiğinizden emin olun. Her bir anahtarınızı ayrıcı adlandırabilirsiniz (örneğin "Bilgisayarım" veya "İş Hesabı"); böylece daha sonra bir anahtarı iptal etmeniz gerektiğinde, hangisini aradığınızı kolayca belirleyebilirsiniz. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index c58a6c6e..0eac7586 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -8,7 +8,7 @@ Artık bir Github hesabınız olduğuna göre, mevcut bir projeye katkıda bulun Bir erişim izniniz olmayan projeye katkıda bulunmak istiyorsanız, projeyi "çatallayabilirsiniz" (fork). Bir projeyi "çatalladığınızda", GitHub projenin tamamen size ait bir kopyasını oluşturur; bu, sizin derleminizde (derlem: namespace) bulunur ve üzerine değişikliklerinizi itebilirsiniz. -[NOT] +[NOTE] ==== "Projeyi çatallamak" (fork) ifadesi, geçmişte bir bağlamda oldukça olumsuz bir anlam taşımıştır: birinin açık kaynaklı bir projeyi farklı bir yöne taşıması, hatta bazen rekip bir proje oluşturarak katkıcıları bölmesi gibi. Ancak GitHub'da "çatallamak" terimi, sadece: üzerinde değişiklikler yaparak katkı sağlamak amacıyla, açık kaynak kodlu bir projeyi, kendi ad-alanınızda çoğaltmak anlamına gelir. @@ -136,7 +136,7 @@ image::images/blink-03-pull-request-open.png["Birleştirme İsteği" oluşturma] Bu ekranda 'Create pull request' (birleştirme isteği oluştur) düğmesine tıkladığınızda, çatalınızı aldığınız proje sahibi bir değişiklik önerildiği konusunda bir bildirim alacak ve tüm bu bilgilere bağlantı veren bir sayfaya yönlendirilecek. -[NOT] +[NOTE] ==== Birleştirme İstekleri genellikle katkı sağlayan kişi tamamlanmış bir değişikliği yapmaya hazır olduğunda, bu gibi açık projelerde yaygın olarak kullanılır; ancak iç projelerde geliştirme döngüsünün _başında_ da sıklıkla kullanılır. Çünkü Birleştirme İsteği açıldıktan *sonra* bile tema dalına güncelleme yapabilirsiniz. @@ -194,7 +194,7 @@ Bu, çoğu GitHub projesinin kullandığı temel iş akışıdır. Konu dalları oluşturulur, üzerlerinde birleştirme istekleri açılır, bir tartışma başlar, belki daha fazla çalışma yapılır ve sonunda istek ya kapatılır ya da birleştirilir. -[NOT] +[NOTE] .Çatal zorunlu değil ==== Önemli bir nokta da, aynı repodaki iki dal arasında da bir birleştirme isteği açabileceğinizdir. @@ -470,7 +470,7 @@ image::images/markdown-07-emoji.png[Emoji] Bu yorum müthiş faydalı sayılmaz, ama duyguları başka türlü iletmenin zor olduğu bir ortama, eğlenceli bir unsur ekler. -[NOT] +[NOTE] ==== Bu günlerde emoji karakterlerini kullanan çok sayıda ağ hizmeti bulunmaktadır. Ne demek istediğinizi ifade eden emoji bulmanıza yardımcı olacak harika bir referans çizelgesi şurada bulunabilir: diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index a19d7b30..49d8e1b5 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -30,7 +30,7 @@ Projeniz GitHub'da yayınlandığı için, projenizi paylaşmak istediğiniz her GitHub'daki her proje, HTTPS üzerinden `https://github.com//` olarak ve SSH üzerinden `git@github.com:/` olarak erişilebilir. Git, bu URL'lerden her ikisine de erişebilir ve verilen kullanıcı kimlik bilgilerine göre erişim kontrolü sağlanır. -[NOT] +[NOTE] ==== Kullanıcıların projeyi kopyalamak için bir GitHub hesabına ihtiyaç duymamalarından dolayı, herkese açık bir projeyi paylaşmak için HTTPS tabanlı URL'yi tercih etmek genellikle daha iyidir. Eğer kullanıcılara SSH URL'si verirseniz, projenize erişmek için bir hesap ve yüklenmiş bir SSH anahtarına ihtiyaç duyacaklardır. diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 85dbf823..5f5fec28 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -1,20 +1,20 @@ [[_bundling]] -=== Bundling +=== Demetleme (Bundling) -Though we've covered the common ways to transfer Git data over a network (HTTP, SSH, etc), there is actually one more way to do so that is not commonly used but can actually be quite useful. +Git verisini ağ üzerinden aktarmanın yaygın yollarını (HTTP, SSH, vb.) öğrendik, ancak aslında pek kullanılmayan fakat oldukça yararlı olabilen başka bir yol daha vardır. -Git is capable of ``bundling'' its data into a single file. -This can be useful in various scenarios. -Maybe your network is down and you want to send changes to your co-workers. -Perhaps you're working somewhere offsite and don't have access to the local network for security reasons. -Maybe your wireless/ethernet card just broke. -Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via `format-patch`. +Git, verisini tek bir dosya halinde "demetleyebilir" ve bu, çeşitli senaryolarda faydalı olabilir. +Belki ağınız kapalıdır ama değişikliklerinizi iş arkadaşlarınıza göndermek istiyorsunuz. +Belki dışarıda bir yerde çalışıyorsunuz ve güvenlik nedeniyle yerel ağa erişiminiz yoktur. +Belki sadece kablosuz/eternet kartınız bozulmuştur. +Belki şu anda paylaşılan bir sunucuya erişiminiz yok ve birine güncellemeleri e-posta ile göndermek istersiniz ama `format-patch` ile 40 değişikliği aktarmak istemiyorsunuzdur. -This is where the `git bundle` command can be helpful. -The `bundle` command will package up everything that would normally be pushed over the wire with a `git push` command into a binary file that you can email to someone or put on a flash drive, then unbundle into another repository. +İşte burada `git bundle` komutunun yardımcı olabileceği yer vardır. +`bundle` komutu, bir `git push` komutuyla normalde ağ üzerinden gönderilecek her şeyi ikilik (binary) bir dosya demeti haline getirecektir. +Bu dosyayı birine e-posta ile gönderebilir veya bir taşınabilir sürücüye koyup, ardından başka bir repoda açabilirsiniz. -Let's see a simple example. -Let's say you have a repository with two commits: +Basit bir örnek görelim. +İki katkı işlenmiş olan bir repoya sahip olduğunuzu varsayalım: [source,console] ---- @@ -32,7 +32,7 @@ Date: Wed Mar 10 07:34:01 2010 -0800 first commit ---- -If you want to send that repository to someone and you don't have access to a repository to push to, or simply don't want to set one up, you can bundle it with `git bundle create`. +Eğer o repoyu birine göndermek istiyorsanız ama gönderilecek repoya erişiminiz yoksa veya hemen bir tane kurmak istemiyorsanız, `git bundle create` ile demetleyebilirsiniz. [source,console] ---- @@ -44,14 +44,14 @@ Writing objects: 100% (6/6), 441 bytes, done. Total 6 (delta 0), reused 0 (delta 0) ---- -Now you have a file named `repo.bundle` that has all the data needed to re-create the repository's `master` branch. -With the `bundle` command you need to list out every reference or specific range of commits that you want to be included. -If you intend for this to be cloned somewhere else, you should add HEAD as a reference as well as we've done here. +Artık, repoyu yeniden oluşturmak için gereken tüm verilere sahip `repo.bundle` adında bir dosyanız var. +`bundle` komutu ile dahil edilmesini istediğiniz her referansı veya belirli bir değişiklik aralığını belirtmeniz gerekir. +Eğer bunu başka bir yere kopyalamak niyetindeyseniz, burada yaptığımız gibi HEAD'i de bir referans olarak eklemelisiniz. -You can email this `repo.bundle` file to someone else, or put it on a USB drive and walk it over. +Bu `repo.bundle` dosyasını başka birine e-posta ile gönderebilir veya USB sürücüsüne koyarak ulaştırabilirsiniz. -On the other side, say you are sent this `repo.bundle` file and want to work on the project. -You can clone from the binary file into a directory, much like you would from a URL. +Bunun yanında, diyelim ki bu `repo.bundle` dosyası size gönderildi ve projede çalışmak istiyorsunuz. +Bu ikilik dosyayı, sanki URL'den klonlama yapar gibi, bir dizine kopyalayabilirsiniz. [source,console] ---- @@ -64,9 +64,9 @@ $ git log --oneline b1ec324 first commit ---- -If you don't include HEAD in the references, you have to also specify `-b master` or whatever branch is included because otherwise it won't know what branch to check out. +Eğer referanslara HEAD'i dahil etmezseniz, -hangi dala geçileceğini bilemeyeceği için- `-b master` veya içerilen herhangi bir dalı belirtmeniz gerekir. -Now let's say you do three commits on it and want to send the new commits back via a bundle on a USB stick or email. +Şimdi diyelim ki üç adet değişiklik yaptınız ve bunları bir USB sürücüsü veya e-posta ile geri göndermek istiyorsunuz. [source,console] ---- @@ -78,14 +78,14 @@ c99cf5b fourth commit - second repo b1ec324 first commit ---- -First we need to determine the range of commits we want to include in the bundle. -Unlike the network protocols which figure out the minimum set of data to transfer over the network for us, we'll have to figure this out manually. - Now, you could just do the same thing and bundle the entire repository, which will work, but it's better to just bundle up the difference - just the three commits we just made locally. +Öncelikle, demete dahil etmek istediğimiz değişiklik aralığını belirlememiz gerekiyor. +Ağ üzerinde aktarılacak minimum veri kümesini otomatik olarak belirleyen ağ protokollerinin aksine, bunu manuel olarak kendimiz belirlememiz gerekecek. +Şimdi, doğrudan tüm repoyu demetlemek işe yarayacak olsa da lokal olarak yaptığımız üç değişikliği içeren farkı demetlemek daha iyidir. -In order to do that, you'll have to calculate the difference. -As we described in <>, you can specify a range of commits in a number of ways. -To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`. -You can test that with the `log` command. +Bunu yapabilmek için farkı hesaplamanız gerekecek. +<> bölümünde açıkladığımız gibi, bir dizi değişiklik aralığını belirtmek için birkaç yol vardır. +Başta kopyaladığımız dalda bulunmayıp, artık master dalımızda olan üç değişikliği almak için `origin/master..master` veya `master ^origin/master` gibi bir şey kullanabilirsiniz. +Bu işlemi `log` komutuyla test edebilirsiniz. [source,console] ---- @@ -95,8 +95,8 @@ c99cf5b fourth commit - second repo 7011d3d third commit - second repo ---- -So now that we have the list of commits we want to include in the bundle, let's bundle them up. -We do that with the `git bundle create` command, giving it a filename we want our bundle to be and the range of commits we want to go into it. +Şimdi demete dahil etmek istediğimiz değişikliklerin listesine sahip olduğumuza göre, onları demetleyelim. +Bunu, git bundle create` komutunu kullanarak yaparız; bunu yaparken demetimizin dosya adını ve eklemek istediğimiz katkıların aralığını veririz. [source,console] ---- @@ -108,11 +108,11 @@ Writing objects: 100% (9/9), 775 bytes, done. Total 9 (delta 0), reused 0 (delta 0) ---- -Now we have a `commits.bundle` file in our directory. -If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime. +Şimdi dizinimizde bir `commits.bundle` dosyasına sahibiz. +Bu dosyayı alıp arkadaşımıza gönderirsek, geçen zaman zarfında dosya üzerinde daha fazla çalışma yapılmış olsa bile, bunu orijinal repoya aktarabilir. -When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository. -The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the necessary ancestors to reconstitute it properly. +Arkadaşımız bu demeti aldığında, onu reposuna aktarmadan önce içerdiğini görmek için inceleyebilir. +İlk komut, dosyanın gerçekten geçerli bir Git demeti olduğundan ve bunu doğru şekilde yeniden oluşturmak için gerekli tüm eklere sahip olduğunuzdan emin olmak için `bundle verify` komutudur. [source,console] ---- @@ -124,8 +124,8 @@ The bundle requires these 1 ref ../commits.bundle is okay ---- -If the bundler had created a bundle of just the last two commits they had done, rather than all three, the original repository would not be able to import it, since it is missing requisite history. -The `verify` command would have looked like this instead: +Eğer demetleyici, tüm üç değişiklik yerine, yalnızca yaptıkları son iki değişikliğin bir demetini oluşturmuş olsaydı, gerekli tarihlerden biri eksik olacağı için, orijinal repo bunu alamazdı. +`verify` komutu ise şu şekilde görünecekti: [source,console] ---- @@ -134,8 +134,8 @@ error: Repository lacks these prerequisite commits: error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 third commit - second repo ---- -However, our first bundle is valid, so we can fetch in commits from it. -If you want to see what branches are in the bundle that can be imported, there is also a command to just list the heads: +Ancak, ilk demetimiz geçerlidir, bu yüzden ondaki değişiklikleri çekebiliriz. +İçeri aktarılabilen demette hangi dalların olduğunu görmek isterseniz, yalnızca uçları (HEAD) listelemek için bir komutumuz da mevcuttur: [source,console] ---- @@ -143,9 +143,9 @@ $ git bundle list-heads ../commits.bundle 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master ---- -The `verify` sub-command will tell you the heads as well. -The point is to see what can be pulled in, so you can use the `fetch` or `pull` commands to import commits from this bundle. -Here we'll fetch the 'master' branch of the bundle to a branch named 'other-master' in our repository: +`verify` alt komutu aynı zamanda başlıkları da size söyleyecektir. +Amacımız içe aktarılabilenleri görmektir, haliyle bu demetten değişiklikleri almak için `fetch` veya `pull` komutlarını kullanabilirsiniz. +Şimdi demetin 'master' dalını, repomuzdaki 'other-master' adlı bir dala almak için `fetch` komutunu kullanıyoruz: [source,console] ---- @@ -154,7 +154,7 @@ From ../commits.bundle * [new branch] master -> other-master ---- -Now we can see that we have the imported commits on the 'other-master' branch as well as any commits we've done in the meantime in our own 'master' branch. +Şimdi, 'other-master' dalında alınan değişiklikleri, kendi 'master' dalımızda yaptığımız tüm değişikliklerle birlikte görebiliriz. [source,console] ---- @@ -168,4 +168,4 @@ $ git log --oneline --decorate --graph --all * b1ec324 first commit ---- -So, `git bundle` can be really useful for sharing or doing network-type operations when you don't have the proper network or shared repository to do so. +Gördüğünüz gibi, `git bundle` uygun ağa veya paylaşılan bir repoya sahip olmadığınızda paylaşım yapmak veya ağ benzeri işlemler gerçekleştirmek için gerçekten yararlı olabilir. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 7ff7826a..df5e8ae4 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -1,49 +1,50 @@ [[_credential_caching]] -=== Credential Storage +=== Kimlik Bilgisi Depolama (((credentials))) (((git commands, credential))) -If you use the SSH transport for connecting to remotes, it's possible for you to have a key without a passphrase, which allows you to securely transfer data without typing in your username and password. -However, this isn't possible with the HTTP protocols – every connection needs a username and password. -This gets even harder for systems with two-factor authentication, where the token you use for a password is randomly generated and unpronounceable. - -Fortunately, Git has a credentials system that can help with this. -Git has a few options provided in the box: - -* The default is not to cache at all. - Every connection will prompt you for your username and password. -* The ``cache'' mode keeps credentials in memory for a certain period of time. - None of the passwords are ever stored on disk, and they are purged from the cache after 15 minutes. -* The ``store'' mode saves the credentials to a plain-text file on disk, and they never expire. - This means that until you change your password for the Git host, you won't ever have to type in your credentials again. - The downside of this approach is that your passwords are stored in cleartext in a plain file in your home directory. -* If you're using a Mac, Git comes with an ``osxkeychain'' mode, which caches credentials in the secure keychain that's attached to your system account. - This method stores the credentials on disk, and they never expire, but they're encrypted with the same system that stores HTTPS certificates and Safari auto-fills. -* If you're using Windows, you can install a helper called ``Git Credential Manager for Windows.'' - This is similar to the ``osxkeychain'' helper described above, but uses the Windows Credential Store to control sensitive information. - It can be found at https://github.com/Microsoft/Git-Credential-Manager-for-Windows[]. - -You can choose one of these methods by setting a Git configuration value: +Eğer uzak sunuculara bağlanmak için SSH taşıyıcısını kullanıyorsanız, şifresiz bir anahtarınız olabilir ve bu da kullanıcı adı ve şifrenizi yazmadan veri aktarmanıza olanak sağlar. +Ancak, HTTP protokolleri için bu mümkün değildir; her bağlantıda bir kullanıcı adı ve şifre gereklidir. +Bu durum, iki faktörlü kimlik doğrulama sistemlerinde daha da zorlaşır, çünkü şifreniz için kullandığınız belirteç rastgele oluşturulmuştur ve okunması zor olabilir. + +Neyse ki, Git'in bu konuda yardımcı olabilecek bir kimlik bilgisi sistemi vardır. +Git'in heybesinde sakladığı bazı seçenekler şunlardır: + +* Varsayılan olarak hiçbir şey önbelleğe alınmaz. + Her bağlantı, kullanıcı adınızı ve şifrenizi girmenizi isteyecektir. +* ``cache`` (Önbellek) modu, belirli bir süre boyunca kimlik bilgilerini bellekte tutar. + Hiçbir şifre hiçbir zaman diskte saklanmaz ve bunlar 15 dakika sonra önbellekten silinir. +* ``store`` (Depolama) modu, kimlik bilgilerini düz metin dosyası halinde diskte kaydeder ve bunlar hiçbir zaman zamanaşımına uğramaz. + Bu, git hesabınız için şifrenizi değiştirene kadar kimlik bilgilerinizi bir daha asla girmeniz gerekmeyeceği anlamına gelir. + Bu yaklaşımın dezavantajı, şifrelerinizin açık metin olarak home dizininizde düz bir dosyada saklanmasıdır. +* Bir Mac kullanıyorsanız, Git ``osxkeychain`` moduyla gelir; bu da kimlik bilgilerini sisteminize bağlı güvenli anahtar zincirinde önbelleğe alır. + Bu yöntem, kimlik bilgilerini diske kaydeder ve bunların süresi hiçbir zaman dolmaz, ancak bunlar HTTPS sertifikalarını ve Safari otomatik doldurmalarını saklayan aynı sistemle şifrelenir. +* Bir Windows kullanıyorsanız, ``Git Credential Manager for Windows`` adlı bir yardımcı programı yükleyebilirsiniz. + Bu, yukarıda açıklanan ``osxkeychain`` yardımcı programına benzer, ancak hassas bilgileri kontrol etmek için Windows Kimlik Bilgisi Deposunu kullanır. + Onu şu adresten bulabilirsiniz: https://github.com/Microsoft/Git-Credential-Manager-for-Windows[]. + +Bu yöntemlerden birini, bir Git yapılandırma değeri belirleyerek seçebilirsiniz: [source,console] ---- $ git config --global credential.helper cache ---- -Some of these helpers have options. -The ``store'' helper can take a `--file ` argument, which customizes where the plain-text file is saved (the default is `~/.git-credentials`). -The ``cache'' helper accepts the `--timeout ` option, which changes the amount of time its daemon is kept running (the default is ``900'', or 15 minutes). -Here's an example of how you'd configure the ``store'' helper with a custom file name: +Bazı yardımcı programların çeşitli seçenekleri vardır. +``store`` yardımcısı, `--file ` argümanını alabilir, bu da düz metin dosyasının nerede kaydedileceğini özelleştirir (varsayılan `~/.git-credentials` dizinidir). +``cache`` yardımcısı, daemon işlemin ne kadar süreyle tutulacağını değiştiren `--timeout ` seçeneğini kabul eder (varsayılan ``900 saniye``, veya 15 dakikadır). +İşte ``store`` yardımcısını özel bir dosya adıyla nasıl yapılandıracağınıza dair bir örnek: [source,console] ---- $ git config --global credential.helper 'store --file ~/.my-credentials' ---- -Git even allows you to configure several helpers. -When looking for credentials for a particular host, Git will query them in order, and stop after the first answer is provided. -When saving credentials, Git will send the username and password to *all* of the helpers in the list, and they can choose what to do with them. -Here's what a `.gitconfig` would look like if you had a credentials file on a thumb drive, but wanted to use the in-memory cache to save some typing if the drive isn't plugged in: +Git, birkaç yardımcıyı yapılandırmanıza bile izin verir. +Belirli bir sunucu için kimlik bilgilerini ararken, Git bunları sırayla sorgular ve bir kez cevap verildikten sonra durur. +Kimlik bilgilerini kaydederken, Git kullanıcı adını ve şifreyi liste içindeki *tüm* yardımcılara gönderir ve onlar bunlarla ne yapacaklarına karar verebilirler. + +Eğer taşınabilir sürücünüzde bir kimlik bilgileri dosyanız varsa, ancak sürücü takılı değilken bazı yazma işlemlerini kaydetmek için bellek içindeki önbelleği kullanmak istiyorsanız, `.gitconfig` şu şekilde görünecektir: [source,ini] ---- @@ -52,14 +53,14 @@ Here's what a `.gitconfig` would look like if you had a credentials file on a th helper = cache --timeout 30000 ---- -==== Under the Hood +==== Şapkanın Altı -How does this all work? -Git's root command for the credential-helper system is `git credential`, which takes a command as an argument, and then more input through stdin. +Peki tüm bunlar nasıl çalışıyor? +Git'in kimlik bilgisi yardımcı sistemine yönelik kök komutu `git credential` 'dır. Bir komutu argüman olarak ve daha sonra daha fazla veri girişini `stdin` üzerinden alır. -This might be easier to understand with an example. -Let's say that a credential helper has been configured, and the helper has stored credentials for `mygithost`. -Here's a session that uses the ``fill'' command, which is invoked when Git is trying to find credentials for a host: +Bir örnek ile bunu anlamak daha kolay olacaktır. +Diyelim ki yapılandırılmış bir kimlik bilgisi yardımcısı, `mygithost` için kimlik bilgilerini saklamış olsun. +İşte, Git'in bir sunucu için kimlik bilgilerini bulmaya çalışırken çağrılan ``fill`` komutunu kullanan bir oturum: [source,console] ---- @@ -83,39 +84,39 @@ username=bob password=s3cre7 ---- -<1> This is the command line that initiates the interaction. -<2> Git-credential is then waiting for input on stdin. - We provide it with the things we know: the protocol and hostname. -<3> A blank line indicates that the input is complete, and the credential system should answer with what it knows. -<4> Git-credential then takes over, and writes to stdout with the bits of information it found. -<5> If credentials are not found, Git asks the user for the username and password, and provides them back to the invoking stdout (here they're attached to the same console). +<1> Bu etkileşimi başlatan komut satırıdır. +<2> Ardından, Git-credential stdin üzerinden giriş bekler. + Bildiklerimizi giriyoruz: protokol ve sunucu adı. +<3> Boş bir satır, girişin tamamlandığını ve kimlik bilgisi sisteminin ne bildiğini yanıtlaması gerektiğini gösterir. +<4> Daha sonra, Git-credential işi devralır ve bulduğu bilgileri stdout ile yazar. +<5> Kimlik bilgileri bulunamazsa; Git kullanıcıya kullanıcı adını ve şifreyi sorup, bunları başlatan stdout'a sağlar (burada aynı konsola bağlanmışlardır). -The credential system is actually invoking a program that's separate from Git itself; which one and how depends on the `credential.helper` configuration value. -There are several forms it can take: +Kimlik bilgisi sistemi aslında Git'ten ayrı bir programı çağırır. Hangi programın çağrıldığı ve nasıl olduğu, `credential.helper` yapılandırma değerine bağlıdır. +Bu, birkaç farklı biçimde olabilir: [options="header"] |====== -| Configuration Value | Behavior -| `foo` | Runs `git-credential-foo` -| `foo -a --opt=bcd` | Runs `git-credential-foo -a --opt=bcd` -| `/absolute/path/foo -xyz` | Runs `/absolute/path/foo -xyz` -| `!f() { echo "password=s3cre7"; }; f` | Code after `!` evaluated in shell +| Yapılandırma Değeri | Davranış +| `foo` | `git-credential-foo` çalışır +| `foo -a --opt=bcd` | `git-credential-foo -a --opt=bcd` çalışır +| `/absolute/path/foo -xyz` | `/absolute/path/foo -xyz` çalışır +| `!f() { echo "password=s3cre7"; }; f` | `!` sonrasındaki kod kabukta (shell) değerlendirilir |====== -So the helpers described above are actually named `git-credential-cache`, `git-credential-store`, and so on, and we can configure them to take command-line arguments. -The general form for this is ``git-credential-foo [args] .'' -The stdin/stdout protocol is the same as git-credential, but they use a slightly different set of actions: +Yukarıda tanımlanan yardımcılar aslında `git-credential-cache`, `git-credential-store`, vb. şeklinde adlandırılmıştır ve onları komut satırı argümanları alacak şekilde yapılandırabiliriz. +Bunun genel formu ``git-credential-foo [args] .`` şeklindedir. +Stdin/stdout protokolü git-credential ile aynıdır, ancak biraz farklı bir eylem kümesi kullanırlar: -* `get` is a request for a username/password pair. -* `store` is a request to save a set of credentials in this helper's memory. -* `erase` purge the credentials for the given properties from this helper's memory. +- `get`: Kullanıcı adı/şifre isteği. +- `store`: Bu yardımcının belleğine, bir kimlik bilgisi kümesini kaydetme isteği. +- `erase`: Belirtilen özelliklere sahip kimlik bilgilerini, bu yardımcının belleğinden silme işlemi. -For the `store` and `erase` actions, no response is required (Git ignores it anyway). -For the `get` action, however, Git is very interested in what the helper has to say. -If the helper doesn't know anything useful, it can simply exit with no output, but if it does know, it should augment the provided information with the information it has stored. -The output is treated like a series of assignment statements; anything provided will replace what Git already knows. +`store` ve `erase` eylemleri için yanıt gerekli değildir (zaten Git tarafından görmezden gelinir). +Ancak Git, `get` eylemi için yardımcının ne söylediğini çok önemser. +Yardımcı işe yarar bir şey bilmiyorsa, herhangi bir çıktı olmadan doğrudan çıkış yapabilir; ancak biliyorsa, sağlanan bilgiyi depoladığı bilgilerle genişletmesi gerekir. +Çıktı, bir dizi atama ifadesi gibi işlenir; sağlanan her bir şey, Git'in zaten bildiği şeyi değiştirecektir. -Here's the same example from above, but skipping git-credential and going straight for git-credential-store: +İşte yukarıdaki örneğin, git-credential'ı atlayarak doğrudan git-credential-store'a geçen bir şekli: [source,console] ---- @@ -132,49 +133,54 @@ username=bob <3> password=s3cre7 ---- -<1> Here we tell `git-credential-store` to save some credentials: the username ``bob'' and the password ``s3cre7'' are to be used when `https://mygithost` is accessed. -<2> Now we'll retrieve those credentials. - We provide the parts of the connection we already know (`https://mygithost`), and an empty line. -<3> `git-credential-store` replies with the username and password we stored above. +<1> Burada `git-credential-store` 'a bazı kimlik bilgilerini kaydetmesini söylüyoruz: `https://mygithost` erişildiğinde kullanıcı adı olarak ``bob`` ve şifre olarak ``s3cre7`` kullanılacaktır. +<2> Şimdi bu kimlik bilgilerini alacağız. + Zaten bildiğimiz bağlantının parçalarını sağlıyoruz (`https://mygithost`) ve bir boş satır ekliyoruz. +<3> `git-credential-store`, yukarıda sakladığımız kullanıcı adı ve şifre ile yanıt verir. -Here's what the `~/git.store` file looks like: +İşte `~/git.store` dosyasının içeriği: [source,ini] ---- https://bob:s3cre7@mygithost ---- -It's just a series of lines, each of which contains a credential-decorated URL. -The `osxkeychain` and `wincred` helpers use the native format of their backing stores, while `cache` uses its own in-memory format (which no other process can read). +Bu sadece kimlik bilgisiyle bezenmiş URL'lerini içeren bir dizi satırdır. +`osxkeychain` ve `wincred` yardımcıları, destek depolarının doğal formatını kullanırken, `cache` kendi bellek içi formatını kullanır (ki bu diğer hiçbir süreç tarafından okunamaz). ==== A Custom Credential Cache -Given that `git-credential-store` and friends are separate programs from Git, it's not much of a leap to realize that _any_ program can be a Git credential helper. -The helpers provided by Git cover many common use cases, but not all. -For example, let's say your team has some credentials that are shared with the entire team, perhaps for deployment. -These are stored in a shared directory, but you don't want to copy them to your own credential store, because they change often. -None of the existing helpers cover this case; let's see what it would take to write our own. -There are several key features this program needs to have: +`git-credential-store` ve benzerleri, Git'ten bağımsız ayrı programlardır, bu nedenle _herhangi bir_ programın bir Git kimlik bilgisi yardımcısı olabileceğini anlamak pek de zor değildir. +Git'in sağladığı yardımcılar birçok yaygın kullanım durumunu kapsar, ancak hepsini değil. +Örneğin, diyelim ki ekibinizin, belki de dağıtım için, tüm ekiple paylaşılan bazı kimlik bilgileri var. +Bu kimlik bilgileri, paylaşılan bir dizinde saklanır, ancak sık sık değiştiği için bunları kendi kimlik bilgisi deposuna kopyalamak istemezsiniz. +Mevcut yardımcıların hiçbiri bu durumu kapsamaz. Şimdi kendimiz bir tane yazmak istersek ne gerektiğini görelim. +Bu programın sahip olması gereken birkaç temel özellik bulunmaktadır: -. The only action we need to pay attention to is `get`; `store` and `erase` are write operations, so we'll just exit cleanly when they're received. -. The file format of the shared-credential file is the same as that used by `git-credential-store`. -. The location of that file is fairly standard, but we should allow the user to pass a custom path just in case. +. Dikkat etmemiz gereken tek işlem `get` işlemidir: `store` ve `erase` yazma işlemleri olduğu için, bunları aldığımızda sadece temiz bir şekilde çıkış yaparız. +. Paylaşılan kimlik bilgisi dosyasının dosya biçimi, `git-credential-store` tarafından kullanılan dosya biçimi ile aynıdır. +. Dosyanın yeri oldukça standarttır, ancak her ihtimale karşı kullanıcının özel bir dizin geçmesine izin vermeliyiz. -Once again, we'll write this extension in Ruby, but any language will work so long as Git can execute the finished product. -Here's the full source code of our new credential helper: +Bu uzantıyı yine Ruby'de yazacağız, ancak Git, bitmiş kodu çalıştırabileceği sürece herhangi bir dil de işe yarayacaktır. +İşte yeni kimlik bilgisi yardımcımızın tam kaynak kodu: [source,ruby] -------- include::../git-credential-read-only[] -------- -<1> Here we parse the command-line options, allowing the user to specify the input file. - The default is `~/.git-credentials`. -<2> This program only responds if the action is `get` and the backing-store file exists. -<3> This loop reads from stdin until the first blank line is reached. - The inputs are stored in the `known` hash for later reference. -<4> This loop reads the contents of the storage file, looking for matches. - If the protocol and host from `known` match this line, the program prints the results to stdout and exits. +<1> Burada komut satırı seçeneklerini ayrıştırıyoruz ve kullanıcının giriş dosyasını belirtmesine izin veriyoruz. + Varsayılan `~/.git-credentials`'dır. +<2> Bu program, sadece eylem `get` ise ve destek dosyası mevcutsa yanıt verir. +<3> Bu döngü, ilk boş satıra ulaşılıncaya kadar stdin'den okur. + Girişler daha sonra başvurmak üzere `known` hash'inde saklanır. +<4> Bu döngü, depolama dosyasının içeriğini okur ve eşleşmeleri arar. + `known`'dan gelen protokol ve sunucu bu satırla eşleşiyorsa, program sonuçları stdout'a yazdırır ve çıkar. + +Yardımcımızı `git-credential-read-only` olarak kaydedeceğiz, bunu `PATH` içinde bir yere koyacağız ve çalıştırılabilir olarak işaretleyeceğiz. +İşte etkileşimli bir oturumun nasıl göründüğü: + + We'll save our helper as `git-credential-read-only`, put it somewhere in our `PATH` and mark it executable. Here's what an interactive session looks like: @@ -191,11 +197,11 @@ username=bob password=s3cre7 ---- -Since its name starts with ``git-'', we can use the simple syntax for the configuration value: +Adı "git-" ile başladığından, yapılandırma değeri için basit sözdizimini kullanabiliriz: [source,console] ---- $ git config --global credential.helper 'read-only --file /mnt/shared/creds' ---- -As you can see, extending this system is pretty straightforward, and can solve some common problems for you and your team. +Gördüğünüz gibi, bu sistemi genişletmek oldukça basit ve sizin ve ekibinizin bazı yaygın sorunlarını çözebilir. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 95cf842a..35600506 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -1,19 +1,21 @@ [[_replace]] -=== Replace +=== Git Nesnesini Değiştirme -As we've emphasized before, the objects in Git's object database are unchangeable, but Git does provide an interesting way to _pretend_ to replace objects in its database with other objects. +Daha önce vurguladığımız gibi, Git'in veritabanındaki nesneleri değişmezdir, ancak Git veritabanındaki nesneleri başka nesnelerle _değiştiriyormuş_ gibi yapmak için ilginç bir yol sunar. -The `replace` command lets you specify an object in Git and say "every time you refer to _this_ object, pretend it's a _different_ object". -This is most commonly useful for replacing one commit in your history with another one without having to rebuild the entire history with, say, `git filter-branch`. +`replace` komutu, Git'te bir nesneyi belirtmenize ve "_bu_ nesne her çağrıldığında, o _sanki_ farklı bir nesneymiş gibi davran" demenize izin verir. +Bu, özellikle tüm geçmişi yeniden oluşturmak zorunda kalmadan, geçmişinizdeki bir katkıyı başka bir katkı ile değiştirmeniz gerektiğinde (ör. `git filter-branch`) çok kullanışlıdır. -For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining. -You can graft one history onto the other by "replacing" the earliest commit in the new line with the latest commit on the older one. -This is nice because it means that you don't actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage affects the SHA-1s). +Örneğin, büyük bir kod geçmişiniz var ve bu geçmişi yeni geliştiriciler için kısa bir geçmiş ve veri madenciliğiyle ilgilenen kişiler için çok daha uzun ve büyük bir geçmişe bölmek istiyorsunuz. +Yeni tarih çizginizdeki en erken katkıyı, eski olanın en son katkısıyla "değiştirerek" bir geçmişi diğerine ekleyebilirsiniz. +Bu, genellikle onları birleştirmek için yapmanız gerektiği üzere (çünkü öncellik SHA-1'leri etkiler), yeni geçmişteki her katkıyı yeniden yazmanızı gerektirmeyeceği için güzel bir yöntemdir. -Let's try this out. -Let's take an existing repository, split it into two repositories, one recent and one historical, and then we'll see how we can recombine them without modifying the recent repositories SHA-1 values via `replace`. +Hadi bunu deneyelim. +Mevcut bir repoyu alalım, onu biri kısa ve yeni, diğeri ise daha uzun, köklü bir proje geçmişine sahip olan iki repoya bölelim. +Ve sonra bu geçmişleri `replace` kullanarak, yeni repoların SHA-1 değerlerini değiştirmeden nasıl birleştirebileceğimize bakalım. -We'll use a simple repository with five simple commits: + +Bunu beş katkısı olan basit bir repo üzerinde deneyelim: [source,console] ---- @@ -25,13 +27,13 @@ c6e1e95 fourth commit c1822cf first commit ---- -We want to break this up into two lines of history. -One line goes from commit one to commit four - that will be the historical one. -The second line will just be commits four and five - that will be the recent history. +Bu repoyu iki tarih çizgisine bölmek istiyoruz. +Bir çizgi, birinci katkıdan dördünca katkıya kadar gider (bu uzak geçmiş olacaktir). +İkinci çizgide sadece dört ve beş numaralı katkılar olacaktır (bu yakın geçmiş olacaktır). image::images/replace1.png[] -Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the master branch of a new remote repository. +Tarihi geçmişi oluşturmak kolaydır, geçmişe bir dal ekleyebilir ve sonra bu dalı yeni bir uzak repo'nun ana dalına (`master` dalına) itebiliriz. [source,console] ---- @@ -46,7 +48,7 @@ c1822cf first commit image::images/replace2.png[] -Now we can push the new `history` branch to the `master` branch of our new repository: +Şimdi, yeni `history` dalını yeni repomuzun `master` dalına itebiliriz: [source,console] ---- @@ -62,9 +64,9 @@ To git@github.com:schacon/project-history.git * [new branch] history -> master ---- -OK, so our history is published. -Now the harder part is truncating our recent history down so it's smaller. -We need an overlap so we can replace a commit in one with an equivalent commit in the other, so we're going to truncate this to just commits four and five (so commit four overlaps). +Artık, geçmişimiz yayınlandı. +Şimdi geriye işin daha zor olan kısmı, yani yakın tarihli geçmişimizi kırpmak kaldı. +Bir yerde örtüşme olması gerekiyor ki birindeki bir katkıyı, diğerindeki eşdeğer bir katkı ile değiştirebilelim. Bu yüzden bu geçmişi sadece dört ve beş numaralı katkılara indirgiyoruz (böylece dört numaralı katkı örtüşecektir). [source,console] ---- @@ -76,12 +78,12 @@ c6e1e95 (history) fourth commit c1822cf first commit ---- -It's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. -So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it. +Bu durumda, tarihçenin nasıl genişletileceği hakkında talimatları olan bir temel katkı oluşturmak faydalıdır. Böylece diğer geliştiriciler, kırpılmış geçmişin ilk katkısına ulaşırlar ve daha fazlasına ihtiyaç duyarlarsa ne yapacaklarını bilirler. +Bu yüzden yapacağımız şey, talimatlar içeren bir başlangıç katkısı oluşturmak ve sonra geriye kalan katkıları (dört ve beş) bunun üzerine yeniden düzenlemektir. -To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. -So, our base commit will be based off of that tree. -We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA-1 back. +Bunu yapmak için, bölme noktası olmak üzere bir nokta belirlememiz gerekiyor ki bu bizim için üçüncü katkı olacaktır: yani SHA dilinde `9c68fdc` dir. +Bu yüzden temel katkımız o ağaç üzerinde olacaktır. +Sadece bir ağaç alıp, bize öncelsiz ve yepyeni bir katkı nesnesi SHA-1'i veren `commit-tree` komutunu kullanarak, temel katkımızı oluşturabiliriz. [source,console] ---- @@ -91,16 +93,16 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree} [NOTE] ===== -The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands. -These are commands that are not generally meant to be used directly, but instead are used by *other* Git commands to do smaller jobs. -On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use. -You can read more about plumbing commands in <> +`commit-tree` komutu, genellikle 'plumbing' (tesisat) komutları olarak adlandırılan bir dizi komuttan biridir. +Bunlar, genellikle doğrudan kullanılmak için değil, daha küçük işleri yapmak için *diğer* Git komutları tarafından kullanılırlar. +Bu tür sıradışı durumlarda, günlük kullanımdan daha ziyade gerçekten düşük seviyeli şeyler yapmamıza izin verirler. +Tesisat komutları hakkında daha fazla bilgiyi <> bölümünde bulabilirsiniz. ===== image::images/replace3.png[] -OK, so now that we have a base commit, we can rebase the rest of our history on top of that with `git rebase --onto`. -The `--onto` argument will be the SHA-1 we just got back from `commit-tree` and the rebase point will be the third commit (the parent of the first commit we want to keep, `9c68fdc`): +Artık temel bir katkımız olduğuna göre, geriye kalan tarihçemizi bunun üzerine `git rebase --onto` komutu ile tekrar düzenleyebiliriz. +`--onto` argümanı, `commit-tree` ile aldığımız SHA-1; ve üçüncü katkımız (saklamak istediğimiz ilk katkının önceli olan, `9c68fdc`) geriye dönük temel noktamız olacaktır: [source,console] ---- @@ -112,11 +114,11 @@ Applying: fifth commit image::images/replace4.png[] -OK, so now we've re-written our recent history on top of a throw away base commit that now has instructions in it on how to reconstitute the entire history if we wanted to. -We can push that new history to a new project and now when people clone that repository, they will only see the most recent two commits and then a base commit with instructions. +Artık, yeniden oluşturulabilir bir tarihçe hakkında talimatlar içeren temel katkımızı işleyip, üzerine yakın geçmişimizi yeniden yazdık. +Eğer bu yeni geçmişi yeni bir projeye gönderirsek; artık insanlar o repoyu kopyaladıklarında, en son iki katkıyı ve sonra da talimatları içeren temel katkıyı göreceklerdir. -Let's now switch roles to someone cloning the project for the first time who wants the entire history. -To get the history data after cloning this truncated repository, one would have to add a second remote for the historical repository and fetch: +Şimdi rolleri değiştirerek, projeyi ilk kez kopyalayan ve tüm tarihçeyi isteyen birinin yerine geçelim. +Bu kırpılmış repoyu kopyaladıktan sonra tarihçeyi almak için, tarihi (uzak geçmişli) repomuz için ikinci bir uzak repo ekleyip, çekmemiz lazım: [source,console] ---- @@ -134,7 +136,7 @@ From https://github.com/schacon/project-history * [new branch] master -> project-history/master ---- -Now the collaborator would have their recent commits in the `master` branch and the historical commits in the `project-history/master` branch. +Şimdi çalışma arkadaşımızın en son katkıları `master` dalında ve tarihi (uzak geçmişli) katkıları `project-history/master` dalında olacaktır. [source,console] ---- @@ -150,15 +152,15 @@ c6e1e95 fourth commit c1822cf first commit ---- -To combine them, you can simply call `git replace` with the commit you want to replace and then the commit you want to replace it with. -So we want to replace the "fourth" commit in the master branch with the "fourth" commit in the `project-history/master` branch: +Onları birleştirmek için, sadece değiştirmek istediğiniz katkıyı ve yerine koymak istediğiniz katkıyı belirterek `git replace` komutunu çağırabilirsiniz. +Burada, `master` dalındaki "dördüncü" katkı, `project-history/master` dalındaki "dördüncü" kattı ile değiştirmek istiyoruz. [source,console] ---- $ git replace 81a708d c6e1e95 ---- -Now, if you look at the history of the `master` branch, it appears to look like this: +Şimdi, `master` dalının geçmişine baktığınızda, şöyle görünmektedir: [source,console] ---- @@ -170,12 +172,12 @@ e146b5f fifth commit c1822cf first commit ---- -Cool, right? Without having to change all the SHA-1s upstream, we were able to replace one commit in our history with an entirely different commit and all the normal tools (`bisect`, `blame`, etc) will work how we would expect them to. +Harika, değil mi? Üst akımdaki tüm SHA-1'leri değiştirmeden, geçmişimizdeki bir katkıyı tamamen farklı bir katkı ile değiştirebildik ve tüm normal araçlar (`bisect`, `blame`, vb.) onlardan beklediğimiz gibi çalışacaktır. image::images/replace5.png[] -Interestingly, it still shows `81a708d` as the SHA-1, even though it's actually using the `c6e1e95` commit data that we replaced it with. -Even if you run a command like `cat-file`, it will show you the replaced data: +İlginçtir ki, `81a708d` hala SHA-1 olarak görünüyor, ancak aslında onu değiştirdiğimiz `c6e1e95` katkısının verilerini kullanıyor. +`cat-file` gibi bir komutu çalıştırsanız bile, değiştirilmiş verileri görürsünüz: [source,console] ---- @@ -188,9 +190,9 @@ committer Scott Chacon 1268712581 -0700 fourth commit ---- -Remember that the actual parent of `81a708d` was our placeholder commit (`622e88e`), not `9c68fdce` as it states here. +Unutmayın ki, `81a708d` katkısının asıl önceli, burada belirtildiği gibi `9c68fdce` değil, yer tutucu katkınızdır (`622e88e`). -Another interesting thing is that this data is kept in our references: +Bir başka ilginç nokta da bu verilerin referanslarımızda tutulmasıdır: [source,console] ---- @@ -202,5 +204,5 @@ e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit refs/remotes/origin/master c6e1e95051d41771a649f3145423f8809d1a74d4 commit refs/replace/81a708dd0e167a3f691541c7a6463343bc457040 ---- -This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it. -This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why separate them?) but it can be useful in other circumstances. +Bu, değiştirdiğimiz veriyi başkalarıyla paylaşmanın kolay olduğu anlamına gelir. Çünkü bunu sunucumuza yükleyebiliriz ve diğerleri de kolayca indirebilir. +Burada ele aldığımız tarihçe aşılaması senaryosu (herkes zaten her iki tarihçeyi de indirebilecekse, onları niye ayırdık ki?) çok yardımcı olmasa da, diğer bazı durumlarda faydalı olabilir. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index b07e8bbe..c1b37951 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -61,7 +61,7 @@ a11bef0 first commit Genellikle, bir projenin içinde benzersiz olması için sekiz ila on karakter yeterlidir. Örneğin, - Şubat 2019 itibarıyla 875.000'den fazla katkı ve neredeyse yedi milyon nesne içeren - oldukça büyük bir proje olan Linux çekirdeğinde, SHA-1'leri ilk 12 karakteri aynı olan hiçbir nesne bulunmuyor. -[NOT] +[NOTE] .SHA-1 HAKKINDA KISA BİR NOT ==== @@ -172,7 +172,7 @@ Reflog bilgilerinin kesinlikle yerel olduğunu bilmelisinizi - yalnızca _sizin Referanslar, başkasının repo kopyasında aynı olmayacaktır; ayrıca bir repoyu başlangıçta klonladıktan hemen sonra, henüz repoda herhangi bir etkinlik olmadığından boş bir referans günlüğünüz olacaktır. `git show HEAD@{2.months.ago}` komutunu çalıştırmak; eğer projeyi en az iki ay önce kopyaladıysanız, yalnızca eşleşen katkıyı gösterecektir; eğer bundan daha yeni bir tarihte kopyaladıysanız, yalnızca ilk yerel katkınızı göreceksiniz. -[İPUCU] +[TIP] .Reflog'u Git'in kabuk (shell) geçmişi versiyonu olarak düşünebilirsiniz. ==== UNIX veya Linux geçmişiniz varsa, reflog'u Git'in kabuk geçmişinin versiyonu olarak düşünebilirsiniz. @@ -211,11 +211,11 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -[NOT] +[NOTE] .Windows'ta caret işaretinden kaçınmak ==== -Windows'ta `^` işareti `cmd.exe` için özel bir karakterdir ve farklı şekilde işlenmelidir. +Windows'ta `^` (caret) işareti `cmd.exe` için özel bir karakterdir ve farklı şekilde işlenmelidir. Ya iki katına çıkarabilir ya da katkı referansını tırnak içine alabilirsiniz: [source,console] diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 7b954ca9..a4de4cdb 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -8,7 +8,7 @@ Bu, katkıların sırasını, mesajlarını veya bir katkıdaki dosyaları deği Bu bölümde, bu görevleri nasıl gerçekleştireceğinizi göreceksiniz, böylece çalışmanızı diğerleriyle paylaşmadan önce katkı geçmişinizin istediğiniz gibi görünmesini sağlayabilirsiniz. -[NOT] +[NOTE] .Çalışmanız sizi tatmin edecek seviyeye gelene kadar itmeyin ==== Git'in temel kurallarından biri, kopyanız içindeki çoğu şeyin yerel olması nedeniyle, geçmişinizi _yerel olarak_ yeniden yazma özgürlüğünüzün olduğudur. @@ -37,7 +37,7 @@ Eğer son katkınızın _içeriğini_ değiştirmek istiyorsanız, işlem temel Bu teknikle dikkatli olmanız gerekmektedir çünkü `amend` komutu, katkının SHA-1 karmasını değiştirir. Bu, çok küçük boyutta bir yeniden temellemeye benzer - eğer çoktan uzak repoya ittiyseniz son katkınızı değiştirmeyin. -[İPUCU] +[TIP] .Düzeltme yapılan bir katkı, bir düzeltilmiş katkı mesajına ihtiyaç duyabilir (veya duymayabilir). ==== İşlenmiş bir katkıyı düzelttiğinizde, hem katkı mesajını hem de katkının içeriğini değiştirme fırsatınız vardır. @@ -169,7 +169,7 @@ Bu komut diğer iki katkıyı otomatik olarak uygulayacak ve işiniz bitmiş ola Eğer daha fazla satırda `pick` yerine `edit` yazdıysanız, her biri için bu adımları tekrarlayabilirsiniz. Her seferinde Git duracak, katkıyı düzeltmenize izin verecek ve işiniz bittiğinde devam edecektir. -==== RKatkıları sıralama +==== Katkıları sıralama Ayrıca, etkileşimli yeniden temellemeleri kullanarak katkıları yeniden sıralamak veya tamamen kaldırmak da mümkündür. Eğer `added cat-file` katkısını kaldırmak ve diğer iki katkının tanıtılma sırasını değiştirmek istiyorsanız, yeniden temelleme betiğini bundan: diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 5663132a..25b4baed 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -7,7 +7,7 @@ Bu sorunun çözümü, `git stash` komutundadır. `stash` komutu, çalışma dizininizin ham durumunu - yani, değiştirilmiş izlenen dosyalarınızı ve izlem değişikliklerinizi - alır ve bunu her zaman yeniden (hatta farklı bir dalda bile) uygulayabileceğiniz tamamlanmamış değişiklikler yığınına olarak kaydeder. -[NOT] +[NOTE] .`git stash push`'a geçiş ==== Ekim 2017'nin sonlarına doğru, Git posta listesinde `git stash save` komutunun kaldırılıp, alternatif olarak yerine zaten mevcut olan `git stash push` komutunun kullanılması üzerine kapsamlı bir tartışma yapılmıştır. @@ -287,7 +287,7 @@ What now> Bu şekilde her dosyayı tek tek inceleyebilir veya silme için desenler belirleyebilirsiniz. -[NOT] +[NOTE] ==== Bazı garip durumlarda, Git'ten çalışma dizininizi temizlemesini istemek için ekstra yetkili olmanız gerekebilir. Mesela alt modül olarak başka Git repolarını kopyaladığınız bir çalışma dizininin altındaysanız, `git clean -fd` komutu bile bu dizinleri silmeyi reddedecektir. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 400bbe4c..c40aef1b 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -1,29 +1,29 @@ [[_git_submodules]] -=== Submodules +=== Alt Modüller -It often happens that while working on one project, you need to use another project from within it. -Perhaps it's a library that a third party developed or that you're developing separately and using in multiple parent projects. -A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. +Bir projede çalışırken, sıklıkla onun içindeki başka bir projeyi kullanmanız gerekebilir. +Bu üçüncü tarafın geliştirdiği bir kütüphane veya ayrı olarak geliştirdiğiniz ve birden fazla ana projede kullandığınız bir kütüphane de olabilir. +Bu senaryolarda ortak bir sorun ortaya çıkar: İki projeyi ayrı olarak işlemek, ancak birini diğerinin içinden kullanabilmek istersiniz. -Here's an example. -Suppose you're developing a website and creating Atom feeds. -Instead of writing your own Atom-generating code, you decide to use a library. -You're likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. -The issue with including the library is that it's difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. -The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. +İşte bir örnek. +Bir web sitesi geliştirirken, Atom beslemesi oluşturuyorsunuz. +Atom oluşturmak üzere kendi kodunuzu yazmak yerine bir kütüphane kullanmaya karar veriyorsunuz. +Muhtemelen bu kodu ya bir CPAN yüklemesi veya Ruby gem gibi paylaşılan bir kütüphaneden dahil etmek ya da kaynak kodunu kendi proje ağacınıza kopyalamak zorunda kalacaksınız. +Kütüphaneyi dahil etmenin sorunu, kütüphaneyi herhangi bir şekilde özelleştirmenin zor olması ve her istemcinin o kütüphaneye erişimi olması gerektiği için, dağıtmanın genellikle daha da zor olmasıdır. +Kodunuzu kendi projenize kopyalamanın sorunu ise, yukarı akış (upstream) değişiklikleri mevcutsa, herhangi bir özel değişiklik yapmanın zorlaşmasıdır. -Git addresses this issue using submodules. -Submodules allow you to keep a Git repository as a subdirectory of another Git repository. -This lets you clone another repository into your project and keep your commits separate. +Git bu sorunu alt modüller kullanarak ele alır. +Alt modüller, bir Git reposunu başka bir Git reposunun bir alt dizini olarak tutmanıza izin verir. +Bu yöntem, diğer depoyu projenize kopyalayarak (git clone) ve katkılarınızı ayrı tutmanızı sağlar. [[_starting_submodules]] -==== Starting with Submodules +==== Alt Modüllere Giriş -We'll walk through developing a simple project that has been split up into a main project and a few sub-projects. +Bir ana proje ve birkaç alt proje olarak bölünmüş basit bir proje geliştirme örneği inceleyeceğiz. -Let's start by adding an existing Git repository as a submodule of the repository that we're working on. -To add a new submodule you use the `git submodule add` command with the absolute or relative URL of the project you would like to start tracking. -In this example, we'll add a library called ``DbConnector''. +Çalıştığımız repoya bir alt modül olarak varolan bir Git reposunu eklemeye başlayarak başlayalım. +Yeni bir alt modül eklemek için, `git submodule add` komutuna, izlemek istediğiniz projenin mutlak veya göreli URL'sini eklersiniz. +Bu örnekte, ``DbConnector`` adında bir kütüphane ekleyeceğiz. [source,console] ---- @@ -36,10 +36,10 @@ Unpacking objects: 100% (11/11), done. Checking connectivity... done. ---- -By default, submodules will add the subproject into a directory named the same as the repository, in this case ``DbConnector''. -You can add a different path at the end of the command if you want it to go elsewhere. +Alt modüller, projeyi varsayılan olarak ``DbConnector`` adında bir alt dizine ekler. +Başka bir yere gitmesini istiyorsanız komutun sonuna farklı bir yol ekleyebilirsiniz. -If you run `git status` at this point, you'll notice a few things. +Bu noktada `git status` komutunu çalıştırırsanız, birkaç şey fark edeceksiniz. [source,console] ---- @@ -54,8 +54,8 @@ Changes to be committed: new file: DbConnector ---- -First you should notice the new `.gitmodules` file. -This is a configuration file that stores the mapping between the project's URL and the local subdirectory you've pulled it into: +İlk olarak, yeni `.gitmodules` dosyasını fark etmişsinizdir. +Bu, projenin URL'si ile onu çektiğiniz yerel alt dizin arasındaki eşleştirmeyi saklayan bir yapılandırma dosyasıdır: [source,ini] ---- @@ -64,21 +64,20 @@ This is a configuration file that stores the mapping between the project's URL a url = https://github.com/chaconinc/DbConnector ---- -If you have multiple submodules, you'll have multiple entries in this file. -It's important to note that this file is version-controlled with your other files, like your `.gitignore` file. -It's pushed and pulled with the rest of your project. -This is how other people who clone this project know where to get the submodule projects from. +Eğer birden fazla alt modülünüz varsa, bu dosyada birden fazla girişiniz olacaktır. +Bu dosyanın, `.gitignore` dosyanız gibi diğer dosyalarınızla birlikte sürüm denetimi altında olduğunu belirtmek önemlidir. +Bu, bu projeyi kopyalayan diğer kişilerin alt modül projelerini nereden alacaklarını bildikleri anlamına gelir. [NOTE] ===== -Since the URL in the .gitmodules file is what other people will first try to clone/fetch from, make sure to use a URL that they can access if possible. -For example, if you use a different URL to push to than others would to pull from, use the one that others have access to. -You can overwrite this value locally with `git config submodule.DbConnector.url PRIVATE_URL` for your own use. -When applicable, a relative URL can be helpful. +Başkalarının ilk olarak kopyalamaya veya çekmeye çalışacakları yer `.gitmodules` dosyasındaki URL olduğu için, mümkünse onların erişebileceği bir URL kullanmaya özen gösterin. +Örneğin, başkalarının çekmek için kullandığından farklı bir URL'yi siz itmek için kullanıyorsanız, diğerlerinin de erişimine açık olanı kullanın. +Kendi kullanımınız için bu değeri yerel olarak değiştirmek isterseniz, `git config submodule.DbConnector.url PRIVATE_URL` komutu ile varolan değerin üzerine yazabilirsiniz. +Mümkünse, göreli bir URL kullanmak da faydalı olabilir. ===== -The other listing in the `git status` output is the project folder entry. -If you run `git diff` on that, you see something interesting: +`git status` çıktısındaki diğer bilgi, proje klasörü girişidir. +Bunu üzerinde `git diff` komutunu çalıştırırsanız, ilginç bir şey göreceksiniz: [source,console] ---- @@ -92,10 +91,10 @@ index 0000000..c3f01dc +Subproject commit c3f01dc8862123d317dd46284b05b6892c7b29bc ---- -Although `DbConnector` is a subdirectory in your working directory, Git sees it as a submodule and doesn't track its contents when you're not in that directory. -Instead, Git sees it as a particular commit from that repository. +`DbConnector`, çalışma dizininizde bir alt dizin olsa dahi, Git onu bir alt modül olarak görür ve siz o dizinde olmadığınızda içeriğini izlemez. +Git bunun yerine onu, o repodan belirli bir katkı olarak görür. -If you want a little nicer diff output, you can pass the `--submodule` option to `git diff`. +Daha düzgün bir diff çıktısı istiyorsanız, `git diff` komutuna `--submodule` seçeneğini ekleyebilirsiniz. [source,console] ---- @@ -112,7 +111,7 @@ index 0000000..71fc376 Submodule DbConnector 0000000...c3f01dc (new submodule) ---- -When you commit, you see something like this: +Eğer katkılarsanız, şöyle bir şey göreceksiniz: [source,console] ---- @@ -123,10 +122,10 @@ $ git commit -am 'added DbConnector module' create mode 160000 DbConnector ---- -Notice the `160000` mode for the `DbConnector` entry. -That is a special mode in Git that basically means you're recording a commit as a directory entry rather than a subdirectory or a file. +`DbConnector` girişinin `160000` moduna dikkat edin. +Bu, Git'te bir dizin girişini, bir alt dizin veya bir dosya olarak kaydetmek yerine bir katkı olarak kaydettiğiniz anlamına gelen özel bir moddur. -Lastly, push these changes: +Son olarak, bu değişiklikleri itin: [source,console] ---- @@ -134,10 +133,10 @@ $ git push origin master ---- [[_cloning_submodules]] -==== Cloning a Project with Submodules +==== Alt Modülleri Olan Bir Projeyi Kopyalama -Here we'll clone a project with a submodule in it. -When you clone such a project, by default you get the directories that contain submodules, but none of the files within them yet: +İşte bir alt modül içeren bir projeyi kopyalayacağız. +Böyle bir projeyi kopyaladığınızda, varsayılan olarak alt modülleri içeren dizinleri alırsınız, ancak henüz içlerindeki dosyaları almazsınız: [source,console] ---- @@ -165,8 +164,8 @@ $ ls $ ---- -The `DbConnector` directory is there, but empty. -You must run two commands: `git submodule init` to initialize your local configuration file, and `git submodule update` to fetch all the data from that project and check out the appropriate commit listed in your superproject: +`DbConnector` dizini vardır, ancak içi boştur. +İki komut çalıştırmanız gerekiyor: Yerel yapılandırma dosyanızı başlatmak için `git submodule init` ve o projeden tüm verileri almak ve süperprojenizde listelenen uygun katkıları kontrol etmek için `git submodule update`: [source,console] ---- @@ -182,10 +181,9 @@ Checking connectivity... done. Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc' ---- -Now your `DbConnector` subdirectory is at the exact state it was in when you committed earlier. - -There is another way to do this which is a little simpler, however. -If you pass `--recurse-submodules` to the `git clone` command, it will automatically initialize and update each submodule in the repository. +Şimdi `DbConnector` alt diziniz, daha önce katkıladığınız durumda. +Ancak, biraz daha basit olan bir yol daha var. +`git clone` komutuna `--recurse-submodules` bayrağını geçirirseniz, repodaki her alt modülü otomatik olarak başlatır ve güncellersiniz. [source,console] ---- @@ -206,16 +204,16 @@ Checking connectivity... done. Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc' ---- -==== Working on a Project with Submodules +==== Alt Modülleri Olan Projelerle Çalışmak -Now we have a copy of a project with submodules in it and will collaborate with our teammates on both the main project and the submodule project. +Şimdi alt modülleri olan bir projenin bir kopyasına sahibiz ve ana projede ve alt modül projede ekibimizle işbirliği yapacağız. -===== Pulling in Upstream Changes +===== Üst-akım Değişikliklerini Çekmek -The simplest model of using submodules in a project would be if you were simply consuming a subproject and wanted to get updates from it from time to time but were not actually modifying anything in your checkout. -Let's walk through a simple example there. +Eğer yalnızca bir alt projeyi tüketiyorsanız ve zaman zaman ondan güncellemeler almak istiyorsanız, ancak gerçekte kopyanızda hiçbir şeyi değiştirmiyorsanız; alt modülleri bir projede kullanmanın en basit modelini uygulayabilirsiniz. +Bir örnek ile üzerinden basitçe geçelim. -If you want to check for new work in a submodule, you can go into the directory and run `git fetch` and `git merge` the upstream branch to update the local code. +Eğer bir alt modüldeki yeni çalışmayı kontrol etmek istiyorsanız, dizine gidip yerel kodu güncellemek için `git fetch` ve `git merge` komutlarını kullanabilirsiniz. [source,console] ---- @@ -230,8 +228,8 @@ Fast-forward 2 files changed, 2 insertions(+) ---- -Now if you go back into the main project and run `git diff --submodule` you can see that the submodule was updated and get a list of commits that were added to it. -If you don't want to type `--submodule` every time you run `git diff`, you can set it as the default format by setting the `diff.submodule` config value to ``log''. +Şimdi ana projeye geri döner ve `git diff --submodule` komutunu çalıştırırsanız, alt modülün güncellendiğini ve ona eklenen katkıların bir listesini görebilirsiniz. +`git diff` komutunu her çalıştırdığınızda `--submodule` yazmak istemiyorsanız, `diff.submodule` yapılandırma değerini ``log`` olarak değiştirerek bu formatı varsayılan olarak ayarlayabilirsiniz. [source,console] ---- @@ -242,10 +240,10 @@ Submodule DbConnector c3f01dc..d0354fc: > better connection routine ---- -If you commit at this point then you will lock the submodule into having the new code when other people update. +Bu noktada bir katkı işlerseniz, başkaları güncellediğinde alt modülü yeni koda kilitlenmiş olursunuz. -There is an easier way to do this as well, if you prefer to not manually fetch and merge in the subdirectory. -If you run `git submodule update --remote`, Git will go into your submodules and fetch and update for you. +Alt dizinde manuel olarak çekme ve birleştirme yapmak istemiyorsanız, bunu yapmanın daha kolay bir yolu daha vardır. +`git submodule update --remote` komutunu çalıştırırsanız, Git sizin için alt modüllere çekip, güncelleyecektir. [source,console] ---- @@ -259,10 +257,10 @@ From https://github.com/chaconinc/DbConnector Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0644' ---- -This command will by default assume that you want to update the checkout to the `master` branch of the submodule repository. -You can, however, set this to something different if you want. -For example, if you want to have the DbConnector submodule track that repository's ``stable'' branch, you can set it in either your `.gitmodules` file (so everyone else also tracks it), or just in your local `.git/config` file. -Let's set it in the `.gitmodules` file: +Bu komut, varsayılan olarak alt modül reposunun `master` dalını izlemek istediğinizi varsayar. +Ancak dilerseniz, bunu farklı bir şeye de ayarlayabilirsiniz. +Örneğin, DbConnector alt modülünün o reposunun ``stable`` dalını izlemesini istiyorsanız, bunu ya `.gitmodules` dosyanızda (böylece diğer herkes de izleyebilir) ya da sadece yerel `.git/config` dosyanızda ayarlayabilirsiniz. +Şimdi bunu `.gitmodules` dosyasına ayarlayalım: [source,console] ---- @@ -278,9 +276,9 @@ From https://github.com/chaconinc/DbConnector Submodule path 'DbConnector': checked out 'c87d55d4c6d4b05ee34fbc8cb6f7bf4585ae6687' ---- -If you leave off the `-f .gitmodules` it will only make the change for you, but it probably makes more sense to track that information with the repository so everyone else does as well. +`-f .gitmodules` seçeneğini kullanmazsanız, sadece sizin için değişiklik yapar, ancak muhtemelen bu bilgiyi herkesin takip etmesi daha mantıklı olacaktır. -When we run `git status` at this point, Git will show us that we have ``new commits'' on the submodule. +Bu noktada `git status` komutunu çalıştırdığınızda, Git alt modülde "yeni katkılar" olduğunu gösterecektir. [source,console] ---- @@ -298,7 +296,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -If you set the configuration setting `status.submodulesummary`, Git will also show you a short summary of changes to your submodules: +`status.submodulesummary` yapılandırmasını ayarlarsanız, Git ayrıca alt modüllerinizdeki değişikliklerin kısa bir özetini de gösterecektir: [source,console] ---- @@ -321,7 +319,7 @@ Submodules changed but not updated: > catch non-null terminated lines ---- -At this point if you run `git diff` we can see both that we have modified our `.gitmodules` file and also that there are a number of commits that we've pulled down and are ready to commit to our submodule project. +Bu noktada `git diff` komutunu çalıştırırsanız, hem `.gitmodules` dosyasını değiştirdiğimizi hem de indirdiğimiz bir dizi katkının alt modül projemize işlenmeye hazır olduğunu görebilirsiniz. [source,console] ---- @@ -342,8 +340,8 @@ index 6fc0b3d..fd1cc29 100644 > better connection routine ---- -This is pretty cool as we can actually see the log of commits that we're about to commit to in our submodule. -Once committed, you can see this information after the fact as well when you run `git log -p`. +Alt modülümüze işleyebileceğimiz katkıların günlüğünü görebilmemiz harika. +Bir kez katkılandıktan sonra, `git log -p` komutunu çalıştırdığınızda, sonradan bu bilgiyi de görebilirsiniz. [source,console] ---- @@ -370,26 +368,26 @@ Submodule DbConnector c3f01dc..c87d55d: > better connection routine ---- -Git will by default try to update *all* of your submodules when you run `git submodule update --remote` so if you have a lot of them, you may want to pass the name of just the submodule you want to try to update. +`git submodule update --remote` komutunu çalıştırdığınızda Git, (varsayılan olarak) *tüm* alt modüllerinizi güncellemeye çalışacaktır, bu yüzden birçok alt modülünüz varsa, sadece güncellemek istediğiniz alt modülün adını geçirmek isteyebilirsiniz. -===== Working on a Submodule +===== Bir Alt Modülle Çalışmak -It's quite likely that if you're using submodules, you're doing so because you really want to work on the code in the submodule at the same time as you're working on the code in the main project (or across several submodules). -Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems). +Alt modüller kullanıyorsanız bunun sebebi muhtemelen, ana projedeki kodla aynı anda alt modüldeki (veya birkaç alt modüldeki) kod üzerinde de çalışmak istemenizdir. +Aksi takdirde, muhtemelen daha basit bir bağımlılık yönetim sistemi kullanıyor olurdunuz (örneğin Maven veya Rubygems gibi). -So now let's go through an example of making changes to the submodule at the same time as the main project and committing and publishing those changes at the same time. +Şimdi, ana projede olduğu gibi alt modülde değişiklik yapma ve bu değişiklikleri aynı anda katkılama ve yayınlama örneğini inceleyelim. -So far, when we've run the `git submodule update` command to fetch changes from the submodule repositories, Git would get the changes and update the files in the subdirectory but will leave the sub-repository in what's called a ``detached HEAD'' state. -This means that there is no local working branch (like ``master'', for example) tracking changes. -With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. -You have to do some extra steps if you want changes in a submodule to be tracked. +Şimdiye kadar öğrendiğimiz üzere, alt modül repolarından değişiklikleri almak için `git submodule update` komutunu çalıştırdığımızda; Git değişiklikleri alır ve alt dizindeki dosyaları günceller ancak alt repoyu ``detached HEAD`` (bağlı olmayan bir HEAD) durumunda bırakır. +Bu, yerel çalışma dalının (örneğin ``master`` gibi) değişiklikleri izlemediği anlamına gelir. +Değişiklikleri izleyen bir çalışma dalı olmadığı için, alt modülde değişiklik yaparsanız bile, bu değişikliklerin bir sonraki `git submodule update` komutunu çalıştırdığınızda kaybolma olasılığı oldukça yüksektir. +Bir alt modüldeki değişikliklerin izlenmesini istiyorsanız atmanız gereken ekstra adımlar bulunmaktadır. -In order to set up your submodule to be easier to go in and hack on, you need to do two things. -You need to go into each submodule and check out a branch to work on. -Then you need to tell Git what to do if you have made changes and then `git submodule update --remote` pulls in new work from upstream. -The options are that you can merge them into your local work, or you can try to rebase your local work on top of the new changes. +Alt modülünüzü daha kolay bir şekilde düzenlemek için iki şey yapmanız gerekiyor. +Her alt modüle gitmeli ve üzerinde çalışmak için bir dal açmalısınız. +Sonra, eğer değişiklik yapmışsanız ve ardından `git submodule update --remote` ile yeni çalışmaları üst akımdan çekiyorsanız, Git'e ne yapması gerektiğini söylemelisiniz. +Seçenekler, yeni değişiklikleri yerel işinize birleştirmek veya yerel işinizi yeni değişikliklerin üstüne tekrar temellemeyi denemektir. -First of all, let's go into our submodule directory and check out a branch. +İlk olarak, alt modül dizinine giderek bir dala geçelim. [source,console] ---- @@ -397,9 +395,9 @@ $ git checkout stable Switched to branch 'stable' ---- -Let's try it with the ``merge'' option. -To specify it manually, we can just add the `--merge` option to our `update` call. -Here we'll see that there was a change on the server for this submodule and it gets merged in. +Bunu ``merge`` seçeneğiyle deneyelim. +Manuel olarak belirtmek için, `update` çağrımıza `--merge` seçeneğini ekleyebiliriz. +İşte bu alt modül için sunucuda bir değişiklik olduğunu göreceğiz ve bu değişiklik birleştirilir. [source,console] ---- @@ -417,8 +415,8 @@ Fast-forward Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5ea' ---- -If we go into the DbConnector directory, we have the new changes already merged into our local `stable` branch. -Now let's see what happens when we make our own local change to the library and someone else pushes another change upstream at the same time. +DbConnector dizinine girdiğimizde, yeni değişikliklerin zaten yerel `stable` dalımıza birleştirildiğini göreceğiz. +Şimdi kütüphanede kendi yerel değişikliğimizi yapalım ve aynı zamanda başka birinin üst akıma başka bir değişiklik gönderdiğinde ne olacağını görelim. [source,console] ---- @@ -429,7 +427,7 @@ $ git commit -am 'unicode support' 1 file changed, 1 insertion(+) ---- -Now if we update our submodule we can see what happens when we have made a local change and upstream also has a change we need to incorporate. +Şimdi alt modülümüzü güncellediğimizde, yerel bir değişiklik yaptığımız ve üst akımın da dahil edilmesi gereken bir değişikliğe sahip olduğumuzda ne olacağını görelim. [source,console] ---- @@ -439,7 +437,7 @@ Applying: unicode support Submodule path 'DbConnector': rebased into '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94' ---- -If you forget the `--rebase` or `--merge`, Git will just update the submodule to whatever is on the server and reset your project to a detached HEAD state. +Eğer `--rebase` veya `--merge` seçeneklerini unutursanız, Git sadece alt modülü sunucuda bulunan herhangi bir duruma günceller ve projenizi bağlı bir HEAD durumuna (detached HEAD) sıfırlar. [source,console] ---- @@ -447,9 +445,9 @@ $ git submodule update --remote Submodule path 'DbConnector': checked out '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94' ---- -If this happens, don't worry, you can simply go back into the directory and check out your branch again (which will still contain your work) and merge or rebase `origin/stable` (or whatever remote branch you want) manually. +Eğer böyle bir durumla karşılaşırsanız endişelenmeyin, sadece dizininize geri dönüp dalınıza tekrar geçebilirsiniz (ki bu hala çalışmanızı içerecektir) ve `origin/stable` (veya istediğiniz uzak dal) dalı manuel olarak birleştirebilir veya tekrar temelleyebilirsiniz. -If you haven't committed your changes in your submodule and you run a submodule update that would cause issues, Git will fetch the changes but not overwrite unsaved work in your submodule directory. +Alt modüldeki değişikliklerinizi katkılamadıysanız ve bir alt modül güncellemesi çalıştırdığınızda sorunlara neden olabilecek değişiklikleri yapmadıysanız, Git değişiklikleri alır ancak alt modül dizininizde kaydedilmemiş çalışmanın üzerine yeniden yazmaz. [source,console] ---- @@ -467,7 +465,7 @@ Aborting Unable to checkout 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector' ---- -If you made changes that conflict with something changed upstream, Git will let you know when you run the update. +Eğer üst akımda yapılan bir değişiklikle çakışan değişiklikler yaptıysanız, güncelleme işlemini çalıştırdığınızda Git bunu size bildirecektir. [source,console] ---- @@ -479,13 +477,13 @@ Automatic merge failed; fix conflicts and then commit the result. Unable to merge 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector' ---- -You can go into the submodule directory and fix the conflict just as you normally would. +Alt modül dizinine gidip çakışmayı normal şekilde düzeltebilirsiniz. [[_publishing_submodules]] -===== Publishing Submodule Changes +===== Alt Modül Değişikliklerini Yayınlama -Now we have some changes in our submodule directory. -Some of these were brought in from upstream by our updates and others were made locally and aren't available to anyone else yet as we haven't pushed them yet. +Şimdi alt modül dizinimizde bazı değişikliklerimiz var. +Bu değişikliklerden bazıları güncellemelerimizle üst akımdan getirildi, diğerleri ise yerel olarak yapıldı ama henüz itmediğimiz için başkaları tarafından erişilebilir durumda değil. [source,console] ---- @@ -498,12 +496,12 @@ Submodule DbConnector c87d55d..82d2ad3: > add new option for conn pooling ---- -If we commit in the main project and push it up without pushing the submodule changes up as well, other people who try to check out our changes are going to be in trouble since they will have no way to get the submodule changes that are depended on. -Those changes will only exist on our local copy. +Ana projeyi katkılayıp ittiğimizde ve alt modül değişikliklerini itmediğimizde; bağımlı olunan alt modül değişikliklerini almanın bir yolu olmayacağı için değişikliklerimizi çekmek isteyenler sıkıntı yaşayacaklar. +Bu değişiklikler yalnızca bizim yerel kopyamızda var olacaktır. -In order to make sure this doesn't happen, you can ask Git to check that all your submodules have been pushed properly before pushing the main project. -The `git push` command takes the `--recurse-submodules` argument which can be set to either ``check'' or ``on-demand''. -The ``check'' option will make `push` simply fail if any of the committed submodule changes haven't been pushed. +Bunu önlemek için, ana projeyi itmeden önce, tüm alt modüllerinizin düzgün bir şekilde itildiğinden emin olmak için Git'ten istekte bulunabilirsiniz. +`git push` komutu ``check`` ya da ``on-demand`` olarak ayarlanabilecek olan `--recurse-submodules` argümanını alır. +``check`` seçeneği, katkılanmış alt modül değişikliklerinden herhangi biri henüz itilmediyse `push` komutunu geçersiz kılar. [source,console] ---- @@ -523,11 +521,11 @@ or cd to the path and use to push them to a remote. ---- -As you can see, it also gives us some helpful advice on what we might want to do next. -The simple option is to go into each submodule and manually push to the remotes to make sure they're externally available and then try this push again. -If you want the check behavior to happen for all pushes, you can make this behavior the default by doing `git config push.recurseSubmodules check`. +Gördüğünüz gibi, bize ne yapmamız gerektiği konusunda bazı yardımcı önerilerde bulunulmaktadır. +En basit seçenek, her alt modüle gidip manuel olarak uzak sunuculara itmek ve sonra ana itme işlemini tekrar denemektir. +Eğer bu denetleme davranışının tüm itmeler için gerçekleşmesini istiyorsanız, bu davranışı varsayılan olarak yapmak için `git config push.recurseSubmodules check` komutunu kullanabilirsiniz. -The other option is to use the ``on-demand'' value, which will try to do this for you. +Diğer seçenek, bunu sizin için bunu yapmaya çalışacak olan ``on-demand`` değerini kullanmaktır. [source,console] ---- @@ -549,19 +547,19 @@ To https://github.com/chaconinc/MainProject 3d6d338..9a377d1 master -> master ---- -As you can see there, Git went into the DbConnector module and pushed it before pushing the main project. -If that submodule push fails for some reason, the main project push will also fail. -You can make this behavior the default by doing `git config push.recurseSubmodules on-demand`. +Görüldüğü gibi, Git DbConnector modülüne girdi ve ana projeyi itmeden önce bu alt modülü itti. +Eğer bu itme bir nedenle başarısız olursa, ana proje itmesi de başarısız olacaktır. +Bu davranışı varsayılan olarak ayarlamak için `git config push.recurseSubmodules on-demand` komutunu kullanabilirsiniz. -===== Merging Submodule Changes +===== Alt Modül Değişikliklerini Birleştirme -If you change a submodule reference at the same time as someone else, you may run into some problems. -That is, if the submodule histories have diverged and are committed to diverging branches in a superproject, it may take a bit of work for you to fix. +Eğer bir başkasıyla aynı anda bir alt modül referansını değiştirirseniz, bazı sorunlarla karşılaşabilirsiniz. +Yani, alt modül geçmişleri ayrışmış ve üstproje içinde ayrık (divergent) dallara katkı işlenmişse, bunu düzeltmeniz gerekebilir. -If one of the commits is a direct ancestor of the other (a fast-forward merge), then Git will simply choose the latter for the merge, so that works fine. +Eğer katkılardan biri diğerinin doğrudan önceliyse (bir hızlı ileri birleştirme), Git sadece birleştirme için sonuncuyu seçecektir, bu yüzden bu sorunsuz çalışır. -Git will not attempt even a trivial merge for you, however. -If the submodule commits diverge and need to be merged, you will get something that looks like this: +Ancak Git sizin için basit birleştirmeyi bile denemez. +Eğer alt modül katkıları ayrıksa ve birleştirilmeleri gerekiyorsa, şuna benzer bir uyarı alırsınız: [source,console] ---- @@ -579,13 +577,12 @@ CONFLICT (submodule): Merge conflict in DbConnector Automatic merge failed; fix conflicts and then commit the result. ---- -So basically what has happened here is that Git has figured out that the two branches record points in the submodule's history that are divergent and need to be merged. -It explains it as ``merge following commits not found'', which is confusing but we'll explain why that is in a bit. +Temelde burada olan olay şudur: Git, alt modülün geçmişinde ayrık ve birleştirilmesi gereken noktaları kaydeden iki dal olduğunu anlamıştır. +Bu, "merge following commits not found" olarak açıklanmıştır, bu kafa karıştırıcıdır ancak birazdan neden böyle olduğunu açıklayacağız. -To solve the problem, you need to figure out what state the submodule should be in. -Strangely, Git doesn't really give you much information to help out here, not even the SHA-1s of the commits of both sides of the history. -Fortunately, it's simple to figure out. -If you run `git diff` you can get the SHA-1s of the commits recorded in both branches you were trying to merge. +Sorunu çözmek için, alt modülün hangi durumda olması gerektiğini belirlemeniz gerekmektedir. +Garip bir şekilde, Git size burada yardımcı olacak pek fazla bilgi vermez, hatta tarihin her iki tarafında katkıların SHA-1'lerini bile vermez. +Neyse ki, bunu bulmak oldukça basittir. `git diff` komutunu çalıştırırsanız, birleştirmeye çalıştığınız iki dalda kaydedilen katkıların SHA-1'lerini alabilirsiniz. [source,console] ---- @@ -596,16 +593,16 @@ index eb41d76,c771610..0000000 +++ b/DbConnector ---- -So, in this case, `eb41d76` is the commit in our submodule that *we* had and `c771610` is the commit that upstream had. -If we go into our submodule directory, it should already be on `eb41d76` as the merge would not have touched it. -If for whatever reason it's not, you can simply create and checkout a branch pointing to it. +Bu durumda, `eb41d76` alt modüldeki *bizim* katkımızı ve `c771610`'ı yukarı akımın katkısını temsil etmektedir. +Alt modül dizinimize gittiğimizde, birleştirme ona dokunmadığı için, `eb41d76` üzerinde olması gerekir. +Herhangi bir nedenden dolayı değilse bile, ona işaret eden bir dal oluşturabilirsiniz. -What is important is the SHA-1 of the commit from the other side. -This is what you'll have to merge in and resolve. -You can either just try the merge with the SHA-1 directly, or you can create a branch for it and then try to merge that in. -We would suggest the latter, even if only to make a nicer merge commit message. +Önemli olan, diğer taraftan gelen katkının SHA-1'idir. +Çözmeniz ve birleştirmeniz gereken budur. +Doğrudan SHA-1 ile birleştirmeyi deneyebilirsiniz, veya onun için bir dal oluşturabilir ve ardından bunu birleştirmeyi deneyebilirsiniz. +En azından daha güzel bir birleştirme katkı mesajı oluşturmak için, biz ikincisini öneriyoruz. -So, we will go into our submodule directory, create a branch based on that second SHA-1 from `git diff` and manually merge. +Bu nedenle, alt modül dizinimize gireceğiz, `git diff` ile alınan ikinci SHA-1'e dayalı bir dal oluşturacağız ve manuel olarak birleştireceğiz. [source,console] ---- @@ -622,7 +619,7 @@ Recorded preimage for 'src/main.c' Automatic merge failed; fix conflicts and then commit the result. ---- -We got an actual merge conflict here, so if we resolve that and commit it, then we can simply update the main project with the result. +Burada gerçek bir birleştirme çakışması yaşadık, bu yüzden bunu çözer ve katkılarsak, bu sonuçla ana projeyi güncelleyebiliriz. [source,console] ---- @@ -648,22 +645,22 @@ $ git commit -m "Merge Tom's Changes" <5> [master 10d2c60] Merge Tom's Changes ---- -<1> First we resolve the conflict -<2> Then we go back to the main project directory -<3> We can check the SHA-1s again -<4> Resolve the conflicted submodule entry -<5> Commit our merge +<1> İlk olarak çakışmayı çöz +<2> TArdından ana proje dizinine geri dön +<3> SHA-1'leri tekrar kontrol edebiliriz +<4> Çakışmış alt modül girişini çöz +<5> Birleştirmeyi katkı olarak işle -It can be a bit confusing, but it's really not very hard. +Bu biraz kafa karıştırıcı olabilir, ancak gerçekten çok zor değil. -Interestingly, there is another case that Git handles. -If a merge commit exists in the submodule directory that contains *both* commits in its history, Git will suggest it to you as a possible solution. -It sees that at some point in the submodule project, someone merged branches containing these two commits, so maybe you'll want that one. +İlginç bir şekilde, Git'in ele aldığı başka bir durum daha var. +Eğer alt modül dizininde hem geçmişteki *her iki* katkıyı da içeren birleştirme katkısı varsa, Git size bunu olası bir çözüm olarak önerir. +Alt modül projesinde, bu iki katkıyı içeren dalların birleştirildiği bir nokta olduğunu görür, bu yüzden belki de bunu isteyebileceğinizi düşünür. -This is why the error message from before was ``merge following commits not found'', because it could not do *this*. -It's confusing because who would expect it to *try* to do this? +Bu yüzden önceki hata mesajının nedeni "merge following commits not found" idi, çünkü *bunu* yapamadı. +Karışık görünmesinin sebebi kimsenin bunu denemesini beklememesidir. -If it does find a single acceptable merge commit, you'll see something like this: +Eğer Git tek bir kabul edilebilir birleştirme katkısı bulursa, şuna benzer bir şey göreceksiniz: [source,console] ---- @@ -682,9 +679,9 @@ CONFLICT (submodule): Merge conflict in DbConnector Automatic merge failed; fix conflicts and then commit the result. ---- -The suggested command Git is providing will update the index as though you had run `git add` (which clears the conflict), then commit. -You probably shouldn't do this though. -You can just as easily go into the submodule directory, see what the difference is, fast-forward to this commit, test it properly, and then commit it. +Verilen komut, izlemi `git add` komutunu çalıştırmış gibi günceller (çakışmayı temizler) ve ardından katkıyı işler. +Aslında bunu yapmanız pek önerilmez. +Bunun yerine, alt modül dizinine girip farkın ne olduğunu görebilir, bu katkıya hızlı bir ileri sarma yapabilir, uygun şekilde test edebilir ve ardından katkınızı işleyebilirsiniz. [source,console] ---- @@ -698,19 +695,19 @@ $ git add DbConnector $ git commit -am 'Fast forwarded to a common submodule child' ---- -This accomplishes the same thing, but at least this way you can verify that it works and you have the code in your submodule directory when you're done. +Bu da aynı şeyi yapar, ama en azından bu şekilde düzgün çalışıp çalışmadığını doğrulayabilir ve işiniz bittiğinde kodun alt modül dizinizde olduğunu görebilirsiniz. -==== Submodule Tips +==== Alt Modül İpuçları -There are a few things you can do to make working with submodules a little easier. +Alt modüllerle çalışmayı biraz daha kolaylaştırmak için yapabileceğiniz birkaç şey var. -===== Submodule Foreach +===== Alt Modül "Foreach" Komutu -There is a `foreach` submodule command to run some arbitrary command in each submodule. -This can be really helpful if you have a number of submodules in the same project. +Her bir alt modülde belirli bir komut çalıştırmak için `foreach` alt modül komutu bulunmaktadır. +Aynı projede birkaç alt modülünüz varsa, bu gerçekten yardımcı olabilir. -For example, let's say we want to start a new feature or do a bugfix and we have work going on in several submodules. -We can easily stash all the work in all our submodules. +Örneğin, yeni bir özellik başlatmak veya bir hata düzeltmek istediğimizi ve birkaç alt modülde çalışmamız olduğunu varsayalım. +Tüm alt modüllerimizdeki çalışmamızı kolayca saklayabiliriz. [source,console] ---- @@ -722,7 +719,7 @@ Saved working directory and index state WIP on stable: 82d2ad3 Merge from origin HEAD is now at 82d2ad3 Merge from origin/stable ---- -Then we can create a new branch and switch to it in all our submodules. +Daha sonra tüm alt modüllerimizde yeni bir dal oluşturabilir ve ona geçebiliriz. [source,console] ---- @@ -733,8 +730,8 @@ Entering 'DbConnector' Switched to a new branch 'featureA' ---- -You get the idea. -One really useful thing you can do is produce a nice unified diff of what is changed in your main project and all your subprojects as well. +Fikri anladınız. +Yapabileceğiniz en faydalı şey, ana projenizde neyin değiştiğini ve tüm yan projelerinizde neyin değiştiğini gösteren güzel bir birleşik diff oluşturmaktır. [source,console] ---- @@ -772,13 +769,13 @@ index 1aaefb6..5297645 100644 struct strbuf out = STRBUF_INIT; ---- -Here we can see that we're defining a function in a submodule and calling it in the main project. -This is obviously a simplified example, but hopefully it gives you an idea of how this may be useful. +Burada, bir alt modülde bir fonksiyon tanımlıyoruz ve ana projede onu çağırıyoruz. +Bu açıkça basitleştirilmiş bir örnek, ancak umarım bunun nasıl faydalı olabileceğine dair bir fikir verir. -===== Useful Aliases +===== Faydalı Kısaltmalar (Alias) -You may want to set up some aliases for some of these commands as they can be quite long and you can't set configuration options for most of them to make them defaults. -We covered setting up Git aliases in <>, but here is an example of what you may want to set up if you plan on working with submodules in Git a lot. +Bazıları oldukça uzun olan bu komutlar için bazı kısaltmalar oluşturmak isteyebilirsiniz ancak bunları varsayılan yapmak isterseniz, çoğu yapılandırma seçeneğini değiştiremezsiniz. +Git'te kısaltmalar kurmayı <> bölümünde ele almıştık, ancak alt modüllerle sıkça çalışmayı planlıyorsanızx kurmak isteyebileceğiniz bir örnek aşağıda verilmiştir. [source,console] ---- @@ -787,14 +784,14 @@ $ git config alias.spush 'push --recurse-submodules=on-demand' $ git config alias.supdate 'submodule update --remote --merge' ---- -This way you can simply run `git supdate` when you want to update your submodules, or `git spush` to push with submodule dependency checking. +Bu şekilde alt modüllerinizi güncellemek istediğinizde sadece `git supdate` komutunu çalıştırabilir veya alt modül bağımlılığı kontrolü ile itmek için `git spush` komutunu kullanabilirsiniz. -==== Issues with Submodules +==== Alt Modüllerle İlgili Sorunlar -Using submodules isn't without hiccups, however. +Ancak alt modüllerle çalışmak tamamen sorunsuz değildir. -For instance switching branches with submodules in them can also be tricky. -If you create a new branch, add a submodule there, and then switch back to a branch without that submodule, you still have the submodule directory as an untracked directory: +Örneğin, alt modül içeren dallarda çalışırken dal değiştirmek karmaşık olabilir. +Eğer yeni bir dal oluşturup, oraya bir alt modül eklerseniz ve daha sonra o alt modülü içermeyen başka bir dala geçerseniz; alt modül dizinini halen izlenmeyen bir dizin olarak görürsününüz: [source,console] ---- @@ -827,8 +824,8 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -Removing the directory isn't difficult, but it can be a bit confusing to have that in there. -If you do remove it and then switch back to the branch that has that submodule, you will need to run `submodule update --init` to repopulate it. +Dizini kaldırmak zor değildir, ancak orada bulundurmak biraz kafa karıştırıcı olabilir. +Eğer kaldırırsanız ve daha sonra o alt modülü içeren dala geri geçerseniz, yeniden oluşturmak için `submodule update --init` komutunu çalıştırmanız gerekecektir. [source,console] ---- @@ -847,12 +844,12 @@ $ ls CryptoLibrary/ Makefile includes scripts src ---- -Again, not really very difficult, but it can be a little confusing. +Tekrardan: gerçekten çok zor değil, ancak biraz kafa karıştırıcı olabilir. -The other main caveat that many people run into involves switching from subdirectories to submodules. -If you've been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. -Assume that you have files in a subdirectory of your project, and you want to switch it to a submodule. -If you delete the subdirectory and then run `submodule add`, Git yells at you: +Birçok insanın karşılaştığı diğer ana husus, alt dizinlerden alt modüllere geçiş yapmaktır. +Eğer projenizdeki dosyaları izliyor ve onları bir alt modüle taşımak istiyorsanız, dikkatli olmanız gerekir; yoksa Git size kızabilir. +Diyelim ki projedeki bir alt dizinde dosyalarınız var ve onu bir alt modüle geçirmek istiyorsunuz. +Eğer alt dizini sildikten sonra `submodule add` komutunu çalıştırırsanız, Git size bağırmaya başlayacaktır: [source,console] ---- @@ -861,8 +858,8 @@ $ git submodule add https://github.com/chaconinc/CryptoLibrary 'CryptoLibrary' already exists in the index ---- -You have to unstage the `CryptoLibrary` directory first. -Then you can add the submodule: +Önce `CryptoLibrary` dizinini izlemden (stage) çıkarmalısınız. +Sonra alt modülü ekleyebilirsiniz: [source,console] ---- @@ -876,8 +873,8 @@ Unpacking objects: 100% (11/11), done. Checking connectivity... done. ---- -Now suppose you did that in a branch. -If you try to switch back to a branch where those files are still in the actual tree rather than a submodule – you get this error: +Şimdi bunu bir dalda yaptığınızı varsayalım. +Eğer bu dosyalar bir alt modül yerine hâlâ gerçek bir ağaçta duruyorsa, o dala geri geçmeye çalıştığınızda, şu hatayı alırsınız: [source,console] ---- @@ -890,7 +887,7 @@ Please move or remove them before you can switch branches. Aborting ---- -You can force it to switch with `checkout -f`, but be careful that you don't have unsaved changes in there as they could be overwritten with that command. +Geçişe zorlamak için `checkout -f` deneyebilirsiniz, ancak bu komutla kaydedilmemiş değişikliklerinizin üzerine yazılabileceğinden dikkatli olun! [source,console] ---- @@ -899,10 +896,11 @@ warning: unable to rmdir CryptoLibrary: Directory not empty Switched to branch 'master' ---- -Then, when you switch back, you get an empty `CryptoLibrary` directory for some reason and `git submodule update` may not fix it either. -You may need to go into your submodule directory and run a `git checkout .` to get all your files back. -You could run this in a `submodule foreach` script to run it for multiple submodules. +Ardından, geri geçtiğinizde, nedeni bilinmeyen bir şekilde boş bir `CryptoLibrary` dizini alırsınız ve `git submodule update` de bunu düzeltemeyebilir. +Tüm dosyalarınızı geri almak için submodule dizinine girip `git checkout .` komutunu çalıştırmanız gerekebilir. +Bu komutu birden fazla alt modül için çalıştırmak için `submodule foreach` bektiğinde çalıştırabilirsiniz. -It's important to note that submodules these days keep all their Git data in the top project's `.git` directory, so unlike much older versions of Git, destroying a submodule directory won't lose any commits or branches that you had. +Bugünlerde alt modüllerin tüm Git verilerini üst projenin `.git` dizininde tuttuğunu unutmayın. +Bu nedenle çok eski Git sürümlerinden farklı olarak, bir alt modül dizinini yok etmek, önceden sahip olduğunuz herhangi bir katkı veya dalı kaybetmez. -With these tools, submodules can be a fairly simple and effective method for developing on several related but still separate projects simultaneously. +Bu araçlarla sayesinde alt modüller, birbiriyle ilişkili ancak ayrı projede bulunan geliştirmeleri aynı anda yapabilmek için oldukça basit ve etkili bir yöntem olabilir. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index b6556985..504c6eb2 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -1,13 +1,13 @@ [[_subtree_merge]] -===== Subtree Merging +===== Alt Ağaç Birleştirme -The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one. -When you specify a subtree merge, Git is often smart enough to figure out that one is a subtree of the other and merge appropriately. +Alt ağaç birleştirme fikri, iki projeniz olduğunda, bu projelerden birinin diğerinin alt dizinine eşlendiği anlamına gelir. +Bir alt ağaç birleştirmesi belirttiğinizde, Git genellikle birinin diğerinin bir alt ağacı olduğunu ve uygun şekilde birleştirmesi gerektiğini anlayacak kadar akıllıdır. -We'll go through an example of adding a separate project into an existing project and then merging the code of the second into a subdirectory of the first. +Bu bölümde, mevcut bir projeye ayrı bir proje eklemeyi ve ardından ikincisinin kodunu birincisinin bir alt dizinine birleştirmeyi inceleyeceğiz. -First, we'll add the Rack application to our project. -We'll add the Rack project as a remote reference in our own project and then check it out into its own branch: +İlk olarak, Rack uygulamasını projemize ekleyeceğiz. +Rack projesini kendi projemize bir uzak referans olarak ekleyeceğiz ve sonra onun kendi dalına geçeceğiz: [source,console] ---- @@ -29,8 +29,8 @@ Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master Switched to a new branch "rack_branch" ---- -Now we have the root of the Rack project in our `rack_branch` branch and our own project in the `master` branch. -If you check out one and then the other, you can see that they have different project roots: +Şimdi `master` dalında kendi projemize ve `rack_branch` dalında Rack projesinin köküne sahibiz. +Önce birini, sonra diğerini kontrol ederseniz, farklı proje köklerine sahip olduklarını görebilirsiniz: [source,console] ---- @@ -43,23 +43,23 @@ $ ls README ---- -This is sort of a strange concept. -Not all the branches in your repository actually have to be branches of the same project. -It's not common, because it's rarely helpful, but it's fairly easy to have branches contain completely different histories. +Bu konsept biraz garip gelebilir. +Bir repodaki tüm dalların aslında aynı projenin dalları olması gerekmez. +Nadiren faydalı olduğu için bu pek yaygın değildir, ancak dalların tamamen farklı tarihçeler içermesini sağlamak aslında kolaydır. -In this case, we want to pull the Rack project into our `master` project as a subdirectory. -We can do that in Git with `git read-tree`. -You'll learn more about `read-tree` and its friends in <>, but for now know that it reads the root tree of one branch into your current staging area and working directory. -We just switched back to your `master` branch, and we pull the `rack_branch` branch into the `rack` subdirectory of our `master` branch of our main project: +Burada, Rack projesini `master` projemize bir alt dizin olarak eklemek istiyoruz. +Bunu `git read-tree` komutuyla yapabiliriz. +`read-tree` ve arkadaşları hakkında daha fazla bilgiyi <> bölümünde öğreneceksiniz; ancak şimdilik, bir dalın kök ağacını mevcut izlem alanınıza ve çalışma dizinize okuduğunu bilmeniz yeterlidir. +Şimdi `master` dalınıza geri döndük ve ana projemizin `master` dalına `rack_branch` dalını `rack` alt dizinine çekiyoruz: [source,console] ---- $ git read-tree --prefix=rack/ -u rack_branch ---- -When we commit, it looks like we have all the Rack files under that subdirectory – as though we copied them in from a tarball. -What gets interesting is that we can fairly easily merge changes from one of the branches to the other. -So, if the Rack project updates, we can pull in upstream changes by switching to that branch and pulling: +Katkıyı işledikten sonra, tüm Rack dosyalarının o alt dizin altında olduğu görünür (sanki onları bir sıkıştırılmış dosyadan kopyalamışız gibi). +İlginç olan, bir dalın değişikliklerini bir diğerine oldukça kolay bir şekilde birleştirebilme yeteneğidir. +Yani, Rack projesi güncellendiğinde, o dala geçip değişiklikleri alabiliriz: [source,console] ---- @@ -67,9 +67,8 @@ $ git checkout rack_branch $ git pull ---- -Then, we can merge those changes back into our `master` branch. -To pull in the changes and prepopulate the commit message, use the `--squash` option, as well as the recursive merge strategy's `-Xsubtree` option. -(The recursive strategy is the default here, but we include it for clarity.) +Ardından, bu değişiklikleri kendi `master` dalımıza birleştirebiliriz. +Değişiklikleri almak ve katkı mesajını önceden yenilemek için `--squash` seçeneğini, ayrıca özyinelemeli birleştirme stratejisinin `-Xsubtree` seçeneğini kullanın. (Özyinelemeli strateji burada varsayılan olduğundan, netleştirmek için dahil ediyoruz.) [source,console] ---- @@ -79,16 +78,16 @@ Squash commit -- not updating HEAD Automatic merge went well; stopped before committing as requested ---- -All the changes from the Rack project are merged in and ready to be committed locally. -You can also do the opposite – make changes in the `rack` subdirectory of your master branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream. +Rack projesindeki tüm değişiklikler birleştirilmiş ve yerel olarak katkılanmaya hazır durumdadır. +Ayrıca, tam tersini de yapabilirsiniz - kendi `master` dalınızın `rack` alt dizininde değişiklikler yapın ve daha sonra bunları proje bakıcılarına veya üst akıma göndermek için sonradan `rack_branch` dalınıza birleştirin. -This gives us a way to have a workflow somewhat similar to the submodule workflow without using submodules (which we will cover in <>). -We can keep branches with other related projects in our repository and subtree merge them into our project occasionally. -It is nice in some ways, for example all the code is committed to a single place. -However, it has other drawbacks in that it's a bit more complex and easier to make mistakes in reintegrating changes or accidentally pushing a branch into an unrelated repository. +Bu bize, alt modüller kullanmadan alt modül iş akışı kullanmaya oldukça benzeyen bir yöntem sunar (ki alt modülleri <> bölümünde ele alacağız). +İlgili diğer projelerin dallarını repomuzda tutabilir ve zaman zaman alt ağaç birleştirmesi yaparak bunları kendi projemize dahil edebiliriz. +Bu, mesela tüm kodların tek bir yerde katkılanmış olması gibi bazı açılardan güzel olabilir. +Ancak, diğer bazı dezavantajlara sahiptir! Örneğin, biraz daha karmaşıktır, değişiklikleri yeniden entegre etmek zordur veya yanlışlıkla bir dalı ilgisiz bir repoya itmek daha kolaydır. -Another slightly weird thing is that to get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch – to see if you need to merge them – you can't use the normal `diff` command. -Instead, you must run `git diff-tree` with the branch you want to compare to: +Biraz garip olan başka bir şey de, (mesela onları birleştirmeniz gerekip gerekmediğini görmek için) `rack` alt dizininde neye sahip olduğunuz ile `rack_branch` dalındaki kod arasındaki farkı görmek istediğinizde normal `diff` komutunu kullanamıyor olmanızdır. +Bunun yerine, karşılaştırmak istediğiniz dal ile `git diff-tree` komutunu çalıştırmalısınız: [source,console] ---- diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 3794521b..dbefff22 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -1,9 +1,9 @@ [[_git_config]] -=== Git Configuration +=== Git Yapılandırması (((git commands, config))) -As you read briefly in <>, you can specify Git configuration settings with the `git config` command. -One of the first things you did was set up your name and email address: +<> bölümünde kısaca okuduğunuz gibi, `git config` komutu ile Git yapılandırma ayarlarını belirleyebilirsiniz. +İlk yapmanız gereken şeylerden biri adınızı ve e-posta adresinizi ayarlamaktı. [source,console] ---- @@ -11,62 +11,62 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Now you'll learn a few of the more interesting options that you can set in this manner to customize your Git usage. +Şimdi, Git kullanımınızı özelleştirmek için bu şekilde belirleyebileceğiniz daha ilginç seçeneklerden birkaçını öğreneceksiniz. -First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want. -The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories. -If you pass the option `--system` to `git config`, it reads and writes from this file specifically. +İlk olarak, hızlı bir gözden geçirme: Git, istediğiniz varsayılan olmayan davranışı belirlemek için bir dizi yapılandırma dosyası kullanır. +Git, bu değerleri aramak için ilk olarak sistem genelinde `/etc/gitconfig` dosyasına bakar; bu dosya, sistemdeki her kullanıcıya ve onların tüm repolarına uygulanan ayarları içerir. +`git config` komutuna `--system` seçeneğini eklerseniz, Git özellikle bu dosyadan okur ve buraya yazar. -The next place Git looks is the `~/.gitconfig` (or `~/.config/git/config`) file, which is specific to each user. -You can make Git read and write to this file by passing the `--global` option. +Git'in bir sonraki baktığı yer, kullanıcıya özgü olan `~/.gitconfig` (ya da `~/.config/git/config`) dosyasıdır. +`--global` seçeneğini ekleyerek Git'in bu dosyayı okuyup yazdırmasını sağlayabilirsiniz. -Finally, Git looks for configuration values in the configuration file in the Git directory (`.git/config`) of whatever repository you're currently using. -These values are specific to that single repository, and represent passing the `--local` option to `git config`. -(If you don't specify which level you want to work with, this is the default.) +Son olarak, Git, şu anda kullandığınız repoya ait olan Git dizinindeki yapılandırma değerlerini arar (`.git/config`). +Bu değerler yalnızca o repoya özgüdür ve `git config` komutuna `--local` seçeneğini eklemeyi temsil eder. +(Hangi düzeyde çalışmak istediğinizi belirtmezseniz, varsayılan olarak bu ayar kullanılır.) -Each of these ``levels'' (system, global, local) overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance. +Bu "düzeylerin" (sistem, global, yerel) her biri, önceki düzeydeki değerleri geçersiz kılar; bu nedenle `.git/config` dosyasındaki değerler, örneğin, `/etc/gitconfig` dosyasındakilerin önüne geçer. [NOTE] ==== -Git's configuration files are plain-text, so you can also set these values by manually editing the file and inserting the correct syntax. -It's generally easier to run the `git config` command, though. +Git'in yapılandırma dosyaları düz metindir. Bu nedenle bu değerleri doğru sözdizimini eklemek şartıyla, manuel olarak da belirleyebilirsiniz. +Ancak genellikle `git config` komutunu çalıştırmak daha kolaydır. ==== -==== Basic Client Configuration +==== Temel İstemci Yapılandırması -The configuration options recognized by Git fall into two categories: client-side and server-side. -The majority of the options are client-side -- configuring your personal working preferences. -Many, _many_ configuration options are supported, but a large fraction of them are useful only in certain edge cases; we'll cover just the most common and useful options here. -If you want to see a list of all the options your version of Git recognizes, you can run +Git tarafından tanınan yapılandırma seçenekleri iki kategoriye ayrılır: istemci tarafı ve sunucu tarafı. +Seçeneklerin çoğu istemci tarafındadır (kişisel çalışma tercihlerinizi yapılandırır). +Çok fazla yapılandırma seçeneği desteklenir, ancak bunların büyük bir kısmı yalnızca belirli uç durumlarda kullanışlıdır (burada sadece en yaygın ve kullanışlı seçenekleri ele alacağız). +Git'in kullandığınız sürümünün tanıdığı tüm seçeneklerin bir listesini görmek istiyorsanız, şunu çalıştırabilirsiniz: [source,console] ---- $ man git-config ---- -This command lists all the available options in quite a bit of detail. -You can also find this reference material at https://git-scm.com/docs/git-config[]. +Bu komut, detaylı bir şekilde mevcut tüm seçenekleri listeler. +Bu başvuru materyalini ayrıca şu adreste bulabilirsiniz: https://git-scm.com/docs/git-config[]. ===== `core.editor` ((($EDITOR)))((($VISUAL, see $EDITOR))) -By default, Git uses whatever you've set as your default text editor via one of the shell environment variables `VISUAL` or `EDITOR`, or else falls back to the `vi` editor to create and edit your commit and tag messages. -To change that default to something else, you can use the `core.editor` setting: +Git varsayılan olarak, bir kabuk (shell) ortam değişkeni olan `VISUAL` veya `EDITOR` 'da sizin belirttiğiniz varsayılan metin düzenleyicisini kullanır, aksi durumdaysa katkı ve etiket mesajlarını oluşturmak ve düzenlemek için `vi` düzenleyicisine geri döner. +Bu varsayılanı başka bir şeye değiştirmek için, `core.editor` ayarını kullanabilirsiniz: [source,console] ---- $ git config --global core.editor emacs ---- -Now, no matter what is set as your default shell editor, Git will fire up Emacs to edit messages. +Artık, varsayılan kabuk düzenleyiciniz ne olursa olsun, Git mesajları düzenlemek için Emacs'i başlatacaktır. ===== `commit.template` (((commit templates))) -If you set this to the path of a file on your system, Git will use that file as the default initial message when you commit. -The value in creating a custom commit template is that you can use it to remind yourself (or others) of the proper format and style when creating a commit message. +Bu değeri sisteminizde bir dosyanın yoluna ayarlarsanız, Git bu dosyayı bir katkı oluştururken varsayılan başlangıç mesajı olarak kullanacaktır. +Özel bir katkı şablonu oluşturmanın önemi: bir katkı mesajı oluştururken, (kendinize veya başkalarına) doğru biçim ve stili hatırlatmak için kullanılabilmesidir. -For instance, consider a template file at `~/.gitmessage.txt` that looks like this: +Örneğin, `~/.gitmessage.txt` adresinde şöyle bir şablon dosyası düşünün: [source,text] ---- @@ -78,9 +78,9 @@ feel free to be detailed. [Ticket: X] ---- -Note how this commit template reminds the committer to keep the subject line short (for the sake of `git log --oneline` output), to add further detail under that, and to refer to an issue or bug tracker ticket number if one exists. +Bu katkı şablonunun, katkı işleyen kişiyi; ( `git log --oneline` çıktısı için) başlık satırını kısa tutmaya, altına daha fazla ayrıntı eklemeye ve varsa bir soruna veya iş paketi takip numarasına atıfta bulunmaya yönelttiğini görebilirsiniz. -To tell Git to use it as the default message that appears in your editor when you run `git commit`, set the `commit.template` configuration value: +`git commit` komutunu çalıştırdığınızda düzenleyicinizde görünen varsayılan mesajı bu şablon olarak kullanılması için, `commit.template` yapılandırma değerini ayarlayın: [source,console] ---- @@ -88,7 +88,7 @@ $ git config --global commit.template ~/.gitmessage.txt $ git commit ---- -Then, your editor will open to something like this for your placeholder commit message when you commit: +Daha sonra, bir katkı işlerken, düzenleyiciniz şöyle bir şey gösterecek: [source,text] ---- @@ -111,33 +111,33 @@ feel free to be detailed. ".git/COMMIT_EDITMSG" 14L, 297C ---- -If your team has a commit-message policy, then putting a template for that policy on your system and configuring Git to use it by default can help increase the chance of that policy being followed regularly. +Eğer ekibinizin bir katkı mesajı politikası varsa, o politikanın bir şablonunu sisteminize yerleştirmek ve Git'i varsayılan olarak kullanması için yapılandırmak, bu politikanın düzenli olarak uygulanma şansını arttıracaktır. ===== `core.pager` (((pager))) -This setting determines which pager is used when Git pages output such as `log` and `diff`. -You can set it to `more` or to your favorite pager (by default, it's `less`), or you can turn it off by setting it to a blank string: +Bu ayar, Git'in `log` ve `diff` gibi çıktıları yazdırdığında hangi sayfa düzeninin kullanılacağını belirler. +Bunu varsayılan olarak `less` şeklinde bırakabilir, `more` olarak ayarlanabilir veya boş bir dize olarak ayarlayarak devre dışı bırakabilirsiniz. [source,console] ---- $ git config --global core.pager '' ---- -If you run that, Git will page the entire output of all commands, no matter how long they are. +Bunu çalıştırırsanız, ne kadar uzun olursa olsun, Git tüm komutların çıktısını ekrana yazdırır. ===== `user.signingkey` (((GPG))) -If you're making signed annotated tags (as discussed in <>), setting your GPG signing key as a configuration setting makes things easier. -Set your key ID like so: +Eğer (<> bölümünde anlatıldığı gibi) imzalı açıklama etiketleri oluşturuyorsanız, GPG imzalama anahtarınızı bir yapılandırma ayarı olarak belirlemeniz işlerinizi kolaylaştırır. +Anahtar kimliğinizi şu şekilde ayarlayın: [source,console] ---- $ git config --global user.signingkey ---- -Now, you can sign tags without having to specify your key every time with the `git tag` command: +Artık `git tag` komutu ile anahtarınızı belirtmeden etiketleri her seferinde imzalayabilirsiniz. [source,console] ---- @@ -147,14 +147,14 @@ $ git tag -s ===== `core.excludesfile` (((excludes)))(((.gitignore))) -You can put patterns in your project's `.gitignore` file to have Git not see them as untracked files or try to stage them when you run `git add` on them, as discussed in <>. +(<> bölümünde anlatıldığı gibi) projenizin `.gitignore` dosyasına belli dosya yolu desenleri koyarak, Git'in o dosyaları takip edilmeyen dosyalar olarak görmemesini veya `git add` komutunu çalıştırdığınızda onları izleme almaya çalışmamasını sağlayabilirsiniz. -But sometimes you want to ignore certain files for all repositories that you work with. -If your computer is running macOS, you're probably familiar with `.DS_Store` files. -If your preferred editor is Emacs or Vim, you know about filenames that end with a `~` or `.swp`. +Ancak bazen, çalıştığınız tüm repolarda belirli dosyaları yok saymak istersiniz. +Bilgisayarınızda macOS çalışıyorsa, muhtemelen `.DS_Store` dosyalarını biliyorsunuzdur. +Tercih ettiğiniz metin düzenleyici Emacs veya Vim ise, `~` ile biten veya `.swp` ile biten dosya adlarını biliyorsunuzdur. -This setting lets you write a kind of global `.gitignore` file. -If you create a `~/.gitignore_global` file with these contents: +Bu ayar, bir tür global `.gitignore` dosyası yazmanızı sağlar. +Bu içeriklere sahip bir `~/.gitignore_global` dosyası oluşturur: [source,ini] ---- @@ -163,12 +163,12 @@ If you create a `~/.gitignore_global` file with these contents: .DS_Store ---- -…and you run `git config --global core.excludesfile ~/.gitignore_global`, Git will never again bother you about those files. +... ve `git config --global core.excludesfile ~/.gitignore_global` komutunu çalıştırırsanız, Git artık bu dosyalarla ilgili sizi bir daha rahatsız etmeyecek. ===== `help.autocorrect` (((autocorrect))) -If you mistype a command, it shows you something like this: +Eğer bir komutu yanlış yazarsanız, size şuna benzer bir şey gösterir: [source,console] ---- @@ -179,8 +179,8 @@ Did you mean this? checkout ---- -Git helpfully tries to figure out what you meant, but it still refuses to do it. -If you set `help.autocorrect` to 1, Git will actually run this command for you: +Git yardımcı olmak için ne anlatmaya çalıştığınızı anlamaya çalışır, ama sizin yerinize kendisi yapmaz. +`help.autocorrect` 'i 1 olarak ayarlarsanız, Git bu komutu sizin için düzeltip otomatik olarak çalıştıracaktır: [source,console] ---- @@ -190,67 +190,68 @@ Continuing under the assumption that you meant 'checkout' in 0.1 seconds automatically... ---- -Note that ``0.1 seconds'' business. `help.autocorrect` is actually an integer which represents tenths of a second. -So if you set it to 50, Git will give you 5 seconds to change your mind before executing the autocorrected command. +"0.1 saniye" kısmına dikkat edin. `help.autocorrect` aslında onda bir saniyeyi temsil eden bir tamsayıdır. +Bu nedenle, onu 50 olarak ayarlarsanız; Git size komutu otomatik düzeltmeden önce fikrinizi değiştirebilmeniz için 5 saniye verecektir. -==== Colors in Git +==== Git'te Renkler (((color))) -Git fully supports colored terminal output, which greatly aids in visually parsing command output quickly and easily. -A number of options can help you set the coloring to your preference. +Git, komut çıktısını hızlı ve kolay bir şekilde görsel olarak ayrıştırmaya büyük ölçüde yardımcı olan renkli terminal çıktısını tam destekler. +Birkaç seçenek, renklendirmeyi tercihinize göre ayarlamanıza yardımcı olabilir. ===== `color.ui` -Git automatically colors most of its output, but there's a master switch if you don't like this behavior. -To turn off all Git's colored terminal output, do this: +Git, çoğu çıktıyı otomatik olarak renklendirir, ancak bu davranışı beğenmezseniz bir ana anahtar da vardır. +Git'in tüm renkli terminal çıktısını kapatmak için şunu yapın: [source,console] ---- $ git config --global color.ui false ---- -The default setting is `auto`, which colors output when it's going straight to a terminal, but omits the color-control codes when the output is redirected to a pipe or a file. +Varsayılan ayar `auto` 'dur. +Bu, çıktı doğrudan bir terminale giderken renklendirme yapar, ancak çıktı bir boru (pipe) veya bir dosyaya yönlendirildiğinde renk kontrol kodlarını atlar. -You can also set it to `always` to ignore the difference between terminals and pipes. -You'll rarely want this; in most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes. -The default setting is almost always what you'll want. +Ayrıca, terminal ve borular arasındaki farkı yok saymak için onu `always` olarak da ayarlayabilirsiniz. +Bunu nadiren isteyeceksiniz; çoğu zaman, yönlendirilmiş çıktınızda renk kodları istiyorsanız, Git buna zorlamak için komuta bir `--color` bayrağı geçirerek bunu sağlayabilirsiniz. +Varsayılan ayar zaten neredeyse her zaman isteyeceğiniz şekildedir. ===== `color.*` -If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. -Each of these can be set to `true`, `false`, or `always`: +Belirli komutların nasıl renklendirileceği hakkında daha özelleştirici olmak isterseniz, Git, fiile özgü renklendirme ayarları da sunar. +Her birini `true`, `false` veya `always` olarak ayarlayabilirsiniz: color.branch color.diff color.interactive color.status -In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color. -For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run +Ayrıca, her birinin (her rengi geçersiz kılacak şekilde) çıktının belirli bölümleri için belirli renkler ayarlamak için kullanabileceğiniz alt ayarları vardır. +Örneğin, diff çıktınızdaki meta bilgilerini mavi ön plan, siyah arka plan ve kalın metin olarak ayarlamak için şunu çalıştırabilirsiniz: [source,console] ---- $ git config --global color.diff.meta "blue black bold" ---- -You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`. -If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul` (underline), `blink`, and `reverse` (swap foreground and background). +Renk seçeneğini aşağıdaki değerlerden biri olarak ayarlayabilirsiniz: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, veya `white`. +Önceki örnekteki gibi kalın gibi bir öznitelik istiyorsanız, `bold`, `dim`, `ul` (altını çizmek), `blink`, ve `reverse` (ön planı ve arka planı değiştirmek) seçeneklerinden birini seçebilirsiniz. [[_external_merge_tools]] -==== External Merge and Diff Tools +==== Harici Birleştirme ve Fark Araçları (((mergetool)))(((difftool))) -Although Git has an internal implementation of diff, which is what we've been showing in this book, you can set up an external tool instead. -You can also set up a graphical merge-conflict-resolution tool instead of having to resolve conflicts manually. -We'll demonstrate setting up the Perforce Visual Merge Tool (P4Merge) to do your diffs and merge resolutions, because it's a nice graphical tool and it's free. +Git'in bir diff için dahili bir uygulaması olsa da, bunun yerine harici bir araç kurabilirsiniz. +Ayrıca, birleşim çakışmalarını manuel olarak çözmek yerine görsel bir çözüm aracı da kurabilirsiniz. +Ücretsiz ve güzel görsel araç olduğu için "Perforce Visual Merge Tool (P4Merge)"'i diff ve birleştirme çözümleriniz için nasıl kuracağınızı göstereceğiz. -If you want to try this out, P4Merge works on all major platforms, so you should be able to do so. -We'll use path names in the examples that work on macOS and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment. +P4Merge tüm büyük platformlarda çalışır, bu yüzden kullancak olursanız, sorunsuzca çalıştırabiliyor olmalısınız. +Örneklerde macOS ve Linux sistemlerinde çalışan dizin isimlerini kullanacağız; Windows için, `/usr/local/bin` 'i cihazınızdaki yürütülebilir yolla değiştirmeniz gerekecektir. -To begin, https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools[download P4Merge from Perforce]. -Next, you'll set up external wrapper scripts to run your commands. -We'll use the macOS path for the executable; in other systems, it will be where your `p4merge` binary is installed. -Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided: +Başlamak için, Perforce'tan P4Merge'i indirin: https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools +Sonraki adımda, komutlarınızı çalıştırmak için harici sargı betiklerini kuracaksınız. +Bu örnekte yürütmek için macOS dizinini kullanacağız; diğer sistemlerde, `p4merge` ikilik dosyanızın kurulu olduğu dizin olacaktır. +İkilik dosyanızı çağıran bir birleştirme sargı betiği olan, `extMerge` adındaki betiği sağlanan tüm argümanlarla kurun: [source,console] ---- @@ -259,15 +260,15 @@ $ cat /usr/local/bin/extMerge /Applications/p4merge.app/Contents/MacOS/p4merge $* ---- -The diff wrapper checks to make sure seven arguments are provided and passes two of them to your merge script. -By default, Git passes the following arguments to the diff program: +Diff sargısı, yedi argümanın sağlandığını kontrol eder ve bunlardan ikisini birleştirme betiğinize aktarır. +Git diff programına aşağıdaki argümanları varsayılan olarak iletir: [source] ---- path old-file old-hex old-mode new-file new-hex new-mode ---- -Because you only want the `old-file` and `new-file` arguments, you use the wrapper script to pass the ones you need. +Sadece `old-file` ve `new-file` argümanlarına ihtiyacınız olduğu için, ihtiyacınız olanları iletmek için sargı betiğini kullanırsınız. [source,console] ---- @@ -276,7 +277,7 @@ $ cat /usr/local/bin/extDiff [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5" ---- -You also need to make sure these tools are executable: +Bu araçların yürütülebilir olduğundan da emin olmanız gerekir: [source,console] ---- @@ -284,9 +285,9 @@ $ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiff ---- -Now you can set up your config file to use your custom merge resolution and diff tools. -This takes a number of custom settings: `merge.tool` to tell Git what strategy to use, `mergetool..cmd` to specify how to run the command, `mergetool..trustExitCode` to tell Git if the exit code of that program indicates a successful merge resolution or not, and `diff.external` to tell Git what command to run for diffs. -So, you can either run four config commands +Şimdi yapılandırma dosyanızı özel bir birleştirme çözümü ve diff araçları kullanacak şekilde ayarlayabilirsiniz. +Bu bir dizi özel ayarı gerektirir: Git'e hangi stratejiyi kullanacağını söylemek için `merge.tool`, komutu nasıl çalıştıracağını belirtmek için `mergetool..cmd`, programın çıkış kodunun birleştirme çözümünün başarılı olup olmadığını belirtmek için `mergetool..trustExitCode`, ve diff için çalıştırılacak komutu belirtmek için `diff.external`. +Bu yüzden ya dört yapılandırma komutunu da çalıştırırsınız [source,console] ---- @@ -296,7 +297,8 @@ $ git config --global mergetool.extMerge.cmd \ $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiff ---- -or you can edit your `~/.gitconfig` file to add these lines: + +ya da `~/.gitconfig` dosyanızı düzenleyerek bu satırları eklersiniz: [source,ini] ---- @@ -309,22 +311,22 @@ or you can edit your `~/.gitconfig` file to add these lines: external = extDiff ---- -After all this is set, if you run diff commands such as this: +Tüm bunları ayarlandıktan sonra, şunun gibi diff komutlarını çalıştırırsanız: [source,console] ---- $ git diff 32d1776b1^ 32d1776b1 ---- -Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like this: +Komut satırında diff çıktısı almak yerine, Git P4Merge'i başlatır, ki bu da aşağı yukarı şöyle görünür: .P4Merge. image::images/p4merge.png[P4Merge.] -If you try to merge two branches and subsequently have merge conflicts, you can run the command `git mergetool`; it starts P4Merge to let you resolve the conflicts through that GUI tool. +İki dalı birleştirmeye çalışırsınız ve sonrasında birleştirme çakışmaları oluşursa, `git mergetool` komutunu çalıştırabilirsiniz; bu size bu GUI (görsel arayüz) aracılığıyla çakışmaları çözme fırsatı sunar. -The nice thing about this wrapper setup is that you can change your diff and merge tools easily. -For example, to change your `extDiff` and `extMerge` tools to run the KDiff3 tool instead, all you have to do is edit your `extMerge` file: +Bu sargı kurulumunun güzel yanı, diff ve birleştirme araçlarınızı kolayca değiştirebilmenizdir. +Örneğin, `extDiff` ve `extMerge` araçlarınızı KDiff3 aracını çalıştıracak şekilde değiştirmek için yapmanız gereken tek şey `extMerge` dosyanızı düzenlemektir: [source,console] ---- @@ -333,10 +335,10 @@ $ cat /usr/local/bin/extMerge /Applications/kdiff3.app/Contents/MacOS/kdiff3 $* ---- -Now, Git will use the KDiff3 tool for diff viewing and merge conflict resolution. +Git artık, diff görüntülemek ve çakışmaları çözmek için KDiff3 aracını kullanacaktır. -Git comes preset to use a number of other merge-resolution tools without your having to set up the cmd configuration. -To see a list of the tools it supports, try this: +Git, cmd yapılandırmasını ayarlamadan önce bir dizi başka birleştirme çözüm aracını kullanmak üzere önceden ayarlanmıştır. +Desteklediği araçların bir listesini görmek için şunu deneyin: [source,console] ---- @@ -368,49 +370,51 @@ Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail. ---- -If you're not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run +Eğer KDiff3 aracını, diff için değil de sadece birleştirme çözümü için kullanmak istiyorsanız; ama kdiff3 yürütülebilir dizininizde ise, o zaman şunu çalıştırabilirsiniz: [source,console] ---- $ git config --global merge.tool kdiff3 ---- -If you run this instead of setting up the `extMerge` and `extDiff` files, Git will use KDiff3 for merge resolution and the normal Git diff tool for diffs. +Eğer `extMerge` ve `extDiff` dosyalarını kurmak yerine bunu çalıştırırsanız, Git birleştirme çözümü için KDiff3'ü ve diff için normal Git diff aracını kullanacaktır. -==== Formatting and Whitespace +==== Biçimlendirme ve Boşluklar (((whitespace))) -Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. -It's very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. -Git has a few configuration options to help with these issues. +Biçimlendirme ve boşluk sorunları, özellikle platformlar arası işbirliğinde birçok geliştiricinin karşılaştığı en sinir bozucu ve gözden kaçması kolay sorunlardan bazılarıdır. +Editörler tarafından sessizce geliştirilen yamalar veya diğer işbirliği çalışmaları yüzünden sisteminize boşluk değişiklikleri aktarılması çok kolaydır. +Özellikle dosyalarınız Windows sistemine bir şekilde dokunmuşsa, satır sonları değiştirilmiş olabilir. +Git'in bu sorunlarla ilgili yardımcı olmak için, birkaç yapılandırma seçeneği vardır. ===== `core.autocrlf` (((crlf)))(((line endings))) -If you're programming on Windows and working with people who are not (or vice-versa), you'll probably run into line-ending issues at some point. -This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas macOS and Linux systems use only the linefeed character. -This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key. +Windows üzerinde program geliştiriyor ama Windows kullanmayan insanlarla çalışıyorsanız (veya tam tersi), muhtemelen bir noktada satır sonu sorunlarıyla karşılaşacaksınız. +Bunun nedeni, Windows'un dosyalarda yeni satırlar için hem bir taşıma-baş (CR: carriage-return) karakteri hem de bir satır besleme (LF: linefeed) karakteri kullanılırken, macOS ve Linux sistemlerinin ise yalnızca satır besleme karakterini kullanmasıdır. +Bu, platformlar arası çalışmanın incelikli ama son derece sinir bozucu bir gerçeğidir. +Windows'ta birçok editör mevcut LF tarzı satır sonu karakterlerini sessizce CRLF ile değiştirir veya kullanıcı enter tuşuna bastığında her iki satır sonu karakterini de ekler. -Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. -You can turn on this functionality with the `core.autocrlf` setting. -If you're on a Windows machine, set it to `true` -- this converts LF endings into CRLF when you check out code: +Git, bir dosyayı dizine eklerken CRLF satır sonlarını otomatik olarak LF'ye dönüştürerek ve kodu dosya sisteminize çıkardığınızda tersini yaparak bunu yönetebilir. +Bu işlevselliği `core.autocrlf` ayarı ile etkinleştirebilirsiniz. +Eğer Windows kullanıyorsanız, bunu `true` olarak ayarlayın: bunu yapmak, kodu çıkarırken LF sonlarını CRLF'ye dönüştürür: [source,console] ---- $ git config --global core.autocrlf true ---- -If you're on a Linux or macOS system that uses LF line endings, then you don't want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. -You can tell Git to convert CRLF to LF on commit but not the other way around by setting `core.autocrlf` to input: +Eğer LF satır sonları kullanan bir Linux veya macOS sistemindesiniz, o zaman dosyaları çıkarırken Git'in bunları otomatik olarak dönüştürmesini istemezsiniz; ancak, yanlışlıkla CRLF sonlarına sahip bir dosya tanıtılırsa, o zaman Git'in bunu düzeltmesini isteyebilirsiniz. +`core.autocrlf` ayarını `input` olarak ayarlayarak Git'e CRLF'yi LF'ye dönüştürmesini ancak tersini yapmamasını söyleyebilirsiniz: [source,console] ---- $ git config --global core.autocrlf input ---- -This setup should leave you with CRLF endings in Windows checkouts, but LF endings on macOS and Linux systems and in the repository. +Bu yapılandırma size, Windows çıkarımlarında CRLF sonları bırakırken, macOS ve Linux sistemlerinde ve repoda LF sonları sağlamalıdır. -If you're a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to `false`: +Eğer Windows programcısıysanız ve yalnızca Windows'a özgü bir proje yapıyorsanız; bu yapılandırma değerini `false` olarak ayarlayarak, bu işlevselliği kapatabilir ve taşıma karakterlerini repoya kaydedebilirsiniz: [source,console] ---- @@ -419,16 +423,16 @@ $ git config --global core.autocrlf false ===== `core.whitespace` -Git comes preset to detect and fix some whitespace issues. -It can look for six primary whitespace issues -- three are enabled by default and can be turned off, and three are disabled by default but can be activated. +Git, bazı boşluk sorunlarını algılamak ve düzeltmek için önceden ayarlanmıştır. +Altı temel boşluk sorununu arayabilir: Bunların üçü varsayılan olarak etkinleştirilmiştir ve kapatılabilir, üçü ise varsayılan olarak devre dışı bırakılmıştır ancak etkinleştirilebilir. -The three that are turned on by default are `blank-at-eol`, which looks for spaces at the end of a line; `blank-at-eof`, which notices blank lines at the end of a file; and `space-before-tab`, which looks for spaces before tabs at the beginning of a line. +Varsayılan olarak açılan üç özellik: satırın sonundaki boşlukları arayan `blank-at-eol`, dosyanın sonundaki boş satırları fark eden `blank-at-eof`, ve bir satırın başında sekme öncesinde boşluk arayan `space-before-tab` 'dir. -The three that are disabled by default but can be turned on are `indent-with-non-tab`, which looks for lines that begin with spaces instead of tabs (and is controlled by the `tabwidth` option); `tab-in-indent`, which watches for tabs in the indentation portion of a line; and `cr-at-eol`, which tells Git that carriage returns at the end of lines are OK. +Varsayılan olarak devre dışı bırakılan ancak etkinleştirilebilecek üç özellik ise: bir satırın başında boşluklar yerine sekme ile başlayan satırları arayan `indent-with-non-tab` (ve `tabwidth` seçeneği tarafından kontrol edilir), bir satırın girinti kısmındaki sekmeleri izleyen `tab-in-indent`, ve satırların sonunda taşıma karakterlerinin kabul edilebilir olduğunu belirten `cr-at-eol` 'dür. -You can tell Git which of these you want enabled by setting `core.whitespace` to the values you want on or off, separated by commas. -You can disable an option by prepending a `-` in front of its name, or use the default value by leaving it out of the setting string entirely. -For example, if you want all but `space-before-tab` to be set, you can do this (with `trailing-space` being a short-hand to cover both `blank-at-eol` and `blank-at-eof`): +Git'e bunlardan hangisinin etkinleştirilmesini istediğinizi, `core.whitespace` 'i açık veya kapalı olmasını istediğiniz değerlere virgülle ayırarak ayarlayarak, söyleyebilirsiniz. +Bir seçeneği devre dışı bırakmak için adının önüne `-` ekleyebilirsiniz, veya tamamen ayar dizgisinden çıkararak varsayılan değeri kullanabilirsiniz. +Örneğin, `space-before-tab` dışındaki tüm özelliklerin ayarlanmasını istiyorsanız, şunu yapabilirsiniz (hem `blank-at-eol` hem de `blank-at-eof` 'yi kapsayan `trailing-space` kısaltmasıyla): [source,console] ---- @@ -436,7 +440,7 @@ $ git config --global core.whitespace \ trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol ---- -Or you can specify the customizing part only: +Veya yalnızca özelleştirme kısmını belirtebilirsiniz: [source,console] ---- @@ -444,67 +448,70 @@ $ git config --global core.whitespace \ -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol ---- -Git will detect these issues when you run a `git diff` command and try to color them so you can possibly fix them before you commit. -It will also use these values to help you when you apply patches with `git apply`. -When you're applying patches, you can ask Git to warn you if it's applying patches with the specified whitespace issues: +`git diff` komutunu çalıştırdığınızda, Git bu sorunları algılayacak ve bunları katkılamadan önce düzeltebilmeniz için de renklendirecektir. +Ayrıca, `git apply` ile yamaları uygularken size yardımcı olmak için bu değerleri kullanacaktır. +Yamaları uygularken, Git'ten belirtilen boşluk sorunlarıyla ilgili sizi uyarmanızı isteyebilirsiniz: [source,console] ---- $ git apply --whitespace=warn ---- -Or you can have Git try to automatically fix the issue before applying the patch: +Ya da Git'ten yamanın uygulanmasından önce sorunu otomatik olarak düzeltmeye çalışmasını isteyebilirsiniz: [source,console] ---- $ git apply --whitespace=fix ---- -These options apply to the `git rebase` command as well. -If you've committed whitespace issues but haven't yet pushed upstream, you can run `git rebase --whitespace=fix` to have Git automatically fix whitespace issues as it's rewriting the patches. +Bu seçenekler `git rebase` komutuna da uygulanır. +Eğer kodunuzu boşluk sorunlarını çözmeden katkılamış, ancak henüz üstakıma itmemişseniz; Git'in yamaları yeniden yazarken boşluk sorunlarını otomatik olarak düzeltmesi için `git rebase --whitespace=fix` komutunu çalıştırabilirsiniz. -==== Server Configuration +==== Sunucu Yapılandırması -Not nearly as many configuration options are available for the server side of Git, but there are a few interesting ones you may want to take note of. +Git'in sunucu tarafında bu kadar çok yapılandırma seçeneği mevcut değildir, ancak not almak isteyebileceğiniz birkaç ilginç seçenek vardır. ===== `receive.fsckObjects` -Git is capable of making sure every object received during a push still matches its SHA-1 checksum and points to valid objects. -However, it doesn't do this by default; it's a fairly expensive operation, and might slow down the operation, especially on large repositories or pushes. -If you want Git to check object consistency on every push, you can force it to do so by setting `receive.fsckObjects` to true: +Git, bir itme işlemi sırasında alınan her nesnenin hala SHA-1 toplamına uymasını ve geçerli nesnelere işaret etmesini sağlayabilir. +Ancak, bunu varsayılan olarak yapmaz. Bu oldukça maliyetli bir işlemdir ve özellikle büyük drpolar veya itme işlemlerinde süreci yavaşlatabilir. +Her itme işleminde Git'in nesne tutarlılığını kontrol etmesini istiyorsanız, `receive.fsckObjects` ayarını true olarak ayarlayarak Git'i buna zorlayabilirsiniz: [source,console] ---- $ git config --system receive.fsckObjects true ---- -Now, Git will check the integrity of your repository before each push is accepted to make sure faulty (or malicious) clients aren't introducing corrupt data. +Artık, Git bir itme talebini kabul etmeden önce, reponun bütünlüğünü kontrol edecek ve hatalı (veya kötü niyetli) istemcilerin bozuk veri eklemesini engellemek için çaba gösterecektir. ===== `receive.denyNonFastForwards` -If you rebase commits that you've already pushed and then try to push again, or otherwise try to push a commit to a remote branch that doesn't contain the commit that the remote branch currently points to, you'll be denied. -This is generally good policy; but in the case of the rebase, you may determine that you know what you're doing and can force-update the remote branch with a `-f` flag to your push command. +Zaten ittiğiniz katkıları yeniden temeller (rebase) ve sonra tekrar itmeye çalışırsanız veya uzak dalın şu anda işaret ettiği katkıyı içermeyen dalına bir katkı göndermeye çalışırsanız reddedilirsiniz. +Bu genellikle iyi bir politikadır; ancak yeniden temelleme durumunda, ne yaptığınızı bildiğinizden eminseniz ve uzak şubeyi Push komutunuza bir '-f' bayrağıyla güncellemeye zorlayabilirsiniz. + +, uzak bir dala bir katkı itmek için, uzak dalın şu anda işaretlediği katkıyı içermeyen bir katkı iterseniz, reddedileceksiniz. +Bu genellikle iyi bir politikadır; ancak yeniden temelleme durumunda, ne yaptığınızı bildiğinizden eminseniz, itme komutunuza `-f` bayrağı ekleyerek uzak dalı zorla güncelleyebilirsiniz. -To tell Git to refuse force-pushes, set `receive.denyNonFastForwards`: +Git'e zorla itme işlemlerini reddetmesini söylemek için `receive.denyNonFastForwards` ayarını belirleyin: [source,console] ---- $ git config --system receive.denyNonFastForwards true ---- -The other way you can do this is via server-side receive hooks, which we'll cover in a bit. -That approach lets you do more complex things like deny non-fast-forwards to a certain subset of users. +Bunu yapmanın diğer yolu, birazdan ele alacağımız sunucu tarafı kabul kancaları aracılığıyladır. +Bu yaklaşım, belirli bir kullanıcı alt kümesine zorlamasız itmelere izin vermek gibi daha karmaşık işler yapmanıza olanak tanır. ===== `receive.denyDeletes` -One of the workarounds to the `denyNonFastForwards` policy is for the user to delete the branch and then push it back up with the new reference. -To avoid this, set `receive.denyDeletes` to true: +`denyNonFastForwards` politikasına yönelik çalışmaların biri, kullanıcının dalı silip ardından yeni referansla tekrar yüklemesidir. +Bunu önlemek için, `receive.denyDeletes` ayarını true olarak ayarlayın: [source,console] ---- $ git config --system receive.denyDeletes true ---- -This denies any deletion of branches or tags -- no user can do it. -To remove remote branches, you must remove the ref files from the server manually. -There are also more interesting ways to do this on a per-user basis via ACLs, as you'll learn in <>. +Bu ayar, dalların veya etiketlerin herhangi birinin silinmesini reddeder (hiçbir kullanıcı bunu yapamaz). +Uzak dalları kaldırmak için, ref dosyalarını sunucudan manuel olarak kaldırmanız gerekir. +Ayrıca, <> bölümünde öğreneceğiniz gibi, ACL'ler aracılığıyla kullanıcı bazında bunu yapmanın daha ilginç yolları da vardır. diff --git a/ch02-git-basics.asc b/ch02-git-basics.asc index 1125825f..f08acb77 100644 --- a/ch02-git-basics.asc +++ b/ch02-git-basics.asc @@ -1,10 +1,10 @@ [[ch02-git-basics]] -== Git Basics +== Git Temelleri -If you can read only one chapter to get going with Git, this is it. -This chapter covers every basic command you need to do the vast majority of the things you'll eventually spend your time doing with Git. -By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. -We'll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. +Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu aradığınız bölümdür. +Bu bölüm, Git'te zamanınızı harcayacağınız şeylerin büyük çoğunluğunu yapmak için ihtiyacınız olan tüm temel komutları kapsar. +Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi izleme alıp (stage) uzak repoya kaydedebilecek seviyeye geleceksiniz. +Ayrıca Git'i belirli dosyaları ve dosya kalıplarını yok sayacak şekilde nasıl ayarlayacağınızı, hataları hızlı ve kolay bir şekilde nasıl geri alacağınızı, projenizin geçmişine nasıl göz atacağınızı, katkılar (commit) arasındaki değişiklikleri nasıl görüntüleyeceğinizi ve uzak repolarla nasıl kod alışverişi yapacağınızı göstereceğiz. include::book/02-git-basics/sections/getting-a-repository.asc[] @@ -20,7 +20,7 @@ include::book/02-git-basics/sections/tagging.asc[] include::book/02-git-basics/sections/aliases.asc[] -=== Summary +=== Özet -At this point, you can do all the basic local Git operations -- creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. -Next, we'll cover Git's killer feature: its branching model. +Bu noktada, tüm temel yerel Git işlemlerini yapabilirsiniz: bir repo oluşturma veya kopyalama, değişiklikler yapma, bu değişiklikleri izleme ve katkı olarak işleme, repodaki tüm geçmiş değişiklikleri görüntüleme, vs. +Şimdi sıradaki konuya geçiyoruz: Git'in ana özelliği olan dallanma modeli. diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index d1528f22..87cda76d 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -1,16 +1,16 @@ [[ch03-git-branching]] -== Git Branching +== Git Dalları (((branches))) -Nearly every VCS has some form of branching support. -Branching means you diverge from the main line of development and continue to do work without messing with that main line. -In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. +Neredeyse her sürüm kontrol sisteminin (VCS) bir tür dal desteği vardır. +Dal oluşturmak, ana geliştirme hattından ayrılıp, bu ana hatla oynamadan çalışmalarımıza devam etmek anlamına gelir. +Birçok sürüm kontrol sistemi aracında bu, genellikle kaynak kodu dizininin yeni bir kopyasını oluşturmanızı gerektiren ve büyük projeler için uzun zaman alabilen, maliyetli bir süreçtir. -Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community. -Why is it so special? -The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. -Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. -Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. +Bazı insanlar Git'in dalma modelini "ölümcül özellik" olarak adlandırır ve kuşkusuz Git'i VCS topluluğunda öne çıkarır. +Peki bu neden bu kadar özeldir? +Git'in dallanma şekli son derece hafiftir, bu da dallandırma işlemlerinin neredeyse anlık hale gelmesini sağlar ve genellikle dallar arasında hızlı bir şekilde geçiş yapılabilir. +Diğer birçok sürüm kontrol sisteminin aksine, Git iş akışlarında sık sık dal açma ve birleştirmeyi teşvik eder, hatta gün içerisinde bir çok kez. +Bu özelliği anlamak ve ustalaşmak size güçlü ve benzersiz bir araç sağlar ve geliştirme şeklinizi tamamen değiştirebilir. include::book/03-git-branching/sections/nutshell.asc[] @@ -24,9 +24,10 @@ include::book/03-git-branching/sections/remote-branches.asc[] include::book/03-git-branching/sections/rebasing.asc[] -=== Summary +=== Özet + +Git'te temel dal açma ve birleştirme işlemlerini ele aldık. +Yeni dallar oluşturmayı, bu dallar arasında geçiş yapmayı ve yerel dalları birleştirmeyi artık rahatlıkla yapabiliyor olmalısınız. +Ayrıca, dallarınızı paylaşmayı, paylaşımlı bir sunucuya itmeyi, başkalarınca paylaşılan dallarda çalışmayı ve dallarınızı paylaşmadan önce yeniden temellemeyi de öğrenmiş olmalısınz. +Şimdi sıradaki konuya geçeceğiz: Kendi Git repo barındırma sunucunuzu (host) çalıştırmak için ihtiyacınız olan şeyler. -We've covered basic branching and merging in Git. -You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. -You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. -Next, we'll cover what you'll need to run your own Git repository-hosting server. diff --git a/ch04-git-server.asc b/ch04-git-server.asc index a867a63c..8e3c0400 100644 --- a/ch04-git-server.asc +++ b/ch04-git-server.asc @@ -1,24 +1,24 @@ [[ch04-git-on-the-server]] -== Git on the Server +== Bir Sunucuda Git Kurma (((serving repositories))) -At this point, you should be able to do most of the day-to-day tasks for which you'll be using Git. -However, in order to do any collaboration in Git, you'll need to have a remote Git repository. -Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they're working on if you're not careful. -Furthermore, you want your collaborators to be able to access the repository even if your computer is offline -- having a more reliable common repository is often useful. -Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. +Şu aşamada, Git'i kullanacağınız günlük görevlerin çoğunu yapabilecek durumda olmalısınız. +Ancak, Git'te işbirliği yapmak için bir uzak Git reposuna ihtiyacınız olacaktır. +Teknik olarak değişiklikleri bireylerin depolarına itip çekebilirsiniz, ancak dikkatli olmazsanız ne üzerinde çalıştıklarını kolayca karıştırabilirsiniz. +Ayrıca, bilgisayarınız çevrimdışı olsa dahi çalışma arkadaşlarınızın repoya erişebilmesini istersiniz - daha güvenilir bir ortak repoya sahip olmak genellikle faydalıdır. +Bu nedenle, biriyle işbirliği yapmanın en tercih edilen yolu, her ikinizin de erişimi olan ara bir repo kurmak ve bu repoya itip çekmektir. -Running a Git server is fairly straightforward. -First, you choose which protocols you want your server to support. -The first section of this chapter will cover the available protocols and the pros and cons of each. -The next sections will explain some typical setups using those protocols and how to get your server running with them. -Last, we'll go over a few hosted options, if you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server. +Bir Git sunucusu çalıştırmak oldukça basittir. +İlk olarak, sunucunuzun hangi protokolleri destekleyeceğini seçersiniz. +Bu bölümün ilk kısmı, mevcut protokolleri ve her birinin artılarını ve eksilerini ele alacaktır. +Sonraki bölümler, bu protokolleri kullanarak tipik bazı kurulumları ve sunucunuzu bu protokollerle nasıl çalıştıracağınızı açıklayacaktır. +Son olarak, kendi sunucunuzu kurup bakımını yapmakla uğraşmak istemiyorsanız ve kodunuzu başka birinin sunucusunda barındırmakla ilgili bir sorununuz yoksa, birkaç barındırma (hosting) seçeneğinden bahsedeceğiz. -If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. +Kendi sunucunuzu çalıştırmakla ilgilenmiyorsanız, barındırılan bir hesap kurmak için bu ünitenin son bölümüne geçebilir ve ardından da bir sonraki üniteye geçebilirsiniz. O kısımda dağıtık bir kaynak kontrol ortamında çalışmanın çeşitli yönlerini tartışacağız. -A remote repository is generally a _bare repository_ -- a Git repository that has no working directory. -Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it's just the Git data. -In the simplest terms, a bare repository is the contents of your project's `.git` directory and nothing else. +Bir uzak repo genellikle bir _yalın repo_ olarak adlandırılan ve çalışma dizini olmayan, basit bir Git reposudur. +Bir repo sadece işbirliği noktası olarak kullanıldığından, sadece Git verileri vardır ve diske çıkarılmış bir poz oluşturma nedeni yoktur; . +En basit ifadesiyle, yalın bir depo projenizin `.git` dizininden başka bir şey değildir. include::book/04-git-server/sections/protocols.asc[] @@ -38,11 +38,11 @@ include::book/04-git-server/sections/gitlab.asc[] include::book/04-git-server/sections/hosted.asc[] -=== Summary +=== Özet -You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. +Başkalarıyla işbirliği yapmak veya çalışmalarınızı paylaşmak için uzaktan bir Git reposu oluşturmanın birkaç seçeneği bulunmaktadır. -Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. -If you place your data on a hosted server, it's easy to set up and maintain; however, you have to be able to keep your code on someone else's servers, and some organizations don't allow that. +Kendi sunucunuzu çalıştırmak size çok fazla kontrol sağlar ve sunucuyu kendi güvenlik duvarınız içinde çalıştırmanıza izin verir, ancak bu tür bir sunucuyu kurmak ve bakımını yapmak genellikle çok fazla zaman gerektirir. +Verilerinizi barındırılan bir sunucuya yerleştirmek ve bakımı yapmak daha kolaydır; ancak kodunuzu başka birinin sunucularında tutmak zorunda kalırsınız ve bazı kuruluşlar buna izin vermez. -It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. +Hangi çözüm veya çözüm karmasının siz ve organizasyonunuz için uygun olduğunu belirlemek artık sizin için daha basit olmalı. diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index 588a2174..dd52deae 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -1,11 +1,11 @@ [[ch05-distributed-git]] -== Distributed Git +== Dağıtık Git (((distributed git))) -Now that you have a remote Git repository set up as a focal point for all the developers to share their code, and you're familiar with basic Git commands in a local workflow, you'll look at how to utilize some of the distributed workflows that Git affords you. +Artık diğer geliştiricilerle ortak bir proje üzerinde çalışırken kodlarınızı paylaşmak üzere kurulmuş bir uzak Git deposuna sahipsiniz ve yerel bir iş akışında temel Git komutlarına aşina olduğunuz için, Git'in size sunduğu dağıtık iş akışlarını nasıl kullanacağınıza bakacaksınız. -In this chapter, you'll see how to work with Git in a distributed environment as a contributor and an integrator. -That is, you'll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing. +Bu bölümde, dağıtık bir ortamda bir katkı sağlayıcı ve proje yöneticisi olarak Git ile nasıl çalışılacağını göreceksiniz. +Yani, bir projeye başarılı bir şekilde kod eklemeyi ve hem siz hem de proje yürütücüsü için sürecin mümkün olduğunca kolay olmasını sağlamayı öğreneceksiniz. Ayrıca birçok geliştiricinin katkıda bulunduğu bir projeyi başarılı bir şekilde sürdürmeyi de öğreneceksiniz. include::book/05-distributed-git/sections/distributed-workflows.asc[] @@ -13,8 +13,8 @@ include::book/05-distributed-git/sections/contributing.asc[] include::book/05-distributed-git/sections/maintaining.asc[] -=== Summary +=== Özet -You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users' contributions. -Congratulations on being an effective Git developer! -In the next chapter, you'll learn about how to use the largest and most popular Git hosting service, GitHub. +Artık Git'te bir projeye katkıda bulunma ve kendi projenizi veya diğer kullanıcıların katkılarını entegre etme konusunda oldukça rahat hissediyor olmalısınız. +Artık etkili bir Git geliştiricisi olduğunuz için sizi kutlarız! +Bir sonraki bölümde, en büyük ve en popüler Git barındırma hizmeti olan GitHub'ı nasıl kullanacağınızı öğreneceksiniz. diff --git a/ch06-github.asc b/ch06-github.asc index e2cd29e7..243907de 100644 --- a/ch06-github.asc +++ b/ch06-github.asc @@ -2,20 +2,20 @@ == GitHub (((GitHub))) -GitHub is the single largest host for Git repositories, and is the central point of collaboration for millions of developers and projects. -A large percentage of all Git repositories are hosted on GitHub, and many open-source projects use it for Git hosting, issue tracking, code review, and other things. -So while it's not a direct part of the Git open source project, there's a good chance that you'll want or need to interact with GitHub at some point while using Git professionally. +GitHub, Git repoları için tek başına en büyük barındırıcıdır ve milyonlarca geliştirici ve projenin işbirliği için merkezi bir noktadır. +Tüm Git repolarının çok büyük bir yüzdesi GitHub'de barındırılır ve birçok açık kaynaklı proje, barındırma, sorun takibi, kod incelemesi ve diğer işler için GitHub'i kullanır. +Bu nedenle, GitHub, Git açık kaynak projesinin doğrudan bir parçası olmasa da, Git'i profesyonel olarak kullanırken GitHub ile etkileşime geçme ihtiyacı duyma ihtimaliniz oldukça yüksektir. -This chapter is about using GitHub effectively. -We'll cover signing up for and managing an account, creating and using Git repositories, common workflows to contribute to projects and to accept contributions to yours, GitHub's programmatic interface and lots of little tips to make your life easier in general. +Bu bölüm, GitHub'i etkili bir şekilde kullanma üzerinedir. +Bir hesap oluşturmayı ve yönetmeyi, Git repoları oluşturmayı ve kullanmayı, projelere katkıda bulunma ve kendi projenize katkıları kabul etmek için yaygın iş akışlarını, GitHub'in programlamaya dayalı arayüzünü ve genel olarak hayatınızı kolaylaştıracak birçok başka küçük ipucunu kapsayacağız. -If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to <>. +Kendi projelerinizi GitHub üzerinden yayınlamak veya GitHub'ta barındırılan diğer projelerle işbirliği yapmak istemiyorsanız, doğrudan <> bölümüne geçebilirsiniz. [WARNING] -.Interfaces Change +.Arayüzdeki Değişimler ==== -It's important to note that like many active websites, the UI elements in these screenshots are bound to change over time. -Hopefully the general idea of what we're trying to accomplish here will still be there, but if you want more up to date versions of these screens, the online versions of this book may have newer screenshots. +Bu ekran görüntülerindeki kullanıcı arayüzü öğelerinin birçoğunun zamanla değişebileceğini belirtmek istiyoruz. +Umuyoruz ki burada neyi başarmaya çalıştığımızın genel fikri hala geçerli olacaktır, ancak daha güncel ekran görüntülerini istiyorsanız, bu kitabın çevrimiçi sürümlerinin daha yeni ekran görüntülerine sahip olabileceğini unutmayın. ==== include::book/06-github/sections/1-setting-up-account.asc[] @@ -28,8 +28,8 @@ include::book/06-github/sections/4-managing-organization.asc[] include::book/06-github/sections/5-scripting.asc[] -=== Summary +=== Özet -Now you're a GitHub user. -You know how to create an account, manage an organization, create and push to repositories, contribute to other people's projects and accept contributions from others. -In the next chapter, you'll learn more powerful tools and tips for dealing with complex situations, which will truly make you a Git master. +Artık bir GitHub kullanıcısısınız. +Hesap oluşturmayı, bir organizasyon yönetmeyi, repo oluşturmayı ve yönlendirmeyi, başkalarının projelerine katkı sağlamayı ve başkalarından katkı kabul etmeyi biliyorsunuz. +Bir sonraki bölümde, karmaşık durumlarla başa çıkmak için daha güçlü araçlar ve ipuçları öğreneceksiniz, bu da sizi gerçek bir Git bükücü yapacak. diff --git a/ch07-git-tools.asc b/ch07-git-tools.asc index 0e7fad55..765cfe5d 100644 --- a/ch07-git-tools.asc +++ b/ch07-git-tools.asc @@ -1,10 +1,10 @@ [[ch07-git-tools]] -== Git Tools +== Git Araçları -By now, you've learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. -You've accomplished the basic tasks of tracking and committing files, and you've harnessed the power of the staging area and lightweight topic branching and merging. +Şimdiye kadar, kaynak kod kontrolü için bir Git reposunu yönetmek veya sürdürmek için ihtiyacınız olan günlük komutları ve iş akışlarının çoğunu öğrendiniz. +Dosyaları izleme ve katkılama gibi temel görevleri başardınız ve ayrıca konu dalları oluşturma ve birleştirme gücünü de kullandınız. -Now you'll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point. +Şimdi, günlük olarak kullanmasanız da, bir noktada ihtiyacınız olabilecek çok güçlü şeyleri keşfedeceksiniz. include::book/07-git-tools/sections/revision-selection.asc[] @@ -34,9 +34,9 @@ include::book/07-git-tools/sections/replace.asc[] include::book/07-git-tools/sections/credentials.asc[] -=== Summary +=== Özet -You've seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. -When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. -If you want to use subprojects in your project, you've learned how to accommodate those needs. -At this point, you should be able to do most of the things in Git that you'll need on the command line day to day and feel comfortable doing so. +Günlük iş akışınızda, katkıları ve izlem alanını daha hassas bir şekilde kullanmanıza izin veren bir dizi gelişmiş araç gördünüz. +Sorunları fark ettiğinizde, bu sorunları hangi katkının, ne zaman ve kim tarafından tanıtıldığını kolayca belirleyebilirsiniz. +Projenizde alt-projeler kullanmak istiyorsanız, bu ihtiyaçları nasıl karşılayacağınızı da öğrendiniz. +Bu noktada, çok rahat ve kendinden emin bir şekilde, Git'te günlük işlerinizin çoğunu komut satırında yapabilir durumda olmalısınız.