From 9deb675265b7e484d770aed8707a24faa8600e9d Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 23 Jan 2024 22:51:07 +0100 Subject: [PATCH 001/210] Update nutshell.asc Translated up to line:48 --- book/03-git-branching/sections/nutshell.asc | 49 +++++++++++---------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 1041d564..27f76cc3 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -1,15 +1,15 @@ [[_git_branches_overview]] -=== Branches in a Nutshell +=== Kısaca Dallar -To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. +Git'in dallanma yöntemini gerçekten anlamak için bir adım geriye çekilip Git'in verileri nasıl sakladığını incelememiz gerekiyor. -As you may remember from <>, Git doesn't store data as a series of changesets or differences, but instead as a series of _snapshots_. +<> bölümündün hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _anlık görüntü_ olarak saklar. -When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. -This object also contains the author's name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. +Git, bir katkı işlediğinizde (commit), aşamalandırdığınız (stage) içeriğin anlık görüntüsünün işaretçisi (pointer: bir katkı veya ağacın yerini gösteren işaretçi) içeren bir katkı nesnesi (object) saklar. +Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve önceki katkı veya katkılara ilişkin işaretçileri içerir. İlk katkı (first commit) için sıfır; normal bir katkı için bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı içinse çoklu öncel katkı bulunur. -To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit. -Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <>), stores that version of the file in the Git repository (Git refers to them as _blobs_), and adds that checksum to the staging area: +Bunu görselleştirmek için, üç dosya içeren bir dizine sahip olduğumuzu ve bunların hepsini aşamalandırıp (stage) katkı olarak işlediğinizi varsayalım. +Dosyaları aşamalandırmak, her bir dosya için bir sağlama toplamı (checksum) hesaplar (<> bölümünde bahsettiğimiz SHA-1 karması), dosyanın bu sürümünü Git reposunda saklar (Git bunlara _blobs_ olarak atıfta bulunur)(Binary Large OBject: ikili geniş nesne), ve bu sağlama toplamını aşamalandırma alanına (stage) ekler: [source,console] ---- @@ -17,29 +17,32 @@ $ git add README test.rb LICENSE $ git commit -m 'The initial commit of my project' ---- -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. -Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit))) +`git commit` komutunu çalıştırarak bir katkı oluşturduğunuzda, Git her alt dizinin (bu durumda sadece kök (root) proje dizini) doğrular (checksum) ve bunları Git reposunda bir ağaç nesnesi (tree object) olarak saklar. +Git daha sonra meta verileri ve kök proje ağacının işaretçisini içeren bir katkı nesnesi oluşturur. Böylece gerektiğinde anlık görüntüyü yeniden oluşturabilir.(((git commands, commit))) -Your Git repository now contains five objects: three _blobs_ (each representing the contents of one of the three files), one _tree_ that lists the contents of the directory and specifies which file names are stored as which blobs, and one _commit_ with the pointer to that root tree and all the commit metadata. +Git reponuz artık beş nesne içeriyor: + - Her biri üç dosyadan birinin içeriğini temsil eden üç _blob_ + - Dizinin içeriğini ve hangi dosya adlarının hangi _blob_ olarak depolandığını listeleyen bir _ağaç_ + - Kök ağacın işaretçisini ve tüm katkı metadata'sını içeren bir _katkı_ -.A commit and its tree -image::images/commit-and-tree.png[A commit and its tree.] +.Bir katkı ve onun ağacı +image::images/commit-and-tree.png[Bir katkı ve onun ağacı.] -If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. +Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz (git commit), sonraki katkı, kendinden hemen önceki katkıya işaret eden bir işaretçiyi depolar. -.Commits and their parents -image::images/commits-and-parents.png[Commits and their parents.] +.Katkı ve önceki katkılar +image::images/commits-and-parents.png[Katkı ve önceki katkılar.] -A branch in Git is simply a lightweight movable pointer to one of these commits. -The default branch name in Git is `master`. -As you start making commits, you're given a `master` branch that points to the last commit you made. -Every time you commit, the `master` branch pointer moves forward automatically. +Git'teki bir dal, temel olarak üzerindeki katkılardan birinin hafif ve taşınabilir bir işaretçisidir. +Git'te varsayılan dalın adı `master`dır (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. -[NOTE] +[NOT] ==== -The ``master'' branch in Git is not a special branch.(((master))) -It is exactly like any other branch. -The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it. +Git'teki ``master`` dalı özel bir dal değildir.(((master))) +Tam olarak diğer diğer dallar gibi davranır. +Hemen hemen her repoda bulunmasının tek nedeni, `git init` komutunun varsayılan olarak onu oluşturması ve çoğu insanın bunu değiştirmeye uğraşmamasıdır. ==== .A branch and its commit history From 37c3b86f889915af563cc7ae0fa24366c50c6220 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 24 Jan 2024 21:27:47 +0100 Subject: [PATCH 002/210] Update nutshell.asc Whole page has been translated --- book/03-git-branching/sections/nutshell.asc | 127 ++++++++++---------- 1 file changed, 64 insertions(+), 63 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 27f76cc3..5aebb27e 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -45,40 +45,40 @@ Tam olarak diğer diğer dallar gibi davranır. Hemen hemen her repoda bulunmasının tek nedeni, `git init` komutunun varsayılan olarak onu oluşturması ve çoğu insanın bunu değiştirmeye uğraşmamasıdır. ==== -.A branch and its commit history -image::images/branch-and-history.png[A branch and its commit history.] +.Bir dal ve katkı geçmişi +image::images/branch-and-history.png[Bir dal ve katkı geçmişi.] [[_create_new_branch]] -==== Creating a New Branch +==== Yeni bir Dal Açma (((branches, creating))) -What happens when you create a new branch? -Well, doing so creates a new pointer for you to move around. -Let's say you want to create a new branch called `testing`. -You do this with the `git branch` command:(((git commands, branch))) +Yeni bir dal oluşturduğunuzda ne olur? +Öncelikle, bu size etrafında dolaşabileceğiniz yeni bir işaretçi oluşturur. +Diyelim ki `testing` adında yeni bir dal oluşturmak istiyorsunuz. +Bunu `git branch` komutu ile yaparsınız:(((git commands, branch))) [source,console] ---- $ git branch testing ---- -This creates a new pointer to the same commit you're currently on. +Bu, şu anda işlediğiniz katkı için yeni bir işaretçi oluşturur. -.Two branches pointing into the same series of commits -image::images/two-branches.png[Two branches pointing into the same series of commits.] +.Aynı katkı dizisine işaret eden iki dal +image::images/two-branches.png[Aynı katkı dizisine işaret eden iki dal.] -How does Git know what branch you're currently on? -It keeps a special pointer called `HEAD`. -Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. -In Git, this is a pointer to the local branch you're currently on. -In this case, you're still on `master`. -The `git branch` command only _created_ a new branch -- it didn't switch to that branch. +Git, şu anda hangi dalda olduğunuzu nasıl bilir? +Bunu `HEAD` adlı özel bir işaretçiyi kullanarak yapar. +Yalnız bu Subversion veya CVS gibi alışkın olduğunuz diğer sürüm denetleyicilerindeki (VCS) `HEAD` kavramından çok farklıdır. +Git'te bu, şu anda üzerinde çalıştığınız yerel dalın bir işaretçisidir. +Mevcut senaryomuzda halen `master` dalındasınız. +`git branch` komutu sadece yeni bir dal _oluşturdu_ ama henüz o dala geçiş yapmadı. -.HEAD pointing to a branch -image::images/head-to-master.png[HEAD pointing to a branch.] +.Bir dala işaret eden HEAD +image::images/head-to-master.png[Bir dala işaret eden HEAD.] -You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. -This option is called `--decorate`. +Dal işaretçilerinin nereye işaret ettiğini görmek için en basitinden bir `git log` komutu çalıştırabilirsiniz. +Bu seçenek, `--decorate` olarak adlandırılır. [source,console] ---- @@ -88,27 +88,27 @@ f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to 98ca9 The initial commit of my project ---- -You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit. +`f30ab` katkısının hemen yanında `master` ve `testing` dallarını görebilirsiniz. [[_switching_branches]] -==== Switching Branches +==== Dallararası Geçiş (((branches, switching))) -To switch to an existing branch, you run the `git checkout` command.(((git commands, checkout))) -Let's switch to the new `testing` branch: +Var olan bir dala geçmek için `git checkout` komutunu çalıştırırsınız.(((git commands, checkout))) +Hadi yeni oluşturduğumuz `testing` dalına geçelim: [source,console] ---- $ git checkout testing ---- -This moves `HEAD` to point to the `testing` branch. +Bu komut `HEAD` işaretçisinin yönünü `testing` dalına çevirir. -.HEAD points to the current branch -image::images/head-to-testing.png[HEAD points to the current branch.] +.Mevcut dalı gösteren HEAD işaretçisi +image::images/head-to-testing.png[Mevcut dalı gösteren HEAD işaretçisi.] -What is the significance of that? -Well, let's do another commit: +Peki bunun önemi nedir? +Hadi şimdi başka bir katkı işleyelim: [source,console] ---- @@ -116,34 +116,34 @@ $ vim test.rb $ git commit -a -m 'made a change' ---- -.The HEAD branch moves forward when a commit is made -image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.] +.Bir katkı işlendiğinde `HEAD`in işaret ettiği dal ileriye doğru hareket eder. +image::images/advance-testing.png[Bir katkı işlendiğinde `HEAD` ileriye doğru hareket eder.] -This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. -Let's switch back to the `master` branch: +İlginç bir şekilde, `testing` dalınız ileri hareket etti ancak `master` dalınız halen en son bıraktığımız halde (`testing` dalına geçiş yaptığınız anda üzerinde bulunduğunuz katkıya işaret ediyor). +Hadi `master` dalımıza tekrar geçelim: [source,console] ---- $ git checkout master ---- -.HEAD moves when you checkout -image::images/checkout-master.png[HEAD moves when you checkout.] +.Başka dala geçtiğinizde (git checkout) HEAD'in yönü değişir +image::images/checkout-master.png[Başka dala geçtiğinizde HEAD'in yönü değişir.] -That command did two things. -It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. -This also means the changes you make from this point forward will diverge from an older version of the project. -It essentially rewinds the work you've done in your `testing` branch so you can go in a different direction. +Bu komut iki şey yaptı: +İlk olarak, `HEAD` işaretçisini tekrar `master` dalına çevirdi ve ikinci olarak, çalışma dizinindeki dosyaları `master`'ın işaret ettiği anlık görüntüye geri dönderdi. +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. -[NOTE] -.Switching branches changes files in your working directory +[NOT] +.Dallar arasında geçiş yapmak çalışma dizinindeki dosyaları değiştirir ==== -It's important to note that when you switch branches in Git, files in your working directory will change. -If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. -If Git cannot do it cleanly, it will not let you switch at all. +Git'te dallar arasında geçiş yaparken, çalışma dizininizdeki dosyaların değişeceğini unutmamalısınız! +Eğer daha eski bir dala geçerseniz, çalışma dizininiz o dalda son katkı işlediğiniz ana geri döner. +Eğer Git bunu temiz bir şekilde gerçekleştiremezse, geçiş yapmanıza hiç izin vermez. ==== -Let's make a few changes and commit again: +Hadi bir kaç değişiklik yapalım ve katkı işleyelim: [source,console] ---- @@ -151,17 +151,17 @@ $ vim test.rb $ git commit -a -m 'made other changes' ---- -Now your project history has diverged (see <>). -You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. -Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you're ready. -And you did all that with simple `branch`, `checkout`, and `commit` commands. +Şimdi projenizin geçmişi sapmış durumda (bakınız <>). +Bir dal oluşturdunuz, ona geçtiniz, üzerinde çalıştınız, ardından ana dalınıza geri döndünüz ve bambaşka bir iş yaptınız. +Her iki değişiklik farklı dallarda yalıtılmış durumdadır: Dallar arasında geçiş yapabilirsiniz ve istediğinizde onları birleştirebilecek durumdasınız. +Bunların hepsini basit `branch`, `checkout` ve `commit` komutları ile yaptınız. [[divergent_history]] -.Divergent history -image::images/advance-master.png[Divergent history.] +.Ayrık geçmiş (Divergent history) +image::images/advance-master.png[Ayrık geçmiş.] -You can also see this easily with the `git log` command. -If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. +Bu durumu `git log` komutuyla kolayca görebilirsiniz. +Eğer `git log --oneline --decorate --graph --all` komutunu çalıştırırsanız; katkı geçmişiniz, dal işaretçilerinin nereye baktığı ve geçmişinizin nasıl ayrıldığı ekranda yazacaktır. [source,console] ---- @@ -174,18 +174,19 @@ $ git log --oneline --decorate --graph --all * 98ca9 initial commit of my project ---- -Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. -Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). +Git'teki bir dal, aslında işaret ettiği katkının 40 karakterlik SHA-1 sağlamasını tutan basit bir dosya olduğu için, dalları oluşturmak ve yok etmek Git için çok kolaydır. +Yeni bir dal oluşturmak, bir dosyaya 41 bayt yazmak kadar hızlı ve basittir (40 karakter ve bir satırbaşı). -This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project's files into a second directory. -This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. -Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. -These features help encourage developers to create and use branches often. +Bu, yöntem olarak projenin tüm dosyalarını ikinci bir dizine yedeklemeyi seçen, çoğu eski VCS aracının kullandığı yolun kesin bir zıttıdır. +Yedekleme yöntemi, projenin boyutuna bağlı olarak birkaç saniye veya hatta dakika bile sürebilir. +Oysa Git'te katkı işlemi her zaman anlık olarak gerçekleşir. +Ayrıca, katkı işlerken öncel katkıları da kaydettiğimiz için, birleştirmek için uygun bir temel bulma işlemi otomatik olarak yapılır ve genellikle çok kolaydır. +Bu özellikler, geliştiricileri sık sık dallar oluşturmaları ve kullanmaları yönünde cesaretlendirir. -Let's see why you should do so. +Haydi, neden bunu yapmanız gerektiğini görelim. -[NOTE] -.Creating a new branch and switching to it at the same time +[NOT] +.Tek komutla dal oluşturmak ve o dala geçiş yapmak ==== -It's typical to create a new branch and want to switch to that new branch at the same time -- this can be done in one operation with `git checkout -b `. +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 `. ==== From 148f31d4383698b4b9f9e7da0c4140fb43eeb409 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 07:46:04 +0100 Subject: [PATCH 003/210] Update nutshell.asc fixing typos --- book/03-git-branching/sections/nutshell.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 5aebb27e..46a539b9 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -3,10 +3,10 @@ Git'in dallanma yöntemini gerçekten anlamak için bir adım geriye çekilip Git'in verileri nasıl sakladığını incelememiz gerekiyor. -<> bölümündün hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _anlık görüntü_ olarak saklar. +<> bölümünden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _anlık görüntü_ olarak saklar. Git, bir katkı işlediğinizde (commit), aşamalandırdığınız (stage) içeriğin anlık görüntüsünün işaretçisi (pointer: bir katkı veya ağacın yerini gösteren işaretçi) içeren bir katkı nesnesi (object) saklar. -Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve önceki katkı veya katkılara ilişkin işaretçileri içerir. İlk katkı (first commit) için sıfır; normal bir katkı için bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı içinse çoklu öncel katkı bulunur. +Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve öncel katkı veya katkılara ilişkin işaretçileri içerir. İlk katkı (first commit) için sıfır; normal bir katkı için bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı içinse çoklu öncel katkı bulunur. Bunu görselleştirmek için, üç dosya içeren bir dizine sahip olduğumuzu ve bunların hepsini aşamalandırıp (stage) katkı olarak işlediğinizi varsayalım. Dosyaları aşamalandırmak, her bir dosya için bir sağlama toplamı (checksum) hesaplar (<> bölümünde bahsettiğimiz SHA-1 karması), dosyanın bu sürümünü Git reposunda saklar (Git bunlara _blobs_ olarak atıfta bulunur)(Binary Large OBject: ikili geniş nesne), ve bu sağlama toplamını aşamalandırma alanına (stage) ekler: @@ -30,8 +30,8 @@ image::images/commit-and-tree.png[Bir katkı ve onun ağacı.] Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz (git commit), sonraki katkı, kendinden hemen önceki katkıya işaret eden bir işaretçiyi depolar. -.Katkı ve önceki katkılar -image::images/commits-and-parents.png[Katkı ve önceki katkılar.] +.Katkı ve öncel katkılar +image::images/commits-and-parents.png[Katkı ve öncel katkılar.] Git'teki bir dal, temel olarak üzerindeki katkılardan birinin hafif ve taşınabilir bir işaretçisidir. Git'te varsayılan dalın adı `master`dır (anadal). From 1cffc8f50922099b020139739a34a2e8d55bcccb Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 08:47:10 +0100 Subject: [PATCH 004/210] Update basic-branching-and-merging.asc Section Branching has been translated up to line:107 --- .../sections/basic-branching-and-merging.asc | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) 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 80ec83e1..c7626d8e 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,31 +1,31 @@ -=== Basic Branching and Merging +=== Basitçe Dallandırma ve Birleştirme -Let's go through a simple example of branching and merging with a workflow that you might use in the real world. -You'll follow these steps: +Şimdi gerçek dünyada kullanabileceğiniz bir iş akışıyla basit bir dallandırma ve birleştirme örneğini inceleyelim. +Bu adımları takip edeceksiniz: -. Do some work on a website. -. Create a branch for a new user story you're working on. -. Do some work in that branch. +. Bir web projesi üzerinde birşeyleri değiştirin. +. Üzerinde çalıştığınız kullanıcı hikayesi (user story) için yeni bir dal oluşturun. +. Bu dal üzerinde çalışın. -At this stage, you'll receive a call that another issue is critical and you need a hotfix. -You'll do the following: +Diyelim ki bu aşamada, başka bir sorunun daha kritik olduğuna ve acilen düzeltmeniz (hotfix) gerektiğine dair bir çağrı aldınız. +Şunları yapmanız gerekiyor: -. Switch to your production branch. -. Create a branch to add the hotfix. -. After it's tested, merge the hotfix branch, and push to production. -. Switch back to your original user story and continue working. +. Üretim (production) dalına geçin (Bu sizin canlı yayındaki dalınızdır, genellikle master veya main olarak adlandırılır). +. Onarım amaçlı yeni bir dal oluşturun. +. Düzgün çalıştığını test ettikten sonra onarım dalını üretim dalıyla birleştirin ve üretime gönderin (push). +. Asıl kullanıcı hikayenize geri dönün ve çalışmaya devam edin. [[_basic_branching]] -==== Basic Branching +==== Basitçe Dallandırma (((branches, basic workflow))) -First, let's say you're working on your project and have a couple of commits already on the `master` branch. +İlk olarak, projeniz üzerinde çalışıyorsunuz ve `master` dalında halihazırda birkaç katkınız var diyelim. -.A simple commit history -image::images/basic-branching-1.png[A simple commit history.] +.Basit bir katkı geçmişi +image::images/basic-branching-1.png[Basit bir katkı geçmişi.] -You've decided that you're going to work on issue #53 in whatever issue-tracking system your company uses. -To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: +#53 numaralı sorun (Ya da şirketinizin kullandığı iş takip sisteminde nasıl gösteriliyorsa) üzerinde çalışmaya karar verdiniz. +Yeni bir dal oluşturup aynı zamanda bu dala geçmek için `git checkout` komutunu `-b` bayrağı ile çalıştırabilirsiniz: [source,console] ---- @@ -33,7 +33,7 @@ $ git checkout -b iss53 Switched to a new branch "iss53" ---- -This is shorthand for: +Bu komut şunun kısa yoludur: [source,console] ---- @@ -41,11 +41,11 @@ $ git branch iss53 $ git checkout iss53 ---- -.Creating a new branch pointer -image::images/basic-branching-2.png[Creating a new branch pointer.] +.Yeni bir dal işaretçisi oluşturmak +image::images/basic-branching-2.png[Yeni bir dal işaretçisi oluşturmak.] -You work on your website and do some commits. -Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): +Web siteniz üzerinde çalışıyor ve bazı bazı katkılar işliyorsunuz. +Bu dala geçiş yapmış olduğunuz için (yani, `HEAD` artık onu işaret ediyor) katkı işlemek `iss53` dalını ileri taşır: [source,console] ---- @@ -53,17 +53,17 @@ $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' ---- -.The `iss53` branch has moved forward with your work -image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work.] +.`iss53` dalı siz çalıştıkça ilerler +image::images/basic-branching-3.png[`iss53` dalı siz çalıştıkça ilerler.] -Now you get the call that there is an issue with the website, and you need to fix it immediately. -With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. -All you have to do is switch back to your `master` branch. +Şimdi, web sitesinde bir sorun olduğu ve bunu derhal düzeltmeniz gerektiğine dair bir çağrı alıyorsunuz. +Git'te, ne yapmış olduğunuz `iss53` değişiklikleri ve onarımınızı birlikte yükleme zorunluluğunuz var, ne de bu değişiklikleri üretime uygulamadan önce geri almak için büyük çaba sarf etmenize. +Yapmanız gereken tek şey, `master` dalınıza geri dönmektir. -However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches. -It's best to have a clean working state when you switch branches. -There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <>. -For now, let's assume you've committed all your changes, so you can switch back to your `master` branch: +Ancak bunu yapmadan önce, çalışma dizininiz veya aşamalandırmada (stage) henüz katkılanmamış değişiklikler varsa ve bu değişiklikler, geçiş yapmak istediğiniz dal ile çakışıyorsa, Git'in sizin dal değiştirmenize izin vermeyeceğini bilmeniz lazım. +Dallar arasında geçiş yaparken temiz bir çalışma durumuna sahip olmak en iyisidir. +Bu sorunun etrafından dolaşmanın tabi ki belli (`stashing` ve `commit amending` gibi) yolları var ama bunları <> bölümünde ele alacağız. +Şu anda, tüm değişikliklerinizi katkıladığınızı varsayalım, böylece `master` dalına geri dönebilirsiniz: [source,console] ---- @@ -71,12 +71,12 @@ $ git checkout master Switched to branch 'master' ---- -At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. -This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. -It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. +Bu aşamada, projenizin çalışma dizini, #53 sorunu üzerinde çalışmaya başlamadan önceki haline tam olarak geri dönmüş durumda ve şimdi onarımınıza odaklanabilirsiniz. +Çok önemli bir hatırlatma!: Dallar arasında geçiş yaptığınızda, Git çalışma dizininizi o dala en son katkı işlediğiniz anda olduğu gibi ayarlar. +Çalışma kopyanızı, dal üzerindeki son katkıladığınız gibi görünmesi için otomatik olarak dosya ekler, kaldırır ve değiştirir. -Next, you have a hotfix to make. -Let's create a `hotfix` branch on which to work until it's completed: +Şimdi, bir onarım yapmanız gerekiyor. +Sorunu düzeltene kadar üzerinde değişiklikler yapabileceğimiz `hotfix` adında bir dal oluşturalım: [source,console] ---- @@ -88,11 +88,11 @@ $ git commit -a -m 'fixed the broken email address' 1 file changed, 2 insertions(+) ---- -.Hotfix branch based on `master` -image::images/basic-branching-4.png[Hotfix branch based on `master`.] +.`master` üzerinden oluşturulmuş `hotfix` dalı +image::images/basic-branching-4.png[`master` üzerinden oluşturulmuş `hotfix` dalı.] -You can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production. -You do this with the `git merge` command:(((git commands, merge))) +Testlerinizi çalıştırabilir, düzeltmenin istediğiniz gibi çalıştığından emin olabilir ve son olarak `hotfix` dalınızı `master` dalınıza birleştirerek üretime alabilirsiniz. +Bunu `git merge` komutuyla yaparsınız:(((git commands, merge))) [source,console] ---- From b9921cb418bcf78ef83020facd408468eda67c1e Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:21:36 +0100 Subject: [PATCH 005/210] Update getting-a-repository.asc 02-basics-01 translated --- .../sections/getting-a-repository.asc | 75 ++++++++++--------- 1 file changed, 41 insertions(+), 34 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index ea7a21ca..91ff7654 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,47 +1,54 @@ +Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu bölüm aradığınız kısı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. +Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi aşamalandırıp (stage'e alıp) 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ı, "commit"ler 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. + + [[_getting_a_repo]] -=== Getting a Git Repository +=== Bir Git Reposu Oluşturma/Kopyalama -You typically obtain a Git repository in one of two ways: +Tipik olarak bir Git reposu oluşturmanın 2 yolu vardır: -1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or -2. You can _clone_ an existing Git repository from elsewhere. +1. Şu anda versiyon kontrolü altında olmayan bir yerel dizini (dosya yolu) alabilir ve onu bir Git reposuna dönüştürebilirsiniz. +Veya +2. Başka bir yerden var olan bir Git reposunu klonlayabilirsiniz. -In either case, you end up with a Git repository on your local machine, ready for work. +Her iki durumda da, yerel makinenizde çalışmaya hazır bir Git reposuna sahip olursunuz. -==== Initializing a Repository in an Existing Directory +==== Varolan Bir Dizinde Repo Başlatma -If you have a project directory that is currently not under version control and you want to start controlling it with Git, you first need to go to that project's directory. -If you've never done this, it looks a little different depending on which system you're running: +Eğer şu anda versiyon kontrolü altında olmayan bir proje diziniz var ve onu Git ile kontrol etmeye başlamak istiyorsanız, önce o projenin dizinine gitmeniz gerekmektedir. +Eğer bunu daha önce yapmadıysanız, hangi işletim sisteminde çalıştığınıza bağlı olarak proje dizininiz farklı görünebilir. -for Linux: +Linux için: [source,console] ---- $ cd /home/user/my_project ---- -for macOS: +macOS için: [source,console] ---- $ cd /Users/user/my_project ---- -for Windows: +Windows için: [source,console] ---- $ cd /c/user/my_project ---- -and type: +Proje dizinine girdikten sonra şunu yazın: [source,console] ---- $ git init ---- -This creates a new subdirectory named `.git` that contains all of your necessary repository files -- a Git repository skeleton. -At this point, nothing in your project is tracked yet. -(See <> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) +Bu, tüm gerekli repo dosyalarını içeren `.git` adında yeni bir alt dizin oluşturur. Yani bir Git repo temeli. +Bu aşamada, projenizde henüz takip edilen bir şey yoktur. +(Yeni oluşturduğunuz `.git` dizininde hangi dosyaların bulunduğuna dair daha fazla bilgi edinmek için <> bölümüne bakabilirsiniz.)(((git commands, init))) -If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. -You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`: +Eğer halihazırda mevcut olan dosyaları versiyon kontrolüne almak istiyorsanız, boş bir dizin yerine, bu hazır dosyaları takip etmeye başlamalı ve bir 'initial commit' (ilk commit) yapmalısınız. +Bunu, takip etmek istediğiniz dosyaları belirten birkaç `git add` komutu ve ardından bir `git commit` komutu ile başarabilirsiniz: [source,console] ---- @@ -50,38 +57,38 @@ $ git add LICENSE $ git commit -m 'initial project version' ---- -We'll go over what these commands do in just a minute. -At this point, you have a Git repository with tracked files and an initial commit. +Bu komutların ne yaptığını birazdan inceleyeceğiz. +Bu aşamada, takip edilen dosyaları içeren bir Git reponuz ve başlangıç 'initial commit'iniz vardır. [[_git_cloning]] -==== Cloning an Existing Repository +==== Mevcut bir Git Reposunu Klonlama (Kopyalama) -If you want to get a copy of an existing Git repository -- for example, a project you'd like to contribute to -- the command you need is `git clone`. -If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". -This is an important distinction -- instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. -Every version of every file for the history of the project is pulled down by default when you run `git clone`. -In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there -- see <> for more details). +Mevcut bir Git deposunun (örneğin katkıda bulunmak istediğiniz bir projenin) bir kopyasını almak istiyorsanız `git clone` komutunu kullanmalısınız. +Eğer Subversion veya benzeri diğer VCS sistemlerine aşina iseniz, "checkout" yerine "clone" komutu kullanıldığını fark edeceksiniz. +Bu önemli bir ayrımdır! Zira Git, yalnızca çalışan bir kopya almak yerine, sunucunun sahip olduğu neredeyse tüm verilerin tam bir kopyasını alır. +`git clone` komutunu çalıştırdığınızda, projenin tarihindeki her dosyanın her sürümü varsayılan olarak indirilir. +Aslında, sunucu diskiniz bozulursa, sunucuyu klonlandığı zamanki durumuna geri döndürmek için genellikle herhangi bir istemcideki klonların neredeyse tümünü kullanabilirsiniz (bazı sunucu tarafı kancalarını vb. kaybedebilirsiniz, ancak sürümlendirilmiş tüm verilere sahip olacaksınız. Daha fazla ayrıntı için: <>). -You clone a repository with `git clone `.(((git commands, clone))) -For example, if you want to clone the Git linkable library called `libgit2`, you can do so like this: +Bir repoyu `git clone ` komutu ile klonlayabilirsiniz.(((git commands, clone))) +Örneğin, "libgit2" adlı Git'e bağlanabilir kitaplığı kopyalamak istiyorsanız bunu şu şekilde yapabilirsiniz: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -That creates a directory named `libgit2`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. -If you go into the new `libgit2` directory that was just created, you'll see the project files in there, ready to be worked on or used. +Bu, içinde bir '.git' dizini olan 'libgit2' adında bir dizin oluşturur; bu repoya ait tüm verileri çeker ve ve en son sürümün çalışan bir kopyasını alır. +Yeni oluşturulan `libgit2` dizinine giderseniz, orada üzerinde çalışılmaya veya kullanılmaya hazır proje dosyalarını görebilirsiniz. -If you want to clone the repository into a directory named something other than `libgit2`, you can specify the new directory name as an additional argument: +Depoyu 'libgit2' dışında bir isimle adlandırılan bir dizine kopyalamak istiyorsanız, yeni dizin adını ek bir argüman olarak belirtebilirsiniz: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 mylibgit ---- -That command does the same thing as the previous one, but the target directory is called `mylibgit`. +Bu komut öncekiyle aynı şeyi yapar, ancak hedef dizine `mylibgit` adını verir. -Git has a number of different transfer protocols you can use. -The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. -<> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +Git'te kullanabileceğiniz bir dizi farklı aktarım protokolü vardır. +Önceki örnekte `https://` protokolü kullanılmıştır ancak `git://` veya SSH aktarım protokolünü kullanan `user@server:path/to/repo.git` ifadelerini de görebilirsiniz. +<> bölümünde sunucunun Git reponuza erişmek için ayarlayabileceği mevcut tüm seçenekleri ve her birinin artılarını ve eksilerini göreceksiniz. From 31a36681fc95177446b8062668b83c2127ab8a1c Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:27:49 +0100 Subject: [PATCH 006/210] Update recording-changes.asc 02-basics-02 translated --- .../sections/recording-changes.asc | 356 +++++++++--------- 1 file changed, 180 insertions(+), 176 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index d6b30b74..ffeea2af 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,26 @@ -=== Recording Changes to the Repository +=== Değişikliklerin Repoya Kaydedilmesi -At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. -Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. +Şu aşamada, yerel makinenizde bir Git reposuna ve önünüzde tüm dosyaları kullanıma hazır veya çalışmakta olan bir kopyasına sahip olmalısınız. +Doğal olarak, proje kaydetmek istediğiniz duruma her ulaştığında değişiklik yapmaya ve bu değişikliklerin anlık görüntülerini reponuza kaydetmeye başlamak isteyeceksiniz. -Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -In short, tracked files are files that Git knows about. +Çalışma dizininizdeki her dosyanın iki durumdan birinde olabileceğini unutmayın: "tracked" (izlenen / takip edilen) veya "untracked" (izlenmeyen / takip edilmeyen). +İzlenen dosyalar, son anlık görüntüdeki (snapshot) dosyalardır: bunlar "modified" (değiştirilmiş), "unmodified" (değiştirilmemiş) veya "staged" (hazırlanmış) olabilirler. +Kısacası izlenen dosyalar Git'in haberdar olduğu ve değişikliklerini takip ettiği dosyalardır. -Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. +İzlenmeyen dosyalar ise diğer her şeydir; çalışma dizininizdeki, son anlık görüntünüzde olmayan ve hazırlama alanınızda (staging area) olmayan dosyalardır. +Bir repoyu ilk kez klonladığınızda, tüm dosyalarınız izlenecek ve "unmodified" (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız. -As you edit files, Git sees them as modified, because you've changed them since your last commit. -As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. +Siz dosyaları düzenlerken Git onları "modified" (değiştirilmiş) olarak görür, çünkü son Git işleminizden (commit, clone, push, vs) sonra bu dosyalarda değişiklik yaptınız. +Çalışırken, bu değiştirilmiş dosyaları seçerek "stage"e alırsınız (commit için hazırlarsınız) ve ardından "stage"e alınmış tüm bu değişiklikleri "commit" edersiniz. Ve döngü her değişiklikten sonra tekrarlanır. -.The lifecycle of the status of your files. +.Dosyalarınızın durumunun yaşam döngüsü. image::images/lifecycle.png[The lifecycle of the status of your files.] [[_checking_status]] -==== Checking the Status of Your Files +==== Dosyalarınızın Durumunu Kontrol Etme -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +Hangi dosyaların hangi durumda olduğunu görmek için `git status` komutu kullanırız. (((git commands, status))) +Bu komutu bir projeyi klonladıktan hemen sonra çalıştırırsanız şöyle bir şey görmelisiniz: [source,console] ---- @@ -30,14 +30,14 @@ Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- -This means you have a clean working directory; in other words, none of your tracked files are modified. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<> will go over branches and references in detail. +Bu, temiz bir çalışma dizininiz olduğu anlamına gelir; bir başka deyişle, izlenen dosyalarınızın hiçbirinde henüz bir değişiklik yok. +Git ayrıca izlenmeyen (untracked) dosyaları görmez; aksi halde onlar da burada listelenirdi. +Son olarak bu komut size hangi projenin hangi dalında (branch) olduğunuzu söyler ve sunucuda klonladığınız daldan ayrılmadığınızı bildirir. +Şimdilik bu dal her zaman varsayılan olan ``master`` yani "ana dal"dır. Bunda endişelenmenizi gerektirecek bir durum yoktur. +<> ünitesinde dalları ve referansları ayrıntılı olarak göreceksiniz. -Let's say you add a new file to your project, a simple `README` file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: +Diyelim ki projenize yeni bir dosya, mesela basit bir `README` (BENİ OKU) dosyası eklediniz. +Dosya daha önce mevcut değilse ve `git status` komutunu çalıştırırsanız izlenmeyen dosyanızı şu şekilde görürsünüz: [source,console] ---- @@ -46,30 +46,30 @@ $ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: - (use "git add ..." to include in what will be committed) + (use "git add ..." to include in what will be committed) README -nothing added to commit but untracked files present (use "git add" to track) +Henüz "commit" edilmek üzere hiçbir şey eklenmedi fakat izlenmeyen (untracked) yeni bir dosya var. (bu dosyayı izlemek için ``git add`` komutu kullanın) ---- -You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including `README`, so let's start tracking the file. +Yeni `README` dosyanızın izlenmediğini görebilirsiniz çünkü durum çıktınızda (git status) ``Untracked files`` (İzlenmeyen dosyalar) başlığı altındadır. +"İzlenmeyen" (untracked) temel olarak Git'in önceki anlık görüntüde sahip olmadığınız bir dosyayı gördüğü anlamına gelir. Siz bunu yapmasını ``git commit`` komutuyla açıkça söyleyene kadar Git bunu "commit" görüntülerinize dahil etmeyecektir. +Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "binary" dosyaları veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. +`README`yi dahil etmeye başlamak istiyorsanız, o halde dosyayı izlemeye başlayalım. [[_tracking_files]] -==== Tracking New Files +==== Yeni Dosyaları İzleme -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the `README` file, you can run this: +Yeni bir dosyayı izlemeye başlamak için `git add` komutu kullanılır.(((git commands, add))) +`README` dosyasını izlemeye başlamak için şu komutu çalıştırabilirsiniz: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: +Durum komutunuzu (git status) tekrar çalıştırırsanız, `README` dosyanızın artık izlendiğini (tracked) ve kaydedilmek üzere hazırlandığını (Staging) görebilirsiniz: [source,console] ---- @@ -83,15 +83,15 @@ Changes to be committed: ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +``Changes to be committed`` başlığı altında yer aldığından "stage" aşamasında olduğunu anlayabilirsiniz. +Bu noktada "commit" yaparsanız, dosyanın `git add`i çalıştırdığınız andaki sürümü, "commit" geçmişinize yeni bir "commit" olarak işlenecektir. +Daha önce `git init` komutunu çalıştırdığınızda, hemen ardından `git add ` komutunu çalıştırdınız; bunun amacı dizininizdeki dosyaları izlemeye başlamaktı.(((git commands, init)))(((git commands, add))) +`git add` komutu, bir dosya veya dizin için bir yol adı alır; eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları "stage"e ekler. -==== Staging Modified Files +==== Değiştirilmiş Dosyaları "stage"e alma -Let's change a file that was already tracked. -If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: +Şimdi izlenmekte (tracked) olan bir dosyayı değiştirelim. +Eğer izlenmnekte olan `CONTRIBUTING.md` adlı dosyayı değiştirir ve ardından `git status` komutunu tekrar çalıştırırsanız, şöyle bir sonuç elde edersiniz: [source,console] ---- @@ -111,11 +111,11 @@ Changes not staged for commit: ---- -The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. -`git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. -It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: +`CONTRIBUTING.md` dosyası, ``Changes not staged for commit`` adlı bir bölümün altında görünür. Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği ancak henüz "stage"e alınmadığı anlamına gelir. +"stage"e almak için `git add` komutunu çalıştırmalısınız. +`git add` çok amaçlı bir komuttur: yeni dosyaları izlemeye başlamak, dosyaları "stage"e almak (commit için hazırlamak) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyleri yapmak için de kullanırsınız. +Bunu, "bu dosyayı projeye ekle" yerine "bu içeriği bir sonraki işleme ekle" olarak düşünmek daha faydalı olabilir.(((git commands, add))) +Şimdi `CONTRIBUTING.md` dosyasını "stage"e almak için `git add` komutunu çalıştıralım ve ardından `git status` komutunu bir kez daha çalıştıralım: [source,console] ---- @@ -131,10 +131,10 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +Her iki dosya da "stage"dedir ve bir sonraki işleminize aktarılacaktır. +Bu noktada, varsayalım ki `CONTRIBUTING.md`de yapmak istediğiniz küçük bir değişikliği hatırladınız. +Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi "commit" etmeye hazırsınız. +Şimdi `git status` komutunu bir kez daha çalıştıralım: [source,console] ---- @@ -156,12 +156,12 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +Bu da ne? +Artık `CONTRIBUTING.md` hem "staged" hem de "unstaged" olarak listelenmiş. +Bu nasıl olabilir? +Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi "stage"e aktardığını görüyorsunuz. +Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md`nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki versiyonu kayıt işlemine girecektir. +`git add`i çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü hazırlamak için `git add`i tekrar çalıştırmanız gerekir: [source,console] ---- @@ -176,11 +176,11 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== Kısa Durum (Status) Bilgisi -While the `git status` output is pretty comprehensive, it's also quite wordy. -Git also has a short status flag so you can see your changes in a more compact way. -If you run `git status -s` or `git status --short` you get a far more simplified output from the command: +`git status` çıktısı oldukça kapsamlı ve aynı zamanda da uzundur. +Git'te ayrıca kısa bir durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. +Eğer `git status -s` veya `git status --short` komutunu çalıştırırsanız, çok daha basitleştirilmiş bir çıktı elde edersiniz: [source,console] ---- @@ -192,18 +192,18 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. -There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. -So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. -The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +İzlenmeyen yeni dosyaların yanında `??`, "stage" alanına eklenen yeni dosyaların yanında `A` (added), değiştirilen dosyaların yanında ise `M` (modified) bulunur. +Çıktıda iki sütun vardır; soldaki sütun "stage" alanının durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. +Örneğin bu çıktıda, `README` dosyası çalışma dizininde değiştirilmiş ancak henüz "stage"e alınmamıştır. `lib/simplegit.rb` dosyası ise değiştirilmiş ve "stage"e alınmıştır. +`Rakefile` değiştirildi (modified), hazırlandı (stage'e alındı) ve tekrar değiştirildi, dolayısıyla üzerinde hem "staged" hem de "unstaged" değişiklikler var. [[_ignoring]] -==== Ignoring Files +==== Dosyaları Yoksayma (Ignore) -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +Sıklıkla Git'in otomatik olarak eklemesini veya izlemesini istemediğiniz bazı dosyalara sahip olursunuz. +Bunlar genellikle kayıt dosyaları gibi derleme sisteminiz tarafından otomatik olarak oluşturulan dosyalardır. +Bu gibi durumlarda, bunlarla eşleşecek şekilde `.gitignore` adlı bir dosya listeleme modeli oluşturabilirsiniz.(((ignoring files))) +Örnek bir `.gitignore` dosyası: [source,console] ---- @@ -212,71 +212,74 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. -The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı ``.o`` veya ``.a`` ile biten (object ve archive) tüm dosyaları yoksaymasını söyler. +İkinci satır Git'e, adları tilde (`~`) ile biten tüm dosyaları yok saymasını söyler; bu, Emacs gibi birçok metin düzenleyicisi tarafından geçici dosyaları işaretlemek için kullanılır. +Ayrıca otomatik olarak oluşturulan log (kayıt), tmp (geçici) veya pid (işlem kimliği) vb dizinleri de ekleyebilirsiniz. +Başlamadan önce yeni reponuz için bir `.gitignore` dosyası oluşturmak genellikle iyi bir fikirdir. Böylece Git reponuzda görmek istemediğiniz dosyaları yanlışlıkla "commit" etmezsiniz. -The rules for the patterns you can put in the `.gitignore` file are as follows: +`.gitignore` dosyasını yazarken göz önünde bulundurmanız gereken kurallar aşağıdaki gibidir: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work, and will be applied recursively throughout the entire working tree. -* You can start patterns with a forward slash (`/`) to avoid recursivity. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* Boş satırlar veya `#` ile başlayan satırlar dikkate alınmaz. +* Standart glob desenleri işler. Yani yazdığınız kural çalışma ağacınızdaki tüm dosyalar için alt dizinleri de dahil olmak üzere geçerlidir. +* Bu alt dizinlere inen yinelemeyi önlemek için dosya dizinine eğik çizgi (`/`) ile başlayabilirsiniz. +* Kuralın geçerli olmasını istediğimiz sadece belli bir dizini belirtmek için dosya dizinini eğik çizgiyle (`/`) sonlandırabilirsiniz. +* Kuralın uygulanmasını istemediğiniz bir modeli ünlem işaretiyle (`!`) başlatarak reddedebilirsiniz. -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +Glob desenleri, "shell"in kullandığı "RegEx" ifadelerine benzer: +Yıldız işareti (`*`) sıfır veya daha fazla karakterle eşleşir, +`[abc]` parantez içindeki herhangi bir karakterle eşleşir (bu örnekte a, b veya c), +Soru işareti (`?`) tek bir karakterle eşleşir, +Ve kısa çizgiyle (`[0-9]`) ayrılmış karakterleri çevreleyen parantezler bu aralıkta yer alan herhangi bir karakterle (bu örnekte 0'dan 9'a kadar rakamlarla) eşleşir, +İç içe geçmiş dizinleri eşleştirmek için iki yıldız işareti de kullanabilirsiniz; `a/**/z` ifadesi, `a/z`, `a/b/z`, `a/b/c/z`, vb. ile eşleşir. -Here is another example `.gitignore` file: +İşte size örnek bir `.gitignore` dosyası: [source] ---- -# ignore all .a files +# .a uzantılı tüm dosyaları yoksay *.a -# but do track lib.a, even though you're ignoring .a files above +# b.a uzantılı tüm dosyaları yoksaysan da, lib.a dosyası bu kuralın istisnasıdır. lib.a dosyasındaki değişiklikleri izle !lib.a -# only ignore the TODO file in the current directory, not subdir/TODO +# Sadece bu dizindeki TODO dosyasını yoksay. Diğer dizinlerdeki TODO dosyalarını değil. (ör: subdir/TODO) /TODO -# ignore all files in any directory named build +# build dizinindeki ve onun alt dizinlrindeki tüm dosyaları yoksay build/ -# ignore doc/notes.txt, but not doc/server/arch.txt +# doc/notes.txt dosyasını yoksay ama doc/server/arch.txt dosyasını değil doc/*.txt -# ignore all .pdf files in the doc/ directory and any of its subdirectories +# doc/ klasörü ve alt klasörlerinde yer alan tüm .pdf dosyalarını yoksay doc/**/*.pdf ---- -[TIP] +[İPUCU] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +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. ==== -[NOTE] +[NOT] ==== -In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. -However, it is also possible to have additional `.gitignore` files in subdirectories. -The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. -(The Linux kernel source repository has 206 `.gitignore` files.) +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. +Bu iç içe geçmiş `.gitignore` dosyalarındaki kurallar yalnızca bulundukları dizinin alt klasörlerinde bulunan dosyalar için geçerlidir. +(Örneğin Linux çekirdeği kaynak reposunda 206 adet `.gitignore` dosyası bulunmaktadır.) -It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. +Birden fazla ".gitignore" dosyası bulunduğu durumlar bu kitabın kapsamı dışındadır. Bu konuda daha detaylı bilgiye konsol ekranınıza "man gitignore" komutu yazarak ulaşabilirsiniz. ==== [[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +==== "Staged" ve "Unstaged" Değişiklikleri Görme -If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed -- the patch, as it were. +`git status` komutu sizin için yeterince bilgi içermiyorsa (sadece hangi dosyaların değiştirildiğini değil, tam olarak neyi değiştirdiğinizi de bilmek istiyorsanız), bunun yerine `git diff` komutunu kullanabilirsiniz.(((git commands, diff))) +`git diff`i daha sonra daha ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç duyacaksınız: Neyi değiştirdiniz ama henüz "stage"e almadınız? +Neyi "stage"e aldınız fakat henüz "commit" etmediniz? +Her ne kadar `git status` bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da, `git diff` size eklenen ve kaldırılan satırları değiştirilen her bir kod parçasıyla birlikte detaylıca gösterir. -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +Diyelim ki `README` dosyasını tekrar değiştirip "stage"e alıyorsunuz ve ardından `CONTRIBUTING.md` dosyasını "stage"e almadan düzenliyorsunuz. +`git status` komutunuzu çalıştırırsanız bir kez daha şöyle bir şey görürsünüz: [source,console] ---- @@ -295,7 +298,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -To see what you've changed but not yet staged, type `git diff` with no other arguments: +Neyi değiştirdiğinizi ancak henüz "stage"e almadığınızı görmek için herhangi bir argüman kullanmadan `git diff' yazın: [source,console] ---- @@ -316,11 +319,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +Bu komut, çalışma dizininizdeki güncel kodu, "stage" alanınızdaki kodla karşılaştırır. +Sonuç size, henüz gerçekleştirmediğiniz değişiklikleri görme imkanı tanır. -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +Eğer bir sonraki "commit" işleminizde nelerin kaydedileceğini görmek istiyorsanız ``git diff --staged`` komutunu kullanabilirsiniz. +Bu komut, "stage" deki değişikliklerinizi, en son "commit" ettiğiniz kodla karşılaştırır: [source,console] ---- @@ -334,11 +337,11 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. -If you've staged all of your changes, `git diff` will give you no output. +`git diff` komutunun son "commit" işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz "stage"e alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. +Eğer tüm değişikliklerinizi "stage"e aldıysanız, `git diff` size hiçbir çıktı vermeyecektir. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. -If our environment looks like this: +Bir başka örnek olarak, `CONTRIBUTING.md` dosyasını "stage"e alır ve ardından yeniden düzenlerseniz, dosyadaki "staged" ve "unstaged" değişiklikleri görmek için `git diff` komutunu kullanabilirsiniz. +Ortamımız şöyle görünüyorsa: [source,console] ---- @@ -359,7 +362,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged: +Artık neyin "unstaged" olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: [source,console] ---- @@ -375,7 +378,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): +veya şu ana kadar neleri "stage"e aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: [source,console] ---- @@ -396,33 +399,33 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -[NOTE] -.Git Diff in an External Tool +[NOT] +Harici Araçlarda .Git Diff ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. -There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. -If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). -Run `git difftool --tool-help` to see what is available on your system. +Kitabın geri kalanında `git diff` komutunu çeşitli şekillerde kullanmaya devam edeceğiz. +Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine grafiksel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka bir yolu daha vardır. +Eğer `git diff` yerine `git difftool` komutu çalıştırırsanız, bu farklardan herhangi birini "emerge", "vimdiff" ve daha birçok farklı yazılımda (ticari yazılımlar dahil) görüntüleyebilirsiniz. +Sisteminizde hangilerinin mevcut olduğunu görmek için `git difftool --tool-help` komutunu çalıştırabilirsiniz. ==== [[_committing_changes]] -==== Committing Your Changes +==== Değişiklikleri "commit" olarak kaydetmek -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) +Artık "stage" alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi "commit" olarak kaydedebilirsiniz. +"unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç `git add` komutuyla "stage"e almadığınız dosyalar) bu işlemle "commit" geçmişine/listesine kaydedilmeyeceğini aklınızdan çıkarmayın. +Bu dosyalar diskinizde "modified" (değiştirilmiş) işaretli olarak kalacaklar. +Bu durumda, eğer bir kez daha `git status` komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğun görürseniz, artık değişikliklerinizi "commit" olarak kaydetmeye hazırsınız demektir.(((git commands, status))) +Değişikliklerinizi "commit" etmenin en basit yolu `git commit` komutunuzu çalıştırmaktır:(((git commands, commit))) [source,console] ---- $ git commit ---- -Doing so launches your editor of choice. -(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>).(((editor, changing default)))(((git commands, config))) +Bunu yaptığınızda seçili derleyiciniz başlatılır. +(Bu sizin shell'inizin `EDITOR` ortam değişkeni tarafından ayarlanmıştır. (Genellikle "vim" veya "emacs"tır, ancak <> ünitesinde gördüğünüz gibi `git config --global core.editor` komutunu kullanarak bunu istediğiniz şekilde yapılandırabilirsiniz.).(((editor, changing default)))(((git commands, config))) -The editor displays the following text (this example is a Vim screen): +Ekranda aşağıdaki metni göreceksiniz (bu örnek bir Vim ekranıdır): [source] ---- @@ -442,13 +445,13 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +Varsayılan "commit" mesajının, yorumlanan `git status` komutunun en son çıktısını ve üstte bir boş satırı içerdiğini görebilirsiniz. +Bu yorumları kaldırabilir ve "commit" mesajınızı yazabilir veya neyi "commit" ettiğinizi hatırlamanıza yardımcı olması için orada bırakabilirsiniz. +(Neyi değiştirdiğinizi daha da açık bir şekilde hatırlatmak için, `git commit` komutuna `-v` bayrağı ekleyebilirsiniz. +Böylece yaptığınız değişikliği (diff) da derleyicinize eklemiş olursunuz ve ileride tam olarak hangi değişiklikleri yaptığınızı görebilirsiniz.) +Derleyicinizden çıktığınızda, Git bu mesajla birlikte (yorumlar ve değişiklikler çıkarılmış olarak) commit kaydınızı oluşturur. -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: +Alternatif olarak, `-m` (message) bayrağı kullanarak "commit" mesajınızı `commit` komutuyla aynı satırda yazabilirsiniz: [source,console] ---- @@ -458,19 +461,19 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +Tebrikler artık ilk "commit" kaydınızı oluşturdunuz! +Bu "commit" kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz: değişiklikleri hangi dala (`master`) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (gelecekte bir "commit"e geri dönmek istediğinizde tam olarak hangi "commit"e dönmek istediğinizi belirtebilmeniz içih her bir "commit"inizin kendine özel bir SHA-1 kodu bulunur. Bu bir nevi kaydınızın kimlik numarası gibidir.) sahip olduğu ('463dc4f'), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır. -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +"commit" kayıtlarınızın, "stage" alanınıza yüklediğiniz codun anlık görüntüsü olduğunu unutmayın. +"stage"e almadığınız her şey dosya ve kod hala orada değiştirilmiş halde duruyor; bunları "commit" geçmişinize eklemek için başka bir "commit" işleminde bulunabilirsiniz. +Aslında her "commit" gerçekleştirdiğinizde, projenizin daha sonra geri dönebileceğiniz veya karşılaştırabileceğiniz bir anlık görüntüsünü kaydetmiş oluyorsunuz. -==== Skipping the Staging Area +==== "Stage" Alanını Atlamak (((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +"stage" alanı "commit"lerinizin tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. +"stage" alanını atlamak istiyorsanız Git basit bir kısayol sağlar. +`git commit` komutuna `-a` (add) seçeneğinin eklenmesi, Git'in zaten izlenen her dosyayı taahhütte bulunmadan önce otomatik olarak "stage"e almasını sağlar ve `git add` kısmını atlamanıza olanak tanır: [source,console] ---- @@ -489,18 +492,19 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. -That's because the `-a` flag includes all changed files. -This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. +Bu durumda "commit" yapmadan önce `CONTRIBUTING.md` dosyasında `git add` komutunu çalıştırmanız gerekmediğine dikkat edin. +Bunun nedeni `-a` bayrağının değiştirilen tüm dosyaları içermesidir. +Bunu yapmakta herhangi bir sorun yoktur ancak dikkatli olun; bazen bu bayrak istenmeyen değişiklikleri de "commit"inize eklemenize neden olur. [[_removing_files]] -==== Removing Files +==== Dosyaları Silmek (((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. +Git'ten bir dosyayı kaldırmak için, onu izlenen dosyalar listenizden (yani "stage"den) kaldırmanız ve ardından bu değişikliği kaydetmeniz ("commit" etmeniz) gerekir. +`git rm` komutu seçtiğiniz dosyayı hem "stage" alanından hem de çalışma dizininizden kaldırır. Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. +Eğer dosyayı silmek yerine sadece takipten çıkarmak istiyorsanız dosya yolunu ve adını `.gitignore` dosyasına kaydetmelisiniz. -If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: +Dosyayı sadece çalışma dizininizden kaldırırsanız, dosyanızı `git status` çıktınızın ``Changes not staged for commit`` (yani _unstaged_) alanında görebilirsiniz: [source,console] ---- @@ -517,7 +521,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +Daha sonra, eğer `git rm` komutunu çalıştırırsanız, dosyanın kaldırılması işlemini "stage" alanına almış olursunuz: [source,console] ---- @@ -532,58 +536,58 @@ Changes to be committed: deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +Bir sonraki "commit" işleminizde dosya kaybolacak ve artık izlenmeyecektir. +Dosyayı değiştirdiyseniz veya "stage" alanına zaten eklediyseniz, Git'i kaldırma işlemine zorlamak için `-f` (forced) seçeneğini kullanmalısınız. +Bu, henüz anlık görüntüye kaydedilmemiş ve Git'ten kurtarılamayan verilerin yanlışlıkla kaldırılmasını önleyen bir güvenlik özelliğidir. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak "stage" alanınızdan kaldırmaktır. +Başka bir deyişle, dosyayı sabit diskinizde tutmak ancak Git'in artık onu izlememesini sağlamak istemeyebilirsiniz. +Eğer `.gitignore` dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla "stage"e aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş `.a` dosyaları gibi) bu özellik oldukça işinize yarayacaktır. +Bunu yapmak için `--cached` seçeneğini kullanın: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as: +Dosyaları, dizinleri ve dosya glob kalıplarını `git rm` komutuna aktarabilirsiniz. +Bu, aşağıdaki gibi şeyler yapabileceğiniz anlamına gelir: [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +`*` işaretinin önündeki ters eğik çizgiye (`\`) dikkat edin. +Bu özellikle gereklidir; çünkü Git, "shell"inizin dosya adı genişletmesine ek olarak, kendi dosya adı genişletmesini de yapar. +Bu komut, `log/` dizinindeki `.log` uzantısına sahip tüm dosyaları kaldırır. +Veya şöyle bir şey de yapabilirsiniz: [source,console] ---- $ git rm \*~ ---- -This command removes all files whose names end with a `~`. +Bu komut, adları `~` ile biten tüm dosyaları kaldırır. [[_git_mv]] -==== Moving Files +==== Dosyaları Taşıma (((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. +Diğer birçok VCS sisteminin aksine Git, dosya hareketlerini açıkça izlemez. +Bir dosyayı yeniden adlandırırsanız, Git'te dosyayı yeniden adlandırdığınızı bildiren hiçbir meta veri depolanmaz. +Ancak Git bu sorunu olaydan sonra çözme konusunda oldukça akıllıdır. Dosya hareketini tespit etme konusunu birazdan ele alacağız. -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like: +Bu nedenle Git'in bir `mv` komutuna sahip olması biraz kafa karıştırıcıdır. +Git'te bir dosyayı yeniden adlandırmak istiyorsanız şöyle bir komut çalıştırabilirsiniz: [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +Bu komut gayet iyi bir şekilde çalışıyor. +Aslında, böyle bir şeyi çalıştırıp duruma bakarsanız Git'in bunu yeniden adlandırılmış bir dosya olarak değerlendirdiğini görürsünüz: [source,console] ---- @@ -597,7 +601,7 @@ Changes to be committed: renamed: README.md -> README ---- -However, this is equivalent to running something like this: +Ancak bu, şunun gibi bir şeyi çalıştırmaya eşdeğerdir: [source,console] ---- @@ -606,6 +610,6 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `git mv` is one command instead of three -- it's a convenience function. -More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Git bunun dolaylı olarak bir yeniden adlandırma olduğunu anlar, dolayısıyla bir dosyayı bu şekilde veya `mv` komutuyla yeniden adlandırmanız önemli değildir. +Tek dikkate değen fark, `git mv` komutunun üç yerine tek bir komut olmasıdır; bu da bize kolaylık sağlar. +Daha da önemlisi, bir dosyayı yeniden adlandırmak için istediğiniz herhangi bir aracı kullanabilir ve ardından add/rm ile adresleyerek dosyayı "commit" edilmeye uygun hale getirebiliriz. From 365f3b87519a828d5cf1be8fa594a1f2701bfbe3 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:28:52 +0100 Subject: [PATCH 007/210] Update viewing-history.asc 02-basics-03 translated --- .../sections/viewing-history.asc | 201 +++++++++--------- 1 file changed, 101 insertions(+), 100 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 373cc128..908a15ad 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ [[_viewing_history]] -=== Viewing the Commit History +=== Commit Geçmişini Görüntüleme -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. +Birkaç "commit" oluşturduktan veya halihazırda "commit" geçmişine sahip bir repoyu klonladıktan sonra muhtemelen neler olup bittiğini görmek için kod geçmişine bakmak isteyeceksiniz. +Bunu yapmanın en temel ve güçlü aracı `git log` komutudur. -These examples use a very simple project called ``simplegit''. -To get the project, run +Bu örneklerde ``simplegit`` adı verilen çok basit bir proje kullanılmaktadır. +Projenin bir kopyasını elde etmek için aşağıdaki komutu çalıştırın: [source,console] ---- $ git clone https://github.com/schacon/simplegit-progit ---- -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +Bu projede `git log` komutunu çalıştırdığınızda, şuna benzer bir çıktı almanız beklenir:(((git commands, log))) [source,console] ---- @@ -36,14 +36,14 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and email, the date written, and the commit message. +Hiçbir argüman almadan kullanılan `git log` komutu, varsayılan olarak bu repoda yapılan "commit"leri ters kronolojik sırayla listeler. Yani en son "commit" en üstte görünür. +Gördüğünüz gibi, bu komut her bir işlemi SHA-1 kimliği, geliştiricinin adı ve e-postası, "commit" tarihi ve mesajıyla birlikte listeler. -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. +Tam olarak aradığınızı size göstermek için `git log` komutuna ilişkin çok sayıda ve çeşitli seçenekler mevcuttur. +Burada size en popüler olanlardan bazılarını göstereceğiz. -One of the more helpful options is `-p` or `--patch`, which shows the difference (the _patch_ output) introduced in each commit. -You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries. +Kullanışlı seçeneklerden biri, her bir "commit"te ortaya çıkan farkı (the _patch_ output) gösteren `-p` veya `--patch`tir. +Ayrıca yalnızca en son 5 "commit"i görmek için '-5' kullanmak gibi. Görüntülenecek günlük "commit" sayısını da sınırlayabilirsiniz. [source,console] ---- @@ -89,10 +89,10 @@ index a0a60ae..47c6340 100644 -end ---- -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +Bu seçenek aynı bilgileri ancak her bir "commit"le yapılan değişikliklerle birlikte görüntüler. +Bu yöntem, kod incelemesi veya bir ortak çalışanın eklediği bir dizi "commit" sırasında neler olduğuna hızlı bir şekilde göz atmak için oldukça faydalıdır. +Ayrıca `git log` ile bir dizi özetleme seçeneğini de kullanabilirsiniz. +Örneğin, her bir "commit" işlemine ilişkin bazı kısaltılmış istatistikleri görmek istiyorsanız `--stat` seçeneğini kullanabilirsiniz: [source,console] ---- @@ -127,14 +127,15 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. +Gördüğünüz gibi, `--stat` seçeneği her bir "commit" girişinin altında değiştirilen dosyaların listesini, kaç dosyanın değiştirildiğini ve bu dosyalara kaç satırın eklendiğini ve kaldırıldığını yazdırır. +Ayrıca en sona bilgilerin bir özetini de koyar. -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +Bir diğer kullanışlı seçenek ise `--pretty`dir. +Bu seçenek, günlük çıktısını varsayılanın dışındaki formatlara çevirir. +Kullanmanız için önceden oluşturulmuş birkaç seçenek mevcuttur. +`oneline` seçeneği her bir "commit"i tek bir satıra yazdırır: Eğer çok sayıda "commit"e bakıyorsanız bu özellikle kullanışlıdır. +Ek olarak, `short` (kısa), `full` (tam), ve `fuller` (geniş) seçenekleri çıktıyı aşağı yukarı aynı şekilde ancak daha az veya daha fazla bilgiyle gösterir. +Sırasıyla: [source,console] ---- @@ -144,8 +145,8 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing -- because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +En ilginç seçenek, kendi günlük çıktı formatınızı belirlemenize olanak tanıyan `format`tır. +Bu, özellikle makine ayrıştırması için çıktı oluşturduğunuzda kullanışlıdır. Biçimi açıkça belirttiğiniz için Git'teki güncellemelerle değişmeyeceğini bilirsiniz.(((log formatting))) [source,console] ---- @@ -155,37 +156,37 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> lists some of the more useful options that `format` takes. +<> `format`in gerektirdiği daha kullanışlı seçeneklerden bazılarını listeler. [[pretty_format]] -.Useful options for `git log --pretty=format` +.Kullanışlı `git log --pretty=format` seçenekleri [cols="1,4",options="header"] |================================ -| Option | Description of Output -| `%H` | Commit hash -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author email -| `%ad` | Author date (format respects the --date=option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject +| Seçenek | Çıktı Tanımı +| `%H` | Commit hash kimliği +| `%h` | Commit hash kimliği (kısa) +| `%T` | Çalışma ağacı hash kimliği +| `%t` | Çalışma ağacı hash kimliği (kısa) +| `%P` | Ana hashler +| `%p` | Ana hashler (kısa) +| `%an` | Yazar adı +| `%ae` | Yazar email adresi +| `%ad` | Yazım tarihi (--date=option) +| `%ar` | Yazım tarihi, göreli +| `%cn` | Geliştirici adı +| `%ce` | Geliştirici email adresi +| `%cd` | Geliştirme tarihi +| `%cr` | Geliştirme tarihi, göreli +| `%s` | Konu |================================ -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <>. +_yazar_ ve _geliştirici_ arasındaki farkın ne olduğunu merak ediyor olabilirsiniz. +Yazar, kodu ilk yazan kişi, geliştirici ise kodu son değiştiren yani "commit" eden kişidir. +Yani, bir projeye bir yama gönderirseniz ve çekirdek üyelerden biri yamayı uygularsa, her ikiniz de kredi alırsınız (yazar olarak siz ve "commit" eden olarak çekirdek üye). +Bu ayrımı <> bölümünde biraz daha ele alacağız. -The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: +`oneline` ve `format` seçenekleri `--graph` adı verilen başka bir `log` seçeneğiyle birlikte kullanıldığında özellikle kullanışlıdır. +Bu seçenek çıktıya, dallanma ve birleştirme geçmişinizi gösteren küçük bir ASCII grafiği ekler: [source,console] ---- @@ -202,85 +203,85 @@ $ git log --pretty=format:"%h %s" --graph * 11d191e Merge branch 'defunkt' into local ---- -This type of output will become more interesting as we go through branching and merging in the next chapter. +Bir sonraki bölümde dallanma ve birleştirme işlemlerine geçtikçe bu tür çıktılar daha ilginç hale gelecektir. -Those are only some simple output-formatting options to `git log` -- there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +Bunlar `git log` için yalnızca bazı basit çıktı biçimlendirme seçenekleridir fakat çok daha fazlası vardır. +<> şu ana kadar ele aldığımız seçeneklerin yanı sıra faydalı olabilecek diğer bazı yaygın biçimlendirme seçeneklerini ve bunların log komutunun çıktısını nasıl değiştirdiklerini listeler. [[log_options]] -.Common options to `git log` +.Yaygın `git log` seçenekleri [cols="1,4",options="header"] |================================ -| Option | Description -| `-p` | Show the patch introduced with each commit. -| `--stat` | Show statistics for files modified in each commit. -| `--shortstat` | Display only the changed/insertions/deletions line from the --stat command. -| `--name-only` | Show the list of files modified after the commit information. -| `--name-status` | Show the list of files affected with added/modified/deleted information as well. -| `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40. -| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. -| `--graph` | Display an ASCII graph of the branch and merge history beside the log output. -| `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). -| `--oneline` | Shorthand for `--pretty=oneline --abbrev-commit` used together. +| Seçenek | Tanım +| `-p` | Her bir "commit"te tanıtılan yamayı göster +| `--stat` | Her "commit"te değiştirilen dosyalara ilişkin istatistikleri göster +| `--shortstat` | --stat komutundan yalnızca değiştirilen/eklenenler/silenler satırını göster +| `--name-only` | "commit" bilgisinden sonra değiştirilen dosyaların listesini göster +| `--name-status` | Eklenen/değiştirilen/silinmiş bilgilerle birlikte değiştirilen dosyaların listesini de göster +| `--abbrev-commit` | SHA-1 kimliğinin tüm 40 karakteri yerine sadece ilk bir kaç karakterini göster +| `--relative-date` | Tarihi, tam tarih biçimini kullanmak yerine göreli bir biçimde göster (ör. ``2 hafta önce``) +| `--graph` | Günlük çıktısının yanında dal ve birleştirme geçmişinin ASCII grafiğini de göster +| `--pretty` | "commit"leri alternatif bir formatta göster. Seçenekler arasında tek satırlı (oneline), kısa (short), tam (full), daha kapsamlı (fuller) ve kendi oluşturduğunuz format da yer alır. +| `--oneline` | `--pretty=oneline --abbrev-commit` birlikte kullanımı için kısayoldur |================================ -==== Limiting Log Output +==== Günlük (Log) Çıktısını Sınırlama -In addition to output-formatting options, `git log` takes a number of useful limiting options; that is, options that let you show only a subset of commits. -You've seen one such option already -- the `-2` option, which displays only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +`git log` çıktı biçimlendirme seçeneklerine ek olarak, bir dizi yararlı sınırlama seçeneğini de beraberinde getirir. Bu "commit"lerin yalnızca belli bir alt kümesini göstermenize izin veren seçeneklerdir. +Böyle bir seçeneği zaten gördünüz: yalnızca son iki işlemi görüntüleyen '-2' seçeneği. +Aslında, `-` işlemini yapabilirsiniz. Buradaki `-n`, en son yapılan `n` sayıdaki "commit"i gösteren herhangi bir tam sayıdır. +Gerçekte, bunu sık kullanmanız pek mümkün değildir; çünkü Git varsayılan olarak tüm çıktıları bir "pager" (sayfa düzenleyici) üzerinden yönlendirir, böylece bir kerede yalnızca bir sayfalık günlük çıktısı görürsünüz. -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: +Yine de, `--since` ve `--until` gibi zaman sınırlayıcı seçenekler çok kullanışlıdır. +Örneğin, aşağıdaki komut son iki hafta içinde yapılan "commit"lerin listesini yazdırır: [source,console] ---- $ git log --since=2.weeks ---- -This command works with lots of formats -- you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +Bu komut birçok formatla çalışır; "2008-01-15" gibi belirli bir tarih veya "2 yıl 1 gün 3 dakika önce" gibi göreceli bir tarih belirtebilirsiniz. -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. +Listeyi, bazı arama kriterleriyle eşleşen "commit"lere göre de filtreleyebilirsiniz. +`--author` seçeneği belirli bir yazara göre filtreleme yapmanızı sağlar ve `--grep` seçeneği "commit" mesajlarındaki anahtar kelimeleri aramanızı sağlar. -[NOTE] +[NOT] ==== -You can specify more than one instance of both the `--author` and `--grep` search criteria, which -will limit the commit output to commits that match _any_ of the `--author` patterns and _any_ -of the `--grep` patterns; however, adding the `--all-match` option further limits the output to -just those commits that match _all_ `--grep` patterns. +Hem `--author` hem de `--grep` arama kriterlerinin birden fazla örneğini de aynı anda kullanabilirsiniz. +Bu "commit" çıktısını sadece uygun düşen `--author` ve `--grep` kalıplarıyla eşleşen "commit"lerle sınırlayacaktır. +Ancak, `--all-match` seçeneğinin eklenmesi çıktıyı _all_ `--grep` kalıplarıyla eşleşen "commit"ler yüzünden daha da sınırlandıracaktır. + ==== -Another really helpful filter is the `-S` option (colloquially referred to as Git's ``pickaxe'' option), which takes a string and shows only those commits that changed the number of occurrences of that string. -For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +Bir diğer gerçekten faydalı filtre ise bir dize (string: karakter dizisi) alan ve yalnızca o dizenin oluşum sayısını değiştiren "commit"leri gösteren `-S` seçeneğidir (yazılımcılar arasında Git'in "kazma" seçeneği olarak anılır). +Örneğin, belirli bir işleve referans ekleyen veya kaldıran son "commit" işlemi bulmak istiyorsanız şunu arayabilirsiniz: [source,console] ---- $ git log -S function_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +`git log`a filtre argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). +Eğer bir dizin veya dosya adı belirtirseniz günlük çıktısını (log), bu dosyalarda değişiklik yapan "commit"lerle sınırlayabilirsiniz. +Bu her zaman son seçenektir ve dosya yollarını seçeneklerden (bayraklardan) ayırmak için genellikle önünde çift çizgi (`--`) bulunur. -In <> we'll list these and a few other common options for your reference. +<> bölümünde bunları ve diğer birkaç genel seçeneği referans olması açısından listeleyeceğiz. [[limit_options]] -.Options to limit the output of `git log` +.`git log` komutunun çıktılarını sınırlama seçeneği [cols="2,4",options="header"] |================================ -| Option | Description -| `-` | Show only the last n commits -| `--since`, `--after` | Limit the commits to those made after the specified date. -| `--until`, `--before` | Limit the commits to those made before the specified date. -| `--author` | Only show commits in which the author entry matches the specified string. -| `--committer` | Only show commits in which the committer entry matches the specified string. -| `--grep` | Only show commits with a commit message containing the string -| `-S` | Only show commits adding or removing code matching the string +| Seçenek | Tanım +| `-` | Sadece en son n sayıdaki "commit"i göster +| `--since`, `--after` | "commit" listesini belirli bir tarihten sonra yapılan "commitler"le sınırla +| `--until`, `--before` | "commit" listesini belirli bir tarihe kadar yapılan "commitler"le sınırla +| `--author` | Sadece author kısmı verilen dizeyle eşleşen "commit"leri göster +| `--committer` | Sadece committer kısmı verilen dizeyle eşleşen "commit"leri göster +| `--grep` | Sadece "commit" mesajında verilen dize bulunan "commit"leri göster +| `-S` | Sadece codunda verilen dizeyi ekleyen veya çıkaran "commit"leri göster |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering))) +Örneğin, Git kaynak kodu geçmişindeki test dosyalarını değiştiren hangi "commit"lerin Ekim 2008 ayında Junio Hamano tarafından işlendiğini ve birleştirme (merge) "commit"leri olmadığını görmek istiyorsanız, şöyle bir komut çalıştırabilirsiniz:(((log filtering))) [source,console] ---- @@ -294,11 +295,11 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Bu komutla, Git kaynak kodu geçmişindeki yaklaşık 40.000 "commit"ten bu kriterlere uyan sadece 6'sını görebilirsiniz. -[TIP] -.Preventing the display of merge commits +[İPUCU] +.Birleştirme Commit'lerinin gösterilmesini engelleme ==== -Depending on the workflow used in your repository, it's possible that a sizable percentage of the commits in your log history are just merge commits, which typically aren't very informative. -To prevent the display of merge commits cluttering up your log history, simply add the log option `--no-merges`. +Reponuzda kullanılan iş akışına bağlı olarak, günlük (log) geçmişinizdeki "commit"lerin büyük bir yüzdesinin yalnızca birleştirme (merge) "commit"leri olması mümkündür ve bunlar genellikle pek bilgilendirici değildir. +Birleştirme işlemlerinin görüntülenmesinin günlük (log) geçmişinizi karmaşık hale getirmesini önlemek için, `--no-merges` seçeneğini eklemeniz yeterlidir. ==== From be5dac9f5d3405e7d123e9a8507866979441e2c4 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:29:48 +0100 Subject: [PATCH 008/210] Update undoing.asc 02-basics-05 translated --- book/02-git-basics/sections/undoing.asc | 97 +++++++++++++------------ 1 file changed, 49 insertions(+), 48 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index a6780602..088c1306 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_undoing]] -=== Undoing Things +=== Değişiklikleri Geri Alma (undo) -At any stage, you may want to undo something. -Here, we'll review a few basic tools for undoing changes that you've made. -Be careful, because you can't always undo some of these undos. -This is one of the few areas in Git where you may lose some work if you do it wrong. +Herhangi bir aşamada bir şeyi geri almak isteyebilirsiniz. +Burada, yaptığınız değişiklikleri geri almak için kullanabileceğiniz birkaç temel aracı inceleyeceğiz. +Dikkatli olun çünkü bu geri alma işlemlerinin bazılarını her zaman iptal ederek geri alma öncesi duruma geri dönemeyebilirsiniz. +Bu, Git'te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç alandan biridir. -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to redo that commit, make the additional changes you forgot, stage them, and commit again using the `--amend` option: +Yaygın geri alma ihtiyaçlarından biri, bazı dosyaları eklemeyi unuttup "commit"inizi çok erken yaptığınızda veya yanlış bir "commit" mesajı yazdığınızda ortaya çıkar. +Bir "commit"i yeniden yapmak istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları "stage"e alın ve `--amend` seçeneğini kullanarak yeniden "commit" yapın: [source,console] ---- $ git commit --amend ---- -This command takes your staging area and uses it for the commit. -If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. +Bu komut "stage" alanınızı alır ve "commit"iniz için kullanır. +Son "commit"inizden beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son "commit"inizden hemen sonra çalıştırdıysanız), anlık görüntünüz tamamen aynı olacak ve değiştireceğiniz tek şey "commit" mesajınız olacaktır. -The same commit-message editor fires up, but it already contains the message of your previous commit. -You can edit the message the same as always, but it overwrites your previous commit. +Bunu yaptığınızda aynı "commit mesajı düzenleyicisi" aynı "commit" mesajıyla devreye girer. +Mesajı her zamanki gibi düzenleyebilirsiniz ancak bu, önceki "commit" mesajınızın üzerine yazılır. -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +Örnek olarak, "commit" yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri "stage"e almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz: [source,console] ---- @@ -29,24 +29,25 @@ $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit -- the second commit replaces the results of the first. +Bu işlemin sonucunda, ikinci "commit"in ilk "commit"in yerini aldığı tek bir "commit" elde edersiniz. -[NOTE] +[NOT] ==== -It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place. -Effectively, it's as if the previous commit never happened, and it won't show up in your repository history. +Şunu anlamanız özellikle önemli: Eğer son "commit"inizi "amend" ederseniz, son "commit"inizi düzeltmekten ziyade, eski "commit" ortadan kaldırıp ve yerine yeni bir "commit" koymaktasınız. +Sanki önceki "commit" hiç gerçekleşmemiş ve repo geçmişinizde görünmeyecekmiş gibi. + +Önceki "commit"leri değiştirmenin asıl değeri, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemedeki bir yazım hatasını düzelttim`` şeklinde gereksiz "commit" mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır. -The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''. ==== [[_unstaging]] -==== Unstaging a Staged File +==== "stage"e Alınmış Dosyayı "stage"den Çıkarmak (Unstaging) -The next two sections demonstrate how to work with your staging area and working directory changes. -The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. -For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. -How can you unstage one of the two? -The `git status` command reminds you: +Sonraki iki bölümde "stage" alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. +İşin güzel yanı, bu iki alanın durumunu tanımlamak için kullandığımız komut aynı zamanda bu alanlarda yapılan değişiklikleri nasıl geri alacağımızı da bize söyler. +Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla `git add *` yazıp ikisini birden "stage"e aldığınızı varsayalım. +İkisinden birini nasıl "stage"den çıkarabilirsiniz? +`git status` komutu size bunu nasıl yapacağınızı zaten hatırlatır: [source,console] ---- @@ -60,8 +61,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -Right below the ``Changes to be committed'' text, it says use `git reset HEAD ...` to unstage. -So, let's use that advice to unstage the `CONTRIBUTING.md` file: +``Changes to be committed`` metninin hemen altında, düzenlemeyi kaldırmak için `git reset HEAD ...` kullanın yazıyor. +O halde, `CONTRIBUTING.md` dosyasını "stage"den çıkarmak için bu tavsiyeyi kullanalım: [source,console] ---- @@ -82,24 +83,24 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -The command is a bit strange, but it works. -The `CONTRIBUTING.md` file is modified but once again unstaged. +Komut biraz garip ama neticede işe yarıyor. +`CONTRIBUTING.md` dosyası değiştirildi ancak nihai durumda "stage"de değil. -[NOTE] +[NOT] ===== -It's true that `git reset` can be a dangerous command, especially if you provide the `--hard` flag. -However, in the scenario described above, the file in your working directory is not touched, so it's relatively safe. +`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. ===== -For now this magic invocation is all you need to know about the `git reset` command. -We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <>. +Şimdilik bu sihirli çağrı, `git reset` komutu hakkında bilmeniz gereken tek şey. +<> ünitesinde `reset`in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz. -==== Unmodifying a Modified File +==== Değiştirilmiş Dosyadaki Değişikliği Geri Alma (Unmodifying) -What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it -- revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? -Luckily, `git status` tells you how to do that, too. -In the last example output, the unstaged area looks like this: +`CONTRIBUTING.md` dosyasındaki değişikliklerinizi saklamak istemediğinizi fark ederseniz ne yaparsınız? +Yaptığınız değişiklikleri kolayca nasıl kaldırabilirsiniz veya en son "commit"inizdeki (veya başlangıçta klonladığınız ya da çalışma dizininize soktuğunuz) haline nasıl geri döndürebilirsiniz? +Neyse ki, `git status` size bunu nasıl yapacağınızı da söyler. +Son örnek çıktıda, "unstaged" alan şuna benzer: [source,console] ---- @@ -110,8 +111,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -It tells you pretty explicitly how to discard the changes you've made. -Let's do what it says: +Yaptığınız değişiklikleri nasıl iptal edeceğinizi oldukça açık bir şekilde anlatmaktadır. +Hadi söyleneni yapalım: [source,console] ---- @@ -125,17 +126,17 @@ Changes to be committed: ---- -You can see that the changes have been reverted. +Değişikliklerin geri alındığını görebilirsiniz. -[IMPORTANT] +[ÖNEMLİ] ===== -It's important to understand that `git checkout -- ` is a dangerous command. -Any local changes you made to that file are gone -- Git just replaced that file with the most recently-committed version. -Don't ever use this command unless you absolutely know that you don't want those unsaved local changes. +`git checkout -- ` komutunun tehlikeli bir komut olduğunu anlamanız çok önemli. +Bu dosyada yaptığınız tüm yerel değişiklikler kayboldu! Git, bu dosyayı en son kaydedilen sürümle değiştirdi. +Kaydedilmemiş yerel değişiklikleri istemediğinizden kesinlikle emin olmadığınız sürece bu komutu asla kullanmayın! ===== -If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <>; these are generally better ways to go. +Bu dosyada yaptığınız değişiklikleri korumak istiyorsanız ancak şimdilik yine de ondan kurtulmanız gerekiyorsa, <> ünitesinde saklama ve dallandırma işlemlerini ele alacağız. Onların genellikle daha kullanışlı yollar olduğunu göreceksiniz. -Remember, anything that is _committed_ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <> for data recovery). -However, anything you lose that was never committed is likely never to be seen again. +Git'te _committed_ olan her şeyin neredeyse her zaman kurtarılabileceğini unutmayın. +Hatta silinen dallardaki "commit"ler veya `--amend` komutuyla üzerini yeniden yazılan "commit"ler bile kurtarılabilir. (veri kurtarma için bkz. >). +Ancak, hiç "commit" etmediğiniz bir şeyi tamamen kaybetmeniz oldukça muhtemeldir. From 13cdfa7f4954130c05287dfbc347f08eb7fae770 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:30:47 +0100 Subject: [PATCH 009/210] Update remotes.asc 02-basics-05 translated --- book/02-git-basics/sections/remotes.asc | 132 ++++++++++++------------ 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index a150fbf6..e082c7fc 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,26 +1,26 @@ [[_remote_repos]] -=== Working with Remotes +=== Uzak Repo ile Çalışmak -To be able to collaborate on any Git project, you need to know how to manage your remote repositories. -Remote repositories are versions of your project that are hosted on the Internet or network somewhere. -You can have several of them, each of which generally is either read-only or read/write for you. -Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. -Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. -In this section, we'll cover some of these remote-management skills. +Herhangi bir Git projesinde işbirliği yapabilmek için uzak depolarınızı nasıl yöneteceğinizi bilmeniz gerekir. +Uzak depolar, projenizin İnternette veya ağda bir yerde barındırılan sürümleridir. +Bunlardan birkaçına sahip olabilirsiniz; bunların her biri genellikle sizin için salt okunurdur veya okuma/yazmadır. +Başkalarıyla işbirliği yapmak, bu uzak depoları yönetmeyi ve işlerinizi paylaşmanız gerektiğinde verileri bu havuzlara gönderip almayı içerir. +Uzak depoların yönetilmesi, uzak depoların nasıl ekleneceğini, artık geçerli olmayan uzaktan kumandaların nasıl kaldırılacağını, çeşitli uzak dalların nasıl yönetileceğini ve bunların izlenip izlenmediğini nasıl tanımlayacağınızı ve daha fazlasını bilmeyi içerir. +Bu bölümde bu uzaktan yönetim becerilerinden bazılarını ele alacağız. -[NOTE] -.Remote repositories can be on your local machine. +[NOT] +.Uzak depolar yerel makinenizde olabilir. ==== -It is entirely possible that you can be working with a ``remote'' repository that is, in fact, on the same host you are. -The word ``remote'' does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. -Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote. +Aslında sizinle aynı ana bilgisayar üzerinde olan bir ``uzak`` repoyla çalışıyor olmanız tamamen mümkündür. +'Uzak' kelimesi, veri deposunun ağda veya internette başka bir yerde olduğu anlamına gelmez, yalnızca başka bir yerde olduğu anlamına gelir. +Böyle bir uzak repoyla çalışmak, diğer uzaktan server'larda olduğu gibi yine de tüm standart push (kod gönderme), pull (kod çekme) ve fetch (kavrama) işlemlerini içerecektir. ==== -==== Showing Your Remotes +==== Uzak Sunucuları Görme -To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) -It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see `origin` -- that is the default name Git gives to the server you cloned from: +Hangi uzak sunucuları yapılandırdığınızı görmek için `git remote` komutunu çalıştırabilirsiniz.(((git commands, remote))) +Bu belirttiğiniz her uzak tanıtıcının kısa adlarını listeler. +Reponuzu klonladıysanız en azından `Origin`i görmelisiniz; Git'in klonladığınız sunucuya verdiği varsayılan isim budur: [source,console] ---- @@ -36,7 +36,7 @@ $ git remote origin ---- -You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: +Ayrıca Git'in o uzak sunucuya okuma ve yazma sırasında kullanılacak kısa ad için sakladığı URL'leri gösteren `-v` bayrağını da belirtebilirsiniz: [source,console] ---- @@ -45,8 +45,8 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -If you have more than one remote, the command lists them all. -For example, a repository with multiple remotes for working with several collaborators might look something like this. +Birden fazla uzak sunucunuz varsa, bu komut hepsini listeler. +Örneğin, birden fazla geliştiricinin beraber çalışmak için oluşturduğu birden fazla uzak sunucuya sahip bir repo şöyle görünebilir. [source,console] ---- @@ -64,16 +64,16 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -This means we can pull contributions from any of these users pretty easily. -We may additionally have permission to push to one or more of these, though we can't tell that here. +Bu, diğer geliştiricilerden kolaylıkla katkı alabileceğimiz anlamına gelir. +Ayrıca bunlardan bir veya daha fazlasını zorlama iznimiz olabilir, ancak bunu buradan söylemek mümkün değil. -Notice that these remotes use a variety of protocols; we'll cover more about this in <>. +Bu uzak sunucuların çeşitli protokoller kullandığına dikkat edin; Bu konu hakkında daha fazla bilgiyi <> bölümünde ele alacağız. -==== Adding Remote Repositories +==== Uzak Sunucuları Görme -We've mentioned and given some demonstrations of how the `git clone` command implicitly adds the `origin` remote for you. -Here's how to add a new remote explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: +`git clone` komutunun sizin için 'Origin' uzak sunucusunu nasıl eklediğinden üstü kapalı bahsettik ve bazı gösterimler verdik. +Yeni bir uzak sunucunun nasıl ekleneceği aşağıda daha açıkça anlatılmıştır.(((git commands, remote))) +Kısa adını kullanarak yeni bir uzak Git reposu eklemek için `git remote add ` komutunu çalıştırın: [source,console] ---- @@ -87,8 +87,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +Artık komut satırında URL'nin tamamı yerine `pb` dizesini kullanabilirsiniz. +Örneğin, Paul'un sahip olduğu ancak henüz sizin reponuzda bulunmayan tüm kodları getirmek istiyorsanız, `git fetch pb` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -102,53 +102,53 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <>.) +Paul'un ana-dalına (master branch) artık yerelde `pb/master` olarak erişilebilmektedir. Onu kendi dallarınızdan biriyle birleştirebilirsiniz veya incelemek isterseniz herhangi bir dala geçerek göz atabilirsiniz. +(Dalların ne olduğunu ve bunların nasıl kullanılacağını <> bölümünde çok daha ayrıntılı olarak ele alacağız.) [[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +==== Uzak Sunucudan Yakalama ve Getirme -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +Az önce gördüğünüz gibi uzak projelerinizden veri almak için aşağıdaki komutu çalıştırabilirsiniz.:(((git commands, fetch))) [source,console] ---- $ git fetch ---- -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +Komut o uzak projeye gider ve o uzak projeden henüz sahip olmadığınız tüm verileri çeker. +Bunu yaptığınız takdirde o uzak sunucudaki tüm dallara erişim için gerekli referanslara sahip olacaksınız. Böylece istediğiniz zaman kodları inceleyebilir veya kendi kodunuzla birleştirebilirsiniz. -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. +Eğer bir repoyu klonlarsanız, komut o uzak repoyu otomatik olarak ``Origin`` adı altına ekler. +Yani, `git fetch origin`, klonlamanızdan (veya sunucudan son getirmenizden) bu yana sunucuya gönderilen tüm yeni çalışmaları getirir. +Git fetch komutunun verileri yalnızca yerel reponuza indirdiğini unutmamalısınız. Verileri herhangi bir çalışmanızla otomatik olarak birleştirmez veya üzerinde çalışmakta olduğunuz kodu değiştirmez. +Hazır olduğunuzda bunu manuel olarak kendi kodunuzla birleştirmeniz gerekir. -If your current branch is set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +Geçerli dalınız uzak bir dalı izleyecek şekilde ayarlanmışsa (daha fazla bilgi için sonraki bölüme ve <>'e bakın), otomatik olarak getirmek için `git pull` komutunu kullanabilirsiniz. Daha sonra bu uzak dalı mevcut dalınızla birleştirin.(((git commands, pull))) +Bu size daha kolay veya daha rahat bir iş akışı sağlar. Varsayılan olarak `git clone` komutu, yerel ana dalınızı (genellikle main veya master olarak adlandırılır), klonladığınız uzak sunucudaki uzak ana dalı (veya varsayılan dalın adı her neyse) izleyecek şekilde otomatik olarak ayarlar. +`git pull` komutunu çalıştırmak genellikle verileri orijinal olarak klonladığınız sunucudan getirir ve otomatik olarak bu verileri üzerinde çalışmakta olduğunuz kodla birleştirmeye çalışır. [[_pushing_remotes]] -==== Pushing to Your Remotes +==== Kodlarınızı Uzak Sunucuya Göndermek (push etmek) -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push `.(((git commands, push))) -If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +Projeniz belli bir aşamaya ulaştıktan sonra paylaşmak isteyebilirsiniz. Bunun için geliştirilmiş kodunuzu uzak repoya göndermeniz (push etmek) gerekmektedir. +Bunun için kullanmanız gereken komut basittir: `git Push `.(((git commands, push))) +Ana dalınızı "Origin" sunucunuza göndermek istiyorsanız (yine klonlama genellikle bu adların her ikisini de sizin için otomatik olarak ayarlar), o zaman yaptığınız "commitleri sunucuya geri göndermek için şunu çalıştırabilirsiniz: [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push. -See <> for more detailed information on how to push to remote servers. +Bu komut yalnızca yazma erişiminizin olduğu bir sunucudan klonlama yapmışsanız ve bu arada hiç kimse başka bir "push" yapmamışsa çalışır. +Siz ve başkaları projeyi aynı anda klonlarsanız ve diğerleri sizden önce geliştirilmiş kodlarını uzak sunucuya gönderirse, doğal olarak sizin gönderiminiz (push) reddedilecektir. +Değiştirilmiş kodunuzu göndermenize (push) izin verilmeden önce, diğerleri tarafından güncellenmiş kodları uzak repodan getirmeniz (pull) ve kendi işinize dahil etmeniz gerekecek. +Güncel çalışmanızı uzak sunuculara nasıl gönderebileceğiniz hakkında daha ayrıntılı bilgi için <> konusuna bakın. [[_inspecting_remote]] -==== Inspecting a Remote +==== Uzak Sunucunun İncelenmesi -If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +Belirli bir uzak sunucu hakkında daha fazla bilgi görmek istiyorsanız git remote show ` komutunu kullanabilirsiniz.(((git commands, remote))) +Bu komutu `origin` gibi belirli bir kısa adla çalıştırırsanız şöyle bir sonuç elde edersiniz: [source,console] ---- @@ -166,12 +166,12 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. +Bu komut uzak repo URL'si yanında izlenen dal bilgilerini de listeler. +Bununla birlikte size, eğer ana daldaysanız (main veya master) ve `git pull` çalıştırırsanız, tüm uzak referansları getirdikten sonra otomatik olarak uzak repodaki ana dalla birleşeceğini (merge) söyler. +Ayrıca indirdiği (pull) tüm uzak referansları da listeler. -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +Bu karşılaşacağınız basit bir örnektir. +Ancak Git'i daha yoğun kullandığınızda, `git remote show` komutuyla çok daha fazla bilgi görebilirsiniz: [source,console] ---- @@ -197,13 +197,13 @@ $ git remote show origin master pushes to master (up to date) ---- -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`. +Bu komut, belirli bir daldaken `git Push` komutunu çalıştırdığınızda otomatik olarak hangi dalın uzak repoya aktarılacağını gösterir. +Ayrıca, sunucudaki hangi uzak dallara henüz sahip olmadığınızı; yerelde sahip olduğunuz hangi dalların uzak sunucudan kaldırılmış olduğunu ve `git pull` çalıştırdığınızda otomatik olarak uzak-izleme dallarıyla birleşecek (merge) çoklu yerel dallarınızı da gösterir. -==== Renaming and Removing Remotes +==== Uzak Sunucuları Yeniden Adlandırma ve Kaldırma -You can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +Bir uzaktan sunucunun kısa adını değiştirmek için `git remote rename` komutunu çalıştırabilirsiniz.(((git commands, remote))) +Örneğin `pb`yi `paul` olarak yeniden adlandırmak istiyorsanız, bunu `git remote rename` komutu ile yapabilirsiniz: [source,console] ---- @@ -213,10 +213,10 @@ origin paul ---- -It's worth mentioning that this changes all your remote-tracking branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. +Bunun tüm uzaktan izleme dal adlarınızı değiştirdiğini belirtmekte fayda var. +Önceden `pb/master` olarak adlandırılan (referance) uzak sunucunun yeni adı artık `paul/master`dır. -If you want to remove a remote for some reason -- you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore -- you can either use `git remote remove` or `git remote rm`: +Herhangi bir nedenden dolayı uzak sunucuyu kaldırmak isterseniz (ör: sunucuyu taşımışsanız veya artık belirli bir aynayı -mirror: bir repodaki tüm verileri ve geçmişi eksiksiz olarak başka bir drepoya kopyalayan bir repo- kullanmıyorsanız veya geliştiricilerden biri artık projeye katkıda bulunmuyorsa) `git remote remove` veya `git remote rm` komutlarından birini kullanabilirsiniz: [source,console] ---- @@ -225,4 +225,4 @@ $ git remote origin ---- -Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted. +Bir uzaktan sunucunun referansını bu şekilde sildiğinizde, o sunucuyla ilişkili tüm uzaktan izleme dalları ve yapılandırma ayarları da silinir. From 07c933b70f6cb3ef9595efd3d6332378dd34edda Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:31:42 +0100 Subject: [PATCH 010/210] Update tagging.asc 02-basics-06 translated --- book/02-git-basics/sections/tagging.asc | 130 ++++++++++++------------ 1 file changed, 66 insertions(+), 64 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 0ae6ae7a..bf596467 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,15 +1,15 @@ [[_git_tagging]] -=== Tagging +=== Etiketleme (tagging) (((tags))) -Like most VCSs, Git has the ability to tag specific points in a repository's history as being important. -Typically, people use this functionality to mark release points (`v1.0`, `v2.0` and so on). -In this section, you'll learn how to list existing tags, how to create and delete tags, and what the different types of tags are. +Çoğu VCS gibi Git de bir reponun geçmişindeki belirli noktaları "önemli" şeklinde etiketleme yeteneğine sahiptir. +Genellikle geliştiriciler bu işlevi her bir sürümü (`v1.0`, `v2.0` vb.) işaretlemek için kullanır. +Bu bölümde mevcut etiketlerin nasıl listeleneceğini, etiketlerin nasıl oluşturulacağını ve silineceğini ve farklı etiket türlerinin neler olduğunu öğreneceksiniz. -==== Listing Your Tags +==== Etiketlerinizi Listeleme (listing) -Listing the existing tags in Git is straightforward. -Just type `git tag` (with optional `-l` or `--list`):(((git commands, tag))) +Git'te mevcut etiketleri listelemek oldukça basittir. +Sadece `git tag` (isterseniz `-l` veya `--list` seçenekleriyle) yazmanız yeterlidir:(((git commands, tag))) [source,console] ---- @@ -18,11 +18,11 @@ v1.0 v2.0 ---- -This command lists the tags in alphabetical order; the order in which they are displayed has no real importance. +Bu komut, etiketleri alfabetik sıraya göre listeler ama görüntülenme sırasının aslında bir önemi yoktur. -You can also search for tags that match a particular pattern. -The Git source repo, for instance, contains more than 500 tags. -If you're interested only in looking at the 1.8.5 series, you can run this: +Ayrıca belli kalıplarla eşleşen etiketleri de arayabilirsiniz. +Örneğin Git kaynak reposu 500'den fazla etiket içerir. +Eğer sadece 1.8.5 serisine bakmak istiyorsanız şunu çalıştırabilirsiniz: [source,console] ---- @@ -39,30 +39,30 @@ v1.8.5.4 v1.8.5.5 ---- -[NOTE] -.Listing tag wildcards requires `-l` or `--list` option +[NOT] +.Joker (wildcard) etiket karakterlerini listelemek `-l` veya `--list` gerektirir ==== -If you want just the entire list of tags, running the command `git tag` implicitly assumes you want a listing and provides one; the use of `-l` or `--list` in this case is optional. +Eğer tüm etiketlerin toplu bir listesini istiyorsanız `git tag` komutunu çalıştırabilirsiniz. Git bu durumda sizin bir liste istediğinizi varsayar ve size bu listeyi verir. Böyle bir durumda `-l` veya `--list` kullanımı isteğe bağlıdır. -If, however, you're supplying a wildcard pattern to match tag names, the use of `-l` or `--list` is mandatory. +Ancak etiket adlarıyla eşleştirmek üzere bir karakter deseni (joker) yazacaksanız, `-l` veya `--list` kullanımı zorunludur. ==== -==== Creating Tags +==== Etiket Oluşturma -Git supports two types of tags: _lightweight_ and _annotated_. +Git iki çeşit etiketi destekler: _lightweight_ (hafif) ve _annotated_ (açıklamalı). -A lightweight tag is very much like a branch that doesn't change -- it's just a pointer to a specific commit. +Hafif bir etiket, değişmeyen bir Git dalı gibidir; yalnızca belirli bir "commit"in işaretçisidir. -Annotated tags, however, are stored as full objects in the Git database. -They're checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). -It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. +Ancak açıklamalı etiketler Git veritabanında tam nesneler olarak depolanır. +Bunlar sağlamalı (checksummed) verilerdir. Etiketleyicinin adını, e-postasını ve etiketleme tarihini içerir; etiketleme mesajınız yer alır ve GNU Privacy Guard (GPG) ile imzalanıp, doğrulanabilir. +Tüm bu bilgilere sahip olabilmeniz için genellikle açıklamalı etiketler oluşturmanız önerilir; ancak geçici bir etiket istiyorsanız veya herhangi bir nedenle diğer bilgileri saklamak istemiyorsanız, hafif etiketler de mevcuttur. [[_annotated_tags]] -==== Annotated Tags +==== Açıklamalı Etiketler (annotated tags) (((tags, annotated))) -Creating an annotated tag in Git is simple. -The easiest way is to specify `-a` when you run the `tag` command:(((git commands, tag))) +Git'te açıklamalı bir etiket oluşturmak basittir. +En kolay yol, `tag` komutunu çalıştırdığınızda `-a` bayrağı da belirtmektir:(((git commands, tag))) [source,console] ---- @@ -73,10 +73,10 @@ v1.3 v1.4 ---- -The `-m` specifies a tagging message, which is stored with the tag. -If you don't specify a message for an annotated tag, Git launches your editor so you can type it in. +`-m` bayrağı etiketle birlikte saklanan bir etiketleme mesajı belirtir. +Eğer bu etiket için bir mesaj belirtmezseniz Git, mesajı yazabilmeniz için otomatik olarak düzenleyicinizi başlatır. -You can see the tag data along with the commit that was tagged by using the `git show` command: +Etiket verilerini `git show` komutunu kullanarak etiketlediğiniz "commit"le birlikte görebilirsiniz: [source,console] ---- @@ -94,14 +94,14 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. +Bu "commit" bilgisini göstermeden önce etiketleme bilgisini, etiketleme tarihini ve açıklama mesajını gösterir. -==== Lightweight Tags +==== Hafif Etiketler (lightweight tags) (((tags, lightweight))) -Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file -- no other information is kept. -To create a lightweight tag, don't supply any of the `-a`, `-s`, or `-m` options, just provide a tag name: +"commit"leri etiketlemenin başka bir yolu da hafif etiketler kullanmaktır. +Bu metodda "commit" sağlaması dışında hiçbir veri saklanmaz. +Hafif etiket oluşturmak için `-a`, `-s` veya `-m` seçeneklerinden hiçbirini kullanmaksızın sadece bir etiket adı yazarsınız: [source,console] ---- @@ -114,8 +114,8 @@ v1.4-lw v1.5 ---- -This time, if you run `git show` on the tag, you don't see the extra tag information.(((git commands, show))) -The command just shows the commit: +Bu sefer etiket üzerinde `git show` komutunu çalıştırırsanız ekstra etiket bilgilerini göremezsiniz.(((git commands, show))) +Komut sadece "commit"i gösterir: [source,console] ---- @@ -127,10 +127,10 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -==== Tagging Later +==== Sonradan Etiketleme -You can also tag commits after you've moved past them. -Suppose your commit history looks like this: +"commit"leri geçtikten sonra da etiketleyebilirsiniz. +"commit" geçmişinizin şöyle göründüğünü varsayalım: [source,console] ---- @@ -147,16 +147,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- -Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit. -You can add it after the fact. -To tag that commit, you specify the commit checksum (or part of it) at the end of the command: +Şimdi, projeyi ``updated rakefile`` "commit"inde bulunurken "v1.2"ye etiketlemeyi unuttuğunuzu varsayalım. +Bunu sonradan da ekleyebilirsiniz. +Bu "commit"i etiketlemek için, komutun sonunda "commit" sağlamasının (checksum) tamamını veya bir kısmını belirtirsiniz: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -You can see that you've tagged the commit:(((git commands, tag))) +"commit"i etiketlediğinizi görebilirsiniz:(((git commands, tag))) [source,console] ---- @@ -183,11 +183,11 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== Sharing Tags +==== Etiketleri Paylaşma -By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) -You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches -- you can run `git push origin `. +Varsayılan olarak `git push` komutu, etiketleri uzak sunuculara aktarmaz.(((git commands, push))) +Etiketleri oluşturduktan sonra açıkça paylaşıma açık bir sunucuya (shared server) göndermeniz gerekecektir. +Bu süreç tıpkı uzak dalları paylaşmaya benzer: `git push origin ` komutunu çalıştırabilirsiniz (tagname: etiket adı). [source,console] ---- @@ -201,8 +201,8 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. -This will transfer all of your tags to the remote server that are not already there. +Aynı anda göndermek istediğiniz çok sayıda etiketiniz varsa, `git push` komutunun yerine `--tags` seçeneğini de kullanabilirsiniz. +Bu, tüm etiketlerinizi, halihazırda orada olmayan uzak sunucuya aktaracaktır. [source,console] ---- @@ -215,18 +215,19 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Now, when someone else clones or pulls from your repository, they will get all your tags as well. +Artık başka biri reponuzu klonladığında veya reponuzdan bilgi aldığında tüm etiketlerinizi de alacaktır. -[NOTE] -.`git push` pushes both types of tags +[NOT] +.`git push` her iki türde etiketi de gönderir ==== -Pushing tags using `git push --tags` does not distinguish between lightweight and annotated tags; there is no simple option that allows you to select just one type for pushing. +Etiketleri `git push --tags` kullanarak göndermek, hafif ve açıklamalı etiketler arasında bir ayrım yapmaz. Gönderme (push) işlemi için tür seçmenize olanak tanıyan basit bir seçenek veya bayrak yoktur. ==== -==== Deleting Tags +==== Etiketleri Silme (delete) + +Yerel reponuzdaki bir etiketi silmek için `git tag -d ` komutunu kullanabilirsiniz (tagname: etiket adı). +Örneğin yukarıdaki hafif etiketimizi şu şekilde kaldırabiliriz: -To delete a tag on your local repository, you can use `git tag -d `. -For example, we could remove our lightweight tag above as follows: [source,console] ---- @@ -234,10 +235,10 @@ $ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add) ---- -Note that this does not remove the tag from any remote servers. -There are two common variations for deleting a tag from a remote server. +Bunun, etiketi herhangi bir uzak sunucudan kaldırmadığını unutmayın. +Uzak sunucudan etiket silmenin iki yaygın çeşidi vardır. -The first variation is `git push :refs/tags/`: +İlk yöntem `git push :refs/tags/` komutudur (remote: uzak sunucu adı, tagname: etiket adı): [source,console] ---- @@ -246,18 +247,18 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -The way to interpret the above is to read it as the null value before the colon is being pushed to the remote tag name, effectively deleting it. +Aslında yaptığımız şey: uzak sunucudaki (remote) etiket adının (tagname) üstüne boş (null) bir değer yazmaktır (":" dan önceki boşluğa dikkat edin). Böylece eski etiket silinecektir. -The second (and more intuitive) way to delete a remote tag is with: +Uzak etiketi silmenin ikinci (ve daha sezgisel) yolu ise `--delete ` kullanmaktır (tagname: etiket adı): [source,console] ---- $ git push origin --delete ---- -==== Checking out Tags +==== Etiketleri kontrol etme -If you want to view the versions of files a tag is pointing to, you can do a `git checkout` of that tag, although this puts your repository in ``detached HEAD'' state, which has some ill side effects: +Bir etiketin işaret ettiği sürümleri görüntülemek istiyorsanız, bu etiketi `git checkout` komutuyla kontrol edebilirsiniz. Ancak bunu yapmak reponuzu ``detached HEAD`` (ayrık uç) durumuna sokar ve bu da bazı olumsuz yan etkilere neden olur: [source,console] ---- @@ -280,8 +281,9 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append HEAD is now at df3f601... add atlas.json and cover image ---- -In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except by the exact commit hash. -Thus, if you need to make changes -- say you're fixing a bug on an older version, for instance -- you will generally want to create a branch: +Normalde her bir dalda bir uç (HEAD) bulunur ve bu uç en son "commit"e sabitlenmiştir. +``detached HEAD`` durumundayken bu uç en son "commit" yerine etikete sabitlendiğinden bir "commit" oluştursanız bile "commit"iniz hiçbir dala ait olmayacağı için kesin "commit" karması (hash) dışında erişilemez olacaktır. +Bu nedenle, değişiklik yapmanız gerekiyorsa (mesela eski bir sürümdeki bir hatayı düzelttiniz) yeni bir dal oluşturmanız gerekecektir: [source,console] ---- @@ -289,4 +291,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -If you do this and make a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +Bunu yapıp bir "commit"te bulunursanız, "version2" dalınız, yeni değişikliklerinizle ilerleyeceği için "v2.0.0" etiketinizden biraz farklı olacaktır, bu yüzden dikkatli olun. From e5763bbe906a7217bc7291b799b1ec75f7d89f52 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:32:45 +0100 Subject: [PATCH 011/210] Update aliases.asc 02-basics-07 translated --- book/02-git-basics/sections/aliases.asc | 38 ++++++++++++------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 2c9c7c02..4d076eca 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,13 +1,13 @@ [[_git_aliases]] -=== Git Aliases +=== Komut Kısayolu (Alias) Ayarlama (((aliases))) -Before we finish this chapter on basic Git, there's just one little tip that can make your Git experience simpler, easier, and more familiar: aliases. -We won't refer to them or assume you've used them later in the book, but you should probably know how to use them. +Temel Git ile ilgili bu bölümü bitirmeden önce Git deneyiminizi daha basit, daha kolay ve daha tanıdık hale getirebilecek küçük bir ipucu vereceğiz: komut kısayolları. +Bu kitapta kısayol (alias) konusuna girmeyeceğiz veya ilerleyen bölümlerde bunları kullandığınızı varsaymayacağız, ancak bunları nasıl kullanacağınızı bilmenizde yine de fayda var. -Git doesn't automatically infer your command if you type it in partially. -If you don't want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`.(((git commands, config))) -Here are a couple of examples you may want to set up: +Eğer komutunuzun tamamını yazmazsanız, Git bir kısaltma yaptığınızı otomatik olarak anlayamaz. +Git komutlarının tamamını uzun uzun yazmak istemiyorsanız, `git config` komutunu kullanarak, her komut için kolayca bir kısayol ayarlayabilirsiniz.(((git commands, config))) +Aşağıda kısayol olarak isteyebileceğiniz birkaç örnek verilmiştir: [source,console] ---- @@ -17,18 +17,18 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -This means that, for example, instead of typing `git commit`, you just need to type `git ci`. -As you go on using Git, you'll probably use other commands frequently as well; don't hesitate to create new aliases. +İlk örnekte `git commit` yerine "git ci" komutunu ayarlıyorsunuz. Artık `git ci` yazarsanız Git bunu `git commit` olarak düşünecektir. +Git'i kullanmaya devam ettikçe muhtemelen diğer komutları da sıklıkla kullanacaksınız; yeni kısayollar oluşturmaktan çekinmeyin. -This technique can also be very useful in creating commands that you think should exist. -For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: +Bu tekniği aynı zamanda Git'te mevcut olmayan, ama olması gerektiğini düşündüğünüz komutların oluşturulmasında da kullanabilirsiniz. +Örneğin, bir dosyayı "stage"den kaldırırken karşılaştığınız "kullanılabilirlik" sorununu düzeltmek için Git'e kendi "stage"den kaldırma komutunuzu ekleyebilirsiniz: [source,console] ---- $ git config --global alias.unstage 'reset HEAD --' ---- -This makes the following two commands equivalent: +Bu yeni tanımlanan komut, aşağıdaki iki komutun işini tek başına yapacaktır. [source,console] ---- @@ -36,15 +36,15 @@ $ git unstage fileA $ git reset HEAD -- fileA ---- -This seems a bit clearer. -It's also common to add a `last` command, like this: +Böylesi daha temiz görünüyor. +Bir `last` komutu eklemek de çok yaygındır. Şunun gibi: [source,console] ---- $ git config --global alias.last 'log -1 HEAD' ---- -This way, you can see the last commit easily: +Böylelikle son işlemi kolayca görebilirsiniz: [source,console] ---- @@ -58,11 +58,11 @@ Date: Tue Aug 26 19:48:51 2008 +0800 Signed-off-by: Scott Chacon ---- -As you can tell, Git simply replaces the new command with whatever you alias it for. -However, maybe you want to run an external command, rather than a Git subcommand. -In that case, you start the command with a `!` character. -This is useful if you write your own tools that work with a Git repository. -We can demonstrate by aliasing `git visual` to run `gitk`: +Gördüğünüz gibi Git, yeni komutu her neyin kısayolu olarak ayarlarsanız onunla değiştirir. +Ancak Git alt komutları yerine harici bir komut da çalıştırmak isteyebilirsiniz. +Bu durumda komuta `!` karakteriyle başlamalısınız. +Eğer Git'te çalışan kendi komutlarınızı yazmak istiyorsanız bu epey kullanışlıdır. +Hadi `git visual` komutunu çalıştıracak `gitk` kısayolunu atamayı gösterelim: [source,console] ---- From 417957649ea7be5fcc40ac267946617f57a92c68 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 25 Jan 2024 23:41:04 +0100 Subject: [PATCH 012/210] Create summary.asc add summary section --- book/02-git-basics/sections/summary.asc | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 book/02-git-basics/sections/summary.asc diff --git a/book/02-git-basics/sections/summary.asc b/book/02-git-basics/sections/summary.asc new file mode 100644 index 00000000..8bcab08b --- /dev/null +++ b/book/02-git-basics/sections/summary.asc @@ -0,0 +1,5 @@ +[[_git_basics_summary]] +=== Özet + +Bu noktada, temel yerel Git işlemlerini yapabilirsiniz: bir repo oluşturma (init) veya kopyalama (clone), değişiklikler yapma, bu değişiklikleri aşamalandırma (stage) ve katkı olarak işleme (commit), repo üzerinde geçirilen tüm değişikliklerin geçmişini görüntüleme (log), vs. +Bir sonraki adımda, Git'in öldürücü özelliğini kapsayacağız: dal modelini. From e42fd9c5613c28d8dda4f1615a770e4091cafe5b Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 27 Jan 2024 09:21:02 +0100 Subject: [PATCH 013/210] Update branch-management.asc Transferring the translation of "Branch Management" --- .../sections/branch-management.asc | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index 3b384bab..dad7d4bd 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -1,11 +1,11 @@ [[_branch_management]] -=== Branch Management +=== Dal Yönetimi (((branches, managing))) -Now that you've created, merged, and deleted some branches, let's look at some branch-management tools that will come in handy when you begin using branches all the time. +Şu ana kadar birkaç dal oluşturduk, birleştirdik ve sildik. Şimdi de sürekli olarak dalları kullanmaya başladığınızda işinize yarayacak bazı dal yönetimi araçlarına bakalım. -The `git branch` command does more than just create and delete branches.(((git commands, branch))) -If you run it with no arguments, you get a simple listing of your current branches: +`git branch` komutu, sadece dallar oluşturmak ve silmekle kalmaz.(((git commands, branch))) +Eğer hiç argüman vermeden çalıştırırsanız, mevcut dallarınızın basit bir listesini de elde edersiniz: [source,console] ---- @@ -15,9 +15,9 @@ $ git branch testing ---- -Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out (i.e., the branch that `HEAD` points to). -This means that if you commit at this point, the `master` branch will be moved forward with your new work. -To see the last commit on each branch, you can run `git branch -v`: +`master` dalının önünde yer alan `*` karakterine dikkat edin: bu, şu anda üzerinde çalıştığını (yani, `HEAD`'in işaret ettiği) dalı gösterir. +Bu, eğer şimdi bir katkı işlerseniz `master` dalının yeni çalışmanızla birlikte ileri taşınacağı anlamına gelir. +Her bir dalın son katkısını görmek için `git branch -v` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -27,8 +27,8 @@ $ git branch -v testing 782fd34 add scott to the author list in the readmes ---- -The useful `--merged` and `--no-merged` options can filter this list to branches that you have or have not yet merged into the branch you're currently on. -To see which branches are already merged into the branch you're on, you can run `git branch --merged`: +Kullanışlı `--merged` ve `--no-merged` seçenekleri bu listeyi, şu anda üzerinde bulunduğunuz dala zaten birleştirdiğiniz veya henüz birleştirmediğiniz dallara filtreleyebilir. +Şu anda üzerinde bulunduğunuz dal içine zaten birleştirilmiş olan dalları görmek için `git branch --merged` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -37,10 +37,11 @@ $ git branch --merged * master ---- -Because you already merged in `iss53` earlier, you see it in your list. -Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you've already incorporated their work into another branch, so you're not going to lose anything. +Daha önce `iss53`ü zaten birleştirdiğiniz için, bu dalı listenizde görüyorsunuz. +Bu listede yer alıp önünde `*` olmayan dalları `git branch -d` ile silmek genellikle güvenlidir. +Çünkü zaten bu dallardaki çalışmayı başka bir dala dahil ettiniz ve onları silmek veri kaybına yol açmayacak. -To see all the branches that contain work you haven't yet merged in, you can run `git branch --no-merged`: +Henüz birleştirmediğiniz bir çalışmayı içeren tüm dalları görmek için `git branch --no-merged` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -48,8 +49,8 @@ $ git branch --no-merged testing ---- -This shows your other branch. -Because it contains work that isn't merged in yet, trying to delete it with `git branch -d` will fail: +Bu son komut başka bir dalınızı gösteriyor. +Henüz birleştirilmemiş bir çalışmayı içerdiği için `git branch -d` ile silmeye çalışmak başarısız olacaktır: [source,console] ---- @@ -58,13 +59,14 @@ error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. ---- -If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out. +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. -[TIP] +[İPUCU] ==== -The options described above, `--merged` and `--no-merged` will, if not given a commit or branch name as an argument, show you what is, respectively, merged or not merged into your _current_ branch. +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. + +Dilediğiniz zaman, sadece ek bir argüman girerek, başka bir dala geçiş yapmaksızın o dalın birleştirme durumu hakkında sorgu yazabilirsiniz. Örneğin `master` dala neler birleştirilmemiş gibi: -You can always provide an additional argument to ask about the merge state with respect to some other branch without checking that other branch out first, as in, what is not merged into the `master` branch? [source,console] ---- $ git checkout testing From 21d090f6d0b0b38d8f25249924adb80fb6dc4e62 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 27 Jan 2024 15:59:10 +0100 Subject: [PATCH 014/210] Update remote-branches.asc remote-branches has been translated up to Line:32 --- .../sections/remote-branches.asc | 49 ++++++++++--------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 7da23f97..a9667ddd 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -1,30 +1,33 @@ [[_remote_branches]] -=== Remote Branches +=== Uzak Dallar (((branches, remote)))(((references, remote))) -Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. -You can get a full list of remote references explicitly with `git ls-remote [remote]`, or `git remote show [remote]` for remote branches as well as more information. -Nevertheless, a more common way is to take advantage of remote-tracking branches. - -Remote-tracking branches are references to the state of remote branches. -They're local references that you can't move; Git moves them for you whenever you do any network communication, to make sure they accurately represent the state of the remote repository. -Think of them as bookmarks, to remind you where the branches in your remote repositories were the last time you connected to them. - -Remote-tracking branch names take the form `/`. -For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. -If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch, but the branch on the server would be represented by the remote-tracking branch `origin/iss53`. - -This may be a bit confusing, so let's look at an example. -Let's say you have a Git server on your network at `git.ourcompany.com`. -If you clone from this, Git's `clone` command automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally. -Git also gives you your own local `master` branch starting at the same place as origin's `master` branch, so you have something to work from. - -[NOTE] -.``origin'' is not special +Uzak işaretçiler, uzak repolarınızdaki dalları, etiketleri ve benzerlerini içeren işaretçilerdir. +`git ls-remote [remote]` veya `git remote show [remote]` komutları ile uzak işaretçilerin tam listesini alabilir ve daha fazla bilgi edinebilirsiniz. +Daha yaygın bir yöntem ise uzak izleme dallarından yararlanmaktır. + +Uzak izleme dalları, uzak dalların durumunu gösteren işaretçilerdir. +Bunlar, hareket ettiremeyeceğiniz yerel işaretçilerdir. +Git, herhangi bir ağ iletişimi yaptığınızda bunları sizin için taşır ve bu sayede uzak repo durumunu doğru bir şekilde temsil ettiklerinden emin olur. +Onları, son bağlandığınızda uzak repolarınızdaki dalların nerede olduğunu hatırlatan birer yer işareti gibi düşünebilirsiniz. + +Uzaktan izlenen (remote-tracking) dal isimleri `/` şeklindedir. +Örneğin, `origin` uzak repo ile en son iletişim kurduğunuzda `master` dalının ne durumda olduğunu görmek istiyorsanız, `origin/master` dalına bir göz atarsınız. +Meslektaşlarınızla bir iş paketi üzerinde çalışıyorsanız ve onlar yeni bir katkı işleyerek `iss53` dalını yukarı itmişse; kendi yerel `iss53` dalınız olabilir ancak sunucuda yer alan dal, uzak izleme dalı olan `origin/iss53` tarafından temsil edilir. + +Bu biraz karışık olabileceği için bir örnekle inceleyelim. +Diyelim ki yerel ağınızdaki `git.ourcompany.com` sayfası üzerinde bir Git sunucunuz var. +Eğer bu sunucudan kopyalama işlemi yapıyorsanız, `git clone` komutu otomatik olarak ona `origin` adını verir, tüm verilerini indirir, `master` dalının bulunduğu yeri gösteren bir işaretçi oluşturur ve bu işaretçiyi yerelde `origin/master` olarak adlandırır. +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] +.``origin`` özel değildir ==== -Just like the branch name ``master'' does not have any special meaning in Git, neither does ``origin''. -While ``master'' is the default name for a starting branch when you run `git init` which is the only reason it's widely used, ``origin'' is the default name for a remote when you run `git clone`. -If you run `git clone -o booyah` instead, then you will have `booyah/master` as your default remote branch.(((origin))) +"Master" dal adının Git'te özel bir anlamı olmadığı gibi, "origin" adı da özel bir anlama sahip değildir. +"Master", `git init` komutunu çalıştırdığınızda başlangıç dalı için varsayılan isim olduğu için yaygın olarak kullanılır. +Benzer şekilde, "origin" de `git clone` komutunu çalıştırdığınızda varsayılan uzak sunucu adıdır. +Eğer `git clone -o booyah` şeklinde bir komut çalıştırırsanız, o zaman varsayılan uzak dalınız `booyah/master` olacaktır.(((origin))) ==== .Server and local repositories after cloning From 3204076129311f50f70d58e4353cee47bda90cb4 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 29 Jan 2024 21:20:21 +0100 Subject: [PATCH 015/210] Update remote-branches.asc translated up to line:135 --- .../sections/remote-branches.asc | 93 ++++++++++--------- 1 file changed, 48 insertions(+), 45 deletions(-) diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index a9667ddd..3b45504a 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -30,45 +30,46 @@ Benzer şekilde, "origin" de `git clone` komutunu çalıştırdığınızda vars Eğer `git clone -o booyah` şeklinde bir komut çalıştırırsanız, o zaman varsayılan uzak dalınız `booyah/master` olacaktır.(((origin))) ==== -.Server and local repositories after cloning -image::images/remote-branches-1.png[Server and local repositories after cloning.] +.Kopyalamamadan sonra sunucu ve yerel repolar +image::images/remote-branches-1.png[Kopyalamamadan sonra sunucu ve yerel repolar.] -If you do some work on your local `master` branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its `master` branch, then your histories move forward differently. -Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn't move. +Eğer yerel `master` dalında çalışıyorsanız ve aynı zamanda başka birisi `git.ourcompany.com` üzerine bir değişiklik yüklüyorsa (push), kendi `master` dalını güncelledikce, geçmişleriniz farklı yönlere ilerler. +Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/master` işaretçisi yer değiştirmez. -.Local and remote work can diverge -image::images/remote-branches-2.png[Local and remote work can diverge.] -To synchronize your work with a given remote, you run a `git fetch ` command (in our case, `git fetch origin`). -This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position. +.Yerel ve uzak çalışma farklılaşabilir +image::images/remote-branches-2.png[Yerel ve uzak çalışma farklılaşabilir.] -.`git fetch` updates your remote-tracking branches -image::images/remote-branches-3.png[`git fetch` updates your remote references.] +Belirli bir uzak repo ile çalışmanızı eşzamanlamak (synchronize) için `git fetch ` komutunu çalıştırırsınız (bizim durumumuzda, `git fetch origin`). +Bu komut, `origin`in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri yakalar (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. -To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let's assume you have another internal Git server that is used only for development by one of your sprint teams. -This server is at `git.team1.ourcompany.com`. -You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <>. -Name this remote `teamone`, which will be your shortname for that whole URL. +.`git fetch` uzak takip dallarınızı günceller +image::images/remote-branches-3.png[`git fetch` zak takip dallarınızı günceller.] -.Adding another server as a remote -image::images/remote-branches-4.png[Adding another server as a remote.] +Çoklu uzak sunuculara sahip olmanın ve bu uzak projelerin uzak dallarının nasıl göründüğünü anlamak için, şu hayali senaryoya başvuralım: Diyelim ki sadece çevik takımlarınızdan birisi tarafından geliştirme amaçlı kullanılan başka bir iç Git sunucunuz var ve bu sunucu `git.team1.ourcompany.com` adresinde bulunmaktadır. +Bunu şu an üzerinde çalıştığınız projeye <> bölümünde ele aldığımız gibi `git remote add` komutu ile yeni bir uzak işaretçi olarak ekleyebilirsiniz. +Bu uzak sunucuyu kısaca `teamone` olarak adlandırın. -Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don't have yet. -Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote-tracking branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch. +.Başka bir sunucuyu uzak (remote) olarak eklemek +image::images/remote-branches-4.png[Başka bir sunucuyu uzak olarak eklemek.] -.Remote-tracking branch for `teamone/master` -image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.] +Şimdi, `git fetch teamone` komutunu çalıştırarak, henüz sahip olmadığınız tüm verileri uzak `teamone` sunucusundan çekebilirsiniz. +Bu sunucu şu anda `origin` sunucunuzun sahip olduğu verilerin bir alt kümesine sahip olduğu için, Git hiç veri çekmez ancak `teamone`ın kendi `master` dalındaki katkıya işaret eden `teamone/master` adında bir uzak takip dalı ayarlar. + +.teamone/master` için uzak takip dalı +image::images/remote-branches-5.png[`teamone/master` için uzak takip dalı.] [[_pushing_branches]] -==== Pushing +==== Yükleme (pushing) (((pushing))) -When you want to share a branch with the world, you need to push it up to a remote to which you have write access. -Your local branches aren't automatically synchronized to the remotes you write to -- you have to explicitly push the branches you want to share. -That way, you can use private branches for work you don't want to share, and push up only the topic branches you want to collaborate on. +Bir dalı dünyayla paylaşmak istediğinizde, yazma erişimine sahip olduğunuz bir uzak sunucuya yüklemeniz (push) gerekiyor. +Yerel dallarınız, yazma işlemi yapabileceğiniz uzak sunuculara otomatik olarak eşzamanlandırılmaz; paylaşmak istediğiniz dalları açıkça yüklemeniz gerekir. +Bu şekilde, paylaşmak istemediğiniz işler için özel (private) dallar kullanabilir ve yalnızca işbirliği yapmak istediğiniz tematik dalları yükleyebilirsiniz. + +Eğer diğerleriyle birlikte çalışmak istediğiniz `serverfix` adında bir dalınız varsa, onu ilk dalınızı yüklediğiniz şekilde yükleyebilirsiniz. -If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. -Run `git push `:(((git commands, push))) +`git push ` komutunu çalıştırın:(((git commands, push))) [source,console] ---- @@ -82,26 +83,28 @@ To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix ---- -This is a bit of a shortcut. -Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my serverfix local branch and push it to update the remote's serverfix branch.'' -We'll go over the `refs/heads/` part in detail in <>, but you can generally leave it off. -You can also do `git push origin serverfix:serverfix`, which does the same thing -- it says, ``Take my serverfix and make it the remote's serverfix.'' -You can use this format to push a local branch into a remote branch that is named differently. -If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project. +Bu biraz kısayol gibidir. +Git otomatik olarak `serverfix` dal ismini `refs/heads/serverfix:refs/heads/serverfix` şeklinde genişletir: Bu 'Lütfen benim yerel `serverfix` dalımı al ve onu uzaktaki `serverfix` dalını güncellemek için it' anlamına gelir. +`refs/heads/` kısmını daha sonra <> bölümünde detaylı bir şekilde ele alacağız, ancak bunu genellikle belirtmenize gerek yoktur. +Aynı işlemi gerçekleştiren bir diğer yöntem de `git push origin serverfix:serverfix` şeklinde kullanmaktır. +Bu da 'Lütfen benim `serverfix` dalımı al ve onu uzaktaki `serverfix` dalı yap' anlamına gelir. +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. -[NOTE] -.Don't type your password every time +[NOT] +.Her defasında şifrenizi yazmayın ==== -If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. -By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push. +Eğer bir HTTPS URL'si kullanarak itme (push) işlemi yapıyorsanız, Git sunucusu sizden kimlik doğrulaması için kullanıcı adı ve şifrenizi isteyecektir. +Varsayılan olarak, Git bu bilgileri size terminal üzerinden sorması için bir istekte bulunur. +Böylece sunucu itmeye izin verip vermediğinizi kontrol edebilir. + +Her itme (push) işlemi yaparken bunu her seferinde yazmak istemiyorsanız, bir 'credential cache' (kimlik bilgisi önbelleği) kurabilirsiniz. En basit olanı, bunu birkaç dakika boyunca bellekte tutmaktır ve bunu kolayca `git config --global credential.helper cache` komutunu çalıştırarak yapabilirsiniz. -If you don't want to type it every single time you push, you can set up a ``credential cache''. -The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`. +Çeşitli kimlik bilgisi önbelleği seçenekleri hakkında daha fazla bilgi için <> bölümüne bakabilirsiniz. -For more information on the various credential caching options available, see <>. ==== -The next time one of your collaborators fetches from the server, they will get a reference to where the server's version of `serverfix` is under the remote branch `origin/serverfix`: +Bir sonraki seferde bir meslektaşınız sunucudan veri çektiğinde, sunucunun `serverfix` dalının versiyonuna dair referansı, uzak dal `origin/serverfix` altında olacaktır: [source,console] ---- @@ -114,11 +117,11 @@ From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ---- -It's important to note that when you do a fetch that brings down new remote-tracking branches, you don't automatically have local, editable copies of them. -In other words, in this case, you don't have a new `serverfix` branch -- you have only an `origin/serverfix` pointer that you can't modify. +Yeni uzak takip dallarını getiren bir çekme işlemi yaptığınızda, bunların düzenlenebilir yerel kopyalarına otomatik olarak sahip olmazsınız. +Yani bu durumda, yeni bir `serverfix` dalınız olmaz -- sadece üzerinde değişiklik yapamayacağınız bir `origin/serverfix` işaretçiniz olur. -To merge this work into your current working branch, you can run `git merge origin/serverfix`. -If you want your own `serverfix` branch that you can work on, you can base it off your remote-tracking branch: +Bu çalışmayı mevcut çalışma dalınıza birleştirmek için `git merge origin/serverfix` komutunu çalıştırabilirsiniz. +Eğer üzerinde çalışabileceğiniz kendi `serverfix` dalınızı istiyorsanız, bunu uzak takip dalınızın üzerine kurabilirsiniz: [source,console] ---- @@ -127,7 +130,7 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -This gives you a local branch that you can work on that starts where `origin/serverfix` is. +Böylelikle, `origin/serverfix`'in başladığı yerden devam eden ve üzerinde çalışabileceğiniz bir yerel dal elde etmiş olursunuz. [[_tracking_branches]] ==== Tracking Branches From f23898aea044a493983b4b77b9c9aa0984d5eeab Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 1 Feb 2024 07:46:25 +0100 Subject: [PATCH 016/210] Update workflows.asc 3.4 Branching Workflows has been translated --- book/03-git-branching/sections/workflows.asc | 84 ++++++++++---------- 1 file changed, 43 insertions(+), 41 deletions(-) diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 4ae66a76..519d59c5 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,63 +1,65 @@ -=== Branching Workflows +=== İş Akışı Dallandırması -Now that you have the basics of branching and merging down, what can or should you do with them? -In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate them into your own development cycle. +Artık dallandırma ve birleştirmenin temellerini öğrendiğinize göre bunları ne yapabilirsiniz? +Bu bölümde, bu hafif dallandırma ile mümkün olan bazı yaygın iş akışlarını ele alacağız, böylece bunları kendi geliştirme döngünüze dahil edip etmek istemediğinize karar verebilirsiniz. -==== Long-Running Branches +==== Uzun Ömürlü (long-running) Dallar (((branches, long-running))) -Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. -This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. +Git, basit bir üçlü birleştirmeyi kullandığı için, bir daldan diğerine uzun bir süre boyunca birden fazla kez birleştirme yapmak genellikle kolaydır. +Bu, her zaman açık olan ve geliştirme döngünüzün farklı aşamalarında kullanabileceğiniz birkaç dalınız olabileceği anlamına gelir; bunlardan bazılarını düzenli olarak diğerlerine birleştirebilirsiniz. -Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch -- possibly only code that has been or will be released. -They have another parallel branch named `develop` or `next` that they work from or use to test stability -- it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. -It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs. +Birçok Git geliştiricisi, bu yaklaşımı benimseyen bir iş akışına sahiptir. +Örneğin, `master` dallarında hatasız çalışan (muhtemelen yayımlanmış veya yayımlanacak) dengeli (stabil) kodu bulundurabilirler. +Bunun yanında üzerinde çalışmak veya düzgün çalıştığını test etmek amacıyla `develop` veya `next` adında başka bir paralel dalları daha vardır. Bunların her zaman dengeli olması gerekmez, ancak kararlı (hatasız çalışan) bir duruma geldiğinde `master` dalına birleştirilebilir. +Bu dal, daha altta yer alan konu dallarını (önceki `iss53` dalı gibi kısa ömürlü dalları) içeri çekmek için kullanılır; hazır olduklarında yani tüm testleri geçip hata vermediklerinde ana dala (master) birleştirilir. -In reality, we're talking about pointers moving up the line of commits you're making. -The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history. +Aslında bahsettiğimiz şey, işlediğiniz katkı çizgisinde yukarı yönlü hareket eden işaretçilerdir. +Dengeli dallar, katkı geçmişinizde daha aşağıda yer alırken, en güncel dallar geçmişin daha yukarısındadır. -.A linear view of progressive-stability branching -image::images/lr-branches-1.png[A linear view of progressive-stability branching.] +.dengeli-ilerleme (progressive-stability) yaklaşımının doğrusal görüntüsü +image::images/lr-branches-1.png[dengeli-ilerleme (progressive-stability) yaklaşımının doğrusal görüntüsü.] -It's generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they're fully tested. +Genellikle, bunları iş kuleleri (work silo) olarak düşünmek daha kolaydır, burada katkı grupları tamamen test edildiğinde daha dengeli bir yapıya eklenir. [[lrbranch_b]] -.A ``silo'' view of progressive-stability branching -image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching.] +.dengeli-ilerleme (progressive-stability) yaklaşımının kule görüntüsü +image::images/lr-branches-2.png[dengeli-ilerleme (progressive-stability) yaklaşımının kule görüntüsü.] -You can keep doing this for several levels of stability. -Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. -The idea is that your branches are at various levels of stability; when they reach a more stable level, they're merged into the branch above them. -Again, having multiple long-running branches isn't necessary, but it's often helpful, especially when you're dealing with very large or complex projects. +Bu yaklaşımı farklı denge seviyelerinde sürdürebilirsiniz. +Bazı büyük projeler, henüz `next` veya `master` dallarına bütünleşmeye hazır olmayan birleşik dalları içeren bir `proposed` veya `pu` (proposed updates) dalına sahiptir. +Temel fikir, dallarınızın çeşitli denge (stability) düzeylerinde olmasıdır; daha kararlı (hatasız çalışan) bir düzeye ulaştıklarında, bir üstlerindeki dala birleştirilirler. +Tekrar belirtmek gerekirse, birden çok uzun ömürlü dala sahip olmak zorunlu değildir, ancak özellikle çok büyük veya karmaşık projelerle uğraşılıyorsa genellikle faydalı olur. [[_topic_branch]] -==== Topic Branches +==== Tematik Dallar (topic branch) (((branches, topic))) -Topic branches, however, are useful in projects of any size. -A topic branch is a short-lived branch that you create and use for a single particular feature or related work. -This is something you've likely never done with a VCS before because it's generally too expensive to create and merge branches. -But in Git it's common to create, work on, merge, and delete branches several times a day. +Ancak, tematik dallar herhangi bir boyuttaki projelerde faydalıdır. +Bir tematik dal, yalnızca belirli bir özellik veya ilgili çalışma için oluşturduğunuz kısa ömürlü bir şubedir. +Bu genellikle dalı oluşturmak ve birleştirmek çok maliyetli olduğu için bir sürüm kontrol sistemiyle daha önce muhtemelen yapmadığınız bir şeydir. +Ancak Git'te bir günde birkaç kez dal oluşturmak, üzerinde çalışmak, birleştirmek ve silmek yaygındır." -You saw this in the last section with the `iss53` and `hotfix` branches you created. -You did a few commits on them and deleted them directly after merging them into your main branch. -This technique allows you to context-switch quickly and completely -- because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such. -You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on. +Bunu, oluşturduğunuz `iss53` ve `hotfix` dalları ile bir önceki bölümde gördünüz. +Bu dallarda birkaç katkı işlediniz ve onları ana dalınıza (master) birleştirdikten hemen sonra sildiniz. +Bu teknik, hızlı ve tam bir bağlam değişimi sağlar. Çünkü çalışmanız, tüm değişikliklerin o konuyla ilgili olduğu dallara ayrılmış durumda, böylece kod incelemesi ve benzeri durumlarda neler olduğunu görmek daha kolaydır. +Değişiklikleri orada dakikalarca, günlerce veya aylarca tutabilir ve hazır olduklarında (oluşturuldukları veya üzerinde çalışıldıkları sıraya bakılmaksızın) birleştirebilirsiniz. -Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your `master` branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch). -Your commit history will look something like this: +Örnek olarak, `master` dalı üzerinde çalışıyorsunuz, bir sorunu çözmek için `iss91` dalını oluşturuyorsunuz, bir süre üzerinde çalıştıktan sonra aynı şeyi başka bir şekilde ele almak için `iss91v2` adlı ikinci bir dal oluşturuyorsunuz, `master` dalına geri dönüyorsunuz ve bir süre orada çalıştıktan sonra, belki de iyi bir fikir olup olmadığından emin olmadığınız bir iş üzerinde çalışmak için oradan da `dumbidea` dalını açıyorsunuz. +Katkı geçmişiniz şuna benzer bir görünüme sahip olacak: -.Multiple topic branches -image::images/topic-branches-1.png[Multiple topic branches.] +.Çoklu Tematik Dallar +image::images/topic-branches-1.png[Çoklu Tematik Dallar.] -Now, let's say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. -You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two. -Your history then looks like this: +Şimdi, diyelim ki sorununuza en iyi çözümün `iss91v2` olduğuna karar verdiniz; ve `dumbidea` dalını iş arkadaşlarınıza gösterdiğinizde bunun aslında çok parlak bir fikir olduğu ortaya çıktı. +Orijinal `iss91` dalını (`C5` ve `C6` katkılarını kaybederek) çöpe atabilir ve diğer iki dalı birleştirebilirsiniz. +O zaman geçmişiniz şöyle görünecek: -.History after merging `dumbidea` and `iss91v2` -image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.] +.Birleştirme sonrası `dumbidea` ve `iss91v2` geçmişi +image::images/topic-branches-2.png[Birleştirme sonrası `dumbidea` ve `iss91v2` geçmişi.] -We will go into more detail about the various possible workflows for your Git project in <>, so before you decide which branching scheme your next project will use, be sure to read that chapter. +Git projeniz için çeşitli olası iş akışları hakkında daha fazla detaya <> bölümünde gireceğiz. +Bu nedenle bir sonraki projenizde hangi dallandırma şemasını kullanacağınıza karar vermeden önce bahsi geçen bölümü okuduğunuzdan emin olun. -It's important to remember when you're doing all this that these branches are completely local. -When you're branching and merging, everything is being done only in your Git repository -- there is no communication with the server. +Bunları yaparken önemli olan, tüm bu dalların tamamen yerel olduğunu hatırlamaktır. +Dallandırma ve birleştirme işlemleri yaparken, her şey yalnızca kendi Git repo dosyanızda gerçekleşir ve sunucu ile iletişim yoktur." From b2d573bba19e7cd66cf799f57c1dcedb864cfa2f Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 2 Feb 2024 13:15:05 +0100 Subject: [PATCH 017/210] Update workflows.asc fixing typos --- book/03-git-branching/sections/workflows.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 519d59c5..d2169221 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -38,7 +38,7 @@ Tekrar belirtmek gerekirse, birden çok uzun ömürlü dala sahip olmak zorunlu Ancak, tematik dallar herhangi bir boyuttaki projelerde faydalıdır. Bir tematik dal, yalnızca belirli bir özellik veya ilgili çalışma için oluşturduğunuz kısa ömürlü bir şubedir. Bu genellikle dalı oluşturmak ve birleştirmek çok maliyetli olduğu için bir sürüm kontrol sistemiyle daha önce muhtemelen yapmadığınız bir şeydir. -Ancak Git'te bir günde birkaç kez dal oluşturmak, üzerinde çalışmak, birleştirmek ve silmek yaygındır." +Ancak Git'te bir günde birkaç kez dal oluşturmak, üzerinde çalışmak, birleştirmek ve silmek yaygındır. Bunu, oluşturduğunuz `iss53` ve `hotfix` dalları ile bir önceki bölümde gördünüz. Bu dallarda birkaç katkı işlediniz ve onları ana dalınıza (master) birleştirdikten hemen sonra sildiniz. From b5c3191a59eb75acbd1a6eed966030ccf100c9a0 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 2 Feb 2024 15:14:17 +0100 Subject: [PATCH 018/210] Update rebasing.asc translated up to line:135 --- book/03-git-branching/sections/rebasing.asc | 109 ++++++++++---------- 1 file changed, 56 insertions(+), 53 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index c9e48ede..c4eb8c74 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -1,29 +1,28 @@ [[_rebasing]] -=== Rebasing +=== Temelleme (rebase) (((rebasing))) -In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. -In this section you'll learn what rebasing is, how to do it, why it's a pretty amazing tool, and in what cases you won't want to use it. +Git'te, bir dalın değişikliklerini diğerine birleştirmenin iki ana yolu vardır: `merge` (birleştirme) ve `rebase` (temelleme). Bu bölümde, temellemenin ne olduğunu, nasıl yapıldığını, neden oldukça etkili bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz. -==== The Basic Rebase +==== Basitçe Temelleme (rebase) -If you go back to an earlier example from <<_basic_merging>>, you can see that you diverged your work and made commits on two different branches. +Eğer önceki örneğe, <<_basic_merging>> başlıklı bölüme geri dönerseniz, işinizi dallandırdığınızı ve iki farklı dalda katkı işlediğinizi görebilirsiniz. -.Simple divergent history -image::images/basic-rebase-1.png[Simple divergent history.] +.Basit bir ayrışma geçmişi +image::images/basic-rebase-1.png[Basit bir ayrışma geçmişi.] -The easiest way to integrate the branches, as we've already covered, is the `merge` command. -It performs a three-way merge between the two latest branch snapshots (`C3` and `C4`) and the most recent common ancestor of the two (`C2`), creating a new snapshot (and commit). +Dalları birleştirmenin en kolay yolu, zaten ele aldığımız gibi `merge` komutudur. +Bu komut, iki dalın (`C3` ve `C4`) ve bunların en son ortak öncelinin (`C2`) son pozlarını üçyönlü birleştirerek, yeni bir poz (ve katkı) oluşturur. [[rebasing-merging-example]] -.Merging to integrate diverged work history -image::images/basic-rebase-2.png[Merging to integrate diverged work history.] +.Ayrık çalışma geçmişini birleştirmek +image::images/basic-rebase-2.png[Ayrık çalışma geçmişini birleştirmek.] -However, there is another way: you can take the patch of the change that was introduced in `C4` and reapply it on top of `C3`. -In Git, this is called _rebasing_. -With the `rebase` command, you can take all the changes that were committed on one branch and replay them on a different branch.(((git commands, rebase))) +Ancak, başka bir yol daha vardır: `C4` ile tanıtılan değişikliğin yamasını alabilir ve bunu `C3`'ün üzerine yeniden uygulayabilirsiniz. +Git'te buna _temel alma_ veya _temelleme_ (rebasing) denir. +`rebase` komutu ile bir dalda işlenmiş tüm değişiklikleri alabilir ve bunları farklı bir dala aktararak bir temel olarak kullanabilirsiniz.(((git commands, rebase))) -For this example, you would check out the `experiment` branch, and then rebase it onto the `master` branch as follows: +Bu örnekte, `experiment` dalına geçer ve ardından onu şu şekilde `master` dalına aktarabilirsiniz: [source,console] ---- @@ -33,12 +32,14 @@ First, rewinding head to replay your work on top of it... Applying: added staged command ---- -This operation works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. +Bu işlem, iki dalın (üzerinde bulunduğunuz dal ve temel aldığınız dal) ortak önceline gitmesiyle başlar. +Ardından, üzerinde bulunduğunuz dalın her katkısının getirdiği farkı alır ve bu farkları geçici dosyalara kaydeder. +Mevcut dalı, üzerine temelleme yaptığınız dalın katkıları ile aynı katkıya sıfırlar ve son olarak her değişikliği sırayla uygular. -.Rebasing the change introduced in `C4` onto `C3` -image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.] +.`C4`teki değişikliği `C3` üzerine temelleme +image::images/basic-rebase-3.png[`C4`teki değişikliği `C3` üzerine temelleme.] -At this point, you can go back to the `master` branch and do a fast-forward merge. +Bu noktada, `master` dalına geri dönebilir ve bir ileri-sarma birleştirmesi (fast-forward merge) yapabilirsiniz. [source,console] ---- @@ -46,47 +47,48 @@ $ git checkout master $ git merge experiment ---- -.Fast-forwarding the master branch -image::images/basic-rebase-4.png[Fast-forwarding the master branch.] +.Master dalına ileri-sarma +image::images/basic-rebase-4.png[Master dalına ileri-sarma.] -Now, the snapshot pointed to by `C4'` is exactly the same as the one that was pointed to by `C5` in <>. -There is no difference in the end product of the integration, but rebasing makes for a cleaner history. -If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. +Şu anda, `C4'` tarafından işaret edilen poz, <> örneğinde `C5` tarafından işaret edilen poz ile tam olarak aynıdır. +Birleştirme çıktısında fark yoktur, ancak temelleme daha temiz bir geçmiş sunar. +Eğer `git log` komutuyla temellenmiş bir dalın günlüğünü incelerseniz, doğrusal bir geçmiş görürsünüz. +Başlangıçta eşzamanlı gerçekleşmiş olsa bile, tüm işin sırayla gerçekleştiği izlenimini verir. -Often, you'll do this to make sure your commits apply cleanly on a remote branch -- perhaps in a project to which you're trying to contribute but that you don't maintain. -In this case, you'd do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. -That way, the maintainer doesn't have to do any integration work -- just a fast-forward or a clean apply. +Çoğu zaman bunu, katkılarınızın temiz bir şekilde bir uzak dala uygulanmasını sağlamak için yaparsınız, belki de bir süre üzerinde çalıştığınız ancak sürdürmediğiniz bir projede. +Bu durumda, işinizi bir dalda yapar ve yamalarınızı ana projeye göndermeye hazır olduğunuzda işinizi `origin/master` üzerine temellersiniz. +Bu şekilde, bakım yapan kişinin herhangi bir birleştirme çalışması yapmasına gerek kalmaz - sadece bir ileri-sarma veya temiz bir uygulama yapması yeterlidir. -Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot -- it's only the history that is different. -Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. +Unutmayın ki, bu işlem sonunda elde ettiğiniz poz, ister bir temelleme işlemi için alınmış son temelleme katkısı, isterse birleştirme işlemi sonrası elde ettiğiniz son birleştirme katkısı olsun, aynı pozdur - farklı olan sadece tarihtir. +"Temelleme" (rebase) değişiklikleri tanımlandıkları sırayla bir iş çizgisinden başka bir iş çizgisine aktarırken, "birleştirme" (merge) uç noktaları alır ve bunları birleştirir. -==== More Interesting Rebases +==== Daha Detaylıca Temelleme -You can also have your rebase replay on something other than the rebase target branch. -Take a history like <>, for example. -You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. -Then, you branched off that to make the client-side changes (`client`) and committed a few times. -Finally, you went back to your server branch and did a few more commits. +Temelleme işlemi için hedef aldığınız dal dışında bir dala da temellemenizi uygulayabilirsiniz. +Mesela <> şeklindeki bir tarihçeyi ele alalım: +Projeye sunucu tarafı işlevselliği eklemek için `server` adında tematik bir dal oluşturdunuz ve bir katkı işlediniz. +Ardından, istemci tarafındaki değişiklikleri yapmak için bu daldan ayrılıp `client` dalında birkaç katkı işlediniz. +Son olarak, sunucu dalına geri dönüp birkaç katkı daha işlediniz. [[rbdiag_e]] -.A history with a topic branch off another topic branch -image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch.] +.Bir tematik daldan ayrılan başka bir tematik dalın geçmişi. +image::images/interesting-rebase-1.png[Bir tematik daldan ayrılan başka bir tematik dalın geçmişi.] -Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it's tested further. -You can take the changes on client that aren't on server (`C8` and `C9`) and replay them on your `master` branch by using the `--onto` option of `git rebase`: +Diyelim ki, bir sürüm için kullanıcı tarafındaki değişiklikleri ana dalınıza birleştirmeye karar verdiniz, ancak sunucu tarafındaki değişiklikleri daha fazla test edilene kadar bekletmek istiyorsunuz. +Bu durumda, sunucu tarafında olmayıp (`C8` and `C9`) kullanıcı tarafında olan değişiklikleri alabilir ve onları `git rebase` komutunun `--onto` seçeneğini kullanarak `master` dalınıza temelleyebilirsiniz: [source,console] ---- $ git rebase --onto master server client ---- -This basically says, ``Take the `client` branch, figure out the patches since it diverged from the `server` branch, and replay these patches in the `client` branch as if it was based directly off the `master` branch instead.'' -It's a bit complex, but the result is pretty cool. +Bu temel olarak şunu ifade eder: " `client` dalını al, bu dalın `server` dalından ayrıldığından bu yana yapılan yamaları belirle ve bu yamaları `client` dalında, sanki doğrudan `master` dalından temellenmiş gibi temelle." +Biraz karmaşık gibi görünebilir, ancak sonuç oldukça etkileyicidir. -.Rebasing a topic branch off another topic branch -image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch.] +.Tematik bir daldan yeni bir tematik dal temelleme +image::images/interesting-rebase-2.png[Tematik bir daldan yeni bir tematik dal temelleme.] -Now you can fast-forward your `master` branch (see <>): +Artık `master` dalınızı ileri sarabilirsiniz (bkz. <>): [source,console] ---- @@ -95,24 +97,25 @@ $ git merge client ---- [[rbdiag_g]] -.Fast-forwarding your master branch to include the client branch changes -image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.] +.`master` dalını `client` dalındaki değişiklikleri içerecek şekilde ileri sarmak. +image::images/interesting-rebase-3.png[`master` dalını `client` dalındaki değişiklikleri içerecek şekilde ileri sarmak.] -Let's say you decide to pull in your server branch as well. -You can rebase the server branch onto the `master` branch without having to check it out first by running `git rebase ` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`): +Diyelim ki sunucu dalını da eklemeye karar verdiniz. +`git rebase ` komutunu çalıştırarak, öncesinde dalınızı değiştirmeden, sunucu dalını `master` dalına tekrar temelleyebilirsiniz. +Bu komut, ilgili tema dalına (burada `server`) geçiş yapar ve onu temel dal üzerine (burada `master`) temeller. [source,console] ---- $ git rebase master server ---- -This replays your `server` work on top of your `master` work, as shown in <>. +Bu, <> diyagramında gösterildiği gibi `server` çalışmanızı `master` çalışmanızın üzerine temeller. [[rbdiag_h]] -.Rebasing your server branch on top of your master branch -image::images/interesting-rebase-4.png[Rebasing your server branch on top of your master branch.] +.`server` dalını `master` dalının üzerine temelleme. +image::images/interesting-rebase-4.png[`server` dalını `master` dalının üzerine temelleme.] -Then, you can fast-forward the base branch (`master`): +Ardından, temel dalınıza (`master`) ileri sarabilirsiniz: [source,console] ---- @@ -120,7 +123,7 @@ $ git checkout master $ git merge server ---- -You can remove the `client` and `server` branches because all the work is integrated and you don't need them anymore, leaving your history for this entire process looking like <>: +Tüm çalışmalar birleştirildiği için artık `client` ve `server` dallarını silebilirsiniz, çünkü bu sürecin tüm geçmişi zaten <> şeklinde görünecektir: [source,console] ---- From 8a04e589c023c278ef54cd19ea5062156fcc9ed5 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 2 Feb 2024 23:47:05 +0100 Subject: [PATCH 019/210] Update rebasing.asc "3.6 Rebasing" translated --- book/03-git-branching/sections/rebasing.asc | 143 ++++++++++---------- 1 file changed, 73 insertions(+), 70 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index c4eb8c74..945a17e9 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -71,7 +71,7 @@ Ardından, istemci tarafındaki değişiklikleri yapmak için bu daldan ayrılı Son olarak, sunucu dalına geri dönüp birkaç katkı daha işlediniz. [[rbdiag_e]] -.Bir tematik daldan ayrılan başka bir tematik dalın geçmişi. +.Bir tematik daldan ayrılan başka bir tematik dalın geçmişi image::images/interesting-rebase-1.png[Bir tematik daldan ayrılan başka bir tematik dalın geçmişi.] Diyelim ki, bir sürüm için kullanıcı tarafındaki değişiklikleri ana dalınıza birleştirmeye karar verdiniz, ancak sunucu tarafındaki değişiklikleri daha fazla test edilene kadar bekletmek istiyorsunuz. @@ -97,7 +97,7 @@ $ git merge client ---- [[rbdiag_g]] -.`master` dalını `client` dalındaki değişiklikleri içerecek şekilde ileri sarmak. +.`master` dalını `client` dalındaki değişiklikleri içerecek şekilde ileri sarmak image::images/interesting-rebase-3.png[`master` dalını `client` dalındaki değişiklikleri içerecek şekilde ileri sarmak.] Diyelim ki sunucu dalını da eklemeye karar verdiniz. @@ -112,7 +112,7 @@ $ git rebase master server Bu, <> diyagramında gösterildiği gibi `server` çalışmanızı `master` çalışmanızın üzerine temeller. [[rbdiag_h]] -.`server` dalını `master` dalının üzerine temelleme. +.`server` dalını `master` dalının üzerine temelleme image::images/interesting-rebase-4.png[`server` dalını `master` dalının üzerine temelleme.] Ardından, temel dalınıza (`master`) ileri sarabilirsiniz: @@ -132,110 +132,113 @@ $ git branch -d server ---- [[rbdiag_i]] -.Final commit history -image::images/interesting-rebase-5.png[Final commit history.] +.Nihai katkı geçmişi +image::images/interesting-rebase-5.png[Nihai katkı geçmişi.] [[_rebase_peril]] -==== The Perils of Rebasing +==== Temellemenin Riskleri (((rebasing, perils of))) -Ahh, but the bliss of rebasing isn't without its drawbacks, which can be summed up in a single line: +Temelleme getirdiği kolaylıkların yanında malesef bazı dezavantajları da içerir. +Bu riskleri tek cümlede özetlemek mümkündür: -*Do not rebase commits that exist outside your repository and people may have based work on them.* +*Repo dışında var olan ve üzerine çalışılmış olabilecek katkıları temellemeyin.* -If you follow that guideline, you'll be fine. -If you don't, people will hate you, and you'll be scorned by friends and family. +Eğer bu kılavuzu takip ederseniz, sorun yaşamazsınız. +Ama anlatacağımız yönergelere uymazsanız, insanlar sizi sevmeyecek; dostlarınız ve aileniz tarafından hor görüleceksiniz. -When you rebase stuff, you're abandoning existing commits and creating new ones that are similar but different. -If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours. +Birşeyleri temellediğinizde (rebase), mevcut katkıları (commit) terk ediyor ve benzer ancak farklı olan yeni katkılar oluşturuyorsunuz. +Eğer katkılarınızı bir yere iterseniz (push) ve başkaları bunları çekip (pull), üzerine çalışma yaparsa, ve daha sonra bu katkıları `git rebase` ile değiştirip tekrar iterseniz, çalışma arkadaşlarınız kendi çalışmalarını tekrar birleştirmek (merge) zorunda kalacak ve onların çalışmalarını kendi projenize çekmeye çalıştığınızda bir karışıklık ortaya çıkacaktır. -Let's look at an example of how rebasing work that you've made public can cause problems. -Suppose you clone from a central server and then do some work off that. -Your commit history looks like this: +Herkese açık bir şekilde yayımladığınız çalışmayı temellemenin nasıl sorunlara yol açabileceğine dair bir örneğe bakalım. +Merkezi bir sunucudan bir repo kopyaladığınızı ve ardından biraz çalışma yaptığınızı düşünelim. +katkı geçmişiniz şu şekilde görünüyor: -.Clone a repository, and base some work on it -image::images/perils-of-rebasing-1.png["Clone a repository, and base some work on it."] +.Bir repo kopyala ve üzerine bazı çalışmalar temelle +image::images/perils-of-rebasing-1.png["Bir repo kopyala ve üzerine bazı çalışmalar temelle."] -Now, someone else does more work that includes a merge, and pushes that work to the central server. -You fetch it and merge the new remote branch into your work, making your history look something like this: +Şimdi, başka biri birleştirme içeren bazı çalışmalar yapar ve bu çalışmayı merkezi sunucuya iter. +Siz bunu çeker ve yeni uzak dalı kendi çalışmanıza birleştirirsiniz, geçmişiniz şöyle görünebilir: -.Fetch more commits, and merge them into your work -image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work."] +.Daha fazla katkı getir ve onları kendi çalışmana birleştir +image::images/perils-of-rebasing-2.png["Daha fazla katkı getir ve onları kendi çalışmana birleştir."] -Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. -You then fetch from that server, bringing down the new commits. +Ardından, birleştirilmiş çalışmayı iten kişi, bunun yerine, geriye gidip çalışmaya temelleme yapmaya karar verir. +Bunun için `git push --force` kullanarak sunucudaki geçmişin üzerine yazar. +Siz de bu sunucudan çekerseniz, yeni katkıları getirirsiniz. [[_pre_merge_rebase_work]] -.Someone pushes rebased commits, abandoning commits you've based your work on -image::images/perils-of-rebasing-3.png["Someone pushes rebased commits, abandoning commits you've based your work on."] +.Birisi çalışmanıza temellediğiniz katkıları terkedip, temellenmiş katkıları iter +image::images/perils-of-rebasing-3.png["Birisi çalışmanıza temellediğiniz katkıları terkedip, temellenmiş katkıları iter."] -Now you're both in a pickle. -If you do a `git pull`, you'll create a merge commit which includes both lines of history, and your repository will look like this: +Şimdi her ikiniz de çıkmazdasınız. +Eğer bir `git pull` yaparsanız, her iki geçmiş çizgisini de içeren birleştirme katkısı oluşturursunuz ve repo şu şekilde görünecektir: [[_merge_rebase_work]] -.You merge in the same work again into a new merge commit -image::images/perils-of-rebasing-4.png[You merge in the same work again into a new merge commit.] +.Aynı çalışmayı tekrar yeni bir birleştirme katkısına dahil edersiniz +image::images/perils-of-rebasing-4.png[Aynı çalışmayı tekrar yeni bir birleştirme katkısına dahil edersiniz.] -If you run a `git log` when your history looks like this, you'll see two commits that have the same author, date, and message, which will be confusing. -Furthermore, if you push this history back up to the server, you'll reintroduce all those rebased commits to the central server, which can further confuse people. -It's pretty safe to assume that the other developer doesn't want `C4` and `C6` to be in the history; that's why they rebased in the first place. +Eğer geçmişiniz bu şekilde göründüğünde bir `git log` komutu çalıştırırsanız; aynı yazar, tarih ve mesajı taşıyan iki katkı göreceksiniz ki bu da kafa karıştırıcı olacaktır. +Dahası, eğer bu geçmişi tekrar sunucuya iterseniz, tüm bu temellenmiş katkıları merkezi sunucuya tekrar eklemiş olursunuz ki bu insanların kafasını daha da karıştırabilir. +Diğer geliştiricinin (en başta temelleme yaptığı için), `C4` ve `C6`'nın geçmişte olmasını istemediğini varsayabiliriz. [[_rebase_rebase]] -==== Rebase When You Rebase +==== Temelleme Yaparken Dikkat Edilmesi Gerekenler -If you *do* find yourself in a situation like this, Git has some further magic that might help you out. -If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten. +Eğer kendinizi böyle bir durumda bulunursanız, Git size yardımcı olabilecek bazı ek özellikler sunar. +Eğer takımınızdaki birisi, temellediğiniz bir işin üzerine yazan değişiklikleri zorla iterse (force push), karşılaşacağınız gerçek sorun hangi kodun size ait olduğu ve hangisinin üzerine yeniden yazılan olduğunu bulmaktır. -It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. -This is called a ``patch-id''. +Git, katkının SHA-1 sağlamasına ek olarak, yalnızca katkı ile tanıtılan yamaya dayalı bir sağlama da hesaplar. +Buna ``patch-id'' denir. -If you pull down work that was rewritten and rebase it on top of the new commits from your partner, Git can often successfully figure out what is uniquely yours and apply them back on top of the new branch. +Eğer üzerine yeniden yazılan işi çekerseniz ve bu işi meslektaşınızın yeni katkıları üzerine temellerseniz; Git genellikle sizin çalışmanızın hangisi olduğunu başarılı bir şekilde bulabilir ve bunları yeni dalın üzerine uygulayabilir. -For instance, in the previous scenario, if instead of doing a merge when we're at <<_pre_merge_rebase_work>> we run `git rebase teamone/master`, Git will: +Örneğin, önceki senaryoda, <<_pre_merge_rebase_work>> noktasındayken birleştirme (merge) yerine `git rebase teamone/master` komutunu çalıştırırsak, Git şunları yapacaktır: -* Determine what work is unique to our branch (C2, C3, C4, C6, C7) -* Determine which are not merge commits (C2, C3, C4) -* Determine which have not been rewritten into the target branch (just C2 and C3, since C4 is the same patch as C4') -* Apply those commits to the top of `teamone/master` +* Dalımıza özgü işleri belirle (C2, C3, C4, C6, C7) +* Hangilerinin birleştirme katkısı olmadığını belirle (C2, C3, C4) +* Hangilerinin hedef dalda üzerine yeniden yazılmadığını belirle (C4, C4' ile aynı yama olduğu için sadece C2 ve C3) +* Tüm bu katkıları `teamone/master`'ın üstüne uygula -So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>. +Bu durumda, <<_merge_rebase_work>> görüntüsündeki sonuç yerine, daha ziyade <<_rebase_rebase_work>> benzeri bir sonuç elde ederiz. [[_rebase_rebase_work]] -.Rebase on top of force-pushed rebase work. -image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.] +.Zorla itilmiş temelleme (force-push rebase) üzerine temelleme +image::images/perils-of-rebasing-5.png[Zorla itilmiş temelleme üzerine temelleme] -This only works if C4 and C4' that your partner made are almost exactly the same patch. -Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there). +Bu sadece meslektaşınızın yaptığı C4 ve C4' katkılarının neredeyse tamamen aynı yama olması durumunda çalışır. +Aksi takdirde, temelleme bunun bir kopya olduğunu anlayamaz ve başka bir C4 benzeri yama ekler (değişiklikler zaten en azından bir dereceye kadar mevcut olacağı için, bu muhtemelen düzgün bir şekilde uygulanamaz). -You can also simplify this by running a `git pull --rebase` instead of a normal `git pull`. -Or you could do it manually with a `git fetch` followed by a `git rebase teamone/master` in this case. +Bunu normal bir `git pull` yerine `git pull --rebase` komutunu çalıştırarak daha da basitleştirebilirsiniz. +Veya bu durumda bir `git fetch` ve ardından `git rebase teamone/master` komutu kullanarak manuel olarak da gerçekleştirebilirsiniz. -If you are using `git pull` and want to make `--rebase` the default, you can set the `pull.rebase` config value with something like `git config --global pull.rebase true`. +Eğer `git pull` kullanıyorsanız ve `--rebase`'yi varsayılan yapmak istiyorsanız, `git config --global pull.rebase true` gibi bir komutla `pull.rebase` yapılandırmasını ayarlayabilirsiniz. -If you only ever rebase commits that have never left your own computer, you'll be just fine. -If you rebase commits that have been pushed, but that no one else has based commits from, you'll also be fine. -If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates. +Eğer sadece kendi bilgisayarınızdan hiç ayrılmamış katkıları temelliyorsanız, sorun yaşamazsınız. +Eğer itilmiş ancak kimsenin bunlardan temellemediği katkıları temelliyorsanız, yine sorun yaşamazsınız. +Ancak eğer zaten herkese açık bir şekilde itilmiş ve birileri bu katkılardan temelleme yapmışsa, o zaman sıkıntılı bir durumla karşılaşabilir ve takım arkadaşlarınızın tepkisini çekebilirsiniz. -If you or a partner does find it necessary at some point, make sure everyone knows to run `git pull --rebase` to try to make the pain after it happens a little bit simpler. +Eğer siz veya bir meslektaşınız bunu gerekli görürse, bu sıkıntıyı biraz daha basitleştirmeye çalışmak için, herkesin `git pull --rebase` komutunu çalıştırmayı bildiğinden emin olun. -==== Rebase vs. Merge +==== Temelleme (rebase) ve Birleştirme (merge) (((rebasing, vs. merging)))(((merging, vs. rebasing))) -Now that you've seen rebasing and merging in action, you may be wondering which one is better. -Before we can answer this, let's step back a bit and talk about what history means. +Temelleme ve birleştirmeyi öğrendiğinize göre hangisinin daha iyi olduğunu merak ediyor olabilirsiniz. +Bunu yanıtlayabilmek için biraz geriye gitmek ve geçmişin ne anlama geldiğini konuşmak gerekiyor. -One point of view on this is that your repository's commit history is a *record of what actually happened.* -It's a historical document, valuable in its own right, and shouldn't be tampered with. -From this angle, changing the commit history is almost blasphemous; you're _lying_ about what actually transpired. -So what if there was a messy series of merge commits? -That's how it happened, and the repository should preserve that for posterity. +Bu konudaki bir bakış açısı, repo katkı geçmişinin *aslında nelerin gerçekleştiğinin bir kaydı* olduğudur. +Bu oynanmaması gereken, çok değerli ve tarihi bir belgedir. +Bu açıdan bakıldığında, katkı geçmişini değiştirmek neredeyse şirktir. +Çünkü tarihi tahrif ederek, gerçekte neler olduğu hakkında _yalan_ söylemiş olursunuz. +Yani karışık bir dizi birleştirme katkısı varsa ne olmuş ki? +İşte öyle olduysa bile repo bunu gelecek nesiller için korumalıdır. -The opposing point of view is that the commit history is the *story of how your project was made.* -You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing. -This is the camp that uses tools like rebase and filter-branch to tell the story in the way that's best for future readers. +Karşıt bakış açısı, katkı geçmişinin *projenizin nasıl yapıldığını anlatan bir hikaye* olduğudur. +Bir kitabın ilk taslağını yayımlamazsınız ve yazılımınızı nasıl sürdüreceğiniz konusundaki kılavuz, dikkatli bir düzenlemeyi hak eder. +Bu görüştekiler "temelleme" ve "dal filtreleme" gibi araçları kullanarak hikayeyi gelecekteki okuyucular için en iyi şekilde anlatan kişilerdir. -Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple. -Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different. -Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation. +Şimdi, birleştirmenin mi yoksa temellemenin mi daha iyi olduğu sorusuna gelince: bunun o kadar da basit bir soru olmadığını anladığınızı ümidediyorum. +Git geçmişinizle ilgili birçok şey yapmanıza izin veren güçlü bir araçtır, ancak her ekip ve her proje de farklıdır. +Her iki işlemin de nasıl çalıştığını bildiğinize göre, hangisinin sizin özel durumunuz için en iyi olduğuna siz karar vereceksiniz. -In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere. +Genel olarak, her iki yaklaşımdan da en iyi şekilde faydalanmanın yolu, henüz paylaşmadığınız yerel değişiklikleri itmeden önce temelleme yaparak geçmişi temizlemektir, ancak herhangi bir sunucuya ittiğiniz bir şeyi asla temelleme yapmamaktır. From 7b4230431187a6926c87124c1c9f3ed6c380346b Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 2 Feb 2024 23:54:29 +0100 Subject: [PATCH 020/210] Create summary.asc add summary section --- book/03-git-branching/sections/summary.asc | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 book/03-git-branching/sections/summary.asc diff --git a/book/03-git-branching/sections/summary.asc b/book/03-git-branching/sections/summary.asc new file mode 100644 index 00000000..33f9195b --- /dev/null +++ b/book/03-git-branching/sections/summary.asc @@ -0,0 +1,7 @@ +[[_git_branching_summary]] +=== Özet + +Git'te temel dal oluşturma ve birleştirme konularını ele aldık. +Artık yeni dallar oluşturmak, dallar arasında geçiş yapmak ve yerel dalları birleştirmek konularında kendinizi rahat hissediyor olmalısınız. +Ayrıca, dallarınızı paylaşabilir ve bunları paylaşılan bir sunucuya iterek başkalarıyla çalışabilir, dallarınızı paylaşılmadan önce temelleyebilirsiniz. +Sırada, kendi Git repo barındırma sunucunuzu çalıştırmak için neleri bilmeniz gerektiğini ele alacağız. From c56cc99964a24fbaa465be5891e0651268e613dc Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 3 Feb 2024 00:10:40 +0100 Subject: [PATCH 021/210] Update basic-branching-and-merging.asc the file is completely translated --- .../sections/basic-branching-and-merging.asc | 119 +++++++++--------- 1 file changed, 60 insertions(+), 59 deletions(-) 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 c7626d8e..7ca00fcc 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,4 +1,4 @@ -=== Basitçe Dallandırma ve Birleştirme +=== Kısaca Dallandırma ve Birleştirme Şimdi gerçek dünyada kullanabileceğiniz bir iş akışıyla basit bir dallandırma ve birleştirme örneğini inceleyelim. Bu adımları takip edeceksiniz: @@ -16,7 +16,7 @@ Diyelim ki bu aşamada, başka bir sorunun daha kritik olduğuna ve acilen düze . Asıl kullanıcı hikayenize geri dönün ve çalışmaya devam edin. [[_basic_branching]] -==== Basitçe Dallandırma +==== Kısaca Dallandırma (branching) (((branches, basic workflow))) İlk olarak, projeniz üzerinde çalışıyorsunuz ve `master` dalında halihazırda birkaç katkınız var diyelim. @@ -104,18 +104,19 @@ Fast-forward 1 file changed, 2 insertions(+) ---- -You'll notice the phrase ``fast-forward'' in that merge. -Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you're on, Git simply moves the pointer forward. -To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together -- this is called a ``fast-forward.'' +Bu birleştirmede ``fast-forward`` ifadesini fark edeceksiniz. +Çünkü birleştirdiğiniz `hotfix` dalını işaret eden `C4` katkısı, üzerinde bulunduğunuz `C2` katkısından doğrudan ilerideydi, Git sadece işaretçiyi ileri taşıdı. +Başka bir deyişle, bir katkıyı, katkı geçmişini takip ederek ulaşılabilen bir katkıyla birleştirmeye çalıştığınızda, birleştirilecek ayrı çalışma olmadığından, Git işaretçiyi doğrudan ileri taşıyarak işleri basitleştirir. +Buna ``fast-forward`` (ileri sarma) denir. -Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. +Artık değişikliğiniz, `master` dalının işaret ettiği katkı anlık görüntüsünde bulunuyor ve düzeltmeyi artık yükleyebilirsiniz. -.`master` is fast-forwarded to `hotfix` -image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.] +.`master`, `hotfix`e doğru ileri sarıldı +image::images/basic-branching-5.png[`master`, `hotfix`e doğru ileri sarıldı.] -After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted. -However, first you'll delete the `hotfix` branch, because you no longer need it -- the `master` branch points at the same place. -You can delete it with the `-d` option to `git branch`: +Bu süper önemli düzeltmeniz yüklendikten sonra, kesintiye uğradığınız çalışmaya geri dönmeye hazırsınız. +Neticede `master` dalı da aynı yere işaret ettiği için, artık ihtiyacınız olmayan, `hotfix` dalını sileceksiniz. +Bu dalı `git branch` komutunun `-d` seçeneği ile silebilirsiniz: [source,console] ---- @@ -123,7 +124,7 @@ $ git branch -d hotfix Deleted branch hotfix (3a0874c). ---- -Now you can switch back to your work-in-progress branch on issue #53 and continue working on it. +Şimdi #53 sorunu üzerindeki bekleyen işinize geri dönebilir ve çalışmaya devam edebilirsiniz. [source,console] ---- @@ -135,19 +136,19 @@ $ git commit -a -m 'finished the new footer [issue 53]' 1 file changed, 1 insertion(+) ---- -.Work continues on `iss53` -image::images/basic-branching-6.png[Work continues on `iss53`.] +.`iss53` üzerinde devam eden iş +image::images/basic-branching-6.png[`iss53` üzerinde devam eden iş.] -It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. -If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. +Burada `hotfix` dalında yaptığınız çalışmanın `iss53` dalındaki dosyalarda bulunmadığını unutmayın. +Eğer onu çekmeniz gerekiyorsa, `git merge master` komutunu çalıştırarak `master` dalını `iss53` dalına kaynaştırabilirsiniz, veya bu değişiklikleri birleştirmek için `iss53` dalını daha sonra `master` dalına çekmeye karar verene kadar bekleyebilirsiniz. [[_basic_merging]] -==== Basic Merging +==== Kısaca Birleştirme (merging) (((branches, merging)))(((merging))) -Suppose you've decided that your issue #53 work is complete and ready to be merged into your `master` branch. -In order to do that, you'll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. -All you have to do is check out the branch you wish to merge into and then run the `git merge` command: +Diyelimk ki #53 sorunu üzerindeki çalışmanızın tamamlandığına ve `master` dalına birleştirilmeye hazır olduğuna karar verdiniz. +Bunu yapmak için, aynı `hotfix` dalınızı daha önce birleştirdiğiniz gibi, `iss53` dalınızı da `master` dalına birleştireceksiniz. +Yapmanız gereken tek şey, birleştirmek istediğiniz dala geçmek ve ardından `git merge` komutunu çalıştırmaktır: [source,console] ---- @@ -159,22 +160,22 @@ index.html | 1 + 1 file changed, 1 insertion(+) ---- -This looks a bit different than the `hotfix` merge you did earlier. -In this case, your development history has diverged from some older point. -Because the commit on the branch you're on isn't a direct ancestor of the branch you're merging in, Git has to do some work. -In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. +Bu, önceki yaptığınız "hotfix" birleştirmesinden biraz farklı görünüyor. +Mevcut durumda, geliştirme geçmişiniz eski bir katkıdan itibaren ayrılmış durumda. +Çünkü üzerinde bulunduğunuz dalın son katkısı, birleştirmeye çalıştığınız dalın doğrudan önceli değilse, Git bazı işlemleri gerçekleştirmek zorundadır. +Yukarıdaki senaryoda, Git bu iki dalın ortak öncelini ve her iki dal ucu tarafından işaret edilen iki farklı anlık görüntüyü kullanarak, üç yollu bir birleştirme yapar. -.Three snapshots used in a typical merge -image::images/basic-merging-1.png[Three snapshots used in a typical merge.] +.Tipik bir birleştirmede kullanılan üç adet anlık görüntü +image::images/basic-merging-1.png[Tipik bir birleştirmede kullanılan üç adet anlık görüntü.] -Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. -This is referred to as a merge commit, and is special in that it has more than one parent. +Sadece dal işaretçisini ileri taşımak yerine, Git, bu üç yollu birleştirmenin sonucu olan yeni bir anlık görüntü oluşturur ve otomatik olarak ona işaret eden yeni bir katkı oluşturur. +Buna birleştirme katkısı denir ve birden fazla üst dala sahip olması bakımından özeldir. -.A merge commit -image::images/basic-merging-2.png[A merge commit.] +.Bir birleştirme katkısı +image::images/basic-merging-2.png[Bir birleştirme katkısı.] -Now that your work is merged in, you have no further need for the `iss53` branch. -You can close the ticket in your ticket-tracking system, and delete the branch: +Şimdi çalışmanız birleştirildiğine göre `iss53` dalına artık ihtiyacınız yok. +İş takip sisteminizdeki biletinizi (ticket) kapatabilir ve dalı silebilirsiniz: [source,console] ---- @@ -182,12 +183,12 @@ $ git branch -d iss53 ---- [[_basic_merge_conflicts]] -==== Basic Merge Conflicts +==== Birleştirme Çakışması (merge conflict) (((merging, conflicts))) -Occasionally, this process doesn't go smoothly. -If you changed the same part of the same file differently in the two branches you're merging, Git won't be able to merge them cleanly. -If your fix for issue #53 modified the same part of a file as the `hotfix` branch, you'll get a merge conflict that looks something like this: +Bazen birleştirme süreci sorunsuz tamamlanamayabilir. +Eğer bir dosyanın aynı kısmını, iki farklı dalda iki farklı şekilde değiştirdiyseniz, Git bu değişimlerden hangisini birleştirmeye katacağını bilemeyeceği için, temiz bir birleştirme işlemi yapamaz. +Eğer #53 sorunu için yaptığınız düzeltme, `hotfix` dalının aynı dosyasının aynı bölümünü değiştirmişse, aşağıdakine benzer bir çakışma uyarısı (merge conflict) alacaksınız: [source,console] ---- @@ -197,9 +198,9 @@ CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. ---- -Git hasn't automatically created a new merge commit. -It has paused the process while you resolve the conflict. -If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: +Git otomatik olarak yeni bir birleştirme katkısı oluşturmadı. +Siz çakışmayı çözene kadar süreci duraklattı. +Eğer çakışma uyarısı aldıktan sonra hangi dosyaların birleştirilmediğini görmek istiyorsanız, `git status` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -216,9 +217,9 @@ Unmerged paths: no changes added to commit (use "git add" and/or "git commit -a") ---- -Anything that has merge conflicts and hasn't been resolved is listed as unmerged. -Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. -Your file contains a section that looks something like this: +Çakışmaları çözülmemiş olan her şey "unmerged" (birleştirilmemiş) olarak listelenir. +Git, çakışmaları olan dosyalara "standart çakışma çözüm işaretçilerini" ekler, böylece bunları manuel olarak açabilir ve çakışmaları çözebilirsiniz. +Dosyanız, aşağıdakine benzer bir bölüm içerir: [source,html] ---- @@ -231,9 +232,9 @@ Your file contains a section that looks something like this: >>>>>>> iss53:index.html ---- -This means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. -In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. -For instance, you might resolve this conflict by replacing the entire block with this: +Bunun anlamı: `=======` işaretinin üstündeki her şey `HEAD` (`merge` komutunu çalıştırdığınızda üzerinde bulunduğunuz dal yani bu senaryoda `master` dalı) içindeki versiyonu gösterirken, işaretin altındaki kısımların ise `iss53` dalı içindeki versiyonu gösterdiğidir. +Çakışmayı çözmek için ya bir tarafı ya da diğerini seçmek yahut da içeriği kendiniz birleştirmek zorundasınız. +Örneğin, bu çakışmayı aşağıdaki gibi tüm bloğu değiştirerek çözebilirsiniz: [source,html] ---- @@ -242,11 +243,11 @@ please contact us at email.support@github.com ---- -This resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. -After you've resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. -Staging the file marks it as resolved in Git. +Bu çözüm, her iki bölümün birazını içerir ve `<<<<<<<`, `=======` ve `>>>>>>>` satırları tamamen kaldırılmıştır. +Her bir çakışmış dosyanın her bir çakışmasını çözdükten sonra, her bir dosya üzerinde `git add` komutunu çalıştırarak onu çözülmüş olarak işaretleyin. +Dosyayı aşamalandırmaya (stage) koymak, Git'te çözülmüş olarak işaretler. -If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:(((git commands, mergetool))) +Bu sorunları çözmek için grafiksel bir araç kullanmak istiyorsanız, `git mergetool` komutunu çalıştırabilirsiniz. Bu, uygun bir görsel birleştirme aracını başlatır ve çakışmaları çözme sürecinde sizi yönlendirir:(((git commands, mergetool))) [source,console] ---- @@ -265,17 +266,17 @@ Normal merge conflict for 'index.html': Hit return to start merge resolution tool (opendiff): ---- -If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on a Mac), you can see all the supported tools listed at the top after ``one of the following tools.'' -Just type the name of the tool you'd rather use. +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. -[NOTE] +[NOT] ==== -If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <>. +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. ==== -After you exit the merge tool, Git asks you if the merge was successful. -If you tell the script that it was, it stages the file to mark it as resolved for you. -You can run `git status` again to verify that all conflicts have been resolved: +Birleştirme aracından çıktıktan sonra, Git size birleştirmenin başarılı olup olmadığını sorar. +Eğer başarılı olduysa, dosyayı çatışması çözüldü olarak işaretlemek üzere aşamalandırmaya (stage) gönderir. +Tüm çakışmaların çözüldüğünü doğrulamak için tekrar `git status` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -289,8 +290,8 @@ Changes to be committed: modified: index.html ---- -If you're happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. -The commit message by default looks something like this: +Eğer bu durumdan memnunsanız ve çakışmaları olan her şeyin aşamalandırıldığını doğruladıysanız, birleştirme işlemini sonuca ulaştırmak için `git commit` komutunu yazabilirsiniz. +Varsayılan olarak, katkı mesajı şu şekilde görünür: [source,console] ---- @@ -315,4 +316,4 @@ Conflicts: # ---- -If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious. +Eğer bu açıklamalar yeterli değilse ve gelecekte bu birleşmeyi inceleyecek diğer kullanıcılara yardımcı olabileceğini düşünüyorsanız; bu katkı mesajını çakışmayı nasıl çözdüğünüz ve yaptığınız değişiklikleri neden yaptığınızı açıklayacak şekilde değiştirebilirsiniz. From c0fa358f0bce26dfda0bc3e47cb3b79baf145eb4 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 3 Feb 2024 00:15:36 +0100 Subject: [PATCH 022/210] Update remote-branches.asc the file is completely translated --- .../sections/remote-branches.asc | 102 +++++++++--------- 1 file changed, 52 insertions(+), 50 deletions(-) diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 3b45504a..13b7a6be 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -33,7 +33,7 @@ Eğer `git clone -o booyah` şeklinde bir komut çalıştırırsanız, o zaman v .Kopyalamamadan sonra sunucu ve yerel repolar image::images/remote-branches-1.png[Kopyalamamadan sonra sunucu ve yerel repolar.] -Eğer yerel `master` dalında çalışıyorsanız ve aynı zamanda başka birisi `git.ourcompany.com` üzerine bir değişiklik yüklüyorsa (push), kendi `master` dalını güncelledikce, geçmişleriniz farklı yönlere ilerler. +Eğer yerel `master` dalında çalışıyorsanız ve aynı zamanda başka birisi `git.ourcompany.com` üzerine bir değişiklik itiyorsa (push), kendi `master` dalını güncelledikce, geçmişleriniz farklı yönlere ilerler. Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/master` işaretçisi yer değiştirmez. @@ -41,7 +41,7 @@ Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/m image::images/remote-branches-2.png[Yerel ve uzak çalışma farklılaşabilir.] Belirli bir uzak repo ile çalışmanızı eşzamanlamak (synchronize) için `git fetch ` komutunu çalıştırırsınız (bizim durumumuzda, `git fetch origin`). -Bu komut, `origin`in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri yakalar (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. +Bu komut, `origin`in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri getirir (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. .`git fetch` uzak takip dallarınızı günceller image::images/remote-branches-3.png[`git fetch` zak takip dallarınızı günceller.] @@ -53,21 +53,21 @@ Bu uzak sunucuyu kısaca `teamone` olarak adlandırın. .Başka bir sunucuyu uzak (remote) olarak eklemek image::images/remote-branches-4.png[Başka bir sunucuyu uzak olarak eklemek.] -Şimdi, `git fetch teamone` komutunu çalıştırarak, henüz sahip olmadığınız tüm verileri uzak `teamone` sunucusundan çekebilirsiniz. -Bu sunucu şu anda `origin` sunucunuzun sahip olduğu verilerin bir alt kümesine sahip olduğu için, Git hiç veri çekmez ancak `teamone`ın kendi `master` dalındaki katkıya işaret eden `teamone/master` adında bir uzak takip dalı ayarlar. +Şimdi, `git fetch teamone` komutunu çalıştırarak, henüz sahip olmadığınız tüm verileri uzak `teamone` sunucusundan getirebilirsiniz. +Bu sunucu şu anda `origin` sunucunuzun sahip olduğu verilerin bir alt kümesine sahip olduğu için, Git hiç veri getirmez ancak `teamone`ın kendi `master` dalındaki katkıya işaret eden `teamone/master` adında bir uzak takip dalı ayarlar. .teamone/master` için uzak takip dalı image::images/remote-branches-5.png[`teamone/master` için uzak takip dalı.] [[_pushing_branches]] -==== Yükleme (pushing) +==== İtme (pushing) (((pushing))) -Bir dalı dünyayla paylaşmak istediğinizde, yazma erişimine sahip olduğunuz bir uzak sunucuya yüklemeniz (push) gerekiyor. -Yerel dallarınız, yazma işlemi yapabileceğiniz uzak sunuculara otomatik olarak eşzamanlandırılmaz; paylaşmak istediğiniz dalları açıkça yüklemeniz gerekir. -Bu şekilde, paylaşmak istemediğiniz işler için özel (private) dallar kullanabilir ve yalnızca işbirliği yapmak istediğiniz tematik dalları yükleyebilirsiniz. +Bir dalı dünyayla paylaşmak istediğinizde, yazma erişimine sahip olduğunuz bir uzak sunucuya itmeniz (push) gerekiyor. +Yerel dallarınız, yazma işlemi yapabileceğiniz uzak sunuculara otomatik olarak eşzamanlandırılmaz; paylaşmak istediğiniz dalları açıkça itmeniz gerekir. +Bu şekilde, paylaşmak istemediğiniz işler için özel (private) dallar kullanabilir ve yalnızca işbirliği yapmak istediğiniz tematik dalları itebilirsiniz. -Eğer diğerleriyle birlikte çalışmak istediğiniz `serverfix` adında bir dalınız varsa, onu ilk dalınızı yüklediğiniz şekilde yükleyebilirsiniz. +Eğer diğerleriyle birlikte çalışmak istediğiniz `serverfix` adında bir dalınız varsa, onu ilk dalınızı ittiğiniz şekilde itebilirsiniz. `git push ` komutunu çalıştırın:(((git commands, push))) @@ -104,7 +104,7 @@ Her itme (push) işlemi yaparken bunu her seferinde yazmak istemiyorsanız, bir ==== -Bir sonraki seferde bir meslektaşınız sunucudan veri çektiğinde, sunucunun `serverfix` dalının versiyonuna dair referansı, uzak dal `origin/serverfix` altında olacaktır: +Bir sonraki seferde bir meslektaşınız sunucudan veri getirdiğinde, sunucunun `serverfix` dalının versiyonuna dair referansı, uzak dal `origin/serverfix` altında olacaktır: [source,console] ---- @@ -117,7 +117,7 @@ From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ---- -Yeni uzak takip dallarını getiren bir çekme işlemi yaptığınızda, bunların düzenlenebilir yerel kopyalarına otomatik olarak sahip olmazsınız. +Yeni uzak takip dallarını getiren bir getirme işlemi yaptığınızda, bunların düzenlenebilir yerel kopyalarına otomatik olarak sahip olmazsınız. Yani bu durumda, yeni bir `serverfix` dalınız olmaz -- sadece üzerinde değişiklik yapamayacağınız bir `origin/serverfix` işaretçiniz olur. Bu çalışmayı mevcut çalışma dalınıza birleştirmek için `git merge origin/serverfix` komutunu çalıştırabilirsiniz. @@ -133,17 +133,17 @@ Switched to a new branch 'serverfix' Böylelikle, `origin/serverfix`'in başladığı yerden devam eden ve üzerinde çalışabileceğiniz bir yerel dal elde etmiş olursunuz. [[_tracking_branches]] -==== Tracking Branches +==== Dalları Takip (((branches, tracking)))(((branches, upstream))) -Checking out a local branch from a remote-tracking branch automatically creates what is called a ``tracking branch'' (and the branch it tracks is called an ``upstream branch''). -Tracking branches are local branches that have a direct relationship to a remote branch. -If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and which branch to merge in. +Bir uzak takip dalından yerel bir dala geçmek, otomatik olarak bir 'takip dalı' (tracking branch) oluşturur (ve takip ettiği dal 'yukarı akış dalı' (upstream branch) olarak adlandırılır). +Takip eden dallar, bir uzak dal ile doğrudan ilişkisi olan yerel dallardır. +Bir takip dalındaysanız ve `git pull` yazarsanız, Git otomatik olarak hangi sunucudan getirileceğini ve hangi dalın birleştirileceğini bilir. -When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. -However, you can set up other tracking branches if you wish -- ones that track branches on other remotes, or don't track the `master` branch. -The simple case is the example you just saw, running `git checkout -b /`. -This is a common enough operation that Git provides the `--track` shorthand: +Bir repoyu kopyaladığınızda, genellikle otomatik olarak `origin/master`'ı takip eden bir `master` dalı oluşturur. +Ancak isterseniz başka takip dalları da kurabilirsiniz - diğer uzaklardaki dalları takip edenler veya `master` dalını takip etmeyenler. +Basit durum, az önce gördüğünüz gibidir: `git checkout -b /`. +Bu, Git'in `--track` kısaltmasını sağlayan yaygın bir işlemdir: [source,console] ---- @@ -152,8 +152,8 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -In fact, this is so common that there's even a shortcut for that shortcut. -If the branch name you're trying to checkout (a) doesn't exist and (b) exactly matches a name on only one remote, Git will create a tracking branch for you: +Aslında, bu işlem o kadar yaygındır ki, bu kısayol için bile bir kısayol vardır. +Eğer geçmeye çalıştığınız dal ismi (a) mevcut değilse ve (b) yalnızca bir uzak dalla tam olarak eşleşiyorsa, Git sizin için bir takip dalı oluşturacaktır: [source,console] ---- @@ -162,7 +162,7 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: +Uzak daldan farklı bir isimle yerel bir dal kurmak için, ilk versiyonu kullanarak kolayca farklı bir yerel dal ismi kullanabilirsiniz: [source,console] ---- @@ -171,9 +171,9 @@ Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ---- -Now, your local branch `sf` will automatically pull from `origin/serverfix`. +Şimdi, yerel dalınız `sf`, otomatik olarak `origin/serverfix`'ten çekecek. -If you already have a local branch and want to set it to a remote branch you just pulled down, or want to change the upstream branch you're tracking, you can use the `-u` or `--set-upstream-to` option to `git branch` to explicitly set it at any time. +Eğer zaten bir yerel dala sahipseniz ve onu henüz çektiğiniz bir uzak dalıyla eşleştirmek veya takip ettiğiniz yukarı akış dalını değiştirmek istiyorsanız, `git branch` komutunun `-u` veya `--set-upstream-to` seçeneğini kullanarak bunu istediğiniz zaman açıkça belirtebilirsiniz. [source,console] ---- @@ -181,15 +181,15 @@ $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ---- -[NOTE] -.Upstream shorthand +[NOT] +.Üstakış (upstream) kısayolu ==== -When you have a tracking branch set up, you can reference its upstream branch with the `@{upstream}` or `@{u}` shorthand. -So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++))) +Eğer kurulu bir takip dalınız varsa, onun yukarı akış dalını `@{upstream}` veya `@{u}` kısaltmasıyla işaretleyebilirsiniz. +Yani eğer `master` dalındaysanız ve bu dal `origin/master`'ı takip ediyorsa, isterseniz `git merge origin/master` yerine `git merge @{u}` gibi bir şey söyleyebilirsiniz.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== -If you want to see what tracking branches you have set up, you can use the `-vv` option to `git branch`. -This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both. +Takip eden dallarınızı görmek istiyorsanız, `git branch` komutuna `-vv` seçeneğini ekleyebilirsiniz. +Bu, her bir dalın takip ettiği bilgileri ve yerel dalınızın önde, geride veya her ikisinde olup olmadığını içeren daha fazla bilgiyle birlikte yerel dallarınızı listeleyecektir. [source,console] ---- @@ -200,38 +200,40 @@ $ git branch -vv testing 5ea463a trying something new ---- -So here we can see that our `iss53` branch is tracking `origin/iss53` and is ``ahead'' by two, meaning that we have two commits locally that are not pushed to the server. -We can also see that our `master` branch is tracking `origin/master` and is up to date. -Next we can see that our `serverfix` branch is tracking the `server-fix-good` branch on our `teamone` server and is ahead by three and behind by one, meaning that there is one commit on the server we haven't merged in yet and three commits locally that we haven't pushed. -Finally we can see that our `testing` branch is not tracking any remote branch. +Burada `iss53` dalımızın `origin/iss53`ü takip ettiğini ve 'önde' (ahead) iki olduğunu görebiliriz. +Bu da lokalde henüz sunucuya gönderilmemiş iki katkı olduğu anlamına gelir. +Ayrıca, `master` dalımızın `origin/master`ı takip ettiğini ve güncel olduğunu görebiliriz. +Sonrasında, `serverfix` dalımızın `teamone` sunucusundaki `server-fix-good` dalını takip ettiğini ve 'önde' (ahead) üç, 'geride' (behind) bir olduğunu görebiliriz. +Bu da henüz birleştirmediğimiz bir katkı olduğu ve lokalde henüz göndermediğimiz üç katkı olduğu anlamına gelir. +Son olarak, `testing` dalımızın herhangi bir uzak dalı takip etmediğini görebiliriz. -It's important to note that these numbers are only since the last time you fetched from each server. -This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. -If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. -You could do that like this: +Bu sayıların, her sunucudan en son getirme yaptığınızdan beri olan sayılar olduğunu unutmak önemlidir. +Bu komut sunuculara ulaşmaz, size bunları yerel olarak önbellekten aldığı bilgileri söyler. +Eğer tamamen güncel 'önde' (ahead) ve 'geride' (behind) sayıları istiyorsanız, bunu çalıştırmadan hemen önce tüm uzak sunuculardan getirmeniz gerekecektir. +Bunu şu şekilde yapabilirsiniz: [source,console] ---- $ git fetch --all; git branch -vv ---- -==== Pulling +==== Çekme (pulling) (((pulling))) -While the `git fetch` command will fetch all the changes on the server that you don't have yet, it will not modify your working directory at all. -It will simply get the data for you and let you merge it yourself. -However, there is a command called `git pull` which is essentially a `git fetch` immediately followed by a `git merge` in most cases. -If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the `clone` or `checkout` commands, `git pull` will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch. +`git fetch` komutu, henüz sahip olmadığınız sunucudaki tüm değişiklikleri getirir, ancak çalışma dizininizi hiç değiştirmez. +Sadece veriyi sizin için alır ve birleştirmenize izin verir. +Ancak, çoğu durumda `git fetch`'in hemen ardından gelen bir `git merge` işlemi olan `git pull` adlı bir komut bulunmaktadır. +Son bölümde gösterildiği gibi bir takip dalınız varsa, bunu açıkça ayarlayarak veya `clone` veya `checkout` komutları tarafından sizin için oluşturulmuşsa, `git pull`, mevcut dalınızın hangi sunucuyu ve dalı takip ettiğini araştırır, bu sunucudan veri çeker ve ardından bu uzak dalı birleştirmeye çalışır. -Generally it's better to simply use the `fetch` and `merge` commands explicitly as the magic of `git pull` can often be confusing. +Genellikle `git pull` komutunun sihirli davranışı sıklıkla karmaşıklığa neden olabileceğinden, açıkça `fetch` ve `merge` komutlarını kullanmak daha iyidir. [[_delete_branches]] -==== Deleting Remote Branches +==== Uzak Dalları Silmek (((branches, deleting remote))) -Suppose you're done with a remote branch -- say you and your collaborators are finished with a feature and have merged it into your remote's `master` branch (or whatever branch your stable codeline is in). -You can delete a remote branch using the `--delete` option to `git push`. -If you want to delete your `serverfix` branch from the server, you run the following: +Varsayalım ki bir uzak dal ile işiniz bitti - diyelim ki siz ve meslektaşlarınız bir özelliği tamamladınız ve onu uzaktaki `master` dalınıza (veya kararlı kod çizginizin bulunduğu dal) birleştirdiniz. +Bir uzak dalı silmek için `git push` komutuna `--delete` seçeneğini ekleyebilirsiniz. +Eğer `serverfix` dalınızı sunucudan silmek istiyorsanız, aşağıdaki komutu çalıştırabilirsiniz: [source,console] ---- @@ -240,5 +242,5 @@ To https://github.com/schacon/simplegit - [deleted] serverfix ---- -Basically all this does is remove the pointer from the server. -The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it's often easy to recover. +Temelde, bu işlem sunucudan işaretçiyi kaldırır. +Git sunucusu genellikle çöp toplama işlemi çalışana kadar veriyi orada tutar, bu nedenle eğer yanlışlıkla silinmişse genellikle kolaylıkla kurtarılabilir. From dda52fbe3ca6475d01f5af51c441c87f85cac8d7 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 3 Feb 2024 00:26:44 +0100 Subject: [PATCH 023/210] Create 04-server first commit --- book/04-git-server/sections/04-server | 1 + 1 file changed, 1 insertion(+) create mode 100644 book/04-git-server/sections/04-server diff --git a/book/04-git-server/sections/04-server b/book/04-git-server/sections/04-server new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/book/04-git-server/sections/04-server @@ -0,0 +1 @@ + From 75085616fc0e73023ed4736f8c6ce6d6266fd3b1 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 3 Feb 2024 00:27:44 +0100 Subject: [PATCH 024/210] Delete book/04-git-server/sections/04-server --- book/04-git-server/sections/04-server | 1 - 1 file changed, 1 deletion(-) delete mode 100644 book/04-git-server/sections/04-server diff --git a/book/04-git-server/sections/04-server b/book/04-git-server/sections/04-server deleted file mode 100644 index 8b137891..00000000 --- a/book/04-git-server/sections/04-server +++ /dev/null @@ -1 +0,0 @@ - From adbcffc137320417a10ae57e49f8c8c7094e999e Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 3 Feb 2024 00:58:27 +0100 Subject: [PATCH 025/210] Update protocols.asc translated up to line:28 --- book/04-git-server/sections/protocols.asc | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 946cf5ae..c6492196 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -1,25 +1,24 @@ -=== The Protocols +=== İletişim Kuralları (Protocols) -Git can use four distinct protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. -Here we'll discuss what they are and in what basic circumstances you would want (or not want) to use them. +Git, veri aktarımı için dört farklı protokol kullanabilir: Yerel, HTTP, SSH (Güvenli Kabuk) ve Git. İşte bunların ne oldukları ve hangi temel durumlarda kullanmak isteyebileceğiniz (veya istemeyebileceğiniz) konusunu tartışacağız. -==== Local Protocol +==== Yerel (local) Protokol (((protocols, local))) -The most basic is the _Local protocol_, in which the remote repository is in another directory on the same host. -This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. -The latter wouldn't be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. +En temel olanı uzak reponun, aynı ana bilgisayardaki başka bir dizinde yer aldığı _Yerel protokoldür_. +Bu genellikle takımınızdaki herkesin NFS mount gibi paylaşılan bir dosya sistemine erişiminin olduğu veya daha az rastlanan herkesin aynı bilgisayara giriş yaptığı durumda kullanılır. +Tüm kod repo örneklerinin aynı bilgisayarda bulunması, bir felaket durumundaki kayıpları daha da olası hale getireceği için, ikinci durum pek de ideal değildir. -If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. -To clone a repository like this, or to add one as a remote to an existing project, use the path to the repository as the URL. -For example, to clone a local repository, you can run something like this: +Eğer paylaşılan bir dosya sistemine bağlanmışsanız, o zaman yerel dosya tabanlı bir repodan kopya alabilir, bu repoya katkı itebilir ve çekebilirsiniz. +Böyle bir repoyu kopyalamak veya mevcut bir projeye uzak repo olarak eklemek için, repo yolunuzu URL olarak kullanın. +Örneğin, bir yerel repoyu kopyalamak için şu şekilde bir komut çalıştırabilirsiniz: [source,console] ---- $ git clone /srv/git/project.git ---- -Or you can do this: +Veya şunun gibi: [source,console] ---- From dab6a05b71b2719ca86693d53adf308692cdb960 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 12:51:16 +0100 Subject: [PATCH 026/210] Update protocols.asc completely translated --- book/04-git-server/sections/protocols.asc | 217 +++++++++++----------- 1 file changed, 112 insertions(+), 105 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index c6492196..27bb9477 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -25,73 +25,75 @@ Veya şunun gibi: $ git clone file:///srv/git/project.git ---- -Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. -If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. -If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network, which is generally much less efficient. -The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out -- generally after an import from another VCS or something similar (see <> for maintenance tasks). -We'll use the normal path here because doing so is almost always faster. +URL'nin başına açıkça `file://` belirtirseniz, Git biraz farklı çalışır. +Eğer sadece dizini belirtirseniz, Git ihtiyaç duyduğu dosyaları ya doğrudan kopyalamaya ya da hardlink kullanmaya çalışır. +Eğer `file://` şeklinde belirtirseniz, Git genellikle ağ üzerinde veri transferi için kullandığı işlemleri başlatır ki bu da genellikle çok daha verimsizdir. +`file://` öneki belirtmenin ana nedeni, genellikle başka bir VCS'den içe aktarım sonrasında, repodan gereksiz referansların veya nesnelerin çıkarıldığı temiz bir kopya istemenizdir (bakım görevleri için: <>). +Genellikle daha hızlı olduğu için burada normal dizini kullanacağız. -To add a local repository to an existing Git project, you can run something like this: +Mevcut bir Git projesine yerel bir repo eklemek için şöyle bir komut çalıştırabilirsiniz: [source,console] ---- $ git remote add local_proj /srv/git/project.git ---- -Then, you can push to and pull from that remote via your new remote name `local_proj` as though you were doing so over a network. +Ardından, bu uzak repoya, ağ üzerinden işlem yapıyormuş gibi, yeni uzak adınız olan `local_proj` üzerinden itme ve çekme işlemleri yapabilirsiniz. -===== The Pros +===== Artıları -The pros of file-based repositories are that they're simple and they use existing file permissions and network access. -If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. -You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. -We'll discuss how to export a bare repository copy for this purpose in <>. +Dosya tabanlı repoların avantajları, basit olmaları ve mevcut dosya ve ağ erişimi izinlerini kullanmalarıdır. +Eğer takımınızın tamamının erişebildiği paylaşılan bir dosya sistemine sahipseniz, bir repo kurmak çok kolaydır. +Bir çıplak repo (bare repository) kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. +Bu amaçla bir çıplak repo kopyasını nasıl dışa aktaracağınızı <> bölümünde ele alacağız. -This is also a nice option for quickly grabbing work from someone else's working repository. -If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you subsequently fetching from it. +Bu ayrıca başka birinin çalışma reposundan hızlı bir şekilde çalışma almak için de güzel bir seçenektir. +Eğer siz ve bir iş arkadaşınız aynı projede çalışıyorsanız ve sizin bir şeyi kontrol etmenizi istiyorlarsa, `git pull /home/john/project` gibi bir komut çalıştırmak; onların projeyi bir uzak sunucuya itip, ardından sizin de bunu ordan çekmenizden genellikle daha kolaydır. -===== The Cons +===== Eksileri -The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. -If you want to push from your laptop when you're at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. +Bu yöntemin dezavantajları, paylaşılan erişimin kurulumunun ve çoklu konumlardan ulaşılabilirliğinin genellikle temel ağ erişimine göre daha zor olmasıdır. +Evden çalışırken birşeyleri itmek istiyorsanız, uzak diski bağlamanız gerekebilir ve bu da ağ erişimine göre daha zorlayıcı ve yavaş olabilir. -It's important to mention that this isn't necessarily the fastest option if you're using a shared mount of some kind. -A local repository is fast only if you have fast access to the data. -A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. +Eğer bir çeşit paylaşılan bağlantı noktası kullanıyorsanız bu illa ki en hızlı seçenek olmak zorunda değildir. +Yerel bir repo sadece, eğer verilere hızlı erişiminiz varsa hızlıdır. +Git, her sistemdeki yerel disklerden çalışmasına izin verdiği için, NFS üzerindeki bir repo genellikle aynı sunucuda yer alan SSH üzerindeki bir repodan daha yavaş olabilir. -Finally, this protocol does not protect the repository against accidental damage. -Every user has full shell access to the ``remote'' directory, and there is nothing preventing them from changing or removing internal Git files and corrupting the repository. +Son olarak, bu protokol repoyu kaza eseri oluşan hasara karşı korumaz. +Her kullanıcının "uzak" dizinine tam kabuk (shell) erişimi vardır ve onların içerideki Git dosyalarını değiştirmesini, kaldırmasını veya repoyu bozmasını engelleyen hiçbir şey yoktur. -==== The HTTP Protocols +==== HTTP Protokolleri -Git can communicate over HTTP using two different modes. -Prior to Git 1.6.6, there was only one way it could do this which was very simple and generally read-only. -In version 1.6.6, a new, smarter protocol was introduced that involved Git being able to intelligently negotiate data transfer in a manner similar to how it does over SSH. -In the last few years, this new HTTP protocol has become very popular since it's simpler for the user and smarter about how it communicates. -The newer version is often referred to as the _Smart_ HTTP protocol and the older way as _Dumb_ HTTP. -We'll cover the newer Smart HTTP protocol first. +Git iki farklı modda HTTP üzerinden iletişim kurabilir. +Git 1.6.6 öncesi sürümlerde genellikle salt okunur olan çok basit bir yol vardı. +1.6.6 sürümünde, Git'in SSH üzerinden yaptığına benzer bir şekilde, veri transferini zekice müzakere edebildiği yeni bir protokol tanıtıldı. +Son birkaç yılda, bu yeni HTTP protokolü kullanıcısı için daha basit ve iletişim şekli yönüyle daha akıllı olduğu için oldukça popüler hale gelmiştir. +Yeni sürüm genellikle _Akıllı_ (smart) HTTP protokolü olarak adlandırılırken, eski yöntem _Aptal_ (dumb) HTTP olarak adlandırılır. +İlk olarak daha yeni olan Akıllı HTTP protokolünü ele alacağız. -===== Smart HTTP +===== Akıllı HTTP (((protocols, smart HTTP))) -Smart HTTP operates very similarly to the SSH or Git protocols but runs over standard HTTPS ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password authentication rather than having to set up SSH keys. +Akıllı HTTP; SSH veya Git protokollerine oldukça benzer bir şekilde çalışır, ancak standart HTTPS bağlantı noktaları üzerinden çalışır ve çeşitli HTTP kimlik doğrulama mekanizmalarını kullanabilir. Bu da kullanıcı açısından genellikle SSH gibi şeylere göre daha kolay olduğu anlamına gelir, çünkü SSH anahtarları kurmaktansa kullanıcı adı/parola kimlik doğrulaması gibi şeyleri kullanılabilir . -It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the `git://` protocol, and can also be pushed over with authentication and encryption like the SSH protocol. -Instead of having to set up different URLs for these things, you can now use a single URL for both. -If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password. -The same goes for read access. +Bu muhtemelen şu anda Git'i kullanmanın en popüler yolu olmuştur. +Çünkü `git://` protokolü gibi anonim hizmet verecek şekilde kurulabilir ve SSH protokolü gibi kimlik doğrulama ve şifreleme ile de gönderilebilir. +Bu işlemler için farklı URL'ler kurmak zorunda kalmak yerine, artık her ikisi için tek bir URL kullanabilirsiniz. +Eğer repo kimlik doğrulama gerektiriyorsa (ki normalde gerektirmelidir), sunucu bir kullanıcı adı ve parola sormak üzere bir istekte bulunabilir. +Okuma erişimi için de aynı durum geçerlidir. -In fact, for services like GitHub, the URL you use to view the repository online (for example, https://github.com/schacon/simplegit[]) is the same URL you can use to clone and, if you have access, push over. +Aslında, GitHub gibi hizmetler için, repoyu çevrimiçi görüntülemek için kullandığınız URL (örneğin, https://github.com/schacon/simplegit[]) kopyalamak ve erişiminiz varsa itmek için kullanabileceğiniz aynı URL'dir. -===== Dumb HTTP +===== Aptal HTTP (((protocols, dumb HTTP))) -If the server does not respond with a Git HTTP smart service, the Git client will try to fall back to the simpler _Dumb_ HTTP protocol. -The Dumb protocol expects the bare Git repository to be served like normal files from the web server. -The beauty of Dumb HTTP is the simplicity of setting it up. -Basically, all you have to do is put a bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you're done (See <>). -At that point, anyone who can access the web server under which you put the repository can also clone your repository. -To allow read access to your repository over HTTP, do something like this: +Eğer sunucu Git HTTP akıllı hizmeti ile yanıt vermezse, Git istemcisi daha basit _Aptal_ HTTP protokolüne geri dönmeye çalışacaktır. +Aptal protokol çıplak Git reposundan tıpkı ağ sunucusundan normal dosyalar gibi sunulmasını bekler. +Aptal HTTP'nin güzelliği kurulumunun basitliğidir. +Temelde yapmanız gereken, çıplak bir Git reposunu HTTP belge kökünüzün altına koymak ve belirli bir `post-update` kancası (hook) kurmaktır. +İşte hepsi bu (Bkz: <>). +Bu noktada, ağ sunucusuna yerleştirdiğiniz repoya erişebilen herkes, aynı zamanda repoyu da kopyalayabilir. +Repoyu HTTP üzerinden okuma erişimine izin vermek için şunu yapabilirsiniz: [source,console] ---- @@ -102,103 +104,108 @@ $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update ---- -That's all.(((hooks, post-update))) -The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. -This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like +Hepsi bu.(((hooks, post-update))) +Git'in varsayılan olarak gelen `post-update` kancası, HTTP çekme ve kopyalamanın düzgün çalışmasını sağlamak için uygun komutu (`git update-server-info`) çalıştırır. +Bu komut, bu repoya itme yaptığınızda (belki SSH üzerinden), ardından diğer insanlar şu şekilde kopyalayabilir: [source,console] ---- $ git clone https://example.com/gitproject.git ---- -In this particular case, we're using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server -- just put the bare repository in its path. -The Git data is served as basic static files (see the <> chapter for details about exactly how it's served). +Bu özel durumda, Apache kurulumları için yaygın olan `/var/www/htdocs` yolu kullanılmıştır, ancak herhangi bir durağan (static) ağ sunucusunu kullanabilirsiniz (sadece çıplak repoyu dizinine koyun). +Git verileri temel durağan dosyalar olarak sunulur (tam olarak nasıl sunulduğu hakkında ayrıntılı bilgi için <> bölümüne bakın). -Generally you would either choose to run a read/write Smart HTTP server or simply have the files accessible as read-only in the Dumb manner. -It's rare to run a mix of the two services. +Genellikle ya okuma/yazma yeteneğine sahip Akıllı HTTP sunucusunu çalıştırmayı seçersiniz ya da dosyaları aptal şekilde sadece salt okunabilir olarak erişilebilir yaparsınız. +İki hizmeti karışık şekilde çalıştırmak nadirdir. -===== The Pros +===== Artılar -We'll concentrate on the pros of the Smart version of the HTTP protocol. +Akıllı HTTP protokolünün avantajlarına odaklanacağız. -The simplicity of having a single URL for all types of access and having the server prompt only when authentication is needed makes things very easy for the end user. -Being able to authenticate with a username and password is also a big advantage over SSH, since users don't have to generate SSH keys locally and upload their public key to the server before being able to interact with it. -For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. -It is also a very fast and efficient protocol, similar to the SSH one. +Tüm erişim türleri için tek bir URL'e sahip olmanın ve sunucunun sadece kimlik doğrulamasına ihtiyaç duyulduğunda istekte bulunmasının basitliği, son kullanıcılar için işleri çok kolay hale getirir. +Kullanıcı adı ve parola ile kimlik doğrulayabilme, SSH'ye kıyasla büyük bir avantajdır. +Böylece kullanıcılar sunucuyla etkileşimde bulunabilmek için, önce yerelde SSH anahtarı oluşturup genel anahtarlarını sunucuya yüklemek zorunda kalmazlar. +Daha az deneyime sahip kullanıcılar veya SSH'nin daha az yaygın olduğu sistemlerde, bu kullanılabilirlik açısından büyük bir avantajdır. +Bu aynı zamanda, SSH'ye benzer şekilde, çok hızlı ve verimli bir protokoldür. -You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. +Ayrıca repolarınızı sadece HTTPS üzerinden salt okunabilir şekilde sunabilirsiniz. +Bu da içerik aktarımını şifreleyebileceğiniz veya istemcilerin belirli imzalı SSL sertifikalarını kullanmasını sağlayabileceğiniz anlamına gelir. -Another nice thing is that HTTPS are such commonly used protocols that corporate firewalls are often set up to allow traffic through these ports. +Bir başka güzel özellik de, HTTPS o kadar yaygın kullanılan bir protokoldür ki kurumsal güvenlik duvarları genellikle bu portlardan trafiğe izin verilecek şekilde kurulmuştur. -===== The Cons +===== Eksiler -Git over HTTPS can be a little more tricky to set up compared to SSH on some servers. -Other than that, there is very little advantage that other protocols have over Smart HTTP for serving Git content. +Bazı sunucularda Git'i HTTPS üzerinden kurmak, SSH'ye kıyasla biraz daha karmaşık olabilir. +Bunun dışında, diğer protokollerin Git içeriğini sunma konusunda Akıllı HTTP'ye karşı çok az avantajı vardır. -If you're using HTTP for authenticated pushing, providing your credentials is sometimes more complicated than using keys over SSH. -There are, however, several credential caching tools you can use, including Keychain access on macOS and Credential Manager on Windows, to make this pretty painless. -Read <> to see how to set up secure HTTP password caching on your system. +Eğer kimlik doğrulamalı itme için HTTP kullanıyorsanız, kimlik bilgilerinizi sağlamak SSH üzerinden anahtar kullanmaktan bazen daha karmaşık olabilir. +Yine de bunu mümkün mertebe sorunsuz hale getirmek için kullanabileceğiniz, macOS için Keychain erişimi veya Windows için Credential Manager dahil, birkaç kimlik bilgisi önbelleği aracı bulunmaktadır. +Sistem üzerinde güvenli HTTP şifre önbelleğinin nasıl kurulacağını öğrenmek için <> bölümüne göz atın. -==== The SSH Protocol +==== SSH Protokolü (((protocols, SSH))) -A common transport protocol for Git when self-hosting is over SSH. -This is because SSH access to servers is already set up in most places -- and if it isn't, it's easy to do. -SSH is also an authenticated network protocol and, because it's ubiquitous, it's generally easy to set up and use. +SSH, Git için kendinden ev sahipliği (self-hosting) yapılırken, yaygın şekilde kullanılan bir iletişim prokotolüdür. +Bu, çoğu zaman zaten sunuculara SSH erişiminin kurulu olması veya kurulu değilse, kurmanın kolaylığı nedeniyle geçerlidir. +SSH ayrıca kimliği doğrulanmış bir ağ protokolüdür ve yaygın olduğu için de genellikle kurulumu ve kullanımı kolaydır. -To clone a Git repository over SSH, you can specify an `ssh://` URL like this: +SSH üzerinden bir Git reposunu kopyalamak için şu şekilde bir `ssh://` URL'si belirtebilirsiniz: [source,console] ---- $ git clone ssh://[user@]server/project.git ---- -Or you can use the shorter scp-like syntax for the SSH protocol: +Veya SSH protokolü için "scp" benzeri daha kısa bir sözdizimini kullanabilirsiniz: [source,console] ---- $ git clone [user@]server:project.git ---- -In both cases above, if you don't specify the optional username, Git assumes the user you're currently logged in as. +Yukarıdaki her iki durumda da isteğe bağlı kullanıcı adını belirtmezseniz, Git şu anda oturum açtığınız kullanıcıyı varsayılan olarak kabul eder. -===== The Pros +===== Artılar -The pros of using SSH are many. -First, SSH is relatively easy to set up -- SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. -Next, access over SSH is secure -- all data transfer is encrypted and authenticated. -Last, like the HTTPS, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. +SSH kullanmanın birçok avantajı vardır. +İlk olarak, SSH kurulumu nispeten kolaydır (SSH daemonları yaygındır, birçok ağ yöneticisi bunda deneyime sahiptir, birçok işletim sistemi dağıtımında kuruludur veya bunları yönetmek için gerekli araçlara sahiptir). +Ayrıca, SSH üzerinden erişim güvenlidir (tüm veri aktarımı şifrelenir ve kimlik doğrulanır). +Son olarak SSH, aynı HTTPS, Git ve yerel protokoller gibi, veriyi mümkün olduğunca sıkıştırarak aktardığı için verimlidir. -===== The Cons +===== Eksiler -The negative aspect of SSH is that it doesn't support anonymous access to your Git repository. -If you're using SSH, people _must_ have SSH access to your machine, even in a read-only capacity, which doesn't make SSH conducive to open source projects for which people might simply want to clone your repository to examine it. -If you're using it only within your corporate network, SSH may be the only protocol you need to deal with. -If you want to allow anonymous read-only access to your projects and also want to use SSH, you'll have to set up SSH for you to push over but something else for others to fetch from. +SSH'nin olumsuz yönü, Git reposuna anonim erişimi desteklememesidir. +Eğer SSH kullanıyorsanız, insanlar (salt okunur dosyalar için dahi) makinenize SSH erişimine sahip olmak _zorundadır_. +Bu da SSH'nin insanların repoyu sadece incelemek amacıyla kopyalamak isteyebileceği açık kaynak projeler için uygun olmadığı anlamına gelir. +Eğer bunu sadece kurumsal ağınız içinde kullanıyorsanız, SSH muhtemelen uğraşmanız gereken tek protokol olabilir. +Eğer projelerinize anonim salt-okunur erişimine izin vermek ve aynı zamanda SSH kullanmak istiyorsanız; projelerinizi itmek için kendinize bir SSH kurmanız gerekecek ,ancak başkalarının sizden çekebilmesi için başka bir şey kullanmanız gerekecektir. -==== The Git Protocol +==== Git Protokolü (((protocols, git))) -Finally, we have the Git protocol. -This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. -In order for a repository to be served over the Git protocol, you must create a `git-daemon-export-ok` file -- the daemon won't serve a repository without that file in it -- but, other than that, there is no security. -Either the Git repository is available for everyone to clone, or it isn't. -This means that there is generally no pushing over this protocol. -You can enable push access but, given the lack of authentication, anyone on the internet who finds your project's URL could push to that project. -Suffice it to say that this is rare. - -===== The Pros - -The Git protocol is often the fastest network transfer protocol available. -If you're serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it's likely that you'll want to set up a Git daemon to serve your project. -It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. - -===== The Cons - -The downside of the Git protocol is the lack of authentication. -It's generally undesirable for the Git protocol to be the only access to your project. -Generally, you'll pair it with SSH or HTTPS access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. -It's also probably the most difficult protocol to set up. -It must run its own daemon, which requires `xinetd` or `systemd` configuration or the like, which isn't always a walk in the park. -It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow. -Behind big corporate firewalls, this obscure port is commonly blocked. +Son olarak, elimizde bir de Git protokolü var. +Bu, Git ile birlikte gelen özel bir daemon'dır. +Kendine adanmış bir portu (9418) dinleyerek SSH protokolüne benzer bir hizmet sunar, ancak kesinlikle hiçbir kimlik doğrulama yoktur. +Bir reponun Git protokolü üzerinden sunulabilmesi için bir `git-daemon-export-ok` dosyası oluşturmanız gerekmektedir (daemon, bu dosya olmadan bir repoyu sunamaz), ancak bunun dışında herhangi bir güvenlik önlemi yoktur. +Git reposu ya herkes tarafından kopyalanabilirdir ya da kimse tarafından. +Bunun anlamı, bu protokol üzerinden genel olarak itmenin olmadığıdır. +İtme erişimini etkinleştirebilirsiniz, ancak kimlik doğrulama eksikliği nedeniyle projenizin URL'sini bulan herkes bu projeye itme yapabilir. +Bunun oldukça nadir olduğunu söylemeye gerek yok tabi. + +===== Artılar + +Git protokolü genellikle mevcut olan en hızlı ağ aktarım protokolüdür. +Eğer geniş bir trafiği olan genel bir proje için veya okuma erişimine kullanıcı kimliği doğrulaması gerektirmeyen çok büyük bir proje için hizmet veriyorsanız, muhtemelen projenizi sunmak için bir Git daemonu kurmak istersiniz. +Bu, şifreleme ve kimlik doğrulama maliyeti olmadan, SSH protokolü ile aynı veri aktarım mekanizmasını kullanmanıza olanak tanır. + +===== Eksiler + +Git protokolünün dezavantajı kimlik doğrulama eksikliğidir. +Projenize erişim için Git protokolünün tek seçenek olması genellikle istenmez. +Genellikle, sadece yazma (itme) izni olan birkaç geliştiriciyi SSH veya HTTPS erişimi ile eşleştirir ve diğer herkesin sadece salt okunur erişimi için `git://` kullanmasını sağlarsınız. +Ayrıca, muhtemelen kurulumu en zor protokol de budur. +Kendi daemon'unu çalıştırmalıdır ki bu da `xinetd` veya `systemd` yapılandırması veya benzerini gerektirir. +Bu da her zaman kolay bir iş değildir. +Ayrıca, kurumsal güvenlik duvarlarının her zaman izin vermediği, standart bir port olmayan, 9418 numaralı porta firewall erişimi gerektirir. +Büyük kurumsal güvenlik duvarları arkasında, bu gizli port genellikle engellenir. From f1da5342c8c6d8b597e66e2106b098f8790ee431 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 21:37:59 +0100 Subject: [PATCH 027/210] Update git-on-a-server.asc 04.02 has been translated --- .../sections/git-on-a-server.asc | 92 ++++++++++--------- 1 file changed, 47 insertions(+), 45 deletions(-) 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 18727c66..e3cc034d 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -1,18 +1,19 @@ [[_getting_git_on_a_server]] -=== Getting Git on a Server +=== Bir Sunucuda Git Kurma -Now we'll cover setting up a Git service running these protocols on your own server. +Şimdi kendi sunucunuzda bu protokoller üzerinde çalışan bir Git servisi kurmayı ele alacağız. -[NOTE] +[NOT] ==== -Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux-based server, though it's also possible to run these services on macOS or Windows servers. -Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved. +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ı (production) 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. ==== -In order to initially set up any Git server, you have to export an existing repository into a new bare repository -- a repository that doesn't contain a working directory. -This is generally straightforward to do. -In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option.(((git commands, clone, bare))) -By convention, bare repository directory names end with the suffix `.git`, like so: +Herhangi bir Git sunucusunu başlangıçta kurabilmek için mevcut bir repoyu yeni bir çıplak repo olmak üzere (çalışma dizini içermeyen bir repo) dışa aktarmanız gerekir. +Bunu yapmak oldukça basittir. +Yeni bir çıplak repo oluşturmak üzere reponuzu kopyalamak için kopyalama komutunu `--bare` seçeneği ile çalıştırırsınız.(((git commands, clone, bare))) +Geleneksel olarak, çıplak repo dizin adları, `.git` soneki ile biter. +Şu şekildedir: [source,console] ---- @@ -21,41 +22,41 @@ Cloning into bare repository 'my_project.git'... done. ---- -You should now have a copy of the Git directory data in your `my_project.git` directory. +Artık `my_project.git` dizininde Git dizin verilerinin bir kopyasına sahip olmalısınız. -This is roughly equivalent to something like +Bu, şuna benzer bir şeye karşılık gelir: [source,console] ---- $ cp -Rf my_project/.git my_project.git ---- -There are a couple of minor differences in the configuration file but, for your purpose, this is close to the same thing. -It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. +Yapılandırma (configuration) dosyasında birkaç küçük fark vardır, ancak sizin amacınız için bu neredeyse aynı şeydir. +Çalışma dizini olmadan yalnızca Git reposunu alır ve ona özel bir dizin oluşturur. [[_bare_repo]] -==== Putting the Bare Repository on a Server +==== Yalın Repoyu Sunucuya Alma -Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. -Let's say you've set up a server called `git.example.com` to which you have SSH access, and you want to store all your Git repositories under the `/srv/git` directory. -Assuming that `/srv/git` exists on that server, you can set up your new repository by copying your bare repository over: +Artık repo için bir yalın kopyaya sahip olduğunuza göre, yapmanız gereken tek şey onu bir sunucuya yerleştirmek ve protokollerinizi kurmaktır. +Diyelim ki SSH erişiminiz olan `git.example.com` adında bir sunucu kurmuşsunuz ve tüm Git repolarınızı `/srv/git` dizini altında saklamak istiyorsunuz. +Bu sunucuda `/srv/git` dizinin bulunduğunu varsayarak, yeni reponuzu, yalın repoyu kopyalayarak aşağıdaki gibi kurabilirsiniz: [source,console] ---- $ scp -r my_project.git user@git.example.com:/srv/git ---- -At this point, other users who have SSH-based read access to the `/srv/git` directory on that server can clone your repository by running +Artık, o sunucudaki `/srv/git` dizinine SSH tabanlı okuma erişimi olan diğer kullanıcılar, repoyu şu komutu çalıştırarak kopyalayabilir: [source,console] ---- $ git clone user@git.example.com:/srv/git/my_project.git ---- -If a user SSHs into a server and has write access to the `/srv/git/my_project.git` directory, they will also automatically have push access. +Eğer `/srv/git/my_project.git` dizinine yazma erişimine sahip bir kullanıcı, sunucuya SSH ile bağlanırsa, otomatik olarak itme erişimine de sahip olacaktır. -Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option. -Note that by running this command, you will not destroy any commits, refs, etc. in the process.(((git commands, init, bare))) +`git init` komutunu `--shared` seçeneği ile çalıştırırsanız, Git otomatik olarak bir repoya grup yazma izinlerini ekler. +Bu komutu çalıştırarak, bu süreçte hiçbir commit, ref vb. yok edilmeyecektir.(((git commands, init, bare))) [source,console] ---- @@ -64,38 +65,39 @@ $ cd /srv/git/my_project.git $ git init --bare --shared ---- -You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. -Now you're ready to collaborate on the same project. +Bir Git reposunu almanın, yalın bir versiyon oluşturmanın ve iş arkadaşlarınızla birlikte SSH erişimine sahip olduğunuz bir sunucuya yerleştirmenin ne kadar kolay olduğunu gördünüz. +Şimdi aynı projede işbirliği yapmaya hazırsınız. -It's important to note that this is literally all you need to do to run a useful Git server to which several people have access -- just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. -You're ready to go -- nothing else needed. +Birkaç kişinin erişimi olan kullanışlı bir Git sunucusunu çalıştırmak için yapmanız gereken tek şey budur. +Sadece bir sunucuda SSH erişimine sahip hesaplar ekleyin ve tüm bu kullanıcılara okuma ve yazma erişimi veren yalın bir repoyu bir yere yerleştirin. +Artık çalışmaya hazırsınız. -In the next few sections, you'll see how to expand to more sophisticated setups. -This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs and more. -However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. +Sonraki birkaç bölümde, daha karmaşık kurulumlara nasıl genişleyeceğinizi göreceksiniz. +Bu mevzu, her bir kullanıcı için hesap oluşturmak zorunda kalmadan, repolara genel okuma erişimi eklemek, ağ arayüzleri kurmak ve daha fazlasını içerecek. +Yine de birkaç kişiyle özel bir projede işbirliği yapmak için ihtiyacınız olan _tek şey_ bir SSH sunucusu ve bir yalın repodur. -==== Small Setups +==== Ufak Kurulumlar -If you're a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. -One of the most complicated aspects of setting up a Git server is user management. -If you want some repositories to be read-only for certain users and read/write for others, access and permissions can be a bit more difficult to arrange. +Eğer küçük bir ekip veya organizasyonunuzda Git'i denemek için sadece birkaç geliştiriciniz varsa, işler sizin için basit olabilir. +Git sunucusu kurmanın en karmaşık yönlerinden biri kullanıcı yönetimidir. +Bazı depoların belirli kullanıcılar için salt okunur, diğerleri için ise okuma/yazma izinli olmasını istiyorsanız, erişim ve izinleri düzenlemek biraz daha zor olabilir. -===== SSH Access +===== SSH Erişimi (((serving repositories, SSH))) -If you have a server to which all your developers already have SSH access, it's generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). -If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of your server's operating system. +Eğer tüm geliştiricilerinizin zaten SSH erişimine sahip olduğu bir sunucunuz varsa, en kolayı ilk repoyu orada kurmaktır, çünkü (geçen bölümde anlattığımız gibi) neredeyse hiç iş yapmanıza gerek yoktur. +Eğer repolarınızda daha karmaşık erişim kontrolü türü izinler olmasını istiyorsanız, bunları sunucunuzun işletim sisteminin normal dosya sistem izinleri ile yönetebilirsiniz. -If you want to place your repositories on a server that doesn't have accounts for everyone on your team for whom you want to grant write access, then you must set up SSH access for them. -We assume that if you have a server with which to do this, you already have an SSH server installed, and that's how you're accessing the server. +Eğer repolarınızı, yazma erişimi vermek istediğiniz herkesin hesap sahip olmadığı bir sunucuya koymak istiyorsanız, o zaman onlar için SSH erişimi kurmalısınız. +Bu işlemi yapacak bir sunucunuz varsa, zaten bir SSH sunucusu kurulu olduğunu ve sunucuya erişim sağlamak için bu yöntemi kullandığınızı varsayıyoruz. -There are a few ways you can give access to everyone on your team. -The first is to set up accounts for everybody, which is straightforward but can be cumbersome. -You may not want to run `adduser` (or the possible alternative `useradd`) and have to set temporary passwords for every new user. +Takımınızdaki herkese erişim sağlamanın birkaç yolu vardır. +İlk olarak, herkes için birer hesap açaabilirsiniz, bu basit ancak sıkıcı olabilecek bir iştir. +Her yeni kullanıcı için `adduser` (veya olası alternatif `useradd`) komutunu çalıştırmak ve geçici şifreler belirlemek istemeyebilirsiniz. -A second method is to create a single 'git' user account on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of that new 'git' account. -At that point, everyone will be able to access that machine via the 'git' account. -This doesn't affect the commit data in any way -- the SSH user you connect as doesn't affect the commits you've recorded. +İkinci bir yöntem, makinada tek bir 'git' kullanıcı hesabı oluşturmak, yazma erişimine sahip olacak her kullanıcıdan bir SSH genel anahtarı göndermelerini istemek ve bu anahtarı yeni 'git' hesabının `~/.ssh/authorized_keys` dosyasına eklemektir. +Artık, herkes 'git' hesabı üzerinden bu makineye erişebilecektir. +Bu, herhangi bir şekilde katkı verilerini etkilemez (bağlandığınız SSH kullanıcısı, işlediğiniz katkıları etkilemez). -Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. -As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work. +Bunu yapmanın başka bir yolu da SSH sunucunuzun bir LDAP sunucusu veya zaten kurulu olan başka bir merkezi kimlik doğrulama kaynağından kimlik doğrulamasını yapmasını sağlamaktır. +Her kullanıcı makineye kabuk erişimi alabildiği sürece, aklınıza gelebilecek herhangi bir SSH kimlik doğrulama mekanizması çalışmalıdır. From 2860f36e6c6b68392ddb3491dccca16e526d3e38 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 21:39:06 +0100 Subject: [PATCH 028/210] Update git-on-a-server.asc From 48449f033e4840a246368cc246fcc7abc143d901 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 21:43:32 +0100 Subject: [PATCH 029/210] Update protocols.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit çıplak repo => yalın repo --- book/04-git-server/sections/protocols.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 27bb9477..ad4e8cab 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -44,8 +44,8 @@ Ardından, bu uzak repoya, ağ üzerinden işlem yapıyormuş gibi, yeni uzak ad Dosya tabanlı repoların avantajları, basit olmaları ve mevcut dosya ve ağ erişimi izinlerini kullanmalarıdır. Eğer takımınızın tamamının erişebildiği paylaşılan bir dosya sistemine sahipseniz, bir repo kurmak çok kolaydır. -Bir çıplak repo (bare repository) kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. -Bu amaçla bir çıplak repo kopyasını nasıl dışa aktaracağınızı <> bölümünde ele alacağız. +Bir yalın repo (bare repository) kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. +Bu amaçla bir yalın repo kopyasını nasıl dışa aktaracağınızı <> bölümünde ele alacağız. Bu ayrıca başka birinin çalışma reposundan hızlı bir şekilde çalışma almak için de güzel bir seçenektir. Eğer siz ve bir iş arkadaşınız aynı projede çalışıyorsanız ve sizin bir şeyi kontrol etmenizi istiyorlarsa, `git pull /home/john/project` gibi bir komut çalıştırmak; onların projeyi bir uzak sunucuya itip, ardından sizin de bunu ordan çekmenizden genellikle daha kolaydır. @@ -88,9 +88,9 @@ Aslında, GitHub gibi hizmetler için, repoyu çevrimiçi görüntülemek için (((protocols, dumb HTTP))) Eğer sunucu Git HTTP akıllı hizmeti ile yanıt vermezse, Git istemcisi daha basit _Aptal_ HTTP protokolüne geri dönmeye çalışacaktır. -Aptal protokol çıplak Git reposundan tıpkı ağ sunucusundan normal dosyalar gibi sunulmasını bekler. +Aptal protokol yalın Git reposundan tıpkı ağ sunucusundan normal dosyalar gibi sunulmasını bekler. Aptal HTTP'nin güzelliği kurulumunun basitliğidir. -Temelde yapmanız gereken, çıplak bir Git reposunu HTTP belge kökünüzün altına koymak ve belirli bir `post-update` kancası (hook) kurmaktır. +Temelde yapmanız gereken, yalın bir Git reposunu HTTP belge kökünüzün altına koymak ve belirli bir `post-update` kancası (hook) kurmaktır. İşte hepsi bu (Bkz: <>). Bu noktada, ağ sunucusuna yerleştirdiğiniz repoya erişebilen herkes, aynı zamanda repoyu da kopyalayabilir. Repoyu HTTP üzerinden okuma erişimine izin vermek için şunu yapabilirsiniz: @@ -113,7 +113,7 @@ Bu komut, bu repoya itme yaptığınızda (belki SSH üzerinden), ardından diğ $ git clone https://example.com/gitproject.git ---- -Bu özel durumda, Apache kurulumları için yaygın olan `/var/www/htdocs` yolu kullanılmıştır, ancak herhangi bir durağan (static) ağ sunucusunu kullanabilirsiniz (sadece çıplak repoyu dizinine koyun). +Bu özel durumda, Apache kurulumları için yaygın olan `/var/www/htdocs` yolu kullanılmıştır, ancak herhangi bir durağan (static) ağ sunucusunu kullanabilirsiniz (sadece yalın repoyu dizinine koyun). Git verileri temel durağan dosyalar olarak sunulur (tam olarak nasıl sunulduğu hakkında ayrıntılı bilgi için <> bölümüne bakın). Genellikle ya okuma/yazma yeteneğine sahip Akıllı HTTP sunucusunu çalıştırmayı seçersiniz ya da dosyaları aptal şekilde sadece salt okunabilir olarak erişilebilir yaparsınız. From b90a26041551dc8a4a828caa41514ac3ec2cb6a6 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 22:09:39 +0100 Subject: [PATCH 030/210] Update generating-ssh-key.asc 04.03 has been translated --- .../sections/generating-ssh-key.asc | 35 ++++++++++--------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 6ed59b1f..2ff2c233 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -1,13 +1,13 @@ [[_generate_ssh_key]] -=== Generating Your SSH Public Key +=== SSH Ortak Anahtarınızı Oluşturma (((SSH keys))) -Many Git servers authenticate using SSH public keys. -In order to provide a public key, each user in your system must generate one if they don't already have one. -This process is similar across all operating systems. -First, you should check to make sure you don't already have a key. -By default, a user's SSH keys are stored in that user's `~/.ssh` directory. -You can easily check to see if you have a key already by going to that directory and listing the contents: +Birçok Git sunucusu, kullanıcı kimliklerini SSH ortak anahtarları ile doğrular. +Bir ortak anahtar elde etmek için, sistemdeki ortak anahtarı olmaya her kullanıcının bir tane oluşturması gerekir. +Bu süreç tüm işletim sistemlerinde benzerdir. +İlk olarak, zaten bir anahtarınızın olup olmadığını kontrol etmelisiniz. +Varsayılan olarak, bir kullanıcının SSH anahtarları, kullanıcının `~/.ssh` dizininde depolanır. +Bu dizine gidip içeriği listeleyerek zaten bir anahtarınız olup olmadığını kolayca kontrol edebilirsiniz: [source,console] ---- @@ -17,9 +17,9 @@ authorized_keys2 id_dsa known_hosts config id_dsa.pub ---- -You're looking for a pair of files named something like `id_dsa` or `id_rsa` and a matching file with a `.pub` extension. -The `.pub` file is your public key, and the other file is the corresponding private key. -If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/macOS systems and comes with Git for Windows: +`id_dsa` veya `id_rsa` gibi adlara sahip bir çift dosya arıyorsunuz ve buna uygun `.pub` uzantılı bir dosya. +`.pub` dosyası ortak anahtarı temsil eder, diğer dosya ise buna karşılık gelen özel anahtardır. +Bu dosyalara sahip değilseniz (veya .ssh dizininiz bile yoksa), Linux/macOS sistemlerinde SSH paketi ile birlikte sağlanan ve Windows için Git ile birlikte gelen ssh-keygen adlı bir programı çalıştırarak bunları oluşturabilirsiniz. [source,console] ---- @@ -35,13 +35,13 @@ The key fingerprint is: d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local ---- -First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don't want to type a password when you use the key. -However, if you do use a password, make sure to add the `-o` option; it saves the private key in a format that is more resistant to brute-force password cracking than is the default format. -You can also use the `ssh-agent` tool to prevent having to enter the password each time. +İlk olarak, anahtarın nereye kaydedileceğini onaylanır (`.ssh/id_rsa`), ardından iki kez bir parola sorar (eğer anahtarı kullanırken bir şifre girmek istemiyorsanız, boş bırakabilirsiniz). +Ancak, bir parola kullanıyorsanız, parola kırma saldırılarına karşı daha dirençli olan bir formatta özel anahtarı kaydetmek için `-o` seçeneğini eklediğinizden emin olun (varsayılan formattan daha güvenlidir). +Ayrıca, her seferinde parolayı girmekten kaçınmak için `ssh-agent` aracını da kullanabilirsiniz. -Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you're using an SSH server setup that requires public keys). -All they have to do is copy the contents of the `.pub` file and email it. -The public keys look something like this: +Şimdi, bunu yapan her kullanıcı, ortak anahtarlarını size veya Git sunucusunu yöneten kişiye (eğer ortak anahtarları gerektiren bir SSH sunucu kurulumu kullanıyorsanız) göndermek zorundadır. +Yapmaları gereken tek şey `.pub` dosyasının içeriğini kopyalayıp e-posta ile göndermektir. +Ortak anahtarlar şu şekilde görünür: [source,console] ---- @@ -54,4 +54,5 @@ mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx NrRFi9wrf+M7Q== schacon@mylaptop.local ---- -For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://help.github.com/articles/generating-ssh-keys[]. +Farklı işletim sistemlerinde SSH anahtarı oluşturma konusunda daha detaylı bilgi için, SSH anahtarı oluşturma konusundaki GitHub rehberine göz atabilirsiniz: +https://help.github.com/articles/generating-ssh-keys[]. From 7a51cf3898e59d89442c58bc3afb41caa604a9ae Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 22:16:13 +0100 Subject: [PATCH 031/210] Update aliases.asc --- book/02-git-basics/sections/aliases.asc | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 4d076eca..d6946dbe 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -3,7 +3,7 @@ (((aliases))) Temel Git ile ilgili bu bölümü bitirmeden önce Git deneyiminizi daha basit, daha kolay ve daha tanıdık hale getirebilecek küçük bir ipucu vereceğiz: komut kısayolları. -Bu kitapta kısayol (alias) konusuna girmeyeceğiz veya ilerleyen bölümlerde bunları kullandığınızı varsaymayacağız, ancak bunları nasıl kullanacağınızı bilmenizde yine de fayda var. +Bu kitapta kısayol konusuna detaylıca girmeyeceğiz veya ilerleyen bölümlerde bunları kullandığınızı varsaymayacağız, ancak yine de nasıl kullanacağınızı bilmenizde fayda var. Eğer komutunuzun tamamını yazmazsanız, Git bir kısaltma yaptığınızı otomatik olarak anlayamaz. Git komutlarının tamamını uzun uzun yazmak istemiyorsanız, `git config` komutunu kullanarak, her komut için kolayca bir kısayol ayarlayabilirsiniz.(((git commands, config))) @@ -21,7 +21,7 @@ $ git config --global alias.st status Git'i kullanmaya devam ettikçe muhtemelen diğer komutları da sıklıkla kullanacaksınız; yeni kısayollar oluşturmaktan çekinmeyin. Bu tekniği aynı zamanda Git'te mevcut olmayan, ama olması gerektiğini düşündüğünüz komutların oluşturulmasında da kullanabilirsiniz. -Örneğin, bir dosyayı "stage"den kaldırırken karşılaştığınız "kullanılabilirlik" sorununu düzeltmek için Git'e kendi "stage"den kaldırma komutunuzu ekleyebilirsiniz: +Örneğin, bir dosyayı aşamalandırmadan (stage) kaldırırken karşılaştığınız "kullanılabilirlik" sorununu düzeltmek için Git'e kendi aşamadan kaldırma komutunuzu ekleyebilirsiniz: [source,console] ---- @@ -37,7 +37,8 @@ $ git reset HEAD -- fileA ---- Böylesi daha temiz görünüyor. -Bir `last` komutu eklemek de çok yaygındır. Şunun gibi: +Bir `last` komutu eklemek de çok yaygındır. +Şunun gibi: [source,console] ---- From a59e503146772ccf6551ce123f8071c83e3b95de Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 22:23:32 +0100 Subject: [PATCH 032/210] Update getting-a-repository.asc replacing some terms --- .../sections/getting-a-repository.asc | 27 ++++++++++--------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 91ff7654..e42eb06f 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,7 +1,7 @@ Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu bölüm aradığınız kısı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. -Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi aşamalandırıp (stage'e alıp) 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ı, "commit"ler 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. +Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi aşamalandırı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. [[_getting_a_repo]] @@ -9,15 +9,15 @@ Ayrıca Git'i belirli dosyaları ve dosya kalıplarını yok sayacak şekilde na Tipik olarak bir Git reposu oluşturmanın 2 yolu vardır: -1. Şu anda versiyon kontrolü altında olmayan bir yerel dizini (dosya yolu) alabilir ve onu bir Git reposuna dönüştürebilirsiniz. +1. Şu anda sürüm denetimi (version control) altında olmayan bir yerel dizini (dosya yolu) alabilir ve onu bir Git reposuna dönüştürebilirsiniz. Veya -2. Başka bir yerden var olan bir Git reposunu klonlayabilirsiniz. +2. Başka bir yerden var olan bir Git reposunu kopyalayabilirsiniz. Her iki durumda da, yerel makinenizde çalışmaya hazır bir Git reposuna sahip olursunuz. ==== Varolan Bir Dizinde Repo Başlatma -Eğer şu anda versiyon kontrolü altında olmayan bir proje diziniz var ve onu Git ile kontrol etmeye başlamak istiyorsanız, önce o projenin dizinine gitmeniz gerekmektedir. +Eğer şu anda sürüm denetimi altında olmayan bir proje diziniz var ve onu Git ile takip etmeye etmeye başlamak istiyorsanız, önce o projenin dizinine gitmeniz gerekmektedir. Eğer bunu daha önce yapmadıysanız, hangi işletim sisteminde çalıştığınıza bağlı olarak proje dizininiz farklı görünebilir. Linux için: @@ -43,11 +43,11 @@ Proje dizinine girdikten sonra şunu yazın: $ git init ---- -Bu, tüm gerekli repo dosyalarını içeren `.git` adında yeni bir alt dizin oluşturur. Yani bir Git repo temeli. +Bu, tüm gerekli repo dosyalarını içeren `.git` adında yeni bir alt dizin oluşturur (Yani bir Git repo temeli). Bu aşamada, projenizde henüz takip edilen bir şey yoktur. (Yeni oluşturduğunuz `.git` dizininde hangi dosyaların bulunduğuna dair daha fazla bilgi edinmek için <> bölümüne bakabilirsiniz.)(((git commands, init))) -Eğer halihazırda mevcut olan dosyaları versiyon kontrolüne almak istiyorsanız, boş bir dizin yerine, bu hazır dosyaları takip etmeye başlamalı ve bir 'initial commit' (ilk commit) yapmalısınız. +Eğer halihazırda mevcut olan dosyaları sürüm denetimine almak istiyorsanız, boş bir dizin yerine, bu hazır dosyaları takip etmeye başlamalı ve bir 'initial commit' (ilk katkı) yapmalısınız. Bunu, takip etmek istediğiniz dosyaları belirten birkaç `git add` komutu ve ardından bir `git commit` komutu ile başarabilirsiniz: [source,console] @@ -61,15 +61,16 @@ Bu komutların ne yaptığını birazdan inceleyeceğiz. Bu aşamada, takip edilen dosyaları içeren bir Git reponuz ve başlangıç 'initial commit'iniz vardır. [[_git_cloning]] -==== Mevcut bir Git Reposunu Klonlama (Kopyalama) +==== Mevcut bir Git Reposunu Kopyalama (Klonlama) Mevcut bir Git deposunun (örneğin katkıda bulunmak istediğiniz bir projenin) bir kopyasını almak istiyorsanız `git clone` komutunu kullanmalısınız. Eğer Subversion veya benzeri diğer VCS sistemlerine aşina iseniz, "checkout" yerine "clone" komutu kullanıldığını fark edeceksiniz. Bu önemli bir ayrımdır! Zira Git, yalnızca çalışan bir kopya almak yerine, sunucunun sahip olduğu neredeyse tüm verilerin tam bir kopyasını alır. -`git clone` komutunu çalıştırdığınızda, projenin tarihindeki her dosyanın her sürümü varsayılan olarak indirilir. -Aslında, sunucu diskiniz bozulursa, sunucuyu klonlandığı zamanki durumuna geri döndürmek için genellikle herhangi bir istemcideki klonların neredeyse tümünü kullanabilirsiniz (bazı sunucu tarafı kancalarını vb. kaybedebilirsiniz, ancak sürümlendirilmiş tüm verilere sahip olacaksınız. Daha fazla ayrıntı için: <>). +`git clone` komutunu çalıştırdığınızda, projenin geçmişindeki her dosyanın her sürümü varsayılan olarak indirilir. +Aslında, sunucu diskiniz bozulursa, sunucuyu kopyalandığı zamanki durumuna geri döndürmek için herhangi bir istemcideki kopyaların neredeyse tümünü kullanabilirsiniz (bazı sunucu tarafı kancalarını vb. kaybedebilirsiniz, ancak sürümlendirilmiş tüm verilere sahip olacaksınız. +Daha fazla ayrıntı için: <>). -Bir repoyu `git clone ` komutu ile klonlayabilirsiniz.(((git commands, clone))) +Bir repoyu `git clone ` komutu ile kopyalayabilirsiniz.(((git commands, clone))) Örneğin, "libgit2" adlı Git'e bağlanabilir kitaplığı kopyalamak istiyorsanız bunu şu şekilde yapabilirsiniz: [source,console] @@ -77,10 +78,10 @@ Bir repoyu `git clone ` komutu ile klonlayabilirsiniz.(((git commands, clon $ git clone https://github.com/libgit2/libgit2 ---- -Bu, içinde bir '.git' dizini olan 'libgit2' adında bir dizin oluşturur; bu repoya ait tüm verileri çeker ve ve en son sürümün çalışan bir kopyasını alır. +Bu, içinde bir '.git' dizini olan 'libgit2' adında bir dizin oluşturur, bu repoya ait tüm verileri çeker ve en son sürümün çalışan bir kopyasını alır. Yeni oluşturulan `libgit2` dizinine giderseniz, orada üzerinde çalışılmaya veya kullanılmaya hazır proje dosyalarını görebilirsiniz. -Depoyu 'libgit2' dışında bir isimle adlandırılan bir dizine kopyalamak istiyorsanız, yeni dizin adını ek bir argüman olarak belirtebilirsiniz: +Repoyu 'libgit2' dışında bir isimle adlandırılan bir dizine kopyalamak istiyorsanız, yeni dizin adını ek bir argüman olarak belirtebilirsiniz: [source,console] ---- From a424912f8fd8b9abae7e56bdb6c07bd5f8faf0e9 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sun, 4 Feb 2024 23:09:41 +0100 Subject: [PATCH 033/210] Update recording-changes.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit replacing terms: stage => aşama commit => katkı --- .../sections/recording-changes.asc | 201 ++++++++++-------- 1 file changed, 107 insertions(+), 94 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index ffeea2af..a89f6128 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,27 @@ === Değişikliklerin Repoya Kaydedilmesi Şu aşamada, yerel makinenizde bir Git reposuna ve önünüzde tüm dosyaları kullanıma hazır veya çalışmakta olan bir kopyasına sahip olmalısınız. -Doğal olarak, proje kaydetmek istediğiniz duruma her ulaştığında değişiklik yapmaya ve bu değişikliklerin anlık görüntülerini reponuza kaydetmeye başlamak isteyeceksiniz. +Doğal olarak, proje kaydetmek istediğiniz duruma her ulaştığında değişiklik yapmaya ve bu değişikliklerin pozlarını (snapshot) reponuza kaydetmeye başlamak isteyeceksiniz. Çalışma dizininizdeki her dosyanın iki durumdan birinde olabileceğini unutmayın: "tracked" (izlenen / takip edilen) veya "untracked" (izlenmeyen / takip edilmeyen). -İzlenen dosyalar, son anlık görüntüdeki (snapshot) dosyalardır: bunlar "modified" (değiştirilmiş), "unmodified" (değiştirilmemiş) veya "staged" (hazırlanmış) olabilirler. +İzlenen dosyalar, son pozdaki (snapshot) dosyalardır: bunlar "modified" (değiştirilmiş), "unmodified" (değiştirilmemiş) veya "staged" (aşamalandırılmış) olabilirler. Kısacası izlenen dosyalar Git'in haberdar olduğu ve değişikliklerini takip ettiği dosyalardır. -İzlenmeyen dosyalar ise diğer her şeydir; çalışma dizininizdeki, son anlık görüntünüzde olmayan ve hazırlama alanınızda (staging area) olmayan dosyalardır. -Bir repoyu ilk kez klonladığınızda, tüm dosyalarınız izlenecek ve "unmodified" (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız. +İzlenmeyen dosyalar ise diğer her şeydir (çalışma dizininizdeki, son pozda olmayan ve aşamalandırmada (staging area) olmayan dosyalardır). +Bir repoyu ilk kez kopyaladığınızda, tüm dosyalarınız izlenecek ve "unmodified" (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız. Siz dosyaları düzenlerken Git onları "modified" (değiştirilmiş) olarak görür, çünkü son Git işleminizden (commit, clone, push, vs) sonra bu dosyalarda değişiklik yaptınız. -Çalışırken, bu değiştirilmiş dosyaları seçerek "stage"e alırsınız (commit için hazırlarsınız) ve ardından "stage"e alınmış tüm bu değişiklikleri "commit" edersiniz. Ve döngü her değişiklikten sonra tekrarlanır. +Çalışırken, bu değiştirilmiş dosyaları seçerek aşamaya alırsınız (katkılamak için hazırlarsınız) ve ardından aşamalandırılmış tüm bu değişiklikleri katkı (commit) olarak işlersiniz. +Ve bu döngü her değişiklikten sonra tekrarlanır. .Dosyalarınızın durumunun yaşam döngüsü. -image::images/lifecycle.png[The lifecycle of the status of your files.] +image::images/lifecycle.png[Dosyalarınızın durumunun yaşam döngüsü.] [[_checking_status]] -==== Dosyalarınızın Durumunu Kontrol Etme +==== Dosyalarınızın Durumunu Denetleme -Hangi dosyaların hangi durumda olduğunu görmek için `git status` komutu kullanırız. (((git commands, status))) -Bu komutu bir projeyi klonladıktan hemen sonra çalıştırırsanız şöyle bir şey görmelisiniz: +Hangi dosyanın hangi durumda olduğunu görmek için `git status` komutu kullanırız.(((git commands, status))) +Bu komutu bir projeyi kopyaladıktan hemen sonra çalıştırırsanız şöyle bir şey görmelisiniz: [source,console] ---- @@ -30,11 +31,13 @@ Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- -Bu, temiz bir çalışma dizininiz olduğu anlamına gelir; bir başka deyişle, izlenen dosyalarınızın hiçbirinde henüz bir değişiklik yok. -Git ayrıca izlenmeyen (untracked) dosyaları görmez; aksi halde onlar da burada listelenirdi. -Son olarak bu komut size hangi projenin hangi dalında (branch) olduğunuzu söyler ve sunucuda klonladığınız daldan ayrılmadığınızı bildirir. -Şimdilik bu dal her zaman varsayılan olan ``master`` yani "ana dal"dır. Bunda endişelenmenizi gerektirecek bir durum yoktur. -<> ünitesinde dalları ve referansları ayrıntılı olarak göreceksiniz. +Bu, temiz bir çalışma dizininiz olduğu anlamına gelir. +Bir başka deyişle, izlenen dosyalarınızın hiçbirinde henüz bir değişiklik yoktur. +Git ayrıca izlenmeyen (untracked) dosyaları görmez, aksi halde onlar da burada listelenirdi. +Son olarak bu komut size hangi projenin hangi dalında (branch) olduğunuzu söyler ve sunucuda kopyaladığınız daldan ayrılmadığınızı bildirir. +Şimdilik bu dal her zaman varsayılan olan ``master`` yani "ana dal"dır. +Bunda endişelenmenizi gerektirecek bir durum yoktur. +<> ünitesinde dalları (branch) ve işaretçileri (reference) ayrıntılı olarak göreceksiniz. Diyelim ki projenize yeni bir dosya, mesela basit bir `README` (BENİ OKU) dosyası eklediniz. Dosya daha önce mevcut değilse ve `git status` komutunu çalıştırırsanız izlenmeyen dosyanızı şu şekilde görürsünüz: @@ -50,26 +53,27 @@ Untracked files: README -Henüz "commit" edilmek üzere hiçbir şey eklenmedi fakat izlenmeyen (untracked) yeni bir dosya var. (bu dosyayı izlemek için ``git add`` komutu kullanın) +nothing added to commit but untracked files present (use "git add" to track) ---- -Yeni `README` dosyanızın izlenmediğini görebilirsiniz çünkü durum çıktınızda (git status) ``Untracked files`` (İzlenmeyen dosyalar) başlığı altındadır. -"İzlenmeyen" (untracked) temel olarak Git'in önceki anlık görüntüde sahip olmadığınız bir dosyayı gördüğü anlamına gelir. Siz bunu yapmasını ``git commit`` komutuyla açıkça söyleyene kadar Git bunu "commit" görüntülerinize dahil etmeyecektir. -Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "binary" dosyaları veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. +Yeni `README` dosyanızın izlenmediğini görebilirsiniz, çünkü durum çıktınızda (git status) ``Untracked files`` (İzlenmeyen dosyalar) başlığı altındadır. +"İzlenmeyen" temel olarak Git'in önceki pozda sahip olmadığınız bir dosyayı gördüğü anlamına gelir. +Siz bunu yapmasını açıkça söyleyene kadar Git bunu pozlarınıza dahil etmeyecektir. +Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "binary" dosyaların veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. `README`yi dahil etmeye başlamak istiyorsanız, o halde dosyayı izlemeye başlayalım. [[_tracking_files]] ==== Yeni Dosyaları İzleme Yeni bir dosyayı izlemeye başlamak için `git add` komutu kullanılır.(((git commands, add))) -`README` dosyasını izlemeye başlamak için şu komutu çalıştırabilirsiniz: +`README` dosyasını izlemeye başlamak için şu komutu çalıştırın: [source,console] ---- $ git add README ---- -Durum komutunuzu (git status) tekrar çalıştırırsanız, `README` dosyanızın artık izlendiğini (tracked) ve kaydedilmek üzere hazırlandığını (Staging) görebilirsiniz: +Durum komutunuzu (git status) tekrar çalıştırırsanız, `README` dosyanızın artık izlendiğini (tracked) ve kaydedilmek üzere aşamalandırıldığını (Staging) görebilirsiniz: [source,console] ---- @@ -83,12 +87,14 @@ Changes to be committed: ---- -``Changes to be committed`` başlığı altında yer aldığından "stage" aşamasında olduğunu anlayabilirsiniz. -Bu noktada "commit" yaparsanız, dosyanın `git add`i çalıştırdığınız andaki sürümü, "commit" geçmişinize yeni bir "commit" olarak işlenecektir. -Daha önce `git init` komutunu çalıştırdığınızda, hemen ardından `git add ` komutunu çalıştırdınız; bunun amacı dizininizdeki dosyaları izlemeye başlamaktı.(((git commands, init)))(((git commands, add))) -`git add` komutu, bir dosya veya dizin için bir yol adı alır; eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları "stage"e ekler. +``Changes to be committed`` başlığı altında yer aldığından aşamalandırıldığını anlayabilirsiniz. +Bu noktada katkı işlerseniz (commit), dosyanın `git add`i çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. +Daha önce `git init` komutunu çalıştırdığınızda, hemen ardından `git add ` komutunu çalıştırdınız. +Bunun amacı dizininizdeki dosyaları izlemeye başlamaktı.(((git commands, init)))(((git commands, add))) +`git add` komutu, bir dosya veya dizin için bir yol adı alır. +Eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları aşamalandırmaya (takip listesine) ekler. -==== Değiştirilmiş Dosyaları "stage"e alma +==== Değiştirilmiş Dosyaları Aşamaya Alma Şimdi izlenmekte (tracked) olan bir dosyayı değiştirelim. Eğer izlenmnekte olan `CONTRIBUTING.md` adlı dosyayı değiştirir ve ardından `git status` komutunu tekrar çalıştırırsanız, şöyle bir sonuç elde edersiniz: @@ -111,11 +117,12 @@ Changes not staged for commit: ---- -`CONTRIBUTING.md` dosyası, ``Changes not staged for commit`` adlı bir bölümün altında görünür. Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği ancak henüz "stage"e alınmadığı anlamına gelir. -"stage"e almak için `git add` komutunu çalıştırmalısınız. -`git add` çok amaçlı bir komuttur: yeni dosyaları izlemeye başlamak, dosyaları "stage"e almak (commit için hazırlamak) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyleri yapmak için de kullanırsınız. +`CONTRIBUTING.md` dosyası, ``Changes not staged for commit`` adlı bir bölümün altında görünür. +Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği, ancak henüz aşamaya (stage) alınmadığı anlamına gelir. +Aşamaya almak için `git add` komutunu çalıştırmalısınız. +`git add` çok amaçlı bir komuttur: yeni dosyaları izlemeye başlamak, dosyaları aşamaya almak (katkı için hazırlamak) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyler için de kullanırsınız. Bunu, "bu dosyayı projeye ekle" yerine "bu içeriği bir sonraki işleme ekle" olarak düşünmek daha faydalı olabilir.(((git commands, add))) -Şimdi `CONTRIBUTING.md` dosyasını "stage"e almak için `git add` komutunu çalıştıralım ve ardından `git status` komutunu bir kez daha çalıştıralım: +Şimdi `CONTRIBUTING.md` dosyasını aşamaya almak için `git add` komutunu çalıştıralım ve ardından `git status` komutunu bir kez daha koşalım: [source,console] ---- @@ -131,10 +138,10 @@ Changes to be committed: ---- -Her iki dosya da "stage"dedir ve bir sonraki işleminize aktarılacaktır. +Her iki dosya da aşamadadır ve bir sonraki işleminize aktarılacaktır. Bu noktada, varsayalım ki `CONTRIBUTING.md`de yapmak istediğiniz küçük bir değişikliği hatırladınız. -Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi "commit" etmeye hazırsınız. -Şimdi `git status` komutunu bir kez daha çalıştıralım: +Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi katkı olarak işlemeye hazırsınız. +Hadi `git status` komutunu bir kez daha çalıştıralım: [source,console] ---- @@ -156,12 +163,12 @@ Changes not staged for commit: ---- -Bu da ne? +Bu da ne!? Artık `CONTRIBUTING.md` hem "staged" hem de "unstaged" olarak listelenmiş. -Bu nasıl olabilir? -Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi "stage"e aktardığını görüyorsunuz. -Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md`nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki versiyonu kayıt işlemine girecektir. -`git add`i çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü hazırlamak için `git add`i tekrar çalıştırmanız gerekir: +Peki neden böyle oldu!? +Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi aşamaya aldığını görüyorsunuz. +Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md`nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. +`git add`i çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü aşamalandırmak için `git add`i tekrar çalıştırmanız gerekir: [source,console] ---- @@ -176,10 +183,10 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Kısa Durum (Status) Bilgisi +==== Kısa-Durum Bilgisi `git status` çıktısı oldukça kapsamlı ve aynı zamanda da uzundur. -Git'te ayrıca kısa bir durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. +Git'te ayrıca bir kısa-durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. Eğer `git status -s` veya `git status --short` komutunu çalıştırırsanız, çok daha basitleştirilmiş bir çıktı elde edersiniz: [source,console] @@ -192,10 +199,11 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -İzlenmeyen yeni dosyaların yanında `??`, "stage" alanına eklenen yeni dosyaların yanında `A` (added), değiştirilen dosyaların yanında ise `M` (modified) bulunur. -Çıktıda iki sütun vardır; soldaki sütun "stage" alanının durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. -Örneğin bu çıktıda, `README` dosyası çalışma dizininde değiştirilmiş ancak henüz "stage"e alınmamıştır. `lib/simplegit.rb` dosyası ise değiştirilmiş ve "stage"e alınmıştır. -`Rakefile` değiştirildi (modified), hazırlandı (stage'e alındı) ve tekrar değiştirildi, dolayısıyla üzerinde hem "staged" hem de "unstaged" değişiklikler var. +İzlenmeyen yeni dosyaların yanında `??`, aşama alanına eklenen yeni dosyaların yanında `A` (added), değiştirilen dosyaların yanında ise `M` (modified) bulunur. +Çıktıda iki sütun vardır: soldaki sütun aşama alanının durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. +Örneğin bu çıktıda, `README` dosyası çalışma dizininde değiştirilmiş ancak henüz aşamaya alınmamıştır. `lib/simplegit.rb` dosyası ise değiştirilmiş ve aşamaya alınmıştır. +`Rakefile` değiştirildi (modified), aşamaya alındı (staged) ve tekrar değiştirildi (changed). +Dolayısıyla üzerinde hem "staged" hem de "unstaged" değişiklikler var. [[_ignoring]] ==== Dosyaları Yoksayma (Ignore) @@ -215,14 +223,15 @@ $ cat .gitignore İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı ``.o`` veya ``.a`` ile biten (object ve archive) tüm dosyaları yoksaymasını söyler. İkinci satır Git'e, adları tilde (`~`) ile biten tüm dosyaları yok saymasını söyler; bu, Emacs gibi birçok metin düzenleyicisi tarafından geçici dosyaları işaretlemek için kullanılır. Ayrıca otomatik olarak oluşturulan log (kayıt), tmp (geçici) veya pid (işlem kimliği) vb dizinleri de ekleyebilirsiniz. -Başlamadan önce yeni reponuz için bir `.gitignore` dosyası oluşturmak genellikle iyi bir fikirdir. Böylece Git reponuzda görmek istemediğiniz dosyaları yanlışlıkla "commit" etmezsiniz. +Başlamadan önce yeni reponuz için bir `.gitignore` dosyası oluşturmak iyi bir fikirdir. +Böylece Git reponuzda görmek istemediğiniz dosyaları yanlışlıkla katkı olarak işlemezsiniz. -`.gitignore` dosyasını yazarken göz önünde bulundurmanız gereken kurallar aşağıdaki gibidir: +`.gitignore` dosyasını yazarken göz önünde bulundurmanız gereken kurallar şunlardır: * Boş satırlar veya `#` ile başlayan satırlar dikkate alınmaz. * Standart glob desenleri işler. Yani yazdığınız kural çalışma ağacınızdaki tüm dosyalar için alt dizinleri de dahil olmak üzere geçerlidir. * Bu alt dizinlere inen yinelemeyi önlemek için dosya dizinine eğik çizgi (`/`) ile başlayabilirsiniz. -* Kuralın geçerli olmasını istediğimiz sadece belli bir dizini belirtmek için dosya dizinini eğik çizgiyle (`/`) sonlandırabilirsiniz. +* Kuralın geçerli olmasını istediğimiz belli bir dizini belirtmek için dosya dizinini eğik çizgiyle (`/`) sonlandırabilirsiniz. * Kuralın uygulanmasını istemediğiniz bir modeli ünlem işaretiyle (`!`) başlatarak reddedebilirsiniz. Glob desenleri, "shell"in kullandığı "RegEx" ifadelerine benzer: @@ -267,18 +276,20 @@ Yine de alt dizinlerde ek `.gitignore` dosyalarının bulunması da mümkündür Bu iç içe geçmiş `.gitignore` dosyalarındaki kurallar yalnızca bulundukları dizinin alt klasörlerinde bulunan dosyalar için geçerlidir. (Örneğin Linux çekirdeği kaynak reposunda 206 adet `.gitignore` dosyası bulunmaktadır.) -Birden fazla ".gitignore" dosyası bulunduğu durumlar bu kitabın kapsamı dışındadır. Bu konuda daha detaylı bilgiye konsol ekranınıza "man gitignore" komutu yazarak ulaşabilirsiniz. +Birden fazla ".gitignore" dosyası bulunduğu durumlar bu kitabın kapsamı dışındadır. +Bu konuda daha detaylı bilgiye konsol ekranınıza "man gitignore" komutu yazarak ulaşabilirsiniz. ==== [[_git_diff_staged]] -==== "Staged" ve "Unstaged" Değişiklikleri Görme +==== Aşamalandırılmış (Staged) ve Aşamalandırılmamış (Unstaged) Değişiklikleri Görme `git status` komutu sizin için yeterince bilgi içermiyorsa (sadece hangi dosyaların değiştirildiğini değil, tam olarak neyi değiştirdiğinizi de bilmek istiyorsanız), bunun yerine `git diff` komutunu kullanabilirsiniz.(((git commands, diff))) -`git diff`i daha sonra daha ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç duyacaksınız: Neyi değiştirdiniz ama henüz "stage"e almadınız? -Neyi "stage"e aldınız fakat henüz "commit" etmediniz? -Her ne kadar `git status` bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da, `git diff` size eklenen ve kaldırılan satırları değiştirilen her bir kod parçasıyla birlikte detaylıca gösterir. +`git diff`i daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç kullanacaksınız: +1. Neyi değiştirdiniz ama henüz aşamaya almadınız? +2. Neyi aşamaya aldınız fakat henüz katkı olarak işlemediniz? +Her ne kadar `git status` bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da `git diff` size; eklenen ve kaldırılan satırları, değiştirilen her bir kod parçasıyla birlikte, detaylıca gösterir. -Diyelim ki `README` dosyasını tekrar değiştirip "stage"e alıyorsunuz ve ardından `CONTRIBUTING.md` dosyasını "stage"e almadan düzenliyorsunuz. +Diyelim ki `README` dosyasını tekrar değiştirip aşamaya alıyorsunuz ve ardından `CONTRIBUTING.md` dosyasını aşamaya almadan düzenliyorsunuz. `git status` komutunuzu çalıştırırsanız bir kez daha şöyle bir şey görürsünüz: [source,console] @@ -298,7 +309,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Neyi değiştirdiğinizi ancak henüz "stage"e almadığınızı görmek için herhangi bir argüman kullanmadan `git diff' yazın: +Neyi değiştirdiğinizi ancak henüz aşamaya almadığınızı görmek için herhangi bir bayrak (parametre) kullanmadan `git diff' yazın: [source,console] ---- @@ -319,11 +330,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -Bu komut, çalışma dizininizdeki güncel kodu, "stage" alanınızdaki kodla karşılaştırır. +Bu komut, çalışma dizininizdeki güncel kodu, aşama alanınızdaki kodla karşılaştırır. Sonuç size, henüz gerçekleştirmediğiniz değişiklikleri görme imkanı tanır. -Eğer bir sonraki "commit" işleminizde nelerin kaydedileceğini görmek istiyorsanız ``git diff --staged`` komutunu kullanabilirsiniz. -Bu komut, "stage" deki değişikliklerinizi, en son "commit" ettiğiniz kodla karşılaştırır: +Eğer bir sonraki katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız ``git diff --staged`` komutunu kullanabilirsiniz. +Bu komut, aşamadaki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır: [source,console] ---- @@ -337,10 +348,10 @@ index 0000000..03902a1 +My Project ---- -`git diff` komutunun son "commit" işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz "stage"e alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. -Eğer tüm değişikliklerinizi "stage"e aldıysanız, `git diff` size hiçbir çıktı vermeyecektir. +`git diff` komutunun son katkı işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz aşamaya alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. +Eğer tüm değişikliklerinizi aşamaya aldıysanız, `git diff` size hiçbir çıktı vermeyecektir. -Bir başka örnek olarak, `CONTRIBUTING.md` dosyasını "stage"e alır ve ardından yeniden düzenlerseniz, dosyadaki "staged" ve "unstaged" değişiklikleri görmek için `git diff` komutunu kullanabilirsiniz. +Bir başka örnek olarak, `CONTRIBUTING.md` dosyasını aşamaya alır ve ardından yeniden düzenlerseniz, dosyadaki aşamalandırılmış ve aşamalandırılmamış değişiklikleri görmek için `git diff` komutunu kullanabilirsiniz. Ortamımız şöyle görünüyorsa: [source,console] @@ -362,7 +373,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Artık neyin "unstaged" olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: +Artık neyin aşamalandırılmamış olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: [source,console] ---- @@ -378,7 +389,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -veya şu ana kadar neleri "stage"e aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: +veya şu ana kadar neleri aşamaya aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: [source,console] ---- @@ -403,19 +414,19 @@ index 8ebb991..643e24f 100644 Harici Araçlarda .Git Diff ==== Kitabın geri kalanında `git diff` komutunu çeşitli şekillerde kullanmaya devam edeceğiz. -Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine grafiksel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka bir yolu daha vardır. +Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine grafiksel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka bir yolları da vardır. Eğer `git diff` yerine `git difftool` komutu çalıştırırsanız, bu farklardan herhangi birini "emerge", "vimdiff" ve daha birçok farklı yazılımda (ticari yazılımlar dahil) görüntüleyebilirsiniz. Sisteminizde hangilerinin mevcut olduğunu görmek için `git difftool --tool-help` komutunu çalıştırabilirsiniz. ==== [[_committing_changes]] -==== Değişiklikleri "commit" olarak kaydetmek +==== Değişiklikleri Katkı Olarak İşlemek -Artık "stage" alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi "commit" olarak kaydedebilirsiniz. -"unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç `git add` komutuyla "stage"e almadığınız dosyalar) bu işlemle "commit" geçmişine/listesine kaydedilmeyeceğini aklınızdan çıkarmayın. +Artık aşama alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi katkı olarak işleyebilirsiniz. +"unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç `git add` komutuyla aşamaya almadığınız dosyalar) bu işlemle katkı geçmişine kaydedilmeyeceğini aklınızdan çıkarmayın. Bu dosyalar diskinizde "modified" (değiştirilmiş) işaretli olarak kalacaklar. -Bu durumda, eğer bir kez daha `git status` komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğun görürseniz, artık değişikliklerinizi "commit" olarak kaydetmeye hazırsınız demektir.(((git commands, status))) -Değişikliklerinizi "commit" etmenin en basit yolu `git commit` komutunuzu çalıştırmaktır:(((git commands, commit))) +Bu durumda, eğer bir kez daha `git status` komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğun görürseniz, artık değişikliklerinizi katkı olarak işlemeye hazırsınız demektir.(((git commands, status))) +Değişikliklerinizi işlemenin en basit yolu `git commit` komutunu çalıştırmaktır:(((git commands, commit))) [source,console] ---- @@ -445,13 +456,13 @@ Ekranda aşağıdaki metni göreceksiniz (bu örnek bir Vim ekranıdır): ".git/COMMIT_EDITMSG" 9L, 283C ---- -Varsayılan "commit" mesajının, yorumlanan `git status` komutunun en son çıktısını ve üstte bir boş satırı içerdiğini görebilirsiniz. -Bu yorumları kaldırabilir ve "commit" mesajınızı yazabilir veya neyi "commit" ettiğinizi hatırlamanıza yardımcı olması için orada bırakabilirsiniz. +Varsayılan katkı mesajının, yorumlanan `git status` komutunun en son çıktısını ve üstte bir boş satırı içerdiğini görebilirsiniz. +Bu yorumları kaldırabilir ve katkı mesajınızı yazabilir veya neyi katkı olarak işlediğinizi hatırlamanıza yardımcı olması için orada bırakabilirsiniz. (Neyi değiştirdiğinizi daha da açık bir şekilde hatırlatmak için, `git commit` komutuna `-v` bayrağı ekleyebilirsiniz. Böylece yaptığınız değişikliği (diff) da derleyicinize eklemiş olursunuz ve ileride tam olarak hangi değişiklikleri yaptığınızı görebilirsiniz.) -Derleyicinizden çıktığınızda, Git bu mesajla birlikte (yorumlar ve değişiklikler çıkarılmış olarak) commit kaydınızı oluşturur. +Derleyicinizden çıktığınızda, Git bu mesajla birlikte (yorumlar ve değişiklikler çıkarılmış olarak) katkı kaydınızı oluşturur. -Alternatif olarak, `-m` (message) bayrağı kullanarak "commit" mesajınızı `commit` komutuyla aynı satırda yazabilirsiniz: +Alternatif olarak, `-m` (message) bayrağı kullanarak katkı mesajınızı `commit` komutuyla aynı satırda yazabilirsiniz: [source,console] ---- @@ -461,19 +472,20 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Tebrikler artık ilk "commit" kaydınızı oluşturdunuz! -Bu "commit" kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz: değişiklikleri hangi dala (`master`) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (gelecekte bir "commit"e geri dönmek istediğinizde tam olarak hangi "commit"e dönmek istediğinizi belirtebilmeniz içih her bir "commit"inizin kendine özel bir SHA-1 kodu bulunur. Bu bir nevi kaydınızın kimlik numarası gibidir.) sahip olduğu ('463dc4f'), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır. +Tebrikler artık ilk katkınızı işlediniz! +Bu katkı kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz; değişiklikleri hangi dala (`master`) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (Gelecekte bir katkıya geri dönmek istediğinizde tam olarak hangi katkıya dönmek istediğinizi belirtebilmeniz içih her bir katkınızın kendine özel bir SHA-1 kodu bulunur. Bu bir nevi kaydınızın kimlik numarası gibidir.) sahip olduğu ('463dc4f'), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır. -"commit" kayıtlarınızın, "stage" alanınıza yüklediğiniz codun anlık görüntüsü olduğunu unutmayın. -"stage"e almadığınız her şey dosya ve kod hala orada değiştirilmiş halde duruyor; bunları "commit" geçmişinize eklemek için başka bir "commit" işleminde bulunabilirsiniz. -Aslında her "commit" gerçekleştirdiğinizde, projenizin daha sonra geri dönebileceğiniz veya karşılaştırabileceğiniz bir anlık görüntüsünü kaydetmiş oluyorsunuz. +Katkı kayıtlarınızın aşama alanınıza yüklediğiniz codun pozu (snapshot) olduğunu unutmayın. +Aşamaya almadığınız her şey dosya ve kod hala orada değiştirilmiş halde duruyor. +Bunları katkı geçmişinize eklemek için başka bir katkı işleminde bulunabilirsiniz. +Aslında her katkı işlediğinizde, projenizin daha sonra geri dönebileceğiniz veya karşılaştırabileceğiniz bir pozunu kaydetmiş oluyorsunuz. -==== "Stage" Alanını Atlamak +==== Aşama (Stage) Alanını Atlamak (((staging area, skipping))) -"stage" alanı "commit"lerinizin tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. -"stage" alanını atlamak istiyorsanız Git basit bir kısayol sağlar. -`git commit` komutuna `-a` (add) seçeneğinin eklenmesi, Git'in zaten izlenen her dosyayı taahhütte bulunmadan önce otomatik olarak "stage"e almasını sağlar ve `git add` kısmını atlamanıza olanak tanır: +Aşama alanı katkılarınızın tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. +Aşama alanını atlamak istiyorsanız Git basit bir kısayol sağlar. +`git commit` komutuna `-a` (add) seçeneğinin eklenmesi, Git'in zaten izlenen her dosyayı katkıda bulunmadan önce otomatik olarak aşamaya almasını sağlar ve `git add` kısmını atlamanıza olanak tanır: [source,console] ---- @@ -492,16 +504,17 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Bu durumda "commit" yapmadan önce `CONTRIBUTING.md` dosyasında `git add` komutunu çalıştırmanız gerekmediğine dikkat edin. -Bunun nedeni `-a` bayrağının değiştirilen tüm dosyaları içermesidir. -Bunu yapmakta herhangi bir sorun yoktur ancak dikkatli olun; bazen bu bayrak istenmeyen değişiklikleri de "commit"inize eklemenize neden olur. +Bu durumda katkı işlemeden önce `CONTRIBUTING.md` dosyasında `git add` komutunu çalıştırmanız gerekmediğine dikkat edin. +Bunun nedeni `-a` (all) bayrağının değiştirilen tüm dosyaları içermesidir. +Bunu yapmakta herhangi bir sorun yoktur ancak dikkatli olun; bazen bu bayrak istenmeyen değişiklikleri de katkılarınıza eklemenize neden olur. [[_removing_files]] ==== Dosyaları Silmek (((files, removing))) -Git'ten bir dosyayı kaldırmak için, onu izlenen dosyalar listenizden (yani "stage"den) kaldırmanız ve ardından bu değişikliği kaydetmeniz ("commit" etmeniz) gerekir. -`git rm` komutu seçtiğiniz dosyayı hem "stage" alanından hem de çalışma dizininizden kaldırır. Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. +Git'ten bir dosyayı kaldırmak için, onu izlenen dosyalar listenizden (stage) kaldırmanız ve ardından bu değişikliği kaydetmeniz (commit) gerekir. +`git rm` komutu seçtiğiniz dosyayı hem aşama alanından hem de çalışma dizininizden kaldırır. +Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. Eğer dosyayı silmek yerine sadece takipten çıkarmak istiyorsanız dosya yolunu ve adını `.gitignore` dosyasına kaydetmelisiniz. Dosyayı sadece çalışma dizininizden kaldırırsanız, dosyanızı `git status` çıktınızın ``Changes not staged for commit`` (yani _unstaged_) alanında görebilirsiniz: @@ -521,7 +534,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Daha sonra, eğer `git rm` komutunu çalıştırırsanız, dosyanın kaldırılması işlemini "stage" alanına almış olursunuz: +Daha sonra, eğer `git rm` komutunu çalıştırırsanız, dosyanın kaldırılması işlemini aşama alanına almış olursunuz: [source,console] ---- @@ -536,13 +549,13 @@ Changes to be committed: deleted: PROJECTS.md ---- -Bir sonraki "commit" işleminizde dosya kaybolacak ve artık izlenmeyecektir. -Dosyayı değiştirdiyseniz veya "stage" alanına zaten eklediyseniz, Git'i kaldırma işlemine zorlamak için `-f` (forced) seçeneğini kullanmalısınız. -Bu, henüz anlık görüntüye kaydedilmemiş ve Git'ten kurtarılamayan verilerin yanlışlıkla kaldırılmasını önleyen bir güvenlik özelliğidir. +Bir sonraki katkı işleminizde dosya kaybolacak ve artık izlenmeyecektir. +Dosyayı değiştirdiyseniz veya aşama alanına zaten eklediyseniz, Git'i kaldırma işlemine zorlamak için `-f` (forced) seçeneğini kullanmalısınız. +Bu, henüz poz olarak kaydedilmemiş ve Git'ten kurtarılamayan verilerin yanlışlıkla kaldırılmasını önleyen bir güvenlik özelliğidir. -Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak "stage" alanınızdan kaldırmaktır. -Başka bir deyişle, dosyayı sabit diskinizde tutmak ancak Git'in artık onu izlememesini sağlamak istemeyebilirsiniz. -Eğer `.gitignore` dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla "stage"e aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş `.a` dosyaları gibi) bu özellik oldukça işinize yarayacaktır. +Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak aşama alanınızdan kaldırmaktır. +Başka bir deyişle, dosyayı sabit diskinizde tutmak ancak Git'in artık onu izlememesini sağlamak isteyebilirsiniz. +Eğer `.gitignore` dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla aşamaya aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş `.a` dosyaları gibi) bu özellik oldukça işinize yarayacaktır. Bunu yapmak için `--cached` seçeneğini kullanın: [source,console] @@ -611,5 +624,5 @@ $ git add README ---- Git bunun dolaylı olarak bir yeniden adlandırma olduğunu anlar, dolayısıyla bir dosyayı bu şekilde veya `mv` komutuyla yeniden adlandırmanız önemli değildir. -Tek dikkate değen fark, `git mv` komutunun üç yerine tek bir komut olmasıdır; bu da bize kolaylık sağlar. -Daha da önemlisi, bir dosyayı yeniden adlandırmak için istediğiniz herhangi bir aracı kullanabilir ve ardından add/rm ile adresleyerek dosyayı "commit" edilmeye uygun hale getirebiliriz. +Tek dikkate değen fark, `git mv` komutunun üç yerine tek bir komut olmasıdır ki bu da bize kolaylık sağlar. +Daha da önemlisi, bir dosyayı yeniden adlandırmak için istediğiniz herhangi bir aracı kullanabilir ve ardından add/rm ile adresleyerek dosyayı katkı olarak işlemeye uygun hale getirebiliriz. From 98e9e23263586f27d6024cda669bf0230baca21c Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 08:05:33 +0100 Subject: [PATCH 034/210] Update remotes.asc change in terminology: commit, push, pull, merge --- book/02-git-basics/sections/remotes.asc | 75 ++++++++++++++----------- 1 file changed, 41 insertions(+), 34 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index e082c7fc..50de24bb 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,26 +1,27 @@ [[_remote_repos]] === Uzak Repo ile Çalışmak -Herhangi bir Git projesinde işbirliği yapabilmek için uzak depolarınızı nasıl yöneteceğinizi bilmeniz gerekir. -Uzak depolar, projenizin İnternette veya ağda bir yerde barındırılan sürümleridir. -Bunlardan birkaçına sahip olabilirsiniz; bunların her biri genellikle sizin için salt okunurdur veya okuma/yazmadır. -Başkalarıyla işbirliği yapmak, bu uzak depoları yönetmeyi ve işlerinizi paylaşmanız gerektiğinde verileri bu havuzlara gönderip almayı içerir. -Uzak depoların yönetilmesi, uzak depoların nasıl ekleneceğini, artık geçerli olmayan uzaktan kumandaların nasıl kaldırılacağını, çeşitli uzak dalların nasıl yönetileceğini ve bunların izlenip izlenmediğini nasıl tanımlayacağınızı ve daha fazlasını bilmeyi içerir. +Herhangi bir Git projesinde işbirliği yapabilmek için uzak repolarınızı nasıl yöneteceğinizi bilmeniz gerekir. +Uzak repolar, projenizin İnternette veya ağda bir yerde barındırılan sürümleridir. +Bunlardan birkaçına sahip olabilirsiniz. +Bunların her biri genellikle sizin için salt okunur veya okuma/yazma erişimlidir. +Başkalarıyla işbirliği yapmak, bu uzak repoları yönetmeyi ve işlerinizi paylaşmanız gerektiğinde verileri bu havuzlara gönderip almayı içerir. +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] -.Uzak depolar yerel makinenizde olabilir. +.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. 'Uzak' kelimesi, veri deposunun ağda veya internette başka bir yerde olduğu anlamına gelmez, yalnızca başka bir yerde olduğu anlamına gelir. -Böyle bir uzak repoyla çalışmak, diğer uzaktan server'larda olduğu gibi yine de tüm standart push (kod gönderme), pull (kod çekme) ve fetch (kavrama) işlemlerini içerecektir. +Böyle bir uzak repoyla çalışmak, diğer uzaktan sunucularda olduğu gibi yine de tüm standart itme (push), çekme (pull) ve getirme (fetch) işlemlerini içerecektir. ==== ==== Uzak Sunucuları Görme Hangi uzak sunucuları yapılandırdığınızı görmek için `git remote` komutunu çalıştırabilirsiniz.(((git commands, remote))) -Bu belirttiğiniz her uzak tanıtıcının kısa adlarını listeler. -Reponuzu klonladıysanız en azından `Origin`i görmelisiniz; Git'in klonladığınız sunucuya verdiği varsayılan isim budur: +Bu belirttiğiniz her uzak sunucunun kısa adlarını listeler. +Reponuzu kopyaladıysanız en azından `Origin`i görmelisiniz (Git'in kopyaladığınız sunucuya verdiği varsayılan isim budur): [source,console] ---- @@ -65,9 +66,9 @@ origin git@github.com:mojombo/grit.git (push) ---- Bu, diğer geliştiricilerden kolaylıkla katkı alabileceğimiz anlamına gelir. -Ayrıca bunlardan bir veya daha fazlasını zorlama iznimiz olabilir, ancak bunu buradan söylemek mümkün değil. +Ayrıca bunlardan bir veya daha fazlasını zorlama iznimiz olabilir, ancak bu ekrandan bu çıkarımda bulunmak mümkün değil. -Bu uzak sunucuların çeşitli protokoller kullandığına dikkat edin; Bu konu hakkında daha fazla bilgiyi <> bölümünde ele alacağız. +Bu uzak sunucuların çeşitli protokoller kullandığına dikkat edin (Bu konu hakkında daha fazla bilgiyi <> bölümünde ele alacağız). ==== Uzak Sunucuları Görme @@ -102,13 +103,14 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul'un ana-dalına (master branch) artık yerelde `pb/master` olarak erişilebilmektedir. Onu kendi dallarınızdan biriyle birleştirebilirsiniz veya incelemek isterseniz herhangi bir dala geçerek göz atabilirsiniz. +Paul'un ana-dalına (master branch) artık yerelde `pb/master` olarak erişilebilmektedir. +Onu kendi dallarınızdan biriyle birleştirebilirsiniz veya incelemek isterseniz herhangi bir dala geçerek göz atabilirsiniz. (Dalların ne olduğunu ve bunların nasıl kullanılacağını <> bölümünde çok daha ayrıntılı olarak ele alacağız.) [[_fetching_and_pulling]] -==== Uzak Sunucudan Yakalama ve Getirme +==== Uzak Sunucudan Getirme ve Çekme -Az önce gördüğünüz gibi uzak projelerinizden veri almak için aşağıdaki komutu çalıştırabilirsiniz.:(((git commands, fetch))) +Az önce gördüğünüz gibi uzak projelerinizden veri almak için aşağıdaki komutu çalıştırabilirsiniz:(((git commands, fetch))) [source,console] ---- @@ -116,38 +118,43 @@ $ git fetch ---- Komut o uzak projeye gider ve o uzak projeden henüz sahip olmadığınız tüm verileri çeker. -Bunu yaptığınız takdirde o uzak sunucudaki tüm dallara erişim için gerekli referanslara sahip olacaksınız. Böylece istediğiniz zaman kodları inceleyebilir veya kendi kodunuzla birleştirebilirsiniz. +Bunu yaptığınız takdirde, o uzak sunucudaki tüm dallara erişim için gerekli referanslara sahip olacaksınız. +Böylece istediğiniz zaman kodları inceleyebilir veya kendi kodunuzla birleştirebilirsiniz. -Eğer bir repoyu klonlarsanız, komut o uzak repoyu otomatik olarak ``Origin`` adı altına ekler. -Yani, `git fetch origin`, klonlamanızdan (veya sunucudan son getirmenizden) bu yana sunucuya gönderilen tüm yeni çalışmaları getirir. -Git fetch komutunun verileri yalnızca yerel reponuza indirdiğini unutmamalısınız. Verileri herhangi bir çalışmanızla otomatik olarak birleştirmez veya üzerinde çalışmakta olduğunuz kodu değiştirmez. +Eğer bir repoyu kopyalarsanız, komut o uzak repoyu otomatik olarak ``Origin`` adı altına ekler. +Yani, `git fetch origin`, kopyalamanızdan (veya sunucudan son getirmenizden) bu yana sunucuya gönderilen tüm yeni çalışmaları getirir. +`git fetch` komutunun verileri yalnızca yerel reponuza indirdiğini unutmamalısınız. +Verileri herhangi bir çalışmanızla otomatik olarak birleştirmez veya üzerinde çalışmakta olduğunuz kodu değiştirmez. Hazır olduğunuzda bunu manuel olarak kendi kodunuzla birleştirmeniz gerekir. -Geçerli dalınız uzak bir dalı izleyecek şekilde ayarlanmışsa (daha fazla bilgi için sonraki bölüme ve <>'e bakın), otomatik olarak getirmek için `git pull` komutunu kullanabilirsiniz. Daha sonra bu uzak dalı mevcut dalınızla birleştirin.(((git commands, pull))) -Bu size daha kolay veya daha rahat bir iş akışı sağlar. Varsayılan olarak `git clone` komutu, yerel ana dalınızı (genellikle main veya master olarak adlandırılır), klonladığınız uzak sunucudaki uzak ana dalı (veya varsayılan dalın adı her neyse) izleyecek şekilde otomatik olarak ayarlar. -`git pull` komutunu çalıştırmak genellikle verileri orijinal olarak klonladığınız sunucudan getirir ve otomatik olarak bu verileri üzerinde çalışmakta olduğunuz kodla birleştirmeye çalışır. +Geçerli dalınız uzak bir dalı izleyecek şekilde ayarlanmışsa (daha fazla bilgi için sonraki bölüme ve <>'e bakın), bu değişiklikleri otomatik olarak getirmek için `git pull` komutunu kullanabilirsiniz. +Daha sonra bu uzak dalı mevcut dalınızla birleştirin.(((git commands, pull))) +Bu size daha kolay veya daha rahat bir iş akışı sağlar. +Varsayılan olarak `git clone` komutu, yerel ana dalınızı (genellikle main veya master olarak adlandırılır), kopyaladığınız uzak sunucudaki uzak ana dalı (veya varsayılan dalın adı her neyse) izleyecek şekilde otomatik olarak ayarlar. +`git pull` komutunu çalıştırmak genellikle verileri kopyaladığınız asıl sunucudan getirir ve otomatik olarak bu verileri üzerinde çalışmakta olduğunuz kodla birleştirmeye çalışır. [[_pushing_remotes]] -==== Kodlarınızı Uzak Sunucuya Göndermek (push etmek) +==== Kodlarınızı Uzak Sunucuya İtmek (push) -Projeniz belli bir aşamaya ulaştıktan sonra paylaşmak isteyebilirsiniz. Bunun için geliştirilmiş kodunuzu uzak repoya göndermeniz (push etmek) gerekmektedir. +Projeniz belli bir aşamaya ulaştıktan sonra paylaşmak isteyebilirsiniz. +Bunun için geliştirilmiş kodunuzu uzak repoya itmeniz gerekmektedir. Bunun için kullanmanız gereken komut basittir: `git Push `.(((git commands, push))) -Ana dalınızı "Origin" sunucunuza göndermek istiyorsanız (yine klonlama genellikle bu adların her ikisini de sizin için otomatik olarak ayarlar), o zaman yaptığınız "commitleri sunucuya geri göndermek için şunu çalıştırabilirsiniz: +Ana dalınızı "Origin" sunucunuza göndermek istiyorsanız (yine kopyalama genellikle bu adların her ikisini de sizin için otomatik olarak ayarlar), o zaman işlediğiniz katkıları sunucuya geri göndermek için şunu çalıştırabilirsiniz: [source,console] ---- $ git push origin master ---- -Bu komut yalnızca yazma erişiminizin olduğu bir sunucudan klonlama yapmışsanız ve bu arada hiç kimse başka bir "push" yapmamışsa çalışır. -Siz ve başkaları projeyi aynı anda klonlarsanız ve diğerleri sizden önce geliştirilmiş kodlarını uzak sunucuya gönderirse, doğal olarak sizin gönderiminiz (push) reddedilecektir. -Değiştirilmiş kodunuzu göndermenize (push) izin verilmeden önce, diğerleri tarafından güncellenmiş kodları uzak repodan getirmeniz (pull) ve kendi işinize dahil etmeniz gerekecek. +Bu komut yalnızca yazma erişiminizin olduğu bir sunucudan kopyalama yapmışsanız ve bu arada hiç kimse başka bir itme yapmamışsa çalışır. +Siz ve başkaları projeyi aynı anda kopyalarsanız ve diğerleri sizden da önce değiştirilmiş kodlarını uzak sunucuya gönderirse, doğal olarak sizin itmeniz reddedilecektir. +Değiştirilmiş kodunuzu itmenize izin verilmeden önce, diğerleri tarafından güncellenmiş kodları uzak repodan getirmeniz ve kendi işinize dahil etmeniz gerekecek. Güncel çalışmanızı uzak sunuculara nasıl gönderebileceğiniz hakkında daha ayrıntılı bilgi için <> konusuna bakın. [[_inspecting_remote]] ==== Uzak Sunucunun İncelenmesi -Belirli bir uzak sunucu hakkında daha fazla bilgi görmek istiyorsanız git remote show ` komutunu kullanabilirsiniz.(((git commands, remote))) +Belirli bir uzak sunucu hakkında daha fazla bilgi görmek istiyorsanız `git remote show ` komutunu kullanabilirsiniz.(((git commands, remote))) Bu komutu `origin` gibi belirli bir kısa adla çalıştırırsanız şöyle bir sonuç elde edersiniz: [source,console] @@ -167,8 +174,8 @@ $ git remote show origin ---- Bu komut uzak repo URL'si yanında izlenen dal bilgilerini de listeler. -Bununla birlikte size, eğer ana daldaysanız (main veya master) ve `git pull` çalıştırırsanız, tüm uzak referansları getirdikten sonra otomatik olarak uzak repodaki ana dalla birleşeceğini (merge) söyler. -Ayrıca indirdiği (pull) tüm uzak referansları da listeler. +Bununla birlikte size, eğer ana daldaysanız (main veya master) ve `git pull` çalıştırırsanız, tüm uzak referansları getirdikten sonra otomatik olarak uzak repodaki ana dalla birleşeceğini söyler. +Ayrıca çekme yaptığı tüm uzak referansları da listeler. Bu karşılaşacağınız basit bir örnektir. Ancak Git'i daha yoğun kullandığınızda, `git remote show` komutuyla çok daha fazla bilgi görebilirsiniz: @@ -197,8 +204,8 @@ $ git remote show origin master pushes to master (up to date) ---- -Bu komut, belirli bir daldaken `git Push` komutunu çalıştırdığınızda otomatik olarak hangi dalın uzak repoya aktarılacağını gösterir. -Ayrıca, sunucudaki hangi uzak dallara henüz sahip olmadığınızı; yerelde sahip olduğunuz hangi dalların uzak sunucudan kaldırılmış olduğunu ve `git pull` çalıştırdığınızda otomatik olarak uzak-izleme dallarıyla birleşecek (merge) çoklu yerel dallarınızı da gösterir. +Bu komut belirli bir daldaken `git Push` komutunu çalıştırdığınızda, otomatik olarak hangi dalın uzak repoya aktarılacağını gösterir. +Ayrıca; sunucudaki hangi uzak dallara henüz sahip olmadığınızı, yerelde sahip olduğunuz hangi dalların uzak sunucudan kaldırılmış olduğunu ve `git pull` çalıştırdığınızda otomatik olarak uzak-izleme dallarıyla birleşecek çoklu yerel dallarınızı da gösterir. ==== Uzak Sunucuları Yeniden Adlandırma ve Kaldırma @@ -214,9 +221,9 @@ paul ---- Bunun tüm uzaktan izleme dal adlarınızı değiştirdiğini belirtmekte fayda var. -Önceden `pb/master` olarak adlandırılan (referance) uzak sunucunun yeni adı artık `paul/master`dır. +Önceden `pb/master` olarak adlandırılan (referans) uzak sunucunun yeni adı artık `paul/master`dır. -Herhangi bir nedenden dolayı uzak sunucuyu kaldırmak isterseniz (ör: sunucuyu taşımışsanız veya artık belirli bir aynayı -mirror: bir repodaki tüm verileri ve geçmişi eksiksiz olarak başka bir drepoya kopyalayan bir repo- kullanmıyorsanız veya geliştiricilerden biri artık projeye katkıda bulunmuyorsa) `git remote remove` veya `git remote rm` komutlarından birini kullanabilirsiniz: +Herhangi bir nedenden dolayı uzak sunucuyu kaldırmak isterseniz (ör: sunucuyu taşımışsanız veya artık belirli bir aynayı -mirror: bir repodaki tüm verileri ve geçmişi eksiksiz olarak başka bir repoya kopyalayan bir repo- kullanmıyorsanız veya geliştiricilerden biri artık projeye katkıda bulunmuyorsa) `git remote remove` veya `git remote rm` komutlarından birini kullanabilirsiniz: [source,console] ---- From 0b8fa2b19531546dcbbdcdb355535a23b13bdbe9 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 08:18:53 +0100 Subject: [PATCH 035/210] Update tagging.asc terminology fixes --- book/02-git-basics/sections/tagging.asc | 61 ++++++++++++++----------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index bf596467..9228fa95 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -8,7 +8,7 @@ Bu bölümde mevcut etiketlerin nasıl listeleneceğini, etiketlerin nasıl olu ==== Etiketlerinizi Listeleme (listing) -Git'te mevcut etiketleri listelemek oldukça basittir. +Git'te mevcut etiketleri listelemek çok basittir. Sadece `git tag` (isterseniz `-l` veya `--list` seçenekleriyle) yazmanız yeterlidir:(((git commands, tag))) [source,console] @@ -20,7 +20,7 @@ v2.0 Bu komut, etiketleri alfabetik sıraya göre listeler ama görüntülenme sırasının aslında bir önemi yoktur. -Ayrıca belli kalıplarla eşleşen etiketleri de arayabilirsiniz. +Ayrıca belli kalıplarla (pattern) eşleşen etiketleri de arayabilirsiniz. Örneğin Git kaynak reposu 500'den fazla etiket içerir. Eğer sadece 1.8.5 serisine bakmak istiyorsanız şunu çalıştırabilirsiniz: @@ -42,7 +42,9 @@ v1.8.5.5 [NOT] .Joker (wildcard) etiket karakterlerini listelemek `-l` veya `--list` gerektirir ==== -Eğer tüm etiketlerin toplu bir listesini istiyorsanız `git tag` komutunu çalıştırabilirsiniz. Git bu durumda sizin bir liste istediğinizi varsayar ve size bu listeyi verir. Böyle bir durumda `-l` veya `--list` kullanımı isteğe bağlıdır. +Eğer tüm etiketlerin toplu bir listesini istiyorsanız `git tag` komutunu çalıştırabilirsiniz. +Git bu durumda sizin bir liste istediğinizi varsayar ve size bu listeyi verir. +Böyle bir durumda `-l` veya `--list` kullanımı isteğe bağlıdır. Ancak etiket adlarıyla eşleştirmek üzere bir karakter deseni (joker) yazacaksanız, `-l` veya `--list` kullanımı zorunludur. ==== @@ -51,11 +53,12 @@ Ancak etiket adlarıyla eşleştirmek üzere bir karakter deseni (joker) yazacak Git iki çeşit etiketi destekler: _lightweight_ (hafif) ve _annotated_ (açıklamalı). -Hafif bir etiket, değişmeyen bir Git dalı gibidir; yalnızca belirli bir "commit"in işaretçisidir. +Hafif bir etiket, değişmeyen bir Git dalı gibidir; yalnızca belirli bir katkının işaretçisidir. Ancak açıklamalı etiketler Git veritabanında tam nesneler olarak depolanır. -Bunlar sağlamalı (checksummed) verilerdir. Etiketleyicinin adını, e-postasını ve etiketleme tarihini içerir; etiketleme mesajınız yer alır ve GNU Privacy Guard (GPG) ile imzalanıp, doğrulanabilir. -Tüm bu bilgilere sahip olabilmeniz için genellikle açıklamalı etiketler oluşturmanız önerilir; ancak geçici bir etiket istiyorsanız veya herhangi bir nedenle diğer bilgileri saklamak istemiyorsanız, hafif etiketler de mevcuttur. +Bunlar sağlamalı (checksummed) verilerdir. +Etiketleyicinin adını, e-postasını ve etiketleme tarihini içerir, etiketleme mesajınız yer alır ve GNU Privacy Guard (GPG) ile imzalanıp, doğrulanabilir. +Tüm bu bilgilere sahip olabilmeniz için genellikle açıklamalı etiketler oluşturmanız önerilir, ancak geçici bir etiket istiyorsanız veya herhangi bir nedenle diğer bilgileri saklamak istemiyorsanız, hafif etiketler de mevcuttur. [[_annotated_tags]] ==== Açıklamalı Etiketler (annotated tags) @@ -76,7 +79,7 @@ v1.4 `-m` bayrağı etiketle birlikte saklanan bir etiketleme mesajı belirtir. Eğer bu etiket için bir mesaj belirtmezseniz Git, mesajı yazabilmeniz için otomatik olarak düzenleyicinizi başlatır. -Etiket verilerini `git show` komutunu kullanarak etiketlediğiniz "commit"le birlikte görebilirsiniz: +Etiket verilerini `git show` komutunu kullanarak etiketlediğiniz katkıyla birlikte görebilirsiniz: [source,console] ---- @@ -94,13 +97,13 @@ Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number ---- -Bu "commit" bilgisini göstermeden önce etiketleme bilgisini, etiketleme tarihini ve açıklama mesajını gösterir. +Bu katkı bilgisini göstermeden önce etiketleme bilgisini, etiketleme tarihini ve açıklama mesajını gösterir. ==== Hafif Etiketler (lightweight tags) (((tags, lightweight))) -"commit"leri etiketlemenin başka bir yolu da hafif etiketler kullanmaktır. -Bu metodda "commit" sağlaması dışında hiçbir veri saklanmaz. +Katkıları etiketlemenin başka bir yolu da hafif etiketler kullanmaktır. +Bu metodda "katkı sağlaması" dışında hiçbir veri saklanmaz. Hafif etiket oluşturmak için `-a`, `-s` veya `-m` seçeneklerinden hiçbirini kullanmaksızın sadece bir etiket adı yazarsınız: [source,console] @@ -115,7 +118,7 @@ v1.5 ---- Bu sefer etiket üzerinde `git show` komutunu çalıştırırsanız ekstra etiket bilgilerini göremezsiniz.(((git commands, show))) -Komut sadece "commit"i gösterir: +Komut sadece katkıyı gösterir: [source,console] ---- @@ -129,8 +132,8 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Sonradan Etiketleme -"commit"leri geçtikten sonra da etiketleyebilirsiniz. -"commit" geçmişinizin şöyle göründüğünü varsayalım: +Katkıları işledikten sonra da etiketleyebilirsiniz. +Katkı geçmişinizin şöyle göründüğünü varsayalım: [source,console] ---- @@ -147,16 +150,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- -Şimdi, projeyi ``updated rakefile`` "commit"inde bulunurken "v1.2"ye etiketlemeyi unuttuğunuzu varsayalım. +Şimdi, projeyi ``updated rakefile`` katkısını işlerken "v1.2" şeklinde etiketlemeyi unuttuğunuzu varsayalım. Bunu sonradan da ekleyebilirsiniz. -Bu "commit"i etiketlemek için, komutun sonunda "commit" sağlamasının (checksum) tamamını veya bir kısmını belirtirsiniz: +Bu katkıyı etiketlemek için, komutun sonunda katkı sağlamasının (checksum) tamamını veya bir kısmını belirtirsiniz: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -"commit"i etiketlediğinizi görebilirsiniz:(((git commands, tag))) +Artık katkıyı etiketlediğinizi görebilirsiniz:(((git commands, tag))) [source,console] ---- @@ -186,7 +189,7 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ==== Etiketleri Paylaşma Varsayılan olarak `git push` komutu, etiketleri uzak sunuculara aktarmaz.(((git commands, push))) -Etiketleri oluşturduktan sonra açıkça paylaşıma açık bir sunucuya (shared server) göndermeniz gerekecektir. +Etiketleri oluşturduktan sonra paylaşıma açık bir sunucuya (shared server) göndermeniz gerekecektir. Bu süreç tıpkı uzak dalları paylaşmaya benzer: `git push origin ` komutunu çalıştırabilirsiniz (tagname: etiket adı). [source,console] @@ -215,15 +218,16 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Artık başka biri reponuzu klonladığında veya reponuzdan bilgi aldığında tüm etiketlerinizi de alacaktır. +Artık başka biri reponuzu kopyaladığında veya reponuzdan bilgi aldığında tüm etiketlerinizi de alacaktır. [NOT] -.`git push` her iki türde etiketi de gönderir +.`git push` her iki türde etiketi de iter ==== -Etiketleri `git push --tags` kullanarak göndermek, hafif ve açıklamalı etiketler arasında bir ayrım yapmaz. Gönderme (push) işlemi için tür seçmenize olanak tanıyan basit bir seçenek veya bayrak yoktur. +Etiketleri `git push --tags` kullanarak itmek, hafif ve açıklamalı etiketler arasında bir ayrım yapmaz. +İtme işlemi için, tür seçmenize olanak tanıyan basit bir seçenek veya bayrak yoktur. ==== -==== Etiketleri Silme (delete) +==== Etiketleri Silme Yerel reponuzdaki bir etiketi silmek için `git tag -d ` komutunu kullanabilirsiniz (tagname: etiket adı). Örneğin yukarıdaki hafif etiketimizi şu şekilde kaldırabiliriz: @@ -247,7 +251,8 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -Aslında yaptığımız şey: uzak sunucudaki (remote) etiket adının (tagname) üstüne boş (null) bir değer yazmaktır (":" dan önceki boşluğa dikkat edin). Böylece eski etiket silinecektir. +Aslında yaptığımız şey: uzak sunucudaki etiket adının (tagname) üstüne boş (null) bir değer yazmaktır (":" dan önceki boşluğa dikkat edin). +Böylece eski etiket silinecektir. Uzak etiketi silmenin ikinci (ve daha sezgisel) yolu ise `--delete ` kullanmaktır (tagname: etiket adı): @@ -256,9 +261,10 @@ Uzak etiketi silmenin ikinci (ve daha sezgisel) yolu ise `--delete ` ku $ git push origin --delete ---- -==== Etiketleri kontrol etme +==== Etiketleri Denetlemek -Bir etiketin işaret ettiği sürümleri görüntülemek istiyorsanız, bu etiketi `git checkout` komutuyla kontrol edebilirsiniz. Ancak bunu yapmak reponuzu ``detached HEAD`` (ayrık uç) durumuna sokar ve bu da bazı olumsuz yan etkilere neden olur: +Bir etiketin işaret ettiği sürümleri görüntülemek istiyorsanız, bu etiketi `git checkout` komutuyla kontrol edebilirsiniz. +Ancak bunu yapmak reponuzu ``detached HEAD`` (ayrık uç) durumuna sokar ve bu da bazı olumsuz yan etkilere neden olur: [source,console] ---- @@ -281,8 +287,8 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append HEAD is now at df3f601... add atlas.json and cover image ---- -Normalde her bir dalda bir uç (HEAD) bulunur ve bu uç en son "commit"e sabitlenmiştir. -``detached HEAD`` durumundayken bu uç en son "commit" yerine etikete sabitlendiğinden bir "commit" oluştursanız bile "commit"iniz hiçbir dala ait olmayacağı için kesin "commit" karması (hash) dışında erişilemez olacaktır. +Normalde her bir dalda bir uç (HEAD) bulunur ve bu uç en son katkıya iliştirilmiştir. +``detached HEAD`` durumundayken bu uç en son katkı yerine etikete sabitlendiğinden, yeni bir katkı işleseniz bile katkıniz hiçbir dala ait olmayacağı için "kesin katkı karması" (hash) dışında erişilemez olacaktır. Bu nedenle, değişiklik yapmanız gerekiyorsa (mesela eski bir sürümdeki bir hatayı düzelttiniz) yeni bir dal oluşturmanız gerekecektir: [source,console] @@ -291,4 +297,5 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Bunu yapıp bir "commit"te bulunursanız, "version2" dalınız, yeni değişikliklerinizle ilerleyeceği için "v2.0.0" etiketinizden biraz farklı olacaktır, bu yüzden dikkatli olun. +Bunu yapıp bir katkı işlerseniz, "version2" dalınız, yeni değişikliklerinizle ilerleyeceği için "v2.0.0" etiketinizden biraz farklı olacaktır. +Bu yüzden dikkatli olun. From f268a2da67ea918a8872d27866c22c46d0a63316 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 08:33:08 +0100 Subject: [PATCH 036/210] Update undoing.asc terminology fixes --- book/02-git-basics/sections/undoing.asc | 60 +++++++++++++------------ 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 088c1306..02297d14 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -3,24 +3,24 @@ Herhangi bir aşamada bir şeyi geri almak isteyebilirsiniz. Burada, yaptığınız değişiklikleri geri almak için kullanabileceğiniz birkaç temel aracı inceleyeceğiz. -Dikkatli olun çünkü bu geri alma işlemlerinin bazılarını her zaman iptal ederek geri alma öncesi duruma geri dönemeyebilirsiniz. -Bu, Git'te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç alandan biridir. +Bu geri alma işlemlerinin bazılarını her zaman iptal ederek eski (geri alma öncesi) duruma geri dönemeyebileceğiniz için, dikkatli olmalısınız. +Bu, Git'te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç durumdan biridir. -Yaygın geri alma ihtiyaçlarından biri, bazı dosyaları eklemeyi unuttup "commit"inizi çok erken yaptığınızda veya yanlış bir "commit" mesajı yazdığınızda ortaya çıkar. -Bir "commit"i yeniden yapmak istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları "stage"e alın ve `--amend` seçeneğini kullanarak yeniden "commit" yapın: +Yaygın geri alma ihtiyaçlarından biri, bazı dosyaları eklemeyi unuttup katkınızı çok erken işlediğinizde veya yanlış bir katkı mesajı yazdığınızda ortaya çıkar. +Bir katkıyı yeniden işlemek istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları aşamaya alın ve `--amend` seçeneğini kullanarak yeniden katkılayın: [source,console] ---- $ git commit --amend ---- -Bu komut "stage" alanınızı alır ve "commit"iniz için kullanır. -Son "commit"inizden beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son "commit"inizden hemen sonra çalıştırdıysanız), anlık görüntünüz tamamen aynı olacak ve değiştireceğiniz tek şey "commit" mesajınız olacaktır. +Bu komut aşama alanınızı alır ve katkılamak için kullanır. +Son katkınızdan beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son katkınızdan hemen sonra çalıştırdıysanız), pozunuz (snapshot) tamamen aynı olacak ve değiştireceğiniz tek şey katkı mesajınız olacaktır. -Bunu yaptığınızda aynı "commit mesajı düzenleyicisi" aynı "commit" mesajıyla devreye girer. -Mesajı her zamanki gibi düzenleyebilirsiniz ancak bu, önceki "commit" mesajınızın üzerine yazılır. +Bunu yaptığınızda aynı "katkı mesajı düzenleyicisi" aynı katı mesajıyla devreye girer. +Mesajı her zamanki gibi düzenleyebilirsiniz, ancak bu sefer önceki katkı mesajınızın üzerine yazılır. -Örnek olarak, "commit" yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri "stage"e almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz: +Örnek olarak, katkı yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri aşamaya almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz: [source,console] ---- @@ -29,25 +29,25 @@ $ git add forgotten_file $ git commit --amend ---- -Bu işlemin sonucunda, ikinci "commit"in ilk "commit"in yerini aldığı tek bir "commit" elde edersiniz. +Bu işlemin sonucunda, ikinci katkınızın ilk katkınızın yerini aldığı tek bir katkı elde edersiniz. [NOT] ==== -Şunu anlamanız özellikle önemli: Eğer son "commit"inizi "amend" ederseniz, son "commit"inizi düzeltmekten ziyade, eski "commit" ortadan kaldırıp ve yerine yeni bir "commit" koymaktasınız. -Sanki önceki "commit" hiç gerçekleşmemiş ve repo geçmişinizde görünmeyecekmiş gibi. +Şunu anlamanız özellikle önemli: Eğer son katkınızı onarırsanız (amend), son katkınızı düzeltmekten ziyade, aslında eski katkınızı ortadan kaldırıp ve yerine yeni bir katkı işlemektesiniz. +Sanki önceki katkı hiç gerçekleşmemiş ve repo geçmişinizde görünmeyecekmiş gibi. -Önceki "commit"leri değiştirmenin asıl değeri, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemedeki bir yazım hatasını düzelttim`` şeklinde gereksiz "commit" mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır. +Önceki katkıları değiştirmenin asıl değeri, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemdeki bir yazım hatasını düzelttim`` şeklinde gereksiz katkı mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır. ==== [[_unstaging]] -==== "stage"e Alınmış Dosyayı "stage"den Çıkarmak (Unstaging) +==== Aşamaya Alınmış Dosyayı Aşamadan Çıkarmak (Unstaging) -Sonraki iki bölümde "stage" alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. +Sonraki iki bölümde aşama alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. İşin güzel yanı, bu iki alanın durumunu tanımlamak için kullandığımız komut aynı zamanda bu alanlarda yapılan değişiklikleri nasıl geri alacağımızı da bize söyler. -Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla `git add *` yazıp ikisini birden "stage"e aldığınızı varsayalım. -İkisinden birini nasıl "stage"den çıkarabilirsiniz? -`git status` komutu size bunu nasıl yapacağınızı zaten hatırlatır: +Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla `git add *` yazıp ikisini birden aşamalandırdığınızı varsayalım. +İkisinden birini nasıl aşamadan çıkarabilirsiniz? +`git status` komutu size bunu nasıl yapacağınızı zaten hatırlatmaktadır: [source,console] ---- @@ -62,7 +62,7 @@ Changes to be committed: ---- ``Changes to be committed`` metninin hemen altında, düzenlemeyi kaldırmak için `git reset HEAD ...` kullanın yazıyor. -O halde, `CONTRIBUTING.md` dosyasını "stage"den çıkarmak için bu tavsiyeyi kullanalım: +O halde, `CONTRIBUTING.md` dosyasını aşamadan çıkarmak için bu yönergeyi kullanalım: [source,console] ---- @@ -92,13 +92,13 @@ Komut biraz garip ama neticede işe yarıyor. Ancak yukarıda açıklanan senaryoda çalışma dizininizdeki dosyaya dokunulmaz, dolayısıyla nispeten güvenlidir. ===== -Şimdilik bu sihirli çağrı, `git reset` komutu hakkında bilmeniz gereken tek şey. -<> ünitesinde `reset`in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz. +Şimdilik bu sihirli çağrı, `git reset` komutu hakkında bilmeniz gereken tek şeydir. +<> bölümünde `reset`in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz. ==== Değiştirilmiş Dosyadaki Değişikliği Geri Alma (Unmodifying) `CONTRIBUTING.md` dosyasındaki değişikliklerinizi saklamak istemediğinizi fark ederseniz ne yaparsınız? -Yaptığınız değişiklikleri kolayca nasıl kaldırabilirsiniz veya en son "commit"inizdeki (veya başlangıçta klonladığınız ya da çalışma dizininize soktuğunuz) haline nasıl geri döndürebilirsiniz? +Yaptığınız değişiklikleri kolayca nasıl kaldırabilirsiniz veya en son katkınızdaki (veya başlangıçta kopyaladığınız ya da çalışma dizininize soktuğunuz) haline nasıl geri döndürebilirsiniz? Neyse ki, `git status` size bunu nasıl yapacağınızı da söyler. Son örnek çıktıda, "unstaged" alan şuna benzer: @@ -111,7 +111,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Yaptığınız değişiklikleri nasıl iptal edeceğinizi oldukça açık bir şekilde anlatmaktadır. +Yaptığınız değişiklikleri nasıl iptal edeceğiniz oldukça açık bir şekilde anlatmaktadır. Hadi söyleneni yapalım: [source,console] @@ -130,13 +130,15 @@ Değişikliklerin geri alındığını görebilirsiniz. [ÖNEMLİ] ===== -`git checkout -- ` komutunun tehlikeli bir komut olduğunu anlamanız çok önemli. -Bu dosyada yaptığınız tüm yerel değişiklikler kayboldu! Git, bu dosyayı en son kaydedilen sürümle değiştirdi. +`git checkout -- ` komutunun tehlikeli bir komut olduğunu anlamanız çok önemlidir. +Bu dosyada yaptığınız tüm yerel değişiklikler kayboldu! +Git, bu dosyayı en son kaydedilen sürümle değiştirdi. Kaydedilmemiş yerel değişiklikleri istemediğinizden kesinlikle emin olmadığınız sürece bu komutu asla kullanmayın! ===== -Bu dosyada yaptığınız değişiklikleri korumak istiyorsanız ancak şimdilik yine de ondan kurtulmanız gerekiyorsa, <> ünitesinde saklama ve dallandırma işlemlerini ele alacağız. Onların genellikle daha kullanışlı yollar olduğunu göreceksiniz. +Bu dosyada yaptığınız değişiklikleri korumak istiyorsanız ancak şimdilik yine de ondan kurtulmanız gerekiyorsa, <> bölümünde saklama ve dallandırma işlemlerini ele alacağız. +Bu işi yapmanın genellikle daha kullanışlı yolları olduğunu göreceksiniz. -Git'te _committed_ olan her şeyin neredeyse her zaman kurtarılabileceğini unutmayın. -Hatta silinen dallardaki "commit"ler veya `--amend` komutuyla üzerini yeniden yazılan "commit"ler bile kurtarılabilir. (veri kurtarma için bkz. >). -Ancak, hiç "commit" etmediğiniz bir şeyi tamamen kaybetmeniz oldukça muhtemeldir. +Git'te _committed_ durumda olan her şeyin neredeyse her zaman kurtarılabileceğini unutmayın. +Hatta silinen dallardaki katkılar veya `--amend` komutuyla üzerini yeniden yazılan katkılar bile kurtarılabilir. (veri kurtarma için bkz. >). +Ancak, hiç katkı olarak işlemediğiniz bir şeyi tamamen kaybetmeniz de oldukça muhtemeldir. From 4cbd03087b1fe7ff8b72bb005d3ae737004133c3 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 08:53:03 +0100 Subject: [PATCH 037/210] Update viewing-history.asc terminology fixes --- .../sections/viewing-history.asc | 99 ++++++++++--------- 1 file changed, 51 insertions(+), 48 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 908a15ad..9d9cb23e 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,7 +1,7 @@ [[_viewing_history]] -=== Commit Geçmişini Görüntüleme +=== Katkı Geçmişini Görüntüleme -Birkaç "commit" oluşturduktan veya halihazırda "commit" geçmişine sahip bir repoyu klonladıktan sonra muhtemelen neler olup bittiğini görmek için kod geçmişine bakmak isteyeceksiniz. +Birkaç katkı işledikten veya halihazırda katkı geçmişine sahip bir repoyu kopyaladıktan sonra muhtemelen neler olup bittiğini görmek için kod geçmişine bakmak isteyeceksiniz. Bunu yapmanın en temel ve güçlü aracı `git log` komutudur. Bu örneklerde ``simplegit`` adı verilen çok basit bir proje kullanılmaktadır. @@ -36,14 +36,15 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -Hiçbir argüman almadan kullanılan `git log` komutu, varsayılan olarak bu repoda yapılan "commit"leri ters kronolojik sırayla listeler. Yani en son "commit" en üstte görünür. -Gördüğünüz gibi, bu komut her bir işlemi SHA-1 kimliği, geliştiricinin adı ve e-postası, "commit" tarihi ve mesajıyla birlikte listeler. +Hiçbir argüman almadan kullanılan `git log` komutu, varsayılan olarak bu repoda yapılan katkıları ters kronolojik sırayla listeler (Yani en son katkı en üstte görünür). +Gördüğünüz gibi, bu komut her bir işlemi SHA-1 kimliği, geliştiricinin adı ve e-postası, katkı tarihi ve mesajıyla birlikte listeler. -Tam olarak aradığınızı size göstermek için `git log` komutuna ilişkin çok sayıda ve çeşitli seçenekler mevcuttur. +Tam olarak aradığınızı bulabilmeniz için `git log` komutuna ilişkin çok sayıda ve çeşitli seçenekler mevcuttur. Burada size en popüler olanlardan bazılarını göstereceğiz. -Kullanışlı seçeneklerden biri, her bir "commit"te ortaya çıkan farkı (the _patch_ output) gösteren `-p` veya `--patch`tir. -Ayrıca yalnızca en son 5 "commit"i görmek için '-5' kullanmak gibi. Görüntülenecek günlük "commit" sayısını da sınırlayabilirsiniz. +Kullanışlı seçeneklerden biri, her bir katkıda ortaya çıkan farkı (the _patch_ output) gösteren `-p` veya `--patch`tir. +Ayrıca yalnızca en son 5 katkıyı görmek için '-5' kullanmak gibi. +Görüntülenecek günlük katkı sayısını da sınırlayabilirsiniz. [source,console] ---- @@ -89,10 +90,10 @@ index a0a60ae..47c6340 100644 -end ---- -Bu seçenek aynı bilgileri ancak her bir "commit"le yapılan değişikliklerle birlikte görüntüler. -Bu yöntem, kod incelemesi veya bir ortak çalışanın eklediği bir dizi "commit" sırasında neler olduğuna hızlı bir şekilde göz atmak için oldukça faydalıdır. +Bu seçenek aynı bilgileri ancak her bir katkıyla yapılan değişikliklerle birlikte görüntüler. +Bu yöntem, kod incelemesi veya bir ortak çalışanın eklediği bir dizi katkı sırasında neler olduğuna hızlı bir şekilde göz atmak için oldukça faydalıdır. Ayrıca `git log` ile bir dizi özetleme seçeneğini de kullanabilirsiniz. -Örneğin, her bir "commit" işlemine ilişkin bazı kısaltılmış istatistikleri görmek istiyorsanız `--stat` seçeneğini kullanabilirsiniz: +Örneğin, her bir katkı işlemine ilişkin bazı kısaltılmış istatistikleri görmek istiyorsanız `--stat` seçeneğini kullanabilirsiniz: [source,console] ---- @@ -127,13 +128,13 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -Gördüğünüz gibi, `--stat` seçeneği her bir "commit" girişinin altında değiştirilen dosyaların listesini, kaç dosyanın değiştirildiğini ve bu dosyalara kaç satırın eklendiğini ve kaldırıldığını yazdırır. +Gördüğünüz gibi, `--stat` seçeneği her bir katkı girişinin altında değiştirilen dosyaların listesini, kaç dosyanın değiştirildiğini ve bu dosyalara kaç satırın eklendiğini ve kaldırıldığını yazdırır. Ayrıca en sona bilgilerin bir özetini de koyar. Bir diğer kullanışlı seçenek ise `--pretty`dir. Bu seçenek, günlük çıktısını varsayılanın dışındaki formatlara çevirir. Kullanmanız için önceden oluşturulmuş birkaç seçenek mevcuttur. -`oneline` seçeneği her bir "commit"i tek bir satıra yazdırır: Eğer çok sayıda "commit"e bakıyorsanız bu özellikle kullanışlıdır. +`oneline` seçeneği her bir katkıyı tek bir satıra yazdırır (eğer çok sayıda katkıya bakıyorsanız özellikle kullanışlıdır). Ek olarak, `short` (kısa), `full` (tam), ve `fuller` (geniş) seçenekleri çıktıyı aşağı yukarı aynı şekilde ancak daha az veya daha fazla bilgiyle gösterir. Sırasıyla: @@ -146,7 +147,8 @@ a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- En ilginç seçenek, kendi günlük çıktı formatınızı belirlemenize olanak tanıyan `format`tır. -Bu, özellikle makine ayrıştırması için çıktı oluşturduğunuzda kullanışlıdır. Biçimi açıkça belirttiğiniz için Git'teki güncellemelerle değişmeyeceğini bilirsiniz.(((log formatting))) +Bu, özellikle makine ayrıştırması için çıktı oluşturduğunuzda kullanışlıdır. +Biçimi açıkça belirttiğiniz için Git'teki güncellemelerle değişmeyeceğini bilirsiniz.(((log formatting))) [source,console] ---- @@ -163,8 +165,8 @@ a11bef0 - Scott Chacon, 6 years ago : first commit [cols="1,4",options="header"] |================================ | Seçenek | Çıktı Tanımı -| `%H` | Commit hash kimliği -| `%h` | Commit hash kimliği (kısa) +| `%H` | katkı hash kimliği +| `%h` | katkı hash kimliği (kısa) | `%T` | Çalışma ağacı hash kimliği | `%t` | Çalışma ağacı hash kimliği (kısa) | `%P` | Ana hashler @@ -181,11 +183,11 @@ a11bef0 - Scott Chacon, 6 years ago : first commit |================================ _yazar_ ve _geliştirici_ arasındaki farkın ne olduğunu merak ediyor olabilirsiniz. -Yazar, kodu ilk yazan kişi, geliştirici ise kodu son değiştiren yani "commit" eden kişidir. -Yani, bir projeye bir yama gönderirseniz ve çekirdek üyelerden biri yamayı uygularsa, her ikiniz de kredi alırsınız (yazar olarak siz ve "commit" eden olarak çekirdek üye). +Yazar, kodu ilk yazan kişi, geliştirici ise kodu son değiştiren yani katkılayan kişidir. +Yani, bir projeye bir yama gönderirseniz ve çekirdek üyelerden biri yamayı uygularsa, her ikiniz de kredi alırsınız (yazar olarak siz ve katkılayan olarak çekirdek üye). Bu ayrımı <> bölümünde biraz daha ele alacağız. -`oneline` ve `format` seçenekleri `--graph` adı verilen başka bir `log` seçeneğiyle birlikte kullanıldığında özellikle kullanışlıdır. +Bu, `oneline` ve `format` seçenekleri `--graph` adı verilen başka bir `log` seçeneğiyle birlikte kullanıldığında özellikle kullanışlıdır. Bu seçenek çıktıya, dallanma ve birleştirme geçmişinizi gösteren küçük bir ASCII grafiği ekler: [source,console] @@ -213,48 +215,49 @@ Bunlar `git log` için yalnızca bazı basit çıktı biçimlendirme seçenekler [cols="1,4",options="header"] |================================ | Seçenek | Tanım -| `-p` | Her bir "commit"te tanıtılan yamayı göster -| `--stat` | Her "commit"te değiştirilen dosyalara ilişkin istatistikleri göster +| `-p` | Her bir katkıda tanıtılan yamayı göster +| `--stat` | Her katkıda değiştirilen dosyalara ilişkin istatistikleri göster | `--shortstat` | --stat komutundan yalnızca değiştirilen/eklenenler/silenler satırını göster -| `--name-only` | "commit" bilgisinden sonra değiştirilen dosyaların listesini göster +| `--name-only` | katkı bilgisinden sonra değiştirilen dosyaların listesini göster | `--name-status` | Eklenen/değiştirilen/silinmiş bilgilerle birlikte değiştirilen dosyaların listesini de göster | `--abbrev-commit` | SHA-1 kimliğinin tüm 40 karakteri yerine sadece ilk bir kaç karakterini göster | `--relative-date` | Tarihi, tam tarih biçimini kullanmak yerine göreli bir biçimde göster (ör. ``2 hafta önce``) | `--graph` | Günlük çıktısının yanında dal ve birleştirme geçmişinin ASCII grafiğini de göster -| `--pretty` | "commit"leri alternatif bir formatta göster. Seçenekler arasında tek satırlı (oneline), kısa (short), tam (full), daha kapsamlı (fuller) ve kendi oluşturduğunuz format da yer alır. +| `--pretty` | Katkıları alternatif bir formatta göster. Seçenekler arasında tek satırlı (oneline), kısa (short), tam (full), daha kapsamlı (fuller) ve kendi oluşturduğunuz format da yer alır. | `--oneline` | `--pretty=oneline --abbrev-commit` birlikte kullanımı için kısayoldur |================================ ==== Günlük (Log) Çıktısını Sınırlama -`git log` çıktı biçimlendirme seçeneklerine ek olarak, bir dizi yararlı sınırlama seçeneğini de beraberinde getirir. Bu "commit"lerin yalnızca belli bir alt kümesini göstermenize izin veren seçeneklerdir. +`git log` çıktı biçimlendirme seçeneklerine ek olarak, bir dizi yararlı sınırlama seçeneğini de beraberinde getirir. +Bu katkıların yalnızca belli bir alt kümesini göstermenize izin veren seçeneklerdir. Böyle bir seçeneği zaten gördünüz: yalnızca son iki işlemi görüntüleyen '-2' seçeneği. -Aslında, `-` işlemini yapabilirsiniz. Buradaki `-n`, en son yapılan `n` sayıdaki "commit"i gösteren herhangi bir tam sayıdır. -Gerçekte, bunu sık kullanmanız pek mümkün değildir; çünkü Git varsayılan olarak tüm çıktıları bir "pager" (sayfa düzenleyici) üzerinden yönlendirir, böylece bir kerede yalnızca bir sayfalık günlük çıktısı görürsünüz. +Aslında, `-` işlemini yapabilirsiniz, buradaki `-n`, en son yapılan `n` sayıdaki katkıyı gösteren herhangi bir tam sayıdır. +Gerçekte, bunu sık kullanmanız pek mümkün değildir, çünkü Git varsayılan olarak tüm çıktıları bir "pager" (sayfa düzenleyici) üzerinden yönlendirir ve böylece bir kerede yalnızca bir sayfalık günlük çıktısı görürsünüz. Yine de, `--since` ve `--until` gibi zaman sınırlayıcı seçenekler çok kullanışlıdır. -Örneğin, aşağıdaki komut son iki hafta içinde yapılan "commit"lerin listesini yazdırır: +Örneğin, aşağıdaki komut son iki hafta içinde yapılan katkıların listesini yazdırır: [source,console] ---- $ git log --since=2.weeks ---- -Bu komut birçok formatla çalışır; "2008-01-15" gibi belirli bir tarih veya "2 yıl 1 gün 3 dakika önce" gibi göreceli bir tarih belirtebilirsiniz. +Bu komut birçok formatla çalışır: "2008-01-15" gibi belirli bir tarih veya "2 yıl 1 gün 3 dakika önce" gibi göreli bir tarih belirtebilirsiniz. -Listeyi, bazı arama kriterleriyle eşleşen "commit"lere göre de filtreleyebilirsiniz. -`--author` seçeneği belirli bir yazara göre filtreleme yapmanızı sağlar ve `--grep` seçeneği "commit" mesajlarındaki anahtar kelimeleri aramanızı sağlar. +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] ==== -Hem `--author` hem de `--grep` arama kriterlerinin birden fazla örneğini de aynı anda kullanabilirsiniz. -Bu "commit" çıktısını sadece uygun düşen `--author` ve `--grep` kalıplarıyla eşleşen "commit"lerle sınırlayacaktır. -Ancak, `--all-match` seçeneğinin eklenmesi çıktıyı _all_ `--grep` kalıplarıyla eşleşen "commit"ler yüzünden daha da sınırlandıracaktır. +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. +Ancak, `--all-match` seçeneğinin eklenmesi çıktıyı _all_ `--grep` kalıplarıyla eşleşen katkılar yüzünden daha da sınırlandıracaktır. ==== -Bir diğer gerçekten faydalı filtre ise bir dize (string: karakter dizisi) alan ve yalnızca o dizenin oluşum sayısını değiştiren "commit"leri gösteren `-S` seçeneğidir (yazılımcılar arasında Git'in "kazma" seçeneği olarak anılır). -Örneğin, belirli bir işleve referans ekleyen veya kaldıran son "commit" işlemi bulmak istiyorsanız şunu arayabilirsiniz: +Bir diğer gerçekten faydalı süzgeç ise bir dize (string) alan ve yalnızca o dizenin oluşum sayısını değiştiren katkıları gösteren `-S` seçeneğidir (yazılımcılar arasında Git'in "kazma" seçeneği olarak anılır). +Örneğin, belirli bir işleve referans ekleyen veya kaldıran son katkıyı bulmak istiyorsanız şunu arayabilirsiniz: [source,console] ---- @@ -262,26 +265,26 @@ $ git log -S function_name ---- `git log`a filtre argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). -Eğer bir dizin veya dosya adı belirtirseniz günlük çıktısını (log), bu dosyalarda değişiklik yapan "commit"lerle sınırlayabilirsiniz. +Eğer bir dizin veya dosya adı belirtirseniz günlük çıktısını, bu dosyalarda değişiklik yapan katkılarla sınırlayabilirsiniz. Bu her zaman son seçenektir ve dosya yollarını seçeneklerden (bayraklardan) ayırmak için genellikle önünde çift çizgi (`--`) bulunur. -<> bölümünde bunları ve diğer birkaç genel seçeneği referans olması açısından listeleyeceğiz. +<> bölümünde bunları ve diğer birkaç genel seçeneği örnek olması açısından listeleyeceğiz. [[limit_options]] .`git log` komutunun çıktılarını sınırlama seçeneği [cols="2,4",options="header"] |================================ | Seçenek | Tanım -| `-` | Sadece en son n sayıdaki "commit"i göster -| `--since`, `--after` | "commit" listesini belirli bir tarihten sonra yapılan "commitler"le sınırla -| `--until`, `--before` | "commit" listesini belirli bir tarihe kadar yapılan "commitler"le sınırla -| `--author` | Sadece author kısmı verilen dizeyle eşleşen "commit"leri göster -| `--committer` | Sadece committer kısmı verilen dizeyle eşleşen "commit"leri göster -| `--grep` | Sadece "commit" mesajında verilen dize bulunan "commit"leri göster -| `-S` | Sadece codunda verilen dizeyi ekleyen veya çıkaran "commit"leri göster +| `-` | Sadece en son n sayıdaki katkıyı göster +| `--since`, `--after` | Katkı listesini belirli bir tarihten sonra yapılan katkılarla sınırla +| `--until`, `--before` | Katkı listesini belirli bir tarihe kadar yapılan katkılarla sınırla +| `--author` | Sadece author kısmı, verilen dizeyle eşleşen katkıları göster +| `--committer` | Sadece committer kısmı, verilen dizeyle eşleşen katkıları göster +| `--grep` | Sadece katkı mesajında, girilen dize bulunan katkıları göster +| `-S` | Sadece kodda verilen dizeyi ekleyen veya çıkaran katkıları göster |================================ -Örneğin, Git kaynak kodu geçmişindeki test dosyalarını değiştiren hangi "commit"lerin Ekim 2008 ayında Junio Hamano tarafından işlendiğini ve birleştirme (merge) "commit"leri olmadığını görmek istiyorsanız, şöyle bir komut çalıştırabilirsiniz:(((log filtering))) +Örneğin, Git kaynak kodu geçmişindeki test dosyalarını değiştiren hangi katkıların Ekim 2008 ayında Junio Hamano tarafından işlendiğini ve birleştirme katkıları olmadığını görmek istiyorsanız, şöyle bir komut çalıştırabilirsiniz:(((log filtering))) [source,console] ---- @@ -295,11 +298,11 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Bu komutla, Git kaynak kodu geçmişindeki yaklaşık 40.000 "commit"ten bu kriterlere uyan sadece 6'sını görebilirsiniz. +Bu komutla, Git kaynak kodu geçmişindeki yaklaşık 40.000 katkıdan, bu kriterlere uyan sadece 6'sını görebilirsiniz. [İPUCU] -.Birleştirme Commit'lerinin gösterilmesini engelleme +.Birleştirme katkılarının gösterilmesini engelleme ==== -Reponuzda kullanılan iş akışına bağlı olarak, günlük (log) geçmişinizdeki "commit"lerin büyük bir yüzdesinin yalnızca birleştirme (merge) "commit"leri olması mümkündür ve bunlar genellikle pek bilgilendirici değildir. -Birleştirme işlemlerinin görüntülenmesinin günlük (log) geçmişinizi karmaşık hale getirmesini önlemek için, `--no-merges` seçeneğini eklemeniz yeterlidir. +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. +Birleştirme işlemlerinin görüntülenmesinin, günlük geçmişinizi karmaşık hale getirmesini önlemek için, `--no-merges` seçeneğini eklemeniz yeterlidir. ==== From cd44312e320c15ceb9dcaed359245de3a23e6a68 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 12:41:31 +0100 Subject: [PATCH 038/210] Update setting-up-server.asc 4.04 has been translated --- .../sections/setting-up-server.asc | 63 ++++++++++--------- 1 file changed, 32 insertions(+), 31 deletions(-) diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 17fd9dbd..6aa4e2da 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -1,16 +1,16 @@ [[_setting_up_server]] -=== Setting Up the Server +=== Sunucu Kurma -Let's walk through setting up SSH access on the server side. -In this example, you'll use the `authorized_keys` method for authenticating your users. -We also assume you're running a standard Linux distribution like Ubuntu. +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. -[NOTE] +[NOT] ==== -A good deal of what is described here can be automated by using the `ssh-copy-id` command, rather than manually copying and installing public keys. +Burada açıklanan birçok işlem, ortak anahtarları manuel olarak kopyalamak ve yüklemek yerine `ssh-copy-id` komutunu kullanarak otomatikleştirilebilir. ==== -First, you create a `git` user account and a `.ssh` directory for that user. +İlk olarak, bir `git` kullanıcı hesabı oluşturmalısınız ve bu kullanıcı için bir `.ssh` dizini oluşturmalısınız. [source,console] ---- @@ -21,9 +21,9 @@ $ mkdir .ssh && chmod 700 .ssh $ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys ---- -Next, you need to add some developer SSH public keys to the `authorized_keys` file for the `git` user. -Let's assume you have some trusted public keys and have saved them to temporary files. -Again, the public keys look something like this: +Sonraki adım, güvenilir bazı geliştirici SSH ortak anahtarlarını `git` kullanıcısı için `authorized_keys` dosyasına eklemektir. +Varsayalım ki güvenilir ortak anahtarlarınız var ve bunları geçici dosyalara kaydettiniz. +Tekrar belirtmek gerekirse, ortak anahtarlar şu şekilde görünür: [source,console] ---- @@ -36,7 +36,7 @@ O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair ---- -You just append them to the `git` user's `authorized_keys` file in its `.ssh` directory: +Onları sadece `git` kullanıcısının `.ssh` dizinindeki `authorized_keys` dosyasına eklersiniz: [source,console] ---- @@ -45,7 +45,8 @@ $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys ---- -Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:(((git commands, init, bare))) +Şimdi, onlar için boş bir repo kurabilirsiniz. +Bunun için `--bare` seçeneği ile `git init` komutunu çalıştırın, böylece bir çalışma dizini olmadan repo başlatılır:(((git commands, init, bare))) [source,console] ---- @@ -56,10 +57,10 @@ $ git init --bare Initialized empty Git repository in /srv/git/project.git/ ---- -Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. -Note that someone must shell onto the machine and create a bare repository every time you want to add a project. -Let's use `gitserver` as the hostname of the server on which you've set up your `git` user and repository. -If you're running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is (assuming that `myproject` is an existing project with files in it): +Sonra, John, Josie veya Jessica, ona bir uzak repo olarak bağlanıp, bir dalı yukarı iterek, projelerinin ilk sürümünü bu repoya ekleyebilir. +Unutmayın ki bir proje eklemek istediğinizde birisi makinaya giriş yapmalı ve bir yalın repo oluşturmalıdır. +`git` kullanıcınızı ve repoyu kurduğunuz sunucunun ana bilgisayar adını `gitserver` olarak kullanalım. +Eğer bunu içsel (internal) olarak çalıştırıyorsanız ve `gitserver` için DNS kurulumu yaptıysanız, o zaman komutları neredeyse olduğu gibi kullanabilirsiniz (`myproject`i dosyalar içeren mevcut bir proje olarak varsayalım): [source,console] ---- @@ -72,7 +73,7 @@ $ git remote add origin git@gitserver:/srv/git/project.git $ git push origin master ---- -At this point, the others can clone it down and push changes back up just as easily: +Artık, diğerleri bunu kolayca kopyalayabilir ve değişiklikleri itebilir: [source,console] ---- @@ -83,15 +84,15 @@ $ git commit -am 'fix for the README file' $ git push origin master ---- -With this method, you can quickly get a read/write Git server up and running for a handful of developers. +Bu yöntemle, birkaç geliştirici için hızlıca okuma/yazma erişimli bir Git sunucusu kurabilirsiniz. -You should note that currently all these users can also log into the server and get a shell as the `git` user. -If you want to restrict that, you will have to change the shell to something else in the `/etc/passwd` file. +Dikkat etmeniz gereken bir husus, şu anda tüm bu kullanıcıların sunucuya giriş yapıp, bir `git` kullanıcısı olarak bir kabuk (shell) alabilmesidir. +Bunu sınırlamak istiyorsanız, `/etc/passwd` dosyasında kabuğu başka bir şeye değiştirmeniz gerekecektir. -You can easily restrict the `git` user account to only Git-related activities with a limited shell tool called `git-shell` that comes with Git. -If you set this as the `git` user account's login shell, then that account can't have normal shell access to your server. -To use this, specify `git-shell` instead of bash or csh for that account's login shell. -To do so, you must first add the full pathname of the `git-shell` command to `/etc/shells` if it's not already there: +`git` kullanıcı hesabını sadece Git ile ilgili faaliyetlerle kısıtlamak için, Git ile birlikte gelen sınırlı bir kabuk aracı olan `git-shell`i kullanabilirsiniz. +Eğer `git` kullanıcı hesabının giriş kabuğu olarak bunu ayarlarsanız, o hesap sunucunuzda normal kabuk erişimine sahip olamaz. +Bunu kullanmak için, o hesabın giriş kabuğu olarak bash veya csh yerine `git-shell`i belirtmelisiniz. +Bunun için, eğer hali hazırda yoksa, `/etc/shells` dosyasına `git-shell` komutunun tam yolunu eklemeniz gerekmektedir: [source,console] ---- @@ -100,15 +101,15 @@ $ 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 ---- -Now you can edit the shell for a user using `chsh -s `: +Şimdi bir kullanıcının kabuğunu `chsh -s ` komutunu kullanarak düzenleyebilirsiniz: [source,console] ---- $ sudo chsh git -s $(which git-shell) ---- -Now, the `git` user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine. -If you try, you'll see a login rejection like this: +Şimdi, `git` kullanıcısı SSH bağlantısını kullanarak yalnızca Git depolarını itme ve çekme işlemlerini gerçekleştirebilir ama makineye kabuk alamaz. +Yine de denerseniz, şunun gibi bir giriş reddi görürsünüz: [source,console] ---- @@ -118,7 +119,7 @@ hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed. ---- -Now Git network commands will still work just fine but the users won't be able to get a shell. -As the output states, you can also set up a directory in the `git` user's home directory that customizes the `git-shell` command a bit. -For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that. -Run `git help shell` for more information on customizing the shell.(((git commands, help))) +Şimdi Git ağ komutları hala düzgün çalışacak ancak kullanıcılar bir kabuk alamayacaktır. +Çıktıda belirtildiği gibi, `git` kullanıcısının ana dizininde `git-shell` komutunu bir miktar özelleştiren bir dizin de kurabilirsiniz. +Örneğin, sunucunun kabul edeceği Git komutlarını sınırlayabilir veya kullanıcıların SSH ile giriş yapmaya çalıştıklarında görecekleri iletileri özelleştirebilirsiniz. +Kabuğu özelleştirmekle ilgili daha fazla bilgi için `git help shell` komutunu çalıştırın.(((git commands, help))) From 6fd4d4c5097c918712e8ddd6f37de06f45fbbb21 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 12:42:13 +0100 Subject: [PATCH 039/210] Update setting-up-server.asc From 0503cccb05c937cb835a9bcf1ef8b83ecc122888 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 16:50:32 +0100 Subject: [PATCH 040/210] Update git-daemon.asc translated --- book/04-git-server/sections/git-daemon.asc | 44 +++++++++++----------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 1bc42577..41f02a0a 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -1,28 +1,29 @@ -=== Git Daemon +=== Git Cini (Daemon) (((serving repositories, git protocol))) -Next we'll set up a daemon serving repositories using the ``Git'' protocol. -This is a common choice for fast, unauthenticated access to your Git data. -Remember that since this is not an authenticated service, anything you serve over this protocol is public within its network. +Şimdi, repoları ``Git'' protokolünü kullanarak sunan bir daemon kuracağız. +Bu, Git verilerinize hızlı, kimlik doğrulamasız erişim için yaygın bir seçenektir. +Unutmayın ki bu kimlik doğrulamasız bir servis olduğundan, bu protokol üzerinden sunduğunuz her şey, ağ içindeki herkese açık olacaktır. -If you're running this on a server outside your firewall, it should be used only for projects that are publicly visible to the world. -If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each. +Eğer bunu güvenlik duvarınızın dışında bir sunucuda çalıştırıyorsanız, yalnızca dünya genelinde herkese açık olan projeler için kullanılmalıdır. +Eğer çalıştırdığınız sunucu güvenlik duvarınızın içindeyse, birçok insanın veya bilgisayarın (sürekli entegrasyon veya derleme sunucuları gibi) salt okuma erişimine sahip olduğu projeler için kullanabilirsiniz. Böylece her biri için bir SSH anahtarı eklemek zorunda kalmazsınız. -In any case, the Git protocol is relatively easy to set up. -Basically, you need to run this command in a daemonized manner:(((git commands, daemon))) +Her durumda, Git protokolü kurulumu nispeten kolaydır. +Temel olarak, bu komutu daemon olarak çalıştırmanız gerekmektedir:(((git commands, daemon))) [source,console] ---- $ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/ ---- -The `--reuseaddr` option allows the server to restart without waiting for old connections to time out, while the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. -If you're running a firewall, you'll also need to punch a hole in it at port 9418 on the box you're setting this up on. +`--reuseaddr` seçeneği, sunucunun eski bağlantıların zaman aşımını beklemeksizin yeniden başlamasına olanak tanırken, `--base-path` seçeneği, insanların projeleri tüm yolunu belirtmeden kopyalamasına izin verir. +Dizin ise, Git daemon'a dışa aktarılacak repoları nerede bulacağını söyler. +Eğer bir güvenlik duvarı kullanıyorsanız, bunu kurduğunuz kutunun 9418 numaralı portunda bir delik açmanız da gerekecektir. -You can daemonize this process a number of ways, depending on the operating system you're running. +Bu işlemi, çalıştırdığınız işletim sistemine bağlı olarak birkaç farklı şekilde demonize edebilirsiniz. -Since `systemd` is the most common init system among modern Linux distributions, you can use it for that purpose. -Simply place a file in `/etc/systemd/system/git-daemon.service` with these contents: +`systemd` modern Linux dağılımları arasında en yaygın init sistemi olduğu için bunu kullanabilirsiniz. +Sadece `/etc/systemd/system/git-daemon.service` dizinine aşağıdaki içeriğe sahip bir dosya yerleştirin: [source,console] ---- @@ -46,16 +47,17 @@ Group=git WantedBy=multi-user.target ---- -You might have noticed that Git daemon is started here with `git` as both group and user. -Modify it to fit your needs and make sure the provided user exists on the system. -Also, check that the Git binary is indeed located at `/usr/bin/git` and change the path if necessary. +Git daemon'un burada hem grup hem de kullanıcı olarak `git` ile başlatıldığını farketmiş olabilirsiniz. +Bunu kendi ihtiyaçlarınıza uyacak şekilde değiştirin ve sağlanan kullanıcının sistemde var olduğundan emin olun. +Ayrıca, Git binary'sinin gerçekten `/usr/bin/git` dizininde olduğunu kontrol edin ve gerekirse dizini değiştirin. -Finally, you'll run `systemctl enable git-daemon` to automatically start the service on boot, and can start and stop the service with, respectively, `systemctl start git-daemon` and `systemctl stop git-daemon`. +Son olarak, `systemctl enable git-daemon` komutunu çalıştırarak servisin otomatik olarak başlamasını sağlayabilir, `systemctl start git-daemon` komutu ile servisi başlatabilir veya `systemctl stop git-daemon` komutu ile durdurabilirsiniz. -On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else -- as long as you get that command daemonized and watched somehow. +Diğer sistemlerde, `xinetd` (`sysvinit` sisteminizde bir betik) veya başka bir şey kullanmak isteyebilirsiniz. +Yeter ki o komutu bir şekilde demonize edip izleyin. -Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to. -You can do this in each repository by creating a file named `git-daemon-export-ok`. +Sonraki adım olarak, Git'e hangi repoların kimlik doğrulamasız Git sunucu tabanlı erişimine izin vereceğini belirtmelisiniz. +`git-daemon-export-ok` adında bir dosya oluşturarak, her repoda bunu yapabilirsiniz. [source,console] ---- @@ -63,4 +65,4 @@ $ cd /path/to/project.git $ touch git-daemon-export-ok ---- -The presence of that file tells Git that it's OK to serve this project without authentication. +Bu dosyanın varlığı, Git'e bu projenin kimlik doğrulamasız hizmet vermesinin uygun olduğunu söyler. From 5b9a93897197cfedfab99d012fcd6ae3cc31a4a1 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 17:23:04 +0100 Subject: [PATCH 041/210] Update smart-http.asc 04.06 has been translated --- book/04-git-server/sections/smart-http.asc | 50 +++++++++++----------- 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 60bdd309..bd07b9f9 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -1,14 +1,14 @@ -=== Smart HTTP +=== Akıllı HTTP (((serving repositories, HTTP))) -We now have authenticated access through SSH and unauthenticated access through `git://`, but there is also a protocol that can do both at the same time. -Setting up Smart HTTP is basically just enabling a CGI script that is provided with Git called `git-http-backend` on the server.(((git commands, "http-backend"))) -This CGI will read the path and headers sent by a `git fetch` or `git push` to an HTTP URL and determine if the client can communicate over HTTP (which is true for any client since version 1.6.6). -If the CGI sees that the client is smart, it will communicate smartly with it; otherwise it will fall back to the dumb behavior (so it is backward compatible for reads with older clients). +Şimdi hem SSH üzerinden kimlik doğrulamalı erişim hem de `git://` üzerinden kimlik doğrulamasız erişimimiz var, ancak aynı anda her ikisini de yapabilen bir protokol de bulunmaktadır. +Akıllı HTTP'yi kurmak temel olarak sunucuda Git ile birlikte gelen `git-http-backend` adlı bir CGI betiğini etkinleştirmektir.(((git commands, "http-backend"))) +Bu CGI bir `git fetch` veya `git push`un bir HTTP URL'sine gönderdiği dizin ve başlıkları okur ve istemcinin HTTP üzerinden iletişim kurup kuramayacağını belirler (1.6.6 sürümünden itibaren tüm istemciler için doğrudur). +CGI istemcinin akıllı olduğunu görürse onunla akıllı iletişim kurar, aksi takdirde (daha eski istemcilerle geriye dönük uyumluluk için) aptal davranışa geri döner. -Let's walk through a very basic setup. -We'll set this up with Apache as the CGI server. -If you don't have Apache setup, you can do so on a Linux box with something like this:(((Apache))) +Hadi şimdi çok temel bir kurulumu inceleyelim. +Bunu Apache'yi CGI sunucusu olarak kullanarak yapacağız. +Eğer Apache kurulumunuz yoksa, Linux üzerinde şöyle bir şey yapabilirsiniz:(((Apache))) [source,console] ---- @@ -16,16 +16,17 @@ $ sudo apt-get install apache2 apache2-utils $ a2enmod cgi alias env ---- -This also enables the `mod_cgi`, `mod_alias`, and `mod_env` modules, which are all needed for this to work properly. +Bu aynı zamanda bunun düzgün çalışabilmesi için gereken `mod_cgi`, `mod_alias` ve `mod_env` modüllerini de etkinleştirir. -You'll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: +Ayrıca, `/srv/git` dizinlerinin Unix kullanıcı grubunu `www-data` olarak ayarlamanız gerekecektir. +Böylece web sunucunuz repoları okuma ve yazma erişimine sahip olabilir, çünkü CGI betiğini çalıştıran Apache örneği (varsayılan olarak) bu kullanıcı olarak çalışacaktır: [source,console] ---- $ chgrp -R www-data /srv/git ---- -Next we need to add some things to the Apache configuration to run the `git-http-backend` as the handler for anything coming into the `/git` path of your web server. +Şimdi, Apache yapılandırmasına bazı şeyler ekleyelim ki `git-http-backend`i web sunucunuzun `/git` dizinine gelen her şey için işleyici olarak çalıştırsın. [source,console] ---- @@ -34,9 +35,9 @@ SetEnv GIT_HTTP_EXPORT_ALL ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ---- -If you leave out `GIT_HTTP_EXPORT_ALL` environment variable, then Git will only serve to unauthenticated clients the repositories with the `git-daemon-export-ok` file in them, just like the Git daemon did. +Eğer `GIT_HTTP_EXPORT_ALL` ortam değişkenini çıkartırsanız, Git (tam olarak Git daemon'ın yaptığı gibi) yalnızca `git-daemon-export-ok` dosyasına sahip olan repoları kimlik doğrulamasız istemcilere sunacaktır. -Finally you'll want to tell Apache to allow requests to `git-http-backend` and make writes be authenticated somehow, possibly with an Auth block like this: +Son olarak, Apache'ye `git-http-backend`e olan isteklere izin vermesini ve yazma işlemlerinin bir şekilde kimlik doğrulanmasını yapmasını isteyeceksiniz, muhtemelen şu şekilde bir Auth bloğu ile: [source,console] ---- @@ -49,24 +50,25 @@ Finally you'll want to tell Apache to allow requests to `git-http-backend` and m ---- -That will require you to create a `.htpasswd` file containing the passwords of all the valid users. -Here is an example of adding a ``schacon'' user to the file: +Bu geçerli tüm kullanıcıların şifrelerini içeren bir `.htpasswd` dosyası oluşturmanızı gerektirecektir. +İşte dosyaya bir ``schacon`` kullanıcısı eklemenin bir örneği: [source,console] ---- $ htpasswd -c /srv/git/.htpasswd schacon ---- -There are tons of ways to have Apache authenticate users, you'll have to choose and implement one of them. -This is just the simplest example we could come up with. -You'll also almost certainly want to set this up over SSL so all this data is encrypted. +Apache'in kullanıcıların kimliğini doğrulaması için birçok yöntemi bulunmaktadır, bunlardan birini seçip uygulamanız gerekecektir. +Bulabildiğimiz en basit örnek budur. +Ayrıca muhtemelen tüm bu verilerin şifrelenmesi için bunu SSL üzerinden kurmak isteyeceksiniz. -We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs. -The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. -It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. -You can do this with nearly any CGI-capable web server, so go with the one that you know best. +Apache yapılandırma detaylarına fazla girmek istemiyoruz, çünkü muhtemelen farklı bir sunucu kullanıyor olabilirsiniz veya farklı kimlik doğrulama ihtiyacınız olabilir. +Fikir, Git'in çağrıldığında HTTP üzerinden veri gönderme ve alma işlemlerini yürütecek `git-http-backend` adlı bir CGI ile birlikte gelmesidir. +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. -[NOTE] +[NOT] ==== -For more information on configuring authentication in Apache, check out the Apache docs here: https://httpd.apache.org/docs/current/howto/auth.html[] +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[] ==== From 28a4f7432a661b041466f3532beca36eb6ef9843 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 17:31:09 +0100 Subject: [PATCH 042/210] Update smart-http.asc "04.06 Smart HTTP" has been translated. From 01dbfd869b457ae0ee0edb3473eedf03f9310e3f Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 17:49:37 +0100 Subject: [PATCH 043/210] Update gitweb.asc 04.07 has been translated --- book/04-git-server/sections/gitweb.asc | 38 +++++++++++++------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index b0c4572d..a12f4129 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -1,17 +1,17 @@ === GitWeb (((serving repositories, GitWeb)))(((GitWeb))) -Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. -Git comes with a CGI script called GitWeb that is sometimes used for this. +Şimdi temel okuma/yazma ve salt okuma erişiminiz olduğuna göre, basit bir web tabanlı görselleştirici kurmak isteyebilirsiniz. +Git bazen bu iş için kullanılan GitWeb adlı bir CGI betiği ile birlikte gelir. [[gitweb]] -.The GitWeb web-based user interface. -image::images/git-instaweb.png[The GitWeb web-based user interface.] +.GitWeb ağ-tabanlı kullanıcı arayüzü. +image::images/git-instaweb.png[GitWeb ağ-tabanlı kullanıcı arayüzü.] -If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight web server on your system like `lighttpd` or `webrick`. -On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. -If you're running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. -To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.(((git commands, instaweb))) +Eğer sisteminizde `lighttpd` veya `webrick` gibi hafif bir ağ sunucusuna sahipseniz ve GitWeb'in projeniz için nasıl görüneceğini kontrol etmek istiyorsanız, Git bir geçici bir örnek başlatmak için bir komut içerir. +Linux makinelerinde genellikle `lighttpd` yüklüdür, bu nedenle projeniz dizininde `git instaweb` yazarak bunu çalıştırabilirsiniz. +Mac'te ise Ruby ile önceden yüklenmiş gelen Leopard bulunduğu için, `webrick` belki en iyi seçeneğiniz olabilir. +`instaweb`'i lighttpd olmayan bir işleyici ile başlatmak için `--httpd` seçeneği ile çalıştırabilirsiniz.(((git commands, instaweb))) [source,console] ---- @@ -20,19 +20,19 @@ $ git instaweb --httpd=webrick [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] ---- -That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. -It's pretty easy on your part. -When you're done and want to shut down the server, you can run the same command with the `--stop` option: +Bu komut, önce 1234 portunda bir HTTPD sunucusunu ve ardından otomatik olarak bu sayfada açılan bir web tarayıcısını başlatır. +Gördüğünüz gibi yapmanız gereken pek bir şey yok. +İşiniz bittiğinde ve sunucuyu kapatmak istediğinizde, aynı komutu `--stop` seçeneği ile çalıştırabilirsiniz: [source,console] ---- $ git instaweb --httpd=webrick --stop ---- -If you want to run the web interface on a server all the time for your team or for an open source project you're hosting, you'll need to set up the CGI script to be served by your normal web server. -Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `dnf`, so you may want to try that first. -We'll walk through installing GitWeb manually very quickly. -First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: +Eğer web arayüzünü, ekibiniz veya barındırdığınız bir açık kaynak projesi için, sürekli bir sunucuda çalıştırmak istiyorsanız, CGI betiğini normal web sunucunuz tarafından sunulacak şekilde kurmanız gerekecektir. +Bazı Linux dağıtımlarında `apt` veya `dnf` üzerinden kurabileceğiniz bir `gitweb` paketi bulunabilir, bu nedenle önce bunu denemek isteyebilirsiniz. +GitWeb'i nasıl hızlı bir şekilde manuel olarak kuracağınızı anlatacağız. +İlk olarak, GitWeb ile birlikte gelen Git kaynak kodunu elde etmeniz ve özel CGI betiğini oluşturmanız gerekiyor: [source,console] ---- @@ -47,8 +47,8 @@ make[2]: `GIT-VERSION-FILE' is up to date. $ sudo cp -Rf gitweb /var/www/ ---- -Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. -Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: +Dikkat edin, komuta `GITWEB_PROJECTROOT` değişkeni ile Git depolarınızı nerede bulacağınızı belirtmeniz gerekmektedir. +Şimdi, Apache'nin bu betik için CGI'yi kullanmasını sağlamalısınız, bunun için bir sanal sunucu (virtualHost) ekleyebilirsiniz: [source,console] ---- @@ -66,5 +66,5 @@ Now, you need to make Apache use CGI for that script, for which you can add a Vi ---- -Again, GitWeb can be served with any CGI or Perl capable web server; if you prefer to use something else, it shouldn't be difficult to set up. -At this point, you should be able to visit `http://gitserver/` to view your repositories online. +GitWeb herhangi bir CGI veya Perl yetenekli web sunucusu ile sunulabilir, yine de başka bir şey kullanmayı tercih ediyorsanız, kurulumu zor olmasa gerek. +Bu noktada, repolarınızı çevrimiçi görüntülemek için `http://gitserver/` adresini ziyaret edebilmelisiniz. From da6a3be845834ab1ee06861d9ba9f27e0dfcb233 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 5 Feb 2024 17:50:37 +0100 Subject: [PATCH 044/210] Update gitweb.asc "04.07 GitWeb" has been translated. From 2503891234dfc75b5da24c8a4212b6b6bcd83833 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 6 Feb 2024 10:42:37 +0100 Subject: [PATCH 045/210] Update gitlab.asc 04.08 translated --- book/04-git-server/sections/gitlab.asc | 163 +++++++++++++------------ 1 file changed, 82 insertions(+), 81 deletions(-) diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index a17d0e5d..77cb76c3 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -1,131 +1,132 @@ === GitLab (((serving repositories, GitLab)))(((GitLab))) -GitWeb is pretty simplistic though. -If you're looking for a more modern, fully featured Git server, there are some several open source solutions out there that you can install instead. -As GitLab is one of the more popular ones, we'll cover installing and using it as an example. -This is a bit more complex than the GitWeb option and likely requires more maintenance, but it is a much more fully featured option. +GitWeb oldukça basit olmasına rağmen, daha modern ve tam özellikli bir Git sunucusu arıyorsanız, onun yerine kurabileceğiniz birkaç açık kaynak çözümü bulunmaktadır. +GitLab popüler olanlardan biri olduğu için, onu örnek olarak kurmayı ve kullanmayı ele alacağız. +GitWeb seçeneğinden biraz daha karmaşık olmasına ve muhtemelen daha fazla bakım gerektirmesine karşın, çok daha kapsamlı bir seçenektir. -==== Installation +==== Kurulum -GitLab is a database-backed web application, so its installation is a bit more involved than some other Git servers. -Fortunately, this process is very well-documented and supported. +GitLab, veritabanı destekli bir ağ uygulaması olduğundan, kurulumu diğer bazı Git sunucularından biraz daha karmaşıktır. +Neyse ki, bu süreç çok iyi belgelendirilmiştir ve desteklenmektedir. -There are a few methods you can pursue to install GitLab. -To get something up and running quickly, you can download a virtual machine image or a one-click installer from https://bitnami.com/stack/gitlab[], and tweak the configuration to match your particular environment.(((bitnami))) -One nice touch Bitnami has included is the login screen (accessed by typing alt+→); it tells you the IP address and default username and password for the installed GitLab. +GitLab'ı kurmak için takip edebileceğiniz birkaç yöntem bulunmaktadır. +Çalışan bir şeyi hızlı bir şekilde kurmak için, bir sanal makine görüntüsü indirebilir veya https://bitnami.com/stack/gitlab[] adresinden tek tıkla kurabilir ve özel ortamınıza uygun şekilde yapılandırabilirsiniz.(((bitnami))) +Bitnami'nin eklediği hoş bir özellik, giriş ekranıdır (alt+→ tuşlarını yazarak erişilir). Bu, yüklenmiş GitLab'ın IP adresini ve varsayılan kullanıcı ad ve şifresini size bildirir. [[bitnami]] -.The Bitnami GitLab virtual machine login screen. -image::images/bitnami.png[The Bitnami GitLab virtual machine login screen.] +.Bitnami GitLab sanal makine giriş ekranı. +image::images/bitnami.png[Bitnami GitLab sanal makine giriş ekranı.] -For anything else, follow the guidance in the GitLab Community Edition readme, which can be found at https://gitlab.com/gitlab-org/gitlab-ce/tree/master[]. -There you'll find assistance for installing GitLab using Chef recipes, a virtual machine on Digital Ocean, and RPM and DEB packages (which, as of this writing, are in beta). -There's also ``unofficial'' guidance on getting GitLab running with non-standard operating systems and databases, a fully-manual installation script, and many other topics. +Başka bir şey için, GitLab Community Edition readme (oku-beni) dosyasındaki yönergeleri takip edin (bu dosyayı https://gitlab.com/gitlab-org/gitlab-ce/tree/master[] adresinde bulabilirsiniz). +Buradaki şef tarifleri, Digital Ocean üzerinde bir sanal makine ile RPM ve DEB paketleri kullanarak (yazıldığı tarih itibariyle beta sürümünde olanlar) size GitLab'ı nasıl kuracağınıza dair yardım sulabilir. +Ayrıca, standart olmayan işletim sistemleri ve veritabanlarıyla GitLab'ı çalıştırma, tamamen manuel bir kurulum betiği ve birçok başka konuyla ilgili "resmi olmayan" yönergeler bulabilirsiniz. -==== Administration +==== Yönetim -GitLab's administration interface is accessed over the web. -Simply point your browser to the hostname or IP address where GitLab is installed, and log in as an admin user. -The default username is `admin@local.host`, and the default password is `5iveL!fe` (which you will be prompted to change as soon as you enter it). -Once logged in, click the ``Admin area'' icon in the menu at the top right. +GitLab'ın yönetim arayüzüne ağ üzerinden erişilir. +Sadece tarayıcınızı GitLab'ın kurulu olduğu ana bilgisayar adına veya IP adresine yönlendirin ve bir yönetici kullanıcısı olarak oturum açın. +Varsayılan kullanıcı adı `admin@local.host` ve varsayılan şifre `5iveL!fe` şeklindedir (şifreyi girdikten hemen sonra değiştirmeniz istenecektir). +Oturum açtıktan sonra, sağ üst köşede bulunan menüdeki "Yönetici Alanı" simgesine tıklayın. [[gitlab_menu]] -.The ``Admin area'' item in the GitLab menu. -image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu.] +.GitLab menüsündeki "Yönetici Alanı" ögesi. +image::images/gitlab-menu.png[GitLab menüsündeki "Yönetici Alanı" ögesi.] -===== Users +===== Kullanıcılar -Users in GitLab are accounts that correspond to people. -User accounts don't have a lot of complexity; mainly it's a collection of personal information attached to login data. -Each user account comes with a *namespace*, which is a logical grouping of projects that belong to that user. -If the user +jane+ had a project named +project+, that project's url would be `http://server/jane/project`. +GitLab'deki kullanıcılar, insanlara karşılık gelen hesaplardır. +Kullanıcı hesapları çok karmaşık değildir: genellikle, giriş verilerine eklenmiş kişisel bilgilerin bir koleksiyonudur. +Her kullanıcı hesabı, o kullanıcıya ait projelerin mantıksal bir gruplaması olan bir *adalanı* (namespace) ile gelir. +Eğer +mehmet+ kullanıcısının +projem+ adında bir projesi olsaydı, o proje'nin URL'si `http://sunucu/mehmet/projem` olurdu. [[gitlab_users]] -.The GitLab user administration screen. -image::images/gitlab-users.png[The GitLab user administration screen.] +.GitLab kullanıcı yönetim ekranı. +image::images/gitlab-users.png[GitLab kullanıcı yönetim ekranı.] -Removing a user can be done in two ways. -``Blocking'' a user prevents them from logging into the GitLab instance, but all of the data under that user's namespace will be preserved, and commits signed with that user's email address will still link back to their profile. +Bir kullanıcıyı kaldırmak iki şekilde yapılabilir: +Bir kullanıcıyı "engellemek", onların GitLab örneğine giriş yapmasını engeller, ancak o kullanıcının adalanı altındaki tüm veriler korunur ve o kullanıcının e-posta adresiyle imzalanan katkılar hala profiliyle bağlantılıdır. -``Destroying'' a user, on the other hand, completely removes them from the database and filesystem. -All projects and data in their namespace is removed, and any groups they own will also be removed. -This is obviously a much more permanent and destructive action, and its uses are rare. +Öte yandan, bir kullanıcıyı "silmek", onu tamamen veritabanından ve dosya sisteminden kaldırır. +Adalanı altındaki tüm projeler ve veriler, sahip oldukları tüm gruplarla birlikte kaldırılır. +Bu açıkça çok daha kalıcı ve yıkıcı bir işlem olduğu için kullanımı nadirdir. [[_gitlab_groups_section]] -===== Groups +===== Gruplar -A GitLab group is an assemblage of projects, along with data about how users can access those projects. -Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be `http://server/training/materials`. +Bir GitLab grubu bir projeler topluluğudur ve kullanıcıların bu projelere nasıl erişebileceği hakkında veriler içerir. +Her grup (kullanıcılar gibi) bir proje adalanına sahiptir, bu nedenle +training+ adında bir grup +materials+ adında bir projeye sahipse, URL'si `http://sunucu/training/materials` olur. [[gitlab_groups]] -.The GitLab group administration screen. -image::images/gitlab-groups.png[The GitLab group administration screen.] +.GitLab grup yönetim ekranı. +image::images/gitlab-groups.png[GitLab grup yönetim ekranı.] -Each group is associated with a number of users, each of which has a level of permissions for the group's projects and the group itself. -These range from ``Guest'' (issues and chat only) to ``Owner'' (full control of the group, its members, and its projects). -The types of permissions are too numerous to list here, but GitLab has a helpful link on the administration screen. +Her bir grup, grubun kendisine ve projelerine, belli bir düzeyde erişim iznine sahip, bir dizi kullanıcı ile ilişkilidir. +Bu izinler, "Misafir" (yalnızca sorunlar ve sohbet) ile "Sahip" (grubun, üyelerin ve projelerin tam denetimi) arasında değişmektedir. +İzin türleri burada listelenmek için fazla sayıda, ancak GitLab'ın yönetim ekranında yardımcı bir bağlantı bulunmaktadır. -===== Projects +===== Projeler -A GitLab project roughly corresponds to a single Git repository. -Every project belongs to a single namespace, either a user or a group. -If the project belongs to a user, the owner of the project has direct control over who has access to the project; if the project belongs to a group, the group's user-level permissions will also take effect. +Bir GitLab projesi yaklaşık olarak tek bir Git reposuna karşılık gelir. +Her proje, bir kullanıcı veya bir grup olmak üzere tek bir adalanına aittir. +Proje bir kullanıcıya aitse, projenin sahibi projeye kimin erişebileceğini doğrudan kontrol eder. +Eğer proje bir gruba aitse, grup düzeyindeki kullanıcı izinleri de etkili olacaktır. -Every project also has a visibility level, which controls who has read access to that project's pages and repository. -If a project is _Private_, the project's owner must explicitly grant access to specific users. -An _Internal_ project is visible to any logged-in user, and a _Public_ project is visible to anyone. -Note that this controls both `git fetch` access as well as access to the web UI for that project. +Her proje ayrıca bir görünürlük seviyesine sahiptir, bu da projenin sayfalarına ve reposuna kimlerin okuma erişimine sahip olduğunu denetler. +Bir proje _private_ (özel) ise, proje sahibi belirli kullanıcılara erişimi açıkça vermelidir. +_internal_ (iç) bir proje sadece oturum açmış her kullanıcı tarafından görülebilir, _public_ (herkese açık) bir proje ise herkese görünür. +Unutmayın ki, bu hem `git fetch` erişimini hem de o projenin web arayüzüne erişimi kontrol eder. -===== Hooks +===== Kancalar (Hooks) -GitLab includes support for hooks, both at a project or system level. -For either of these, the GitLab server will perform an HTTP POST with some descriptive JSON whenever relevant events occur. -This is a great way to connect your Git repositories and GitLab instance to the rest of your development automation, such as CI servers, chat rooms, or deployment tools. +GitLab, hem proje ve hem de sistem düzeyinde kancaları destekler. +Her ikisi için de, ilgili olaylar meydana geldiğinde GitLab sunucusu açıklamacı JSON ile bir HTTP POST gerçekleştirir. +Bu, Git repolarınızı ve GitLab örneğinizi, CI sunucuları, sohbet odaları veya dağıtım araçları gibi geliştirme otomasyonunuzun geri kalanına bağlamanın harika bir yoludur. -==== Basic Usage +==== Basit Kullanım -The first thing you'll want to do with GitLab is create a new project. -This is accomplished by clicking the ``+'' icon on the toolbar. -You'll be asked for the project's name, which namespace it should belong to, and what its visibility level should be. -Most of what you specify here isn't permanent, and can be re-adjusted later through the settings interface. -Click ``Create Project'', and you're done. +GitLab'da yapmak isteyeceğiniz ilk şey yeni bir proje oluşturmaktır. +Bunu, araç çubuğundaki ``+`` simgesine tıklayarak yapabilirsiniz. +Projenin adı, hangi adalanına ait olması gerektiği ve görünürlük seviyesinin ne olması gerektiği sorulacaktır. +Burada belirttiğiniz çoğu şey kalıcı değildir ve daha sonra ayarlar arayüzü üzerinden yeniden ayarlanabilir. +``Create Project``e (proje oluştur) tıklayın ve işlem tamamdır. -Once the project exists, you'll probably want to connect it with a local Git repository. -Each project is accessible over HTTPS or SSH, either of which can be used to configure a Git remote. -The URLs are visible at the top of the project's home page. -For an existing local repository, this command will create a remote named `gitlab` to the hosted location: +Proje oluştuktan sonra, muhtemelen yerel bir Git reposuyla bağlantı kurmak isteyeceksiniz. +Her proje HTTPS veya SSH üzerinden erişilebilirdir ve her ikisi de bir Git uzak sunucusu yapılandırmak için kullanılabilir. +URL'ler, proje ana sayfasının üstünde görünür. +Bu komut mevcut bir yerel repo için barındırılan konuma `gitlab` adında bir uzak sunucu oluşturacaktır: [source,console] ---- $ git remote add gitlab https://server/namespace/project.git ---- -If you don't have a local copy of the repository, you can simply do this: +Eğer reponuzun yerel bir kopyası yoksa, bunu sadece şu şekilde yapabilirsiniz: [source,console] ---- $ git clone https://server/namespace/project.git ---- -The web UI provides access to several useful views of the repository itself. -Each project's home page shows recent activity, and links along the top will lead you to views of the project's files and commit log. +Ağ arayüzü reponun kendisine ait bazı kullanışlı görüntülere erişim sağlar. +Her proje ana sayfası, son etkinliği gösterir ve üst kısımdaki bağlantılar, proje dosyalarının ve işlem günlüğün görüntülerine yönlendirir. -==== Working Together +==== Birlikte Çalışma -The simplest way of working together on a GitLab project is by giving another user direct push access to the Git repository. -You can add a user to a project by going to the ``Members'' section of that project's settings, and associating the new user with an access level (the different access levels are discussed a bit in <<_gitlab_groups_section>>). -By giving a user an access level of ``Developer'' or above, that user can push commits and branches directly to the repository with impunity. +Bir GitLab projesinde birlikte çalışmanın en basit yolu, başka bir kullanıcıya Git reposuna doğrudan itme erişimi vermektedir. +Bunu yapmak için, o projenin ayarlarında "Üyeler" bölümüne giderek yeni kullanıcıyı bir erişim seviyesi ile ilişkilendirebilirsiniz (farklı erişim seviyeleri konusuna <<_gitlab_groups_section>> bölümünde biraz girilmiştir). +"Geliştirici" veya daha üst bir erişim seviyesi verilen bir kullanıcı o repoya gelişigüzel olarak doğrudan işlemler ve dallar ekleyebilir. -Another, more decoupled way of collaboration is by using merge requests. -This feature enables any user that can see a project to contribute to it in a controlled way. -Users with direct access can simply create a branch, push commits to it, and open a merge request from their branch back into `master` or any other branch. -Users who don't have push permissions for a repository can ``fork'' it (create their own copy), push commits to _that_ copy, and open a merge request from their fork back to the main project. -This model allows the owner to be in full control of what goes into the repository and when, while allowing contributions from untrusted users. +Daha bağımsız bir işbirliği yöntemi de "birleştirme isteklerini" kullanmaktır. +Bu özellik, bir projeyi görebilen herhangi bir kullanıcının, denetimli bir şekilde katkıda bulunmasını sağlar. +Doğrudan erişimi olan kullanıcılar basitçe bir dal oluşturabilir, işlemleri ona iter ve dallarından `master` veya başka bir dala birleştirme isteği açabilir. +Depoya itme izinleri olmayan kullanıcılar onu "çatallayabilir" (kendi kopyalarını oluşturabilir), işlemleri bu kopyaya iter ve kendi çatalından ana projeye birleştirme isteği açabilir. +Bu model "güvenilmeyen kullanıcılardan" katkı alınmasına olanak tanırken, sahibin (owner) de repoya neyin, ne zaman gireceği konusunda tam bir kontrol sahibi olmasını sağlar. -Merge requests and issues are the main units of long-lived discussion in GitLab. -Each merge request allows a line-by-line discussion of the proposed change (which supports a lightweight kind of code review), as well as a general overall discussion thread. -Both can be assigned to users, or organized into milestones. +Birleştirme istekleri ve sorunlar, GitLab'da uzun süreli tartışmanın ana birimleridir. +Her birleştirme isteği, önerilen değişikliğin satır bazında tartışılmasına (hafif bir kod incelemesi) ve genel bir genel tartışma başlığına izin verir. +Her ikisi de kullanıcılara atanabilir veya kilometre taşlarına düzenlenebilir. -This section is focused mainly on the Git-related features of GitLab, but as a mature project, it provides many other features to help your team work together, such as project wikis and system maintenance tools. -One benefit to GitLab is that, once the server is set up and running, you'll rarely need to tweak a configuration file or access the server via SSH; most administration and general usage can be accomplished through the in-browser interface. +Bu bölüm, öncelikle GitLab'ın Git ile ilgili özelliklerine odaklanmış olsa da, olgun bir proje olarak, ekibinizin birlikte çalışmasına yardımcı olacak birçok başka özellik de sunar (örneğin proje vikileri ve sistem bakım araçları). +GitLab'ın bir avantajı da sunucu kurulup ve çalıştırıldığı zaman, nadiren bir yapılandırma dosyasını ayarlamak veya sunucuya SSH üzerinden erişmek gibi bir ihtiyacınızın olmamasıdır. +Çoğu yönetim ve genel kullanım, tarayıcı tabanlı arayüz üzerinden gerçekleştirilebilir. From f79d752cc86cd89eb3d476502848d85c1cd7c47c Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 6 Feb 2024 11:22:39 +0100 Subject: [PATCH 046/210] Update hosted.asc 04.09 translated --- book/04-git-server/sections/hosted.asc | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index 6828f64e..ac1f3913 100644 --- a/book/04-git-server/sections/hosted.asc +++ b/book/04-git-server/sections/hosted.asc @@ -1,10 +1,14 @@ -=== Third Party Hosted Options +=== Üçüncü Taraf Barındırma Seçenekleri -If you don't want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. -Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. -Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with. +Kendi Git sunucunuzu kurmak için gereken tüm işlemleri yapmak istemiyorsanız, Git projelerinizi barındırabileceğiniz (hosting) harici bir siteden yayın yapma seçenekleriniz de bulunmaktadır. +Bunu yapmanın birçok avantajı vardır: bir barındırma sitesi genellikle hızlı kurulur, projeleri başlatmak kolaydır ve sunucu bakım veya izlemesi gerekmez. +Dahili olarak kendi sunucunuzu kurup çalıştırsanız bile, açık kaynak kodunuz için genel bir barındırma sitesini kullanmak isteyebilirsiniz. +Bu şekilde genellikle açık kaynak topluluğunun sizi bulması ve yardım etmesi daha kolay olur. -These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. -To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[] +Bu günlerde seçebileceğiniz birçok barındırma seçeneği bulunmaktadır, her birinin farklı avantajları ve dezavantajları vardır. +Güncel bir liste görmek için, ana Git wiki'sindeki GitHosting sayfasına göz atabilirsiniz: +https://git.wiki.kernel.org/index.php/GitHosting[] -We'll cover using GitHub in detail in <>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server. +Kendi Git sunucunuzu kurmak istemiyorsanız, GitHub gibi en büyük Git barındırma hizmetlerinden birini kullanmayı düşünebilirsiniz (GitHub ile ilgili detaylı bilgilere <> bölümünde yer vereceğiz). +GitHub şu anda en büyük Git barındırma hizmetidir ve herhangi bir durumda GitHub üzerinde barındırılan projelerle etkileşimde bulunmanız gerekebilir. +Ancak, kendi Git sunucunuzu kurmak istemezseniz, tercih edebileceğiniz onlarca farklı seçenek daha mevcuttur. From d0fd682f839a76821d34ca4134b970b3c74b4497 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 6 Feb 2024 11:27:32 +0100 Subject: [PATCH 047/210] Create summary.asc summary section has been added --- book/04-git-server/sections/summary.asc | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 book/04-git-server/sections/summary.asc diff --git a/book/04-git-server/sections/summary.asc b/book/04-git-server/sections/summary.asc new file mode 100644 index 00000000..eac8b167 --- /dev/null +++ b/book/04-git-server/sections/summary.asc @@ -0,0 +1,9 @@ +[[_git_server_summary]] +=== Özet + +Başkalarıyla işbirliği yapmak veya çalışmalarınızı paylaşmak için uzaktan bir Git reposunu kurabileceğiniz birkaç seçeneğiniz bulunmaktadır. + +Kendi sunucunuzu çalıştırmak size büyük bir kontrol ve sunucuyu kendi güvenlik duvarınız içinde çalıştırmanıza olanak tanır, ancak bu tür bir sunucu genellikle kurmak ve bakımını yapmak için önemli ölçüde zaman gerektirir. +Verilerinizi barındırılan bir sunucuya yerleştirirseniz, kurulumu ve bakımı kolay olur, ancak kodunuzu başka birinin sunucularında tutmanız gerekeceği için bazı kurumlar buna izin vermez. + +Hangi çözümün veya çözüm karmasının sizin ve kuruluşunuz için uygun olduğunu belirlemek oldukça basittir. From 53c9bb643e0c8e2da0312439691b3b02af384a75 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 7 Feb 2024 13:41:54 +0100 Subject: [PATCH 048/210] Update distributed-workflows.asc 05.01 translated --- .../sections/distributed-workflows.asc | 135 +++++++++--------- 1 file changed, 71 insertions(+), 64 deletions(-) diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 124fbad7..3c3dc085 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,90 +1,97 @@ -=== Distributed Workflows +=== Dağıtık İş Akışları (((workflows))) -In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. -In centralized systems, every developer is a node working more or less equally with a central hub. -In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. -This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility. -We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. +Merkezi Sürüm Denetim Sistemleri (CVCS'ler) ile karşılaştırıldığında, Git'in dağıtık yapısı, geliştiricilerin projelerde nasıl işbirliği yapacakları konusunda çok daha esnek olmalarını sağlar. +Merkezi sistemlerde, her geliştirici merkezi bir dağıtım göbeğiyle (hub) neredeyse eşit olarak çalışan bir düğümdür (node). +Ancak, Git'te her geliştirici potansiyel olarak hem bir düğüm hem de bir göbektir: yani, her geliştirici hem diğer repolara kod katkısında bulunabilir, hem de diğerlerinin çalışmalarını temel alabilecekleri ve katkıda bulunabilecekleri bir açık repoyu yürütebilir. +Bu, projeniz ve/veya ekibiniz için geniş bir olası iş akışı yelpazesi sunar, bu esneklikten faydalanabileceğiniz birkaç yaygın paradigmayı ele alacağız. +Her tasarımın güçlü yanlarını ve olası zayıflıklarını inceleyeceğiz. +Kullanım amacıyla bunlardan tek birini seçebilir veya her birinden özellikleri bazı özellikleri alarak bir karma elde edebilirsiniz. -==== Centralized Workflow +==== Merkezi İş Akışları (((workflows, centralized))) -In centralized systems, there is generally a single collaboration model -- the centralized workflow. -One central hub, or _repository_, can accept code, and everyone synchronizes their work with it. -A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location. +Merkezi sistemlerde genellikle tek bir işbirliği modeli bulunur: merkezi iş akışı. +Merkezi bir dağıtım göbeği veya _repo_, kodları kabul edebilir ve herkes çalışmalarını onunla eşitler. +Geliştiriciler (o göbeğin tüketicileri olan) düğümlerdir ve işlerini bu merkezi konumla eşitlerler. -.Centralized workflow. -image::images/centralized_workflow.png[Centralized workflow.] +.Merkezi iş akışı. +image::images/centralized_workflow.png[Merkezi iş akışı.] -This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. -The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes. -This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git. +Bunun anlamı, iki geliştiricinin göbekten (hub, repo) kopyaladığı ve her ikisinin de değişiklikler yaptığı durumda, değişikliklerini ilk gönderen birinci geliştiricinin bunu herhangi bir sorun yaşamadan yapabileceğidir. +İkinci geliştirici değişiklikleri göndermeden önce, birinci geliştiricinin çalışmasını birleştirmelidir. +Böylece birinci geliştiricinin değişikliklerini üzerine yazmamış olur. +Bu kavram, Subversion(((Subversion))) (veya herhangi bir başka CVCS) gibi Git'te de geçerlidir ve bu model Git'te mükemmel bir şekilde çalışır. -If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. -Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other. +Şirketiniz veya ekibinizde merkezi iş akışından zaten memnunsanız, Git'i kullanarak bu iş akışını kolayca sürdürebilirsiniz. +Tek bir repo kurun ve ekibinizdeki herkese itme erişimi verin. +Git kullanıcıların birbirlerinin üstüne yazmasına izin vermez. -Say John and Jessica both start working at the same time. -John finishes his change and pushes it to the server. -Then Jessica tries to push her changes, but the server rejects them. -She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges. -This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with. +Ahmet ve Mehmet'in aynı anda çalışmaya başladıklarını varsayalım. +Ahmet değişikliğini tamamlar ve onu sunucuya iter. +Sonra Mehmet değişikliklerini iterlemeye çalışır, ancak sunucu bunları reddeder. +Ona, ileri alınmayan değişikliklerini iterlemeye çalıştığı ve bunu yapamayacağı söylenir, çünkü önce çekme ve birleştirme yapması gerekmektedir. +Bu iş akış modeli, birçok insanın aşina olduğu ve rahat hissettiği bir kavram olduğu için çoğu kişiye çekici gelir. -This is also not limited to small teams. -With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously. +Bu sadece küçük ekiplerle sınırlı değildir. +Git'in dallanma modeliyle, yüzlerce geliştiricinin aynı anda onlarca dal üzerinde başarılı bir şekilde çalışması mümkündür. [[_integration_manager]] -==== Integration-Manager Workflow +==== Birleşme Yöneticisi İş Akışı (((workflows, integration manager))) -Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's. -This scenario often includes a canonical repository that represents the ``official'' project. -To contribute to that project, you create your own public clone of the project and push your changes to it. -Then, you can send a request to the maintainer of the main project to pull in your changes. -The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. -The process works as follows (see <>): - -1. The project maintainer pushes to their public repository. -2. A contributor clones that repository and makes changes. -3. The contributor pushes to their own public copy. -4. The contributor sends the maintainer an email asking them to pull changes. -5. The maintainer adds the contributor's repository as a remote and merges locally. -6. The maintainer pushes merged changes to the main repository. +Çünkü Git, birden çok uzak repoya sahip olmanıza izin verir ve her geliştiricinin kendi açık reposuna yazma erişimi ve diğer herkesin okuma erişiminin olduğu bir iş akışına sahip olmanız mümkündür. +Bu senaryo genellikle, "resmi" projeyi temsil eden kanonik bir repo içerir. +Bu projeye katkıda bulunmak için, projenin kendi açık kopyanızı oluşturur ve değişikliklerinizi ona itersiniz. +Daha sonra, ana projenin bakıcısına değişikliklerinizi çekmesi için bir istek gönderebilirsiniz. +Proje yürütücüsü daha sonra; reponuzu bir uzak repo olarak ekleyebilir, değişikliklerinizi yerel olarak test edebilir, bunları kendi dalına birleştirebilir ve reposuna geri itebilir. +İşlem şu şekilde çalışır: + +Süreç şöyle ilerler (bkz <>): + +1. Proje yürütücüsü kendi acık reposuna iter. +2. Bir katkılayıcı bu repoyu kopyalar ve değişiklikler yapar. +3. Katkılayıcı bunu kendi açık kopyasına iter. +4. Katkılayıcı yürütücüye değişiklikleri çekmesi için bir e-posta gönderir. +5. Yürütücü katkıcının reposunu bir uzak repo olarak ekler ve yerel olarak birleştirir. +6. Yürütücü birleştirilen değişiklikleri ana repoya iter. [[wfdiag_b]] -.Integration-manager workflow. -image::images/integration-manager.png[Integration-manager workflow.] +.Birleşme yöneticisi iş akışı. +image::images/integration-manager.png[Birleşme yöneticisi iş akışı.] (((forking))) -This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see. -One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. -Contributors don't have to wait for the project to incorporate their changes -- each party can work at their own pace. +Bu, GitHub veya GitLab gibi dağıtım-göbeği tabanlı araçlarla çok yaygın bir iş akışıdır. +Burada bir projeyi çatallamak (dal açmak) ve değişikliklerinizi herkesin görebilmesi için dalınıza itmek çok kolaydır. +Bu yaklaşımın başlıca avantajlarından biri, ana repo yürütücüsünün herhangi bir zamanda değişikliklerinizi alabilmesidir. +Katkılayıcılar değişikliklerinin projeye dahil edilmesini beklemek zorunda değillerdir: her taraf kendi hızında çalışabilir. -==== Dictator and Lieutenants Workflow +==== Diktatör ve Yardımcılar İş Akışı (((workflows, dictator and lieutenants))) -This is a variant of a multiple-repository workflow. -It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. -Various integration managers are in charge of certain parts of the repository; they're called _lieutenants_. -All the lieutenants have one integration manager known as the benevolent dictator. -The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull. -The process works like this (see <>): - -1. Regular developers work on their topic branch and rebase their work on top of `master`. - The `master` branch is that of the reference repository to which the dictator pushes. -2. Lieutenants merge the developers' topic branches into their `master` branch. -3. The dictator merges the lieutenants' `master` branches into the dictator's `master` branch. -4. Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it. +Bu, çoklu repo iş akışının bir türüdür. +Genellikle, Linux çekirdeği gibi, yüzlerce katılımcısı olan büyük projeler tarafından kullanılır. +Çeşitli birleşim yöneticileri belirli repo parçalarından sorumludur ve bunlara _yardımcılar_ denir. +Tüm yardımcılar, "benevolent dictator" (yardımsever diktatör) olarak bilinen bir birleşim yöneticisine sahiptir. +Tüm yardımcıların bu yardımsever diktatörün kendi dizininden referans repoya ittiği kodu çekmesi gereklidir. +Süreç şöyle işler (bkz. <>): + +1. Normal geliştiriciler tematik dallarda çalışır ve çalışmalarını `master` üzerine temeller (rebase). + `master` dalı yöneticinin ittiği referans reposunun dalıdır. +2. Yardımcılar, geliştiricilerin konu dallarını kendi `master` dallarına birleştirir. +3. Diktatör yardımcıların `master` dallarını kendi `master` dalına birleştirir. +4. Son olarak, diktatör bu `master` dalını referans reposuna iter, böylece diğer geliştiriciler bunun üzerine temelleme yapabilir. [[wfdiag_c]] -.Benevolent dictator workflow. -image::images/benevolent-dictator.png[Benevolent dictator workflow.] +.Yardımsever diktatör iş akışı. +image::images/benevolent-dictator.png[Yardımsever diktatör iş akışı.] -This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments. -It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. +Bu tür bir iş akışı yaygın değildir, ancak çok büyük projelerde veya yüksek derecede hiyerarşik ortamlarda faydalı olabilir. +Proje liderine (diktatöre) projenin büyük kısmını devretmesine ve bunları birleştirmeden önce bir çok noktada geniş kod altkümeleri toplamasına olanak tanır. -==== Workflows Summary +==== İş Akışı Özeti -These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. -Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows. -In the next section, you'll learn about a few common patterns for contributing to a project. +Bunlar, Git gibi bir dağıtılmış sistemle mümkün olan bazı yaygın olarak kullanılan iş akışlarıdır, ancak gördüğünüz gibi, gerçek dünya iş akışınıza uyacak şekilde birçok değişiklik yapılabilir. +Umarım artık sizin için hangi iş akışı karmasının daha uygun olduğunu belirleyebilirsiniz. + +Bir sonraki bölümde bir projeye katkıda bulunmanın ana örüntüleri hakkında daha fazla bilgi sahibi olacak ve farklı iş akışları oluşturmak için ana rollerini nasıl gerçekleştireceğiniz hakkında daha belirgin örnekler göreceksiniz. From 976f65b308d6793727fd2d51dd371731f2807558 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 8 Feb 2024 11:21:38 +0100 Subject: [PATCH 049/210] Update contributing.asc translate up to line:322 --- .../sections/contributing.asc | 272 +++++++++--------- 1 file changed, 134 insertions(+), 138 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 56a13aa2..57371c53 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,116 +1,111 @@ [[_contributing_project]] -=== Contributing to a Project +=== Projenin Gelişimine Katkıda Bulunmak (((contributing))) -The main difficulty with describing how to contribute to a project are the numerous variations on how to do that. -Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute -- every project is a bit different. -Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method. - -The first variable is active contributor count -- how many users are actively contributing code to this project, and how often? -In many instances, you'll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects. -For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day. -This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged. -Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. -How can you keep your code consistently up to date and your commits valid? - -The next variable is the workflow in use for the project. -Is it centralized, with each developer having equal write access to the main codeline? -Does the project have a maintainer or integration manager who checks all the patches? -Are all the patches peer-reviewed and approved? -Are you involved in that process? -Is a lieutenant system in place, and do you have to submit your work to them first? - -The next variable is your commit access. -The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't. -If you don't have write access, how does the project prefer to accept contributed work? -Does it even have a policy? -How much work are you contributing at a time? -How often do you contribute? - -All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. -We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples. +Proje gelişimine katkında bulunmayı tanımlamanın temel zorluğu, bunu yapmanın birçok farklı yolunun olmasıdır. +Git çok esnek olduğundan, insanlar birçok farklı şekilde birlikte çalışabilirler ve her proje birbirinden farklı olduğu için, size projenin gelişiminde nasıl rol almanız gerektiğini dikte etmek yanlış olur. +Aktif katkıcı sayısı, seçilen iş akışı, sizin işlenen katkılara erişiminiz ve muhtemel dış katkı yöntemi gibi bazı değişkenler bu süreci etkiler. + +İlk değişken aktif katkıcı sayısıdır: bu projeye kaç aktif katkıcı, ne sıklıkta, kod katkısında bulunuyor? +Çoğu zaman, günde birkaç katkı işleyen, iki veya üç geliştirici olabilir hatta bazı durağan projeler için daha azdır. +Daha büyük şirketler veya projeler için, binlerce geliştirici olabilir ve her gün yüzlerce veya binlerce katkı işlenebilir. +Katkıda bulunan geliştirici sayısı arttıkça, kodunuzun temiz şekilde uygulanması veya kolayca birleştirilebilmesi konusunda daha fazla sorunla karşılaşırsınız. +Gönderdiğiniz değişiklikler, siz çalışırken veya değişiklikleriniz onaylanmayı ve uygulanmayı beklerken, birleştirilen çalışmalar nedeniyle artık uyumsuz hale gelebilir veya ciddi şekilde bozulabilir. + +Sonraki değişken: projenin kullandığı iş akışıdır. +Her geliştiricinin ana kod satırına eşit yazma erişimine sahip olduğu iş akışı, merkezi mi yoksa dağıtık mıdır? +Projede, tüm yamaları kontrol eden bir bakım veya birleştirme yöneticisi var mı? +Tüm yamalar gözden geçirilip ve onaylanıyor mu? +Bu süreçte yer alıyor musunuz? +Diktatör-yaver sistemi var mı ve çalışmanızı önce onlara sunmanız mı gerekiyor? + +Tüm bu sorular, bir projeye nasıl etkili bir şekilde katkıda bulunacağınızı ve sizin için tercih edilen veya uygulanabilir olan iş akışlarının neler olduğunu etkileyebilir. +Bu soruların bazı yönlerini, basitten daha karmaşığa doğru bir dizi kullanım durumuyla ele alacağız. +Bu örneklerden yola çıkarak, ihtiyacınız olan belirli iş akışlarını oluşturabileceğinizi umuyoruz. [[_commit_guidelines]] -==== Commit Guidelines +==== Katkı Rehberi -Before we start looking at the specific use cases, here's a quick note about commit messages. -Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. -The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches -- you can read it in the Git source code in the `Documentation/SubmittingPatches` file. +Özel kullanım durumlarını incelemeye başlamadan önce, katkı mesajları hakkında kısa bir not verelim. +Katkı oluşturmak için iyi bir kılavuza sahip olmak ve ona uygun davranmak, Git ile çalışmayı ve başkalarıyla işbirliği yapmayı çok daha kolay hale getirir. +Git projesi, yama göndermek amacıyla nasıl iyi bir katkı oluşturacağınız hakkında kullanışlı ipuçları sunan kullanışlı bir belgeye sahiptir. +Onu Git kaynak kodunda `Documentation/SubmittingPatches` dosyasında bulabilirsiniz. (((git commands, diff, check))) -First, your submissions should not contain any whitespace errors. -Git provides an easy way to check for this -- before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. +Öncelikle, gönderilerinizde boşluk (whitespace) hataları olmamalıdır. +Git, bunu kontrol etmek için kolay bir yol sağlar: Git'in olası boşluk hataların tanımlayıp size listelemesi için, katkılamadan önce `git diff --check` komutunu çalıştırın. -.Output of `git diff --check`. -image::images/git-diff-check.png[Output of `git diff --check`.] +.`git diff --check` çıktısı. +image::images/git-diff-check.png[`git diff --check` çıktısı.] -If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. +Eğer bunu katkılamadan önce çalıştırırsanız, diğer geliştiricileri rahatsız edebilecek boşluk sorunlarını katkılamak üzere olduğunuzu görebilirsiniz. -Next, try to make each commit a logically separate changeset. -If you can, try to make your changes digestible -- don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. -Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. -If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <>). -The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes. +Sonraki adım, her bir katkıyı mantıksal olarak ayrı bir değişim seti olarak ayarlamaktır. +Mümkünse, değişikliklerinizi sindirilebilir hale getirmeye çalışın: bütün hafta sonu beş farklı sorun üzerinde kod yazıp, Pazartesi günü hepsini tek bir devasa katkı olarak göndermeyin. +Hafta sonu boyunca hiç katkı işlemeseniz bile, pazartesi günü çalışmanızı her soruna (iş paketine) -faydalı bir katkı mesajı da içeren- en az bir katkı olacak şekilde ayırın. +Değişikliklerden bazıları aynı dosyayı değiştiriyorsa, dosyaları kısmen aşamalandırmak için `git add --patch` kullanmaya çalışın (<> bölümünde detaylı olarak ele alınmıştır). +Tüm değişiklikler bir şekilde eklendikten sonra, ister tek katkıda işleyin ister beş, dalın ucu üzerinde yer alan nihai proje pozu aynıdır. +Bu yüzden değişikliklerinizi inceleyen diğer geliştiricilerin işlerini kolaylaştırmaya çalışın. -This approach also makes it easier to pull out or revert one of the changesets if you need to later. -<> describes a number of useful Git tricks for rewriting history and interactively staging files -- use these tools to help craft a clean and understandable history before sending the work to someone else. +Bu yaklaşım, daha sonra bir değişiklik setini çıkarmak veya geri almak istediğinizde de işleriniz büyük ölçüde kolaylaştırır. +<> bölümünde geçmişi değiştirme ve dosyaları etkileşimli olarak aşamalamayla ilgili birçok faydalı ipucu bulabilirsiniz. +Bu araçları kullanarak, çalışmanızı başka birine göndermeden önce, temiz ve anlaşılabilir bir katkı geçmişi oluşturmaya yardımcı olun. -The last thing to keep in mind is the commit message. -Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. -As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. -The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow. -Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." -Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]: +Akılda tutulması gereken son şey ise katkı mesajıdır. +Kaliteli bir katkı mesajı oluşturma alışkanlığı, Git'i kullanmayı ve işbirliği yapmayı çok daha kolay hale getirir. +Genel bir kural olarak mesajlarınız: 50 karakteri geçmeyecek şekilde, değişiklik setini özetleyen tek bir satırla başlamalı ve bir satır boşluk bıraktıktan sonra daha ayrıntılı bir açıklama içermelidir. +Ayrıntılı açıklamada: değişikliğinizi neden yaptığınızı, ve uygulamanızın önceki davranışla nasıl farklılıklar içerdiğini açıklamanız gerekir. +Bu takip edebileceğiniz sağlam bir yönergedir. +Katkı mesajınızı emir kipiyle yazın: "Hata düzeltildi" veya "Düzeltilmiş Hata" yerine "Hata düzelt" gibi. +Tim Pope tarafından yazılan https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[şablonu] inceleyebilirsiniz: [source,text] ---- -Capitalized, short (50 chars or less) summary +Büyük harfle başlayan, kısa (50 karakterden az) özet -More detailed explanatory text, if necessary. Wrap it to about 72 -characters or so. In some contexts, the first line is treated as the -subject of an email and the rest of the text as the body. The blank -line separating the summary from the body is critical (unless you omit -the body entirely); tools like rebase can get confused if you run the -two together. +Gerekirse, daha detaylı açıklayıcı metin. +Yaklaşık 72 civarı karakterle anlatın. +Bazı bağlamlarda, ilk satır aynı bir e-postadaki konu kısmı ve geri kalan kısım da mesaj gövdesi gibi kabul edilir. +Özet ile detay arasındaki boş satır (açıklamayı tamamen atlamazsanız) kritik önemdedir. +Eğer ikisini birleştirirseniz "rebase" gibi araçlar karışıklık yaşayabilir. -Write your commit message in the imperative: "Fix bug" and not "Fixed bug" -or "Fixes bug." This convention matches up with commit messages generated -by commands like git merge and git revert. +Katkı mesajınızı emir kipiyle yazın: "Hata düzeltildi" veya "Hatayı önlüyor" yerine "Hataları düzelt" gibi ifadeler kullanın. +Bu kural, `git merge` ve `git revert` gibi komutlarla oluşturulan katkı mesajlarıyla eşleşir. -Further paragraphs come after blank lines. +Daha ileri açıklamalar boş satırlardan sonra gelir. -- Bullet points are okay, too +- Madde işaretleri (-, *, vb) uygundur -- Typically a hyphen or asterisk is used for the bullet, followed by a - single space, with blank lines in between, but conventions vary here +- Genellikle madde işareti olarak tire (-) veya yıldız (*) kullanılır, ardından tek bir boşluk bırakılır ve maddeler arasında boş satırlar bulunur. (Bu kısımda anlatılan kurallar ortak görüşe göre değişebilir.) -- Use a hanging indent +- Aynı maddede ikinci satıra geçerken bir girinti kullanılır. ---- -If all your commit messages follow this model, things will be much easier for you and the developers with whom you collaborate. -The Git project has well-formatted commit messages -- try running `git log --no-merges` there to see what a nicely-formatted project-commit history looks like. +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). -[NOTE] -.Do as we say, not as we do. +[NOT] +.Dediğimizi yap, yaptığımızı değil! ==== -For the sake of brevity, many of the examples in this book don't have nicely-formatted commit messages like this; instead, we simply use the `-m` option to `git commit`. +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. -In short, do as we say, not as we do. +Yani: dediğimi yapın, yaptığımı yapmayın! ==== [[_private_team]] -==== Private Small Team +==== Küçük Özel Takımlar (((contributing, private small team))) -The simplest setup you're likely to encounter is a private project with one or two other developers. -``Private,'' in this context, means closed-source -- not accessible to the outside world. -You and the other developers all have push access to the repository. +Muhtemelen karşılaşacağınız en basit kurulum, birkaç geliştiriciyle yapacağınız özel bir projedir. +Bu bağlamda "özel", kapalı kaynaklı anlamına gelir, yani dış dünyadan erişilemez. +Siz ve diğer geliştiricilerin hepsi repoya itme erişimine sahipsiniz. -In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. -You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time. -Let's see what it might look like when two developers start to work together with a shared repository. -The first developer, John, clones the repository, makes a change, and commits locally. -(The protocol messages have been replaced with `...` in these examples to shorten them somewhat.) +Bu geliştirme ortamında, Subversion veya başka bir merkezi sistem kullandığınızdaki gibi bir iş akışı takip edebilirsiniz. +Çevrimdışı katkı işleme ve çok daha basit dallandırma ve birleştirme gibi avantajlara sahip olursunuz, ancak iş akışı yine de çok benzerdir. +Temel fark, birleştirmelerin sunucu üzerinde ve katkı anında olması yerine, istemci tarafında gerçekleşmesidir. +İki geliştiricinin paylaşılan bir repoda birlikte çalışmaya başladığı durumun nasıl görüneceğine bakalım. +İlk geliştirici, John, repoyu kopyalar, bir değişiklik yapar ve yerel olarak katkı işler. +(Örnekleri kısaltmak için, protokol mesajları `...` şeklinde yazılmıştır.) [source,console] ---- @@ -125,7 +120,7 @@ $ git commit -am 'remove invalid default value' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -The second developer, Jessica, does the same thing -- clones the repository and commits a change: +İkinci geliştirici, Jessica, aynı şeyi yapar: repoyu koypalar ve bir değişiklik katkılar: [source,console] ---- @@ -140,7 +135,7 @@ $ git commit -am 'add reset task' 1 files changed, 1 insertions(+), 0 deletions(-) ---- -Now, Jessica pushes her work to the server, which works just fine: +Şimdi Jessica çalışmasını sorunsuz bir şekilde sunucuya gönderiyor: [source,console] ---- @@ -151,12 +146,12 @@ To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master ---- -The last line of the output above shows a useful return message from the push operation. -The basic format is `.. fromref -> toref`, where `oldref` means the old reference, `newref` means the new reference, `fromref` is the name of the local reference being pushed, and `toref` is the name of the remote reference being updated. -You'll see similar output like this below in the discussions, so having a basic idea of the meaning will help in understanding the various states of the repositories. -More details are available in the documentation for https://git-scm.com/docs/git-push[git-push]. +Yukarıdaki çıktının son satırı, itme işlemi ardından yararlı bir dönüş mesajı gösterir. +Temel format, `.. fromref -> toref` şeklindedir, burada `oldref` eski referansı, `newref` yeni referansı, `fromref` gönderilen yerel referansın adını ve `toref` güncellenen uzak referansın adını ifade eder. +İleride de benzer çıktılar göreceğiniz için, bu mevzuda temel kavrayışınızın olması, repoların çeşitli durumlarını anlamanıza yardımcı olacaktır. +https://git-scm.com/docs/git-push[git-itme] linkinde daha fazla ayrıntı bulunmaktadır. -Continuing with this example, shortly afterwards, John makes some changes, commits them to his local repository, and tries to push them to the same server: +Örneğimize devam edersek, bir süre sonra John bazı değişiklikler yapar, bunları yerel reposuna kaydeder ve aynı sunucuya göndermeye çalışır: [source,console] ---- @@ -167,12 +162,12 @@ To john@githost:simplegit.git error: failed to push some refs to 'john@githost:simplegit.git' ---- -In this case, John's push fails because of Jessica's earlier push of _her_ changes. -This is especially important to understand if you're used to Subversion, because you'll notice that the two developers didn't edit the same file. -Although Subversion automatically does such a merge on the server if different files are edited, with Git, you must _first_ merge the commits locally. -In other words, John must first fetch Jessica's upstream changes and merge them into his local repository before he will be allowed to push. +Bu durumda, John'un gönderimi, Jessica'nın _kendi_ değişikliklerini önceden göndermesinden dolayı başarısız olur. +Eğer Subversion kullanıyorsanız bu özellikle önemlidir, çünkü iki geliştiricinin aynı dosyayı düzenlemediğini fark edeceksiniz. +Subversion'da farklı dosyalar düzenlenirse sunucu otomatik olarak böyle bir birleştirme yapar, ancak Git'te _öncelikle_ geliştiricilerin yerel olarak birleştirme yapmaları gerekir. +Yani, John'un önce Jessica'nın yukarı akış (upstream) değişikliklerini alıp bunları yerel reposuna birleştirmesi gerekmektedir. -As a first step, John fetches Jessica's work (this only _fetches_ Jessica's upstream work, it does not yet merge it into John's work): +İlk adım olarak, John Jessica'nın çalışmasını alır (`fetch` sadece Jessica'nın yukarı akış çalışmasını alır, henüz John'un çalışmasına birleştirmez): [source,console] ---- @@ -182,12 +177,12 @@ From john@githost:simplegit + 049d078...fbff5bc master -> origin/master ---- -At this point, John's local repository looks something like this: +Bu noktada, John'un yerel reposu şuna benzer: -.John's divergent history. -image::images/small-team-1.png[John's divergent history.] +.John'un ayrık geçmişi. +image::images/small-team-1.png[John'un ayrık geçmişi.] -Now John can merge Jessica's work that he fetched into his own local work: +Şimdi John, çektiği Jessica'nın çalışmasını kendi yerel çalışmasına birleştirebilir: [source,console] ---- @@ -197,12 +192,12 @@ Merge made by the 'recursive' strategy. 1 files changed, 1 insertions(+), 0 deletions(-) ---- -As long as that local merge goes smoothly, John's updated history will now look like this: +Eğer bu yerel birleştirme sorunsuz bir şekilde gerçekleşirse, John'ın güncellenmiş geçmişi artık şöyle görünecektir: -.John's repository after merging `origin/master`. -image::images/small-team-2.png[John's repository after merging `origin/master`.] +.`origin/master`'a birleştirme sonrası John'un reposu. +image::images/small-team-2.png[`origin/master`'a birleştirme sonrası John'un reposu.] -At this point, John might want to test this new code to make sure none of Jessica's work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server: +Bu noktada, Jessica'nın çalışmalarının kendisininkini etkilemediğinden emin olmak için, John bu yeni kodu test etmek isteyebilir ve her şeyin yolundaysa, sonunda birleştirilmiş yeni çalışmasını sunucuya itebilir: [source,console] ---- @@ -212,18 +207,18 @@ To john@githost:simplegit.git fbff5bc..72bbc59 master -> master ---- -In the end, John's commit history will look like this: +Sonuçta, John'ın katkı geçmişi şöyle görünecektir: -.John's history after pushing to the `origin` server. -image::images/small-team-3.png[John's history after pushing to the `origin` server.] +.`origin` sunucusuna ittikten sonra John'un katkı geçmişi. +image::images/small-team-3.png[`origin` sunucusuna ittikten sonra John'un katkı geçmişi.] -In the meantime, Jessica has created a new topic branch called `issue54`, and made three commits to that branch. -She hasn't fetched John's changes yet, so her commit history looks like this: +Bu arada, Jessica `issue54` adında yeni bir tematik dal oluşturdu ve bu dala üç katkı işledi. +Henüz John'un değişikliklerini çekmediği için, katkı geçmişi şöyle görünüyor: -.Jessica's topic branch. -image::images/small-team-4.png[Jessica's topic branch.] +.Jessica'nın tematik dalı. +image::images/small-team-4.png[Jessica'nın tematik dalı.] -Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with: +Jessica birden John'ın sunucuya yeni bir değişiklik ittiğini öğrenir ve ona bir göz atmak ister: böylece henüz sahip olmadığı tüm yeni içerikleri sunucudan alabilecektir: [source,console] ---- @@ -234,14 +229,15 @@ From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ---- -That pulls down the work John has pushed up in the meantime. -Jessica's history now looks like this: +Bu komutla, John'ın en son yüklediği çalışmayı indirir. +Jessica'nın geçmişi şimdi şöyle görünmektedir: + -.Jessica's history after fetching John's changes. -image::images/small-team-5.png[Jessica's history after fetching John's changes.] +.John'un değişikliklerini yakaladıktan sonra Jessica'nın geçmişi. +image::images/small-team-5.png[John'un değişikliklerini yakaladıktan sonra Jessica'nın geçmişi.] -Jessica thinks her topic branch is ready, but she wants to know what part of John's fetched work she has to merge into her work so that she can push. -She runs `git log` to find out: +Jessica tematik dalının hazır olduğunu düşünüyor, ancak itme yapabilmek için, John'dan aldığı hangi bölümü kendi çalışmasına birleştirmesi gerektiğini öğrenmek istiyor. +Bunu öğrenmek için `git log` komutunu çalıştırır: [source,console] ---- @@ -253,15 +249,15 @@ Date: Fri May 29 16:01:27 2009 -0700 remove invalid default value ---- -The `issue54..origin/master` syntax is a log filter that asks Git to display only those commits that are on the latter branch (in this case `origin/master`) that are not on the first branch (in this case `issue54`). -We'll go over this syntax in detail in <>. +`issue54..origin/master` sözdizimi, Git'e sadece ikinci dalda (`origin/master`) bulunan ve ilk dalda (`issue54`) bulunmayan katkıları göstermesini isteyen bir günlük (log kaydı) süzgecidir. +Bu sözdizimini <> bölümünde detaylı olarak ele alacağız. -From the above output, we can see that there is a single commit that John has made that Jessica has not merged into her local work. -If she merges `origin/master`, that is the single commit that will modify her local work. +Yukarıdaki çıktıdan, John'un işlediği ama Jessica'nın yerel çalışmasına birleştirmediği tek bir katkı olduğunu görebiliriz. +Eğer Jessica `origin/master`'a birleştirirse, bu onun yerel çalışmasını değiştirecek olan tek katkı olacaktır. -Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again. +Jessica artık tematik çalışmasını ana dalına birleştirip, John'un çalışmasını (`origin/master`) da ana dalına birleştirdikten sonra tekrar sunucuya gönderebilir. -First (having committed all of the work on her `issue54` topic branch), Jessica switches back to her master branch in preparation for integrating all this work: +Jessica `issue54` tematik dalındaki tüm çalışmalarını katkıladıktan sonra, bütün bu çalışmaları birleştirmek için ana dalına (master) geçiş yapar: [source,console] ---- @@ -270,9 +266,9 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica can merge either `origin/master` or `issue54` first -- they're both upstream, so the order doesn't matter. -The end snapshot should be identical no matter which order she chooses; only the history will be different. -She chooses to merge the `issue54` branch first: +Jessica önce `origin/master` veya `issue54`'ü birleştirebilir: ikisi de üst akımda olduğu için sıra önemli değildir. +Hangi sırayı seçerse seçsin, son poz aynı olmalıdır (sadece tarih farklı olacaktır). +Jessica, önce `issue54` dalını birleştirmeyi tercih eder: [source,console] ---- @@ -284,8 +280,8 @@ Fast forward 2 files changed, 6 insertions(+), 1 deletions(-) ---- -No problems occur; as you can see it was a simple fast-forward merge. -Jessica now completes the local merging process by merging John's earlier fetched work that is sitting in the `origin/master` branch: +Herhangi bir sorun yoktur ve gördüğünüz gibi, bu normal bir "ileri sarma" birleştirmesidir. +Jessica şimdi John'ın önceden alınmış ve `origin/master` dalında beklemekte olan çalışmasını birleştirme sürecini tamamlar: [source,console] ---- @@ -296,12 +292,12 @@ Merge made by the 'recursive' strategy. 1 files changed, 1 insertions(+), 1 deletions(-) ---- -Everything merges cleanly, and Jessica's history now looks like this: +Her şey temiz bir şekilde birleştirildi ve Jessica'nın geçmişi şimdi şöyle görünüyor: -.Jessica's history after merging John's changes. -image::images/small-team-6.png[Jessica's history after merging John's changes.] +.John'un değişikliklerini birleştirdikten sonra Jessica'nın geçmişi. +image::images/small-team-6.png[John'un değişikliklerini birleştirdikten sonra Jessica'nın geçmişi.] -Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed even more changes in the meantime): +Artık `origin/master` Jessica'nın `master` dalından erişilebilir durumda olduğuna göre Jessica değişikliklerini itebilir durumda olmalı (tabi John bu arada daha fazla değişiklik yapıp itmemişse): [source,console] ---- @@ -311,18 +307,18 @@ To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ---- -Each developer has committed a few times and merged each other's work successfully. +Her geliştirici birkaç kez katkı işlemiş ve birbirlerinin çalışmasını başarılı bir şekilde birleştirmiştir. -.Jessica's history after pushing all changes back to the server. -image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] +.Tüm değişiklikleri sunucuya geri iten Jessica'nın geçmişi. +image::images/small-team-7.png[Tüm değişiklikleri sunucuya geri iten Jessica'nın geçmişi.] -That is one of the simplest workflows. -You work for a while (generally in a topic branch), and merge that work into your `master` branch when it's ready to be integrated. -When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server. -The general sequence is something like this: +Bu, en basit iş akışlarından biridir. +Bir süre çalışırsınız (genellikle bir tematik dalda) ve calışmanız birleştirilmeye hazır olduğunda bunu `master` dalınıza birleştirirsiniz. +Bu çalışmayı paylaşmak isterseniz, yeni bir değişiklik varsa `master` dalınızı `origin/master` üzerinden çekip (fetch) birleştirirsiniz (merge) ve son olarak sunucudaki `master` dala itersiniz. +Bu işlem genellikle şöyle olur: -.General sequence of events for a simple multiple-developer Git workflow. -image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] +.Basit bir çok geliştiricili Git iş akışı için genel olaylar dizisi. +image::images/small-team-flow.png[Basit bir çok geliştiricili Git iş akışı için genel olaylar dizisi.] ==== Private Managed Team From a4c4f233a2e0fca0a523a550229838953aaa58b4 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 8 Feb 2024 11:28:56 +0100 Subject: [PATCH 050/210] Update generating-ssh-key.asc fix typos --- book/04-git-server/sections/generating-ssh-key.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 2ff2c233..b836fa0f 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -3,7 +3,7 @@ (((SSH keys))) Birçok Git sunucusu, kullanıcı kimliklerini SSH ortak anahtarları ile doğrular. -Bir ortak anahtar elde etmek için, sistemdeki ortak anahtarı olmaya her kullanıcının bir tane oluşturması gerekir. +Bir ortak anahtar elde etmek için, sistemdeki ortak anahtarı olmayan her kullanıcının bir tane oluşturması gerekir. Bu süreç tüm işletim sistemlerinde benzerdir. İlk olarak, zaten bir anahtarınızın olup olmadığını kontrol etmelisiniz. Varsayılan olarak, bir kullanıcının SSH anahtarları, kullanıcının `~/.ssh` dizininde depolanır. @@ -35,7 +35,7 @@ The key fingerprint is: d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local ---- -İlk olarak, anahtarın nereye kaydedileceğini onaylanır (`.ssh/id_rsa`), ardından iki kez bir parola sorar (eğer anahtarı kullanırken bir şifre girmek istemiyorsanız, boş bırakabilirsiniz). +İlk olarak, anahtarın nereye kaydedileceğini onaylar (`.ssh/id_rsa`), ardından iki kez bir parola sorar (eğer anahtarı kullanırken bir şifre girmek istemiyorsanız, boş bırakabilirsiniz). Ancak, bir parola kullanıyorsanız, parola kırma saldırılarına karşı daha dirençli olan bir formatta özel anahtarı kaydetmek için `-o` seçeneğini eklediğinizden emin olun (varsayılan formattan daha güvenlidir). Ayrıca, her seferinde parolayı girmekten kaçınmak için `ssh-agent` aracını da kullanabilirsiniz. From 922b0266eda1c58dc5dd948187201a2c1cebd843 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 8 Feb 2024 11:32:07 +0100 Subject: [PATCH 051/210] Update gitlab.asc fix typos --- book/04-git-server/sections/gitlab.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 77cb76c3..42d22eb4 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -73,8 +73,8 @@ Proje bir kullanıcıya aitse, projenin sahibi projeye kimin erişebileceğini d Eğer proje bir gruba aitse, grup düzeyindeki kullanıcı izinleri de etkili olacaktır. Her proje ayrıca bir görünürlük seviyesine sahiptir, bu da projenin sayfalarına ve reposuna kimlerin okuma erişimine sahip olduğunu denetler. -Bir proje _private_ (özel) ise, proje sahibi belirli kullanıcılara erişimi açıkça vermelidir. -_internal_ (iç) bir proje sadece oturum açmış her kullanıcı tarafından görülebilir, _public_ (herkese açık) bir proje ise herkese görünür. +Bir proje _Private_ (özel) ise, proje sahibi belirli kullanıcılara erişimi açıkça vermelidir. +_Internal_ (iç) bir proje sadece oturum açmış her kullanıcı tarafından görülebilir, _Public_ (herkese açık) bir proje ise herkese görünür. Unutmayın ki, bu hem `git fetch` erişimini hem de o projenin web arayüzüne erişimi kontrol eder. ===== Kancalar (Hooks) From ddbde3ed98c51ba204ecd34e3319a5e5b70ff692 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 8 Feb 2024 11:51:01 +0100 Subject: [PATCH 052/210] Update generating-ssh-key.asc --- book/04-git-server/sections/generating-ssh-key.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index b836fa0f..477eec76 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -3,7 +3,7 @@ (((SSH keys))) Birçok Git sunucusu, kullanıcı kimliklerini SSH ortak anahtarları ile doğrular. -Bir ortak anahtar elde etmek için, sistemdeki ortak anahtarı olmayan her kullanıcının bir tane oluşturması gerekir. +Bir ortak anahtar elde etmek için, sistemdeki ortak anahtarı olmayan her kullanıcının, bir adet oluşturması gerekir. Bu süreç tüm işletim sistemlerinde benzerdir. İlk olarak, zaten bir anahtarınızın olup olmadığını kontrol etmelisiniz. Varsayılan olarak, bir kullanıcının SSH anahtarları, kullanıcının `~/.ssh` dizininde depolanır. From 624e3160f341c7c98c66da4b0a361ca118ced480 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 9 Feb 2024 09:03:53 +0100 Subject: [PATCH 053/210] Update contributing.asc line:416 --- .../sections/contributing.asc | 60 ++++++++++--------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 57371c53..4fb368b0 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,9 +1,9 @@ [[_contributing_project]] -=== Projenin Gelişimine Katkıda Bulunmak +=== Projenin Gelişiminde Rol Almak (((contributing))) -Proje gelişimine katkında bulunmayı tanımlamanın temel zorluğu, bunu yapmanın birçok farklı yolunun olmasıdır. -Git çok esnek olduğundan, insanlar birçok farklı şekilde birlikte çalışabilirler ve her proje birbirinden farklı olduğu için, size projenin gelişiminde nasıl rol almanız gerektiğini dikte etmek yanlış olur. +Proje gelişiminde alınabilecek rolleri tanımlamanın temel zorluğu, bunu yapmanın birçok farklı yolunun olmasıdır. +Git çok esnek olduğundan, insanlar bir proje üzerinde birçok farklı şekilde birlikte çalışabilirler ve her proje birbirinden farklı olduğu için, size projenin gelişiminde nasıl rol almanız gerektiğini dikte etmek yanlış olur. Aktif katkıcı sayısı, seçilen iş akışı, sizin işlenen katkılara erişiminiz ve muhtemel dış katkı yöntemi gibi bazı değişkenler bu süreci etkiler. İlk değişken aktif katkıcı sayısıdır: bu projeye kaç aktif katkıcı, ne sıklıkta, kod katkısında bulunuyor? @@ -93,10 +93,10 @@ Yani: dediğimi yapın, yaptığımı yapmayın! ==== [[_private_team]] -==== Küçük Özel Takımlar +==== Küçük Özel Ekipler (((contributing, private small team))) -Muhtemelen karşılaşacağınız en basit kurulum, birkaç geliştiriciyle yapacağınız özel bir projedir. +Muhtemelen karşılaşacağınız en basit kurulum, sadece birkaç geliştiriciyle yapacağınız özel bir projedir. Bu bağlamda "özel", kapalı kaynaklı anlamına gelir, yani dış dünyadan erişilemez. Siz ve diğer geliştiricilerin hepsi repoya itme erişimine sahipsiniz. @@ -320,19 +320,21 @@ Bu işlem genellikle şöyle olur: .Basit bir çok geliştiricili Git iş akışı için genel olaylar dizisi. image::images/small-team-flow.png[Basit bir çok geliştiricili Git iş akışı için genel olaylar dizisi.] -==== Private Managed Team +==== Özel Yönetilen Ekipler (((contributing, private managed team))) -In this next scenario, you'll look at contributor roles in a larger private group. -You'll learn how to work in an environment where small groups collaborate on features, after which those team-based contributions are integrated by another party. +Sıradaki senaryoda, daha büyük bir özel grupta projede yer alanların rollerini inceleyeceğiz. +Küçük ekiplerden her birinin, büyük bir projenin sadece bir kısmı (mesela bir uygulamanın tek bir özelliği) üzerinde işbirliği yaptığı ve sonra bu ekip bazlı çalışmaların üçüncü bir tarafça birleştirildiği ortamlarda nasıl çalışacağınızı öğreneceksiniz. -Let's say that John and Jessica are working together on one feature (call this ``featureA''), while Jessica and a third developer, Josie, are working on a second (say, ``featureB''). -In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. -In this scenario, all work is done in team-based branches and pulled together by the integrators later. +Diyelim ki John ve Jessica bir özellik (bunu `featureA` olarak adlandıralım) üzerinde birlikte çalışırken, Jessica aynı zamanda Josie adındaki üçüncü bir geliştirici ile birlikte, ikinci bir özellik (bu da `featureB` olsun) üzerinde de çalışıyor. +Bu senaryoda şirket, birim ekiplerce geliştirilen çalışmaların sadece belirli bazı mühendisler tarafından birleştirilebildiği bir birleşim-yöneticisi ağ akışı kullanıyor ve ana reponun `master` dalı sadece bu mühendisler tarafından güncellenebiliyor. +Burada, tüm çalışmalar ekip temelli dallarda yapılır ve daha sonra birleştiriciler tarafından bir araya getirilebilir. -Let's follow Jessica's workflow as she works on her two features, collaborating in parallel with two different developers in this environment. -Assuming she already has her repository cloned, she decides to work on `featureA` first. -She creates a new branch for the feature and does some work on it there: +Hadi her iki özellik üzerinde ve iki farklı geliştiriciyle eşzamanlı çalışırken Jessica'nın iş akışını takip edelim. +Varsayalım ki reposunu zaten kopyalamış ve ilk olarak `featureA` üzerinde çalışmaya karar vermiş olsun. +Özelliğe yeni bir dal oluşturur ve burada bazı çalışmalar yapar: + +Önce `featureA` için yeni bir dal oluşturur ve orada bazı çalışmalar yapar: [source,console] ---- @@ -345,8 +347,8 @@ $ git commit -am 'add limit to log function' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -At this point, she needs to share her work with John, so she pushes her `featureA` branch commits up to the server. -Jessica doesn't have push access to the `master` branch -- only the integrators do -- so she has to push to another branch in order to collaborate with John: +Bu noktada, çalışmalarını John ile paylaşması gerektiği için `featureA` dalındaki katkıların sunucuya iter. +Jessica'nın `master` dalına itme erişimi olmadığından (yalnızca birleştiricilerin yetkisi vardı), John ile işbirliği yapabilmek için çalışmalarını başka bir dala itmesi gerekiyor: [source,console] ---- @@ -356,9 +358,9 @@ To jessica@githost:simplegit.git * [new branch] featureA -> featureA ---- -Jessica emails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now. -While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie. -To begin, she starts a new feature branch, basing it off the server's `master` branch: +Jessica John'a: çalışmalarını `featureA` adında bir dalda ittiğini ve isterse bakabileceğini söylemek için bir e-posta gönderir. +Jessica John'dan geri bildirim beklerken, Josie ile `featureB` üzerinde çalışmasına başlamaya karar verir. +Başlamak için, sunucunun `master` dalından temel alarak (rebase) alarak tematik bir dal açar: [source,console] ---- @@ -368,7 +370,7 @@ $ git checkout -b featureB origin/master Switched to a new branch 'featureB' ---- -Now, Jessica makes a couple of commits on the `featureB` branch: +Ardından `featureB` dalında birkaç katkı işler: [source,console] ---- @@ -382,14 +384,13 @@ $ git commit -am 'add ls-files' 1 files changed, 5 insertions(+), 0 deletions(-) ---- -Jessica's repository now looks like this: +Jessica'nın reposu artık şöyle görünüyor: -.Jessica's initial commit history. -image::images/managed-team-1.png[Jessica's initial commit history.] +.Jessica'nın ilk katkı geçmişi. +image::images/managed-team-1.png[Jessica'nın ilk katkı geçmişi.] -She's ready to push her work, but gets an email from Josie that a branch with some initial ``featureB'' work on it was already pushed to the server as the `featureBee` branch. -Jessica needs to merge those changes with her own before she can push her work to the server. -Jessica first fetches Josie's changes with `git fetch`: +Jessica çalışmasını itmeye hazırdır, ancak Josie'den, içinde öncel `featureB` çalışmalarını barındıran `featureBee` adında bir dalın, daha önceden sunucuya itilmiş olduğunu bildiren e-posta alır. +Jessica'nın kendi çalışmasını sunucuya göndermeden önce bu değişiklikleri kendi mevcut çalışmasıyla birleştirmesi gerekmektedir. Jessica önce Josie'nin değişikliklerini `git fetch` komutu kullanarak getirir: [source,console] ---- @@ -399,7 +400,7 @@ From jessica@githost:simplegit * [new branch] featureBee -> origin/featureBee ---- -Assuming Jessica is still on her checked-out `featureB` branch, she can now merge Josie's work into that branch with `git merge`: +Jessica'nın halen `featureB` dalında olduğunu varsayarsak, Josie'nin çalışmasını bu dal ile `git merge` kullanarak hemen birleştirebilir: [source,console] ---- @@ -410,8 +411,9 @@ Merge made by the 'recursive' strategy. 1 files changed, 4 insertions(+), 0 deletions(-) ---- -At this point, Jessica wants to push all of this merged ``featureB'' work back to the server, but she doesn't want to simply push her own `featureB` branch. -Rather, since Josie has already started an upstream `featureBee` branch, Jessica wants to push to _that_ branch, which she does with: +Jessica şimdi bu birleştirilmiş "featureB" çalışmasını hepsini sunucuya geri itmeyi düşünüyor, ancak kendi `featureB` dalını doğrudan itmek istemiyor. +Josie zaten bir üst akım dalı olarak `featureBee`'yi başlattığı için, Jessica _onu_ itmek istiyor. +Bunu şöyle yapıyor: [source,console] ---- From 555a6e49f1fb0a8f6e95756d5dcc5e2eea752cd5 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 9 Feb 2024 10:50:17 +0100 Subject: [PATCH 054/210] Update contributing.asc Translate up to line:498 --- .../sections/contributing.asc | 47 ++++++++++--------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 4fb368b0..0bfdccf5 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -266,7 +266,7 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica önce `origin/master` veya `issue54`'ü birleştirebilir: ikisi de üst akımda olduğu için sıra önemli değildir. +Jessica önce `origin/master` veya `issue54`'ü birleştirebilir: ikisi de kökdalda olduğu için sıra önemli değildir. Hangi sırayı seçerse seçsin, son poz aynı olmalıdır (sadece tarih farklı olacaktır). Jessica, önce `issue54` dalını birleştirmeyi tercih eder: @@ -412,8 +412,8 @@ Merge made by the 'recursive' strategy. ---- Jessica şimdi bu birleştirilmiş "featureB" çalışmasını hepsini sunucuya geri itmeyi düşünüyor, ancak kendi `featureB` dalını doğrudan itmek istemiyor. -Josie zaten bir üst akım dalı olarak `featureBee`'yi başlattığı için, Jessica _onu_ itmek istiyor. -Bunu şöyle yapıyor: +Zaten Josie'nin bir kökdal olarak başlattığı `featureBee` mevcut olduğundan, Jessica _oraya_ itmek istiyor. +Ve bunu şöyle yapıyor: [source,console] ---- @@ -423,12 +423,12 @@ To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee ---- -This is called a _refspec_. -See <> for a more detailed discussion of Git refspecs and different things you can do with them. -Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later. +Bu, bir _refspec_ olarak adlandırılır. +Git refspec'lerin detaylı bir incelemesi ve onunla daha başka neler yapılacağını görmek için <> bağlantısına bakabilirsiniz. +Ayrıca `-u` bayrağına da dikkat edin: bu --set-upstream` ifadesinin kısaltmasıdır ve dalları daha kolay itme ve çekme işlemleri için yapılandırır. -Suddenly, Jessica gets email from John, who tells her he's pushed some changes to the `featureA` branch on which they are collaborating, and he asks Jessica to take a look at them. -Again, Jessica runs a simple `git fetch` to fetch _all_ new content from the server, including (of course) John's latest work: +Jessica ansızın John'dan, beraber çalıştıkları `featureA` dalında, bazı değişiklikler yaptığını belirten bir e-posta alır ve Jessica'dan bunlara bakmasını ister. +Jessica tekrardan John'un en son çalışmasını da içeren sunucudan _tüm_ yeni içeriği getirmek için basit bir `git fetch` komutu çalıştırır: [source,console] ---- @@ -438,7 +438,7 @@ From jessica@githost:simplegit 3300904..aad881d featureA -> origin/featureA ---- -Jessica can display the log of John's new work by comparing the content of the newly-fetched `featureA` branch with her local copy of the same branch: +Jessica, yeni alınan `featureA` dalının içeriğini kendi yerel kopyasıyla karşılaştırarak, John'un yeni çalışmasının günlüğünü görüntüleyebilir: [source,console] ---- @@ -450,7 +450,7 @@ Date: Fri May 29 19:57:33 2009 -0700 changed log output to 30 from 25 ---- -If Jessica likes what she sees, she can merge John's new work into her local `featureA` branch with: +Jessica gördüğü işi beğenir ve John'un yeni çalışmasını yerel `featureA` dalına birleştirmek ister: [source,console] ---- @@ -463,7 +463,8 @@ Fast forward 1 files changed, 9 insertions(+), 1 deletions(-) ---- -Finally, Jessica might want to make a couple minor changes to all that merged content, so she is free to make those changes, commit them to her local `featureA` branch, and push the end result back to the server. +Son olarak, Jessica muhtemelen tüm bu birleştirilen içeriğe birkaç küçük değişiklik eklemek isteyecektir. +Bu yüzden, gerekli değişiklikleri yapar, bunları yerel `featureA` dalına katkılar ve sonucu sunucuya geri iter. [source,console] ---- @@ -476,23 +477,23 @@ To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA ---- -Jessica's commit history now looks something like this: +Jessica'nın katkı geçmişi şöyle görünmektedir: -.Jessica's history after committing on a feature branch. -image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] +.feature dalına katkıladıktan sonra Jessica'nın geçmişi. +image::images/managed-team-2.png[feature dalına katkıladıktan sonra Jessica'nın geçmişi.] -At some point, Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. -After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: +Jessica, Josie ve John, birleşim yöneticilerine, `featureA` ve `featureBee` adlı dalların ana gövdeye birleştirilmeye hazır olduğunu bildirirler. +Bu dallar ana gövdeye birleştirildikten sonra yapılacak bir çekme işlemi, yeni birleştirme katkısın indirecek ve geçmiş şu şekilde görünecektir: -.Jessica's history after merging both her topic branches. -image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] +.Her iki tematik dalı birleştirdikten sonra Jessica'nın geçmişi. +image::images/managed-team-3.png[Her iki tematik dalı birleştirdikten sonra Jessica'nın geçmişi.] -Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. -The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. -The sequence for the workflow you saw here is something like this: +Birçok ekibin Git'e geçme sebebi, paralel işleyen farklı dallar üzerindeki eşzamanlı çalışmaları sürecin sonunda rahatça birleştirme yeteneğidir. +Bir takımın daha küçük alt gruplarının, tüm ekibi dâhil etmek veya engellemek zorunda kalmadan uzak dallar aracılığıyla işbirliği yapabilme yeteneği, Git'in büyük bir avantajıdır. +Burada gördüğünüz iş akışı bunu göstermektedir: -.Basic sequence of this managed-team workflow. -image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] +.Yönetilen ekip iş akışının temel sıralaması. +image::images/managed-team-flow.png[Yönetilen ekip iş akışının temel sıralaması.] [[_public_project]] ==== Forked Public Project From e05c2be4470b4e6cf12ecbfa29d45991fb34e0a9 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 9 Feb 2024 15:32:11 +0100 Subject: [PATCH 055/210] Update contributing.asc translate up to line:642 --- .../sections/contributing.asc | 93 ++++++++++--------- 1 file changed, 49 insertions(+), 44 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 0bfdccf5..20fbd57e 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -496,17 +496,18 @@ Burada gördüğünüz iş akışı bunu göstermektedir: image::images/managed-team-flow.png[Yönetilen ekip iş akışının temel sıralaması.] [[_public_project]] -==== Forked Public Project +==== Çatallanmış Açık Projeler (((contributing, public small project))) -Contributing to public projects is a bit different. -Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. -This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, repo.or.cz, and others), and many project maintainers expect this style of contribution. -The next section deals with projects that prefer to accept contributed patches via email. +Açık (açık kaynak kodlu) projelere katkı sağlamak biraz farklıdır. +Projedeki dalları doğrudan güncelleme izniniz olmadığı için, çalışmanızı yürütücülere (maintainer) başka bir şekilde ulaştırmalısınız. +Bu ilk örnek, çatal oluşturma imkanı sunan Git barındırma siteleri üzerinden katkı sağlama sürecini açıklar. +GitHub, BitBucket, repo.or.cz ve benzeri birçok barındırma sitesi (host) bunu destekler ve birçok proje yürütücüsü bu tarz bir katkı bekler. +Sonraki bölüm, katkı sağlanan yamaların e-posta aracılığıyla kabul edildiği projeleri ele alır. -First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there. -The sequence looks basically like this: +İlk olarak ana repoyu kopyalamanız gerekmektedir. +Ardından katkıda bulunmayı planladığınız yama veya yama dizisi için bir tematik dal oluşturacak ve çalışmanızı burada yapacaksınız. +Temel olarak bu sıralama şöyle görünür: [source,console] ---- @@ -519,25 +520,27 @@ $ git commit $ git commit ---- -[NOTE] +[NOT] ==== -You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review -- see <> for more information about interactive rebasing. +İşinizi tek katkı (commit) 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. ==== -When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project. -You then need to add this repository URL as a new remote of your local repository; in this example, let's call it `myfork`: +Daldaki çalışmanız bittiğinde ve bunu yürütücülere katkı olarak göndermeye hazır olduğunuzda, orijinal proje sayfasına gidin ve ``Fork''düğmesine tıklayarak, kendi yazılabilir çatalınızı oluşturun. +Ardından, bu repo URL'sini yerel reponuzun yeni bir uzak reposu olarak eklemelisiniz. +Hadi ona `myfork` adını verelim: [source,console] ---- $ git remote add myfork ---- -You then need to push your new work to this repository. -It's easiest to push the topic branch you're working on to your forked repository, rather than merging that work into your master branch and pushing that. -The reason is that if your work isn't accepted or is cherry-picked, you don't have to rewind your master branch (the Git `cherry-pick` operation is covered in more detail in <>). -If the maintainers `merge`, `rebase`, or `cherry-pick` your work, you'll eventually get it back via pulling from their repository anyhow. +Sonra, yeni çalışmanızı bu repoya göndermeniz gerekir. +Çalıştığınız tematik dalınızı çatallamış olduğunuz depoya göndermek, onu master dalınıza birleştirip ardından da itmekten daha kolaydır. +Bunun nedeni, çalışmanızın kabul edilmemesi veya ayıklanması (cherry-pick) durumunda ana dalınızı geri sarmanız gerekmemesidir (Git `cherry-pick` işlemi <> bölümünde daha ayrıntılı olarak ele alınmıştır). +Eğer yürütücüler çalışmanızı birleştirir (merge), temeller (rebase) veya ayıklarsa (cherry-pick), çalışmanızı onların reposundan çekerek alabilirsiniz. -In any event, you can push your work with: +Her durumda, çalışmanızı şu şekilde itebilirsiniz: [source,console] ---- @@ -545,11 +548,11 @@ $ git push -u myfork featureA ---- (((git commands, request-pull))) -Once your work has been pushed to your fork of the repository, you need to notify the maintainers of the original project that you have work you'd like them to merge. -This is often called a _pull request_, and you typically generate such a request either via the website -- GitHub has its own ``Pull Request'' mechanism that we'll go over in <> -- or you can run the `git request-pull` command and email the subsequent output to the project maintainer manually. +Çalışmanız reponun size ait çatalına itildikten sonra, orjinal projenin yürütücülerini çalışmanızı birleştirmelerini istediğinize dair bilgilendirmelisiniz. +Bu genellikle bir _çekme isteği_ (pull request) olarak adlandırılır ve genellikle web sitesi üzerinden oluşturulur (GitHub'ın kendi ``Çekme İsteği'' mekanizması vardır, bu konuyu <> bölümünde ele alacağız) ya da `git request-pull` komutunu çalıştırıp ardından üretilen çıktıyı proje yürütücüsüno manuel olarak e-posta yoluyla gönderebilirsiniz. -The `git request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and produces a summary of all the changes you're asking to be pulled. -For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed, she can run this: +`git request-pull` komutu, tematik dalınızı çekmek istediğiniz temel dalı ve çekilmesini istediğiniz Git deposunun URL'sini alır ve çekilecek tüm değişikliklerin bir özetini üretir. +Örneğin, Jessica'nın John'a bir çekme isteği göndermek istediğini ve yeni gönderdiği tema dalında iki değişiklik yaptığını varsayalım, bu durumda şunu çalıştırabilir: [source,console] ---- @@ -570,11 +573,11 @@ Jessica Smith (2): 1 files changed, 9 insertions(+), 1 deletions(-) ---- -This output can be sent to the maintainer -- it tells them where the work was branched from, summarizes the commits, and identifies from where the new work is to be pulled. +Katkıların özetini gösteren, çalışmanın nereden dallandığını ve yeni çalışmanın nereden çekileceğini belirten bu çıktı, yürütücüye gönderilebilir. -On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected. -Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly. -For example, if you want to submit a second topic of work to the project, don't continue working on the topic branch you just pushed up -- start over from the main repository's `master` branch: +Yürütücü olmadığınız bir projede, genellikle `origin/master`'ı izleyen `master` gibi bir dalın bulunması ve çalışmanızı, reddedilmesi durumunda kolayca silebileceğiniz, tematik dallar üzerinde yapmanız daha kolay olur. +İş paketlerinin tematik dallara -- kök daldan izole şekilde -- kısıtlanması, çalıştığınız süre zarfında ana repo ucunun ilerlemiş olması ve sizin katkılarınızın artık temiz bir şekilde uygulanamaması durumunda da işinizi yeniden düzenlemenizi kolaylaştırır. +Örneğin, projeye ikinci bir iş başlığı göndermek istiyorsanız, zaten yukarı itilmiş olan tematik dalda çalışmaya devam etmeyin; ana repo `master` dalından tekrar başlayın: [source,console] ---- @@ -587,13 +590,14 @@ $ git request-pull origin/master myfork $ git fetch origin ---- -Now, each of your topics is contained within a silo -- similar to a patch queue -- that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: +Artık her bir başlığımız, yama kuyruğunda (patch queue) olduğu gibi: yeniden yazabileceğiniz, temelleyebileceğiniz ve başka konu başlıklarından bağımsız ve birbirini etkilemeden değiştirebileceğiniz bir iş ambarı içinde bulunuyor. +Şunun gibi: -.Initial commit history with `featureB` work. -image::images/public-small-1.png[Initial commit history with `featureB` work.] +.`featureB` çalışmasının öncel katkı geçmişi. +image::images/public-small-1.png[`featureB` çalışmasının öncel katkı geçmişi.] -Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. -In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: +Diyelim ki, yürütücü birçok başka yamayı çekmiş ve sizin ilk dalınızı çekmeyi de denemiş, ancak artık temiz bir şekilde birleşmiyor. +Bu durumda, bu dalı `origin/master`'ın üzerine temellemeyi (rebase) deneyebilir ve yürütücü için çatışmaları çözüp, ardından değişikliklerinizi yeniden gönderebilirsiniz. [source,console] ---- @@ -602,18 +606,18 @@ $ git rebase origin/master $ git push -f myfork featureA ---- -This rewrites your history to now look like <>. +Bu, şimdi geçmişinizi <> gibi yeniden yazar. [[psp_b]] -.Commit history after `featureA` work. -image::images/public-small-2.png[Commit history after `featureA` work.] +.`featureA` çalışmasından sonra katkı geçmişi. +image::images/public-small-2.png[`featureA` çalışmasından sonra katkı geçmişi.] -Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. -An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`). +Dalı yeniden temellendirdiniz; bu yüzden sunucudaki `featureA` dalını, kendi soyundan gelmeyen bir katkıyla değiştirebilmek için itme (push) komutunuza `-f` bayrağı eklemelisiniz. +Başka bir alternatif ise, bu yeni çalışmayı sunucuda farklı (mesela `featureAv2` olarak adlandırılmış) bir dala itmektir. -Let's look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail. -You'll also take this opportunity to move the work to be based off the project's current `master` branch. -You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that as a new branch: +Bir başka olası senaryoya bir göz atalım: yürütücü ikinci dalınızdaki çalışmayı inceledi ve yaklaşımınızı beğendi, ancak uygulamadi bir detayı değiştirmenizi istiyor. +Bu fırsatı, çalışmanın projenin mevcut `master` dalına dayandırılmasını sağlamak için de kullanacaksınız. +Mevcut `origin/master` dalına dayanan yeni bir dal başlatırsınız; burada `featureB` değişikliklerini birleştirir, çatışmaları çözer, uygulama değişikliğini yapar ve ardından bunu yeni bir dal olarak itersiniz: (((git commands, merge, squash))) [source,console] @@ -625,14 +629,15 @@ $ git commit $ git push myfork featureBv2 ---- -The `--squash` option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit. -This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. -Also the `--no-commit` option can be useful to delay the merge commit in case of the default merge process. +`--squash` seçeneği birleştirilen dal üzerindeki tüm çalışmayı alır ve bunu bir birleştirme katkısı oluşturmadan - ama gerçek bir birleştirme gerçekleştiğinde oluşan bir repo durumu üretecek şekilde - bir değişiklik kümesine sıkıştırır. +Bunun anlamı, gelecekteki birleştirme katkınızın yalnızca bir önceli olmasıdır. +Ayrıca, diğer dalın tüm değişikliklerini tanıtmanıza ve ardından yeni bir katkı işlemine geçmeden önce daha fazla değişiklik yapmanıza izin verir +Ek olarak, varsayılan birleştirme işlemi durumunda, birleştirme katkısını geciktirmek için `--no-commit` seçeneğini kullanabilirsiniz. -At this point, you can notify the maintainer that you've made the requested changes, and that they can find those changes in your `featureBv2` branch. +Bu noktada, istenen değişiklikleri yaptığınızı ve bu değişikliklere `featureBv2` dalından ulaşabileceklerini proje yürütücüsüne bildirebilirsiniz. -.Commit history after `featureBv2` work. -image::images/public-small-3.png[Commit history after `featureBv2` work.] +.`featureBv2` çalışmasının ardından katkı geçmişi. +image::images/public-small-3.png[`featureBv2` çalışmasının ardından katkı geçmişi.] [[_project_over_email]] ==== Public Project over Email From 55206985bf8d4cc49f17da1de9dcfbcb4f118990 Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 08:50:30 +0100 Subject: [PATCH 056/210] Update contributing.asc fix typos --- book/05-distributed-git/sections/contributing.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 20fbd57e..ed9cd9c0 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -266,7 +266,7 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica önce `origin/master` veya `issue54`'ü birleştirebilir: ikisi de kökdalda olduğu için sıra önemli değildir. +Jessica önce `origin/master` veya `issue54`ü birleştirebilir: ikisi de kökdalda olduğu için sıra önemli değildir. Hangi sırayı seçerse seçsin, son poz aynı olmalıdır (sadece tarih farklı olacaktır). Jessica, önce `issue54` dalını birleştirmeyi tercih eder: @@ -526,7 +526,7 @@ $ git commit Etkileşimli temelleme (interactive rebasing) hakkında daha fazla bilgi için <> bölümüne bakabilirsiniz. ==== -Daldaki çalışmanız bittiğinde ve bunu yürütücülere katkı olarak göndermeye hazır olduğunuzda, orijinal proje sayfasına gidin ve ``Fork''düğmesine tıklayarak, kendi yazılabilir çatalınızı oluşturun. +Daldaki çalışmanız bittiğinde ve bunu yürütücülere katkı olarak göndermeye hazır olduğunuzda, orijinal proje sayfasına gidin ve "Fork" düğmesine tıklayarak, kendi yazılabilir çatalınızı oluşturun. Ardından, bu repo URL'sini yerel reponuzun yeni bir uzak reposu olarak eklemelisiniz. Hadi ona `myfork` adını verelim: @@ -549,7 +549,7 @@ $ git push -u myfork featureA (((git commands, request-pull))) Çalışmanız reponun size ait çatalına itildikten sonra, orjinal projenin yürütücülerini çalışmanızı birleştirmelerini istediğinize dair bilgilendirmelisiniz. -Bu genellikle bir _çekme isteği_ (pull request) olarak adlandırılır ve genellikle web sitesi üzerinden oluşturulur (GitHub'ın kendi ``Çekme İsteği'' mekanizması vardır, bu konuyu <> bölümünde ele alacağız) ya da `git request-pull` komutunu çalıştırıp ardından üretilen çıktıyı proje yürütücüsüno manuel olarak e-posta yoluyla gönderebilirsiniz. +Bu genellikle bir _çekme isteği_ (pull request) olarak adlandırılır ve genellikle web sitesi üzerinden oluşturulur (GitHub'ın kendi "Çekme İsteği" mekanizması vardır, bu konuyu <> bölümünde ele alacağız) ya da `git request-pull` komutunu çalıştırıp ardından üretilen çıktıyı proje yürütücüsüno manuel olarak e-posta yoluyla gönderebilirsiniz. `git request-pull` komutu, tematik dalınızı çekmek istediğiniz temel dalı ve çekilmesini istediğiniz Git deposunun URL'sini alır ve çekilecek tüm değişikliklerin bir özetini üretir. Örneğin, Jessica'nın John'a bir çekme isteği göndermek istediğini ve yeni gönderdiği tema dalında iki değişiklik yaptığını varsayalım, bu durumda şunu çalıştırabilir: @@ -575,7 +575,7 @@ Jessica Smith (2): Katkıların özetini gösteren, çalışmanın nereden dallandığını ve yeni çalışmanın nereden çekileceğini belirten bu çıktı, yürütücüye gönderilebilir. -Yürütücü olmadığınız bir projede, genellikle `origin/master`'ı izleyen `master` gibi bir dalın bulunması ve çalışmanızı, reddedilmesi durumunda kolayca silebileceğiniz, tematik dallar üzerinde yapmanız daha kolay olur. +Yürütücü olmadığınız bir projede, genellikle `origin/master`ı izleyen `master` gibi bir dalın bulunması ve çalışmanızı, reddedilmesi durumunda kolayca silebileceğiniz, tematik dallar üzerinde yapmanız daha kolay olur. İş paketlerinin tematik dallara -- kök daldan izole şekilde -- kısıtlanması, çalıştığınız süre zarfında ana repo ucunun ilerlemiş olması ve sizin katkılarınızın artık temiz bir şekilde uygulanamaması durumunda da işinizi yeniden düzenlemenizi kolaylaştırır. Örneğin, projeye ikinci bir iş başlığı göndermek istiyorsanız, zaten yukarı itilmiş olan tematik dalda çalışmaya devam etmeyin; ana repo `master` dalından tekrar başlayın: From 915c0c8e549378c9de1e13aabc9aee5b966495ac Mon Sep 17 00:00:00 2001 From: Murat Yasar <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 10:00:39 +0100 Subject: [PATCH 057/210] Update contributing.asc translate the section: "Contributing to a Project" --- .../sections/contributing.asc | 67 ++++++++++--------- 1 file changed, 35 insertions(+), 32 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index ed9cd9c0..c378e394 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -266,7 +266,7 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica önce `origin/master` veya `issue54`ü birleştirebilir: ikisi de kökdalda olduğu için sıra önemli değildir. +Jessica önce `origin/master` veya `issue54` 'ü birleştirebilir: ikisi de kökdalda olduğu için sıra önemli değildir. Hangi sırayı seçerse seçsin, son poz aynı olmalıdır (sadece tarih farklı olacaktır). Jessica, önce `issue54` dalını birleştirmeyi tercih eder: @@ -640,15 +640,16 @@ Bu noktada, istenen değişiklikleri yaptığınızı ve bu değişikliklere `fe image::images/public-small-3.png[`featureBv2` çalışmasının ardından katkı geçmişi.] [[_project_over_email]] -==== Public Project over Email +==== E-posta Üzerinden Açık Projeler (((contributing, public large project))) -Many projects have established procedures for accepting patches -- you'll need to check the specific rules for each project, because they will differ. -Since there are several older, larger projects which accept patches via a developer mailing list, we'll go over an example of that now. +Çok sayıda proje, yamaları kabul etmek için belirlenmiş yönergeler kullanır. +Bunlar birbirinden farklılık göstereceği için, her proje için bu yönergeleri kontrol etmeniz gerekecektir. +Yamaları geliştirici posta listesi üzerinden kabul eden birkaç eski ve büyük proje olduğundan, şimdi bir örnekle bunu ele alacağız. -The workflow is similar to the previous use case -- you create topic branches for each patch series you work on. -The difference is how you submit them to the project. -Instead of forking the project and pushing to your own writable version, you generate email versions of each commit series and email them to the developer mailing list: +Bu iş akışı, bir önceki kullanım durumuna benzer; üzerinde çalıştığınız her yama serisi için tematik dallar oluşturursunuz. +Fark, onları projeye nasıl gönderdiğinizdedir. +Projeyi çatallayıp kendi yazılabilir sürümünüze itmek yerine, her bir katkı serisinin e-posta sürümlerini oluşturur ve geliştirici posta listesine e-posta olarak gönderirsiniz: [source,console] ---- @@ -660,9 +661,10 @@ $ git commit ---- (((git commands, format-patch))) -Now you have two commits that you want to send to the mailing list. -You use `git format-patch` to generate the mbox-formatted files that you can email to the list -- it turns each commit into an email message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. -The nice thing about this is that applying a patch from an email generated with `format-patch` preserves all the commit information properly. +Şimdi posta listesine göndermek istediğiniz iki katkınız var. +Geliştirici listesine e-posta olarak gönderebileceğiniz mbox biçimli dosyalar oluşturmak için `git format-patch` komutu kullanırsınız. +Bu komut her katkıyı; ilk satırı e-postanın başlık kısmına ve geri kalan mesaj ve yama da e-postanın gövde kısmına denk düşen bir e-posta'ya dönüştürür. +Bu yöntemin güzel yanı: `format-patch` ile oluşturulan bir e-postadan yama uygulayarak, tüm katkı bilgilerinin düzgün bir şekilde korunmasıdır. [source,console] ---- @@ -671,9 +673,9 @@ $ git format-patch -M origin/master 0002-changed-log-output-to-30-from-25.patch ---- -The `format-patch` command prints out the names of the patch files it creates. -The `-M` switch tells Git to look for renames. -The files end up looking like this: +`format-patch` komutu oluşturduğu yama dosyalarının isimlerini yazdırır. +`-M` bayrağı Git'e yeniden adlandırmaları aramasını söyler. +Dosyalar en sonda şöyle görünür: [source,console] ---- @@ -706,17 +708,18 @@ index 76f47bc..f9815f1 100644 2.1.0 ---- -You can also edit these patch files to add more information for the email list that you don't want to show up in the commit message. -If you add text between the `---` line and the beginning of the patch (the `diff --git` line), the developers can read it, but that content is ignored by the patching process. +Ayrıca, katkı mesajında görünmesini istemediğiniz e-posta listesi için daha fazla bilgi ekleyerek bu yama dosyalarını düzenleyebilirsiniz. +Eğer `---` satırı ve yama başlangıcı (`diff --git` satırı) arasına metin eklerseniz, geliştiriciler bunu okuyabilir; ancak bu içerik yamalama işlemi tarafından yok sayılır. -To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program. -Pasting the text often causes formatting issues, especially with ``smarter'' clients that don't preserve newlines and other whitespace appropriately. -Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you. -We'll demonstrate how to send a patch via Gmail, which happens to be the email agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code. +Bir posta listesine e-posta göndermek için, ya dosyayı e-posta içeriğinize kopyala-yapıştır yoluyla ekler ya da komut satırı aracılığıyla gönderebilirsiniz. +Metni yapıştırmak - özellikle yeni satır ve diğer boşlukları uygun şekilde korumayan "akıllı" istemcilerde - biçimlendirme sorunlarına neden olabilir. +Neyse ki Git'in sağladığı, doğru biçimlendirilmiş yamaları IMAP aracılığıyla göndermenize yardımcı olacak bir araç, size kolaylık sağlayabilir. +En iyi bildiğimiz e-posta aracısı olan Gmail üzerinden bir yamanın nasıl gönderileceğini size göstereceğiz. +Git kaynak kodunda yer alan `Documentation/SubmittingPatches` dosyasının sonunda, farklı e-posta programları için yazılmış detaylı yönergeleri okuyabilirsiniz. (((git commands, config)))(((email))) -First, you need to set up the imap section in your `~/.gitconfig` file. -You can set each value separately with a series of `git config` commands, or you can add them manually, but in the end your config file should look something like this: +İlk olarak, `~/.gitconfig` dosyanızdaki imap bölümünü yapılandırmanız gerekir. +Her bir değeri ayrı ayrı `git config` komutlarıyla ayarlayabilir veya bunları manuel olarak ekleyebilirsiniz; ancak sonunda yapılandırma dosyanız şuna benzer bir şekilde olmalıdır: [source,ini] ---- @@ -729,8 +732,8 @@ You can set each value separately with a series of `git config` commands, or you sslverify = false ---- -If your IMAP server doesn't use SSL, the last two lines probably aren't necessary, and the host value will be `imap://` instead of `imaps://`. -When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server: +IMAP sunucunuz SSL kullanmıyorsa, muhtemelen son iki satıra ihtiyacınız olmayacak ve host değeri `imap://` yerine `imaps://` olacaktır. +Bunu ayarladıktan sonra, `git imap-send` komutunu kullanarak belirtilen IMAP sunucusunun Taslaklar klasörüne yama serisini yerleştirebilirsiniz: [source,console] ---- @@ -742,10 +745,10 @@ sending 2 messages 100% (2/2) done ---- -At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you're sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. +Bu aşamada, Taslaklar klasörüne giderek, "Alıcı" alanını gönderdiğiniz yama serisinin e-posta listesine göre ayarlayabilir ve gerekirse proje yürütücüsünü veya ilgili kişiyi "CC" olarak ekleyebilirsiniz. Artık e-postanızı göndermeye hazırsınız. -You can also send the patches through an SMTP server. -As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file: +Ayrıca yamaları bir SMTP sunucusu aracılığıyla da gönderebilirsiniz. +Aynı yukarıda olduğu gibi, her değeri ayrı ayrı `git config` komutlarıyla ayarlayabilir veya `~/.gitconfig` dosyanızdaki "sendemail" bölümüne manuel olarak ekleyebilirsiniz: [source,ini] ---- @@ -756,7 +759,7 @@ As before, you can set each value separately with a series of `git config` comma smtpserverport = 587 ---- -After this is done, you can use `git send-email` to send your patches: +Bunu yaptıktan sonra, yamalarınızı göndermek için `git send-email` komutunu kullanabilirsiniz: [source,console] ---- @@ -769,7 +772,7 @@ Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y ---- -Then, Git spits out a bunch of log information looking something like this for each patch you're sending: +Sonra, Git gönderdiğiniz her bir yaman için şöyle bir günlük bilgisi çıkarır: [source,text] ---- @@ -789,8 +792,8 @@ References: Result: OK ---- -==== Summary +==== Özet -This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process. -Next, you'll see how to work the other side of the coin: maintaining a Git project. -You'll learn how to be a benevolent dictator or integration manager. +Bu bölüm, karşılaşabileceğiniz birkaç farklı Git projesi türüyle başa çıkmanın yaygın iş akışlarını anlattı ve bu süreci yönetmenize yardımcı olacak birkaç yeni aracı tanıttı. +Şimdi, işin diğer yüzüyle nasıl çalışılacağını göreceksiniz: Bir Git projesini yürütmek. +Bir hayırsever diktatör veya birleştirme yöneticisi olmayı öğreneceksiniz. From 7619e4f612ac3ef265391058cb034a7c42bda1ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:13:46 +0100 Subject: [PATCH 058/210] Update contributing.asc fix typo --- book/05-distributed-git/sections/contributing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index c378e394..cfdb77ab 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -575,7 +575,7 @@ Jessica Smith (2): Katkıların özetini gösteren, çalışmanın nereden dallandığını ve yeni çalışmanın nereden çekileceğini belirten bu çıktı, yürütücüye gönderilebilir. -Yürütücü olmadığınız bir projede, genellikle `origin/master`ı izleyen `master` gibi bir dalın bulunması ve çalışmanızı, reddedilmesi durumunda kolayca silebileceğiniz, tematik dallar üzerinde yapmanız daha kolay olur. +Yürütücü olmadığınız bir projede, genellikle `origin/master` ı izleyen `master` gibi bir dalın bulunması ve çalışmanızı, reddedilmesi durumunda kolayca silebileceğiniz, tematik dallar üzerinde yapmanız daha kolay olur. İş paketlerinin tematik dallara -- kök daldan izole şekilde -- kısıtlanması, çalıştığınız süre zarfında ana repo ucunun ilerlemiş olması ve sizin katkılarınızın artık temiz bir şekilde uygulanamaması durumunda da işinizi yeniden düzenlemenizi kolaylaştırır. Örneğin, projeye ikinci bir iş başlığı göndermek istiyorsanız, zaten yukarı itilmiş olan tematik dalda çalışmaya devam etmeyin; ana repo `master` dalından tekrar başlayın: From 3edb00b1bc72c32d6361a21eb8a8b075915d267a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:25:50 +0100 Subject: [PATCH 059/210] Update recording-changes.asc fix typos --- .../sections/recording-changes.asc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index a89f6128..e8aef632 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -56,7 +56,7 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -Yeni `README` dosyanızın izlenmediğini görebilirsiniz, çünkü durum çıktınızda (git status) ``Untracked files`` (İzlenmeyen dosyalar) başlığı altındadır. +Yeni `README` dosyanızın izlenmediğini görebilirsiniz, çünkü durum çıktınızda (git status) `Untracked files` (İzlenmeyen dosyalar) başlığı altındadır. "İzlenmeyen" temel olarak Git'in önceki pozda sahip olmadığınız bir dosyayı gördüğü anlamına gelir. Siz bunu yapmasını açıkça söyleyene kadar Git bunu pozlarınıza dahil etmeyecektir. Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "binary" dosyaların veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. @@ -87,8 +87,8 @@ Changes to be committed: ---- -``Changes to be committed`` başlığı altında yer aldığından aşamalandırıldığını anlayabilirsiniz. -Bu noktada katkı işlerseniz (commit), dosyanın `git add`i çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. +`Changes to be committed` başlığı altında yer aldığından aşamalandırıldığını anlayabilirsiniz. +Bu noktada katkı işlerseniz (commit), dosyanın `git add` çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. Daha önce `git init` komutunu çalıştırdığınızda, hemen ardından `git add ` komutunu çalıştırdınız. Bunun amacı dizininizdeki dosyaları izlemeye başlamaktı.(((git commands, init)))(((git commands, add))) `git add` komutu, bir dosya veya dizin için bir yol adı alır. @@ -117,7 +117,7 @@ Changes not staged for commit: ---- -`CONTRIBUTING.md` dosyası, ``Changes not staged for commit`` adlı bir bölümün altında görünür. +`CONTRIBUTING.md` dosyası, `Changes not staged for commit` adlı bir bölümün altında görünür. Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği, ancak henüz aşamaya (stage) alınmadığı anlamına gelir. Aşamaya almak için `git add` komutunu çalıştırmalısınız. `git add` çok amaçlı bir komuttur: yeni dosyaları izlemeye başlamak, dosyaları aşamaya almak (katkı için hazırlamak) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyler için de kullanırsınız. @@ -164,11 +164,11 @@ Changes not staged for commit: ---- Bu da ne!? -Artık `CONTRIBUTING.md` hem "staged" hem de "unstaged" olarak listelenmiş. +Artık `CONTRIBUTING.md` hem `staged` hem de `unstaged` olarak listelenmiş. Peki neden böyle oldu!? Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi aşamaya aldığını görüyorsunuz. Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md`nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. -`git add`i çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü aşamalandırmak için `git add`i tekrar çalıştırmanız gerekir: +`git add` çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü aşamalandırmak için tekrar `git add` çalıştırmanız gerekir: [source,console] ---- @@ -220,7 +220,7 @@ $ cat .gitignore *~ ---- -İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı ``.o`` veya ``.a`` ile biten (object ve archive) tüm dosyaları yoksaymasını söyler. +İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı `.o` veya `.a` ile biten (object ve archive) tüm dosyaları yoksaymasını söyler. İkinci satır Git'e, adları tilde (`~`) ile biten tüm dosyaları yok saymasını söyler; bu, Emacs gibi birçok metin düzenleyicisi tarafından geçici dosyaları işaretlemek için kullanılır. Ayrıca otomatik olarak oluşturulan log (kayıt), tmp (geçici) veya pid (işlem kimliği) vb dizinleri de ekleyebilirsiniz. Başlamadan önce yeni reponuz için bir `.gitignore` dosyası oluşturmak iyi bir fikirdir. @@ -333,7 +333,7 @@ index 8ebb991..643e24f 100644 Bu komut, çalışma dizininizdeki güncel kodu, aşama alanınızdaki kodla karşılaştırır. Sonuç size, henüz gerçekleştirmediğiniz değişiklikleri görme imkanı tanır. -Eğer bir sonraki katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız ``git diff --staged`` komutunu kullanabilirsiniz. +Eğer bir sonraki katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız `git diff --staged` komutunu kullanabilirsiniz. Bu komut, aşamadaki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır: [source,console] @@ -517,7 +517,7 @@ Git'ten bir dosyayı kaldırmak için, onu izlenen dosyalar listenizden (stage) Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. Eğer dosyayı silmek yerine sadece takipten çıkarmak istiyorsanız dosya yolunu ve adını `.gitignore` dosyasına kaydetmelisiniz. -Dosyayı sadece çalışma dizininizden kaldırırsanız, dosyanızı `git status` çıktınızın ``Changes not staged for commit`` (yani _unstaged_) alanında görebilirsiniz: +Dosyayı sadece çalışma dizininizden kaldırırsanız, dosyanızı `git status` çıktınızın `Changes not staged for commit` (yani _unstaged_) alanında görebilirsiniz: [source,console] ---- From 1c047951c2b2a06ba3df0546bd22910b0038cc52 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:32:23 +0100 Subject: [PATCH 060/210] Update recording-changes.asc fix typo --- book/02-git-basics/sections/recording-changes.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index e8aef632..c0d0312b 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -139,7 +139,7 @@ Changes to be committed: ---- Her iki dosya da aşamadadır ve bir sonraki işleminize aktarılacaktır. -Bu noktada, varsayalım ki `CONTRIBUTING.md`de yapmak istediğiniz küçük bir değişikliği hatırladınız. +Bu noktada, varsayalım ki `CONTRIBUTING.md` dosyasında yapmak istediğiniz küçük bir değişikliği hatırladınız. Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi katkı olarak işlemeye hazırsınız. Hadi `git status` komutunu bir kez daha çalıştıralım: @@ -163,11 +163,11 @@ Changes not staged for commit: ---- -Bu da ne!? +Bu da ne! Artık `CONTRIBUTING.md` hem `staged` hem de `unstaged` olarak listelenmiş. Peki neden böyle oldu!? Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi aşamaya aldığını görüyorsunuz. -Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md`nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. +Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md` nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. `git add` çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü aşamalandırmak için tekrar `git add` çalıştırmanız gerekir: [source,console] From c0ee7438b6229fdc224e777b6114ca10d9760dc0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:33:36 +0100 Subject: [PATCH 061/210] Update recording-changes.asc fix typo --- book/02-git-basics/sections/recording-changes.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index c0d0312b..6bb82647 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -284,7 +284,7 @@ Bu konuda daha detaylı bilgiye konsol ekranınıza "man gitignore" komutu yaza ==== Aşamalandırılmış (Staged) ve Aşamalandırılmamış (Unstaged) Değişiklikleri Görme `git status` komutu sizin için yeterince bilgi içermiyorsa (sadece hangi dosyaların değiştirildiğini değil, tam olarak neyi değiştirdiğinizi de bilmek istiyorsanız), bunun yerine `git diff` komutunu kullanabilirsiniz.(((git commands, diff))) -`git diff`i daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç kullanacaksınız: +`git diff` komutunu daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç kullanacaksınız: 1. Neyi değiştirdiniz ama henüz aşamaya almadınız? 2. Neyi aşamaya aldınız fakat henüz katkı olarak işlemediniz? Her ne kadar `git status` bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da `git diff` size; eklenen ve kaldırılan satırları, değiştirilen her bir kod parçasıyla birlikte, detaylıca gösterir. From ca1d435099ce47eda655fb4a22ee0a50964cb68c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:36:07 +0100 Subject: [PATCH 062/210] Update viewing-history.asc fix typo --- book/02-git-basics/sections/viewing-history.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 9d9cb23e..9920f87e 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -264,7 +264,7 @@ Bir diğer gerçekten faydalı süzgeç ise bir dize (string) alan ve yalnızca $ git log -S function_name ---- -`git log`a filtre argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). +`git log` komutuna filtre argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). Eğer bir dizin veya dosya adı belirtirseniz günlük çıktısını, bu dosyalarda değişiklik yapan katkılarla sınırlayabilirsiniz. Bu her zaman son seçenektir ve dosya yollarını seçeneklerden (bayraklardan) ayırmak için genellikle önünde çift çizgi (`--`) bulunur. From fcc7b3344af82e4f522aa94e1a4e20152d056d8f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:38:05 +0100 Subject: [PATCH 063/210] Update branch-management.asc fix typos --- book/03-git-branching/sections/branch-management.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index dad7d4bd..a1591c0f 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -15,7 +15,7 @@ $ git branch testing ---- -`master` dalının önünde yer alan `*` karakterine dikkat edin: bu, şu anda üzerinde çalıştığını (yani, `HEAD`'in işaret ettiği) dalı gösterir. +`master` dalının önünde yer alan `*` karakterine dikkat edin: bu, şu anda üzerinde çalıştığını (yani, `HEAD` 'in işaret ettiği) dalı gösterir. Bu, eğer şimdi bir katkı işlerseniz `master` dalının yeni çalışmanızla birlikte ileri taşınacağı anlamına gelir. Her bir dalın son katkısını görmek için `git branch -v` komutunu çalıştırabilirsiniz: @@ -37,7 +37,7 @@ $ git branch --merged * master ---- -Daha önce `iss53`ü zaten birleştirdiğiniz için, bu dalı listenizde görüyorsunuz. +Daha önce `iss53` dalını zaten birleştirdiğiniz için, bu dalı listenizde görüyorsunuz. Bu listede yer alıp önünde `*` olmayan dalları `git branch -d` ile silmek genellikle güvenlidir. Çünkü zaten bu dallardaki çalışmayı başka bir dala dahil ettiniz ve onları silmek veri kaybına yol açmayacak. From dbb3bae5356afd67767eafc5ca52a93c691c20f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:41:12 +0100 Subject: [PATCH 064/210] Update nutshell.asc fix typos --- book/03-git-branching/sections/nutshell.asc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 46a539b9..611739e6 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -3,7 +3,7 @@ Git'in dallanma yöntemini gerçekten anlamak için bir adım geriye çekilip Git'in verileri nasıl sakladığını incelememiz gerekiyor. -<> bölümünden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _anlık görüntü_ olarak saklar. +<> bölümünden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _poz_ olarak saklar. Git, bir katkı işlediğinizde (commit), aşamalandırdığınız (stage) içeriğin anlık görüntüsünün işaretçisi (pointer: bir katkı veya ağacın yerini gösteren işaretçi) içeren bir katkı nesnesi (object) saklar. Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve öncel katkı veya katkılara ilişkin işaretçileri içerir. İlk katkı (first commit) için sıfır; normal bir katkı için bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı içinse çoklu öncel katkı bulunur. @@ -34,13 +34,13 @@ Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz (git image::images/commits-and-parents.png[Katkı ve öncel katkılar.] Git'teki bir dal, temel olarak üzerindeki katkılardan birinin hafif ve taşınabilir bir işaretçisidir. -Git'te varsayılan dalın adı `master`dır (anadal). +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] ==== -Git'teki ``master`` dalı özel bir dal değildir.(((master))) +Git'teki `master` dalı özel bir dal değildir.(((master))) Tam olarak diğer diğer dallar gibi davranır. Hemen hemen her repoda bulunmasının tek nedeni, `git init` komutunun varsayılan olarak onu oluşturması ve çoğu insanın bunu değiştirmeye uğraşmamasıdır. ==== @@ -116,7 +116,7 @@ $ vim test.rb $ git commit -a -m 'made a change' ---- -.Bir katkı işlendiğinde `HEAD`in işaret ettiği dal ileriye doğru hareket eder. +.Bir katkı işlendiğinde `HEAD` 'in işaret ettiği dal ileriye doğru hareket eder. image::images/advance-testing.png[Bir katkı işlendiğinde `HEAD` ileriye doğru hareket eder.] İlginç bir şekilde, `testing` dalınız ileri hareket etti ancak `master` dalınız halen en son bıraktığımız halde (`testing` dalına geçiş yaptığınız anda üzerinde bulunduğunuz katkıya işaret ediyor). @@ -131,7 +131,7 @@ $ git checkout master image::images/checkout-master.png[Başka dala geçtiğinizde HEAD'in yönü değişir.] Bu komut iki şey yaptı: -İlk olarak, `HEAD` işaretçisini tekrar `master` dalına çevirdi ve ikinci olarak, çalışma dizinindeki dosyaları `master`'ın işaret ettiği anlık görüntüye geri dönderdi. +İlk olarak, `HEAD` işaretçisini tekrar `master` dalına çevirdi ve ikinci olarak, çalışma dizinindeki dosyaları `master`'ın işaret ettiği poza geri dönderdi. 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. From 11a7c6581688f6e48efff1dfd09436f5a4b876dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:41:58 +0100 Subject: [PATCH 065/210] Update nutshell.asc fix typo --- book/03-git-branching/sections/nutshell.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 611739e6..4d8563a7 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -131,7 +131,7 @@ $ git checkout master image::images/checkout-master.png[Başka dala geçtiğinizde HEAD'in yönü değişir.] Bu komut iki şey yaptı: -İlk olarak, `HEAD` işaretçisini tekrar `master` dalına çevirdi ve ikinci olarak, çalışma dizinindeki dosyaları `master`'ın işaret ettiği poza geri dönderdi. +İlk olarak, `HEAD` işaretçisini tekrar `master` dalına çevirdi ve ikinci olarak, çalışma dizinindeki dosyaları `master` 'ın işaret ettiği poza geri dönderdi. 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. From d9b6033d8f562e4adafdc84ef6952b69cf42c442 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 20:46:04 +0100 Subject: [PATCH 066/210] Update rebasing.asc fix typos --- book/03-git-branching/sections/rebasing.asc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 945a17e9..ed11193c 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -18,7 +18,7 @@ Bu komut, iki dalın (`C3` ve `C4`) ve bunların en son ortak öncelinin (`C2`) .Ayrık çalışma geçmişini birleştirmek image::images/basic-rebase-2.png[Ayrık çalışma geçmişini birleştirmek.] -Ancak, başka bir yol daha vardır: `C4` ile tanıtılan değişikliğin yamasını alabilir ve bunu `C3`'ün üzerine yeniden uygulayabilirsiniz. +Ancak, başka bir yol daha vardır: `C4` ile tanıtılan değişikliğin yamasını alabilir ve bunu `C3` 'ün üzerine yeniden uygulayabilirsiniz. Git'te buna _temel alma_ veya _temelleme_ (rebasing) denir. `rebase` komutu ile bir dalda işlenmiş tüm değişiklikleri alabilir ve bunları farklı bir dala aktararak bir temel olarak kullanabilirsiniz.(((git commands, rebase))) @@ -36,8 +36,8 @@ Bu işlem, iki dalın (üzerinde bulunduğunuz dal ve temel aldığınız dal) o Ardından, üzerinde bulunduğunuz dalın her katkısının getirdiği farkı alır ve bu farkları geçici dosyalara kaydeder. Mevcut dalı, üzerine temelleme yaptığınız dalın katkıları ile aynı katkıya sıfırlar ve son olarak her değişikliği sırayla uygular. -.`C4`teki değişikliği `C3` üzerine temelleme -image::images/basic-rebase-3.png[`C4`teki değişikliği `C3` üzerine temelleme.] +.`C4` 'teki değişikliği `C3` üzerine temelleme +image::images/basic-rebase-3.png[`C4` 'teki değişikliği `C3` üzerine temelleme.] Bu noktada, `master` dalına geri dönebilir ve bir ileri-sarma birleştirmesi (fast-forward merge) yapabilirsiniz. @@ -82,7 +82,7 @@ Bu durumda, sunucu tarafında olmayıp (`C8` and `C9`) kullanıcı tarafında ol $ git rebase --onto master server client ---- -Bu temel olarak şunu ifade eder: " `client` dalını al, bu dalın `server` dalından ayrıldığından bu yana yapılan yamaları belirle ve bu yamaları `client` dalında, sanki doğrudan `master` dalından temellenmiş gibi temelle." +Bu temel olarak şunu ifade eder: "`client` dalını al, bu dalın `server` dalından ayrıldığından bu yana yapılan yamaları belirle ve bu yamaları `client` dalında, sanki doğrudan `master` dalından temellenmiş gibi temelle." Biraz karmaşık gibi görünebilir, ancak sonuç oldukça etkileyicidir. .Tematik bir daldan yeni bir tematik dal temelleme @@ -189,7 +189,7 @@ Eğer kendinizi böyle bir durumda bulunursanız, Git size yardımcı olabilecek Eğer takımınızdaki birisi, temellediğiniz bir işin üzerine yazan değişiklikleri zorla iterse (force push), karşılaşacağınız gerçek sorun hangi kodun size ait olduğu ve hangisinin üzerine yeniden yazılan olduğunu bulmaktır. Git, katkının SHA-1 sağlamasına ek olarak, yalnızca katkı ile tanıtılan yamaya dayalı bir sağlama da hesaplar. -Buna ``patch-id'' denir. +Buna ``patch-id`` denir. Eğer üzerine yeniden yazılan işi çekerseniz ve bu işi meslektaşınızın yeni katkıları üzerine temellerseniz; Git genellikle sizin çalışmanızın hangisi olduğunu başarılı bir şekilde bulabilir ve bunları yeni dalın üzerine uygulayabilir. @@ -212,7 +212,7 @@ Aksi takdirde, temelleme bunun bir kopya olduğunu anlayamaz ve başka bir C4 be Bunu normal bir `git pull` yerine `git pull --rebase` komutunu çalıştırarak daha da basitleştirebilirsiniz. Veya bu durumda bir `git fetch` ve ardından `git rebase teamone/master` komutu kullanarak manuel olarak da gerçekleştirebilirsiniz. -Eğer `git pull` kullanıyorsanız ve `--rebase`'yi varsayılan yapmak istiyorsanız, `git config --global pull.rebase true` gibi bir komutla `pull.rebase` yapılandırmasını ayarlayabilirsiniz. +Eğer `git pull` kullanıyorsanız ve `--rebase` varsayılan olsun istiyorsanız, `git config --global pull.rebase true` gibi bir komutla `pull.rebase` yapılandırmasını ayarlayabilirsiniz. Eğer sadece kendi bilgisayarınızdan hiç ayrılmamış katkıları temelliyorsanız, sorun yaşamazsınız. Eğer itilmiş ancak kimsenin bunlardan temellemediği katkıları temelliyorsanız, yine sorun yaşamazsınız. From 3df99fd7652efbfa51274db9ae363c6f08e08d94 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:00:37 +0100 Subject: [PATCH 067/210] Update remote-branches.asc fix typos --- .../sections/remote-branches.asc | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 13b7a6be..4b81cee8 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -41,7 +41,7 @@ Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/m image::images/remote-branches-2.png[Yerel ve uzak çalışma farklılaşabilir.] Belirli bir uzak repo ile çalışmanızı eşzamanlamak (synchronize) için `git fetch ` komutunu çalıştırırsınız (bizim durumumuzda, `git fetch origin`). -Bu komut, `origin`in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri getirir (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. +Bu komut, `origin` 'in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri getirir (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. .`git fetch` uzak takip dallarınızı günceller image::images/remote-branches-3.png[`git fetch` zak takip dallarınızı günceller.] @@ -136,12 +136,12 @@ Böylelikle, `origin/serverfix`'in başladığı yerden devam eden ve üzerinde ==== Dalları Takip (((branches, tracking)))(((branches, upstream))) -Bir uzak takip dalından yerel bir dala geçmek, otomatik olarak bir 'takip dalı' (tracking branch) oluşturur (ve takip ettiği dal 'yukarı akış dalı' (upstream branch) olarak adlandırılır). +Bir uzak takip dalından yerel bir dala geçmek, otomatik olarak bir 'takip dalı' (tracking branch) oluşturur (ve takip ettiği dal 'üst-akım dalı' (upstream branch) olarak adlandırılır). Takip eden dallar, bir uzak dal ile doğrudan ilişkisi olan yerel dallardır. Bir takip dalındaysanız ve `git pull` yazarsanız, Git otomatik olarak hangi sunucudan getirileceğini ve hangi dalın birleştirileceğini bilir. -Bir repoyu kopyaladığınızda, genellikle otomatik olarak `origin/master`'ı takip eden bir `master` dalı oluşturur. -Ancak isterseniz başka takip dalları da kurabilirsiniz - diğer uzaklardaki dalları takip edenler veya `master` dalını takip etmeyenler. +Bir repoyu kopyaladığınızda, genellikle otomatik olarak `origin/master` 'ı takip eden bir `master` dalı oluşturur. +Ancak isterseniz başka takip dalları da kurabilirsiniz (diğer uzaklardaki dalları takip edenler veya `master` dalını takip etmeyenler). Basit durum, az önce gördüğünüz gibidir: `git checkout -b /`. Bu, Git'in `--track` kısaltmasını sağlayan yaygın bir işlemdir: @@ -171,7 +171,7 @@ Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ---- -Şimdi, yerel dalınız `sf`, otomatik olarak `origin/serverfix`'ten çekecek. +Şimdi, yerel dalınız `sf`, otomatik olarak `origin/serverfix` 'ten çekecek. Eğer zaten bir yerel dala sahipseniz ve onu henüz çektiğiniz bir uzak dalıyla eşleştirmek veya takip ettiğiniz yukarı akış dalını değiştirmek istiyorsanız, `git branch` komutunun `-u` veya `--set-upstream-to` seçeneğini kullanarak bunu istediğiniz zaman açıkça belirtebilirsiniz. @@ -182,10 +182,10 @@ Branch serverfix set up to track remote branch serverfix from origin. ---- [NOT] -.Üstakış (upstream) kısayolu +.Üstakım (upstream) kısayolu ==== Eğer kurulu bir takip dalınız varsa, onun yukarı akış dalını `@{upstream}` veya `@{u}` kısaltmasıyla işaretleyebilirsiniz. -Yani eğer `master` dalındaysanız ve bu dal `origin/master`'ı takip ediyorsa, isterseniz `git merge origin/master` yerine `git merge @{u}` gibi bir şey söyleyebilirsiniz.(((+++@{u}+++)))(((+++@{upstream}+++))) +Yani eğer `master` dalındaysanız ve bu dal `origin/master` 'ı takip ediyorsa, isterseniz `git merge origin/master` yerine `git merge @{u}` gibi bir şey söyleyebilirsiniz.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== Takip eden dallarınızı görmek istiyorsanız, `git branch` komutuna `-vv` seçeneğini ekleyebilirsiniz. @@ -200,9 +200,9 @@ $ git branch -vv testing 5ea463a trying something new ---- -Burada `iss53` dalımızın `origin/iss53`ü takip ettiğini ve 'önde' (ahead) iki olduğunu görebiliriz. +Burada `iss53` dalımızın `origin/iss53` 'ü takip ettiğini ve 'önde' (ahead) iki olduğunu görebiliriz. Bu da lokalde henüz sunucuya gönderilmemiş iki katkı olduğu anlamına gelir. -Ayrıca, `master` dalımızın `origin/master`ı takip ettiğini ve güncel olduğunu görebiliriz. +Ayrıca, `master` dalımızın `origin/master` 'ı takip ettiğini ve güncel olduğunu görebiliriz. Sonrasında, `serverfix` dalımızın `teamone` sunucusundaki `server-fix-good` dalını takip ettiğini ve 'önde' (ahead) üç, 'geride' (behind) bir olduğunu görebiliriz. Bu da henüz birleştirmediğimiz bir katkı olduğu ve lokalde henüz göndermediğimiz üç katkı olduğu anlamına gelir. Son olarak, `testing` dalımızın herhangi bir uzak dalı takip etmediğini görebiliriz. @@ -222,7 +222,7 @@ $ git fetch --all; git branch -vv (((pulling))) `git fetch` komutu, henüz sahip olmadığınız sunucudaki tüm değişiklikleri getirir, ancak çalışma dizininizi hiç değiştirmez. Sadece veriyi sizin için alır ve birleştirmenize izin verir. -Ancak, çoğu durumda `git fetch`'in hemen ardından gelen bir `git merge` işlemi olan `git pull` adlı bir komut bulunmaktadır. +Ancak, çoğu durumda `git fetch` 'in hemen ardından gelen bir `git merge` işlemi olan `git pull` adlı bir komut bulunmaktadır. Son bölümde gösterildiği gibi bir takip dalınız varsa, bunu açıkça ayarlayarak veya `clone` veya `checkout` komutları tarafından sizin için oluşturulmuşsa, `git pull`, mevcut dalınızın hangi sunucuyu ve dalı takip ettiğini araştırır, bu sunucudan veri çeker ve ardından bu uzak dalı birleştirmeye çalışır. Genellikle `git pull` komutunun sihirli davranışı sıklıkla karmaşıklığa neden olabileceğinden, açıkça `fetch` ve `merge` komutlarını kullanmak daha iyidir. From 5020dc7b3e0f3dad4f5cb7415e9acacbc70b7be3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:02:46 +0100 Subject: [PATCH 068/210] Update generating-ssh-key.asc From 7be07704e4c2b9c57543ba9ae3ea1b7975fb4994 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:03:36 +0100 Subject: [PATCH 069/210] Update git-daemon.asc --- book/04-git-server/sections/git-daemon.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 41f02a0a..d752959c 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -1,7 +1,7 @@ === Git Cini (Daemon) (((serving repositories, git protocol))) -Şimdi, repoları ``Git'' protokolünü kullanarak sunan bir daemon kuracağız. +Şimdi, repoları "Git" protokolünü kullanarak sunan bir daemon kuracağız. Bu, Git verilerinize hızlı, kimlik doğrulamasız erişim için yaygın bir seçenektir. Unutmayın ki bu kimlik doğrulamasız bir servis olduğundan, bu protokol üzerinden sunduğunuz her şey, ağ içindeki herkese açık olacaktır. From 4d7626cd39d8901ac30ffe78f8236b17f26eff41 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:04:20 +0100 Subject: [PATCH 070/210] Update gitweb.asc --- book/04-git-server/sections/gitweb.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index a12f4129..1fa25c5f 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -11,7 +11,7 @@ image::images/git-instaweb.png[GitWeb ağ-tabanlı kullanıcı arayüzü.] Eğer sisteminizde `lighttpd` veya `webrick` gibi hafif bir ağ sunucusuna sahipseniz ve GitWeb'in projeniz için nasıl görüneceğini kontrol etmek istiyorsanız, Git bir geçici bir örnek başlatmak için bir komut içerir. Linux makinelerinde genellikle `lighttpd` yüklüdür, bu nedenle projeniz dizininde `git instaweb` yazarak bunu çalıştırabilirsiniz. Mac'te ise Ruby ile önceden yüklenmiş gelen Leopard bulunduğu için, `webrick` belki en iyi seçeneğiniz olabilir. -`instaweb`'i lighttpd olmayan bir işleyici ile başlatmak için `--httpd` seçeneği ile çalıştırabilirsiniz.(((git commands, instaweb))) +`instaweb` 'i lighttpd olmayan bir işleyici ile başlatmak için `--httpd` seçeneği ile çalıştırabilirsiniz.(((git commands, instaweb))) [source,console] ---- From 9e5b26bbb6b996fb8228fbbf6894c3f2a9964d3a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:05:43 +0100 Subject: [PATCH 071/210] Update setting-up-server.asc --- book/04-git-server/sections/setting-up-server.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 6aa4e2da..3a64c720 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -91,7 +91,7 @@ Bunu sınırlamak istiyorsanız, `/etc/passwd` dosyasında kabuğu başka bir ş `git` kullanıcı hesabını sadece Git ile ilgili faaliyetlerle kısıtlamak için, Git ile birlikte gelen sınırlı bir kabuk aracı olan `git-shell`i kullanabilirsiniz. Eğer `git` kullanıcı hesabının giriş kabuğu olarak bunu ayarlarsanız, o hesap sunucunuzda normal kabuk erişimine sahip olamaz. -Bunu kullanmak için, o hesabın giriş kabuğu olarak bash veya csh yerine `git-shell`i belirtmelisiniz. +Bunu kullanmak için, o hesabın giriş kabuğu olarak bash veya csh yerine `git-shell` 'i belirtmelisiniz. Bunun için, eğer hali hazırda yoksa, `/etc/shells` dosyasına `git-shell` komutunun tam yolunu eklemeniz gerekmektedir: [source,console] From 80966a157f7b55122d0decda73311a526fb98821 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Sat, 10 Feb 2024 21:06:59 +0100 Subject: [PATCH 072/210] Update smart-http.asc --- book/04-git-server/sections/smart-http.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index bd07b9f9..28293722 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -3,7 +3,7 @@ (((serving repositories, HTTP))) Şimdi hem SSH üzerinden kimlik doğrulamalı erişim hem de `git://` üzerinden kimlik doğrulamasız erişimimiz var, ancak aynı anda her ikisini de yapabilen bir protokol de bulunmaktadır. Akıllı HTTP'yi kurmak temel olarak sunucuda Git ile birlikte gelen `git-http-backend` adlı bir CGI betiğini etkinleştirmektir.(((git commands, "http-backend"))) -Bu CGI bir `git fetch` veya `git push`un bir HTTP URL'sine gönderdiği dizin ve başlıkları okur ve istemcinin HTTP üzerinden iletişim kurup kuramayacağını belirler (1.6.6 sürümünden itibaren tüm istemciler için doğrudur). +Bu CGI bir `git fetch` veya `git push` 'un bir HTTP URL'sine gönderdiği dizin ve başlıkları okur ve istemcinin HTTP üzerinden iletişim kurup kuramayacağını belirler (1.6.6 sürümünden itibaren tüm istemciler için doğrudur). CGI istemcinin akıllı olduğunu görürse onunla akıllı iletişim kurar, aksi takdirde (daha eski istemcilerle geriye dönük uyumluluk için) aptal davranışa geri döner. Hadi şimdi çok temel bir kurulumu inceleyelim. @@ -26,7 +26,7 @@ Böylece web sunucunuz repoları okuma ve yazma erişimine sahip olabilir, çün $ chgrp -R www-data /srv/git ---- -Şimdi, Apache yapılandırmasına bazı şeyler ekleyelim ki `git-http-backend`i web sunucunuzun `/git` dizinine gelen her şey için işleyici olarak çalıştırsın. +Şimdi, Apache yapılandırmasına bazı şeyler ekleyelim ki `git-http-backend` 'i web sunucunuzun `/git` dizinine gelen her şey için işleyici olarak çalıştırsın. [source,console] ---- @@ -37,7 +37,7 @@ ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ Eğer `GIT_HTTP_EXPORT_ALL` ortam değişkenini çıkartırsanız, Git (tam olarak Git daemon'ın yaptığı gibi) yalnızca `git-daemon-export-ok` dosyasına sahip olan repoları kimlik doğrulamasız istemcilere sunacaktır. -Son olarak, Apache'ye `git-http-backend`e olan isteklere izin vermesini ve yazma işlemlerinin bir şekilde kimlik doğrulanmasını yapmasını isteyeceksiniz, muhtemelen şu şekilde bir Auth bloğu ile: +Son olarak, Apache'ye `git-http-backend` 'e olan isteklere izin vermesini ve yazma işlemlerinin bir şekilde kimlik doğrulanmasını yapmasını isteyeceksiniz, muhtemelen şu şekilde bir Auth bloğu ile: [source,console] ---- From 8f1c1521e3fc0d2ff95b3cee851b79ac0abd32f7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 12 Feb 2024 10:10:27 +0100 Subject: [PATCH 073/210] Update maintaining.asc translate up to line:70 --- .../sections/maintaining.asc | 56 ++++++++++--------- 1 file changed, 29 insertions(+), 27 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 81de7af8..31d0c43a 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -1,59 +1,61 @@ -=== Maintaining a Project +=== Bir Projeyi Yürütme (((maintaining a project))) -In addition to knowing how to contribute effectively to a project, you'll likely need to know how to maintain one. -This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project. -Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run. +Projeye katkı sağlamanın yanı sıra genellikle bilmeniz gereken bir diğer beceri de Bir projeyi etkili bir şekilde yürütmektir. +Bu `format-patch` ile oluşturulan ve size e-posta yoluyla gönderilen yamaları kabul etmek ve uygulamak veya eklediğiniz uzak dallardaki değişiklikleri projenize birleştirmekten oluşabilir. +İster klasik bir repoyu yürütüyor olun, ister yamaları doğrulayarak veya onaylayarak projeye yardımcı olun; diğer katkıda bulunanlar için en açık ve sizin için uzun vadede en sürdürülebilir kabul yöntemini bilmeniz gerekir. -==== Working in Topic Branches +==== Tematik Dallarda Çalışma (((branches, topic))) -When you're thinking of integrating new work, it's generally a good idea to try it out in a _topic branch_ -- a temporary branch specifically made to try out that new work. -This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it. -If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. -The maintainer of the Git project tends to namespace these branches as well -- such as `sc/ruby_client`, where `sc` is short for the person who contributed the work. -As you'll remember, you can create the branch based off your `master` branch like this: +Yeni bir çalışmayı birleştirmeyi düşündüğünüzde, sırf bunu denemek için geçici bir _tematik dal_ oluşturmak iyi bir fikirdir. +Bu şekilde, bir yamanın detaylarını bireysel olarak ayarlamak ve işe yaramıyorsa daha sonra geri dönmek üzere bir kenara ayırmak için zamanınız olur. +Denemeyi yapacağınız işin konusuna dayanan basit ve açıklayıcı bir dal adı oluşturursanız (ör. `ruby_client` vb); bir süre terk edip daha sonra geri dönmek zorunda kalırsanız, kolaylıkla hatırlayabilirsiniz. + +Git projesinin yürütücüsü de genellikle bu dalları isimlendirir (ör. `sc/ruby_client`. Surada `sc` çalışmayı ekleyen kişinin kısaltmasıdır). +Hatırlayacağınız gibi, bunu `master` dalınızdan şu şekilde oluşturabilirsiniz: [source,console] ---- $ git branch sc/ruby_client master ---- -Or, if you want to also switch to it immediately, you can use the `checkout -b` option: +Veya doğrudan o dala geçmek istiyorsanız, `checkout -b` seçeneğini kullanabilirsiniz: [source,console] ---- $ git checkout -b sc/ruby_client master ---- -Now you're ready to add the contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches. +Şimdi aldığınız çalışmayı bu tematik dala eklemeye hazırsınız ve onu daha uzun vadeli dallarınıza birleştirip birleştirmeyeceğinize karar verebilirsiniz. [[_patches_from_email]] -==== Applying Patches from Email +==== E-Postadan gelen Yamaları Uygulamak (((email, applying patches from))) -If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. -There are two ways to apply an emailed patch: with `git apply` or with `git am`. +E-posta yoluyla alınan bir yamayı projenize birleştirmeniz gerekiyorsa, yamayı test etmek için tematik dalınıza uygulamanız gerekir. +E-postayla gönderilen bir yamayı uygulamanın iki yolu vardır: `git apply` ve `git am`. -===== Applying a Patch with apply +===== Bir Yamayı `apply` ile Uygulamak (((git commands, apply))) -If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. -Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: +Eğer birisi yamayı `git diff` veya Unix'un `diff` komutunun bir türevi ile oluşturduysa (ki bir sonraki bölümde göreceğiniz üzere bu önerilmez), yamayı `git apply` komutu ile uygulayabilirsiniz. +Yamayı `/tmp/patch-ruby-client.patch` dosyasına kaydettiğinizi farzedersek, şu şekilde uygulayabilirsiniz: [source,console] ---- $ git apply /tmp/patch-ruby-client.patch ---- -This modifies the files in your working directory. -It's almost identical to running a `patch -p1` command to apply the patch, although it's more paranoid and accepts fewer fuzzy matches than patch. -It also handles file adds, deletes, and renames if they're described in the `git diff` format, which `patch` won't do. -Finally, `git apply` is an ``apply all or abort all'' model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. -`git apply` is overall much more conservative than `patch`. -It won't create a commit for you -- after running it, you must stage and commit the changes introduced manually. +Bu, çalışma dizininizdeki dosyaları değiştirir. +Bir yama uygulamak için `patch -p1` komutunu çalıştırmakla neredeyse aynıdır; ancak daha paranoiddir ve patch'e göre daha az belirsiz eşleşme (fuzzy match) kabul eder. +Ayrıca, `git diff` formatında açıklanmış dosya ekleme, silme ve yeniden adlandırma işlemlerini, `patch` 'in yapmayacağı şekilde ele alır. +Son olarak, `git apply` uygulamanızda "tümünü uygula" veya "hiçbirini uygulama" kararını vermeniz gereken bir modelidir: `patch` ise yamaları kısmen uygulayabilir ve çalışma dizenizi tuhaf bir durumda bırakabilir. +`git apply` genel olarak `patch` 'den çok daha katı davranır. +Size bir katkı kaydı oluşturmaz: çalıştırdıktan sonra, değişiklikleri elle aşamalandırmanız ve katkı işlemeniz gerekir. -You can also use `git apply` to see if a patch applies cleanly before you try actually applying it -- you can run `git apply --check` with the patch: +`git apply` komutunu, bir yamayı gerçekten uygulamadan önce, düzgün bir şekilde uygulanıp uygulanamayacağını kontrol etmek için de kullanabilirsiniz. +Bunun için `git apply --check` komutu yamayla birlikte çalıştırabilirsiniz. [source,console] ---- @@ -62,8 +64,8 @@ error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply ---- -If there is no output, then the patch should apply cleanly. -This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want. +Eğer çıktı yoksa, yama temiz bir şekilde uygulanabilir demektir. +Bu komut ayrıca, kontrolün başarısız olduğu durumlarda da sonucu sıfır olmayan bir durumla (non-zero status) çıkar, bu nedenle isterseniz bu komutu betiklerde de kullanabilirsiniz. [[_git_am]] ===== Applying a Patch with `am` From e366f0dc1af3e66beac81dda62e56d134ed2ef07 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 12 Feb 2024 12:21:27 +0100 Subject: [PATCH 074/210] Update maintaining.asc translate up to line: 104 --- .../sections/maintaining.asc | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 31d0c43a..4a311f85 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -68,16 +68,17 @@ Eğer çıktı yoksa, yama temiz bir şekilde uygulanabilir demektir. Bu komut ayrıca, kontrolün başarısız olduğu durumlarda da sonucu sıfır olmayan bir durumla (non-zero status) çıkar, bu nedenle isterseniz bu komutu betiklerde de kullanabilirsiniz. [[_git_am]] -===== Applying a Patch with `am` +===== `git am` Komutuyla Yama Uygulama (((git commands, am))) -If the contributor is a Git user and was good enough to use the `format-patch` command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. -If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you. -You should only have to use `git apply` for legacy patches and things like that. +Eğer geliştirici yamasını oluşturmak için `format-patch` komutunu kullanacak tecrübede bir Git kullanıcısıysa; yama yazar bilgisi ve bir katkı mesajı da içereceği için, işiniz daha kolay olur. +Mümkünse, geliştiricilerinizi yamalarını oluşturmak için `diff` yerine `format-patch` kullanmaları yönünde teşvik edin. +Yalnızca eski yamalar (legacy patch) ve benzeri durumlar için `git apply` kullanmanız gerekir. + +`format-patch` ile oluşturulan bir yamayı uygulamak için `git am` ("bir posta kutusundan bir dizi yamayı uygulamak" için bu komut kullanıldığından `am` olarak adlandırılır) kullanılır. +`git am` komutu teknik olarak, bir veya daha fazla e-posta mesajını tek bir metin dosyasında depolamak için oluşturulan basit bir düz-metin biçimi olan "mbox" dosyasını okumak amacıyla oluşturulmuştur. +Ve şuna benzer: -To apply a patch generated by `format-patch`, you use `git am` (the command is named `am` as it is used to "apply a series of patches from a mailbox"). -Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. -It looks something like this: [source,console] ---- @@ -89,11 +90,11 @@ Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 ---- -This is the beginning of the output of the `git format-patch` command that you saw in the previous section; it also represents a valid mbox email format. -If someone has emailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. +Bu, önceki bölümde gördüğünüz `git format-patch` komutunun çıktısının başlangıcıdır; aynı zamanda geçerli bir mbox e-posta biçimini temsil eder. +Eğer biri size yamayı `git send-email` komutunu kullanarak düzgün şekilde e-posta ile gönderdiyse; ve siz de bunu mbox biçiminde indirir ve `git am` 'i o mbox dosyasına işaret edecek şekilde ayarlarsanız; gördüğü tüm yamaları uygulamaya başlayacaktır. +Eğer bir mbox formatında birkaç e-postayı kaydedebilen bir posta istemcisi çalıştırıyorsanız, tüm yama serilerini bir dosyaya kaydedip, bunların hepsini tek seferde uygulamak için `git am` 'i kullanabilirsiniz. -However, if someone uploaded a patch file generated via `git format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: +Ancak, birisi `git format-patch` kullanarak oluşturulan bir yama dosyasını bir bilet sistemi veya benzer bir yere yüklediyse; bu dosyayı yerel olarak kaydedip, ardından diskte kaydedilen bu dosyayı uygulamak için `git am` 'e iletebilirsiniz: [source,console] ---- From 69f1d80ca12b4b31e1191294283c5ccdfe22e176 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 12 Feb 2024 17:53:07 +0100 Subject: [PATCH 075/210] Update maintaining.asc translate up to line: 225 --- .../sections/maintaining.asc | 60 ++++++++++--------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 4a311f85..8949ec0a 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -102,9 +102,9 @@ $ git am 0001-limit-log-function.patch Applying: add limit to log function ---- -You can see that it applied cleanly and automatically created the new commit for you. -The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email. -For example, if this patch was applied from the mbox example above, the commit generated would look something like this: +Gördüğünüz gibi, temiz bir şekilde uygulandı ve otomatik olarak yeni bir katkı oluşturuldu. +Yazar bilgileri, e-postanın `From` (gönderici) ve `Date` (tarih) başlıklarından; katkı mesajı, e-postanın `Subject` (konu) ve yamadan önceki gövde kısmından alınır. +Örneğin, yukarıdaki mbox örneğinden uyarlanan bir yama için oluşturulan katkı şöyle görünecektir: [source,console] ---- @@ -120,12 +120,12 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700 Limit log functionality to the first 20 ---- -The `Commit` information indicates the person who applied the patch and the time it was applied. -The `Author` information is the individual who originally created the patch and when it was originally created. +`Commit` (katkı) bilgileri yamayı uygulayan kişiyi ve uygulanma zamanını gösterir. +`Author` (yazar) bilgileri ise özgün yamayı oluşturan kişiyi ve ne zaman oluşturduğunu gösterir. -But it's possible that the patch won't apply cleanly. -Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven't applied yet. -In that case, the `git am` process will fail and ask you what you want to do: +Ama yamanın temiz bir şekilde uygulanamaması ihtimal dahilindedir. +Belki ana dalınız, yamanın oluşturulduğu daldan çok uzaklaşmıştır veya yama henüz uygulamadığınız başka bir yamaya bağlıdır. +Bu durumda, `git am` işlemi başarısız olacak ve ne yapmak istediğinizi size soracaktır: [source,console] ---- @@ -139,8 +139,8 @@ If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". ---- -This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. -You solve this issue much the same way -- edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch: +Bu komut, sorun yaşadığı dosyalara "çatışan birleştirme" veya "yeniden temelleme işlemi" gibi çatışma işaretçileri koyar. +Bu sorunu çözmenin yolu neredeyse aynıdır: dosyayı çatışmayı çözecek şekilde düzenleyin, yeni dosyayı hazırlayın ve ardından bir sonraki yamaya devam etmek için `git am --resolved` komutunu çalıştırın: [source,console] ---- @@ -150,9 +150,9 @@ $ git am --resolved Applying: seeing if this helps the gem ---- -If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge. -This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository. -If you do have that commit -- if the patch was based on a public commit -- then the `-3` option is generally much smarter about applying a conflicting patch: +Eğer Git'in çatışmayı biraz daha akıllıca çözmesini istiyorsanız `-3` seçeneğini kullanarak, Git'in üç yollu bir birleştirme yapmayı denemesini sağlarsınız. +Yama üzerindeki işlenecek olan katkı, sizin reposunuzda bulunmuyorsa çalışmayacağı için, bu seçenek varsayılan olarak etkinleştirilmemiştir. +Eğer o katkı sizin reposunuzda mevcutsa (eğer yama bir halka açık katkıya dayanıyorsa), o zaman `-3` seçeneği genellikle bir çatışmalı yamanın uygulanması konusunda daha akıllıdır: [source,console] ---- @@ -165,10 +165,10 @@ Falling back to patching base and 3-way merge... No changes -- Patch already applied. ---- -In this case, without the `-3` option the patch would have been considered as a conflict. -Since the `-3` option was used the patch applied cleanly. +Yukarıdaki durumda `-3` seçeneği olmasaydı, yama bir çatışma olarak kabul edilirdi. +`-3` seçeneği kullanıldığı için temiz bir şekilde uygulandı. -If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it: +Eğer bir mbox'tan bir dizi yama uyguluyorsanız; her bulduğu yamada durup, onu uygulamak isteyip istemediğinizi soran, etkileşimli `am` komutunu da çalıştırabilirsiniz: [source,console] ---- @@ -180,17 +180,18 @@ seeing if this helps the gem Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ---- -This is nice if you have a number of patches saved, because you can view the patch first if you don't remember what it is, or not apply the patch if you've already done so. +Eğer kaydedilmiş birkaç yamanız varsa ve hangilerini zaten uyguladığınızı veya uygulayacağınızı hatırlayamıyorsanız; öncesinde yamayı görmenize olanak sağladığı için, bu özellik oldukça kullanışlıdır. -When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch. +Bir tema için tüm yamalar uygulandığında ve dalınıza katkı olarak işlendiğinde, bunları uzun vadeli çalışan bir dala birleştirip birleştirmeyeceğinizi veya nasıl birleştireceğinizi seçebilirsiniz. [[_checking_out_remotes]] ==== Checking Out Remote Branches (((branches, remote))) -If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally. -For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally: +Eğer bu katkı; kendi reposunu kuran, bir dizi değişiklik yapıp, buraya iten ve ardından değişikliklerin URL'sini ve değişikliklerin bulunduğu uzak dalın adını size gönderen bir Git kullanıcısından geldiyse, onları bir uzak repo olarak ekleyebilir ve yerel olarak birleştirebilirsiniz. + +Örneğin, Jessica size kendi reposunun `ruby-client` dalında harika bir yeni özellik olduğunu söyleyen bir e-posta gönderirse; onun uzak reposunu ekleyip, bu yerelde dala geçiş yaparak, bu özelliği test edebilirsiniz: [source,console] ---- @@ -199,18 +200,19 @@ $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client ---- -If she emails you again later with another branch containing another great feature, you could directly `fetch` and `checkout` because you already have the remote setup. +Daha sonra, size başka bir harika özelliğe sahip başka bir dalı içeren yeni bir e-posta gönderirse, zaten uzak sunucuyu kurduğunuz için doğrudan `fetch` ve `checkout` yapabilirsiniz. -This is most useful if you're working with a person consistently. -If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. -You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. -However, scripts and hosted services may make this easier -- it depends largely on how you develop and how your contributors develop. +Biriyle sürekli birlikte çalışıyorsanız en kullanışlı olan yöntem budur. +Eğer birisi arada bir ve sadece tek bir yama eklemek istiyorsa, o zaman bu değişiklikleri e-posta yoluyla kabul etmek, herkesin kendi sunucusunu çalıştırmasından ve birkaç yama almak için sürekli olarak uzak sunucular ekleyip, kaldırmasından daha tasarruflu bir zaman yönetimidir. +Ayrıca, muhtemelen yalnızca bir veya iki yama sağlayan herkes için yüzlerce uzak sunucu eklemek istemezsiniz. +Her ne kadar, betikler ve barındırılan hizmetler bu işi kolaylaştırabilse de, bu büyük ölçüde sizin ve katkı sağlayan geliştiricilerin nasıl geliştirme yaptığına bağlıdır. -The other advantage of this approach is that you get the history of the commits as well. -Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access. +Bu yaklaşımın bir diğer avantajı ise geçmişini de almanızdır. +Geçerli birleştirme sorunlarına sahip olabilseniz dahi, bu çalışmalarının geçmişinizde nerede olduğunu bilirsiniz. +Varsayılan olarak sağlanan düzgün bir üç yollu birleştirme, `-3` sağlamak zorunda kalmaktan ve yamanın erişiminiz olan herkese açık bir katkıya dayanmasını ummaktan iyidir. -If you aren't working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. -This does a one-time pull and doesn't save the URL as a remote reference: +Eğer sürekli olarak bir kişiyle çalışmıyor ama yine de yamayı onlardan bu şekilde çekmek istiyorsanız, `git pull` komutuna uzak repo URL'sini girebilirsiniz. +Bu, tek seferlik bir çekme işlemi yapar ama URL'yi uzak bir referans olarak kaydetmez: [source,console] ---- From 1ba46cc7f826b85e9c84cce419c2c48e4a6f2374 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 12 Feb 2024 20:27:51 +0100 Subject: [PATCH 076/210] Update maintaining.asc translate up to line:306 --- .../sections/maintaining.asc | 56 +++++++++---------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 8949ec0a..3081b86b 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -185,7 +185,7 @@ Eğer kaydedilmiş birkaç yamanız varsa ve hangilerini zaten uyguladığınız Bir tema için tüm yamalar uygulandığında ve dalınıza katkı olarak işlendiğinde, bunları uzun vadeli çalışan bir dala birleştirip birleştirmeyeceğinizi veya nasıl birleştireceğinizi seçebilirsiniz. [[_checking_out_remotes]] -==== Checking Out Remote Branches +==== Uzak Dallara Geçmek (((branches, remote))) @@ -223,17 +223,17 @@ Merge made by the 'recursive' strategy. ---- [[_what_is_introduced]] -==== Determining What Is Introduced +==== Katkıları Tanımlamak (((branches, diffing))) -Now you have a topic branch that contains contributed work. -At this point, you can determine what you'd like to do with it. -This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch. +Şimdi, üzerinde katkı yapılan bir tematik dalınız var. +Bu noktada, onunla ne yapmak istediğinizi belirleyebilirsiniz. +Bu bölümde, ana dalınıza bir yamayı birleştirdiğinizde, tam olarak neyi tanıtacağınızı incelemek için birkaç komutu tekrar ele alacağız. -It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch. -You can exclude commits in the master branch by adding the `--not` option before the branch name. -This does the same thing as the `master..contrib` format that we used earlier. -For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this: +Tematik dalda olan, ancak ana dalınızda olmayan tüm katkıların gözden geçirilmesinde fayda vardır. +Ana dalınızda bulunan katkıları bundan hariç tutmak için `--not` seçeneğini dal adının önüne ekleyebilirsiniz. +Bu, daha önce kullandığımız `master..contrib` biçimiyle aynı işlemi yapar. +Örneğin, katkılayıcınız size iki yama gönderirse ve siz `contrib` adında bir dal oluşturup bunları oraya uygularsanız, şunu çalıştırabilirsiniz: [source,console] ---- @@ -251,27 +251,27 @@ Date: Mon Oct 22 19:38:36 2008 -0700 updated the gemspec to hopefully work better ---- -To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit. +Hatırlayacağınız üzere her katkının hangi değişiklikleri içerdiğini görmek için, `git log` komutuna `-p` seçeneğini ekleyebilirsiniz. Ayrıca her katkıyla gelen fark da gösterilecektir. -To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. -You may think to run this: +Ana dal ve tematik dalı birleştirirseniz kodda ne gibi farklılıklar olacağının tam bir resmini görmek isterseniz, doğru sonuçları elde etmek için garip bir hile kullanmanız gerekebilir. +Şunu çalıştırmayı düşünebilirsiniz: [source,console] ---- $ git diff master ---- -This command gives you a diff, but it may be misleading. -If your `master` branch has moved forward since you created the topic branch from it, then you'll get seemingly strange results. -This happens because Git directly compares the snapshots of the last commit of the topic branch you're on and the snapshot of the last commit on the `master` branch. -For example, if you've added a line in a file on the `master` branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line. +Bu komut size bir fark gösterir, ancak sonuç yanıltıcı olabilir. +Eğer `master` dalınız, tematik dalınızı oluşturduğunuzdan bu yana ilerlemişse, çok garip sonuçlar elde edebilirsiniz. +Bunun sebebi, Git'in üzerinde bulunduğunuz tema dalındaki son katkının pozuyla, `master` dalındaki son katkının pozunu doğrudan karşılaştırmasıdır. +Örneğin, `master` dalındaki bir dosyaya bir satır eklerseniz; pozların doğrudan karşılaştırılması, tematik dalın bu satırı kaldıracakmış gibi görünmesine neden olur. -If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch. +Eğer `master` dalı tematik dalınızın doğrudan bir atası ise, bu bir sorun değildir; ancak eğer iki geçmiş ayrıldıysa, fark `master` dalına özgü olan her şeyi kaldırıyor ve tema dalınızdaki tüm yeni şeyleri ekliyormuş gibi görünecektir. -What you really want to see are the changes added to the topic branch -- the work you'll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch. +Gerçekte görmek istediğiniz şey, konu dalına eklenen değişikliklerdir, yani bu dalı ana dala birleştirdiğinizde getireceğiniz çalışma. +Bunu görmek için, Git'in tema dalınızın son katkısını, master üzerindeki ilk ortak atasıyla karşılaştırması neticesinde görebilirsiniz. -Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it: +Teknik olarak bunu yapmanın yolu: ortak atayı açıkça bulup ardından diff'i üzerinde çalıştırmaktır: [source,console] ---- @@ -287,23 +287,23 @@ or, more concisely: $ git diff $(git merge-base contrib master) ---- -However, neither of those is particularly convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. -In the context of the `git diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: +Yine de bunlar özellikle kullanışlı yöntemler değil, bu yüzden Git aynı işi yapmak için başka bir kısaltma sağlar: üç nokta sözdizimi. +`git diff` komutu bağlamında: `diff` yapmak için üzerinde bulunduğunuz dalın son katkısı ile başka bir dalın son ortak atası arasına üç nokta (...) koyabilirsiniz: [source,console] ---- $ git diff master...contrib ---- -This command shows you only the work your current topic branch has introduced since its common ancestor with master. -That is a very useful syntax to remember. +Bu komut, mevcut tema dalınızın, master ile ortak atasından bu yana getirdiği çalışmayı gösterir. +Bu akılda tutmaya değer ve çok kullanışlı bir sözdizimidir. -==== Integrating Contributed Work +==== Katkılanan İşi Birleştirmek (((integrating work))) -When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. -Furthermore, what overall workflow do you want to use to maintain your project? -You have a number of choices, so we'll cover a few of them. +Tema dalınızdaki tüm çalışma, ana dala daha yakın bir dala birleştirilmeye hazır olduğunda, sıradaki soru bunun nasıl yapılacağıdır. +Bunun da ötesinde, projenizi yürütmek için hangi genel iş akışını kullanmak istiyorsunuz? +Şimdi elinizdeki pek çok seçenekten birkaçını ele alacağız. ===== Merging Workflows From c6fc67189de44a48aa0a853f69fa9a6543a95d5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 13 Feb 2024 16:34:39 +0100 Subject: [PATCH 077/210] Update maintaining.asc translate up to line:438 --- .../sections/maintaining.asc | 141 +++++++++--------- 1 file changed, 73 insertions(+), 68 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 3081b86b..31fd662f 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -305,91 +305,95 @@ Tema dalınızdaki tüm çalışma, ana dala daha yakın bir dala birleştirilme Bunun da ötesinde, projenizi yürütmek için hangi genel iş akışını kullanmak istiyorsunuz? Şimdi elinizdeki pek çok seçenekten birkaçını ele alacağız. -===== Merging Workflows +===== İş Akışlarını Birleştirmek (((workflows, merging))) -One basic workflow is to simply merge all that work directly into your `master` branch. -In this scenario, you have a `master` branch that contains basically stable code. -When you have work in a topic branch that you think you've completed, or work that someone else has contributed and you've verified, you merge it into your master branch, delete that just-merged topic branch, and repeat. +En temel iş akışı, tüm çalışmayı doğrudan `master` dalınıza birleştirmektir. +Bu senaryoda, kararlı kodu içeren bir `master` dalınız bulunmaktadır. +Tematik dalda tamamlandığını düşündüğünüz veya bir başkasının katkıda bulunduğu ama sizin onayladığınız bir çalışma varsa, bunu ana dalınıza birleştirir ve artık ihtiyaç duymadığınız tema dalını silersiniz. Bu süreci her defasında tekrar edersiniz. -For instance, if we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <>, and we merge `ruby_client` followed by `php_client`, your history will end up looking like <>. +Örneğin, `ruby_client` ve `php_client` adlı iki dalında çalışma yapılan <> gibi bir repomuz olduğunu varsayalım. +Eğer, önce `ruby_client` ve ardından da `php_client` dalını birleştirirsek, geçmişiniz <> gibi görünecektir. [[merwf_a]] -.History with several topic branches. -image::images/merging-workflows-1.png[History with several topic branches.] +.Bir kaç tematik dallı bir geçmiş. +image::images/merging-workflows-1.png[Bir kaç tematik dallı bir geçmiş.] [[merwf_b]] -.After a topic branch merge. -image::images/merging-workflows-2.png[After a topic branch merge.] +.Bir tema dalını birleştirdikten sonrası. +image::images/merging-workflows-2.png[ABir tema dalını birleştirdikten sonrası.] -That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. +Bu muhtemelen en basit iş akışıdır; ancak neyi değiştirdiğinize çok dikkat ettiğiniz, daha büyük ve istikrarlı projelerle uğraşıyorsanız, sorun yaşayabilirsiniz. -If you have a more important project, you might want to use a two-phase merge cycle. -In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. -You regularly push both of these branches to the public repository. -Each time you have a new topic branch to merge in (<>), you merge it into `develop` (<>); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (<>). +Daha önemli bir projeniz varsa, iki aşamalı bir birleştirme döngüsü kullanmak isteyebilirsiniz. +Bu senaryoda, sadece çok kararlı bir sürüm çıktığında güncellenecek olan `master` ve her yeni kodunuzu üzerinde geliştirip denediğiniz `develop` adında, iki adet uzun ömürlü dalınız var: + +Her iki dalı da düzenli olarak açık reponuza (public repository) itiyorsunuz. +Birleştirilecek yeni bir tema dalınız olduğunda (<>), bunu `develop` dalına birleştirirsiniz (<>); ardından, yeni bir sürüm etiketlediğinizde, `master` dalını ileri sararak (fast-forward) şu anda istikrarlı olan `develop` dalını bulunduğu yere getirirsiniz (<>). [[merwf_c]] -.Before a topic branch merge. -image::images/merging-workflows-3.png[Before a topic branch merge.] +.Tema dalı birleşmesi öncesi. +image::images/merging-workflows-3.png[Tema dalı birleşmesi öncesi.] [[merwf_d]] -.After a topic branch merge. -image::images/merging-workflows-4.png[After a topic branch merge.] +.Tema dalı birleşmesi sonrası. +image::images/merging-workflows-4.png[Tema dalı birleşmesi sonrası.] [[merwf_e]] -.After a project release. -image::images/merging-workflows-5.png[After a topic branch release.] +.Yeni sürümü sonrası. +image::images/merging-workflows-5.png[Yeni sürümü sonrası.] -This way, when people clone your project's repository, they can either check out `master` to build the latest stable version and keep up to date on that easily, or they can check out `develop`, which is the more cutting-edge content. -You can also extend this concept by having an `integrate` branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a `develop` branch; and when that has proven itself stable for a while, you fast-forward your `master` branch. +Bu şekilde, insanlar reponuzu kopyaladığında; ya en son "kararlı" sürümü derlemek ve bunu kolayca güncellemek için `master` dalına geçebilir ya da daha en "güncel" içeriği içeren `develop` dalına. +Ayrıca, tüm çalışmaların birleştirildiği bir `integrate` dalı oluşturarak bu anlayışı genişletebilirsiniz. +Bu dal üzerindeki kod tabanı kararlı hale gelip, testleri geçtiğinde, bunu bir `develop` dalına birleştirebilirsiniz; ve burada kararlı durumu kanıtlandığında, `master` dalınızı bu noktaya doğru ileri sararsınız. -===== Large-Merging Workflows +===== Büyük Birleştirme İş Akışı (((workflows, "merging (large)"))) -The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. -When new work is introduced by contributors, it's collected into topic branches in the maintainer's repository in a manner similar to what we've described (see <>). -At this point, the topics are evaluated to determine whether they're safe and ready for consumption or whether they need more work. -If they're safe, they're merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. +Bu Git projesinde dört uzun ömürlü dal bulunmaktadır: `master`, `next`, yeni güncellemeler için `pu` (proposed updates) ve bakım geri portları için `maint` (maintenance). +Yeni çalışma görücüye çıktığında, bunlar daha önce anlatılana benzer şekilde (bkz <>) yürütücünün reposundaki tema dallarına toplanır (bkz. <>). +Bu noktada, çalışmalar, "güvenilir ve canlıya çıkmaya hazır mı, yoksa üzerinde biraz daha çalışılması mı gerekiyor" kararı verilmek üzere değerlendirilirler. +Güvenilir olanlar `next` dalına birleştirilir ve bu dal herkesin deneyebilmesi için yukarı itilir. [[merwf_f]] -.Managing a complex series of parallel contributed topic branches. -image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] +.Çoklu paralel tema dallarının karmaşıklığını yönetmek. +image::images/large-merges-1.png[Çoklu paralel tema dallarının karmaşıklığını yönetmek.] + +Eğer konular halen geliştirilmeye ihtiyaç duyuyorsa, bunlar `next` yerine `pu` dalına birleştirilir. +Tamamen istikrarlı oldukları belirlendiğinde, yeniden `master` dalına birleştirilirler. +`next` ve `pu` dalları daha sonra `master` dalından yeniden inşa edilir. +Bu, `master` dalının neredeyse her zaman ileri gitmesi, `next` dalının zaman zaman yeniden temellenmesi (rebase) ve `pu` dalının daha da sık yeniden temellenmesi, anlamına gelir: -If the topics still need work, they're merged into `pu` instead. -When it's determined that they're totally stable, the topics are re-merged into `master`. -The `next` and `pu` branches are then rebuilt from the `master`. -This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: +.Katkı sağlanan tema dallarını uzun ömürlü birleşim dallarına birleştirmek. +image::images/large-merges-2.png[Katkı sağlanan tema dallarını uzun ömürlü birleşim dallarına birleştirmek.] -.Merging contributed topic branches into long-term integration branches. -image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] +Bir tema dalı nihayet `master` dalına birleştirildiğinde, artık repodan kaldırılır. +Git projesinin ayrıca son sürümden çatallanmış `maint` adlı bir bakım dalı vardır. +Bu dal, bir bakım sürümü gerektiğinde geriye dönük yamalar sağlamak için kullanılır. -When a topic branch has finally been merged into `master`, it's removed from the repository. -The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. -Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. -The Git project's workflow is specialized. -To clearly understand this you could check out the https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide]. +Bu sistemde, yürütücünün yeni katkıları değerlendirmesine yardımcı olmak için yapılandırılmış özelleştirilmiş bir iş akışı vardır. +Git reposunu kopyaladığınızda, projeye nasıl katkıda bulunmak istediğinize veya geliştirme döngüsünde ne kadar ilerlemek istediğinize bağlı olarak; projenin farklı gelişim aşamalarını gözlemlemek amacıyla geçiş yapabileceğiniz, dört farklı dalınız olur. +Bu iş akışını daha iyi anlamak için https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Yürütücü Kılavuzu]'nu inceleyebilirsiniz. [[_rebase_cherry_pick]] -===== Rebasing and Cherry-Picking Workflows +===== Temelleme ve Ayıklama (Cherry-Picking) İş Akışları (((workflows, rebasing and cherry-picking))) -Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. -When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. -If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. +Diğer yürütücüler, doğrusal bir geçmişe sahip olmak için genellikle için katkılanan çalışmaları master dalının üstüne yeniden temellemeyi (rebase) veya ayıklamayı (cherry-pick) tercih ederler. +Bir tema dalında birleştirmek istediğiniz bir çalışmanız varsa, o dala geçer ve değişiklikleri mevcut `master` (veya `develop`, vb.) dalı üstüne yeniden inşa etmek için temelleme (rebase) komutunu çalıştırırsınız. +Bu işlem sorunsuz tamamlanırsa, `master` dalınızı ileri sarabilir ve sonuçta doğrusal bir proje geçmişine sahip olursunuz. (((git commands, cherry-pick))) -The other way to move introduced work from one branch to another is to cherry-pick it. -A cherry-pick in Git is like a rebase for a single commit. -It takes the patch that was introduced in a commit and tries to reapply it on the branch you're currently on. -This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you'd prefer to cherry-pick it rather than run rebase. -For example, suppose you have a project that looks like this: +Tanıtılan bir çalışmayı bir daldan başka bir dala taşımanın bir diğer yolu da onu ayıklamaktır (cherry-pick). +Git'te ayıklama işlemi, bir tek katkı için bir yeniden temelleme gibidir. +Bir katkıyla yapılan değişiklikleri alır ve bunları şu anda bulunduğunuz dala tekrar uygulamaya çalışır. +Bir tema dalında birkaç katkımız varsa ve bunları ayıklayıp yalnızca birini almak istiyorsanız veya bir tema dalında yalnızca bir katkınız varsa ve yeniden temellemek yerine bunu tercih etmek istiyorsanız, bu özellik kullanışlıdır. +Örneğin, şöyle bir projeniz olduğunu varsayalım: -.Example history before a cherry-pick. -image::images/rebasing-1.png[Example history before a cherry-pick.] +.Ayıklama öncesi örnek geçmiş. +image::images/rebasing-1.png[Ayıklama öncesi örnek geçmiş.] -If you want to pull commit `e43a6` into your master branch, you can run +Eğer `e43a6` katkısını ana dalınıza çekmek istiyorsanız, şunu çalıştırabilirsiniz: [source,console] ---- @@ -399,36 +403,37 @@ Finished one cherry-pick. 3 files changed, 17 insertions(+), 3 deletions(-) ---- -This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. -Now your history looks like this: +Bu, `e43a6` ile tanıtılan değişikliği çeker, ancak uygulanan tarihi farklı olduğu için yeni bir katkı SHA-1 değeri alırsınız. +Artık geçmişiniz şöyle görünür: + -.History after cherry-picking a commit on a topic branch. -image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] +.Tema dalındaki katkı ayıklandıktan sonra geçmiş. +image::images/rebasing-2.png[Tema dalındaki katkı ayıklandıktan sonra geçmiş.] -Now you can remove your topic branch and drop the commits you didn't want to pull in. +Şimdi tema dalınızı kaldırabilir ve içe almak istemediğiniz katkıları atabilirsiniz. ===== Rerere (((git commands, rerere)))(((rerere))) -If you're doing lots of merging and rebasing, or you're maintaining a long-lived topic branch, Git has a feature called ``rerere'' that can help. +Eğer çok sayıda birleştirme ve yeniden temelleme yapıyorsanız veya uzun ömürlü bir tema dalını sürdürüyorsanız; Git'in `rerere` olarak adlandırılan yardımcı bir özelliği vardır. -Rerere stands for ``reuse recorded resolution'' -- it's a way of shortcutting manual conflict resolution. -When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it. +Rerere, "reuse recorded resolution" (kaydedilmiş çözümü yeniden kullan) anlamına gelir ve çakışmaları manuel olarak çözmeniz gerektiğinde kullanabileceğiniz kestirme bir yoldur. +Rerere etkinleştirildiğinde, Git başarılı birleştirmelerin öncel ve ardıl pozlar kümesini saklar; ve eğer daha önce düzelttiğiniz bir çakışma ile tam olarak aynı görünen yeni bir çakışma fark ederse, sizi bununla meşgul etmeden, daha önceki çözümü kullanır. -This feature comes in two parts: a configuration setting and a command. -The configuration setting is `rerere.enabled`, and it's handy enough to put in your global config: +Bu özellik iki kısımdan oluşur: bir yapılandırma ayarı ve bir komut. +Yapılandırma ayarı `rerere.enabled` şeklindedir ve genel yapılandırmanıza eklemek oldukça kullanışlıdır: [source,console] ---- $ git config --global rerere.enabled true ---- -Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future. +Böylece, çakışmaları çözen bir birleştirme yaptığınızda, bu çözüm gelecekte ihtiyaç duymanız ihtimaline binaen önbelleğe kaydedilecektir. -If you need to, you can interact with the rerere cache using the `git rerere` command. -When it's invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if `rerere.enabled` is set to `true`). -There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. -We will cover rerere in more detail in <>. +İhtiyacınız olduğunda, `git rerere` komutunu kullanarak rerere önbelleğiyle etkileşime geçebilirsiniz. +Tek başına çağrıldığında; Git, çözümler veritabanını kontrol ederek, mevcut birleştirme çatışmasıyla bir eşleşme bulmaya ve bunu çözmeye çalışır (`rerere.enabled` yapılandırması `true` olarak ayarlandıysa, bu işlem otomatik olarak yapılır). +Kaydedilecek ögeleri görmek, önbellekten belirli bir çözümü silmek veya tüm önbelleği temizlemek için kullanılabilecek, alt komutlar da vardır. +`rerere` komutunu <> bölümünde daha detaylı olarak ele alacağız. [[_tagging_releases]] ==== Tagging Your Releases From 3a42d1136e5afa728eca559edfb474713081b3d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 13 Feb 2024 20:29:39 +0100 Subject: [PATCH 078/210] Update maintaining.asc translate up to line: 495 --- .../sections/maintaining.asc | 29 ++++++++++--------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 31fd662f..378e4ff5 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -436,12 +436,12 @@ Kaydedilecek ögeleri görmek, önbellekten belirli bir çözümü silmek veya t `rerere` komutunu <> bölümünde daha detaylı olarak ele alacağız. [[_tagging_releases]] -==== Tagging Your Releases +==== Sürümü Etiketlemek (((tags)))(((tags, signing))) -When you've decided to cut a release, you'll probably want to assign a tag so you can re-create that release at any point going forward. -You can create a new tag as discussed in <>. -If you decide to sign the tag as the maintainer, the tagging may look something like this: +Bir sürüm yayımlamaya karar verdiğinizde, bu sürümü gelecekte yeniden oluşturabilmek için etiketlemek isteyebilirsiniz. +Yeni bir etiketi <> bölümünde anlatıldığı gibi oluşturabilirsiniz. +Eğer etiketi yürütücü olarak imzalamaya karar verirseniz, etiketleme işlemi şöyle görünebilir: [source,console] ---- @@ -451,9 +451,9 @@ user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 ---- -If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. -The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. -To do this, you can figure out which key you want by running `gpg --list-keys`: +Etiketlerinizi imzalarsanız, etiketlerinizi imzalamak için kullandığınız genel PGP anahtarını dağıtma sorunuyla karşılaşabilirsiniz. +Git proje yürütücüsü, genel anahtarlarını repoya bir blob olarak dahil edip, ardından doğrudan bu içeriğe işaret eden bir etiket ekleyerek bu sorunu çözmüştür. +Bunu yapmak için, `gpg --list-keys` komutunu çalıştırarak hangi anahtarı kullanmak istediğinizi belirleyebilirsiniz: [source,console] ---- @@ -465,7 +465,8 @@ uid Scott Chacon sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] ---- -Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob: +Daha sonra, anahtarı dışa aktarıp, bu içeriği `git hash-object` üzerinden yönlendirerek, anahtarı doğrudan Git veritabanına aktarabilirsiniz. +Bu şekilde Git, bu içeriğe sahip yeni bir blob oluşturur ve blob'un SHA-1 değerini size geri verir: [source,console] ---- @@ -473,26 +474,26 @@ $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you: +Artık anahtar içeriğiniz Git'te olduğuna göre, `hash-object` komutunun size verdiği yeni SHA-1 değerini belirterek doğrudan ona işaret eden bir etiket oluşturabilirsiniz: [source,console] ---- $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone. -If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG: +`git push --tags` komutunu çalıştırırsanız, `maintainer-pgp-pub` etiketi herkesle paylaşılacaktır. +Bir etiketi doğrulamak isteyen biri; PGP anahtarınızı doğrudan içe aktarmak için, blob'u veritabanından çekip, GPG'ye aktarabilir: [source,console] ---- $ git show maintainer-pgp-pub | gpg --import ---- -They can use that key to verify all your signed tags. -Also, if you include instructions in the tag message, running `git show ` will let you give the end user more specific instructions about tag verification. +Bu anahtar, imzalı tüm etiketlerinizi doğrulamak için kullanabilir. +Ayrıca, etiket mesajında talimatlar eklerseniz; `git show ` komutuyla son kullanıcıya etiket doğrulaması hakkında daha belirli yönergeler verebilirsiniz. [[_build_number]] -==== Generating a Build Number +==== Yapı Numarası Oluşturma (((build numbers)))(((git commands, describe))) Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. From a324b3d71715f4487a65e91dd39bcacbdbf4c3f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 14 Feb 2024 08:39:11 +0100 Subject: [PATCH 079/210] Update maintaining.asc complete translation of ch.5 --- .../sections/maintaining.asc | 41 ++++++++++--------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 378e4ff5..f1f03771 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -496,8 +496,8 @@ Ayrıca, etiket mesajında talimatlar eklerseniz; `git show ` komutuyla ==== Yapı Numarası Oluşturma (((build numbers)))(((git commands, describe))) -Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. -In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git): +Git'in her katkıyla tekdüze olarak artan, 'v123' gibi numaraları veya benzer bir şeyi olmadığından; bir katkıyı insanlar tarafından okunabilir bir isimle eşleştirmek için, o katkı üzerinde `git describe` komutunu çalıştırabilirsiniz. +Bunun sonucunda, Git; o katkıdan önceki en son etiketin adını, arkasından bu etiketten bu katkıya kadar işlenen katkı sayısını ve en arkaya da tanımlanan katkının kısmi SHA-1 değerini içeren bir dize oluşturur (en başa Git'i simgeleyen "g" harfi eklenir): [source,console] ---- @@ -505,21 +505,21 @@ $ git describe master v1.6.2-rc1-20-g8c5b85c ---- -This way, you can export a snapshot or build and name it something understandable to people. -In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this. -If you're describing a commit that you have directly tagged, it gives you simply the tag name. +Bu şekilde, bir poz veya derleme oluşturup okunaklı bir isim verebilirsiniz. +Aslında, eğer Git'i kendi reposundan kopyaladığınız kaynak kodundan derlemişseniz, `git --version` komutu size şuna benzeyen bir çıktı verir. +Eğer doğrudan etiketlediğiniz bir katkıyı tanımlıyorsanız, size sadece etiket adını verir. -By default, the `git describe` command requires annotated tags (tags created with the `-a` or `-s` flag); if you want to take advantage of lightweight (non-annotated) tags as well, add the `--tags` option to the command. -You can also use this string as the target of a `git checkout` or `git show` command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. -For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated. +`git describe` komutu, varsayılan olarak, (`-a` veya `-s` bayrağı ile oluşturulan) dipnotlu etiketlere ihtiyaç duyar. Eğer hafif (dipnotsuz) etiketlerden de faydalanmak istiyorsanız, komuta `--tags` seçeneğini ekleyin. +Bu dizeyi `git checkout` veya `git show` komutunun hedefi olarak da kullanabilirsiniz, ancak sonundaki kısaltılmış SHA-1 değerine dayansa da sonsuza kadar geçerli olmayabilir. +Örneğin, Linux çekirdeği son zamanlarda SHA-1 nesne benzersizliğini sağlamak için 8'den 10 karaktere geçti, bu nedenle eski `git describe` çıktı adları geçersiz hale geldi. [[_preparing_release]] -==== Preparing a Release +==== Bir Sürüm Hazırlama (((releasing)))(((git commands, archive))) -Now you want to release a build. -One of the things you'll want to do is create an archive of the latest snapshot of your code for those poor souls who don't use Git. -The command to do this is `git archive`: +Diyelimk ki şimdi bir sürüm yayımlamak istiyorsunuz. +Bunun için yapmanız gerekenlerden biri, Git'i kullanmayan garibanlar için kodunuzun en son pozunun bir arşivini oluşturmaktır. +Bunun için `git archive` komutunu kullanmalısınız: [source,console] ---- @@ -528,23 +528,24 @@ $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz ---- -If someone opens that tarball, they get the latest snapshot of your project under a project directory. -You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`: +Eğer birisi bu sıkıştırılmış tar dosyasını açarsa, projenizin en son pozunu bir proje dizini altına almış olur. +Aynı şekilde bir zip arşivi de oluşturabilirsiniz, ancak bunu `git archive` komutuna `--format=zip` seçeneğini bağlayarak yapabilirsiniz: [source,console] ---- $ git archive master --prefix='project/' --format=zip > `git describe master`.zip ---- -You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people. +Artık projenizin sürümünün, web sitenize yükleyebileceğiniz veya birilerine e-posta ile gönderebileceğiniz, güzel bir tar dosyası ve zip arşivi vardır. [[_the_shortlog]] -==== The Shortlog +==== Kısa Günlük (((git commands, shortlog))) -It's time to email your mailing list of people who want to know what's happening in your project. -A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the `git shortlog` command. -It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1: +Artık, projenizdeki son değişiklikler hakkında bilgi sahibi olmak isteyenlere bir e-posta gönderme zamanı geldi. +Son sürüm veya e-postanızdan bu yana projenizde yapılan değişiklikleri tutan değişim günlüğünü hızlıca elde etmek için `git shortlog` komutunu kullanabilirsiniz. +Bu komut, veerdiğiniz aralıktaki tüm katkıları özetler. +Örneğin, son sürümünüz v1.0.1 ise, aşağıdaki komut size son sürümünüzden bu yana yapılan tüm katkıların bir özetini verir: [source,console] ---- @@ -564,4 +565,4 @@ Tom Preston-Werner (4): Regenerated gemspec for version 1.0.2 ---- -You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list. +v1.0.1'den bu yana yapılan tüm katkıların yazarlarına göre gruplandırılmış temiz bir özet elde eder ve ardından bu özeti listenize e-posta olarak gönderebilirsiniz. From c6b378e1f70106ee2e7c61a68dfa15174dd02ed6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 14 Feb 2024 18:15:47 +0100 Subject: [PATCH 080/210] Update 1-setting-up-account.asc translate up to line: 94 --- .../sections/1-setting-up-account.asc | 112 +++++++++--------- 1 file changed, 59 insertions(+), 53 deletions(-) diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 56fc5c84..8bc93354 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,91 +1,97 @@ -=== Account Setup and Configuration +=== Hesap Kurulumu ve Yapılandırma (((GitHub, user accounts))) -The first thing you need to do is set up a free user account. -Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. +İlk yapmanız gereken şey ücretsiz bir kullanıcı hesabı oluşturmaktır. +https://github.com[] adresine gidin, henüz alınmamış bir kullanıcı adı seçin, e-posta adresinizi girin ve bir şifre belirleyin, ardından büyük yeşil "Sign up for GitHub" düğmesine tıklayın. +[NOT] +==== +Bu kitabın Türçeye çevrildiği tarih (2023 Şubat) itibariyle GitHub sayfası henüz Türkçe hizmet sunmadığı için, size daha net bir yönerge sunabilmek amacıyla arayüz ögeleri (sekme, bölüm, düğme vb) İngilizce orijinal haliyle bırakılmıştır. +==== -.The GitHub sign-up form. -image::images/signup.png[The GitHub sign-up form.] +.GitHub kayıt formu. +image::images/signup.png[GitHub kayıt formu.] -The next thing you'll see is the pricing page for upgraded plans, but it's safe to ignore this for now. -GitHub will send you an email to verify the address you provided. -Go ahead and do this; it's pretty important (as we'll see later). +Göreceğiniz bir sonraki şey, yükseltilmiş planların fiyatlandırma sayfasıdır, ancak şimdilik bunu yok sayabilirsiniz. +GitHub, e-posta adresinizi doğrulamak için size bir e-posta gönderecektir. +İşleme devam edin ve şunu yapın: çok önemlidir (daha sonra göreceğimiz gibi). -[NOTE] +[NOT] ==== -GitHub provides all of its functionality with free accounts, with the limitation that all of your projects are fully public (everyone has read access). -GitHub's paid plans also include the option of creating private projects, but we won't be covering those in this book. +Ü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. ==== -Clicking the Octocat logo at the top-left of the screen will take you to your dashboard page. -You're now ready to use GitHub. +Ekranın sol üst köşesindeki Octocat (sekiz kollu kedi) logosuna tıklamak sizi gösterge panelinize götürecektir. +Artık GitHub'ı kullanmaya hazırsınız. -==== SSH Access +==== SSH Erişimi (((SSH keys, with GitHub))) -As of right now, you're fully able to connect with Git repositories using the `https://` protocol, authenticating with the username and password you just set up. -However, to simply clone public projects, you don't even need to sign up - the account we just created comes into play when we fork projects and push to our forks a bit later. +Şu anda, `https://` protokolünü kullanarak doğrudan Git repolarına bağlanabilir; yeni oluşturduğunuz kullanıcı adı ve şifrenizle kimlik doğrulaması yapabilirsiniz. +Kaydolmaya bile gerek duymadan açık projeleri kopyalayabilirsiniz. +Projeleri çatallamak ve çatallarımıza katkılarımızı itmek için oluşturduğumuz hesap anında devreye girer. -If you'd like to use SSH remotes, you'll need to configure a public key. -(If you don't already have one, see <>.) -Open up your account settings using the link at the top-right of the window: +Uzak SSH sunucularını kullanmak istiyorsanız, bir açık anahtar yapılandırmanız gerekecektir. +(Eğer anahtarınız yoksa, <> bölümüne bakın.) +Pencerenin sağ üst köşesindeki bağlantıyı kullanarak hesap ayarlarınızı açın: -.The ``Account settings'' link. -image::images/account-settings.png[The ``Account settings'' link.] +."Account Settings" (hesap ayarları) bağlantısı. +image::images/account-settings.png["Account Settings" (hesap ayarları) bağlantısı.] -Then select the ``SSH keys'' section along the left-hand side. +Ardından sol taraftaki "SSH keys" (SSH anahtarı) bölümünü seçin. -.The ``SSH keys'' link. -image::images/ssh-keys.png[The ``SSH keys'' link.] +."SSH anahtarı" bağlantısı. +image::images/ssh-keys.png["SSH anahtarı" bağlantısı.] -From there, click the "`Add an SSH key`" button, give your key a name, paste the contents of your `~/.ssh/id_rsa.pub` (or whatever you named it) public-key file into the text area, and click ``Add key''. +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. -[NOTE] +[NOT] ==== -Be sure to name your SSH key something you can remember. -You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for. +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. + ==== [[_personal_avatar]] -==== Your Avatar +==== Avatarınız -Next, if you wish, you can replace the avatar that is generated for you with an image of your choosing. -First go to the ``Profile'' tab (above the SSH Keys tab) and click ``Upload new picture''. +Sonraki adımda, isterseniz size varsayılan olarak atanan avatarı, kendi seçtiğiniz bir resimle değiştirebilirsiniz. +İlk olarak, "Profile" (profil) sekmesine gidin (SSH Anahtarları sekmesinin üstünde) ve `Upload new picture` "Yeni resim yükle"yi tıklayın. -.The ``Profile'' link. -image::images/your-profile.png[The ``Profile'' link.] +."Profile" bağlantısı. +image::images/your-profile.png["Profile" bağlantısı.] -We'll choose a copy of the Git logo that is on our hard drive and then we get a chance to crop it. +Bilgisayarınızdan Git logosunun bir kopyasını seçip, ardından onu kırpma şansı elde edeceksiniz. -.Crop your avatar -image::images/avatar-crop.png[Crop your uploaded avatar.] +.Avatarınızı kırpın +image::images/avatar-crop.png[Yüklediğiniz Avatarı kırpın.] -Now anywhere you interact on the site, people will see your avatar next to your username. +Şimdi sayfa üzerinde etkileşimde bulunduğunuz her yerde, insanlar kullanıcı adınızın yanında avatarınızı görecekler. -If you happen to have uploaded an avatar to the popular Gravatar service (often used for Wordpress accounts), that avatar will be used by default and you don't need to do this step. +Eğer popüler Gravatar servisine (çoğunlukla Wordpress hesapları için kullanılır) bir avatar yüklediyseniz, varsayılan olarak o avatar kullanılacaktır; haliyle bu adımı yapmanıza gerek yoktur. -==== Your Email Addresses +==== E-Posta Adresleri -The way that GitHub maps your Git commits to your user is by email address. -If you use multiple email addresses in your commits and you want GitHub to link them up properly, you need to add all the email addresses you have used to the Emails section of the admin section. +GitHub'ın Git katkılarını kullanıcıya eşlemesinin yolu e-posta adresiyle olur. +Birden fazla e-posta adresi kullanıyorsanız ve GitHub'ın bunları doğru şekilde bağlamasını istiyorsanız, kullandığınız tüm e-posta adreslerini "admin" (yönetim) bölümünün E-postalar bölümüne eklemeniz gerekir. [[_add_email_addresses]] -.Add email addresses -image::images/email-settings.png[Add all your email addresses.] +.E-posta adresi ekleme +image::images/email-settings.png[Tüm e-posta adreslerinizi ekleyin.] -In <<_add_email_addresses>> we can see some of the different states that are possible. -The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. -The second address is verified and so can be set as the primary if you wish to switch them. -The final address is unverified, meaning that you can't make it your primary address. -If GitHub sees any of these in commit messages in any repository on the site, it will be linked to your user now. +<<_add_email_addresses>> bağlantısında olası farklı durumları görebiliriz. +En üstteki adres doğrulanmış ve birincil adres olarak ayarlanmıştır, bu nedenle tüm bildirim ve alıntılar buraya gönderilecektir. +İkinci adres doğrulanmıştır ve dolayısıyla değiştirmek istediğinizde bunu birincil olarak ayarlayabilirsiniz. +Son adres doğrulanmamıştır, bu da onu birincil adresiniz olarak belirleyemeyeceğiniz anlamına gelir. +GitHub bu adreslerden herhangi birini sayfasındaki herhangi bir repodaki katkı mesajında görürse, bu katkıyla kullanıcıyı ilişkilendirecektir. -==== Two Factor Authentication +==== Çift Faktörlü Kimlik Doğrulama -Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. -Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. -Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account. +Son olarak, ekstra güvenlik için kesinlikle Çift Faktörlü Kimlik Doğrulama veya "2FA" kurmanız tavsiye edilir. +İki Faktörlü Kimlik Doğrulama, şifrenizin bir şekilde çalınması durumunda hesabınızın tehlikeye girme riskini azaltmak için geliştirilmiş ve son zamanlarda giderek daha popüler hale gelen bir kimlik doğrulama mekanizmasıdır. +Bunun etkinleştirilmesi, GitHub'ın sizden iki farklı doğrulama yöntemi istemesine neden olur; böylece biri tehlikeye girerse, saldırganın hesabınıza erişim sağlaması engellenir. -You can find the Two-factor Authentication setup under the Security tab of your Account settings. +İki Faktörlü Kimlik Doğrulama kurulumunu Hesap ayarlarınızın (Account Settings), Güvenlik (Security) sekmesinde bulabilirsiniz. .2FA in the Security Tab image::images/2fa-1.png[2FA in the Security Tab] From d259c4c9a5c5592b8bff9cd5c078ce1e7f4a4b24 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 14 Feb 2024 22:11:52 +0100 Subject: [PATCH 081/210] Update 1-setting-up-account.asc translate complate page --- .../sections/1-setting-up-account.asc | 25 ++++++++----------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 8bc93354..26d44de8 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -3,10 +3,6 @@ (((GitHub, user accounts))) İlk yapmanız gereken şey ücretsiz bir kullanıcı hesabı oluşturmaktır. https://github.com[] adresine gidin, henüz alınmamış bir kullanıcı adı seçin, e-posta adresinizi girin ve bir şifre belirleyin, ardından büyük yeşil "Sign up for GitHub" düğmesine tıklayın. -[NOT] -==== -Bu kitabın Türçeye çevrildiği tarih (2023 Şubat) itibariyle GitHub sayfası henüz Türkçe hizmet sunmadığı için, size daha net bir yönerge sunabilmek amacıyla arayüz ögeleri (sekme, bölüm, düğme vb) İngilizce orijinal haliyle bırakılmıştır. -==== .GitHub kayıt formu. image::images/signup.png[GitHub kayıt formu.] @@ -35,13 +31,13 @@ Uzak SSH sunucularını kullanmak istiyorsanız, bir açık anahtar yapılandır (Eğer anahtarınız yoksa, <> bölümüne bakın.) Pencerenin sağ üst köşesindeki bağlantıyı kullanarak hesap ayarlarınızı açın: -."Account Settings" (hesap ayarları) bağlantısı. -image::images/account-settings.png["Account Settings" (hesap ayarları) bağlantısı.] +."Account Settings" (Hesap Ayarları) bağlantısı. +image::images/account-settings.png["Account Settings" (Hesap Ayarları) bağlantısı.] Ardından sol taraftaki "SSH keys" (SSH anahtarı) bölümünü seçin. -."SSH anahtarı" bağlantısı. -image::images/ssh-keys.png["SSH anahtarı" bağlantısı.] +."SSH keys" (SSH anahtarı) bağlantısı. +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. @@ -49,7 +45,6 @@ Buradan, `Add an SSH key` (Bir SSH anahtarı ekle) düğmesine tıklayın, anaht ==== 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. - ==== [[_personal_avatar]] @@ -58,8 +53,8 @@ Her bir anahtarınızı ayrıcı adlandırabilirsiniz (örneğin "Bilgisayarım" Sonraki adımda, isterseniz size varsayılan olarak atanan avatarı, kendi seçtiğiniz bir resimle değiştirebilirsiniz. İlk olarak, "Profile" (profil) sekmesine gidin (SSH Anahtarları sekmesinin üstünde) ve `Upload new picture` "Yeni resim yükle"yi tıklayın. -."Profile" bağlantısı. -image::images/your-profile.png["Profile" bağlantısı.] +."Profile" (profil) bağlantısı. +image::images/your-profile.png["Profile" (profil) bağlantısı.] Bilgisayarınızdan Git logosunun bir kopyasını seçip, ardından onu kırpma şansı elde edeceksiniz. @@ -93,9 +88,9 @@ Bunun etkinleştirilmesi, GitHub'ın sizden iki farklı doğrulama yöntemi iste İki Faktörlü Kimlik Doğrulama kurulumunu Hesap ayarlarınızın (Account Settings), Güvenlik (Security) sekmesinde bulabilirsiniz. -.2FA in the Security Tab -image::images/2fa-1.png[2FA in the Security Tab] +.Güvenlik (Security) Sekmesinde 2FA +image::images/2fa-1.png[Güvenlik (Security) Sekmesinde 2FA] -If you click on the ``Set up two-factor authentication'' button, it will take you to a configuration page where you can choose to use a phone app to generate your secondary code (a ``time based one-time password''), or you can have GitHub send you a code via SMS each time you need to log in. +"Set up two-factor authentication" (çift faktörlü kimlik doğrulaması kurulumu) düğmesine tıklarsanız; sizi, ikincil kodunuzu (tek kullanımlı anlık şifre) oluşturmak için bir telefon uygulaması kullanmayı seçebileceğiniz veya GitHub'ın her girişinizde size SMS yoluyla bir giriş kodu göndermesini tercih edebileceğiniz bir yapılandırma sayfasına yönlendirecektir. -After you choose which method you prefer and follow the instructions for setting up 2FA, your account will then be a little more secure and you will have to provide a code in addition to your password whenever you log into GitHub. +Tercih ettiğiniz yöntemi belirledikten ve 2FA kurulum talimatlarını izledikten sonra, hesabınız nispeten daha güvenli olacak ve GitHub'a her giriş yapmak istediğinizde, şifrenizin yanı sıra bir kod sağlamanız gerekecektir. From a946c6ef32ba01a4603f87f6fe951e318c01f8c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 14 Feb 2024 23:22:03 +0100 Subject: [PATCH 082/210] Update 2-contributing.asc translate up to line: 31 --- book/06-github/sections/2-contributing.asc | 33 +++++++++++----------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index edcc081a..064659fc 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -1,33 +1,34 @@ -=== Contributing to a Project +=== Bir Projeye Katkıda Bulunmak -Now that our account is set up, let's walk through some details that could be useful in helping you contribute to an existing project. +Artık bir Github hesabınız olduğuna göre, mevcut bir projeye katkıda bulunmakta yardımcı olabilecek bazı ayrıntıları gözden geçirelim. -==== Forking Projects +==== Projeleri Çatallamak (((forking))) -If you want to contribute to an existing project to which you don't have push access, you can ``fork'' the project. -When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it. +Bir erişim izniniz olmayan projeye katkıda bulunmak istiyorsanız, projeyi "çatallayabilirsiniz" (fork). +Bir projeyi "çataladığınızda", GitHub projenin tamamen size ait bir kopyasını oluşturur; bu, sizin derleminizde (derlem: namespace) bulunur ve üzerine değişikliklerinizi itebilirsiniz. -[NOTE] +[NOT] ==== -Historically, the term ``fork'' has been somewhat negative in context, meaning that someone took an open source project in a different direction, sometimes creating a competing project and splitting the contributors. -In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner. +"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. ==== -This way, projects don't have to worry about adding users as collaborators to give them push access. -People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next. -This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in. +Bu şekilde, kullanıcıları katkılayıcı olarak eklemek ve itme erişimi vermek gibi işlerle uğraşmak zorunda kalınmaz. +İnsanlar bir projeyi çatallayabilir, kodlarını itebilir ve (bir sonraki adımda ele alacağımız üzere) değişikliklerini birleştirerek orijinal repoya katkıda bulunmak amacıyla bir birleştirme isteği (pull request) gönderebilirler. +Böylece, proje sahibi ve katkıda bulunanlar arasında değişiklikler üzerine bir müzakere başlar. +Proje sahibi değişikliklerden memnun olduğu noktada bu değişiklikleri birleştirebilir. -To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page. +Bir projeyi çatallamak için, projenin sayfasını ziyaret edin ve sayfanın sağ üst köşesindeki "Fork" (çatalla) düğmesine tıklayın. -.The ``Fork'' button. -image::images/forkbutton.png[The ``Fork'' button.] +."Fork" (Çatalla) düğmesi. +image::images/forkbutton.png["Fork" (Çatalla) düğmesi.] -After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code. +Birkaç saniye sonra, kendi yazılabilir kodunuzun bir kopyasıyla yeni proje sayfanıza yönlendirileceksiniz. [[ch06-github_flow]] -==== The GitHub Flow +==== GitHub Akışı (((GitHub, Flow))) GitHub is designed around a particular collaboration workflow, centered on Pull Requests. From de379af6c2b6dfcd503ee366ee3fea969cdb396c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 15 Feb 2024 08:50:04 +0100 Subject: [PATCH 083/210] Update 2-contributing.asc translate upto line:145 --- book/06-github/sections/2-contributing.asc | 90 +++++++++++----------- 1 file changed, 47 insertions(+), 43 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 064659fc..b1cf71ff 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -31,39 +31,39 @@ Birkaç saniye sonra, kendi yazılabilir kodunuzun bir kopyasıyla yeni proje sa ==== GitHub Akışı (((GitHub, Flow))) -GitHub is designed around a particular collaboration workflow, centered on Pull Requests. -This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. -It is centered on the <> workflow covered in <>. +GitHub, birleştirme isteklerine odaklanan belirli bir iş birliği iş akışı etrafında tasarlanmıştır. +Bu akış, ister tek bir ortak repoda sıkı işbirliği yapan bir ekiple, ister düzinelerce çatalı olan bir projeye katkıda bulunan ama birbirini tanımayan yabancılarla, isterse dünyanın dört bir yanında ofisleri bulunan küresel bir şirket için çalışın, sorunsuz bir şekilde çalışır. +Bu, <> bölümünde ele alınmış olan <> iş akışına odaklanmıştır. -Here's how it generally works: +Genel olarak nasıl çalıştığı şöyle özetlenebilir: -1. Fork the project -2. Create a topic branch from `master`. -3. Make some commits to improve the project. -4. Push this branch to your GitHub project. -5. Open a Pull Request on GitHub. -6. Discuss, and optionally continue committing. -7. The project owner merges or closes the Pull Request. -8. Sync the updated master back to your fork. +1. fork: Projeyi çatallayın. +2. branch: `master` dalından konu bazlı (tematik) bir dal çıkarın. +3. commit: Projeyi geliştirmek için katkılar işleyin. +4. push: Bu dalı GitHub projenize itin. +5. pull Request: GitHub'ta bir birleştirme isteği açın. +6. Değişiklikleri proje sahibiyle tartışın ve katkı işlemeye devam edin. +7. merge: Proje sahibi değişiklikleri ana dala birleştirir veya birleştirme isteğini reddeder. +8. pull: Kendi çatalınızı güncellenmiş ana dala eşleyin. -This is basically the Integration Manager workflow covered in <>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. +Bu temel olarak <> bölümünde ele alınan Birleştirme Yöneticisi iş akışıdır, ancak değişiklikleri iletmek ve incelemek için e-posta yerine ekipler GitHub'ın ağ tabanlı araçlarını kullanır. -Let's walk through an example of proposing a change to an open source project hosted on GitHub using this flow. +Örnek olarak, GitHub'da bulunan bir açık kaynak projesine, bu akışı kullanarak bir değişiklik önerisini birlikte inceleyelim. -===== Creating a Pull Request +===== Birleştirme İsteği Oluşturmak -Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[]. +Diyelim ki, Arduino programlanabilir mikrodenetleyicisinde çalıştırmak için kod arayan Tony https://github.com/schacon/blink[] adresinde harika bir program dosyası bulur. -.The project we want to contribute to. -image::images/blink-01-start.png[The project we want to contribute to.] +.Katkıda bulunmak istediğimiz proje. +image::images/blink-01-start.png[TKatkıda bulunmak istediğimiz proje.] -The only problem is that the blinking rate is too fast. -We think it's much nicer to wait 3 seconds instead of 1 in between each state change. -So let's improve the program and submit it back to the project as a proposed change. +Tek sorun, yanıp sönme hızının çok yüksek olması. +Her ışıltı arasında 1 saniye yerine 3 saniye beklemenin çok daha iyi olduğunu düşünüyoruz. +Bu yüzden programı iyileştirelim ve bir değişiklik önerisi olarak projeye geri gönderelim. -First, we click the 'Fork' button as mentioned earlier to get our own copy of the project. -Our user name here is ``tonychacon'' so our copy of this project is at `https://github.com/tonychacon/blink` and that's where we can edit it. -We will clone it locally, create a topic branch, make the code change and finally push that change back up to GitHub. +Öncelikle, kendi kopyamızını almak için yukarıda belirtildiği gibi 'Fork' düğmesine tıklıyoruz. +Kullanıcı adımız burada "tonychacon" olduğu için kendi kopyamızı `https://github.com/tonychacon/blink` adresinde bulabilir ve burada düzenleyebiliriz. +Yerel olarak kopyalayacak, bir tema dalı oluşturacak, kod değişikliği yapacak ve son olarak bu değişikliği GitHub'a geri iteceğiz. [source,console] ---- @@ -108,35 +108,39 @@ To https://github.com/tonychacon/blink * [new branch] slow-blink -> slow-blink ---- -<1> Clone our fork of the project locally -<2> Create a descriptive topic branch -<3> Make our change to the code -<4> Check that the change is good -<5> Commit our change to the topic branch -<6> Push our new topic branch back up to our GitHub fork +<1> Projemizin kendi çatalını yerel olarak kopyalayın. +<2> Açıklayıcı bir tema dalı oluşturun. +<3> Kodda değişiklik yapın. +<4> Değişikliğin iyi olduğundan emin olun. +<5> Değişikliği tema dalına katkı olarak işleyin. +<6> Yeni tema dalınzı GitHub çatalınıza geri itin. -Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project. +Şimdi GitHub'daki çatalımıza geri dönersek; GitHub'ın yeni tema dalını ittiğinizi fark ettiğini, değişikliklerimizi kontrol etmek ve orijinal projeye bir Birleştirme İsteği açmak için büyük yeşil bir düğme sunduğunu görebiliriz. -You can alternatively go to the ``Branches'' page at `https://github.com///branches` to locate your branch and open a new Pull Request from there. +Alternatif olarak, `//dal` (örnekte: tonychacon/blink/tema_dalı) adresindeki "Branches" (dallar) sayfasına giderek dalınızı bulabilir ve oradan yeni bir birleştirme isteği açabilirsiniz. -.Pull Request button -image::images/blink-02-pr.png[Pull Request button] + + +.Birleştirme isteği düğmesi +image::images/blink-02-pr.png[Birleştirme isteği düğmesi] (((GitHub, pull requests))) -If we click that green button, we'll see a screen that asks us to give our Pull Request a title and description. -It is almost always worthwhile to put some effort into this, since a good description helps the owner of the original project determine what you were trying to do, whether your proposed changes are correct, and whether accepting the changes would improve the original project. +Yeşil düğmeye tıklarsak, birleştirme isteğimize bir başlık ve açıklama vermemizi isteyen bir ekran görürüz. +Genellikle buna biraz çaba harcamak faydalı olur, çünkü iyi bir açıklama, orijinal projenin sahibinin ne yapmaya çalıştığınızı, önerdiğiniz değişikliklerin doğru olup olmadığını ve değişikliklerin kabul edilmesinin orijinal projeyi iyileştirip iyileştirmeyeceğini belirlemesine yardımcı olur. -We also see a list of the commits in our topic branch that are ``ahead'' of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner. +Ayrıca, `master` dalından önde (ahead) olan tema dalımızdaki katkıların bir listesini (bu senaryoda sadece bir tane) ve bu dalın projenin sahibi tarafından birleştirilmesi durumunda yapılacak tüm değişikliklerin birleştirilmiş bir farkını görürüz. -.Pull Request creation page -image::images/blink-03-pull-request-open.png[Pull Request creation] -When you hit the 'Create pull request' button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it. +."Birleştirme İsteği" oluşturma sayfası +image::images/blink-03-pull-request-open.png["Birleştirme İsteği" oluşturma] -[NOTE] +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] ==== -Though Pull Requests are used commonly for public projects like this when the contributor has a complete change ready to be made, it's also often used in internal projects _at the beginning_ of the development cycle. -Since you can keep pushing to the topic branch even *after* the Pull Request is opened, it's often opened early and used as a way to iterate on work as a team within a context, rather than opened at the very end of the process. +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. +Genellikle projenin sonunda değil, başında açılır; işi ekipçe, bir bağlam içinde ardışık yapabilmek için bir yol olarak kullanılır. ==== ===== Iterating on a Pull Request From 257d67cd9832f1f440b0567339aa62ed6fccf950 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:12:48 +0100 Subject: [PATCH 084/210] Update 2-contributing.asc translate up to line: 108 --- book/06-github/sections/2-contributing.asc | 82 +++++++++++----------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index b1cf71ff..d7a1c163 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -143,70 +143,70 @@ Birleştirme İstekleri genellikle katkı sağlayan kişi tamamlanmış bir değ Genellikle projenin sonunda değil, başında açılır; işi ekipçe, bir bağlam içinde ardışık yapabilmek için bir yol olarak kullanılır. ==== -===== Iterating on a Pull Request +===== Birleştirme İsteği Tekrarı -At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. -Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on. +Bu noktada, proje sahibi önerilen değişikliği inceleyebilir, birleştirebilir, reddedebilir veya üzerine yorum yapabilir. Diyelim ki fikri beğendi, ancak ışığın kapalı kalma süresinin, açık kalma süresinden biraz daha uzun sürmesini tercih etti. -Where this conversation may take place over email in the workflows presented in <>, on GitHub this happens online. -The project owner can review the unified diff and leave a comment by clicking on any of the lines. +Bu konuşma, GitHub üzerinde çevrimiçi olarak gerçekleşirken, <> bölümünde sunulan iş akışlarında e-posta üzerinden gerçekleşir. +Proje sahibi, birleştirilmiş farkı gözden geçirebilir ve herhangi bir satıra tıklayarak bir yorum bırakabilir. -.Comment on a specific line of code in a Pull Request -image::images/blink-04-pr-comment.png[PR line comment] +.Birleştirme isteğindeki belirli bir kod satırına yorum yapmak +image::images/blink-04-pr-comment.png[Birleştirme isteği satır yorumu] -Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. -We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this: +Yönetici bu yorumu yaptıktan sonra, isteği açan kişi (ve hatta repoyu izleyen herkes) bir bildirim alır. +Bunu özelleştirmeyi daha sonra ele alacağız, ancak e-posta bildirimlerini açmış olsaydı, Tony şöyle bir e-posta alırdı: [[_email_notification]] -.Comments sent as email notifications -image::images/blink-04-email.png[Email notification] +.E-posta bildirimi olarak gönderilen yorum +image::images/blink-04-email.png[E-posta bildirimi] -Anyone can also leave general comments on the Pull Request. -In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. -You can see that the code comments are brought into the conversation as well. +Ayrıca herkes bu birleştirme isteği üzerine herkese açık yorumlar da yapabilir. +<<_pr_discussion>> bölümünde, projenin sahibinin hem bir kod satırına yorum yapması, hem de tartışma bölümünde genel bir yorum bırakması örneğini görebilirsiniz. +Kod yorumlarının da konuşmaya dahil edildiğini görebilirsiniz. [[_pr_discussion]] -.Pull Request discussion page -image::images/blink-05-general-comment.png[PR discussion page] +.Birleştirme isteği tartışma sayfası +image::images/blink-05-general-comment.png[Birleştirme isteği tartışma sayfası] -Now the contributor can see what they need to do in order to get their change accepted. -Luckily this is very straightforward. -Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push, which will automatically update the Pull Request. -In <<_pr_final>> you can also see that the old code comment has been collapsed in the updated Pull Request, since it was made on a line that has since been changed. +Şimdi katkılayıcı, değişikliklerinin kabul edilmesi için yapması gerekenleri görebilir. +Neyse ki bu çok basittir. +E-posta üzerinden serinizi tekrar oluşturup, posta listesine yeniden göndermeniz gerekirken; GitHub'ta sadece konu dalına tekrar katkı işleyip iterseniz, birleştirme isteği otomatik olarak güncellenir. +<<_pr_final>> bölümünde, güncellenen bir birleştirme isteğindeki eski kod yorumunun, artık değiştirilmiş bir satıra yapıldığı için daraltıldığını görebilirsiniz. -Adding commits to an existing Pull Request doesn't trigger a notification, so once Tony has pushed his corrections he decides to leave a comment to inform the project owner that he made the requested change. +Varolan bir birleştirme talebine yeni katkılar işlemek, bir bildirim tetiklemez; bu yüzden Tony düzeltmelerini ittikten sonra, proje sahibine istenen değişikliği yaptığını bildirmek için bir yorum bırakmaya karar verir. [[_pr_final]] -.Pull Request final -image::images/blink-06-final.png[PR final] +.Birleştirme isteği kapanışı +image::images/blink-06-final.png[Birleştirme isteği kapanışı] -An interesting thing to notice is that if you click on the ``Files Changed'' tab on this Pull Request, you'll get the ``unified'' diff -- that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. -In `git diff` terms, it basically automatically shows you `git diff master...` for the branch this Pull Request is based on. -See <> for more about this type of diff. +Bu birleştirme talebinin "Files Changed" (Değiştirilen Dosyalar) sekmesine tıklarsanız, "bileşke fark"ı alırsınız; yani, bu konu dalı birleştirildiğinde, ana dalınıza kaynaşacak olan tüm kod farkını. +`git diff` terimi, temelde bu birleştirme isteğinin dayandığı dal için `git diff master...` komut çıktısını site otomatik olarak gösterir. +Bu tür bir fark hakkında daha fazla bilgi için <> bölümüne bakın. -The other thing you'll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. -This button only shows up if you have write access to the repository and a trivial merge is possible. -If you click it GitHub will perform a ``non-fast-forward'' merge, meaning that even if the merge *could* be a fast-forward, it will still create a merge commit. +Diğer bir dikkat çekici nokta ise; GitHub'ın birleştirme isteğinin temiz bir şekilde birleştirilip birleştirilemeyeceğini kontrol etmesi ve birleştirmeyi sunucuda yapmak için bir düğme oluşturmasıdır. +Bu düğme, repoya yazma erişiminiz varsa ve basit birleşme mümkünse görünür. +Tıklarsanız, GitHub "ileri-sarma" (fast-forward) *olabilecek durumlarda* bile "ileri-sarmayan" (non-fast-forward) birleşmesi gerçekleştirir ve bir birleştirme katkısı oluşturur. -If you would prefer, you can simply pull the branch down and merge it locally. -If you merge this branch into the `master` branch and push it to GitHub, the Pull Request will automatically be closed. +Tercih ederseniz, basitçe dalı çekip (pull), yerelde birleştirebilirsiniz (merge). +Bu dalı `master` dala birleştirir ve GitHub'a iterseniz, birletşirme isteği otomatik olarak kapanır. -This is the basic workflow that most GitHub projects use. -Topic branches are created, Pull Requests are opened on them, a discussion ensues, possibly more work is done on the branch and eventually the request is either closed or merged. +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. -[NOTE] -.Not Only Forks + +[NOT] +.Çatal zorunlu değil ==== -It's important to note that you can also open a Pull Request between two branches in the same repository. -If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. -No forking necessary. +Önemli bir nokta da, aynı repodaki iki dal arasında da bir birleştirme isteği açabileceğinizdir. +Bir özellik üzerinde birileriyle birlikte çalışıyorsanız ve her ikininin de projeye yazma erişimi varsa; bir konu dalını repoya itebilir; ardından üzerinde tartışma ve kod incelemesi sürecini başlatmak için, aynı projenin `master` dalına bir birleştirme talebi açabilirsiniz. +Çatallamanız gerekmez. ==== -==== Advanced Pull Requests +==== Gelişmiş Birleştirme İstekleri -Now that we've covered the basics of contributing to a project on GitHub, let's cover a few interesting tips and tricks about Pull Requests so you can be more effective in using them. +GitHub'daki bir projeye katkıda bulunmanın temellerini öğrendikten sonra, birleştirme istekleriyle ilgili birkaç ilginç ipucunu ve püf noktasını öğrenelim; böylece onları daha etkili bir şekilde kullanabilirsiniz. -===== Pull Requests as Patches +===== Yama Olarak Birleştirme İsteği It's important to understand that many projects don't really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging. From 7cff79024e09b5082b8d568dfe9f30f700e3480b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 19 Feb 2024 09:10:53 +0100 Subject: [PATCH 085/210] Update 2-contributing.asc translated up to line: 300 --- book/06-github/sections/2-contributing.asc | 75 +++++++++++----------- 1 file changed, 39 insertions(+), 36 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index d7a1c163..ff874e65 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -208,39 +208,42 @@ GitHub'daki bir projeye katkıda bulunmanın temellerini öğrendikten sonra, bi ===== Yama Olarak Birleştirme İsteği -It's important to understand that many projects don't really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. -Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging. +Birçok projenin, birleştirme isteklerini; posta listesi tabanlı projelerin düşündüğü gibi sıralı ve kusursuz bir yama kuyruğu olarak görmediğini anlamak gereklidir. +Çoğu GitHub projesi, Birleştirme isteği dallarını, önerilen bir değişiklik etrafında yapılan karşılıklı konuşmalar olarak düşünür ve uygulanan birleştirme bileşik bir fark ile sonuçlanır. -This is an important distinction, because generally the change is suggested before the code is thought to be perfect, which is far more rare with mailing list based patch series contributions. -This enables an earlier conversation with the maintainers so that arriving at the proper solution is more of a community effort. -When code is proposed with a Pull Request and the maintainers or community suggest a change, the patch series is generally not re-rolled, but instead the difference is pushed as a new commit to the branch, moving the conversation forward with the context of the previous work intact. +Değişiklik genellikle, kodun mükemmel olduğu düşünülmeden önce önerildiği için - ki posta listesi tabanlı yama serisi katkılarında bi çok daha nadirdir - bu önemli bir ayrımdır. +Bu, yürütücülerle daha erken bir müzakere başlatır, böylece doğru çözüme varılması daha ziyade bir topluluk çabası haline gelir. +Bir birleştirme isteğiyle kod önerildiğinde, yürütücüler veya topluluk bir değişiklik önerirse; yama serisi genellikle yeniden yapılmaz. +Bunun yerine bu ek değişiklik, yeni bir katkı olarak dalın içine itilir ve önceki çalışmanın bağlamı korunur. -For instance, if you go back and look again at <<_pr_final>>, you'll notice that the contributor did not rebase his commit and send another Pull Request. -Instead they added new commits and pushed them to the existing branch. -This way if you go back and look at this Pull Request in the future, you can easily find all of the context of why decisions were made. -Pushing the ``Merge'' button on the site purposefully creates a merge commit that references the Pull Request so that it's easy to go back and research the original conversation if necessary. +Örneğin, <<_pr_final>> örneğine tekrar bakarsanız, katkı sağlayıcının katkısını yeniden temellemediğini (rebase) ve başka bir birleştirme isteği göndermediğini farkedeceksiniz. +Bunun yerine, yeni katkılar işleyip, bunları mevcut dala itmiştir. +Bu şekilde, gelecekte bu birleştirme isteğine tekrar baktığınızda, kararların neden alındığına dair tüm bağlamı kolayca görebilirsiniz. +Sitedeki "Birleştir" düğmesine tıklamak; gerektiğinde orijinal tartışmayı aramayı kolaylaştırmak için, birleştirme isteğine referans veren bir birleştirme katkısı oluşturur. -===== Keeping up with Upstream +===== Ana Repoyla Güncel Tutmak + +Eğer birleştirme isteğiniz güncelliğini yitirirse veya başka bir nedenle temiz bir şekilde birleştirilemezse; yürütücünün bunu kolaylıkla birleştirebilmesi için bunu düzeltmek isteyeceksiniz. +GitHub bunu sizin için test edecek ve her birleştirme isteğinin alt kısmında birleştirmenin normal olup olmadığını size bildirecektir. -If your Pull Request becomes out of date or otherwise doesn't merge cleanly, you will want to fix it so the maintainer can easily merge it. -GitHub will test this for you and let you know at the bottom of every Pull Request if the merge is trivial or not. [[_pr_fail]] -.Pull Request does not merge cleanly -image::images/pr-01-fail.png[PR merge failure] +.Birleştirme isteği temizce yapılamaz +image::images/pr-01-fail.png[PR birleştirme hatası] -If you see something like <<_pr_fail>>, you'll want to fix your branch so that it turns green and the maintainer doesn't have to do extra work. +Eğer <<_pr_fail>> gibi bir şey görürseniz; rengin yeşile dönmesi için dalınızı düzeltmek istersiniz, böylece yürütücü ekstra iş yapmak zorunda kalmaz. -You have two main options in order to do this. -You can either rebase your branch on top of whatever the target branch is (normally the `master` branch of the repository you forked), or you can merge the target branch into your branch. +Bunu yapmanın temel olarak iki yolu bulunmaktadır. +Ya dalınızı hedeflediğiniz dalın (genellikle çatalladığınız reponun `master` dalı) üzerine yeniden temellersiniz (rebase) veya hedef dalı kendi dalınıza birleştirirsiniz. -Most developers on GitHub will choose to do the latter, for the same reasons we just went over in the previous section. -What matters is the history and the final merge, so rebasing isn't getting you much other than a slightly cleaner history and in return is *far* more difficult and error prone. +GitHub'daki çoğu geliştirici, önceki bölümde ele aldığımız aynı nedenlerden dolayı, genellikle ikincisini seçer. +Önemli olan katkı geçmişi ve nihai birleşmedir. +Yeniden temellemek biraz daha temiz bir geçmiş sağlar ama *çok* daha zor ve hata yapmaya meyilli bir işlemdir. -If you want to merge in the target branch to make your Pull Request mergeable, you would add the original repository as a new remote, fetch from it, merge the main branch of that repository into your topic branch, fix any issues and finally push it back up to the same branch you opened the Pull Request on. +Eğer hedeflediğiniz dala birleştirerek, birleştirme isteğinizi birleştirilebilir hale getirmek istiyorsanız; özgün repoyu yeni bir uzak repo olarak ekleyip, ordan getirirsiniz (fetch); ardından reponun ana dalını, kendi tema dalınıza birleştirirsiniz; sorunları düzeltir ve son olarak bunu üzerinde birleştirme isteği açtığınız dala geri itersiniz. -For example, let's say that in the ``tonychacon'' example we were using before, the original author made a change that would create a conflict in the Pull Request. -Let's go through those steps. +Önceki "tonychacon" örneğini kullanırsak; diyelim ki orijinal yazar birleştirme isteğinde çakışma oluşturacak bir değişiklik yaptı. +Şimdi bu adımları birlikte gözden geçirelim. [source,console] ---- @@ -275,26 +278,26 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Add the original repository as a remote named ``upstream'' -<2> Fetch the newest work from that remote -<3> Merge the main branch of that repository into your topic branch -<4> Fix the conflict that occurred -<5> Push back up to the same topic branch +<1> Orijinal repoyu ``upstream'' adıyla bir uzak olarak ekleyin. +<2> Bu uzaktan en yeni çalışmayı alın. +<3> Bu reponun ana dalını kendi tema dalınıza birleştirin. +<4> Oluşan çakışmayı düzeltin. +<5> Aynı konu dalına geri yükleyin. -Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly. +Bunu yaptıktan sonra, birleştirme isteği otomatik olarak güncellenecek ve düzgünce birleştirilebiliyor mu diye tekrar kontrol edilecektir. [[_pr_merge_fix]] -.Pull Request now merges cleanly -image::images/pr-02-merge-fix.png[PR fixed] +.Birleştirme isteği sorunsuzca gerçekleştirilebiliyor +image::images/pr-02-merge-fix.png[PR onarıldı] -One of the great things about Git is that you can do that continuously. -If you have a very long-running project, you can easily merge from the target branch over and over again and only have to deal with conflicts that have arisen since the last time that you merged, making the process very manageable. +Git'in harika özelliklerinden biri de sürekli olarak bunu yapabilmenizdir. +Çok uzun süreli bir projeniz varsa, hedef dal üzerinden defalarca birleştirme işlemi yapabilirsiniz ve sadece son birleştirdiğinizden beri ortaya çıkan çakışmalarla uğraşmanız gerekecektir; bu da süreci çok daha yönetilebilir hale getirir. -If you absolutely wish to rebase the branch to clean it up, you can certainly do so, but it is highly encouraged to not force push over the branch that the Pull Request is already opened on. -If other people have pulled it down and done more work on it, you run into all of the issues outlined in <>. -Instead, push the rebased branch to a new branch on GitHub and open a brand new Pull Request referencing the old one, then close the original. +Eğer mutlaka dalı temizlemek için yeniden temellemek istiyorsanız, elbette yapabilirsiniz, ancak zaten açılmış olan dal üzerinde "zorla itme işlemi" (force push) yapmaktan kaçınmanız şiddetle tavsiye edilir. +Başkaları tarafından çekilip, üzerinde daha fazla çalışma yapılmışsa; <> bölümünde belirtilen tüm sorunlarla karşılaşırsınız. +Onun yerine, yeniden temellenmiş dalı GitHub'da yeni bir dala itin ve eskisine referans veren yepyeni bir birleştirme isteği açın, ardından orijinal isteği kapatın. -===== References +===== Referanslar Your next question may be ``How do I reference the old Pull Request?''. It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub. From 22836d16ac4b76f785c20ac55d9714a34f25c5de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 19 Feb 2024 21:21:27 +0100 Subject: [PATCH 086/210] Update 3-contributing.asc translated up to line:417 --- book/06-github/sections/2-contributing.asc | 124 +++++++++++---------- 1 file changed, 63 insertions(+), 61 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index ff874e65..7e488f4c 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -299,19 +299,19 @@ Onun yerine, yeniden temellenmiş dalı GitHub'da yeni bir dala itin ve eskisine ===== Referanslar -Your next question may be ``How do I reference the old Pull Request?''. -It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub. +Sonraki sorunuz muhtemelen "Eski birleştirme isteğine nasıl referans verebilirim?" olabilir. +GitHub'da yazı yazabileceğiniz hemen hemen her yerde diğer şeylere referans vermenin pek çok farklı yolu bulunmaktadır. -Let's start with how to cross-reference another Pull Request or an Issue. -All Pull Requests and Issues are assigned numbers and they are unique within the project. -For example, you can't have Pull Request #3 _and_ Issue #3. -If you want to reference any Pull Request or Issue from any other one, you can simply put `#` in any comment or description. -You can also be more specific if the Issue or Pull request lives somewhere else; write `username#` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#` to reference something in another repository. +Başka bir birleştirme isteği veya bir iş paketine nasıl referans verileceğini açıklayalım. +Tüm birleştirme istekleri ve iş paketleri numaralandırılır ve bunlar proje içinde benzersizdir. +Örneğin, birleştirme isteği #3 ve iş paketi #3'e sahip olamazsınız. +Başka bir birleştirme isteği veya iş paketine herhangi bir yerden referans vermek istiyorsanız, sadece herhangi bir yorum veya açıklamada `#` yazabilirsiniz. +Ayrıca, birleştirme isteği veya iş paketi başka bir yerdeyse daha kesin olabilirsiniz; kendi reponuzun bir çatalında bir paket veya isteğe atıfta bulunuyorsanız `kullanıcıadı#` yazın, başka bir repoda bir şeye referans veriyorsanız `kullanıcıadı/repo#` yazın. -Let's look at an example. -Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. -We also want to reference an issue in the fork of the repository and an issue in a completely different project. -We can fill out the description just like <<_pr_references>>. +Hadi bir örnek üzerinde görelim. +Diyelimk ki önceki örnekteki dalı yeniden temelledik, onun için yeni bir birleştirme isteği oluşturduk ve şimdi yeni istekten eskisine referans vermek istiyoruz. +Ayrıca, repo çatalındaki bir iş paketine ve tamamen farklı bir projedeki bir başka iş paketine de referans vermek istiyoruz. +Açıklamayı <<_pr_references>> örneğinde olduğu gibi doldurabiliriz. [[_pr_references]] .Cross references in a Pull Request. @@ -320,80 +320,82 @@ image::images/mentions-01-syntax.png[PR references] When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>. [[_pr_references_render]] -.Cross references rendered in a Pull Request. -image::images/mentions-02-render.png[PR references rendered] +.Birleştirme isteği çapraz referansları +image::images/mentions-02-render.png[PR referansaları işlendi.] -Notice that the full GitHub URL we put in there was shortened to just the information needed. +Orada belirttiğimiz tam GitHub URL'sinin yalnızca gerekli bilgilere kısaltıldığını görebilirsiniz. + +Şimdi Tony, orijinal Birleştirme İsteğini kapatırsa: GitHub, birleştirme isteği zaman çizelgesinde otomatik olarak bir geri izleme etkinliği oluşturduğu için, yeni istekte onu görebiliriz. +Bu, bu birleştirme isteğini ziyaret eden ve kapatıldığını gören herkesin, onu geçersiz kılan isteğe kolayca bağlantı kurabileceği anlamına gelir. +Bu bağlantı <<_pr_closed>> gibi görünecektir: -Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. -This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. -The link will look something like <<_pr_closed>>. [[_pr_closed]] -.Link back to the new Pull Request in the closed Pull Request timeline. -image::images/mentions-03-closed.png[PR closed] +.Kapalı birleştirme isteği zaman çizelgesinde yeni birleştirme isteği bağlantısı. +image::images/mentions-03-closed.png[Kapalı PR] -In addition to issue numbers, you can also reference a specific commit by SHA-1. -You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. -Again, you can reference commits in forks or other repositories in the same way you did with issues. +Sadece iş paketi numaralarını değil, aynı zamanda bir belirli bir katkıyı SHA-1 ile de referans verebilirsiniz. +Tam 40 karakterlik bir SHA-1 belirtmeniz gerekiyor, ancak GitHub bu şekilde bir yorumda gördüğünde doğrudan katkıya bağlantı kurar. +Tekrar edersek, katkıları çatallarda veya diğer repolarda, aynı iş paketlerinde olduğu gibi eferanslayabilirsiniz. -==== GitHub Flavored Markdown +==== GitHub Flavored (Aromalı) Markdown -Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. -In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. -Markdown is like writing in plain text but which is rendered richly. +Diğer İş Paketlerine bağlantı vermek, GitHub'da hemen hemen her metin kutusunda yapabileceğiniz ilginç şeylerin, sadece başlangıcıdır. +İş Paketi ve Birleştirme İsteği açıklamaları, yorumlar, kod yorumları ve daha fazlasında "GitHub Flavored Markdown" adı verilen bir yapıyı kullanabilirsiniz. +Markdown, düz metin şeklinde yazıp, zengince işlenmiş olarak sunmak anlamına gelir. -See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown. +Metin ve yorumların, Markdown kullanılarak nasıl yazılacağının ve işleneceğinin örneği için <<_example_markdown>> bağlantısına bakın. [[_example_markdown]] -.An example of GitHub Flavored Markdown as written and as rendered. -image::images/markdown-01-example.png[Example Markdown] +.GitHub Aromalı Markdown'ın yazım ve sunum örneği. +image::images/markdown-01-example.png[Markdown örneği] -The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. -These can all be really useful when creating useful Pull Request or Issue comments or descriptions. +GitHub Markdown'a kendinden kattığı çeşni sayesinde, size sıradan Markdown sözdiziminden öteye geçen deneyimler sunar. +Bunlar, bir İş Paketi yorumu, Birleştirme İsteği veya açıklama oluştururken oldukça kullanışlı olabilir. -===== Task Lists +===== Görev Listeleri -The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. -A task list is a list of checkboxes of things you want to get done. -Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete. +Özellikle Birleştirme İsteklerinde kullanım için, gerçekten kullanışlı ilk GitHub özel Markdown özelliği, Görev Listesidir. +Bir görev listesi, yapmak istediğiniz işlerin tıklanabilir kutucuklar halinde listelenmesidir. +Bunları bir İş Paketi veya Birleştirme İsteği içine koymak, genellikle tamamlanmasını isteğininiz işleri belirtir. -You can create a task list like this: +Bir görev listesini şöyle oluşturabilirsiniz: [source,text] ---- -- [X] Write the code -- [ ] Write all the tests -- [ ] Document the code +- [X] Kod yaz +- [ ] Tüm testleri yaz +- [ ] Dokümentasyonu hazırla ---- -If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>> +Bunu, Birleştirme İsteği veya İş Paketinin açıklamasına dahil edersek, sonucu <<_eg_task_lists>> gibi görüntülenir. [[_eg_task_lists]] -.Task lists rendered in a Markdown comment. -image::images/markdown-02-tasks.png[Example Task List] +..Markdown yorumu içindeki görev listesi. +image::images/markdown-02-tasks.png[Örnek görev listesi.] + +Bu genellikle Birleştirme İsteklerinde, Birleştirme İsteği'nin birleştirilmeye hazır olmadan önce, dalda ne yapmak istediğinizi belirtmek için kullanılır. +Gerçekten harika olan kısım; doğrudan onay kutularına tıklayarak yorumları güncelleyebilmenizdir - görevleri işaretlemek için Markdown'ı doğrudan düzenlemenize gerek yoktur. -This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. -The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off. +Dahası, GitHub, İşlerinizde ve Birleştirme İsteklerinizde görev listelerini arar ve onları listelenen sayfalarda meta veri olarak gösterir. +Örneğin, içinde görevler listesi olan bir Birleştirme İsteğiniz varsa ve Birleştirme İstekleri giriş sayfasına bakarsanız, ne kadarının tamamlandığını görebilirsiniz. +Bu, insanların Birleştirme İsteklerini alt görevlere ayırmalarına ve diğer kişilerin dalın gelişimini izlemesine yardımcı olur. +Bunu <<_task_list_progress>> örneğinde görebilirsiniz. -What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. -For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. -This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. -You can see an example of this in <<_task_list_progress>>. [[_task_list_progress]] -.Task list summary in the Pull Request list. -image::images/markdown-03-task-summary.png[Example Task List] +.Birleştirme İsteği listesinde görev listesi özeti. +image::images/markdown-03-task-summary.png[Örnek görev listesi] -These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature. +Bu özellikler, bir Birleştirme İsteğini erken açarsanız ve yeni bir özelliğin gelişimini izlemek için kullanırsanız, son derece yararlı olabilir. -===== Code Snippets +===== Kod Parçacıkları (Code Snippets) -You can also add code snippets to comments. -This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. -This is also often used to add example code of what is not working or what this Pull Request could implement. +Yorumlara kod parçacıkları da ekleyebilirsiniz. +Bu, deneyebileceğiniz bir şeyi gerçekten denemeden önce, bir katkı yorumu olarak eklemek isteğiğinizde, çok kullanışlı bir özelliktir. +Ayrıca, çalışmayan veya bu Birleştirme İsteğinde uygulanabilecek kod örneği eklemek için de sıkça kullanılır. -To add a snippet of code you have to ``fence'' it in backticks. +Kod parçacığını eklemek için, onu (ters-kesme işaretleriyle "`") kafeslemelisiniz. [source,text] ---- @@ -405,14 +407,14 @@ for(int i=0 ; i < 5 ; i++) ``` ---- -If you add a language name like we did there with 'java', GitHub will also try to syntax highlight the snippet. -In the case of the above example, it would end up rendering like <<_md_code>>. +Eğer yukarıdaki örnekte olduğu gibi 'java' ya da bir programlama dili adı eklerseniz, GitHub ek olarak kod parçacığının sözdizimini de vurgulamaya çalışacaktır. +Yukarıdaki örnekte sonuç <<_md_code>> gibi olur. [[_md_code]] -.Rendered fenced code example. -image::images/markdown-04-fenced-code.png[Rendered fenced code] +.Kafeslenmiş kod örneği. +image::images/markdown-04-fenced-code.png[Kafeslenmiş kod] -===== Quoting +===== Alıntı If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. From 4fd8fb6b3ffbfafcf9bfecb711b3da2855fb7237 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 21 Feb 2024 09:14:16 +0100 Subject: [PATCH 087/210] Update-contributing.asc translate complete for contributing.asc --- book/06-github/sections/2-contributing.asc | 113 +++++++++++---------- 1 file changed, 58 insertions(+), 55 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 7e488f4c..a7134723 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -314,10 +314,11 @@ Ayrıca, repo çatalındaki bir iş paketine ve tamamen farklı bir projedeki bi Açıklamayı <<_pr_references>> örneğinde olduğu gibi doldurabiliriz. [[_pr_references]] -.Cross references in a Pull Request. -image::images/mentions-01-syntax.png[PR references] +.Birleştirme İsteği çapraz referansları. +image::images/mentions-01-syntax.png[PR referansları] -When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>. +Bu birleştirme isteği gönderildiğinde, bunların <<_pr_references_render>> gibi işlendiğini göreceğiz. + we'll see all of that rendered like <<_pr_references_render>>. [[_pr_references_render]] .Birleştirme isteği çapraz referansları @@ -416,11 +417,11 @@ image::images/markdown-04-fenced-code.png[Kafeslenmiş kod] ===== Alıntı -If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. -In fact, this is so common and so useful that there is a keyboard shortcut for it. -If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you. +Eğer uzun bir yorumun küçük bir kısmına yanıt veriyorsanız, diğer yorumdan alıntı yapacağınız kısımları, `>` karakteriyle başlatarak seçebilirsiniz. +Aslında, bu o kadar yaygın ve kullanışlıdır ki bunun için bir klavye kısayolu bile vardır. +Yanıtlamak amacıyla alıntılamak istediğiniz metni vurgulayın ve `r` tuşuna basın, bu size yorum kutusunda bu metni alıntılayacaktır. -The quotes look something like this: +Alınıtı şöyle görünecektir: [source,text] ---- @@ -430,25 +431,25 @@ The quotes look something like this: How big are these slings and in particular, these arrows? ---- -Once rendered, the comment will look like <<_md_quote>>. +İşlendikten sonra yorum <<_md_quote>>'deki gibi görünecektir. [[_md_quote]] -.Rendered quoting example. -image::images/markdown-05-quote.png[Rendered quoting] +.İşlenmiş alıntı örneği. +image::images/markdown-05-quote.png[İşlenmiş alıntı] ===== Emoji -Finally, you can also use emoji in your comments. -This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. -There is even an emoji helper in GitHub. -If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for. +Son olarak, yorumlarınızda emoji de kullanabilirsiniz. +Bu aslında, birçok GitHub İşlemi ve Birleştirme İsteğinde gördüğünüz yorumlarda yaygın olarak kullanılır. +Hatta GitHub'da bir emoji yardımcısı bile vardır. +Bir yorum yazıyorsanız ve `:` karakteri ile başlarsanız, bir otomatik tamamlama, aradığınız emojiyi bulmanıza yardımcı olur. [[_md_emoji_auto]] -.Emoji autocompleter in action. -image::images/markdown-06-emoji-complete.png[Emoji autocompleter] +.İş başındaki emoji tamamlayıcısı. +image::images/markdown-06-emoji-complete.png[Emoji tamamlayıcısı] -Emojis take the form of `::` anywhere in the comment. -For instance, you could write something like this: +Emojiler, yorumun herhangi bir yerinde `::` şeklinde olabilir. +Örneğin, şöyle bir şey yazabilirsiniz: [source,text] ---- @@ -461,51 +462,52 @@ I :eyes: that :bug: and I :cold_sweat:. :clap::tada::panda_face: ---- -When rendered, it would look something like <<_md_emoji>>. +İşlendiğinde <<_md_emoji>> gibi görünür. [[_md_emoji]] -.Heavy emoji commenting. +.Yoğun emojili yorumlar. image::images/markdown-07-emoji.png[Emoji] -Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in. +Bu yorum müthiş faydalı sayılmaz, ama duyguları başka türlü iletmenin zor olduğu bir ortama, eğlenceli bir unsur ekler. - -[NOTE] +[NOT] ==== -There are actually quite a number of web services that make use of emoji characters these days. -A great cheat sheet to reference to find emoji that expresses what you want to say can be found at: +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: https://www.webfx.com/tools/emoji-cheat-sheet/ ==== -===== Images +===== Görüntüler -This isn't technically GitHub Flavored Markdown, but it is incredibly useful. -In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them. +Teknik olarak, bu GitHub'a özgün Markdown olmasa da son derece kullanışlıdır. +Yorumlara Markdown görüntü bağlantıları eklemenin yanı sıra, ilgili URL'leri bulmak ve gömülü bağlantılar eklemek de zor olabilir; bu yüzden GitHub metin alanlarına sürükleyip bırakarak görüntüler gömmenize olanak tanır. [[_md_drag]] -.Drag and drop images to upload them and auto-embed them. -image::images/markdown-08-drag-drop.png[Drag and drop images] +.Görüntüleri yüklemek için sürükleyip bırakarak gömün. +image::images/markdown-08-drag-drop.png[Görüntüleri sürükle ve bırak] + +<<_md_drag>> bağlantısına bakarsanız, metin alanının üstünde küçük bir ipucu, "Markdown olarak ayrıştırıldı" uyarısı, görebilirsiniz. +Buna tıkladığınızda, GitHub'da Markdown ile yapabileceğiniz her şeyi içeren bir hatırlatma notuna erişebilirsiniz. -If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. -Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub. [[_fetch_and_push_on_different_repositories]] -==== Keep your GitHub public repository up-to-date +==== GitHub'taki Herkese Açık Repolarınızı Güncel Tututn -Once you've forked a GitHub repository, your repository (your "fork") exists independently from the original. -In particular, when the original repository has new commits, GitHub informs you by a message like: +Bir GitHub reposunu çatalladıktan sonra, "oluşturduğunuz çatal" artık sizin reponuzun bir parçasıdır ve orijinalinden bağımsız olur. +Özellikle, orijinal repoya yeni katkılar işlendikçe; GitHub, şu şekilde bir mesajla sizi bilgilendirir: [source,text] ---- This branch is 5 commits behind progit:master. +Bu dal progit:master'in 5 katkı gerisindedir. ---- -But your GitHub repository will never be automatically updated by GitHub; this is something that you must do yourself. -Fortunately, this is very easy to do. +Ancak, GitHub reponuz asla GitHub tarafından otomatik olarak güncellenmez; bunu kendiniz yapmanız gerekir. +Neyse ki, bunu yapmak çok kolaydır. -One possibility to do this requires no configuration. -For example, if you forked from `https://github.com/progit/progit2.git`, you can keep your `master` branch up-to-date like this: +Bunu yapmanın yollarından biri hiçbir yapılandırma gerektirmez. +Örneğin, `https://github.com/progit/progit2.git` adresinden çatallandıysanız, `master` dalınızı şu şekilde güncel tutabilirsiniz: [source,console] ---- @@ -514,12 +516,12 @@ $ git pull https://github.com/progit/progit2.git <2> $ git push origin master <3> ---- -<1> If you were on another branch, return to `master`. -<2> Fetch changes from `https://github.com/progit/progit2.git` and merge them into `master`. -<3> Push your `master` branch to `origin`. +<1> Eğer başka bir daldaydıysanız, `master` dalına dönün. +<2> Değişiklikleri `https://github.com/progit/progit2.git` adresinden getirin ve bunları `master` dala birleştirin. +<3> `master` dalınızı `origin` 'a itin. -This works, but it is a little tedious having to spell out the fetch URL every time. -You can automate this work with a bit of configuration: +İşe yarıyor, ancak her seferinde getirme URL'sini yazmak biraz can sıkıcı. +Bu işlemi yapılandırma yoluyla otomatik hale getirebilirsiniz: [source,console] ---- @@ -528,12 +530,12 @@ $ git branch --set-upstream-to=progit/master master <2> $ git config --local remote.pushDefault origin <3> ---- -<1> Add the source repository and give it a name. - Here, I have chosen to call it `progit`. -<2> Set your `master` branch to fetch from the `progit` remote. -<3> Define the default push repository to `origin`. +<1> Kaynak reposunu ekleyin ve ona bir isim verin. + Burada `progit` adı verilmiştir. +<2> `master` dalınızı `progit` uzak reposundan getirmek üzere ayarlayın. +<3> Varsayılan itme reposunu `origin` olarak tanımlayın. -Once this is done, the workflow becomes much simpler: +Bunu bir kez yaptığınızda iş akışı çok daha basit hale gelir: [source,console] ---- @@ -542,10 +544,11 @@ $ git pull <2> $ git push <3> ---- -<1> If you were on another branch, return to `master`. -<2> Fetch changes from `progit` and merge changes into `master`. -<3> Push your `master` branch to `origin`. +<1> Eğer başka bir daldaysanız, `master` dalına geri dönün. +<2> `progit` reposundan değişiklikleri getirin ve `master` dalına birleştirin. +<3> `master` dalınızı `origin` 'a itin. -This approach can be useful, but it's not without downsides. -Git will happily do this work for you silently, but it won't warn you if you make a commit to `master`, pull from `progit`, then push to `origin` -- all of those operations are valid with this setup. -So you'll have to take care never to commit directly to `master`, since that branch effectively belongs to the upstream repository. +Bu yaklaşım faydalı olabilir, ancak bazı dezavantajları da bulunmaktadır. +Git sessizce bu işlemi yapacaktır, ancak `master` dalına bir katkı işlerseniz; `progit` 'den çekip, ardından `origin` 'e gönderirken, size bir uyarı vermeyecektir. +Bu düzenleme ile tüm bu işlemler geçerli hale gelir. +Bu nedenle, `master` dalına doğrudan katkı işlememeye dikkat etmelisiniz, çünkü bu dal etkin bir şekilde üst-akım reposuna aittir. From 2f8d552a43c2788f88ce9708cc893cab1ea5617c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 22 Feb 2024 07:48:46 +0100 Subject: [PATCH 088/210] translate line:76 --- book/06-github/sections/3-maintaining.asc | 111 +++++++++++----------- 1 file changed, 56 insertions(+), 55 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 6a8c9bb0..d3d9a929 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -1,98 +1,99 @@ [[_maintaining_gh_project]] -=== Maintaining a Project +=== Proje Bakımı -Now that we're comfortable contributing to a project, let's look at the other side: creating, maintaining and administering your own project. +Artık bir projeye katkıda bulunmaya alıştığımıza göre, şimdi işin diğer tarafına bakalım: kendi projenizi oluşturma, bakma ve yönetme. -==== Creating a New Repository +==== Yeni Bir Repo Oluşturma -Let's create a new repository to share our project code with. -Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. +Projemizin kodunu paylaşmak için yeni bir repo oluşturalım. +Bunun için, panonun sağ tarafında bulunan ``New repository`` (Yeni Repo) düğmesine veya <<_new_repo_dropdown>>'da göründüğü gibi kullanıcı adınızın yanındaki üst araç çubuğundaki `+` düğmesine tıklayarak başlayın. -.The ``Your repositories'' area. -image::images/newrepo.png[The ``Your repositories'' area.] +. ``Your repositories`` (repolarınız) bölümü. +image::images/newrepo.png[``Your repositories`` (repolarınız) bölümü.] [[_new_repo_dropdown]] -.The ``New repository'' dropdown. -image::images/new-repo.png[The ``new repository'' dropdown.] +.``New repository`` (yeni repo) açılır-listesi. +image::images/new-repo.png[``New repository`` (yeni repo) açılır-listesi.] -This takes you to the ``new repository'' form: +Bu sizi ``new repository'' (yeni repo) formuna ulaştırır: -.The ``new repository'' form. +.``new repository`` form. image::images/newrepoform.png[The ``new repository'' form.] -All you really have to do here is provide a project name; the rest of the fields are completely optional. -For now, just click the ``Create Repository'' button, and boom – you have a new repository on GitHub, named `/`. +Burada yapmanız gereken tek şey bir proje adı yazmak; diğer alanlar tamamen isteğe bağlıdır. +Şimdilik sadece ``Create Repository`` (Repo Oluştur) düğmesine tıklayın, ve anında GitHub'da `/` adında yeni bir repoya sahipsiniz. -Since you have no code there yet, GitHub will show you instructions for how to create a brand-new Git repository, or connect an existing Git project. -We won't belabor this here; if you need a refresher, check out <>. +Henüz kodunuz olmadığı için, GitHub size tamamen yeni bir Git reposu nasıl oluşturacağınızı veya mevcut bir Git projesini nasıl bağlayacağınızı gösterecektir. +Burada bunun üzerinde daha fazla durmayacağımız için, daha fazla bilgiye ihtiyacınız varsa, <> bölümüne göz atabilirsiniz. -Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with. -Every project on GitHub is accessible over HTTPS as `https://github.com//`, and over SSH as `git@github.com:/`. -Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them. +Projeniz GitHub'da yayınlandığı için, projenizi paylaşmak istediğiniz herkese URL'yi verebilirsiniz. +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. -[NOTE] +[NOT] ==== -It is often preferable to share the HTTPS based URL for a public project, since the user does not have to have a GitHub account to access it for cloning. -Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL. -The HTTPS one is also exactly the same URL they would paste into a browser to view the project there. +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. +HTTPS URL'si tam olarak, kullanıcıların projeyi bir tarayıcıda görüntülemek için yapıştıracakları aynı URL'dir. ==== -==== Adding Collaborators +==== Çalışma Arkadaşı (Ortak) Eklemek -If you're working with other people who you want to give commit access to, you need to add them as ``collaborators''. -If Ben, Jeff, and Louise all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project. -Doing so will give them ``push'' access, which means they have both read and write access to the project and Git repository. +Başkalarıyla birlikte çalışıyorsanız ve onlara katkı erişimi vermek istiyorsanız; onları "Çalışma Arkadaşı" olarak eklemeniz gerekir. +Ben, Jeff ve Louise GitHub hesabı oluşturduysa ve onlara repo erişimi vermek istiyorsanız, onları projenize ekleyebilirsiniz. +Bunu yapmak, onlara "itme" erişimi verecek; yani projeye ve Git reposuna, hem okuma hem de yazma erişimine sahip olacaklardır. -Click the ``Settings'' link at the bottom of the right-hand sidebar. -.The repository settings link. -image::images/reposettingslink.png[The repository settings link.] +Sağ kenarın altındaki ``Settings`` (ayarlar) linkine tıklayın. -Then select ``Collaborators'' from the menu on the left-hand side. -Then, just type a username into the box, and click ``Add collaborator.'' -You can repeat this as many times as you like to grant access to everyone you like. -If you need to revoke access, just click the ``X'' on the right-hand side of their row. +.Repo ayarları linki. +image::images/reposettingslink.png[Repo ayarları linki.] -.Repository collaborators. -image::images/collaborators.png[The repository collaborators box.] +Sol taraftaki menüden ``Collaborators`` 'ı seçin. +Ardından, kutuya eklemek istediğiniz kullanıcının adını yazın ve "Add collaborator" (çalışma arkadaşı ekle) düğmesine tıklayın. +Bu işlemi dilediğiniz kadar yineleyerek, istediğiniz herkese erişim verebilirsiniz. +Erişimi iptal etmeniz gerekiyorsa, sadece isimlerinin bulunduğu sırasının sağ tarafındaki "X"e tıklayın. -==== Managing Pull Requests +.Repo Ortakları. +image::images/collaborators.png[Repo Ortakları Kutusu.] -Now that you have a project with some code in it and maybe even a few collaborators who also have push access, let's go over what to do when you get a Pull Request yourself. +==== Birleştirme İsteklerini (PR: Pull Requests) Yönetmek -Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. -The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch. +Şimdi kod içeren bir projeniz ve hatta birkaç çalışma arkadaşınızın da itme erişimi olduğu bir projeniz olduğuna göre, bir Birleştirme İsteği aldığınızda ne yapmanız gerektiğini görelim. -For these examples, let's assume you are ``tonychacon'' and you've created a new Arduino code project named ``fade''. +Birleştirme İstekleri ya repo çatalınızdaki bir dalda ya da aynı repodaki başka bir daldan gelebilir. +Tek fark, çatallarda olanlar genellikle sizin dalınıza itme yapamaz ve siz de onlarınkine. Dahili Birleştirme İstekleri genellikle her iki tarafın da dala erişim sağlayabilmesi durumudur. + +Bu örnekler için, varsayalım ki sizin adınız ``tonychacon`` ve ``fade`` adında yeni bir Arduino kodu projesi oluşturdunuz. [[_email_notifications]] -===== Email Notifications +===== E-Posta Bildirimleri -Someone comes along and makes a change to your code and sends you a Pull Request. -You should get an email notifying you about the new Pull Request and it should look something like <<_email_pr>>. +Birisi kodunuza bir değişiklik yapar ve size bir Birleştirme İsteği (Pull Request) gönderir. +Yeni Birleştirme İsteği hakkında sizi bilgilendiren bir e-posta almalısınız ve bu e-posta genellikle <<_email_pr>> gibi bir şeydir. [[_email_pr]] -.Email notification of a new Pull Request. -image::images/maint-01-email.png[Pull Request email notification] +.Yeni bir birleştirme isteğinin e-posta bildirimi. +image::images/maint-01-email.png[Birleştirme isteği e-posta bildirimi] -There are a few things to notice about this email. -It will give you a small diffstat -- a list of files that have changed in the Pull Request and by how much. -It gives you a link to the Pull Request on GitHub. -It also gives you a few URLs that you can use from the command line. +Bu e-postada dikkat edilmesi gereken birkaç şey vardır: +Küçük bir "diffstat" bulunur: Birleştirme İsteği'nde değişen dosyaların ve bu değişikliklerin miktarının bir listesi. +GitHub'daki Birleştirme İsteği'ne bir bağlantı verir. +Ayrıca, komut satırından kullanabileceğiniz birkaç URL sağlar. -If you notice the line that says `git pull patch-1`, this is a simple way to merge in a remote branch without having to add a remote. -We went over this quickly in <>. -If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes. +`git pull patch-1` satırına dikkat edin; bu uzak bir dalı eklemeye gerek kalmadan, uzak bir dalı birleştirmenin basit bir yoludur. +<> bölümünde bunun hakkında kısaca konuştuk. +İsterseniz bir konu dalı oluşturup, değişiklikleri birleştirmek için bu komutu çalıştırabilirsiniz. -The other interesting URLs are the `.diff` and `.patch` URLs, which as you may guess, provide unified diff and patch versions of the Pull Request. -You could technically merge in the Pull Request work with something like this: +Diğer ilginç URL'ler `.diff` ve `.patch` URL'leridir. Tahmin edebileceğiniz gibi, birleştirme isteğinin, birleştirilmiş diff ve yama sürümlerini sağlar. +Birleştirme isteği çalışmasını, teknik olarak şöyle birleştirebilirsiniz: [source,console] ---- $ curl https://github.com/tonychacon/fade/pull/1.patch | git am ---- -===== Collaborating on the Pull Request +===== Birleştirme İsteği Yoluyla İşbirliği As we covered in <>, you can now have a conversation with the person who opened the Pull Request. You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere. From 93a9f9e574a0aabc011495715007ce0d337b9c6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 22 Feb 2024 15:31:48 +0100 Subject: [PATCH 089/210] translate up to line:120 --- book/06-github/sections/3-maintaining.asc | 29 ++++++++++++----------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index d3d9a929..63e50bf2 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -95,27 +95,28 @@ $ curl https://github.com/tonychacon/fade/pull/1.patch | git am ===== Birleştirme İsteği Yoluyla İşbirliği -As we covered in <>, you can now have a conversation with the person who opened the Pull Request. -You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere. +<> bölümünden hatırlayacağınız üzere birleştirme isteği açan kişiyle artık bir konuşma başlatabilirsiniz. GitHub soslu Markdown'ı her yerde kullanarak isteğiniz kod satırlarına yorum yazabilir, katkının veya birleştirme isteğinin tamamına yorum apabilirsiniz. -Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. -They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread. +Birileri birleştirme isteği üzerine yorum yaptıkça e-posta bildirimleri almaya devam edersiniz, böylece etkinliğin canlı olduğunu bilirsiniz. +Her biri etkinliğin gerçekleştiği birleştirme isteğine giden bir bağlantıya sahip olacaktır ve ayrıca siz doğrudan e-postaya yanıt vererek birleştirme isteği konu başlığına yorum yapabileceksiniz. -.Responses to emails are included in the thread. -image::images/maint-03-email-resp.png[Email response] -Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull ` syntax we saw earlier, or by adding the fork as a remote and fetching and merging. +.E-postalara verilen yanıtlar zincirde yer alır. +image::images/maint-03-email-resp.png[E-posta cevabı] -If the merge is trivial, you can also just hit the ``Merge'' button on the GitHub site. -This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. -This means that no matter what, every time you hit the merge button, a merge commit is created. -As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link. +Kodu beğendiğiniz ve birleştirmek istediğinizde, artık kodu yerelinize çekip birleştirebilirsiniz. +Bunun için ya önceden gördüğümüz `git pull ` sözdizimini kullanabilirsiniz ya da çatalı bir uzak sunucu olarak ekleyerek çekip birleştirebilirsiniz. + +Eğer birleştirme basitse, GitHub sitesindeki ``Merge`` (Birleştir) düğmesine basarak da işlemi gerçekleştirebilirsiniz. +Bir "ileri sarma" (fast-forward) birleştirmesi mümkün olsa bile "ileri sarma" olmayan bir birleştirme işlemi yapar ve bir birleştirme katkısı işler. +Bu, her durumda birleştirme düğmesine her basıldığında, bir birleştirme katkısı işlendiği anlamına gelir. +<<_merge_button>> bağlantısına tıklarsanız, GitHub size tüm bu bilgileri verecektir. [[_merge_button]] -.Merge button and instructions for merging a Pull Request manually. -image::images/maint-02-merge.png[Merge button] +.Birleştir dügmesi (merge) ve manuel birleştirme yönergesi. +image::images/maint-02-merge.png[Birleştirme dügmesi] -If you decide you don't want to merge it, you can also just close the Pull Request and the person who opened it will be notified. +Eğer birleştirmek istemediğinize karar verirseniz, doğrudan birleştirme isteğini kapatabilirsiniz. Bu durumda isteği açan kişiye bir bildirim gönderilir. [[_pr_refs]] ===== Pull Request Refs From 86257eafc4d78bd0bc580d515c252c3104cb119e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 23 Feb 2024 09:04:28 +0100 Subject: [PATCH 090/210] translate up to line:223 --- book/06-github/sections/3-maintaining.asc | 69 +++++++++++------------ 1 file changed, 34 insertions(+), 35 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 63e50bf2..f819cac8 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -119,18 +119,18 @@ image::images/maint-02-merge.png[Birleştirme dügmesi] Eğer birleştirmek istemediğinize karar verirseniz, doğrudan birleştirme isteğini kapatabilirsiniz. Bu durumda isteği açan kişiye bir bildirim gönderilir. [[_pr_refs]] -===== Pull Request Refs +===== Birleştirme İsteği Referansları -If you're dealing with a *lot* of Pull Requests and don't want to add a bunch of remotes or do one time pulls every time, there is a neat trick that GitHub allows you to do. -This is a bit of an advanced trick and we'll go over the details of this a bit more in <>, but it can be pretty useful. +Eğer *çok* fazla Birleştirme İsteği ile uğraşıyorsanız ama bir sürü uzak repo eklemek veya her seferinde bir defalık çekmeler yapmak istemiyorsanız; GitHub'ın size izin verdiği güzel bir hile var. +Bu biraz iler seviye bir hile (ayrıntılarını <> bölümünde göreceğiz) ama çok kullanışlı olabilir. -GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. -By default you don't get them when you clone, but they are there in an obscured way and you can access them pretty easily. +Aslında GitHub, bir repodaki birleştirme isteği dallarını sunucuda bir nevi sahte-dal olarak tanıtır. +Repoyu kopyaladığınızda bunlara da sahip olamazsınız, ancak bir şekilde orada gizlenmişlerdir ve onlara kolayca erişebilirsiniz. -To demonstrate this, we're going to use a low-level command (often referred to as a ``plumbing'' command, which we'll read about more in <>) called `ls-remote`. -This command is generally not used in day-to-day Git operations but it's useful to show us what references are present on the server. +Bunu göstermek için `ls-remote` adlı düşük seviyeli bir komut kullanacağız. (<> bölümünde `ls-remote` hakkında daha fazla bilgi bulacaksınız). +Bu komut genellikle günlük Git işlemlerinde pek ullanılmaz ancak sunucuda hangi referansların mevcut olduğunu göstermek için yararlıdır. -If we run this command against the ``blink'' repository we were using earlier, we will get a list of all the branches and tags and other references in the repository. +Daha önce kullandığımız "blink" reposu üzerinde bu komutu çalıştırırsak, repoda bulunan tüm dallar, etiketler ve diğer referansların bir listesini alırız. [source,console] ---- @@ -145,16 +145,16 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head 31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge ---- -Of course, if you're in your repository and you run `git ls-remote origin` or whatever remote you want to check, it will show you something similar to this. +Tabii ki, kendi reponuzdaysanız ve `git ls-remote origin` veya kontrol etmek istediğiniz herhangi bir uzak adı verirseniz, size bunun gibi bir şey gösterecektir. -If the repository is on GitHub and you have any Pull Requests that have been opened, you'll get these references that are prefixed with `refs/pull/`. -These are basically branches, but since they're not under `refs/heads/` you don't get them normally when you clone or fetch from the server -- the process of fetching ignores them normally. +Eğer repo GitHub'ta ise ve açılmış herhangi bir Birleştirme İsteğiniz varsa, `refs/pull/` ile başlayan bu referansları elde edersiniz. +Temel olarak bunlar dallardır, ancak `refs/heads/` altında olmadıkları için, sunucudan kopyalama veya çekme yoluyla onları normal bir şeklide almazsınız -- çekme komutu (fetch) onları doğal olarak yoksayar. -There are two references per Pull Request - the one that ends in `/head` points to exactly the same commit as the last commit in the Pull Request branch. -So if someone opens a Pull Request in our repository and their branch is named `bug-fix` and it points to commit `a5a775`, then in *our* repository we will not have a `bug-fix` branch (since that's in their fork), but we _will_ have `pull//head` that points to `a5a775`. -This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes. +Her birleştirme isteği için iki referans bulunur: `/head` ile biten referans, Birleştirme İsteği dalındaki son katkının tam olarak aynısına işaret eder. +Yani eğer biri bizim repomuzda bir birleştirme isteği açarsa ve onların `bug-fix` olarak adlandırılmış dalı `a5a775` katkısına işaret ediyorsa, o zaman _bizim_ repomuzda bir `bug-fix` dalımız olmayacaktır (çünkü bu dal o kişinin kendi reposundadır), ancak `pull//head` olarak `a5a775`'e işaret eden bir dalımız olacak. +Bu, bir sürü uzak depo eklemek zorunda kalmadan kolayca her birleştirme isteği dalını bir seferde indirebileceğimiz anlamına gelir. -Now, you could do something like fetching the reference directly. +Şimdi, doğrudan referansı almak için bir şeyler yapabilirsiniz. [source,console] ---- @@ -163,14 +163,14 @@ From https://github.com/libgit2/libgit2 * branch refs/pull/958/head -> FETCH_HEAD ---- -This tells Git, ``Connect to the `origin` remote, and download the ref named `refs/pull/958/head`.'' -Git happily obeys, and downloads everything you need to construct that ref, and puts a pointer to the commit you want under `.git/FETCH_HEAD`. -You can follow that up with `git merge FETCH_HEAD` into a branch you want to test it in, but that merge commit message looks a bit weird. -Also, if you're reviewing a *lot* of pull requests, this gets tedious. +Bu, Git'e `origin` uzak sunucusuna bağlanıp, `refs/pull/958/head` adındaki referansı indirmesini söyler. +Git mutlu bir şekilde size itaat eder: istediğiniz referansı oluşturmak için gereken her şeyi indirir ve `.git/FETCH_HEAD` altına bir işaretçi ekler. +Bunu, test etmek istediğiniz dallardan birinde `git merge FETCH_HEAD` ile takip edebilirsiniz, ancak birleştirme işlemi komutunun ileti metni biraz garip görünebilir. +Ayrıca, çok sayıda birleştirme isteğini inceliyorsanız, bu işlem sıkıcı hale gelir. -There's also a way to fetch _all_ of the pull requests, and keep them up to date whenever you connect to the remote. -Open up `.git/config` in your favorite editor, and look for the `origin` remote. -It should look a bit like this: +Ayrıca, _tüm_ birleştirme isteklerini almanın ve her bağlandığınızda bunları güncel tutmanın bir yolu daha var. +Favori metin düzenleyicinizde `.git/config` dosyasını açın ve `origin` uzak sunucusunu arayın. +Şöyle görünmelidir: [source,ini] ---- @@ -179,10 +179,10 @@ It should look a bit like this: fetch = +refs/heads/*:refs/remotes/origin/* ---- -That line that begins with `fetch =` is a ``refspec.'' -It's a way of mapping names on the remote with names in your local `.git` directory. -This particular one tells Git, "the things on the remote that are under `refs/heads` should go in my local repository under `refs/remotes/origin`." -You can modify this section to add another refspec: +`fetch =` ile başlayan satır, "refspec" olarak adlandırılan bir dizedir. +Bu, uzak sunucudaki adları yerel `.git` dizininizdeki adlarla eşleştirmek için kullanılan bir yoldur. +Buradaki Git'e, "uzak sunucuda `refs/heads` altındaki şeylerin, yerel repomda `refs/remotes/origin` altına gitmesi gerektiğini" söyler. +Başka bir refspec eklemek için bu bölümü değiştirebilirsiniz: [source,ini] ---- @@ -192,8 +192,8 @@ You can modify this section to add another refspec: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* ---- -That last line tells Git, ``All the refs that look like `refs/pull/123/head` should be stored locally like `refs/remotes/origin/pr/123`.'' -Now, if you save that file, and do a `git fetch`: +Bu son satır Git'e şunu söyler: "Tüm `refs/pull/123/head` gibi görünen referanslar yerel olarak `refs/remotes/origin/pr/123` şeklinde saklanmalıdır". +Şimdi, bu dosyayı kaydettikten ve bir `git fetch` yaptıktan sonra: [source,console] ---- @@ -205,8 +205,8 @@ $ git fetch # … ---- -Now all of the remote pull requests are represented locally with refs that act much like tracking branches; they're read-only, and they update when you do a fetch. -This makes it super easy to try the code from a pull request locally: +Şimdi tüm uzak birleştirme istekleri, yerelde izleyici dallar gibi davranan referanslarla temsil ediliyorlar; bunlar salt okunurdur ve bir çekme yapılğında güncelleniyor. +Bu, bir birleştirme isteğinden gelen kodu yerel olarak denemeyi son derece kolaylaştırır: [source,console] ---- @@ -216,12 +216,11 @@ Branch pr/2 set up to track remote branch pr/2 from origin. Switched to a new branch 'pr/2' ---- -The eagle-eyed among you would note the `head` on the end of the remote portion of the refspec. -There's also a `refs/pull/#/merge` ref on the GitHub side, which represents the commit that would result if you push the ``merge'' button on the site. -This can allow you to test the merge before even hitting the button. +Detaylara bakmayı sevenler, refspec'in uzak kısmında sonunda `head` olduğunu fark ederlerdi. +GitHub tarafında bir de `refs/pull/#/merge` referansı bulunur, bu da sitenin `merge` (birleştir) düğmesine tıkladığınızda ortaya çıkacak olan işlemi temsil eder. +Bu, düğmeye bile basmadan birleştirmeyi test edebilmenizi sağlar. - -===== Pull Requests on Pull Requests +===== Birleştirme İstekleri Üzerinde Birleştirme İstekleri Not only can you open Pull Requests that target the main or `master` branch, you can actually open a Pull Request targeting any branch in the network. In fact, you can even target another Pull Request. From 6dff27d63cea953e2ecaf32fe61001d7d34151d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 23 Feb 2024 15:44:22 +0100 Subject: [PATCH 091/210] correct typos --- book/06-github/sections/2-contributing.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index a7134723..175a7fa2 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -6,7 +6,7 @@ Artık bir Github hesabınız olduğuna göre, mevcut bir projeye katkıda bulun (((forking))) Bir erişim izniniz olmayan projeye katkıda bulunmak istiyorsanız, projeyi "çatallayabilirsiniz" (fork). -Bir projeyi "çataladığınızda", GitHub projenin tamamen size ait bir kopyasını oluşturur; bu, sizin derleminizde (derlem: namespace) bulunur ve üzerine değişikliklerinizi itebilirsiniz. +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] ==== @@ -492,7 +492,7 @@ Buna tıkladığınızda, GitHub'da Markdown ile yapabileceğiniz her şeyi içe [[_fetch_and_push_on_different_repositories]] -==== GitHub'taki Herkese Açık Repolarınızı Güncel Tututn +==== GitHub'taki Herkese Açık Repolarınızı Güncel Tututun Bir GitHub reposunu çatalladıktan sonra, "oluşturduğunuz çatal" artık sizin reponuzun bir parçasıdır ve orijinalinden bağımsız olur. Özellikle, orijinal repoya yeni katkılar işlendikçe; GitHub, şu şekilde bir mesajla sizi bilgilendirir: From a7a6a2e20d5189850fb66b9d88652464e3666cf8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Fri, 23 Feb 2024 15:49:37 +0100 Subject: [PATCH 092/210] Update translation --- book/06-github/sections/1-setting-up-account.asc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 26d44de8..fe522fc5 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -9,7 +9,8 @@ image::images/signup.png[GitHub kayıt formu.] Göreceğiniz bir sonraki şey, yükseltilmiş planların fiyatlandırma sayfasıdır, ancak şimdilik bunu yok sayabilirsiniz. GitHub, e-posta adresinizi doğrulamak için size bir e-posta gönderecektir. -İşleme devam edin ve şunu yapın: çok önemlidir (daha sonra göreceğimiz gibi). +E-posta ile gönderilen linki tıklayın ve işleme devam edin. +Daha sonra göreceğiniz üzere bu çok önemlidir. [NOT] ==== From f91d1505857a4d21208e7af42f101355160f48b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 26 Feb 2024 09:24:08 +0100 Subject: [PATCH 093/210] translate up to line: 271 --- book/06-github/sections/3-maintaining.asc | 58 +++++++++++------------ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index f819cac8..b0833982 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -222,53 +222,53 @@ Bu, düğmeye bile basmadan birleştirmeyi test edebilmenizi sağlar. ===== Birleştirme İstekleri Üzerinde Birleştirme İstekleri -Not only can you open Pull Requests that target the main or `master` branch, you can actually open a Pull Request targeting any branch in the network. -In fact, you can even target another Pull Request. +Yalnızca ana veya "master" dalı hedef alan birleştirme isteklerini açmakla kalmaz, aynı zamanda ağdaki herhangi bir dalı hedef alan bir birleştirme isteğini de açabilirsiniz. +Aslında başka bir birleştirme isteğini bile hedefleyebilirsiniz. -If you see a Pull Request that is moving in the right direction and you have an idea for a change that depends on it or you're not sure is a good idea, or you just don't have push access to the target branch, you can open a Pull Request directly to it. +Eğer doğru yönde ilerleyen bir istek görürseniz ve buna bağlı bir değişiklik fikriniz varsa veya bunun iyi bir fikir olduğundan henüz emin değilseniz, ya da sadece hedef dala itme erişiminiz yoksa; doğrudan bir istek açabilirsiniz. -When you go to open a Pull Request, there is a box at the top of the page that specifies which branch you're requesting to pull to and which you're requesting to pull from. -If you hit the ``Edit'' button at the right of that box you can change not only the branches but also which fork. +Bir birleştirme isteği açmak istediğinizde, sayfanın üst kısmında hangi dala çekmek istediğinizi ve hangisinden çekmek istediğinizi belirten bir kutu bulunur. O kutunun sağındaki ``Edit`` (Düzenle) düğmesine bastığınızda; sadece dalları değil, aynı zamanda belli bir çatalı da seçebileceğinizi göreceksiniz. [[_pr_targets]] -.Manually change the Pull Request target fork and branch. -image::images/maint-04-target.png[PR targets] +.Birleştirme isteğinin hedef çatalını ve dalını manuel olarak değiştirin. +image::images/maint-04-target.png[Birleştirme isteği hedefleri] -Here you can fairly easily specify to merge your new branch into another Pull Request or another fork of the project. +Burada, yeni dalınızı hangi birleştirme isteğine veya projenin hangi çatalına birleştireceğinizi kolaylıkla belirtebilirsiniz. -==== Mentions and Notifications +==== Bildirim ve İsim Etiketlemek -GitHub also has a pretty nice notifications system built in that can come in handy when you have questions or need feedback from specific individuals or teams. +GitHub'un ayrıca oldukça kullanışlı bir bildirim sistemi de bulunmaktadır; ki bu, belirli birey veya gruplara sorularınız olduğunda veya geribildirime ihtiyaç duyduğunuzda, çok işinize yarayabilir. -In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. +Herhangi bir yorumda `@` karakterini yazmaya başlarsanız, projedeki ortak ve katkıda bulunan kişilerin isim ve kullanıcı adları otomatik olarak tamamlanmaya başlar. -.Start typing @ to mention someone. -image::images/maint-05-mentions.png[Mentions] +.Birisinden bahsederken ismine @ karakteri ile başlayarak onu etiketleyin. +image::images/maint-05-mentions.png[İsim etiketleme] -You can also mention a user who is not in that dropdown, but often the autocompleter can make it faster. +Ayrıca, o seçenek listesinde olmayan bir kullanıcıyı da etiketleyebilirsiniz, ancak genellikle otomatik tamamlama daha hızlıdır. -Once you post a comment with a user mention, that user will be notified. -This means that this can be a really effective way of pulling people into conversations rather than making them poll. -Very often in Pull Requests on GitHub people will pull in other people on their teams or in their company to review an Issue or Pull Request. +Bir kullanıcının etiketlediğiniz bir yorumu gönderdiğinizde, o kullanıcı bir bildirim alır. +Bu, insanları konuşmalara dahil etmek için oldukça etkili bir yoldur ve anket yapmaktan kullanışlıdır. +GitHub'daki birleştirme isteklerinde, insanlar sıklıkla takım veya şirket arkadaşlarını, bir konu veya birleştirme isteğini gözden geçirmek amacıyla, bu sohbet alanına çekerler. -If someone gets mentioned on a Pull Request or Issue, they will be ``subscribed'' to it and will continue getting notifications any time some activity occurs on it. -You will also be subscribed to something if you opened it, if you're watching the repository or if you comment on something. -If you no longer wish to receive notifications, there is an ``Unsubscribe'' button on the page you can click to stop receiving updates on it. +Eğer birinin adı, bir Konu (issue) veya birleştirme isteğinde geçerse, o kişi o konuya "abone" olmuş olur ve herhangi bir işlem gerçekleştiğinde bildirim almaya devam eder. +Ayrıca, bir şeyi (konu, dal, vs) siz açtıysanız, bir repoyu izliyorsanız veya bir konuya yorum yaptıysanız, yine ona abone olursunuz. +Eğer artık bildirim almak istemiyorsanız, üzerinde güncellemeler almayı durdurmak için tıklayabileceğiniz bir ``Unsubscribe`` (Abonelikten Çık) düğmesi bulunmaktadır. -.Unsubscribe from an Issue or Pull Request. -image::images/maint-06-unsubscribe.png[Unsubscribe] +.Bir Konu veya Birleştirme İsteğinden çık. +image::images/maint-06-unsubscribe.png[Abonelikten çık] -===== The Notifications Page +===== Bildirimler Sayfası -When we mention ``notifications'' here with respect to GitHub, we mean a specific way that GitHub tries to get in touch with you when events happen and there are a few different ways you can configure them. -If you go to the ``Notification center'' tab from the settings page, you can see some of the options you have. +GitHub bağlamında "bildirimler" dediğimizde, kastettiğimiz şey: bir şey meydana geldiğinde, GitHub'un sizinle iletişime geçmeye çalıştığı belirli bir yöntemdir ve bunları yapılandırmanın birkaç farklı yolu vardır. +Ayarlar sayfasından ``Notification center`` (Bildirim merkezi) sekmesine giderseniz, sahip olduğunuz seçeneklerden bazılarını görebilirsiniz. -.Notification center options. -image::images/maint-07-notifications.png[Notification center] +.Bildirim merkezi seçenekleri. +image::images/maint-07-notifications.png[Bildirim merkezi] -The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching. +Bildirim almak için; ``E-posta`` üzerinden ve ``Web`` üzerinden olmak üzere iki seçeneğiniz bulunmaktadır. +Etkinliklere aktif olarak katıldığınızda ve izlediğiniz arşivlerdeki etkinlikler için bu ikisinden birini, hiçbirini veya her ikisini birden seçebilirsiniz. -====== Web Notifications +====== Ağ Bildirimleri Web notifications only exist on GitHub and you can only check them on GitHub. If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. From 2ebe9708fd7db357a820d238b2348d55f12c04eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 26 Feb 2024 17:55:02 +0100 Subject: [PATCH 094/210] Translate up to line: 370 --- book/06-github/sections/3-maintaining.asc | 101 +++++++++++----------- 1 file changed, 52 insertions(+), 49 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index b0833982..58e17599 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -270,31 +270,31 @@ Etkinliklere aktif olarak katıldığınızda ve izlediğiniz arşivlerdeki etki ====== Ağ Bildirimleri -Web notifications only exist on GitHub and you can only check them on GitHub. -If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. +Ağ bildirimleri yalnızca GitHub'ta mevcuttur ve bunları yalnızca GitHub'ta kontrol edebilirsiniz. +Eğer tercihlerinizde bu seçeneği işaretlerseniz ve sizin için bir bildirim tetiklenirse; ekranınızın üst kısmında bildirim simgesinin üzerinde <<_not_center>> şekilde görüldüğü gibi, küçük mavi bir nokta göreceksiniz. [[_not_center]] -.Notification center. -image::images/maint-08-notifications-page.png[Notification center] +.Bildirim merkezi. +image::images/maint-08-notifications-page.png[Bildirim merkezi] -If you click on that, you will see a list of all the items you have been notified about, grouped by project. -You can filter to the notifications of a specific project by clicking on its name in the left hand sidebar. -You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifications in a project by clicking the checkmark at the top of the group. -There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item. +O noktaya tıklarsanız, bildirildiğiniz tüm öğelerin bir listesini, projeye göre gruplandırılmış olarak göreceksiniz. +Sol kenar çubuğunda yazan proje ismine tıklayarak belirli bir projenin bildirimlerini filtreleyebilirsiniz. +Ayrıca, herhangi bir bildirimin yanındaki onay işareti simgesine tıklayarak bildirimi kabul edebilirsiniz veya bir projedeki _tüm_ bildirimleri onaylamak için grup üstündeki onay işaretine tıklayabilirsiniz. +Her onay işaretinin yanında bir sessize alma düğmesi de bulunur; bu düğmeye tıklayarak ilgili öğeyle ilgili daha fazla bildirim almayı durdurabilirsiniz. -All of these tools are very useful for handling large numbers of notifications. -Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen. +Tüm bu araçlar, büyük miktarda bildirimle başa çıkmak için çok kullanışlıdır. +Birçok deneyimli GitHub kullanıcısı, e-posta bildirimlerini tamamen kapatır ve tüm bildirimlerini bu ekran aracılığıyla yönetir. -====== Email Notifications +====== E-Posta Bildirimleri -Email notifications are the other way you can handle notifications through GitHub. -If you have this turned on you will get emails for each notification. -We saw examples of this in <<_email_notification>> and <<_email_pr>>. -The emails will also be threaded properly, which is nice if you're using a threading email client. +E-posta bildirimleri, GitHub üzerinden bildirimleri yönetmenin diğer bir yoludur. +Bunu açık şekilde ayarladıysanız, her bildirim için bir e-posta alırsınız. +Bunun örneklerini <<_email_notification>> ve <<_email_pr>>'de görmüştük. +E-postalar da düzgün bir şekilde konu başlığına göre gruplandırılır, eğer bir konu başlığına göre e-posta istemcisi kullanıyorsanız bu oldukça kullanışlıdır. -There is also a fair amount of metadata embedded in the headers of the emails that GitHub sends you, which can be really helpful for setting up custom filters and rules. +GitHub tarafından size gönderilen e-postaların başlıklarında gömülü bir miktar meta veri bulunur; bu da özel filtreler ve kurallar oluşturmak için gerçekten faydalı olabilir. -For instance, if we look at the actual email headers sent to Tony in the email shown in <<_email_pr>>, we will see the following among the information sent: +Örneğin, <<_email_pr>>'de gösterilen e-postada Tony'ye gönderilen gerçek e-posta başlıklarına baktığımızda, gönderilen bilgiler arasında aşağıdakileri göreceğiz: [source,mbox] ---- @@ -309,61 +309,64 @@ List-Unsubscribe: ,... X-GitHub-Recipient-Address: tchacon@example.com ---- -There are a couple of interesting things here. -If you want to highlight or re-route emails to this particular project or even Pull Request, the information in `Message-ID` gives you all the data in `///` format. -If this were an issue, for example, the `` field would have been ``issues'' rather than ``pull''. +Burada ilginç birkaç şey var. +Eğer bu belirli projeyi veya hatta bir birleştirme isteği ile ilgili e-postaları vurgulamak veya yeniden yönlendirmek istiyorsanız; `Message-ID` içindeki veriler, size tüm bilgileri `///` formatında verir. +Bu bir konu olsaydı; örneğin, `` alanı "pull" (çek) yerine, "issues" (konular) olarak belirtilirdi. -The `List-Post` and `List-Unsubscribe` fields mean that if you have a mail client that understands those, you can easily post to the list or ``Unsubscribe'' from the thread. -That would be essentially the same as clicking the ``mute'' button on the web version of the notification or ``Unsubscribe'' on the Issue or Pull Request page itself. +`List-Post` ve `List-Unsubscribe` alanları size (bu alanları anlayabilen bir posta istemciniz varsa), kolayca listeye gönderi yapabilmenizi veya konudan "Aboneliğinizi" kaldırabilmenizi sağlar. +Bu, esasen bildirimin ağ sürümündeki ``mute`` (sessize al) ya da Konu (issues) veya birleştirme isteği (Pull Request) sayfasında "unsubscribe" (Abonelikten Çık) düğmesine tıklamakla aynı olacaktır. -It's also worth noting that if you have both email and web notifications enabled and you read the email version of the notification, the web version will be marked as read as well if you have images allowed in your mail client. +Ayrıca, eğer hem e-posta hem de ağ bildirimleri etkinleştirilmişse, bildirinin e-posta sürümünü okursanız ve posta istemcinizde rde esimlere izin verilmişse; ağ sürümü de okunmuş olarak işaretlenir. -==== Special Files +==== Özel Dosyalar There are a couple of special files that GitHub will notice if they are present in your repository. -==== README +==== README (BENİOKU) Dosyası -The first is the `README` file, which can be of nearly any format that GitHub recognizes as prose. -For example, it could be `README`, `README.md`, `README.asciidoc`, etc. -If GitHub sees a README file in your source, it will render it on the landing page of the project. +Listenin başında `README` dosyası bulunur ve GitHub'ın yazı olarak tanıdığı neredeyse herhangi bir formatta olabilir. +Örneğin, `README`, `README.md`, `README.asciidoc`, vb. olabilir. +GitHub, kaynaklarınızda bir README dosyası görürse, bunu projenizin açılış sayfası görüntüsüne çevirir. -Many teams use this file to hold all the relevant project information for someone who might be new to the repository or project. -This generally includes things like: +Birçok ekip, repoya veya projeye yeni katılanlar için ilgili tüm proje bilgilerini içermek üzere, bu dosyayı kullanır. +Bu dosya genellikle şunları içerir: -* What the project is for -* How to configure and install it -* An example of how to use it or get it running -* The license that the project is offered under -* How to contribute to it +* Projenin amacı +* Nasıl yapılandırılacağı ve kurulacağı +* Nasıl kullanılacağı veya çalıştırılacağına dair bir örnek +* Projenin sunulduğu lisans +* Projeye nasıl katkıda bulunulacağı -Since GitHub will render this file, you can embed images or links in it for added ease of understanding. +GitHub bu dosyayı görüntüye çevireceği için, daha iyi anlaşılmasını sağlamak amacıyla içine görseller veya bağlantılar ekleyebilirsiniz. -==== CONTRIBUTING +==== CONTRIBUTING (KATILIM) -The other special file that GitHub recognizes is the `CONTRIBUTING` file. -If you have a file named `CONTRIBUTING` with any file extension, GitHub will show <<_contrib_file>> when anyone starts opening a Pull Request. +GitHub'ın tanıdığı diğer özel dosya `CONTRIBUTING` dosyasıdır. +Herhangi bir dosya uzantısına sahip `CONTRIBUTING` adında bir dosyanız varsa; biri birleştirme isteği açmaya başladığında, GitHub <<_contrib_file>> dosyasını gösterecektir. [[_contrib_file]] -.Opening a Pull Request when a CONTRIBUTING file exists. -image::images/maint-09-contrib.png[Contributing notice] +.CONTRIBUTING dosyası varken birleştirme isteği açılması. +image::images/maint-09-contrib.png[Katkı bildirimi] -The idea here is that you can specify specific things you want or don't want in a Pull Request sent to your project. -This way people may actually read the guidelines before opening the Pull Request. +Buradaki fikir, projenize gönderilen bir "birleştirme isteğine" belirli şeyleri isteyip istemediğinizi belirtebilmenizdir. +Bu şekilde, insanlar birleştirme isteği açmadan önce kuralları okuyabilirler. -==== Project Administration +==== Proje Yönetimi -Generally there are not a lot of administrative things you can do with a single project, but there are a couple of items that might be of interest. +Genel olarak, tek bir projede yapabileceğiniz çok fazla yönetim işi yoktur, ancak ilginizi çekebilecek birkaç öge bulunmaktadır. + +===== Varsayılan Dalı Değiştirmek + +Eğer varsayılan olarak insanların birleştirme isteği açmaları veya varsayılan olarak görmeleri için "main" (ana) dışında bir dal kullanıyorsanız, bunu repo ayarları sayfasında ``Options`` (Seçenekler) sekmesi altında değiştirebilirsiniz. -===== Changing the Default Branch If you are using a branch other than ``master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository's settings page under the ``Options'' tab. [[_default_branch]] -.Change the default branch for a project. -image::images/maint-10-default-branch.png[Default branch] +.Bir projenin varsayılan dalını değiştirmek. +image::images/maint-10-default-branch.png[Varsayılan dal] -Simply change the default branch in the dropdown and that will be the default for all major operations from then on, including which branch is checked out by default when someone clones the repository. +Sadece açılır menüde varsayılan dalı değiştirin; artık reponun kopyalanması da dahil, tüm önemli işlemler için varsayılan dal bu olacak. ===== Transferring a Project From ece364c074c674d55cf1d7169ffeefd21fe196c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 26 Feb 2024 19:50:27 +0100 Subject: [PATCH 095/210] Translate complete maintaining.asc --- book/06-github/sections/3-maintaining.asc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 58e17599..8c382ba2 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -368,15 +368,15 @@ image::images/maint-10-default-branch.png[Varsayılan dal] Sadece açılır menüde varsayılan dalı değiştirin; artık reponun kopyalanması da dahil, tüm önemli işlemler için varsayılan dal bu olacak. -===== Transferring a Project +===== Bir Projeyi Taşıma -If you would like to transfer a project to another user or an organization in GitHub, there is a ``Transfer ownership'' option at the bottom of the same ``Options'' tab of your repository settings page that allows you to do this. +GitHub'da bir projeyi başka bir kullanıcıya veya bir kuruluşa aktarmak istiyorsanız, repo ayarları sayfasının ``Options`` (Seçenekler) sekmesinin altında, bunu yapmanıza izin veren ``Transfer ownership`` (Sahipliği aktar) seçeneği bulunmaktadır. [[_transfer_project]] -.Transfer a project to another GitHub user or Organization. -image::images/maint-11-transfer.png[Transfer] +.Projeyj başka bir GitHub kullancı veya kuruluşuna aktar. +image::images/maint-11-transfer.png[Aktar] -This is helpful if you are abandoning a project and someone wants to take it over, or if your project is getting bigger and want to move it into an organization. +Bu özellik, bir projeyi bırakıyorsanız ve birisi onu devralmak istiyorsa ya da projeniz büyüyorsa ve onu bir kuruluşa taşımak istiyorsanız faydalı olabilir. -Not only does this move the repository along with all its watchers and stars to another place, it also sets up a redirect from your URL to the new place. -It will also redirect clones and fetches from Git, not just web requests. +Bu sadece repoyu tüm takipçi ve yıldızlarıyla birlikte başka bir yere taşımakla kalmaz, aynı zamanda URL'nizden yeni yere bir yönlendirme de kurar. +Ayrıca, sadece ağ isteklerini değil, kopyalama ve Git'ten getirmeleri de yönlendirir. From 1c4ed66a6e3255c2b81314a8a9c5fb9fa2ce3ca4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 26 Feb 2024 19:52:58 +0100 Subject: [PATCH 096/210] correct typo --- book/06-github/sections/2-contributing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 175a7fa2..c58a6c6e 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -278,7 +278,7 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Orijinal repoyu ``upstream'' adıyla bir uzak olarak ekleyin. +<1> Orijinal repoyu ``upstream`` adıyla bir uzak olarak ekleyin. <2> Bu uzaktan en yeni çalışmayı alın. <3> Bu reponun ana dalını kendi tema dalınıza birleştirin. <4> Oluşan çakışmayı düzeltin. From 8ca67ca9aca48a0a5fc5e8f310b2bd6b422f0023 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 26 Feb 2024 20:51:34 +0100 Subject: [PATCH 097/210] Translate complete managing-organization.asc --- .../sections/4-managing-organization.asc | 84 ++++++++++--------- 1 file changed, 43 insertions(+), 41 deletions(-) diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index f3137e5d..daa9bd95 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -1,72 +1,74 @@ [[ch06-github_orgs]] -=== Managing an organization +=== Kurumsal Yönetim (((GitHub, organizations))) -In addition to single-user accounts, GitHub has what are called Organizations. -Like personal accounts, Organizational accounts have a namespace where all their projects exist, but many other things are different. -These accounts represent a group of people with shared ownership of projects, and there are many tools to manage subgroups of those people. -Normally these accounts are used for Open Source groups (such as ``perl'' or ``rails'') or companies (such as ``google'' or ``twitter''). +Tek kullanıcı hesaplarına ek olarak, GitHub'ın "kuruluşlar" ad altında kurumsal hesapları da bulunmaktadır. +Kişisel hesaplar gibi, Kurumsal hesaplar da tüm projelerinin bulunduğu bir isim alanına sahiptir, ancak birçok farklı özelliğe de sahiptirler. +Bu hesaplar, projelerin ortak sahipliğini paylaşan bir grup insanı temsil eder ve bu insanların alt gruplarını yönetmek için birçok araç sunmaktadır. +Normalde, bu hesaplar Açık Kaynak grupları (örneğin ``perl`` veya ``rails``) veya şirketler (örneğin ``google`` veya ``twitter``) için kullanılır. -==== Organization Basics +==== Kısaca Kurumsal Hesap -An organization is pretty easy to create; just click on the ``+'' icon at the top-right of any GitHub page, and select ``New organization'' from the menu. +Kurumsal hesap oluşturmak oldukça kolaydır; herhangi bir GitHub sayfasının sağ üst köşesindeki ``+`` simgesine tıklayın ve menüden ``New organization`` (Yeni kuruluş) seçeneğini belirtin. -.The ``New organization'' menu item. -image::images/neworg.png[The ``New organization'' menu item.] +."Yeni kuruluş" ögesi. +image::images/neworg.png[``New organization`` ögesi.] -First you'll need to name your organization and provide an email address for a main point of contact for the group. -Then you can invite other users to be co-owners of the account if you want to. +İlk olarak, kuruluşunuzu adlandırmanız ve grup için bir ana iletişim noktası olarak bir e-posta adresi girmeniz gerekecektir. +Daha sonra, isterseniz, diğer kullanıcıları hesabın ortakları olarak davet edebilirsiniz. -Follow these steps and you'll soon be the owner of a brand-new organization. -Like personal accounts, organizations are free if everything you plan to store there will be open source. +Bu adımları izlerseniz, çok yakında yepyeni bir kuruluşun sahibi olacaksınız. +Orada saklayacağınız her şeyin açık kaynak olması durumunda, kişisel hesaplar gibi kurumsal hesaplar da ücretsizdir. -As an owner in an organization, when you fork a repository, you'll have the choice of forking it to your organization's namespace. -When you create new repositories you can create them either under your personal account or under any of the organizations that you are an owner in. -You also automatically ``watch'' any new repository created under these organizations. +Bir kuruluşun sahibi olarak bir repoyu çatalladığınızda, onu kuruluşunuzun ad alanına çatallamak üzere seçim yapabilirsiniz. +Yeni repolar oluşturduğunuzda, bunları kişisel hesabınızın altında veya sahip olduğunuz herhangi bir kuruluşun altında oluşturabilirsiniz. +Ayrıca, bu kuruluşlar altında oluşturulan her yeni repoyu, otomatik olarak "izlersiniz". -Just like in <<_personal_avatar>>, you can upload an avatar for your organization to personalize it a bit. -Also just like personal accounts, you have a landing page for the organization that lists all of your repositories and can be viewed by other people. +<<_personal_avatar>> "kişisel avatar"da olduğu gibi, kuruluşunuz için bir avatar yükleyerek, onu biraz kişiselleştirebilirsiniz. +Ayrıca kişisel hesaplar gibi, tüm repolarınızı listeleyen ve diğer insanlar tarafından görülebilen kurumsal bir açılış sayfasına sahipsiniz. -Now let's cover some of the things that are a bit different with an organizational account. +Şimdi de kurumsal hesaplarda biraz daha farklı olan bazı konuları ele alalım. -==== Teams +==== Takımlar -Organizations are associated with individual people by way of teams, which are simply a grouping of individual user accounts and repositories within the organization and what kind of access those people have in those repositories. +Kuruluşlar, bireysel kişilerle; bir nevi kuruluş içerisindeki bireysel kullanıcı hesapları ve bunların kurumsal repolara erişim türü grupları olan "takımlar" aracılığıyla ilişkilendirilir. -For example, say your company has three repositories: `frontend`, `backend`, and `deployscripts`. -You'd want your HTML/CSS/JavaScript developers to have access to `frontend` and maybe `backend`, and your Operations people to have access to `backend` and `deployscripts`. -Teams make this easy, without having to manage the collaborators for every individual repository. +Örnekle açıklamak gerekirse: diyelim ki şirketinizin üç reposu var: `frontend`, `backend` ve `deployscripts`. +HTML/CSS/JavaScript geliştiricilerinizin `frontend` ve belki de `backend` repolarına, Operasyon ekibinizin ise `backend` ve `deployscripts` repolarına erişimi olmasını istersiniz. +Takımlar özelliği, her bir repo için ayrı ayrı katılımcıları yönetmek zorunda kalmadan, bu işi kolaylaştırır. -The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organization. +Kuruluş sayfası, bu kuruluşun altındaki tüm repoları, kullanıcıları ve takımları içeren basit bir gösterge paneline sahiptir. [[_org_page]] -.The Organization page. +.Kuruluş sayfası. image::images/orgs-01-page.png[] -To manage your Teams, you can click on the Teams sidebar on the right hand side of the page in <<_org_page>>. -This will bring you to a page you can use to add members to the team, add repositories to the team or manage the settings and access control levels for the team. -Each team can have read only, read/write or administrative access to the repositories. -You can change that level by clicking the ``Settings'' button in <<_team_page>>. +Takımlarınızı yönetmek için, <<_org_page>> (kuruluş) sayfasının sağ tarafında bulunan "Teams" (Takımlar) kenar çubuğuna tıklayabilirsiniz. +Bu sizi takımlara üye veya repo ekleyebileceğiniz, veya takımın ayarlarını ve erişim kontrol seviyelerini yönetebileceğiniz bir sayfaya götürecektir. +Her takım, bu repolara salt okunur, okuma/yazma veya yönetici erişimli olarak ulaşabilir. +Bu erişim seviyelerini <<_team_page>> (takım) sayfasındaki ``Settings`` (Ayarlar) düğmesine tıklayarak değiştirebilirsiniz. [[_team_page]] -.The Team page. +.Takım sayfası. image::images/orgs-02-teams.png[] -When you invite someone to a team, they will get an email letting them know they've been invited. +Birini bir takıma davet ettiğinizde, davet edildiklerini bildiren bir e-posta alacaklardır. -Additionally, team `@mentions` (such as `@acmecorp/frontend`) work much the same as they do with individual users, except that *all* members of the team are then subscribed to the thread. -This is useful if you want the attention from someone on a team, but you don't know exactly who to ask. +Ek olarak, takım `@mentions`(etiketlemeleri) (ör. `@acmecorp/frontend`), bireysel kullanıcılarla aynı şekilde çalışır; ancak takımın *tüm* üyeleri o konuya abone olur. +Bu özellik, bir takımdan birinin dikkatini çekmek istiyor ancak tam olarak kime soracağınızı bilmiyorsanız, çok kullanışlıdır. -A user can belong to any number of teams, so don't limit yourself to only access-control teams. -Special-interest teams like `ux`, `css`, or `refactoring` are useful for certain kinds of questions, and others like `legal` and `colorblind` for an entirely different kind. +Bir kullanıcı birden fazla takıma üye olabilir, yani kendinizi sadece "access-control" (erişim kontrolü) takımlarıyla sınırlamayın. +`ux`, `css` veya `refactoring` (yeniden düzenleme) gibi özel ilgi takımları, belirli türdeki sorular için çok faydalıdır. Aslında bu `hukuk`, `renk körlüğü` vs gibi tamamen farklı türde olanlar için de öyledir. + +==== Denetim Kaydı + +Kurumsal hesaplar sahiplerine ayrıca kuruluş altında neler olduğuyla ilgili tüm bilgilere erişim de sağlar. +'Audit Log' (denetim kaydı) sekmesine giderek, kurumsal seviyede neler olduğunu, bunları kimin yaptığını ve dünyanın neresinde yapıldığını görebilirsiniz. -==== Audit Log -Organizations also give owners access to all the information about what went on under the organization. -You can go to the 'Audit Log' tab and see what events have happened at an organization level, who did them and where in the world they were done. [[_the_audit_log]] -.The Audit log. +.Denetim kaydı. image::images/orgs-03-audit.png[] -You can also filter down to specific types of events, specific places or specific people. +Ayrıca belirli türdeki etkinliklere, belirli yerlere veya belirli kişilere göre filtreleme yapabilirsiniz. From a4f7cadb948755c7255ee9b7f31cace5bdaa7850 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 27 Feb 2024 20:20:30 +0100 Subject: [PATCH 098/210] translate up to line: 37 - scripting.asc --- book/06-github/sections/5-scripting.asc | 46 ++++++++++++------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index b85917d7..2a367698 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -1,40 +1,40 @@ -=== Scripting GitHub +=== GitHub'ı otomatikleştirme -So now we've covered all of the major features and workflows of GitHub, but any large group or project will have customizations they may want to make or external services they may want to integrate. +Şimdi GitHub'ın tüm önemli özelliklerini ve iş akışlarını ele aldık, ancak büyük bir grup veya projenin her zaman yapabileceği özelleştirmeler veya eklemek isteyebileceği harici hizmetler olacaktır. -Luckily for us, GitHub is really quite hackable in many ways. -In this section we'll cover how to use the GitHub hooks system and its API to make GitHub work how we want it to. +Neyse ki, GitHub birçok yönden oldukça esnek. +Bu bölümde, GitHub'ın kanca (hook) sistemi ve API'sini nasıl kullanacağımızı ve GitHub'ı istediğimiz gibi çalıştırmak için nasıl kullanabileceğimizi ele alacağız. -==== Services and Hooks +==== Kancalar ve Hizmetler (Hooks and Services) -The Hooks and Services section of GitHub repository administration is the easiest way to have GitHub interact with external systems. +GitHub repo yönetiminin "Hooks and Services" (Kancalar ve Hizmetler) bölümü, GitHub'ı harici sistemlerle etkileştirmenin en kolay yoludur. -===== Services +===== Hizmetler (Services) -First we'll take a look at Services. -Both the Hooks and Services integrations can be found in the Settings section of your repository, where we previously looked at adding Collaborators and changing the default branch of your project. -Under the ``Webhooks and Services'' tab you will see something like <<_services_hooks>>. +Öncelikle Hizmetlere bir göz atalım. +Kancalar ve Hizmetler entegrasyonlarını, reponuzun - daha önce ortak eklemeyi ve projenizin varsayılan dalını değiştirdiğimiz yer olan- "Settings" (Ayarlar) bölümünde bulabilirsiniz. +``Webhooks and Services`` (ağ Kancaları ve Hizmetler) sekmesi altında <<_services_hooks>> gibi bir şey göreceksiniz. [[_services_hooks]] -.Services and Hooks configuration section. -image::images/scripting-01-services.png[Services and hooks] +.Hizmetler ve Kancalar yapılandırma bölümü. +image::images/scripting-01-services.png[Hizmetler ve kancalar] -There are dozens of services you can choose from, most of them integrations into other commercial and open source systems. -Most of them are for Continuous Integration services, bug and issue trackers, chat room systems and documentation systems. -We'll walk through setting up a very simple one, the Email hook. -If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>. +Çoğu diğer ticari ve açık kaynak sistemlere entegrasyon sunan onlarca hizmet arasından dileğinizi seçebilirsiniz. +Bunların çoğu, daimi entegrasyon hizmetleri, hata ve sorun izleyicileri, sohbet odası sistemleri ve belgeleme sistemleri içindir. +Şimdi bunlar içerisinden, çok basit bir hizmet olan E-posta kanca hizmetini kurmayı göstereceğiz. +Eğer ``Add Service`` (Hizmet Ekle) açılır menüsünden ``email``'i seçerseniz, karşınıza <<_service_config>> gibi bir yapılandırma ekranı çıkar. [[_service_config]] -.Email service configuration. -image::images/scripting-02-email-service.png[Email service] +.E-posta hizmet yapılandırması. +image::images/scripting-02-email-service.png[E-posta hizmeti] -In this case, if we hit the ``Add service'' button, the email address we specified will get an email every time someone pushes to the repository. -Services can listen for lots of different types of events, but most only listen for push events and then do something with that data. +Burada ``Add service`` (Hizmet ekle) düğmesine basarsak, birisi repomuza her itme yaptığında belirttiğimiz e-posta adresine bir e-posta gelir. +Hizmetler birçok farklı türde etkinlik dinleyebilir, ancak çoğu yalnızca itme etkinliklerini dinler ve ardından bu verilerle bir şeyler yapar. -If there is a system you are using that you would like to integrate with GitHub, you should check here to see if there is an existing service integration available. -For example, if you're using Jenkins to run tests on your codebase, you can enable the Jenkins builtin service integration to kick off a test run every time someone pushes to your repository. +Eğer GitHub ile entegre etmek istediğiniz bir sistem varsa, burada mevcut bir servis entegrasyonu olup olmadığını kontrol etmelisiniz. +Örneğin, kod tabanınızda testleri çalıştırmak için Jenkins kullanıyorsanız, Jenkins'in yerleşik hizmet entegrasyonunu etkinleştirerek, biri reponuza itme yaptığında bir test çalıştırabilirsiniz. -===== Hooks +===== Kancalar (Hooks) If you need something more specific or you want to integrate with a service or site that is not included in this list, you can instead use the more generic hooks system. GitHub repository hooks are pretty simple. From 0686747803b33a3e97c08f9645d80726f0b0079d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 28 Feb 2024 09:03:25 +0100 Subject: [PATCH 099/210] Translate up to line: 170 - scripting.asc --- book/06-github/sections/5-scripting.asc | 77 +++++++++++++------------ 1 file changed, 39 insertions(+), 38 deletions(-) diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 2a367698..b2b5b441 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -36,28 +36,29 @@ Eğer GitHub ile entegre etmek istediğiniz bir sistem varsa, burada mevcut bir ===== Kancalar (Hooks) -If you need something more specific or you want to integrate with a service or site that is not included in this list, you can instead use the more generic hooks system. -GitHub repository hooks are pretty simple. -You specify a URL and GitHub will post an HTTP payload to that URL on any event you want. +Eğer daha belirli bir ihtiyacınız varsa veya bu listede bulunmayan bir servis veya siteyle entegre olmak istiyorsanız, daha genel kancaları kullanabilirsiniz. +GitHub repo kancaları oldukça basittir. +Bir URL belirtirsiniz ve GitHub istediğiniz herhangi bir etkinlikte o URL'ye bir HTTP yükü (payload) gönderir. -Generally the way this works is you can setup a small web service to listen for a GitHub hook payload and then do something with the data when it is received. +Bu genellikle, GitHub kancası yükünü dinlemesi için küçük bir ağ hizmeti kurulması ve veri alındığında onunla bir şeyler yapması şeklinde çalışır. -To enable a hook, you click the ``Add webhook'' button in <<_services_hooks>>. -This will bring you to a page that looks like <<_web_hook>>. +Bir kancayı etkinleştirmek için <<_services_hooks>>'daki ``Add webhook`` (ağ kancası ekle) düğmesine tıklarsınız. +Bu sizi <<_web_hook>> gibi bir sayfaya götürecektir. [[_web_hook]] -.Web hook configuration. -image::images/scripting-03-webhook.png[Web hook] +.Ağ kancası yapılandırması. +image::images/scripting-03-webhook.png[Ağ kancası] -The configuration for a web hook is pretty simple. -In most cases you simply enter a URL and a secret key and hit ``Add webhook''. -There are a few options for which events you want GitHub to send you a payload for -- the default is to only get a payload for the `push` event, when someone pushes new code to any branch of your repository. +Bir ağ kancasını yapılandırmak çok basittir. +Çoğu durumda, sadece bir URL ve bir gizli anahtar girip, ardından ``Add webhook`` (Webhook ekle) düğmesine tıklarsınız. +GitHub'ın size bir yük göndermesini istediğiniz olaylar için birkaç seçenek vardır. +Varsayılan olarak, yalnızca birisi herhangi bir repo dalına yeni bir kod ittiğinde bir yük alacağınız 'push' (itme) olayıdır. -Let's see a small example of a web service you may set up to handle a web hook. -We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing. +Bir ağ kancasını yönetmek üzere ayarlayabileceğiniz bir ağ hizmetinin küçük bir örneğini görelim. +Oldukça kısa olduğundan ve ne yaptığımızı kolayca anlayabilmeniz gerektiğinden, Ruby ağ çerçevesi (framework) Sinatra'yı kullanacağız. -Let's say we want to get an email if a specific person pushes to a specific branch of our project modifying a specific file. -We could fairly easily do that with code like this: +Diyelim ki, belirli bir kişinin, belirli bir dosyayı değiştirerek, belirli bir dala ittiğinde bir e-posta almak istiyoruz. +Bunu aşağıdaki gibi bir kodla çok kolay bir şekilde yapabiliriz: [source,ruby] ---- @@ -93,37 +94,37 @@ post '/payload' do end ---- -Here we're taking the JSON payload that GitHub delivers us and looking up who pushed it, what branch they pushed to and what files were touched in all the commits that were pushed. -Then we check that against our criteria and send an email if it matches. +Burada GitHub'ın bize sunduğu JSON verisini alıp; kimin ittiğini, hangi dalı ittiğini ve hangi dosyaların değiştirildiğini kontrol ediyoruz. +Ardından, yukarıdaki kriterlere göre kontrol edip, eşleşiyorsa bir e-posta gönderiyoruz. -In order to develop and test something like this, you have a nice developer console in the same screen where you set the hook up. -You can see the last few deliveries that GitHub has tried to make for that webhook. -For each hook you can dig down into when it was delivered, if it was successful and the body and headers for both the request and the response. -This makes it incredibly easy to test and debug your hooks. +Böyle bir şey geliştirmek ve test etmek için, kancayı kurduğunuz ekranda güzel bir geliştirici konsolunuz bulunur. +GitHub'ın bu kanca için dağıtmaya çalıştığı son birkaç teslimatı görebilirsiniz. +Her kanca için: ne zaman teslim edildiğini, başarılı olup olmadığını, istek ve yanıtın gövdesini ve başlıklarını inceleyebilirsiniz. +Bu, kancalarınızı test etmeyi ve hataları ayıklamayı (debug) inanılmaz derecede kolaylaştırır. [[_web_hook_debug]] -.Web hook debugging information. -image::images/scripting-04-webhook-debug.png[Webhook debug] +.Ağ kancası hata ayıklama bilgileri. +image::images/scripting-04-webhook-debug.png[Ağ kancası hata ayıklama] -The other great feature of this is that you can redeliver any of the payloads to test your service easily. +Bunun diğer bir harika özelliği, hizmetinizi kolayca test etmek için yüklerden herhangi birini yeniden gönderebilmenizdir. -For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at https://developer.github.com/webhooks/ +Web kancalarının nasıl yazılacağı ve dinleyebileceğiniz tüm farklı olay (event) türleri hakkında daha fazla bilgi için [GitHub Geliştirici belgelerine](https://developer.github.com/webhooks/) bakabilirsiniz. -==== The GitHub API +==== GitHub API (((GitHub, API))) -Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? -What if you need to automate something like adding collaborators or labeling issues? +Hizmetler ve kancalar, repolarınızda gerçekleşen olaylar hakkında bildirim almanızı sağlar, ancak ya bu olaylar hakkında daha fazla bilgiye ihtiyacınız varsa! +Örneğin, projeye çalışma arkadaşı veya konulara etiket eklemek gibi bir şeyi otomatikleştirmeniz gerekiyorsa ne yapacaksınız? -This is where the GitHub API comes in handy. -GitHub has tons of API endpoints for doing nearly anything you can do on the website in an automated fashion. -In this section we'll learn how to authenticate and connect to the API, how to comment on an issue and how to change the status of a Pull Request through the API. +İşte GitHub API'sinin devreye girdiği yer burasıdır. +GitHub, hemen hemen ağ sayfasındaki neredeyse her şeyi otomatikleştirebileceğiniz birçok API uç noktasına sahiptir. +Bu bölümde, API'ye kimlik doğrulama yapmayı, API'ye bağlanmayı, bir konuya yorum yapmayı ve bir birleştirme isteğinin durumunu değiştirmeyi öğreneceğiz. -==== Basic Usage +==== Temel Kullanım -The most basic thing you can do is a simple GET request on an endpoint that doesn't require authentication. -This could be a user or read-only information on an open source project. -For example, if we want to know more about a user named ``schacon'', we can run something like this: +Yapabileceğiniz en temel şey, bir uç noktada kimlik doğrulaması gerektirmeyen basit bir GET isteğidir. +Bu, bir kullanıcı veya açık kaynaklı bir projedeki salt-okunur bilgiler olabilir. +Örneğin, ``schacon`` adlı bir kullanıcı hakkında daha fazla bilgi edinmek istiyorsak, şöyle bir şey çalıştırabiliriz: [source,javascript] ---- @@ -141,8 +142,8 @@ $ curl https://api.github.com/users/schacon } ---- -There are tons of endpoints like this to get information about organizations, projects, issues, commits -- just about anything you can publicly see on GitHub. -You can even use the API to render arbitrary Markdown or find a `.gitignore` template. +GitHub üzerinde görebileceğiniz - herkese açık olarak yayınlanan - neredeyse her şey (topluluklar, projeler, konular, katkılar, vs) hakkında bilgi alabileceğiniz, buna benzer birçok uç nokta bulunmaktadır. +API'yi kullanarak keyfinize göre bir Markdown oluşturabilir veya bir `.gitignore` şablonu bulabilirsiniz. [source,javascript] ---- @@ -166,7 +167,7 @@ hs_err_pid* ---- -==== Commenting on an Issue +==== Bir Konuda Yorum Yapmak However, if you want to do an action on the website such as comment on an Issue or Pull Request or if you want to view or interact with private content, you'll need to authenticate. From 7782f8f8731562dcaa853d4dde393b8ddb6edf65 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 28 Feb 2024 18:21:50 +0100 Subject: [PATCH 100/210] Translate complete - scripting.asc --- book/06-github/sections/5-scripting.asc | 83 ++++++++++++------------- 1 file changed, 41 insertions(+), 42 deletions(-) diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index b2b5b441..ece13141 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -169,30 +169,29 @@ hs_err_pid* ==== Bir Konuda Yorum Yapmak -However, if you want to do an action on the website such as comment on an Issue or Pull Request or if you want to view or interact with private content, you'll need to authenticate. +Ancak, bir konu ya da birleştirme isteğine yorum yapmak veya özel içeriği görüntülemek ya da onla etkileşime girmek gibi bir işlem yapmak istiyorsanız, kimlik doğrulaması yapmanız gerekecektir. -There are several ways to authenticate. -You can use basic authentication with just your username and password, but generally it's a better idea to use a personal access token. -You can generate this from the ``Applications'' tab of your settings page. +Kimlik doğrulamanın birkaç yolu vardır. +Sadece kullanıcı adı ve şifrenizle temel kimlik doğrulaması yapabilirsiniz, ancak kişisel bir erişim jetonu kullanmak genellikle daha iyidir. +Bunu, "Ayarlar" (Settings) sayfanızın "Uygulamalar" (Applications) sekmesinden oluşturabilirsiniz. [[_access_token]] -.Generate your access token from the ``Applications'' tab of your settings page. -image::images/scripting-05-access-token.png[Access Token] +.Ayarlar sayfanızın "Uygulamalar" sekmesinden erişim jetonu oluşturmak. +image::images/scripting-05-access-token.png[Erişim jetonu] -It will ask you which scopes you want for this token and a description. -Make sure to use a good description so you feel comfortable removing the token when your script or application is no longer used. +Size bu jetonu ne amaçla kullanmak istediğiniz sorulup, bir açıklama beklenecek. +Betiğiniz veya uygulamanız artık kullanılmadığında, jetonu kafanız rahat bir şekilde kaldırabilmek için, bu jetonu neden oluşturduğunuza dair iyi bir açıklama yazdığınızdan emin olun. -GitHub will only show you the token once, so be sure to copy it. -You can now use this to authenticate in your script instead of using a username and password. -This is nice because you can limit the scope of what you want to do and the token is revocable. +GitHub bu jetonu yalnızca bir kez gösterecektir, bu nedenle onu kopyaladığınızdan emin olun. +Bunu betik veya uygulamanızda kullanarak kimliğinizi doğruladığınız taktirde artık kullanıcı adı ve şifre kullanmak zorunda kalmayacaksınız. +Bunun güzel yanı, kullanım kapsamını sınırlayabilir veya istediğinizde iptal edebilirsiniz. -This also has the added advantage of increasing your rate limit. -Without authenticating, you will be limited to 60 requests per hour. -If you authenticate you can make up to 5,000 requests per hour. +Bu yöntem ayrıca, istek sınırınızı artırmak gibi ek bir avantaja da sahiptir. +Kimlik doğrulamasız, saatte 60 istekle sınırlanırsınız ama kimlik doğruladığınızda saatte 5.000 istek yapabilirsiniz. -So let's use it to make a comment on one of our issues. -Let's say we want to leave a comment on a specific issue, Issue #6. -To do so we have to do an HTTP POST request to `repos///issues//comments` with the token we just generated as an Authorization header. +Hadi bunu bir konuya yorum yapmak için kullanalım. +Diyelim ki belirli bir konuya (konu #6 diye adlandıralım) bir yorum bırakmak istiyoruz. +Bunu yapmak için yeni oluşturduğumuz jetonu bir yetkilendirme başlığı olarak kullanarak `repos///issues//comments` adresine bir HTTP POST isteği yapmamız gerekecek. [source,javascript] ---- @@ -216,23 +215,23 @@ $ curl -H "Content-Type: application/json" \ } ---- -Now if you go to that issue, you can see the comment that we just successfully posted as in <<_api_comment>>. +Şimdi bu konuya giderseniz, az önce başarıyla yayınladığımız yorumu <<_api_comment>> olarak görebilirsiniz. [[_api_comment]] -.A comment posted from the GitHub API. -image::images/scripting-06-comment.png[API Comment] +.GitHub API'den gönderilen bir yorum. +image::images/scripting-06-comment.png[API Yorumu] -You can use the API to do just about anything you can do on the website -- creating and setting milestones, assigning people to Issues and Pull Requests, creating and changing labels, accessing commit data, creating new commits and branches, opening, closing or merging Pull Requests, creating and editing teams, commenting on lines of code in a Pull Request, searching the site and on and on. +GitHub API'sini web sitesinde yapabileceğiniz hemen hemen her şeyi yapmak için kullanabilirsiniz: kilometre taşları oluşturma ve ayarlama, insanları görevlere ve birleştirme isteklerine atama, etiketler oluşturma ve değiştirme, katkı verilerine erişme, yeni katkı ve dallar oluşturma, birleştirme istekleri açma/kapatma veya birleştirme, takımlar oluşturma ve düzenleme, birleştirme isteğindeki kod satırlarına yorum yapma, siteyi arama yapma ve çok daha fazlası. -==== Changing the Status of a Pull Request +==== Birleştirme İsteğinin Durumunu Değiştirmek -There is one final example we'll look at since it's really useful if you're working with Pull Requests. -Each commit can have one or more statuses associated with it and there is an API to add and query that status. +Son olarak, birleştirme istekleriyle çalışıyorsanız oldukça yararlı olan bir örnek daha inceleyeceğiz. +Her bir işlem, bir veya daha fazla durumla ilişkilendirilebilir; bu durumları eklemek ve sorgulamak için bir API bulunmaktadır. -Most of the Continuous Integration and testing services make use of this API to react to pushes by testing the code that was pushed, and then report back if that commit has passed all the tests. -You could also use this to check if the commit message is properly formatted, if the submitter followed all your contribution guidelines, if the commit was validly signed -- any number of things. +"Sürekli Entegrasyon" ve test hizmetlerinin çoğu, kodun test edilmesi için yapılan itmelere (push) tepki vermek için bu API'yi kullanır ve ardından bu işlemin tüm testleri geçip geçmediğini bildirir. +Siz bu API ile, katkı mesajının uygun şekilde biçimlendirilip biçimlendirilmediğini, göndericinin sizin katkı rehberinize uyup uymadığını, katkının geçerli şekilde imzalanıp imzalanmadığını, vb bir çok şeyi kontrol etmek için kullanabilirsiniz. -Let's say you set up a webhook on your repository that hits a small web service that checks for a `Signed-off-by` string in the commit message. +Örneğin reponuzda, "katkı mesajında `Signed-off-by` dizesi olup olmadığını kontrol eden bir ağ hizmetine" erişen bir ağ kancası kurduğunuzu varsayalım. [source,ruby] ---- @@ -277,27 +276,27 @@ post '/payload' do end ---- -Hopefully this is fairly simple to follow. -In this web hook handler we look through each commit that was just pushed, we look for the string 'Signed-off-by' in the commit message and finally we POST via HTTP to the `/repos///statuses/` API endpoint with the status. +Umarım kolayca takip edebilirsin. +Bu web kancası işleyicisinde, yeni işlenen her katkıyı inceleyerek, katkı mesajında 'Signed-off-by' dizesini arıyoruz ve son olarak durumu (status) belirtmek için HTTP aracılığıyla `/repos///statuses/` API uç noktasına POST gönderiyoruz. -In this case you can send a state ('success', 'failure', 'error'), a description of what happened, a target URL the user can go to for more information and a ``context'' in case there are multiple statuses for a single commit. -For example, a testing service may provide a status and a validation service like this may also provide a status -- the ``context'' field is how they're differentiated. +Burada, bir durum ('success', 'failure', 'error'), ne yapıldığına ilişkin bir açıklama, kullanıcının daha fazla bilgi almak için gidebileceği bir hedef URL ve tek bir katkı için birden fazla durum (status) olması durumunda da bir ``bağlam`` (context) gönderebilirsiniz. +Örneğin, bir test hizmeti de veya bunun gibi bir doğrulama hizmeti de bir durum sağlayabilir; "bağlam" (context) alanı onların nasıl farklılaştırıldığını gösterir. -If someone opens a new Pull Request on GitHub and this hook is set up, you may see something like <<_commit_status>>. +Eğer birisi GitHub'da yeni bir birleştirme isteği açarsa ve bu kanca kurulmuşsa, <<_commit_status>> gibi bir şey görebilirsiniz. [[_commit_status]] -.Commit status via the API. -image::images/scripting-07-status.png[Commit status] +.API üzerinden katkı durumu. +image::images/scripting-07-status.png[Katkı durumu] -You can now see a little green check mark next to the commit that has a ``Signed-off-by'' string in the message and a red cross through the one where the author forgot to sign off. -You can also see that the Pull Request takes the status of the last commit on the branch and warns you if it is a failure. -This is really useful if you're using this API for test results so you don't accidentally merge something where the last commit is failing tests. +Artık, mesajında ``Signed-off-by`` dizesi bulunan katkının yanında küçük yeşil bir onay işareti görünürken, yazarın imzalamayı unuttuğu katkının yanında ise kırmızı bir çarpı işareti bulunduğunu görebilirsiniz. +Ayrıca, birleştirme isteğinin, daldaki son katkıyla aynı durum kodunu taşıdığını ve başarısızlık durumunda sizi uyardığını görebilirsiniz. +Eğer bu API'yi test sonuçları için kullanıyorsanız, testleri geçemeyen bir katkıyı yanlışlıkla birleştirmenizi engelleyeceği için, bu çok kullanışlıdır . ==== Octokit -Though we've been doing nearly everything through `curl` and simple HTTP requests in these examples, several open-source libraries exist that make this API available in a more idiomatic way. -At the time of this writing, the supported languages include Go, Objective-C, Ruby, and .NET. -Check out https://github.com/octokit[] for more information on these, as they handle much of the HTTP for you. +Bu örneklerde neredeyse her şeyi `curl` ve basit HTTP istekleri aracılığıyla yapmamıza rağmen, bazı açık kaynaklı kütüphaneler bu API'yi daha kendine özgü bir şekilde kullanmaktadır. +Bu yazının kaleme alındığı sırada desteklenen diller arasında Go, Objective-C, Ruby ve .NET de bulunmaktadır. +HTTP işlemlerinin birçoğunu sizin için halleden bu kütüphane hakkında daha fazla bilgi için https://github.com/octokit[] adresine bakabilirsiniz. -Hopefully these tools can help you customize and modify GitHub to work better for your specific workflows. -For complete documentation on the entire API as well as guides for common tasks, check out https://developer.github.com[]. +Umarım bu araçlar, GitHub'ı özelleştirerek, size özel iş akışlarının daha iyi çalışmasını sağlamanıza yardımcı olur. +Yaygın görevler için kılavuzlar ve API hakkında daha detaylı belgeler için https://developer.github.com[] adresine göz atabilirsiniz. From e696f1113a8aaffa82a06e86a2d8e18666f583c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:05:55 +0100 Subject: [PATCH 101/210] Update about-version-control.asc --- .../sections/about-version-control.asc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index df26e5c6..b5686dec 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -5,8 +5,8 @@ Versiyon kontrol, belirli versiyonların daha sonra çağrılabilmesi için zaman içerisinde bir dosya veya dosya grubundaki değişiklikleri kaydeden bir sistemdir. Örneğin bu kitapta, versiyon kontrol için yazılım kodları kullanılacaktır fakat versiyon kontrol bilgisayardaki herhangi bir dosya türü için de kullanılabilir. -Eğer grafik ya da web tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Versiyon Kontrol Sistemi (VKS) akıllıca bir seçim olacaktır. -Versiyon Kontrol Sistemi, seçili dosyaların bir önceki versiyona (bir önceki değişiklik yapılmış duruma) döndürülmesi, projenin tamamının bir önceki versiyona döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. +Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Versiyon Kontrol Sistemi (VKS) akıllıca bir seçim olacaktır. +Versiyon Kontrol Sistemi, seçili dosyaların bir önceki versiyona (bir önceki duruma) döndürülmesi, projenin tamamının bir önceki versiyona döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. Genel olarak VKS kullanmak, değişiklik yaptığınız dosyalar üzerinde bir şeyleri berbat ettiğinizde ya da bir şeyleri kaybettiğinizde kolayca geri getirebilmeniz anlamına gelmektedir. Ayrıca VKS'nin tüm bu özelliklerini çok az bir iş yüküyle elde edersiniz. @@ -30,7 +30,7 @@ RCS yama setlerini (dosyalar arasındaki farklılıklar) disk üzerinde özel bi (((version control,centralized))) İnsanların karşılaştığı bir diğer büyük problemse diğer sistemlerdeki geliştiricilerle iş birliği yapmak zorunda kalmalarıydı. Bu problemin çözümü olarak Merkezî Versiyon Kontrol Sistemleri (MVKS) geliştirildi. -Bu sistemler (CVS, Subversion ve Perforce gibi) bütün sürümlendirilmiş dosyaları barındıran tek bir sunucuya ve o sunucudaki dosyaları merkezî bir yerden sürekli denetleyen istemcilere sahipti. (((CVS)))(((Subversion)))(((Perforce))) +Bu sistemler (CVS, Subversion ve Perforce gibi) bütün sürümlendirilmiş dosyaları barındıran tek bir sunucuya ve o sunucudaki dosyaları tek merkezden sürekli denetleyen istemcilere sahipti. (((CVS)))(((Subversion)))(((Perforce))) Uzun yıllar boyunca bu sistem, versiyon kontrol sistemleri için standart oldu. .Merkezî versiyon kontrol. @@ -50,12 +50,12 @@ Yerel VKS'ler de aynı sorundan muzdariptir, projenin tüm tarihini ve dosyalar (((version control,distributed))) İşte tam da burada devreye Dağıtık Versiyon Kontrol Sistemleri (DVKS) giriyor. -Bir DVKS'de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok depoyu deponun tam tarihiyle birlikte yansıtırlar. -Dolayısıyla eğer herhangi bir sunucu devre dışı kalırsa, birbiriyle o sunucu aracılığıyla iş birliği yapan sistemlerdeki herhangi bir istemci deposu sunucuyu yenilemek için geri yüklenebilir. +Bir DVKS'de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok repoyu reponun tam tarihiyle birlikte yansıtırlar. +Dolayısıyla eğer herhangi bir sunucu devre dışı kalırsa, birbiriyle o sunucu aracılığıyla iş birliği yapan sistemlerdeki herhangi bir istemci reposu sunucuyu yenilemek için geri yüklenebilir. Her klon, en nihayetinde tüm verilerin tam bir yedeğidir aslında. .Dağıtık versiyon kontrol. image::images/distributed.png[Dağıtık versiyon kontrol şeması] -Ayrıca bu sistemlerin çoğu birden çok uzak depoyla çalışmayı rahatlıkla kaldırabilir, o yüzden farklı gruplardan insanlarla farklı yollarla eş zamanlı bir şekilde rahatlıkla iş birliği yapabilirsiniz. +Ayrıca bu sistemlerin çoğu birden çok uzak repoyla çalışmayı rahatlıkla kaldırabilir, o yüzden farklı gruplardan insanlarla farklı yollarla eş zamanlı bir şekilde rahatlıkla iş birliği yapabilirsiniz. Bu da size hiyerarşik model gibi merkezi sistemlerde yapması mümkün olmayan birden çok iş akışı şekli tanımlama ve kullanma olanağı sağlar. From de7666c1ccf5ecdd7839316644380fd97f528cfc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:08:07 +0100 Subject: [PATCH 102/210] Update command-line.asc --- book/01-introduction/sections/command-line.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 9b4952a7..0d70ffb0 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,12 +1,12 @@ === Komut Satırı Git'i kullanmanın pek çok farklı yolu vardır. -Orijinal komut-satırlarının yanında, birbirinden çok farklı yeteneklere sahip grafiksel kullanıcı arayüzleri de vardır. +Orijinal komut-satırlarının yanında, birbirinden çok farklı yeteneklere sahip görsel kullanıcı arayüzleri de vardır. Bu kitapta Git'i komut satırı üzerinden kullanacağız. -Özellikle bilmeniz gereken şey ise, komut satırında __tüm__ Git komutlarını çalıştırabiliyor olmanızdır. Çoğu GKA (grafiksel kullanıcı arayüzü) sadelik için Git'in fonksiyonlarının sadece belli başlı, küçük bir kısmını kullanmaya izin verir. +Özellikle bilmeniz gereken şey ise, komut satırında __tüm__ Git komutlarını çalıştırabiliyor olmanızdır. Çoğu GUI (Graphical User Interface: görsel kullanıcı arayüzü) sadelik için Git'in fonksiyonlarının sadece belli başlı, küçük bir kısmını kullanmaya izin verir. -Eğer komut satırını nasıl çalıştıracağınızı biliyorsanız muhtemelen GKA'nın nasıl çalıştırılabileceğini de bulabilirsiniz. Ancak bu durumun tersi her zaman geçerli olmayabilir. -Ayrıca kullanacağınız grafiksel istemci her ne kadar sizin kişisel zevkinize bağlı olsa da, __bütün__ kullanıcılar komut satırı araçlarını yüklemiş ve kullanmaya hazır durumda tutuyor olmalı. +Eğer komut satırını nasıl çalıştıracağınızı biliyorsanız muhtemelen GUI'nin nasıl çalıştırılabileceğini de bulabilirsiniz. Ancak bu durumun tersi her zaman geçerli olmayabilir. +Ayrıca kullanacağınız görsel istemci her ne kadar sizin kişisel zevkinize bağlı olsa da, __bütün__ kullanıcılar komut satırı araçlarını yüklemiş ve kullanmaya hazır durumda tutuyor olmalı. O yüzden sizden macOS'daki Terminal'i ya da Windows'taki Komut İstemi'ni veya PowerShell'i nasıl açacağınızı biliyor olmanızı bekliyoruz. Eğer neyden bahsettiğimizden bihaberseniz, burada biraz ara verip bu konuda araştırma yapıp kitabı öyle okumanızı öneririz. Aksi takdirde kitabın devamındaki açıklamaları ve örnekleri anlayamayabilirsiniz. From 1abfe9eabc794aa2507f21a6c1cbf6254cb87ed7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:11:55 +0100 Subject: [PATCH 103/210] Update about-version-control.asc --- .../sections/about-version-control.asc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index b5686dec..7f6a587c 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -5,7 +5,7 @@ Versiyon kontrol, belirli versiyonların daha sonra çağrılabilmesi için zaman içerisinde bir dosya veya dosya grubundaki değişiklikleri kaydeden bir sistemdir. Örneğin bu kitapta, versiyon kontrol için yazılım kodları kullanılacaktır fakat versiyon kontrol bilgisayardaki herhangi bir dosya türü için de kullanılabilir. -Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Versiyon Kontrol Sistemi (VKS) akıllıca bir seçim olacaktır. +Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Versiyon Kontrol Sistemi (VCS: Version Control System) akıllıca bir seçim olacaktır. Versiyon Kontrol Sistemi, seçili dosyaların bir önceki versiyona (bir önceki duruma) döndürülmesi, projenin tamamının bir önceki versiyona döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. Genel olarak VKS kullanmak, değişiklik yaptığınız dosyalar üzerinde bir şeyleri berbat ettiğinizde ya da bir şeyleri kaybettiğinizde kolayca geri getirebilmeniz anlamına gelmektedir. Ayrıca VKS'nin tüm bu özelliklerini çok az bir iş yüküyle elde edersiniz. @@ -22,23 +22,23 @@ Tüm bu sorunlardan ötürü, uzun zaman önce geliştiriciler, yapılan tüm de .Yerel versiyon kontrol. image::images/local.png[Yerel versiyon kontrol şeması] -En popüler VKS araçları RCS adında bir sistemdi, ki kendisi bugün bile hâlâ pek çok bilgisayarda kullanılır. +En popüler VCS araçları RCS adında bir sistemdi, ki kendisi bugün bile hâlâ pek çok bilgisayarda kullanılır. RCS yama setlerini (dosyalar arasındaki farklılıklar) disk üzerinde özel bir formatta tutarak çalışır; daha sonra tüm yamaları bir araya getirerek herhangi bir zamanda herhangi bir dosyanın nasıl göründüğüne bakarak onu yeniden oluşturabilir. ==== Merkezî Versiyon Kontrol Sistemleri (((version control,centralized))) İnsanların karşılaştığı bir diğer büyük problemse diğer sistemlerdeki geliştiricilerle iş birliği yapmak zorunda kalmalarıydı. -Bu problemin çözümü olarak Merkezî Versiyon Kontrol Sistemleri (MVKS) geliştirildi. +Bu problemin çözümü olarak Merkezî Versiyon Kontrol Sistemleri (CVCS: Central VCS) geliştirildi. Bu sistemler (CVS, Subversion ve Perforce gibi) bütün sürümlendirilmiş dosyaları barındıran tek bir sunucuya ve o sunucudaki dosyaları tek merkezden sürekli denetleyen istemcilere sahipti. (((CVS)))(((Subversion)))(((Perforce))) Uzun yıllar boyunca bu sistem, versiyon kontrol sistemleri için standart oldu. .Merkezî versiyon kontrol. image::images/centralized.png[Merkezî versiyon kontrol şeması] -Bu kurulum yerel VKS'lere kıyasla pek çok avantaj sunar. +Bu kurulum yerel VCS'lere kıyasla pek çok avantaj sunar. Örneğin, projedeki herkes diğer herkesin projede ne yaptığını belli bir ölçüye kadar bilebilir. -Yöneticiler, kimin ne yapabileceği konusunda hassas bir kontrole sahiptir ve bir MVKS'yi yönetmek her istemcideki yerel veritabanlarıyla uğraşmaktan çok daha kolaydır. +Yöneticiler, kimin ne yapabileceği konusunda hassas bir kontrole sahiptir ve bir CVCS'yi yönetmek her istemcideki yerel veritabanlarıyla uğraşmaktan çok daha kolaydır. Bununla birlikte bu kurulumun ciddi dezavantajları da vardır. En bariz olanı merkezi sunucuların tek bir noktaya bağlı olmasıdır. @@ -49,8 +49,8 @@ Yerel VKS'ler de aynı sorundan muzdariptir, projenin tüm tarihini ve dosyalar ==== Dağıtık Versiyon Kontrol Sistemleri (((version control,distributed))) -İşte tam da burada devreye Dağıtık Versiyon Kontrol Sistemleri (DVKS) giriyor. -Bir DVKS'de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok repoyu reponun tam tarihiyle birlikte yansıtırlar. +İşte tam da burada devreye Dağıtık Versiyon Kontrol Sistemleri (DVCS: Distributed VCS) giriyor. +Bir DVCS'de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok repoyu reponun tam tarihiyle birlikte yansıtırlar. Dolayısıyla eğer herhangi bir sunucu devre dışı kalırsa, birbiriyle o sunucu aracılığıyla iş birliği yapan sistemlerdeki herhangi bir istemci reposu sunucuyu yenilemek için geri yüklenebilir. Her klon, en nihayetinde tüm verilerin tam bir yedeğidir aslında. From e918046d473b9a1efa07cd7f8281d6b26c310d1c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:37:19 +0100 Subject: [PATCH 104/210] Update first-time-setup.asc --- .../sections/first-time-setup.asc | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index b2e922d5..db30adda 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -5,24 +5,24 @@ Bu ayarları bir bilgisayarda yalnızca bir kere yapmanız yeterli, güncelleme yapsanız bile kaybolmayacaklardır. Ayrıca istediğinizde gerekli komutları çalıştırarak onları değiştirebilirsiniz. -Git, `git config` adında, size Git'in tüm yönleriyle nasıl göründüğünü ve çalıştığını kontrol eden yapılandırma değişkenlerini görme ve değiştirme kabiliyetini veren bir araca sahiptir. +Git, `git config` adında, size Git'in tüm yönleriyle nasıl göründüğünü ve çalıştığını yöneten, yapılandırma değişkenlerini görme ve değiştirme kabiliyetini veren bir araca sahiptir. Bu değişkenler üç farklı yerde saklanabilir: -1. `/etc/gitconfig` dosyası: Sistemdeki tüm kullanıcılara ve onların repository'lerine uygulanmış olan değerleri içerir. +1. `/etc/gitconfig` dosyası: Sistemdeki tüm kullanıcılara ve onların repolarına uygulanmış olan değerleri içerir. Eğer `git config` komutuna `--system` opsiyonunu eklerseniz, okuma ve yazma işlemlerini bu dosya üzerinden gerçekleştirir. (Çünkü bu bir sistem yapılandırma dosyasıdır, değişiklik yapmak için yönetici veya süper kullanıcı ayrıcalığına ihtiyacınız vardır.) -2. `~/.gitconfig` ya da `~/.config/git/config` dosyası: Spesifik olarak size, sizin kullanıcı hesabınıza ait olan değerler. - `--global` opsiyonunu yazarak Git'in okuma ve yazma işlemlerini spesifik olarak bu dosya üzerinden yapmasını sağlayabilirsiniz, bu durum sisteminizde çalıştığınız _tüm_ reposity'leri etkiler. -3. Hangi repository'i kullanıyorsanız o repository'deki Git klasöründeki `config`dosyası (tam olarak `.git/config`): O spesifik repository'e özgüdür. - Git'i `--local` komutuyla bu dosya üzerinden okuma ve yazma işlemlerini yapmaya zorlayabilirsiniz, hatta bu opsiyon aslında varsayılan olarak gelir. - (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) +2. `~/.gitconfig` ya da `~/.config/git/config` dosyası: Size özel ve sizin kullanıcı hesabınıza ait olan değerler. + `--global` seçeneğini yazarak Git'in okuma ve yazma işlemlerini özellikle bu dosya üzerinden yapmasını sağlayabilirsiniz, bu durum sisteminizde çalıştığınız _tüm_ repoları etkiler. +3. Hangi repoyu kullanıyorsanız o repodaki Git klasöründeki `config`dosyası (tam olarak `.git/config`): O repoya özgüdür. + Git'i `--local` komutuyla bu dosya üzerinden okuma ve yazma işlemlerini yapmaya zorlayabilirsiniz, hatta bu seçim aslında varsayılan olarak gelir. + (Doğal olarak, bu seçeneğin düzgün çalışması için, bir Git reposunun içinde bulunmanız gerekmektedir.) -Her seviyedeki değerler, kendilerinden bir önceki seviyede olan değerleri geçersiz kılar. Dolayısıyla `.git/config` değerleri `/etc/gitconfig` değerlerini geçersiz kılar. +Herhangi bir seviyedeki değerler, kendinden bir önceki seviyede olan değerleri geçersiz kılar. Dolayısıyla `.git/config` değerleri `/etc/gitconfig` değerlerini geçersiz kılar. Windows sistemlerinde Git, `$HOME` klasöründeki `.gitconfig` dosyasını arar. (çoğu kişide `C:\Users\$USER` konumundadır) -Git'i bilgisayarınıza kurarken nereye kurulacağını seçtiğiniz `etc/gitconfig` dosyasını, MSys köküne özgü olmasına rağmen, hâlâ arar. -Eğer Windows için Git'in 2.x veya daha versiyonunu kullanıyorsanız, Windows XP'de `C:\Documents and Settings\All Users\Application Data\Git\config` sistem-seviyesinde bulunan bir yapılandırma dosyası vardır. Windows Vista ve daha yeni versiyonlardaki konumu ise: `C:\ProgramData\Git\config`. -This config file can only be changed by `git config -f ` as an admin. +MSys köküyle ilintili olmasına rağmen, Git'i bilgisayarınıza kurarken nereye kurulacağını seçtiğiniz `etc/gitconfig` dosyasını da arar. +Eğer Windows için Git'in 2.x veya daha iler bir sürümünü kullanıyorsanız, Windows XP'de `C:\Documents and Settings\All Users\Application Data\Git\config` sistem-seviyesinde bulunan bir yapılandırma dosyası vardır. Windows Vista ve daha yeni sürümlerdeki konumu ise: `C:\ProgramData\Git\config`. +Bu yapılandırma dosyası yalnızca bir yönetici olarak `git config -f ` kullanılarak değiştirilebilir. Tüm ayarlarınızı ve onların nereden geldiğini görmek için şu komutu kullanabilirsiniz: @@ -33,8 +33,8 @@ $ git config --list --show-origin ==== Kimliğiniz -Git'i ilk kurduğunuzda yapmanız gereken ilk şey, kullanıcı adınızı ve email'inizi belirlemek olmalıdır. -Bunu yapmak önemlidir çünkü her Git commit'i bu bilgileri kullanır ve tüm yarattığınız commitlere değişmez bir şekilde gömülmüştür. +Git'i ilk kurduğunuzda yapmanız gereken ilk şey, kullanıcı adınızı ve e-postanızı belirlemek olmalıdır. +Bunu yapmak önemlidir çünkü her Git katkısı (commit) bu bilgileri kullanır ve tüm işlediğiniz katkılara değişmez bir şekilde gömülmüştür. [source,console] ---- @@ -42,15 +42,15 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -`--global` opsiyonunu kullandığınızda bu işlemi yalnızca bir kere yaptığınızı tekrar etmekte fayda var çünkü Git sisteminizde her zaman global olarak tanımladığınız bilgiyi kullanacaktır. -Eğer bu bilgileri spesifik bir proje için geçersiz kılmak ve o projeye özgü bilgiler tanımlamak isterseniz, projenin içindeyken komutu `--global` opsiyonu olmadan çalıştırın. +`--global` seçeneğini kullandığınızda bu işlemi yalnızca bir kere yaptığınızı tekrar etmekte fayda vardır, çünkü Git sisteminizde her zaman global olarak tanımladığınız bilgiyi kullanacaktır. +Eğer bu bilgileri bir projeye özel olarak geçersiz kılmak ve o projeye özgü bilgiler tanımlamak isterseniz, bu komutu projenin içindeyken ve `--global` seçeneği "olmadan" çalıştırın. -GKA araçlarının çoğu onları ilk çalıştırdığınızda bu bilgileri tanımlamanız için size yardımcı olacaktır. +VCS araçlarının çoğu onları ilk çalıştırdığınızda bu bilgileri tanımlamanız için size yardımcı olacaktır. [[_editor]] ==== Editörünüz -Şimdi kimliğinizi tanımladığımıza göre, mesaj yazmak için kullanacağınız varsayılan metin editörü ayarınızı yapmanın zamanı geldi. Eğer bu ayarı yapmazsanız, Git, sisteminizin varsayılan editörünü kullanacaktır. +Kimliğinizi artık tanımladığımıza göre, mesaj yazmak için kullanacağınız varsayılan metin editörü ayarınızı yapılandırmanın zamanı geldi. Eğer bu ayarı yapmazsanız, Git, sisteminizin varsayılan editörünü kullanacaktır. Eğer Emacs gibi farklı bir metin editörü kullanmak isterseniz, şunu yapabilirsiniz: @@ -62,7 +62,7 @@ $ git config --global core.editor emacs Windows sisteminde farklı bir metin editörü kullanmak isterseniz o editörün çalıştırılabilir dosyasının tam yolunu belirtmelisiniz. Bu durum da editörünüzün nasıl paketlendiğine bağlı olarak değişiklik gösterebilir. -Popüler bir editör olan Notepad++'i, 64-bit'lik versiyonlar tüm plug-in'leri desteklemediği için yüksek ihtimalle 32-bit'lik versiyonla kullanacaksınız. +Popüler bir editör olan Notepad++'ı, 64-bit'lik sürümler tüm eklentileri desteklemediği için yüksek ihtimalle 32-bit'lik sürüm kullanacaksınız. Eğer 32-bit'lik bir Windows sistemdeyseniz ya da 64-bit'lik sistemde 64-bit'lik editöre sahipseniz, şöyle bir komut girmelisiniz: [source,console] @@ -70,16 +70,16 @@ 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" ---- -[NOTE] +[NOT] ==== 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 versiyon kullanıyorsanız, favori editörünüzü nasıl kuracağınız hakkında bilgi almak için şurayı okuyabilirsiniz: <> +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: <> ==== -[WARNING] +[UYARI] ==== 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. -An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit. +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. ==== ==== Ayarlarınızı Gözden Geçirmek @@ -100,7 +100,7 @@ color.diff=auto Anahtarlara birden çok kez rastlayabilirsiniz çünkü Git aynı anahtarı farklı dosyalardan okur (örneğin `/etc/gitconfig` ve `~/.gitconfig`). Bu durumda, Git gördüğü her eşsiz anahtar için son değeri kullanır. -Ayrıca Git'in spesifik bir anahtarın değeri hakkında ne düşündüğünü görmenin yolu da şu şekildedir: `git config `:(((git commands, config))) +Ayrıca Git'in belli bir anahtarın değeri hakkında ne düşündüğünü görmenin yolu da şu şekildedir: `git config `:(((git commands, config))) [source,console] ---- @@ -108,7 +108,7 @@ $ git config user.name John Doe ---- -[NOTE] +[NOT] ==== 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: From f1e95a2348ea9209c37a171b38d13690acc1da72 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:42:50 +0100 Subject: [PATCH 105/210] Update about-version-control.asc --- .../sections/about-version-control.asc | 40 +++++++++---------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 7f6a587c..b846b9d2 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,40 +1,40 @@ -=== Versiyon Kontrol +=== Sürüm Denetimi (((version control))) -'Versiyon kontrol' nedir ve neden önemsenmelidir? -Versiyon kontrol, belirli versiyonların daha sonra çağrılabilmesi için zaman içerisinde bir dosya veya dosya grubundaki değişiklikleri kaydeden bir sistemdir. -Örneğin bu kitapta, versiyon kontrol için yazılım kodları kullanılacaktır fakat versiyon kontrol bilgisayardaki herhangi bir dosya türü için de kullanılabilir. +'Sürüm Denetimi' nedir ve neden önemsenmelidir? +Sürüm denetimi, belirli sürümlerin daha sonra çağrılabilmesi için zaman içerisinde bir dosya veya dosya grubundaki değişiklikleri kaydeden bir sistemdir. +Örneğin bu kitapta, sürüm denetimi için yazılım kodları kullanılacaktır fakat sürüm denetimi bilgisayardaki herhangi bir dosya türü için de kullanılabilir. -Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Versiyon Kontrol Sistemi (VCS: Version Control System) akıllıca bir seçim olacaktır. -Versiyon Kontrol Sistemi, seçili dosyaların bir önceki versiyona (bir önceki duruma) döndürülmesi, projenin tamamının bir önceki versiyona döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. +Eğer grafik ya da ağ tasarımcı iseniz ve çalıştığınız görüntü ya da tasarımların her bir değişikliklerini tutmak istiyorsanız (ki bu gerçekten istebilecek bir şeydir), Sürüm Denetim Sistemi (VCS: Version Control System) akıllıca bir seçim olacaktır. +Sürüm Denetim Sistemi, seçili dosyaların bir önceki sürüme (bir önceki duruma) döndürülmesi, projenin tamamının bir önceki sürüme döndürülmesi, zaman içerisinde yapılan değişikliklerin karşılaştırılması, probleme neden olabilecek değişikliklerin en son kimin tarafından yapıldığı, kim bir problemden ne zaman bahsetti gibi bir çok işlemin gerçekleştirilebilmesini sağlar. Genel olarak VKS kullanmak, değişiklik yaptığınız dosyalar üzerinde bir şeyleri berbat ettiğinizde ya da bir şeyleri kaybettiğinizde kolayca geri getirebilmeniz anlamına gelmektedir. Ayrıca VKS'nin tüm bu özelliklerini çok az bir iş yüküyle elde edersiniz. -==== Yerel Versiyon Kontrol Sistemleri +==== Yerel Sürüm Denetim Sistemleri (((version control,local))) -Çoğu insanın versiyon kontrol metodu, ilgili dosyaları başka bir yere kopyalamaktır (Muhtemelen daha zeki olanları, klasör isimlendirmesinde zaman damgası kullanıyordur). +Çoğu insanın sürüm denetim yöntemi, ilgili dosyaları başka bir yere kopyalamaktır (Muhtemelen daha zeki olanları, klasör isimlendirmesinde zaman damgası kullanıyordur). Bu yaklaşım basit olduğundan çok yaygındır fakat aynı zamanda inanılmaz derecede hataya açık bir yaklaşımdır. Hangi dizinde bulunduğunuzu unutmak, yanlışlıkla yanlış dosya üzerine yazmak veya istemediğiniz dosyaların üzerine yazmak gibi ihtimallerin gerçekleşmesi çok olasıdır. -Tüm bu sorunlardan ötürü, uzun zaman önce geliştiriciler, yapılan tüm değişiklikleri gözden geçirilebilir parçalar halinde basit veritabanı üzerinde tutan yerel versiyon kontrol sistemlerini geliştirdiler. +Tüm bu sorunlardan ötürü, uzun zaman önce geliştiriciler, yapılan tüm değişiklikleri gözden geçirilebilir parçalar halinde basit veritabanı üzerinde tutan yerel sürüm denetim sistemlerini geliştirdiler. -.Yerel versiyon kontrol. -image::images/local.png[Yerel versiyon kontrol şeması] +.Yerel sürüm denetimi. +image::images/local.png[Yerel sürüm denetim şeması] En popüler VCS araçları RCS adında bir sistemdi, ki kendisi bugün bile hâlâ pek çok bilgisayarda kullanılır. RCS yama setlerini (dosyalar arasındaki farklılıklar) disk üzerinde özel bir formatta tutarak çalışır; daha sonra tüm yamaları bir araya getirerek herhangi bir zamanda herhangi bir dosyanın nasıl göründüğüne bakarak onu yeniden oluşturabilir. -==== Merkezî Versiyon Kontrol Sistemleri +==== Merkezî Sürüm Denetim Sistemleri (((version control,centralized))) İnsanların karşılaştığı bir diğer büyük problemse diğer sistemlerdeki geliştiricilerle iş birliği yapmak zorunda kalmalarıydı. -Bu problemin çözümü olarak Merkezî Versiyon Kontrol Sistemleri (CVCS: Central VCS) geliştirildi. +Bu problemin çözümü olarak Merkezî Sürüm Denetim Sistemleri (CVCS: Central VCS) geliştirildi. Bu sistemler (CVS, Subversion ve Perforce gibi) bütün sürümlendirilmiş dosyaları barındıran tek bir sunucuya ve o sunucudaki dosyaları tek merkezden sürekli denetleyen istemcilere sahipti. (((CVS)))(((Subversion)))(((Perforce))) -Uzun yıllar boyunca bu sistem, versiyon kontrol sistemleri için standart oldu. +Uzun yıllar boyunca bu sistem, sürüm denetim sistemleri için standart oldu. -.Merkezî versiyon kontrol. -image::images/centralized.png[Merkezî versiyon kontrol şeması] +.Merkezî Sürüm Denetimi. +image::images/centralized.png[Merkezî sürüm denetim şeması] Bu kurulum yerel VCS'lere kıyasla pek çok avantaj sunar. Örneğin, projedeki herkes diğer herkesin projede ne yaptığını belli bir ölçüye kadar bilebilir. @@ -46,16 +46,16 @@ Eğer o sunucu bir saatliğine çökerse, çöktüğü andan itibaren hiç kimse Eğer sunucu veritabanındaki harici disk bozulursa ve düzgün yedekleme yapılmamışsa, kullanıcıların kendi yerel makinelerinde tuttukları anlık durum dışında projenin tüm tarihini ve dosyalarını, yani her şeyi kaybedersiniz. Yerel VKS'ler de aynı sorundan muzdariptir, projenin tüm tarihini ve dosyalarını tek bir yerde tuttuğunuz sürece, her şeyi kaybetme riskiniz vardır. -==== Dağıtık Versiyon Kontrol Sistemleri +==== Dağıtık Sürüm Denetim Sistemleri (((version control,distributed))) -İşte tam da burada devreye Dağıtık Versiyon Kontrol Sistemleri (DVCS: Distributed VCS) giriyor. +İşte tam da burada devreye Dağıtık Sürüm Denetim Sistemleri (DVCS: Distributed VCS) giriyor. Bir DVCS'de (Git, Mercurial, Bazaar ya da Darcs gibi) istemciler sadece dosyaların son anlık görünümünü denetlemezler, daha çok repoyu reponun tam tarihiyle birlikte yansıtırlar. Dolayısıyla eğer herhangi bir sunucu devre dışı kalırsa, birbiriyle o sunucu aracılığıyla iş birliği yapan sistemlerdeki herhangi bir istemci reposu sunucuyu yenilemek için geri yüklenebilir. Her klon, en nihayetinde tüm verilerin tam bir yedeğidir aslında. -.Dağıtık versiyon kontrol. -image::images/distributed.png[Dağıtık versiyon kontrol şeması] +.Dağıtık sürüm denetimi. +image::images/distributed.png[Dağıtık sürüm denetim şeması] Ayrıca bu sistemlerin çoğu birden çok uzak repoyla çalışmayı rahatlıkla kaldırabilir, o yüzden farklı gruplardan insanlarla farklı yollarla eş zamanlı bir şekilde rahatlıkla iş birliği yapabilirsiniz. Bu da size hiyerarşik model gibi merkezi sistemlerde yapması mümkün olmayan birden çok iş akışı şekli tanımlama ve kullanma olanağı sağlar. From 2b567bf272929c26c93d250b1ecf53462cf187b5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 11:56:38 +0100 Subject: [PATCH 106/210] Update help.asc --- book/01-introduction/sections/help.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 435d2006..d351dc40 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -16,12 +16,12 @@ $ man git- ---- $ git help config ---- -Bu komutların en güzel yanı, onlara her yerden, her koşulda erişebiliyor olmanız, çevrimdışı olsanız bile. +Bu komutların en güzel yanı, çevrimdışı olsanız bile onlara her yerden ve her koşulda erişebiliyor olmanız. Eğer kullanım kılavuzu ve bu kitap sizin için yeterli değilse ve birebir yardıma ihtiyacınız varsa, https://freenode.net[] adresinde bulunan Freenode IRC sunucusundaki `#git` ya da `#github` kanallarından bizzat yardım alabilirsiniz. -Bu kanallar çoğunlukla Git hakkında epey bilgili olan ve yardım etmeye açık olan yüzlerce insanla doludur.(((IRC))) +Bu kanallar çoğunlukla Git hakkında epey bilgili ve size yardıma açık olan yüzlerce insanla doludur.(((IRC))) -Ek olarak eğer kullanım kılavuzunun tamamına ihtiyaç duymuyor, onun yerine sadece Git komutu olarak kullanılabilen komutlara erişmek istiyorsanız, daha kısa ve öz olan ``help'' çıktısını `-h` ya da `--help` opsiyonlarıyla çalıştırabilirsiniz. +Ek olarak eğer kullanım kılavuzunun tamamına ihtiyaç duymuyor, onun yerine sadece Git komutu olarak kullanılabilen komutlara erişmek istiyorsanız, daha kısa ve öz olan ``help`` çıktısını `-h` ya da `--help` seçenekleriyle çalıştırabilirsiniz. [source,console] ---- From 1c0fc6c901a1c3e6936a22a4e4ac391160499310 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 12:03:53 +0100 Subject: [PATCH 107/210] Update history.asc --- book/01-introduction/sections/history.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index 6a2a5771..cacdba9e 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,23 +1,23 @@ === Git'in Kısa Tarihçesi -Hayattaki harika olan diğer pek çok şey gibi, Git de biraz yaratıcı yıkım ve ateşli tartışmaların sonucunda ortaya çıktı. +Hayattaki harika olan diğer pek çok şey gibi, Git de yaratıcı yıkım ve ateşli tartışmaların sonucunda ortaya çıktı. Linux kerneli oldukça geniş bir kapsama sahip bir açık kaynaklı yazılım projesidir.(((Linux))) -Linux kernelinin bakım süresinin büyük bir kısmında (1991-2002) yazılıma yapılan değişiklikler yamalar ve arşivlenmiş dosyalarla aktarıldı. -2002 yılında Linux kernel projesi tescilli bir dağıtık versiyon kontrol sistemi(DVKS) olan Bitkeeper'i kullanmaya başladı. +Linux çekirdeğinin bakım süresinin büyük bir kısmında (1991-2002) yapılan değişiklikler, yamalar ve arşivlenmiş dosyalarla aktarıldı. +2002 yılında Linux kernel projesi tescilli bir dağıtık sürüm denetim sistemi olan Bitkeeper'i kullanmaya başladı. -2005 yılında Linux kernelini geliştiren toplulukla Bitkeeper'i geliştirmiş olan ticari şirket arasındaki ilişkiler koptu ve Bitkeeper'in dağıtık versiyon kontrol sisteminin ücretsiz olma durumu şirket tarafından kaldırıldı. +2005 yılında Linux çekirdeğini geliştiren toplulukla Bitkeeper'i geliştirmiş olan ticari şirket arasındaki ilişkiler koptu ve o zamana kadar ücretsiz olan Bitkeeper'in dağıtık sürüm denetim sistemi artık ücretli hale geldi. -Bu da Linux'u geliştiren topluluğun (özellikle Linux'un yaratıcısı olan Linus Torvalds'ın) Bitkeeper'i kullanırken edindiği deneyimler üzerinden kendi dağıtık versiyon kontrol sistemini geliştirmek istemesine sebep oldu.(((Linus Torvalds))) +Bu da Linux'u geliştiren topluluğun (özellikle Linux'un yaratıcısı olan Linus Torvalds'ın) Bitkeeper'i kullanırken edindiği deneyimler üzerinden kendi dağıtık sürüm denetim sistemini geliştirmek istemesine sebep oldu.(((Linus Torvalds))) Geliştirilecek olan yeni sistemin bazı hedefleri şunlardı: * Hız * Minimal tasarım -* Lineer olmayan geliştirme için güçlü destek (binlerce paralel dal desteği) +* Doğrusal olmayan geliştirme için güçlü destek (binlerce paralel dal desteği) * Tamamen dağıtık olması -* Devasa projeleri Linux kerneli verimliliğinde destekleyebilmesi (hız ve veri büyüklüğü açısından) +* Devasa projeleri (hız ve veri büyüklüğü açısından) Linux çekirdeği verimliliğinde destekleyebilmesi 2005 yılında ortaya çıkışından beri Git, kullanımı kolay olacak şekilde hem evrilip hem de olgunlaşmasına rağmen, ilk baştaki hedeflerini ve özelliklerini koruyabildi. -Müthiş derecede hızlı, devasa projelerde bile inanılmaz verimli ve lineer olmayan geliştirme için harika bir dallanma sistemine sahip. +Müthiş derecede hızlı, devasa projelerde bile inanılmaz ölçüde verimli ve doğrusal olmayan geliştirme için harika bir dallanma sistemine sahip. (Daha fazlası için: <>) From 3d7812d134f6977c89474498942949fa2602c1af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 12:34:32 +0100 Subject: [PATCH 108/210] Update installing.asc --- book/01-introduction/sections/installing.asc | 34 ++++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 6d185c38..689999cc 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -2,13 +2,13 @@ Git'i kullanmaya başlamadan önce onu bilgisayarınıza kurmuş olmanız gerekmektedir. 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. +İsterseniz paket olarak, isterseniz başka bir kurucuyla ya da kaynak kodunu indirip kendiniz derleyerek Git'i yükleyebilirsiniz. -[NOTE] +[NOT] ==== -Bu kitap Git'in *2.8.0* versiyonu baz alınarak yazılmıştır. -Kullanacağımız çoğu kod Git'in en eski versiyonlarında 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. -Git geriye dönük uyumluluğu harika bir şekilde koruduğu için 2.0'dan sonraki herhangi bir versiyon sorun çıkarmadan çalışacaktır. +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. +Git geriye dönük uyumluluğu harika bir şekilde koruduğu için 2.0'dan sonraki herhangi bir sürüm sorun çıkarmadan çalışacaktır. ==== ==== Linux'a Yüklemek @@ -36,7 +36,7 @@ Daha fazla seçenek istiyorsanız aşağıdaki Git websitesinde birbirinden fark (((macOS, installing))) Git'i Mac'a yüklemenin birkaç yolu vardır. En kolay yolu muhtemelen Xcode Komut Satırı Araçlarını yüklemektir.(((Xcode))) -Mavericks'in (10.9) veya üst sürümünde bunu basitçe Terminal'da `git` komutunu çalıştırarak yapabilirsiniz. +Mavericks'in (10.9) veya üst sürümünde bunu Terminal'de `git` komutunu çalıştırarak kolaylıkla yapabilirsiniz. [source,console] ---- @@ -45,28 +45,28 @@ $ git --version Eğer halihazırda Git'i kurmamışsanız, kurmanızı söyleyecektir. -Eğer daha güncel bir sürüm isterseniz ikili kurucu aracılığıyla yükleyebilirsiniz. +Eğer daha güncel bir sürüm isterseniz, ikili kurucu aracılığıyla yükleyebilirsiniz. macOS için Git kurucusu Git'in kendi sitesinde yüklemek için halihazırda bulunmaktadır: https://git-scm.com/download/mac[] .Git macOS Yükleyicisi. image::images/git-osx-installer.png[Git macOS yükleyicisi.] Ayrıca macOS'a yüklerken GitHub'un bir parçası olacak şekilde de yükleyebilirsiniz. -GKA'daki (Grafiksel Kullanıcı Arayüzü) Git aracının komut satırı araçlarını yükleme seçeneği de vardır. +GUI'deki (Görsel Kullanıcı Arayüzü) Git aracının komut satırı araçlarını yükleme seçeneği de vardır. macOS için olan GitHub aracını şu siteden indirebilirsiniz: https://desktop.github.com[] ==== Windows'a Yüklemek Git'i Windows'a yüklemenin de birkaç yolu vardır.(((Windows, installing))) En resmi sürümü Git'in kendi sitesinde bulunmaktadır. -Şu bağlantıya gidin ve indirme otomatikman başlayacaktır: https://git-scm.com/download/win[] -Ama bunun tam olarak Git olmadığını, indirdiğiniz şeyin Windows için Git adlı bir proje olduğunu ve kendisinin Git'den farklı olduğunuzu unutmayın. Daha fazla bilgi için: https://gitforwindows.org[] +Şu bağlantıya tıklarsanız indirme otomatik olarak başlayacaktır: https://git-scm.com/download/win[] +Ama bunun tam olarak Git olmadığını, indirdiğiniz şeyin Windows için Git adlı bir proje olduğunu ve bunun da Git'den farklı olduğunu unutmayın. Daha fazla bilgi için: https://gitforwindows.org[] Otomatik bir kurulum için şu bağlantıyı kullanabilirsiniz: https://chocolatey.org/packages/git[Git Chocolatey package] Chocolatey paketinin topluluk tarafından geliştirildiğini ve denetlendiğini unutmayın. Git'i yüklemenin bir diğer kolay yolu da GitHub Desktop aracılığıyla yüklemektir. -Bahsi geçen kurucu, GKA'nın yanında Git'in komut satırı versiyonunu da içerir. +Bahsi geçen kurucu, GUI'nin yanında Git'in komut satırı sürümünü de içerir. Ayrıca PowerShell ile de epey iyi çalışır ve sağlam kullanıcı bilgilerini ve CRLF ayarlarını hazırlar.(((PowerShell)))(((CRLF)))(((credential caching))) Bunlar hakkında ileride daha çok şey öğreneceğiz ama bunların ihtiyaç duyduğunuz şeyler olduğunu belirtmekte fayda var. Şu bağlantıdan indirebilirsiniz: https://desktop.github.com[GitHub Desktop sitesi] @@ -74,10 +74,10 @@ Bunlar hakkında ileride daha çok şey öğreneceğiz ama bunların ihtiyaç du ==== Kaynaktan Yüklemek Bazı insanlar Git'i, en güncel sürümü edinebildiğiniz için, bizzat kaynağından yüklemenin daha faydalı olduğunu düşünebilir. -İkili yükleyiciler biraz geriden gelmeye meyillidir ama Git yıllar içinde olgunlaştıkça fark git gide azaldı. +İkili yükleyiciler biraz geriden gelmeye meyillidir ama Git yıllar içinde olgunlaştıkça aradaki fark git gide azaldı. -Eğer Git'i kaynaktan yüklemek istiyorsanız Git'in bel bağladığı şu kütüphanelere sahip olmalısınız: autotools, curl, zlib, openssl, expat ve libiconv. -Örneğin eğer `dnf` (Fedora gibi) kullanılan bir sistem kullanıyorsanız ya da `apt-get` (Debian-bazlı sistem gibi), derleme yapmak için gereken en temel bağımlılıkları ve Git çalıştırılabilirini yüklemek için şu aşağıdaki komutlardan birini kullanabilirsiniz: +Eğer Git'i kaynağından yüklemek istiyorsanız Git'in bağımlı olduğu şu kütüphanelere sahip olmalısınız: autotools, curl, zlib, openssl, expat ve libiconv. +Örneğin, eğer Fedora gibi `dnf` kullanılan ya da `apt-get` gibi Debian-bazlı bir sistem kullanıyorsanız; Git ikililerini kurmak ve derleme yapmak için gereken temel bağımlılıkları yüklemek için aşağıdaki komutlardan birini kullanabilirsiniz: [source,console] ---- @@ -118,10 +118,10 @@ $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi ---- Tüm gerekli bağımlılıkları kurduktan sonra, tarball'ın yayınlanmış son sürümünü farklı yerlerden edinebilirsiniz. -kernel.org sitesinden edinebilirsiniz https://www.kernel.org/pub/software/scm/git[], ya da GitHub'un websitesinden https://github.com/git/git/releases[]. -Genel olarak son sürümün ne olduğu GitHub'un kendi sayfasında daha nettir ama kernel.org sayfası da ayrıca indirdiğiniz sürümü doğrulamak için gerekli olan yayınlama imzalarına sahiptir. +Bunu kernel.org sitesinden (https://www.kernel.org/pub/software/scm/git[]) ya da GitHub'un websitesinden (https://github.com/git/git/releases[]) edinebilirsiniz. +Genel olarak son sürümün ne olduğu GitHub'ın kendi sayfasında daha nettir ama kernel.org sayfası da indirdiğiniz sürümü doğrulamak için gerekli olan yayınlama imzalarına sahiptir. -Sonunda derleyip yükleyebilirsiniz: +Ardından, derleyip yükleyin: [source,console] ---- From ca615772d0fa6fe5cd89ac2193b5d83bad31a703 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 13:03:08 +0100 Subject: [PATCH 109/210] Update what-is-git.asc --- book/01-introduction/sections/what-is-git.asc | 85 +++++++++---------- 1 file changed, 42 insertions(+), 43 deletions(-) diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 6ece57e8..43dfe9bf 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -2,54 +2,54 @@ Özetle Git nedir? Bu, özümsemesi gerekli ve önemli olan bir bölümdür. Çünkü eğer Git'in ne olduğunu, temellerini ve nasıl çalıştığını iyi anlarsanız, Git'i etkili bir şekilde kullanmak da muhtemelen sizin için çok daha kolay olacaktır. -Git'i öğrenirken, mümkün olduğunca diğer Versiyon Kontrol Sistemleri'nden (CVS, Subversion veya Perforce gibi) bildiklerinizi aklınızdan çıkarmaya gayret edin ki Git'i daha berrak ve doğru şekilde öğrenip kullanabilesiniz. -Git'in kullanıcı arayüzü diğer Versiyon Kontrol Sistemleri'ne epey benzese de Git bilgileri diğerlerinden çok daha farklı bir şekilde depolar ve bu bilgiler hakkında daha farklı düşünür. Bu yüzden bunun gibi farklılıkları anlamak Git'i kullanırken kafanızın karışmasını engeller.((Subversion))((Perforce)) +Git'i öğrenirken, mümkün olduğunca diğer Sürüm Denetim Sistemleri'nden (CVS, Subversion veya Perforce gibi) bildiklerinizi aklınızdan çıkarmaya gayret edin ki Git'i daha berrak ve doğru şekilde öğrenip kullanabilesiniz. +Git'in kullanıcı arayüzü diğer Sürüm Denetim Sistemleri'ne epey benzese de Git, bilgileri diğerlerinden çok daha farklı bir şekilde depolar ve bu bilgiler hakkında daha farklı düşünür. Bu yüzden bunun gibi farklılıkları anlamak Git'i kullanırken kafanızın karışmasını engeller.((Subversion))((Perforce)) ==== Farklılıklar Değil, Anlık Görünümler -Git'in diğer herhangi bir VKS'den (Subversion ve benzerleri dahil olmak üzere) en büyük farkı, Git'in veriler hakkında düşünme şeklidir. +Git'in diğer herhangi bir VCS'den (Subversion ve benzerleri dahil olmak üzere) en büyük farkı, Git'in veriler hakkında düşünme şeklidir. Diğer çoğu sistem bilgileri dosya-bazlı değişim listesi şeklinde saklar. -Bu diğer sistemler (CVS, Subversion, Perforce, Bazaar vd.) bilgileri dosya setleri ve o dosyalara zaman içinde yapılan değişiklikler şeklinde saklar (Bu genellikle _delta-bazlı_ versiyon kontrol şeklinde tanımlanır). +Bu diğer sistemler (CVS, Subversion, Perforce, Bazaar vd.) bilgileri dosya setleri ve o dosyalara zaman içinde yapılan değişiklikler şeklinde saklar (Bu genellikle _delta-bazlı_ sürüm denetimi şeklinde tanımlanır). -.Verileri her dosyanın baz versiyonunu referans alarak, yapılan değişiklikler şeklinde saklamak. -image::images/deltas.png[Verileri her dosyanın baz versiyonunu referans alarak, yapılan değişiklikler şeklinde saklamak.] +.Verileri her dosyanın baz halini referans alarak, yapılan değişiklikler şeklinde saklamak. +image::images/deltas.png[Verileri her dosyanın baz halni referans alarak, yapılan değişiklikler şeklinde saklamak.] -Git, verileri hakkında bu şekilde düşünmez ve onları bu şekilde saklamaz. -Bunun yerine Git, verilerini daha çok minyatür dosya sistemlerinin anlık görünümler serisi şeklinde düşünür ve o şekilde saklar. -Git'le her commit yaptığınızda ya da projenizin durumunu kaydettiğinizde, Git kısaca tüm dosyalarınızın o an nasıl göründüğünün fotoğrafını çeker ve o anlık görünümün referansını saklar. +Git, veriler hakkında bu şekilde düşünmez ve onları bu şekilde saklamaz. +Bunun yerine Git, verilerini daha çok minyatür dosya sistemlerinin anlık görüntüler serisi şeklinde düşünür ve o şekilde saklar. +Git'le her katkı (katkı) işlediğinizde ya da projenizin durumunu kaydettiğinizde, Git kısaca tüm dosyalarınızın o an nasıl göründüğünün fotoğrafını çeker ve o anlık görünümün referansını saklar. Verimli olmak adına, eğer dosyalar değişmemişse Git o dosyaları tekrar saklamaz, onun yerine o dosyaların halihazırda saklandığı referansa bağlantı verir. -Yani Git, verilerini daha çok *anlık görünüm akışı* olarak görür. +Yani Git, verilerini daha çok *anlık görüntü akışı* (poz) olarak görür. -.Veriyi projenin anlık görünümleri olarak saklamak. -image::images/snapshots.png[Git zaman geçtikçe veriyi projenin anlık görünümleri olarak saklar.] +.Veriyi projenin pozları olarak saklamak. +image::images/snapshots.png[Git zaman geçtikçe veriyi projenin pozları olarak saklar.] -Bu Git ve neredeyse diğer tüm VKS'lerinin arasındaki en büyük ayrımdır. -Bu da Git'i, diğer sistemlerin kendilerinden önceki jenerasyondan kopyaladıkları versiyon kontrolünün her yönünü yeniden değerlendirmesini sağlar. -Böylelikle Git, basit bir VKS'dense, inanılmaz güçlü araçlarla donatılmış minyatür bir dosya sistemi olmuştur. +Bu Git ve neredeyse diğer tüm VCS'leri arasındaki en büyük ayrımdır. +Bu da Git'i, diğer sistemlerin kendilerinden önceki nesilden kopyaladıkları sürüm denetimi mirasını her yönünü yeniden değerlendirmesini sağlar. +Böylelikle Git, basit bir VCS'dense, inanılmaz güçlü araçlarla donatılmış minyatür bir dosya sistemi olmuştur. Git'deki dallanmayı anlatırken verileriniz hakkında bu şekilde düşünmenin getirilerini keşfedeceğiz. <> ==== Neredeyse Her İşlem Yereldir Git'deki çoğu işlem çalışmak için yalnızca yerel dosyalara ve kaynaklara ihtiyaç duyar. Genel olarak başka bir bilgisayardan sizin ağınıza bilgi gelmesine ihtiyacınız yoktur. -Eğer çoğu işlemin ağ gecikme yüküne sahip olduğu bir MVKS'ye (Merkezî Versiyon Kontrol Sistemi) alışkınsanız, Git'in bu yönü size, Hız Tanrıları'nın Git'i, ilahi ve tanrısal güçlerle kutsadığını düşündürecektir. +Eğer çoğu işlemin ağ gecikme yüküne sahip olduğu bir CVCS'ye (Merkezî Versiyon Kontrol Sistemi) alışkınsanız; Git'in bu yönü size, Git'in Allah tarafından ilahi bir hız yeteneğiyle kutsadığını düşündürtecektir. Çünkü projenizin tüm tarihçesi tam olarak yerel diskinizdedir, ve çoğu işlem de neredeyse anında gerçekleşir. Örneğin, projenin tarihçesine göz atmak için Git'in sunucuya girip, tarihçeye erişip size göstermesine gerek yoktur, onun yerine hızlıca sizin yerel veritabanınızdan okur. Bu da proje tarihçesini neredeyse anında görebildiğiniz anlamına gelir. Eğer bir dosyanın mevcut sürümü ve bir ay önceki sürümü arasındaki değişiklikleri görmek isterseniz, Git, uzaktaki bir sunucuya bu işlemi yapması için başvurmak ya da dosyanın eski versiyonunu uzaktaki sunucudan çekip yerel diskte hesaplamak yerine, dosyanın bir ay önceki haline hızlıca göz atıp yerel bir farklılık hesaplaması yapar. -Bu da çevrim dışı ya da VPN'sizseniz bile yapamayacağınız sadece çok az şey olduğunu belirtir. -Eğer uçakla ya da trenle seyahet ediyorken biraz çalışmak isterseniz, yerel ortamınızda çalışıp commitleyebilir (_yerel_ kopyanıza) ve internet bağlantısı edindiğinizde de onu internete yükleyebilirsiniz. +Bu da çevrim dışı ya da VPN'sizseniz bile yapamayacağınız çok az şey olduğu anlamına geliyor. +Eğer uçak ya da trenle seyahat ederken biraz çalışmak isterseniz, yerel ortamınızda çalışıp commitleyebilir (_yerel_ kopyanıza) ve internet bağlantısı edindiğinizde de onu internete yükleyebilirsiniz. Eğer eve giderseniz ve VPN istemciniz düzgün bir şekilde çalışmazsa bile hâlâ yerel ortamınızda çalışabilirsiniz. Diğer çoğu sistemde ise bunları yapmak ya imkânsız ya da çok sancılıdır. -Örneğin Perforce'de, eğer sunucuya bağlı değilseniz pek bir şey yapamazsınız. Subversion ve CVS'de ise dosyaları düzenleyebilir ama sunucuya commitleyemezsiniz (Çünkü sunucunuz çevrim dışı). +Örneğin Perforce'de, eğer sunucuya bağlı değilseniz pek bir şey yapamazsınız. Subversion ve CVS'de ise dosyaları düzenleyebilir ama sunucuya commitleyemezsiniz (Çünkü sunucunuz çevrim dışıdır). Bu size şu an çok da önemli bir özellikmiş gibi gelmeyebilir ama Git'i öğrendikçe ve kullandıkça bunun ne kadar büyük bir fayda sağladığını bizzat göreceksiniz. ==== Git'in Entegrasyonu Vardır -Git'deki her şey saklanmadan önce sağlaması yapılır ve ondan sonra da o sağlamayla referans gösterilir. +Git'deki her şeyin saklanmadan önce sağlaması yapılır ve ondan sonra da o sağlamayla referans gösterilir. Bu da dosyaların ya da klasörlerin içeriğini Git'in haberi olmadan değiştirmenin imkânsız olduğu anlamına gelir. -Bu işlev Git'in temelinde gömülü halde gelir ve Git'in felsefesinin ayrılmaz bir parçasıdır. +Bu işlev Git'in temelinde gömülü halde gelir ve Git felsefesinin ayrılmaz bir parçasıdır. Aktarım yaparken bilgi kaybetmezsiniz. Aynı şekilde Git farkına varmadan bir dosya da bozulmaz. Git'in sağlama yapmak için kullandığı bu mekanizmanın adı SHA-1 özetidir.(((SHA-1))) @@ -68,9 +68,9 @@ Hatta Git, sunucusundaki her şeyi dosya isimleriyle değil, içeriklerinin öze Git'de bir şeyler yaptığınızda neredeyse hepsi sadece Git'in veritabanına veri _ekler_. Sistemin geri alınamayan bir şey yapmasını veya verileri herhangi bir şekilde silmesini sağlamak zordur. -Tüm VCS'lerde olduğu gibi, henüz commitlemediğiniz değişiklikleri kaybedebilir veya karman çorman yapabilirsiniz, ancak Git'e bir anlık görünüm verdikten sonra, özellikle veritabanınızı düzenli olarak başka bir repository'e yollarsanız, kaybetmek çok zordur. +Tüm VCS'lerde olduğu gibi, henüz işlemediğiniz değişiklikleri kaybedebilir veya karman çorman yapabilirsiniz, ancak Git'e bir anlık görünüm verdikten sonra (özellikle veritabanınızı düzenli olarak başka bir repoya yollarsanız) kaybetmek çok zordur. -Bu da Git'i kullanmayı keyifli kılar çünkü ortalığı batırma tehlikesi olmadan istediğimiz gibi denemeler yapabileceğimizi biliriz. +Bu da Git'i kullanmayı keyifli kılar, çünkü ortalığı batırma tehlikesi olmadan istediğimiz gibi denemeler yapabileceğimizi biliriz. Git'in verilerini nasıl sakladığını ve kaybolmuş gibi görünen dosyaları nasıl geri alabileceğinizi daha detaylı bir şekilde öğrenmek için: <> ==== Üç Durum @@ -78,32 +78,31 @@ Git'in verilerini nasıl sakladığını ve kaybolmuş gibi görünen dosyaları Eğer Git'i öğrenme sürecinizin sorunsuz olmasını istiyorsanız, şimdi dikkatinizi verin. Git hakkında akılda tutulacak ana şey şudur, Git'in dosyalarınızın içinde bulunabileceği üç ana durum vardır: _modified_, _staged_, and _committed_: -* Modified, dosyayı değiştirdiğinizi ama henüz veritabanına commitlemediğinizi gösterir. -* Staged, değiştirilmiş bir dosyayı bir sonraki commit anlık görünümünde işlenecek şekilde işaretlediğinizi gösterir. -* Committed, dosyanın güvenli bir şekilde yerel veritabanınızda saklandığını gösterir. +* Modified: dosyayı değiştirdiğinizi ama henüz veritabanına katkılamadığınızı (commit) gösterir. +* Staged: değiştirilmiş bir dosyayı bir sonraki katkı pozunda (snapshot) işlenecek şekilde işaretlediğinizi gösterir. +* Committed: dosyanın güvenli bir şekilde yerel veritabanınızda saklandığını gösterir. -Bu da bizi bir Git projesinin üç ana bölümüne getirir: the working tree, the staging area, ve Git klasörü. +Bu da bizi bir Git projesinin üç ana bölümüne getirir: the working tree (çalışma ağacı), the staging area (izleme alanı), ve Git klasörü. -.Working tree, staging area, ve Git klasörü. -image::images/areas.png["Working tree, staging area ve Git klasörü"] +.çalışma ağacı, izleme alanı ve Git klasörü. +image::images/areas.png["çalışma ağacı, izleme alanı ve Git klasörü"] -Working tree, checkout komutunun projenin bir versiyonunda çalıştırılmasıdır. -Bu dosyalar Git directory'deki sıkıştırılmış veritabanından çıkarılır ve sizin modifiye edebilmeniz veya kullanabilmeniz için diskinize yerleştirilir. +Çalışma ağacı (working tree), checkout komutunun projenin bir sürümünde çalıştırılmasıdır. +Bu dosyalar Git dizinindeki sıkıştırılmış veritabanından çıkarılır ve sizin modifiye edebilmeniz veya kullanabilmeniz için diskinize yerleştirilir. -The staging area bir dosyadır, genel olarak Git klasörünüzün içindedir ve bir sonraki commite hangi bilgilerin gideceğini depolar. -Git jargonundaki teknik adı ``index``dir, ama ``staging area`` ifadesi de iş görür. +İzleme alanı (staging area) bir dosyadır, genel olarak Git klasörünüzün içindedir ve bir sonraki katkıya hangi bilgilerin işleneceğini depolar. +Git terminolojisindeki teknik adı ``index``dir, ama ``izleme alanı`` ifadesi de iş görür. - -Git klasörü ise Git'in projenize ait tüm üstverileri ve obje veritabanını sakladığı yerdir. -Bu Git'in en önemli bölümüdür, aynı zamanda da başka bir repository'den _klonu_ kopyaladığınızda kopyalanan şeyin ta kendisidir. +Git klasörü ise Git'in projenize ait tüm üstverileri ve nesne veritabanını sakladığı yerdir. +Bu Git'in en önemli bölümüdür; aynı zamanda da başka bir repodan _klon_ kopyaladığınızda kopyalanan şeyin de ta kendisidir. Git'in iş akışı basitçe şöyledir: -1. Working tree'de dosyaları düzenlersiniz. -2. Bir sonraki committe işlenecek olan değişiklikleri seçersiniz. -3. Bir commit yaparsınız, staging area'daki dosyaların anlık görünümünü çeker ve Git klasörünüzde kalıcı olarak saklarsınız. +1. Çalışma ağacında dosyaları düzenlersiniz. +2. ``git add ...`` komutuyla bir sonraki katkıya işlenecek olan değişiklikleri seçersiniz. +3. ``git commit ...`` komutuyla bir katkı işlersiniz, izleme alanındaki (stage) dosyaların pozlaını (snapshot) çeker ve Git klasörünüzde kalıcı olarak saklarsınız. -Eğer bir dosyanın belli bir versiyonu Git klasöründeyse, o dosya _commitlenmiş_ sayılır. -Eğer düzenlenmiş ve staging area'ya eklenmişse, _stage edilmiştir_. -Eğer son denetlenmesinden sonra değiştirilmişse ama işlenmemişse, o halde _modifiye_ edilmiştir. -Şu kısımda bu durumlar hakkında daha fazla şey öğrenecek ve bu durumların avantajını kullanmayı ya da stage kısmını tamamen es geçmeyi öğreneceksiniz: <> +Eğer bir dosyanın belli bir sürümü Git klasöründeyse, o dosya _katkılanmış_ sayılır (commited). +Eğer düzenlenmiş ve izleme alanına eklenmişse, _izlem_'e alınmıştır (staged). +Eğer son denetlenmesinden sonra değiştirilmişse ama işlenmemişse, o halde _değiştirilmiş_ durumdadır (modified). +<> bölümünde bu durumlar hakkında daha fazla şey öğrenecek ve bu durumların avantajını kullanmayı ya da izlem (stage) kısmını tamamen es geçmeyi öğreneceksiniz: From cf904f7ea69432a86dd75a9f4158b4926ee47c1f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 13:04:01 +0100 Subject: [PATCH 110/210] Update history.asc --- book/01-introduction/sections/history.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index 6a2a5771..cacdba9e 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,23 +1,23 @@ === Git'in Kısa Tarihçesi -Hayattaki harika olan diğer pek çok şey gibi, Git de biraz yaratıcı yıkım ve ateşli tartışmaların sonucunda ortaya çıktı. +Hayattaki harika olan diğer pek çok şey gibi, Git de yaratıcı yıkım ve ateşli tartışmaların sonucunda ortaya çıktı. Linux kerneli oldukça geniş bir kapsama sahip bir açık kaynaklı yazılım projesidir.(((Linux))) -Linux kernelinin bakım süresinin büyük bir kısmında (1991-2002) yazılıma yapılan değişiklikler yamalar ve arşivlenmiş dosyalarla aktarıldı. -2002 yılında Linux kernel projesi tescilli bir dağıtık versiyon kontrol sistemi(DVKS) olan Bitkeeper'i kullanmaya başladı. +Linux çekirdeğinin bakım süresinin büyük bir kısmında (1991-2002) yapılan değişiklikler, yamalar ve arşivlenmiş dosyalarla aktarıldı. +2002 yılında Linux kernel projesi tescilli bir dağıtık sürüm denetim sistemi olan Bitkeeper'i kullanmaya başladı. -2005 yılında Linux kernelini geliştiren toplulukla Bitkeeper'i geliştirmiş olan ticari şirket arasındaki ilişkiler koptu ve Bitkeeper'in dağıtık versiyon kontrol sisteminin ücretsiz olma durumu şirket tarafından kaldırıldı. +2005 yılında Linux çekirdeğini geliştiren toplulukla Bitkeeper'i geliştirmiş olan ticari şirket arasındaki ilişkiler koptu ve o zamana kadar ücretsiz olan Bitkeeper'in dağıtık sürüm denetim sistemi artık ücretli hale geldi. -Bu da Linux'u geliştiren topluluğun (özellikle Linux'un yaratıcısı olan Linus Torvalds'ın) Bitkeeper'i kullanırken edindiği deneyimler üzerinden kendi dağıtık versiyon kontrol sistemini geliştirmek istemesine sebep oldu.(((Linus Torvalds))) +Bu da Linux'u geliştiren topluluğun (özellikle Linux'un yaratıcısı olan Linus Torvalds'ın) Bitkeeper'i kullanırken edindiği deneyimler üzerinden kendi dağıtık sürüm denetim sistemini geliştirmek istemesine sebep oldu.(((Linus Torvalds))) Geliştirilecek olan yeni sistemin bazı hedefleri şunlardı: * Hız * Minimal tasarım -* Lineer olmayan geliştirme için güçlü destek (binlerce paralel dal desteği) +* Doğrusal olmayan geliştirme için güçlü destek (binlerce paralel dal desteği) * Tamamen dağıtık olması -* Devasa projeleri Linux kerneli verimliliğinde destekleyebilmesi (hız ve veri büyüklüğü açısından) +* Devasa projeleri (hız ve veri büyüklüğü açısından) Linux çekirdeği verimliliğinde destekleyebilmesi 2005 yılında ortaya çıkışından beri Git, kullanımı kolay olacak şekilde hem evrilip hem de olgunlaşmasına rağmen, ilk baştaki hedeflerini ve özelliklerini koruyabildi. -Müthiş derecede hızlı, devasa projelerde bile inanılmaz verimli ve lineer olmayan geliştirme için harika bir dallanma sistemine sahip. +Müthiş derecede hızlı, devasa projelerde bile inanılmaz ölçüde verimli ve doğrusal olmayan geliştirme için harika bir dallanma sistemine sahip. (Daha fazlası için: <>) From 5a7f7af8961274a4c97a821ffa26915e38f2ea20 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 16:59:49 +0100 Subject: [PATCH 111/210] Update aliases.asc --- book/02-git-basics/sections/aliases.asc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index d6946dbe..13e1b91d 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -6,8 +6,8 @@ Temel Git ile ilgili bu bölümü bitirmeden önce Git deneyiminizi daha basit, Bu kitapta kısayol konusuna detaylıca girmeyeceğiz veya ilerleyen bölümlerde bunları kullandığınızı varsaymayacağız, ancak yine de nasıl kullanacağınızı bilmenizde fayda var. Eğer komutunuzun tamamını yazmazsanız, Git bir kısaltma yaptığınızı otomatik olarak anlayamaz. -Git komutlarının tamamını uzun uzun yazmak istemiyorsanız, `git config` komutunu kullanarak, her komut için kolayca bir kısayol ayarlayabilirsiniz.(((git commands, config))) -Aşağıda kısayol olarak isteyebileceğiniz birkaç örnek verilmiştir: +Git komutlarının tamamını uzun uzun yazmak istemiyorsanız, `git config` komutunu kullanarak, dilediğiniz komut için kolaylıkla bir kısayol ayarlayabilirsiniz.(((git commands, config))) +Aşağıda kısayol olarak atamak isteyebileceğiniz birkaç örnek verilmiştir: [source,console] ---- @@ -17,11 +17,11 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -İlk örnekte `git commit` yerine "git ci" komutunu ayarlıyorsunuz. Artık `git ci` yazarsanız Git bunu `git commit` olarak düşünecektir. -Git'i kullanmaya devam ettikçe muhtemelen diğer komutları da sıklıkla kullanacaksınız; yeni kısayollar oluşturmaktan çekinmeyin. +İlk örnekte `git commit` yerine `git ci` komutunu ayarlıyorsunuz. Artık `git ci` yazarsanız Git bunu `git commit` olarak düşünecektir. +Git'i kullanmaya devam ettikçe muhtemelen diğer komutları da sıklıkla kullanacaksınız. Yeni kısayollar oluşturmaktan çekinmeyin. Bu tekniği aynı zamanda Git'te mevcut olmayan, ama olması gerektiğini düşündüğünüz komutların oluşturulmasında da kullanabilirsiniz. -Örneğin, bir dosyayı aşamalandırmadan (stage) kaldırırken karşılaştığınız "kullanılabilirlik" sorununu düzeltmek için Git'e kendi aşamadan kaldırma komutunuzu ekleyebilirsiniz: +Örneğin, bir dosyayı izlemden (stage) kaldırırken karşılaştığınız "kullanılabilirlik" sorununu düzeltmek için Git'e kendi izlemden kaldırma komutunuzu ekleyebilirsiniz: [source,console] ---- @@ -60,7 +60,7 @@ Date: Tue Aug 26 19:48:51 2008 +0800 ---- Gördüğünüz gibi Git, yeni komutu her neyin kısayolu olarak ayarlarsanız onunla değiştirir. -Ancak Git alt komutları yerine harici bir komut da çalıştırmak isteyebilirsiniz. +Ancak Git alt komutları yerine, harici bir komut da çalıştırmak isteyebilirsiniz. Bu durumda komuta `!` karakteriyle başlamalısınız. Eğer Git'te çalışan kendi komutlarınızı yazmak istiyorsanız bu epey kullanışlıdır. Hadi `git visual` komutunu çalıştıracak `gitk` kısayolunu atamayı gösterelim: From 93422611af78c50319274d26aee4f60f8d0e6864 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 17:05:36 +0100 Subject: [PATCH 112/210] Update getting-a-repository.asc --- book/02-git-basics/sections/getting-a-repository.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index e42eb06f..21994f0e 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,6 +1,6 @@ -Git'e başlamak için yalnızca bir bölüm okuyabilecek vaktiniz varsa, işte bu bölüm aradığınız kısım. +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. -Bölümün sonunda, bir Git reposunu yapılandırıp başlatabilmeniz, dosyaları izlemeyi başlatıp durdurabilmeniz ve değişikliklerinizi aşamalandırıp (stage) uzak repoya kaydedebilecek seviyeye geleceksiniz. +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. @@ -11,13 +11,13 @@ Tipik olarak bir Git reposu oluşturmanın 2 yolu vardır: 1. Şu anda sürüm denetimi (version control) altında olmayan bir yerel dizini (dosya yolu) alabilir ve onu bir Git reposuna dönüştürebilirsiniz. Veya -2. Başka bir yerden var olan bir Git reposunu kopyalayabilirsiniz. +2. Başka bir yerden, var olan bir Git reposunu kopyalayabilirsiniz. Her iki durumda da, yerel makinenizde çalışmaya hazır bir Git reposuna sahip olursunuz. ==== Varolan Bir Dizinde Repo Başlatma -Eğer şu anda sürüm denetimi altında olmayan bir proje diziniz var ve onu Git ile takip etmeye etmeye başlamak istiyorsanız, önce o projenin dizinine gitmeniz gerekmektedir. +Eğer şu anda sürüm denetimi altında olmayan bir proje diziniz varsa ve onu Git ile takip etmeye etmeye başlamak istiyorsanız, önce o projenin dizinine gitmeniz gerekmektedir. Eğer bunu daha önce yapmadıysanız, hangi işletim sisteminde çalıştığınıza bağlı olarak proje dizininiz farklı görünebilir. Linux için: From 2b15ba9cdebf7788f12b3b6e6d4944196d44c183 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 17:48:33 +0100 Subject: [PATCH 113/210] Update recording-changes.asc --- .../sections/recording-changes.asc | 138 +++++++++--------- 1 file changed, 69 insertions(+), 69 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 6bb82647..2aba4ee3 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -3,15 +3,15 @@ Şu aşamada, yerel makinenizde bir Git reposuna ve önünüzde tüm dosyaları kullanıma hazır veya çalışmakta olan bir kopyasına sahip olmalısınız. Doğal olarak, proje kaydetmek istediğiniz duruma her ulaştığında değişiklik yapmaya ve bu değişikliklerin pozlarını (snapshot) reponuza kaydetmeye başlamak isteyeceksiniz. -Çalışma dizininizdeki her dosyanın iki durumdan birinde olabileceğini unutmayın: "tracked" (izlenen / takip edilen) veya "untracked" (izlenmeyen / takip edilmeyen). -İzlenen dosyalar, son pozdaki (snapshot) dosyalardır: bunlar "modified" (değiştirilmiş), "unmodified" (değiştirilmemiş) veya "staged" (aşamalandırılmış) olabilirler. +Çalışma dizininizdeki her dosyanın iki durumdan birinde olabileceğini unutmayın: ``tracked`` (izlenen / takip edilen) veya ``untracked`` (izlenmeyen / takip edilmeyen). +İzlenen dosyalar, son pozdaki dosyalardır: bunlar ``modified`` (değiştirilmiş), ``unmodified`` (değiştirilmemiş) veya ``staged`` (izleme alınmış; indekslenmiş) olabilirler. Kısacası izlenen dosyalar Git'in haberdar olduğu ve değişikliklerini takip ettiği dosyalardır. -İzlenmeyen dosyalar ise diğer her şeydir (çalışma dizininizdeki, son pozda olmayan ve aşamalandırmada (staging area) olmayan dosyalardır). -Bir repoyu ilk kez kopyaladığınızda, tüm dosyalarınız izlenecek ve "unmodified" (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız. +İzlenmeyen dosyalar ise diğer her şeydir (çalışma dizininizdeki, son pozda olmayan ve izlemde olmayan dosyalardır). +Bir repoyu ilk kez kopyaladığınızda, tüm dosyalarınız izlenecek ve ``unmodified`` (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız. -Siz dosyaları düzenlerken Git onları "modified" (değiştirilmiş) olarak görür, çünkü son Git işleminizden (commit, clone, push, vs) sonra bu dosyalarda değişiklik yaptınız. -Çalışırken, bu değiştirilmiş dosyaları seçerek aşamaya alırsınız (katkılamak için hazırlarsınız) ve ardından aşamalandırılmış tüm bu değişiklikleri katkı (commit) olarak işlersiniz. +Siz dosyaları düzenlerken Git onları ``modified`` (değiştirilmiş) olarak görür, çünkü son Git işleminizden (commit, clone, vs) sonra bu dosyalarda değişiklik yaptınız. +Çalışırken, bu değiştirilmiş dosyaları seçerek izleme alırsınız (katkılamak amacıyla indekslersiniz) ve ardından izleme alınmış tüm bu değişiklikleri katkı olarak işlersiniz. Ve bu döngü her değişiklikten sonra tekrarlanır. .Dosyalarınızın durumunun yaşam döngüsü. @@ -33,9 +33,9 @@ nothing to commit, working directory clean Bu, temiz bir çalışma dizininiz olduğu anlamına gelir. Bir başka deyişle, izlenen dosyalarınızın hiçbirinde henüz bir değişiklik yoktur. -Git ayrıca izlenmeyen (untracked) dosyaları görmez, aksi halde onlar da burada listelenirdi. +Ayrıca, Git izlenmeyen dosyaları görmez; aksi halde onlar da burada listelenirdi. Son olarak bu komut size hangi projenin hangi dalında (branch) olduğunuzu söyler ve sunucuda kopyaladığınız daldan ayrılmadığınızı bildirir. -Şimdilik bu dal her zaman varsayılan olan ``master`` yani "ana dal"dır. +Şimdilik bu dal her zaman varsayılan olan ``master``, yani "ana dal"dır. Bunda endişelenmenizi gerektirecek bir durum yoktur. <> ünitesinde dalları (branch) ve işaretçileri (reference) ayrıntılı olarak göreceksiniz. @@ -56,11 +56,11 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -Yeni `README` dosyanızın izlenmediğini görebilirsiniz, çünkü durum çıktınızda (git status) `Untracked files` (İzlenmeyen dosyalar) başlığı altındadır. +Yeni `README` dosyanızın izlenmediğini görebilirsiniz, çünkü `git status` komutuyla alacağınız durum çıktısında `Untracked files` (izlenmeyen dosyalar) başlığı altındadır. "İzlenmeyen" temel olarak Git'in önceki pozda sahip olmadığınız bir dosyayı gördüğü anlamına gelir. -Siz bunu yapmasını açıkça söyleyene kadar Git bunu pozlarınıza dahil etmeyecektir. -Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "binary" dosyaların veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. -`README`yi dahil etmeye başlamak istiyorsanız, o halde dosyayı izlemeye başlayalım. +Siz bunu yapmasını açıkça söyleyene kadar, Git bunu pozlarınıza dahil etmeyecektir. +Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "ikili" (binary) dosyaların veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. +`README` 'yi katkılarınıza dahil etmek istiyorsanız, o halde dosyayı izlemeye başlayalım. [[_tracking_files]] ==== Yeni Dosyaları İzleme @@ -73,7 +73,7 @@ Yeni bir dosyayı izlemeye başlamak için `git add` komutu kullanılır.(((git $ git add README ---- -Durum komutunuzu (git status) tekrar çalıştırırsanız, `README` dosyanızın artık izlendiğini (tracked) ve kaydedilmek üzere aşamalandırıldığını (Staging) görebilirsiniz: +Durum komutunuzu (git status) tekrar çalıştırırsanız, `README` dosyanızın artık takip edildiğini (tracked) ve kaydedilmek üzere izleme alındığını görebilirsiniz: [source,console] ---- @@ -87,14 +87,14 @@ Changes to be committed: ---- -`Changes to be committed` başlığı altında yer aldığından aşamalandırıldığını anlayabilirsiniz. -Bu noktada katkı işlerseniz (commit), dosyanın `git add` çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. +`Changes to be committed` başlığı altında yer aldığından izleme alındığını anlayabilirsiniz. +Bu noktada bir katkı işlerseniz, dosyanın `git add` çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. Daha önce `git init` komutunu çalıştırdığınızda, hemen ardından `git add ` komutunu çalıştırdınız. Bunun amacı dizininizdeki dosyaları izlemeye başlamaktı.(((git commands, init)))(((git commands, add))) `git add` komutu, bir dosya veya dizin için bir yol adı alır. -Eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları aşamalandırmaya (takip listesine) ekler. +Eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları izleme ekler. -==== Değiştirilmiş Dosyaları Aşamaya Alma +==== Değiştirilmiş Dosyaları İzleme Alma Şimdi izlenmekte (tracked) olan bir dosyayı değiştirelim. Eğer izlenmnekte olan `CONTRIBUTING.md` adlı dosyayı değiştirir ve ardından `git status` komutunu tekrar çalıştırırsanız, şöyle bir sonuç elde edersiniz: @@ -118,11 +118,11 @@ Changes not staged for commit: ---- `CONTRIBUTING.md` dosyası, `Changes not staged for commit` adlı bir bölümün altında görünür. -Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği, ancak henüz aşamaya (stage) alınmadığı anlamına gelir. -Aşamaya almak için `git add` komutunu çalıştırmalısınız. -`git add` çok amaçlı bir komuttur: yeni dosyaları izlemeye başlamak, dosyaları aşamaya almak (katkı için hazırlamak) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyler için de kullanırsınız. +Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği, ancak henüz izleme alınmadığı anlamına gelir. +İzleme almak için `git add` komutunu çalıştırmalısınız. +`git add` çok amaçlı bir komuttur: yeni dosyaları takibe başlamak, dosyaları izleme almak (katkı için indekslemek) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyler için de kullanırsınız. Bunu, "bu dosyayı projeye ekle" yerine "bu içeriği bir sonraki işleme ekle" olarak düşünmek daha faydalı olabilir.(((git commands, add))) -Şimdi `CONTRIBUTING.md` dosyasını aşamaya almak için `git add` komutunu çalıştıralım ve ardından `git status` komutunu bir kez daha koşalım: +Şimdi `CONTRIBUTING.md` dosyasını izleme almak için `git add` komutunu çalıştıralım ve ardından `git status` komutunu bir kez daha koşalım: [source,console] ---- @@ -138,7 +138,7 @@ Changes to be committed: ---- -Her iki dosya da aşamadadır ve bir sonraki işleminize aktarılacaktır. +Her iki dosya da izlemdedir ve bir sonraki işleminize aktarılacaktır. Bu noktada, varsayalım ki `CONTRIBUTING.md` dosyasında yapmak istediğiniz küçük bir değişikliği hatırladınız. Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi katkı olarak işlemeye hazırsınız. Hadi `git status` komutunu bir kez daha çalıştıralım: @@ -166,9 +166,9 @@ Changes not staged for commit: Bu da ne! Artık `CONTRIBUTING.md` hem `staged` hem de `unstaged` olarak listelenmiş. Peki neden böyle oldu!? -Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi aşamaya aldığını görüyorsunuz. +Git'in bir dosyayı tam olarak `git add` komutunu çalıştırdığınız anda olduğu gibi izleme aldığını görüyorsunuz. Eğer şimdi `git commit` komutunu çalıştırırsanız, `CONTRIBUTING.md` nin çalışma dizininizde göründüğü şekliyle değil de `git add` komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. -`git add` çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü aşamalandırmak için tekrar `git add` çalıştırmanız gerekir: +`git add` çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü izleme almak için tekrar `git add` çalıştırmanız gerekir: [source,console] ---- @@ -183,10 +183,10 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Kısa-Durum Bilgisi +==== Özet-Durum Bilgisi `git status` çıktısı oldukça kapsamlı ve aynı zamanda da uzundur. -Git'te ayrıca bir kısa-durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. +Git'te ayrıca bir özet-durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. Eğer `git status -s` veya `git status --short` komutunu çalıştırırsanız, çok daha basitleştirilmiş bir çıktı elde edersiniz: [source,console] @@ -200,9 +200,9 @@ M lib/simplegit.rb ---- İzlenmeyen yeni dosyaların yanında `??`, aşama alanına eklenen yeni dosyaların yanında `A` (added), değiştirilen dosyaların yanında ise `M` (modified) bulunur. -Çıktıda iki sütun vardır: soldaki sütun aşama alanının durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. -Örneğin bu çıktıda, `README` dosyası çalışma dizininde değiştirilmiş ancak henüz aşamaya alınmamıştır. `lib/simplegit.rb` dosyası ise değiştirilmiş ve aşamaya alınmıştır. -`Rakefile` değiştirildi (modified), aşamaya alındı (staged) ve tekrar değiştirildi (changed). +Çıktıda iki sütun vardır: soldaki sütun izlem (stage) durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. +Örneğin bu çıktıda, `README` dosyası çalışma dizininde değiştirilmiş ancak henüz izleme alınmamıştır. `lib/simplegit.rb` dosyası ise değiştirilmiş ve izleme alınmıştır. +`Rakefile` değiştirildi (modified), izleme alındı (staged) ve tekrar değiştirildi (changed). Dolayısıyla üzerinde hem "staged" hem de "unstaged" değişiklikler var. [[_ignoring]] @@ -220,7 +220,7 @@ $ cat .gitignore *~ ---- -İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı `.o` veya `.a` ile biten (object ve archive) tüm dosyaları yoksaymasını söyler. +İlk satır Git'e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı `.o` (object) veya `.a` (archive) ile biten tüm dosyaları yoksaymasını söyler. İkinci satır Git'e, adları tilde (`~`) ile biten tüm dosyaları yok saymasını söyler; bu, Emacs gibi birçok metin düzenleyicisi tarafından geçici dosyaları işaretlemek için kullanılır. Ayrıca otomatik olarak oluşturulan log (kayıt), tmp (geçici) veya pid (işlem kimliği) vb dizinleri de ekleyebilirsiniz. Başlamadan önce yeni reponuz için bir `.gitignore` dosyası oluşturmak iyi bir fikirdir. @@ -248,13 +248,13 @@ Ve kısa çizgiyle (`[0-9]`) ayrılmış karakterleri çevreleyen parantezler bu # .a uzantılı tüm dosyaları yoksay *.a -# b.a uzantılı tüm dosyaları yoksaysan da, lib.a dosyası bu kuralın istisnasıdır. lib.a dosyasındaki değişiklikleri izle +# .a uzantılı tüm dosyaları yoksaysan da, lib.a dosyası bu kuralın istisnasıdır. lib.a dosyasındaki değişiklikleri izle !lib.a # Sadece bu dizindeki TODO dosyasını yoksay. Diğer dizinlerdeki TODO dosyalarını değil. (ör: subdir/TODO) /TODO -# build dizinindeki ve onun alt dizinlrindeki tüm dosyaları yoksay +# build dizinindeki ve onun alt dizinlerindeki tüm dosyaları yoksay build/ # doc/notes.txt dosyasını yoksay ama doc/server/arch.txt dosyasını değil @@ -266,30 +266,30 @@ doc/**/*.pdf [İPUCU] ==== -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. +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] ==== -Basit projelerde, bir proje kök dizininde tüm alt dizinler için geçerli olmak üzere tek bir ".gitignore" dosyası bulunur. +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. Bu iç içe geçmiş `.gitignore` dosyalarındaki kurallar yalnızca bulundukları dizinin alt klasörlerinde bulunan dosyalar için geçerlidir. (Örneğin Linux çekirdeği kaynak reposunda 206 adet `.gitignore` dosyası bulunmaktadır.) Birden fazla ".gitignore" dosyası bulunduğu durumlar bu kitabın kapsamı dışındadır. -Bu konuda daha detaylı bilgiye konsol ekranınıza "man gitignore" komutu yazarak ulaşabilirsiniz. +Bu konuda daha detaylı bilgiye konsol ekranınıza `man gitignore` komutu yazarak ulaşabilirsiniz. ==== [[_git_diff_staged]] -==== Aşamalandırılmış (Staged) ve Aşamalandırılmamış (Unstaged) Değişiklikleri Görme +==== İzleme Alınmış (Staged) ve Alınmamış (Unstaged) Değişiklikleri Görme `git status` komutu sizin için yeterince bilgi içermiyorsa (sadece hangi dosyaların değiştirildiğini değil, tam olarak neyi değiştirdiğinizi de bilmek istiyorsanız), bunun yerine `git diff` komutunu kullanabilirsiniz.(((git commands, diff))) -`git diff` komutunu daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için ihtiyaç kullanacaksınız: -1. Neyi değiştirdiniz ama henüz aşamaya almadınız? -2. Neyi aşamaya aldınız fakat henüz katkı olarak işlemediniz? +`git diff` komutunu daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için kullanacaksınız: +1. Neyi değiştirdiniz ama henüz izleme almadınız? +2. Neyi izleme aldınız fakat henüz katkı olarak işlemediniz? Her ne kadar `git status` bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da `git diff` size; eklenen ve kaldırılan satırları, değiştirilen her bir kod parçasıyla birlikte, detaylıca gösterir. -Diyelim ki `README` dosyasını tekrar değiştirip aşamaya alıyorsunuz ve ardından `CONTRIBUTING.md` dosyasını aşamaya almadan düzenliyorsunuz. +Diyelim ki `README` dosyasını tekrar değiştirip izleme alıyorsunuz ve ardından `CONTRIBUTING.md` dosyasını izleme almadan düzenliyorsunuz. `git status` komutunuzu çalıştırırsanız bir kez daha şöyle bir şey görürsünüz: [source,console] @@ -309,7 +309,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Neyi değiştirdiğinizi ancak henüz aşamaya almadığınızı görmek için herhangi bir bayrak (parametre) kullanmadan `git diff' yazın: +Neyi değiştirdiğinizi ancak henüz izleme almadığınızı görmek için herhangi bir bayrak (parametre) kullanmadan `git diff' yazın: [source,console] ---- @@ -330,11 +330,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -Bu komut, çalışma dizininizdeki güncel kodu, aşama alanınızdaki kodla karşılaştırır. +Bu komut, çalışma dizininizdeki güncel kodu, izlem alanınızdaki kodla karşılaştırır. Sonuç size, henüz gerçekleştirmediğiniz değişiklikleri görme imkanı tanır. Eğer bir sonraki katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız `git diff --staged` komutunu kullanabilirsiniz. -Bu komut, aşamadaki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır: +Bu komut, izlemdeki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır: [source,console] ---- @@ -348,10 +348,10 @@ index 0000000..03902a1 +My Project ---- -`git diff` komutunun son katkı işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz aşamaya alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. -Eğer tüm değişikliklerinizi aşamaya aldıysanız, `git diff` size hiçbir çıktı vermeyecektir. +`git diff` komutunun son katkı işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz izleme alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. +Eğer tüm değişikliklerinizi izleme aldıysanız, `git diff` size hiçbir çıktı vermeyecektir. -Bir başka örnek olarak, `CONTRIBUTING.md` dosyasını aşamaya alır ve ardından yeniden düzenlerseniz, dosyadaki aşamalandırılmış ve aşamalandırılmamış değişiklikleri görmek için `git diff` komutunu kullanabilirsiniz. +Bir başka örnek olarak, `CONTRIBUTING.md` dosyasını izleme alır ve ardından yeniden düzenlerseniz, dosyadaki izleme alınmış ve alınmammış değişiklikleri görmek için `git diff` komutunu kullanabilirsiniz. Ortamımız şöyle görünüyorsa: [source,console] @@ -373,7 +373,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Artık neyin aşamalandırılmamış olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: +Artık neyin izleme alınmamış olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: [source,console] ---- @@ -389,7 +389,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -veya şu ana kadar neleri aşamaya aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: +veya şu ana kadar neleri izleme aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: [source,console] ---- @@ -414,7 +414,7 @@ index 8ebb991..643e24f 100644 Harici Araçlarda .Git Diff ==== Kitabın geri kalanında `git diff` komutunu çeşitli şekillerde kullanmaya devam edeceğiz. -Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine grafiksel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka bir yolları da vardır. +Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine görsel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka yolları da vardır. Eğer `git diff` yerine `git difftool` komutu çalıştırırsanız, bu farklardan herhangi birini "emerge", "vimdiff" ve daha birçok farklı yazılımda (ticari yazılımlar dahil) görüntüleyebilirsiniz. Sisteminizde hangilerinin mevcut olduğunu görmek için `git difftool --tool-help` komutunu çalıştırabilirsiniz. ==== @@ -422,10 +422,10 @@ Sisteminizde hangilerinin mevcut olduğunu görmek için `git difftool --tool-he [[_committing_changes]] ==== Değişiklikleri Katkı Olarak İşlemek -Artık aşama alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi katkı olarak işleyebilirsiniz. -"unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç `git add` komutuyla aşamaya almadığınız dosyalar) bu işlemle katkı geçmişine kaydedilmeyeceğini aklınızdan çıkarmayın. +Artık izlem alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi katkı olarak işleyebilirsiniz. +"unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç `git add` komutuyla izleme almadığınız dosyalar) bu işlemle katkı geçmişine kaydedilmeyeceğini aklınızdan çıkarmayın. Bu dosyalar diskinizde "modified" (değiştirilmiş) işaretli olarak kalacaklar. -Bu durumda, eğer bir kez daha `git status` komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğun görürseniz, artık değişikliklerinizi katkı olarak işlemeye hazırsınız demektir.(((git commands, status))) +Bu durumda, eğer bir kez daha `git status` komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğunu görürseniz, artık değişikliklerinizi katkı olarak işlemeye hazırsınız demektir.(((git commands, status))) Değişikliklerinizi işlemenin en basit yolu `git commit` komutunu çalıştırmaktır:(((git commands, commit))) [source,console] @@ -459,7 +459,7 @@ Ekranda aşağıdaki metni göreceksiniz (bu örnek bir Vim ekranıdır): Varsayılan katkı mesajının, yorumlanan `git status` komutunun en son çıktısını ve üstte bir boş satırı içerdiğini görebilirsiniz. Bu yorumları kaldırabilir ve katkı mesajınızı yazabilir veya neyi katkı olarak işlediğinizi hatırlamanıza yardımcı olması için orada bırakabilirsiniz. (Neyi değiştirdiğinizi daha da açık bir şekilde hatırlatmak için, `git commit` komutuna `-v` bayrağı ekleyebilirsiniz. -Böylece yaptığınız değişikliği (diff) da derleyicinize eklemiş olursunuz ve ileride tam olarak hangi değişiklikleri yaptığınızı görebilirsiniz.) +Böylece yaptığınız değişikliği (diff) derleyicinize eklemiş olursunuz ve tam olarak hangi değişiklikleri yaptığınızı görebilirsiniz.) Derleyicinizden çıktığınızda, Git bu mesajla birlikte (yorumlar ve değişiklikler çıkarılmış olarak) katkı kaydınızı oluşturur. Alternatif olarak, `-m` (message) bayrağı kullanarak katkı mesajınızı `commit` komutuyla aynı satırda yazabilirsiniz: @@ -472,20 +472,20 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Tebrikler artık ilk katkınızı işlediniz! -Bu katkı kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz; değişiklikleri hangi dala (`master`) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (Gelecekte bir katkıya geri dönmek istediğinizde tam olarak hangi katkıya dönmek istediğinizi belirtebilmeniz içih her bir katkınızın kendine özel bir SHA-1 kodu bulunur. Bu bir nevi kaydınızın kimlik numarası gibidir.) sahip olduğu ('463dc4f'), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır. +Tebrikler, artık ilk katkınızı işlediniz! +Bu katkı kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz; değişiklikleri hangi dala (`master`) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (Gelecekte, geçmiş bir katkıya geri dönmek istediğinizde tam olarak hangi katkıya dönmek istediğinizi belirtebilmeniz içih her bir katkınızın kendine özel bir SHA-1 kodu bulunur. Bu bir nevi katkınızın kimlik numarası gibidir.) sahip olduğu ('463dc4f'), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır. -Katkı kayıtlarınızın aşama alanınıza yüklediğiniz codun pozu (snapshot) olduğunu unutmayın. -Aşamaya almadığınız her şey dosya ve kod hala orada değiştirilmiş halde duruyor. +Katkı kayıtlarınızın izleme yüklediğiniz kodun pozu (anlık görüntüsü) olduğunu unutmayın. +İzleme almadığınız her şey dosya ve kod hala orada değiştirilmiş bir halde duruyor. Bunları katkı geçmişinize eklemek için başka bir katkı işleminde bulunabilirsiniz. Aslında her katkı işlediğinizde, projenizin daha sonra geri dönebileceğiniz veya karşılaştırabileceğiniz bir pozunu kaydetmiş oluyorsunuz. -==== Aşama (Stage) Alanını Atlamak +==== İzlem Alanını Atlamak (((staging area, skipping))) -Aşama alanı katkılarınızın tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. -Aşama alanını atlamak istiyorsanız Git basit bir kısayol sağlar. -`git commit` komutuna `-a` (add) seçeneğinin eklenmesi, Git'in zaten izlenen her dosyayı katkıda bulunmadan önce otomatik olarak aşamaya almasını sağlar ve `git add` kısmını atlamanıza olanak tanır: +İzlem alanı katkılarınızın tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. +İzlem alanını atlamak istiyorsanız, Git bunun için basit bir kısayol sağlar. +`git commit` komutuna `-a` (add) seçeneğinin eklenmesi, Git'in zaten izlenen her dosyayı katkıda bulunmadan önce otomatik olarak izleme almasını sağlar ve `git add` kısmını atlamanıza olanak tanır: [source,console] ---- @@ -505,15 +505,15 @@ $ git commit -a -m 'added new benchmarks' ---- Bu durumda katkı işlemeden önce `CONTRIBUTING.md` dosyasında `git add` komutunu çalıştırmanız gerekmediğine dikkat edin. -Bunun nedeni `-a` (all) bayrağının değiştirilen tüm dosyaları içermesidir. +Bunun nedeni `-a` bayrağının değiştirilen tüm dosyaları içermesidir. Bunu yapmakta herhangi bir sorun yoktur ancak dikkatli olun; bazen bu bayrak istenmeyen değişiklikleri de katkılarınıza eklemenize neden olur. [[_removing_files]] ==== Dosyaları Silmek (((files, removing))) -Git'ten bir dosyayı kaldırmak için, onu izlenen dosyalar listenizden (stage) kaldırmanız ve ardından bu değişikliği kaydetmeniz (commit) gerekir. -`git rm` komutu seçtiğiniz dosyayı hem aşama alanından hem de çalışma dizininizden kaldırır. +Git'ten bir dosyayı kaldırmak için, onu izlemden kaldırmanız ve ardından bu değişikliği kaydetmeniz (commit) gerekir. +`git rm` komutu seçtiğiniz dosyayı hem izlem alanından hem de çalışma dizininizden kaldırır. Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. Eğer dosyayı silmek yerine sadece takipten çıkarmak istiyorsanız dosya yolunu ve adını `.gitignore` dosyasına kaydetmelisiniz. @@ -534,7 +534,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Daha sonra, eğer `git rm` komutunu çalıştırırsanız, dosyanın kaldırılması işlemini aşama alanına almış olursunuz: +Daha sonra, eğer `git rm` komutunu çalıştırırsanız, dosyanın kaldırılması işlemini izlem alanına almış olursunuz: [source,console] ---- @@ -550,12 +550,12 @@ Changes to be committed: ---- Bir sonraki katkı işleminizde dosya kaybolacak ve artık izlenmeyecektir. -Dosyayı değiştirdiyseniz veya aşama alanına zaten eklediyseniz, Git'i kaldırma işlemine zorlamak için `-f` (forced) seçeneğini kullanmalısınız. +Dosyayı değiştirdiyseniz veya izleme zaten eklediyseniz, Git'i kaldırma işlemine zorlamak için `-f` (forced) seçeneğini kullanmalısınız. Bu, henüz poz olarak kaydedilmemiş ve Git'ten kurtarılamayan verilerin yanlışlıkla kaldırılmasını önleyen bir güvenlik özelliğidir. -Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak aşama alanınızdan kaldırmaktır. +Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak izlemden kaldırmaktır. Başka bir deyişle, dosyayı sabit diskinizde tutmak ancak Git'in artık onu izlememesini sağlamak isteyebilirsiniz. -Eğer `.gitignore` dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla aşamaya aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş `.a` dosyaları gibi) bu özellik oldukça işinize yarayacaktır. +Eğer `.gitignore` dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla izleme aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş `.a` dosyaları gibi) bu özellik oldukça işinize yarayacaktır. Bunu yapmak için `--cached` seçeneğini kullanın: [source,console] @@ -624,5 +624,5 @@ $ git add README ---- Git bunun dolaylı olarak bir yeniden adlandırma olduğunu anlar, dolayısıyla bir dosyayı bu şekilde veya `mv` komutuyla yeniden adlandırmanız önemli değildir. -Tek dikkate değen fark, `git mv` komutunun üç yerine tek bir komut olmasıdır ki bu da bize kolaylık sağlar. +Tek dikkate değer fark, `git mv` komutunun üç yerine tek bir komut olmasıdır ki bu da bize kolaylık sağlar. Daha da önemlisi, bir dosyayı yeniden adlandırmak için istediğiniz herhangi bir aracı kullanabilir ve ardından add/rm ile adresleyerek dosyayı katkı olarak işlemeye uygun hale getirebiliriz. From 05cf29dc6b60bcac6babc319f97ff86d68ffc63a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 17:56:08 +0100 Subject: [PATCH 114/210] Update remotes.asc --- book/02-git-basics/sections/remotes.asc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 50de24bb..140bd3c5 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -21,7 +21,7 @@ Böyle bir uzak repoyla çalışmak, diğer uzaktan sunucularda olduğu gibi yin Hangi uzak sunucuları yapılandırdığınızı görmek için `git remote` komutunu çalıştırabilirsiniz.(((git commands, remote))) Bu belirttiğiniz her uzak sunucunun kısa adlarını listeler. -Reponuzu kopyaladıysanız en azından `Origin`i görmelisiniz (Git'in kopyaladığınız sunucuya verdiği varsayılan isim budur): +Reponuzu kopyaladıysanız en azından ``Origin``'i görmelisiniz (Git'in kopyaladığınız sunucuya verdiği varsayılan isim budur): [source,console] ---- @@ -72,7 +72,7 @@ Bu uzak sunucuların çeşitli protokoller kullandığına dikkat edin (Bu konu ==== Uzak Sunucuları Görme -`git clone` komutunun sizin için 'Origin' uzak sunucusunu nasıl eklediğinden üstü kapalı bahsettik ve bazı gösterimler verdik. +`git clone` komutunun sizin için ``Origin`` uzak sunucusunu nasıl eklediğinden üstü kapalı bahsettik ve bazı gösterimler verdik. Yeni bir uzak sunucunun nasıl ekleneceği aşağıda daha açıkça anlatılmıştır.(((git commands, remote))) Kısa adını kullanarak yeni bir uzak Git reposu eklemek için `git remote add ` komutunu çalıştırın: @@ -134,12 +134,12 @@ Varsayılan olarak `git clone` komutu, yerel ana dalınızı (genellikle main ve `git pull` komutunu çalıştırmak genellikle verileri kopyaladığınız asıl sunucudan getirir ve otomatik olarak bu verileri üzerinde çalışmakta olduğunuz kodla birleştirmeye çalışır. [[_pushing_remotes]] -==== Kodlarınızı Uzak Sunucuya İtmek (push) +==== Kodlarınızı Uzak Sunucuya İtmek Projeniz belli bir aşamaya ulaştıktan sonra paylaşmak isteyebilirsiniz. Bunun için geliştirilmiş kodunuzu uzak repoya itmeniz gerekmektedir. Bunun için kullanmanız gereken komut basittir: `git Push `.(((git commands, push))) -Ana dalınızı "Origin" sunucunuza göndermek istiyorsanız (yine kopyalama genellikle bu adların her ikisini de sizin için otomatik olarak ayarlar), o zaman işlediğiniz katkıları sunucuya geri göndermek için şunu çalıştırabilirsiniz: +Ana dalınızı `Origin` sunucunuza göndermek istiyorsanız (yine kopyalama genellikle bu adların her ikisini de sizin için otomatik olarak ayarlar), o zaman işlediğiniz katkıları sunucuya geri göndermek için şunu çalıştırabilirsiniz: [source,console] ---- @@ -204,7 +204,7 @@ $ git remote show origin master pushes to master (up to date) ---- -Bu komut belirli bir daldaken `git Push` komutunu çalıştırdığınızda, otomatik olarak hangi dalın uzak repoya aktarılacağını gösterir. +Bu komut belirli bir daldayken `git Push` komutunu çalıştırdığınızda, otomatik olarak hangi dalın uzak repoya aktarılacağını gösterir. Ayrıca; sunucudaki hangi uzak dallara henüz sahip olmadığınızı, yerelde sahip olduğunuz hangi dalların uzak sunucudan kaldırılmış olduğunu ve `git pull` çalıştırdığınızda otomatik olarak uzak-izleme dallarıyla birleşecek çoklu yerel dallarınızı da gösterir. ==== Uzak Sunucuları Yeniden Adlandırma ve Kaldırma @@ -223,7 +223,7 @@ paul Bunun tüm uzaktan izleme dal adlarınızı değiştirdiğini belirtmekte fayda var. Önceden `pb/master` olarak adlandırılan (referans) uzak sunucunun yeni adı artık `paul/master`dır. -Herhangi bir nedenden dolayı uzak sunucuyu kaldırmak isterseniz (ör: sunucuyu taşımışsanız veya artık belirli bir aynayı -mirror: bir repodaki tüm verileri ve geçmişi eksiksiz olarak başka bir repoya kopyalayan bir repo- kullanmıyorsanız veya geliştiricilerden biri artık projeye katkıda bulunmuyorsa) `git remote remove` veya `git remote rm` komutlarından birini kullanabilirsiniz: +Herhangi bir nedenden dolayı uzak sunucuyu kaldırmak isterseniz (ör: sunucuyu taşımışsanız veya artık belirli bir aynayı (mirror: bir repodaki tüm verileri ve geçmişi eksiksiz olarak başka bir repoya kopyalayan bir repo) kullanmıyorsanız veya geliştiricilerden biri artık projeye katkıda bulunmuyorsa `git remote remove` veya `git remote rm` komutlarından birini kullanabilirsiniz: [source,console] ---- From 62c742f9f08fff96d6840c2273a50d974448e0fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 4 Mar 2024 17:56:30 +0100 Subject: [PATCH 115/210] Delete book/02-git-basics/sections/summary.asc --- book/02-git-basics/sections/summary.asc | 5 ----- 1 file changed, 5 deletions(-) delete mode 100644 book/02-git-basics/sections/summary.asc diff --git a/book/02-git-basics/sections/summary.asc b/book/02-git-basics/sections/summary.asc deleted file mode 100644 index 8bcab08b..00000000 --- a/book/02-git-basics/sections/summary.asc +++ /dev/null @@ -1,5 +0,0 @@ -[[_git_basics_summary]] -=== Özet - -Bu noktada, temel yerel Git işlemlerini yapabilirsiniz: bir repo oluşturma (init) veya kopyalama (clone), değişiklikler yapma, bu değişiklikleri aşamalandırma (stage) ve katkı olarak işleme (commit), repo üzerinde geçirilen tüm değişikliklerin geçmişini görüntüleme (log), vs. -Bir sonraki adımda, Git'in öldürücü özelliğini kapsayacağız: dal modelini. From 47dfbc99ff8820dbeba0ab1df3491e4ec2910f19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 11:11:17 +0100 Subject: [PATCH 116/210] Update tagging.asc --- book/02-git-basics/sections/tagging.asc | 32 ++++++++++++------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 9228fa95..094efd3c 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,12 +1,12 @@ [[_git_tagging]] -=== Etiketleme (tagging) +=== Etiketleme (((tags))) -Çoğu VCS gibi Git de bir reponun geçmişindeki belirli noktaları "önemli" şeklinde etiketleme yeteneğine sahiptir. +Çoğu VCS gibi Git de bir reponun geçmişindeki belirli noktaları "önemli" şeklinde etiketleme (tagging) yeteneğine sahiptir. Genellikle geliştiriciler bu işlevi her bir sürümü (`v1.0`, `v2.0` vb.) işaretlemek için kullanır. Bu bölümde mevcut etiketlerin nasıl listeleneceğini, etiketlerin nasıl oluşturulacağını ve silineceğini ve farklı etiket türlerinin neler olduğunu öğreneceksiniz. -==== Etiketlerinizi Listeleme (listing) +==== Etiketlerinizi Listeleme Git'te mevcut etiketleri listelemek çok basittir. Sadece `git tag` (isterseniz `-l` veya `--list` seçenekleriyle) yazmanız yeterlidir:(((git commands, tag))) @@ -20,7 +20,7 @@ v2.0 Bu komut, etiketleri alfabetik sıraya göre listeler ama görüntülenme sırasının aslında bir önemi yoktur. -Ayrıca belli kalıplarla (pattern) eşleşen etiketleri de arayabilirsiniz. +Ayrıca belli kalıplarla eşleşen etiketleri de arayabilirsiniz. Örneğin Git kaynak reposu 500'den fazla etiket içerir. Eğer sadece 1.8.5 serisine bakmak istiyorsanız şunu çalıştırabilirsiniz: @@ -40,32 +40,32 @@ v1.8.5.5 ---- [NOT] -.Joker (wildcard) etiket karakterlerini listelemek `-l` veya `--list` gerektirir +.Joker etiket karakterlerini listelemek `-l` veya `--list` gerektirir ==== Eğer tüm etiketlerin toplu bir listesini istiyorsanız `git tag` komutunu çalıştırabilirsiniz. Git bu durumda sizin bir liste istediğinizi varsayar ve size bu listeyi verir. Böyle bir durumda `-l` veya `--list` kullanımı isteğe bağlıdır. -Ancak etiket adlarıyla eşleştirmek üzere bir karakter deseni (joker) yazacaksanız, `-l` veya `--list` kullanımı zorunludur. +Ancak etiket adlarıyla eşleştirmek üzere bir karakter deseni yazacaksanız, `-l` veya `--list` kullanımı zorunludur. ==== ==== Etiket Oluşturma -Git iki çeşit etiketi destekler: _lightweight_ (hafif) ve _annotated_ (açıklamalı). +Git, iki çeşit etiketi destekler: _lightweight_ (hafif) ve _annotated_ (açıklamalı). Hafif bir etiket, değişmeyen bir Git dalı gibidir; yalnızca belirli bir katkının işaretçisidir. Ancak açıklamalı etiketler Git veritabanında tam nesneler olarak depolanır. Bunlar sağlamalı (checksummed) verilerdir. -Etiketleyicinin adını, e-postasını ve etiketleme tarihini içerir, etiketleme mesajınız yer alır ve GNU Privacy Guard (GPG) ile imzalanıp, doğrulanabilir. +Etiketi koyan kişinin adını, e-postasını ve etiketleme tarihini içerir, etiketleme mesajınız yer alır ve GNU Privacy Guard (GPG) ile imzalanıp, doğrulanabilir. Tüm bu bilgilere sahip olabilmeniz için genellikle açıklamalı etiketler oluşturmanız önerilir, ancak geçici bir etiket istiyorsanız veya herhangi bir nedenle diğer bilgileri saklamak istemiyorsanız, hafif etiketler de mevcuttur. [[_annotated_tags]] -==== Açıklamalı Etiketler (annotated tags) +==== Açıklamalı Etiketler (((tags, annotated))) Git'te açıklamalı bir etiket oluşturmak basittir. -En kolay yol, `tag` komutunu çalıştırdığınızda `-a` bayrağı da belirtmektir:(((git commands, tag))) +En kolay yol, `tag` komutunu çalıştırdığınızda `-a` (annotated) bayrağı da belirtmektir:(((git commands, tag))) [source,console] ---- @@ -76,7 +76,7 @@ v1.3 v1.4 ---- -`-m` bayrağı etiketle birlikte saklanan bir etiketleme mesajı belirtir. +`-m` (message) bayrağı etiketle birlikte saklanan bir etiketleme mesajı belirtir. Eğer bu etiket için bir mesaj belirtmezseniz Git, mesajı yazabilmeniz için otomatik olarak düzenleyicinizi başlatır. Etiket verilerini `git show` komutunu kullanarak etiketlediğiniz katkıyla birlikte görebilirsiniz: @@ -99,10 +99,10 @@ Date: Mon Mar 17 21:52:11 2008 -0700 Bu katkı bilgisini göstermeden önce etiketleme bilgisini, etiketleme tarihini ve açıklama mesajını gösterir. -==== Hafif Etiketler (lightweight tags) +==== Hafif Etiketler (((tags, lightweight))) -Katkıları etiketlemenin başka bir yolu da hafif etiketler kullanmaktır. +Katkıları etiketlemenin başka bir yolu da hafif (lightweight) etiketler kullanmaktır. Bu metodda "katkı sağlaması" dışında hiçbir veri saklanmaz. Hafif etiket oluşturmak için `-a`, `-s` veya `-m` seçeneklerinden hiçbirini kullanmaksızın sadece bir etiket adı yazarsınız: @@ -132,7 +132,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Sonradan Etiketleme -Katkıları işledikten sonra da etiketleyebilirsiniz. +Katkıları, işledikten sonra da etiketleyebilirsiniz. Katkı geçmişinizin şöyle göründüğünü varsayalım: [source,console] @@ -251,7 +251,7 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -Aslında yaptığımız şey: uzak sunucudaki etiket adının (tagname) üstüne boş (null) bir değer yazmaktır (":" dan önceki boşluğa dikkat edin). +Aslında yaptığımız şey: uzak sunucudaki etiket adının üstüne boş (null) bir değer yazmaktır (":" dan önceki boşluğa dikkat edin). Böylece eski etiket silinecektir. Uzak etiketi silmenin ikinci (ve daha sezgisel) yolu ise `--delete ` kullanmaktır (tagname: etiket adı): @@ -288,7 +288,7 @@ HEAD is now at df3f601... add atlas.json and cover image ---- Normalde her bir dalda bir uç (HEAD) bulunur ve bu uç en son katkıya iliştirilmiştir. -``detached HEAD`` durumundayken bu uç en son katkı yerine etikete sabitlendiğinden, yeni bir katkı işleseniz bile katkıniz hiçbir dala ait olmayacağı için "kesin katkı karması" (hash) dışında erişilemez olacaktır. +``detached HEAD`` durumundayken bu uç en son katkı yerine etikete sabitlendiğinden, yeni bir katkı işleseniz bile katkıniz hiçbir dala ait olmayacağı için "katkı karması" (hash) dışında erişilemez olacaktır. Bu nedenle, değişiklik yapmanız gerekiyorsa (mesela eski bir sürümdeki bir hatayı düzelttiniz) yeni bir dal oluşturmanız gerekecektir: [source,console] From 92581d897845948bcd866fe814575d1f0a5943c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 11:23:06 +0100 Subject: [PATCH 117/210] Update undoing.asc --- book/02-git-basics/sections/undoing.asc | 36 ++++++++++++------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 02297d14..cedbe9d8 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_undoing]] -=== Değişiklikleri Geri Alma (undo) +=== Değişiklikleri Geri Alma Herhangi bir aşamada bir şeyi geri almak isteyebilirsiniz. Burada, yaptığınız değişiklikleri geri almak için kullanabileceğiniz birkaç temel aracı inceleyeceğiz. -Bu geri alma işlemlerinin bazılarını her zaman iptal ederek eski (geri alma öncesi) duruma geri dönemeyebileceğiniz için, dikkatli olmalısınız. -Bu, Git'te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç durumdan biridir. +Bu geri alma işlemlerinin bazılarını her istediğinizde iptal ederek (bu geri alma işlemi öncesi) eski duruma geri "dönemeyebileceğiniz" için, dikkatli olmalısınız. +Bu, Git'te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç özel durumdan biridir. Yaygın geri alma ihtiyaçlarından biri, bazı dosyaları eklemeyi unuttup katkınızı çok erken işlediğinizde veya yanlış bir katkı mesajı yazdığınızda ortaya çıkar. -Bir katkıyı yeniden işlemek istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları aşamaya alın ve `--amend` seçeneğini kullanarak yeniden katkılayın: +Bir katkıyı yeniden işlemek istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları izlem alın ve `--amend` seçeneğini kullanarak yeniden katkılayın: [source,console] ---- $ git commit --amend ---- -Bu komut aşama alanınızı alır ve katkılamak için kullanır. -Son katkınızdan beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son katkınızdan hemen sonra çalıştırdıysanız), pozunuz (snapshot) tamamen aynı olacak ve değiştireceğiniz tek şey katkı mesajınız olacaktır. +Bu komut izlem alanınızı alır ve katkılamak için kullanır. +Son katkınızdan beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son katkınızdan hemen sonra çalıştırdıysanız), pozunuz tamamen aynı olacak ve değiştireceğiniz tek şey katkı mesajınız olacaktır. -Bunu yaptığınızda aynı "katkı mesajı düzenleyicisi" aynı katı mesajıyla devreye girer. +Bunu yaptığınızda aynı "katkı mesajı düzenleyicisi" aynı katkı mesajıyla devreye girer. Mesajı her zamanki gibi düzenleyebilirsiniz, ancak bu sefer önceki katkı mesajınızın üzerine yazılır. -Örnek olarak, katkı yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri aşamaya almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz: +Örnek olarak, katkı yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri izleme almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz: [source,console] ---- @@ -33,20 +33,20 @@ Bu işlemin sonucunda, ikinci katkınızın ilk katkınızın yerini aldığı t [NOT] ==== -Şunu anlamanız özellikle önemli: Eğer son katkınızı onarırsanız (amend), son katkınızı düzeltmekten ziyade, aslında eski katkınızı ortadan kaldırıp ve yerine yeni bir katkı işlemektesiniz. +Ş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. -Önceki katkıları değiştirmenin asıl değeri, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemdeki bir yazım hatasını düzelttim`` şeklinde gereksiz katkı mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır. +Önceki katkıları değiştirmenin asıl önemi, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemdeki bir yazım hatasını düzelttim`` şeklinde gereksiz katkı mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır. ==== [[_unstaging]] -==== Aşamaya Alınmış Dosyayı Aşamadan Çıkarmak (Unstaging) +==== İzleme Alınmış Dosyayı izlemden Çıkarmak -Sonraki iki bölümde aşama alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. -İşin güzel yanı, bu iki alanın durumunu tanımlamak için kullandığımız komut aynı zamanda bu alanlarda yapılan değişiklikleri nasıl geri alacağımızı da bize söyler. -Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla `git add *` yazıp ikisini birden aşamalandırdığınızı varsayalım. -İkisinden birini nasıl aşamadan çıkarabilirsiniz? +Sonraki iki bölümde izlem alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. +İşin güzel yanı, bu iki alanın durumunu tanımlamak için kullandığımız komutun aynı zamanda bu alanlarda yapılan değişiklikleri nasıl geri alacağımızı da bize söylemesidir. +Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla `git add *` yazıp ikisini birden izleme aldığınızı varsayalım. +İkisinden sadece birini nasıl izlemden çıkarabilirsiniz? `git status` komutu size bunu nasıl yapacağınızı zaten hatırlatmaktadır: [source,console] @@ -84,7 +84,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 değil. +`CONTRIBUTING.md` dosyası değiştirildi ancak nihai durumda "stage"de (izlemde) değil. [NOT] ===== @@ -93,9 +93,9 @@ Ancak yukarıda açıklanan senaryoda çalışma dizininizdeki dosyaya dokunulma ===== Şimdilik bu sihirli çağrı, `git reset` komutu hakkında bilmeniz gereken tek şeydir. -<> bölümünde `reset`in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz. +<> bölümünde `reset`'in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz. -==== Değiştirilmiş Dosyadaki Değişikliği Geri Alma (Unmodifying) +==== Değiştirilmiş Dosyadaki Değişikliği Geri Alma `CONTRIBUTING.md` dosyasındaki değişikliklerinizi saklamak istemediğinizi fark ederseniz ne yaparsınız? Yaptığınız değişiklikleri kolayca nasıl kaldırabilirsiniz veya en son katkınızdaki (veya başlangıçta kopyaladığınız ya da çalışma dizininize soktuğunuz) haline nasıl geri döndürebilirsiniz? From cf8a66b2ba3a6bab7af1f192f0501cc24b9b863f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 11:40:29 +0100 Subject: [PATCH 118/210] Update viewing-history.asc --- .../sections/viewing-history.asc | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 9920f87e..d82178db 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -135,7 +135,7 @@ Bir diğer kullanışlı seçenek ise `--pretty`dir. Bu seçenek, günlük çıktısını varsayılanın dışındaki formatlara çevirir. Kullanmanız için önceden oluşturulmuş birkaç seçenek mevcuttur. `oneline` seçeneği her bir katkıyı tek bir satıra yazdırır (eğer çok sayıda katkıya bakıyorsanız özellikle kullanışlıdır). -Ek olarak, `short` (kısa), `full` (tam), ve `fuller` (geniş) seçenekleri çıktıyı aşağı yukarı aynı şekilde ancak daha az veya daha fazla bilgiyle gösterir. +Ek olarak, `short` (kısa), `full` (tam), ve `fuller` (tastamam) seçenekleri çıktıyı aşağı yukarı aynı şekilde ancak daha az veya daha fazla bilgiyle gösterir. Sırasıyla: [source,console] @@ -146,7 +146,7 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -En ilginç seçenek, kendi günlük çıktı formatınızı belirlemenize olanak tanıyan `format`tır. +En ilginç seçenek, kendi günlük çıktı formatınızı belirlemenize olanak tanıyan `format`'tır. Bu, özellikle makine ayrıştırması için çıktı oluşturduğunuzda kullanışlıdır. Biçimi açıkça belirttiğiniz için Git'teki güncellemelerle değişmeyeceğini bilirsiniz.(((log formatting))) @@ -158,7 +158,7 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> `format`in gerektirdiği daha kullanışlı seçeneklerden bazılarını listeler. +<> `format`'ın gerektirdiği daha kullanışlı seçeneklerden bazılarını listeler. [[pretty_format]] .Kullanışlı `git log --pretty=format` seçenekleri @@ -172,11 +172,11 @@ a11bef0 - Scott Chacon, 6 years ago : first commit | `%P` | Ana hashler | `%p` | Ana hashler (kısa) | `%an` | Yazar adı -| `%ae` | Yazar email adresi +| `%ae` | Yazar e-posta adresi | `%ad` | Yazım tarihi (--date=option) | `%ar` | Yazım tarihi, göreli | `%cn` | Geliştirici adı -| `%ce` | Geliştirici email adresi +| `%ce` | Geliştirici e-posta adresi | `%cd` | Geliştirme tarihi | `%cr` | Geliştirme tarihi, göreli | `%s` | Konu @@ -208,7 +208,7 @@ $ git log --pretty=format:"%h %s" --graph Bir sonraki bölümde dallanma ve birleştirme işlemlerine geçtikçe bu tür çıktılar daha ilginç hale gelecektir. Bunlar `git log` için yalnızca bazı basit çıktı biçimlendirme seçenekleridir fakat çok daha fazlası vardır. -<> şu ana kadar ele aldığımız seçeneklerin yanı sıra faydalı olabilecek diğer bazı yaygın biçimlendirme seçeneklerini ve bunların log komutunun çıktısını nasıl değiştirdiklerini listeler. +<> şu ana kadar ele aldığımız seçeneklerin yanı sıra faydalı olabilecek diğer bazı yaygın biçimlendirme seçeneklerini ve bunların `log` komutunun çıktısını nasıl değiştirdiklerini listeler. [[log_options]] .Yaygın `git log` seçenekleri @@ -222,7 +222,7 @@ Bunlar `git log` için yalnızca bazı basit çıktı biçimlendirme seçenekler | `--name-status` | Eklenen/değiştirilen/silinmiş bilgilerle birlikte değiştirilen dosyaların listesini de göster | `--abbrev-commit` | SHA-1 kimliğinin tüm 40 karakteri yerine sadece ilk bir kaç karakterini göster | `--relative-date` | Tarihi, tam tarih biçimini kullanmak yerine göreli bir biçimde göster (ör. ``2 hafta önce``) -| `--graph` | Günlük çıktısının yanında dal ve birleştirme geçmişinin ASCII grafiğini de göster +| `--graph` | Günlük (log) çıktısının yanında dal ve birleştirme geçmişinin ASCII grafiğini de göster | `--pretty` | Katkıları alternatif bir formatta göster. Seçenekler arasında tek satırlı (oneline), kısa (short), tam (full), daha kapsamlı (fuller) ve kendi oluşturduğunuz format da yer alır. | `--oneline` | `--pretty=oneline --abbrev-commit` birlikte kullanımı için kısayoldur |================================ @@ -256,7 +256,7 @@ Ancak, `--all-match` seçeneğinin eklenmesi çıktıyı _all_ `--grep` kalıpla ==== -Bir diğer gerçekten faydalı süzgeç ise bir dize (string) alan ve yalnızca o dizenin oluşum sayısını değiştiren katkıları gösteren `-S` seçeneğidir (yazılımcılar arasında Git'in "kazma" seçeneği olarak anılır). +Gerçekten faydalı bir diğer süzgeç (filter) ise bir dize (string) alan ve yalnızca o dizenin oluşum sayısını değiştiren katkıları gösteren `-S` seçeneğidir (yazılımcılar arasında Git'in "kazma" seçeneği olarak anılır). Örneğin, belirli bir işleve referans ekleyen veya kaldıran son katkıyı bulmak istiyorsanız şunu arayabilirsiniz: [source,console] @@ -264,7 +264,7 @@ Bir diğer gerçekten faydalı süzgeç ise bir dize (string) alan ve yalnızca $ git log -S function_name ---- -`git log` komutuna filtre argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). +`git log` komutuna süzme argümanı olarak yazabileceğimiz son faydalı seçenek ise dosya yoludur (path). Eğer bir dizin veya dosya adı belirtirseniz günlük çıktısını, bu dosyalarda değişiklik yapan katkılarla sınırlayabilirsiniz. Bu her zaman son seçenektir ve dosya yollarını seçeneklerden (bayraklardan) ayırmak için genellikle önünde çift çizgi (`--`) bulunur. @@ -278,8 +278,8 @@ Bu her zaman son seçenektir ve dosya yollarını seçeneklerden (bayraklardan) | `-` | Sadece en son n sayıdaki katkıyı göster | `--since`, `--after` | Katkı listesini belirli bir tarihten sonra yapılan katkılarla sınırla | `--until`, `--before` | Katkı listesini belirli bir tarihe kadar yapılan katkılarla sınırla -| `--author` | Sadece author kısmı, verilen dizeyle eşleşen katkıları göster -| `--committer` | Sadece committer kısmı, verilen dizeyle eşleşen katkıları göster +| `--author` | Sadece yazar (author) kısmı, verilen dizeyle eşleşen katkıları göster +| `--committer` | Sadece geliştirici (committer) kısmı, verilen dizeyle eşleşen katkıları göster | `--grep` | Sadece katkı mesajında, girilen dize bulunan katkıları göster | `-S` | Sadece kodda verilen dizeyi ekleyen veya çıkaran katkıları göster |================================ @@ -298,7 +298,7 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Bu komutla, Git kaynak kodu geçmişindeki yaklaşık 40.000 katkıdan, bu kriterlere uyan sadece 6'sını görebilirsiniz. +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] .Birleştirme katkılarının gösterilmesini engelleme From 45f469ed2e78002f7249c382a3210d662d9dfaca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 11:53:52 +0100 Subject: [PATCH 119/210] Update basic-branching-and-merging.asc --- .../sections/basic-branching-and-merging.asc | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) 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 7ca00fcc..59da1f52 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,10 +1,10 @@ -=== Kısaca Dallandırma ve Birleştirme +=== Kısaca Dallandırma ve Birleştirme Temelleri Şimdi gerçek dünyada kullanabileceğiniz bir iş akışıyla basit bir dallandırma ve birleştirme örneğini inceleyelim. Bu adımları takip edeceksiniz: . Bir web projesi üzerinde birşeyleri değiştirin. -. Üzerinde çalıştığınız kullanıcı hikayesi (user story) için yeni bir dal oluşturun. +. Üzerinde çalıştığınız iş paketi (user story) için yeni bir dal oluşturun. . Bu dal üzerinde çalışın. Diyelim ki bu aşamada, başka bir sorunun daha kritik olduğuna ve acilen düzeltmeniz (hotfix) gerektiğine dair bir çağrı aldınız. @@ -12,11 +12,11 @@ Diyelim ki bu aşamada, başka bir sorunun daha kritik olduğuna ve acilen düze . Üretim (production) dalına geçin (Bu sizin canlı yayındaki dalınızdır, genellikle master veya main olarak adlandırılır). . Onarım amaçlı yeni bir dal oluşturun. -. Düzgün çalıştığını test ettikten sonra onarım dalını üretim dalıyla birleştirin ve üretime gönderin (push). -. Asıl kullanıcı hikayenize geri dönün ve çalışmaya devam edin. +. Düzgün çalıştığını test ettikten sonra onarım dalını üretim dalıyla birleştirin ve üretime itin. +. Asıl iş paketinize geri dönün ve çalışmaya devam edin. [[_basic_branching]] -==== Kısaca Dallandırma (branching) +==== Dallandırma (((branches, basic workflow))) İlk olarak, projeniz üzerinde çalışıyorsunuz ve `master` dalında halihazırda birkaç katkınız var diyelim. @@ -25,7 +25,7 @@ Diyelim ki bu aşamada, başka bir sorunun daha kritik olduğuna ve acilen düze image::images/basic-branching-1.png[Basit bir katkı geçmişi.] #53 numaralı sorun (Ya da şirketinizin kullandığı iş takip sisteminde nasıl gösteriliyorsa) üzerinde çalışmaya karar verdiniz. -Yeni bir dal oluşturup aynı zamanda bu dala geçmek için `git checkout` komutunu `-b` bayrağı ile çalıştırabilirsiniz: +Yeni bir dal oluşturup aynı zamanda bu dala geçmek için `git checkout` komutunu `-b` (branch) bayrağı ile çalıştırabilirsiniz: [source,console] ---- @@ -60,7 +60,7 @@ image::images/basic-branching-3.png[`iss53` dalı siz çalıştıkça ilerler.] Git'te, ne yapmış olduğunuz `iss53` değişiklikleri ve onarımınızı birlikte yükleme zorunluluğunuz var, ne de bu değişiklikleri üretime uygulamadan önce geri almak için büyük çaba sarf etmenize. Yapmanız gereken tek şey, `master` dalınıza geri dönmektir. -Ancak bunu yapmadan önce, çalışma dizininiz veya aşamalandırmada (stage) henüz katkılanmamış değişiklikler varsa ve bu değişiklikler, geçiş yapmak istediğiniz dal ile çakışıyorsa, Git'in sizin dal değiştirmenize izin vermeyeceğini bilmeniz lazım. +Ancak bunu yapmadan önce, çalışma dizininiz veya izlemde (stage) henüz katkılanmamış değişiklikler varsa ve bu değişiklikler, geçiş yapmak istediğiniz dal ile çakışıyorsa, Git'in sizin dal değiştirmenize izin vermeyeceğini bilmeniz lazım. Dallar arasında geçiş yaparken temiz bir çalışma durumuna sahip olmak en iyisidir. Bu sorunun etrafından dolaşmanın tabi ki belli (`stashing` ve `commit amending` gibi) yolları var ama bunları <> bölümünde ele alacağız. Şu anda, tüm değişikliklerinizi katkıladığınızı varsayalım, böylece `master` dalına geri dönebilirsiniz: @@ -116,7 +116,7 @@ image::images/basic-branching-5.png[`master`, `hotfix`e doğru ileri sarıldı.] Bu süper önemli düzeltmeniz yüklendikten sonra, kesintiye uğradığınız çalışmaya geri dönmeye hazırsınız. Neticede `master` dalı da aynı yere işaret ettiği için, artık ihtiyacınız olmayan, `hotfix` dalını sileceksiniz. -Bu dalı `git branch` komutunun `-d` seçeneği ile silebilirsiniz: +Bu dalı `git branch` komutunun `-d` (delete) seçeneği ile silebilirsiniz: [source,console] ---- @@ -143,7 +143,7 @@ Burada `hotfix` dalında yaptığınız çalışmanın `iss53` dalındaki dosyal Eğer onu çekmeniz gerekiyorsa, `git merge master` komutunu çalıştırarak `master` dalını `iss53` dalına kaynaştırabilirsiniz, veya bu değişiklikleri birleştirmek için `iss53` dalını daha sonra `master` dalına çekmeye karar verene kadar bekleyebilirsiniz. [[_basic_merging]] -==== Kısaca Birleştirme (merging) +==== Birleştirme (((branches, merging)))(((merging))) Diyelimk ki #53 sorunu üzerindeki çalışmanızın tamamlandığına ve `master` dalına birleştirilmeye hazır olduğuna karar verdiniz. @@ -165,10 +165,10 @@ Mevcut durumda, geliştirme geçmişiniz eski bir katkıdan itibaren ayrılmış Çünkü üzerinde bulunduğunuz dalın son katkısı, birleştirmeye çalıştığınız dalın doğrudan önceli değilse, Git bazı işlemleri gerçekleştirmek zorundadır. Yukarıdaki senaryoda, Git bu iki dalın ortak öncelini ve her iki dal ucu tarafından işaret edilen iki farklı anlık görüntüyü kullanarak, üç yollu bir birleştirme yapar. -.Tipik bir birleştirmede kullanılan üç adet anlık görüntü -image::images/basic-merging-1.png[Tipik bir birleştirmede kullanılan üç adet anlık görüntü.] +.Tipik bir birleştirmede kullanılan üç poz +image::images/basic-merging-1.png[Tipik bir birleştirmede kullanılan üç poz.] -Sadece dal işaretçisini ileri taşımak yerine, Git, bu üç yollu birleştirmenin sonucu olan yeni bir anlık görüntü oluşturur ve otomatik olarak ona işaret eden yeni bir katkı oluşturur. +Sadece dal işaretçisini ileri taşımak yerine, Git, bu üç yollu birleştirmenin sonucu olan yeni bir poz oluşturur ve otomatik olarak ona işaret eden yeni bir katkı oluşturur. Buna birleştirme katkısı denir ve birden fazla üst dala sahip olması bakımından özeldir. .Bir birleştirme katkısı @@ -232,7 +232,7 @@ Dosyanız, aşağıdakine benzer bir bölüm içerir: >>>>>>> iss53:index.html ---- -Bunun anlamı: `=======` işaretinin üstündeki her şey `HEAD` (`merge` komutunu çalıştırdığınızda üzerinde bulunduğunuz dal yani bu senaryoda `master` dalı) içindeki versiyonu gösterirken, işaretin altındaki kısımların ise `iss53` dalı içindeki versiyonu gösterdiğidir. +Bunun anlamı: `=======` işaretinin üstündeki her şey `HEAD` (`merge` komutunu çalıştırdığınızda üzerinde bulunduğunuz dal yani bu senaryoda `master` dalı) içindeki sürümü gösterirken, işaretin altındaki kısımların ise `iss53` dalı içindeki sürümü gösterdiğidir. Çakışmayı çözmek için ya bir tarafı ya da diğerini seçmek yahut da içeriği kendiniz birleştirmek zorundasınız. Örneğin, bu çakışmayı aşağıdaki gibi tüm bloğu değiştirerek çözebilirsiniz: @@ -245,9 +245,9 @@ please contact us at email.support@github.com Bu çözüm, her iki bölümün birazını içerir ve `<<<<<<<`, `=======` ve `>>>>>>>` satırları tamamen kaldırılmıştır. Her bir çakışmış dosyanın her bir çakışmasını çözdükten sonra, her bir dosya üzerinde `git add` komutunu çalıştırarak onu çözülmüş olarak işaretleyin. -Dosyayı aşamalandırmaya (stage) koymak, Git'te çözülmüş olarak işaretler. +Dosyayı izleme almak, Git'te çözülmüş olarak işaretler. -Bu sorunları çözmek için grafiksel bir araç kullanmak istiyorsanız, `git mergetool` komutunu çalıştırabilirsiniz. Bu, uygun bir görsel birleştirme aracını başlatır ve çakışmaları çözme sürecinde sizi yönlendirir:(((git commands, mergetool))) +Bu sorunları çözmek için görsel bir araç kullanmak istiyorsanız, `git mergetool` komutunu çalıştırabilirsiniz. Bu, uygun bir görsel birleştirme aracını başlatır ve çakışmaları çözme sürecinde sizi yönlendirir:(((git commands, mergetool))) [source,console] ---- @@ -275,7 +275,7 @@ Karmaşık birleştirme çatışmalarını çözmek için daha gelişmiş araçl ==== Birleştirme aracından çıktıktan sonra, Git size birleştirmenin başarılı olup olmadığını sorar. -Eğer başarılı olduysa, dosyayı çatışması çözüldü olarak işaretlemek üzere aşamalandırmaya (stage) gönderir. +Eğer başarılı olduysa, dosyayı çatışması çözüldü olarak işaretlemek üzere izleme gönderir. Tüm çakışmaların çözüldüğünü doğrulamak için tekrar `git status` komutunu çalıştırabilirsiniz: [source,console] From 7dc4c9f238c4a2aa016fe4cdc898049a6fa37661 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 12:02:51 +0100 Subject: [PATCH 120/210] Update nutshell.asc --- book/03-git-branching/sections/nutshell.asc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 4d8563a7..3f178036 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -1,15 +1,15 @@ [[_git_branches_overview]] -=== Kısaca Dallar +=== Dallar Git'in dallanma yöntemini gerçekten anlamak için bir adım geriye çekilip Git'in verileri nasıl sakladığını incelememiz gerekiyor. <> bölümünden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _poz_ olarak saklar. -Git, bir katkı işlediğinizde (commit), aşamalandırdığınız (stage) içeriğin anlık görüntüsünün işaretçisi (pointer: bir katkı veya ağacın yerini gösteren işaretçi) içeren bir katkı nesnesi (object) saklar. +Git, bir katkı işlediğinizde, izleme (stage) aldığınız içeriğin pozunun işaretçisini içeren bir katkı nesnesi saklar. Bu nesne aynı zamanda yazarın adını ve e-posta adresini, katkı mesajını ve öncel katkı veya katkılara ilişkin işaretçileri içerir. İlk katkı (first commit) için sıfır; normal bir katkı için bir; ve birden fazla dalın birleşmesinden kaynaklanan bir katkı içinse çoklu öncel katkı bulunur. -Bunu görselleştirmek için, üç dosya içeren bir dizine sahip olduğumuzu ve bunların hepsini aşamalandırıp (stage) katkı olarak işlediğinizi varsayalım. -Dosyaları aşamalandırmak, her bir dosya için bir sağlama toplamı (checksum) hesaplar (<> bölümünde bahsettiğimiz SHA-1 karması), dosyanın bu sürümünü Git reposunda saklar (Git bunlara _blobs_ olarak atıfta bulunur)(Binary Large OBject: ikili geniş nesne), ve bu sağlama toplamını aşamalandırma alanına (stage) ekler: +Bunu görselleştirmek için, üç dosya içeren bir dizine sahip olduğumuzu ve bunların hepsini izleme alıp, katkı olarak işlediğinizi varsayalım. +Dosyaları izlemlemek, her bir dosya için bir sağlama toplamı (checksum) hesaplar (<> bölümünde bahsettiğimiz SHA-1 karması), dosyanın bu sürümünü Git reposunda saklar (Git bunlara _blobs_ olarak atıfta bulunur)(Binary Large OBject: ikilik geniş nesne), ve bu sağlama toplamını izlem alanına ekler: [source,console] ---- @@ -17,18 +17,18 @@ $ git add README test.rb LICENSE $ git commit -m 'The initial commit of my project' ---- -`git commit` komutunu çalıştırarak bir katkı oluşturduğunuzda, Git her alt dizinin (bu durumda sadece kök (root) proje dizini) doğrular (checksum) ve bunları Git reposunda bir ağaç nesnesi (tree object) olarak saklar. -Git daha sonra meta verileri ve kök proje ağacının işaretçisini içeren bir katkı nesnesi oluşturur. Böylece gerektiğinde anlık görüntüyü yeniden oluşturabilir.(((git commands, commit))) +`git commit` komutunu çalıştırarak bir katkı oluşturduğunuzda, Git her alt dizinin (bu durumda sadece kök (root) proje dizini) doğrular ve bunları Git reposunda bir ağaç nesnesi (tree object) olarak saklar. +Git daha sonra meta verileri ve kök proje ağacının işaretçisini içeren bir katkı nesnesi oluşturur. Böylece gerektiğinde pozu yeniden oluşturabilir.(((git commands, commit))) Git reponuz artık beş nesne içeriyor: - Her biri üç dosyadan birinin içeriğini temsil eden üç _blob_ - Dizinin içeriğini ve hangi dosya adlarının hangi _blob_ olarak depolandığını listeleyen bir _ağaç_ - - Kök ağacın işaretçisini ve tüm katkı metadata'sını içeren bir _katkı_ + - Kök ağacın işaretçisini ve tüm katkı metaverisini içeren bir _katkı_ .Bir katkı ve onun ağacı image::images/commit-and-tree.png[Bir katkı ve onun ağacı.] -Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz (git commit), sonraki katkı, kendinden hemen önceki katkıya işaret eden bir işaretçiyi depolar. +Eğer bazı değişiklikler yaparsanız ve tekrar katkı olarak işlerseniz, sonraki katkı, kendinden hemen önceki katkıya işaret eden bir işaretçiyi depolar. .Katkı ve öncel katkılar image::images/commits-and-parents.png[Katkı ve öncel katkılar.] @@ -180,7 +180,7 @@ Yeni bir dal oluşturmak, bir dosyaya 41 bayt yazmak kadar hızlı ve basittir ( Bu, yöntem olarak projenin tüm dosyalarını ikinci bir dizine yedeklemeyi seçen, çoğu eski VCS aracının kullandığı yolun kesin bir zıttıdır. Yedekleme yöntemi, projenin boyutuna bağlı olarak birkaç saniye veya hatta dakika bile sürebilir. Oysa Git'te katkı işlemi her zaman anlık olarak gerçekleşir. -Ayrıca, katkı işlerken öncel katkıları da kaydettiğimiz için, birleştirmek için uygun bir temel bulma işlemi otomatik olarak yapılır ve genellikle çok kolaydır. +Ayrıca, katkı işlerken öncel katkıları da kaydettiğimiz için, birleştirmek için uygun bir nokta bulma işlemi otomatik olarak yapılır ve genellikle çok kolaydır. Bu özellikler, geliştiricileri sık sık dallar oluşturmaları ve kullanmaları yönünde cesaretlendirir. Haydi, neden bunu yapmanız gerektiğini görelim. From 7c2840a55a4f55d351875bda6fabe116f169d206 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Tue, 5 Mar 2024 16:53:18 +0100 Subject: [PATCH 121/210] Update rebasing.asc --- book/03-git-branching/sections/rebasing.asc | 92 ++++++++++----------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index ed11193c..52779b53 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -1,10 +1,10 @@ [[_rebasing]] -=== Temelleme (rebase) +=== Yeniden Temelleme (rebase) (((rebasing))) -Git'te, bir dalın değişikliklerini diğerine birleştirmenin iki ana yolu vardır: `merge` (birleştirme) ve `rebase` (temelleme). Bu bölümde, temellemenin ne olduğunu, nasıl yapıldığını, neden oldukça etkili bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz. +Git'te, bir dalın değişikliklerini diğerine birleştirmenin iki ana yolu vardır: `merge` (birleştirme) ve `rebase` (yeniden temelleme). Bu bölümde, yeniden temellemenin ne olduğunu, nasıl yapıldığını, neden oldukça etkili bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz. -==== Basitçe Temelleme (rebase) +==== Kısaca Yeniden Temelleme Eğer önceki örneğe, <<_basic_merging>> başlıklı bölüme geri dönerseniz, işinizi dallandırdığınızı ve iki farklı dalda katkı işlediğinizi görebilirsiniz. @@ -19,7 +19,7 @@ Bu komut, iki dalın (`C3` ve `C4`) ve bunların en son ortak öncelinin (`C2`) image::images/basic-rebase-2.png[Ayrık çalışma geçmişini birleştirmek.] Ancak, başka bir yol daha vardır: `C4` ile tanıtılan değişikliğin yamasını alabilir ve bunu `C3` 'ün üzerine yeniden uygulayabilirsiniz. -Git'te buna _temel alma_ veya _temelleme_ (rebasing) denir. +Git'te buna _yeniden temelleme_ (rebasing) denir. `rebase` komutu ile bir dalda işlenmiş tüm değişiklikleri alabilir ve bunları farklı bir dala aktararak bir temel olarak kullanabilirsiniz.(((git commands, rebase))) Bu örnekte, `experiment` dalına geçer ve ardından onu şu şekilde `master` dalına aktarabilirsiniz: @@ -32,9 +32,9 @@ First, rewinding head to replay your work on top of it... Applying: added staged command ---- -Bu işlem, iki dalın (üzerinde bulunduğunuz dal ve temel aldığınız dal) ortak önceline gitmesiyle başlar. +Bu işlem, iki dalın (üzerinde bulunduğunuz dal ve yeniden temellediğiniz dal) ortak önceline gitmesiyle başlar. Ardından, üzerinde bulunduğunuz dalın her katkısının getirdiği farkı alır ve bu farkları geçici dosyalara kaydeder. -Mevcut dalı, üzerine temelleme yaptığınız dalın katkıları ile aynı katkıya sıfırlar ve son olarak her değişikliği sırayla uygular. +Mevcut dalı, üzerine yeniden temelleme yaptığınız dalın katkıları ile aynı katkıya sıfırlar ve son olarak her değişikliği sırayla uygular. .`C4` 'teki değişikliği `C3` üzerine temelleme image::images/basic-rebase-3.png[`C4` 'teki değişikliği `C3` üzerine temelleme.] @@ -51,20 +51,20 @@ $ git merge experiment image::images/basic-rebase-4.png[Master dalına ileri-sarma.] Şu anda, `C4'` tarafından işaret edilen poz, <> örneğinde `C5` tarafından işaret edilen poz ile tam olarak aynıdır. -Birleştirme çıktısında fark yoktur, ancak temelleme daha temiz bir geçmiş sunar. +Birleştirme çıktısında fark yoktur, ancak yeniden temelleme daha temiz bir geçmiş sunar. Eğer `git log` komutuyla temellenmiş bir dalın günlüğünü incelerseniz, doğrusal bir geçmiş görürsünüz. Başlangıçta eşzamanlı gerçekleşmiş olsa bile, tüm işin sırayla gerçekleştiği izlenimini verir. Çoğu zaman bunu, katkılarınızın temiz bir şekilde bir uzak dala uygulanmasını sağlamak için yaparsınız, belki de bir süre üzerinde çalıştığınız ancak sürdürmediğiniz bir projede. -Bu durumda, işinizi bir dalda yapar ve yamalarınızı ana projeye göndermeye hazır olduğunuzda işinizi `origin/master` üzerine temellersiniz. +Bu durumda, işinizi bir dalda yapar ve yamalarınızı ana projeye göndermeye hazır olduğunuzda işinizi `origin/master` üzerine yeniden temellersiniz. Bu şekilde, bakım yapan kişinin herhangi bir birleştirme çalışması yapmasına gerek kalmaz - sadece bir ileri-sarma veya temiz bir uygulama yapması yeterlidir. -Unutmayın ki, bu işlem sonunda elde ettiğiniz poz, ister bir temelleme işlemi için alınmış son temelleme katkısı, isterse birleştirme işlemi sonrası elde ettiğiniz son birleştirme katkısı olsun, aynı pozdur - farklı olan sadece tarihtir. -"Temelleme" (rebase) değişiklikleri tanımlandıkları sırayla bir iş çizgisinden başka bir iş çizgisine aktarırken, "birleştirme" (merge) uç noktaları alır ve bunları birleştirir. +Unutmayın ki, bu işlem sonunda elde ettiğiniz poz, ister bir yeniden temelleme işlemi için alınmış son temelleme katkısı, isterse birleştirme işlemi sonrası elde ettiğiniz son birleştirme katkısı olsun, aynı pozdur - farklı olan sadece tarihtir. +"Yeniden Temelleme" değişiklikleri tanımlandıkları sırayla bir iş çizgisinden başka bir iş çizgisine aktarırken, "birleşim" uç noktaları alır ve bunları birleştirir. -==== Daha Detaylıca Temelleme +==== Daha Detaylıca Yeniden Temelleme -Temelleme işlemi için hedef aldığınız dal dışında bir dala da temellemenizi uygulayabilirsiniz. +Yeniden temelleme işlemi için hedef aldığınız dal dışında bir dala da temellemenizi uygulayabilirsiniz. Mesela <> şeklindeki bir tarihçeyi ele alalım: Projeye sunucu tarafı işlevselliği eklemek için `server` adında tematik bir dal oluşturdunuz ve bir katkı işlediniz. Ardından, istemci tarafındaki değişiklikleri yapmak için bu daldan ayrılıp `client` dalında birkaç katkı işlediniz. @@ -75,18 +75,18 @@ Son olarak, sunucu dalına geri dönüp birkaç katkı daha işlediniz. image::images/interesting-rebase-1.png[Bir tematik daldan ayrılan başka bir tematik dalın geçmişi.] Diyelim ki, bir sürüm için kullanıcı tarafındaki değişiklikleri ana dalınıza birleştirmeye karar verdiniz, ancak sunucu tarafındaki değişiklikleri daha fazla test edilene kadar bekletmek istiyorsunuz. -Bu durumda, sunucu tarafında olmayıp (`C8` and `C9`) kullanıcı tarafında olan değişiklikleri alabilir ve onları `git rebase` komutunun `--onto` seçeneğini kullanarak `master` dalınıza temelleyebilirsiniz: +Bu durumda, sunucu tarafında olmayıp (`C8` and `C9`) kullanıcı tarafında olan değişiklikleri alabilir ve onları `git rebase` komutunun `--onto` seçeneğini kullanarak `master` dalınıza yeniden temelleyebilirsiniz: [source,console] ---- $ git rebase --onto master server client ---- -Bu temel olarak şunu ifade eder: "`client` dalını al, bu dalın `server` dalından ayrıldığından bu yana yapılan yamaları belirle ve bu yamaları `client` dalında, sanki doğrudan `master` dalından temellenmiş gibi temelle." +Bu temel olarak şunu ifade eder: "`client` dalını al, bu dalın `server` dalından ayrıldığından bu yana yapılan yamaları belirle ve bu yamaları `client` dalında, sanki doğrudan `master` dalından temellenmiş gibi yeniden temelle." Biraz karmaşık gibi görünebilir, ancak sonuç oldukça etkileyicidir. -.Tematik bir daldan yeni bir tematik dal temelleme -image::images/interesting-rebase-2.png[Tematik bir daldan yeni bir tematik dal temelleme.] +.Tematik bir daldan yeni bir tematik dala yeniden temelleme +image::images/interesting-rebase-2.png[Tematik bir daldan yeni bir tematik dala yeniden temelleme.] Artık `master` dalınızı ileri sarabilirsiniz (bkz. <>): @@ -102,20 +102,20 @@ image::images/interesting-rebase-3.png[`master` dalını `client` dalındaki de Diyelim ki sunucu dalını da eklemeye karar verdiniz. `git rebase ` komutunu çalıştırarak, öncesinde dalınızı değiştirmeden, sunucu dalını `master` dalına tekrar temelleyebilirsiniz. -Bu komut, ilgili tema dalına (burada `server`) geçiş yapar ve onu temel dal üzerine (burada `master`) temeller. +Bu komut, ilgili tema dalına (burada `server`) geçiş yapar ve onu ana dal üzerine (burada `master`) yeniden temeller. [source,console] ---- $ git rebase master server ---- -Bu, <> diyagramında gösterildiği gibi `server` çalışmanızı `master` çalışmanızın üzerine temeller. +Bu, <> diyagramında gösterildiği gibi `server` çalışmanızı `master` çalışmanızın üzerine yeniden temeller. [[rbdiag_h]] -.`server` dalını `master` dalının üzerine temelleme -image::images/interesting-rebase-4.png[`server` dalını `master` dalının üzerine temelleme.] +.`server` dalını `master` dalının üzerine yeniden temelleme +image::images/interesting-rebase-4.png[`server` dalını `master` dalının üzerine yeniden temelleme.] -Ardından, temel dalınıza (`master`) ileri sarabilirsiniz: +Ardından, ana dalınıza (`master`) ileri sarabilirsiniz: [source,console] ---- @@ -136,21 +136,21 @@ $ git branch -d server image::images/interesting-rebase-5.png[Nihai katkı geçmişi.] [[_rebase_peril]] -==== Temellemenin Riskleri +==== Yeniden Temellemenin Riskleri (((rebasing, perils of))) -Temelleme getirdiği kolaylıkların yanında malesef bazı dezavantajları da içerir. +Yeniden temelleme getirdiği kolaylıkların yanında malesef bazı dezavantajları da içerir. Bu riskleri tek cümlede özetlemek mümkündür: -*Repo dışında var olan ve üzerine çalışılmış olabilecek katkıları temellemeyin.* +*Repo dışında var olan ve üzerine çalışılmış olabilecek katkıları yeniden temellemeyin.* Eğer bu kılavuzu takip ederseniz, sorun yaşamazsınız. Ama anlatacağımız yönergelere uymazsanız, insanlar sizi sevmeyecek; dostlarınız ve aileniz tarafından hor görüleceksiniz. -Birşeyleri temellediğinizde (rebase), mevcut katkıları (commit) terk ediyor ve benzer ancak farklı olan yeni katkılar oluşturuyorsunuz. -Eğer katkılarınızı bir yere iterseniz (push) ve başkaları bunları çekip (pull), üzerine çalışma yaparsa, ve daha sonra bu katkıları `git rebase` ile değiştirip tekrar iterseniz, çalışma arkadaşlarınız kendi çalışmalarını tekrar birleştirmek (merge) zorunda kalacak ve onların çalışmalarını kendi projenize çekmeye çalıştığınızda bir karışıklık ortaya çıkacaktır. +Birşeyleri yeniden temellediğinizde, mevcut katkıları terk ediyor ve benzer ancak farklı olan yeni katkılar oluşturuyorsunuz. +Eğer katkılarınızı bir yere iterseniz ve başkaları bunları çekip), üzerine çalışma yaparsa, ve daha sonra bu katkıları `git rebase` ile değiştirip tekrar iterseniz, çalışma arkadaşlarınız kendi çalışmalarını tekrar birleştirmek zorunda kalacak ve onların çalışmalarını kendi projenize çekmeye çalıştığınızda bir karışıklık ortaya çıkacaktır. -Herkese açık bir şekilde yayımladığınız çalışmayı temellemenin nasıl sorunlara yol açabileceğine dair bir örneğe bakalım. +Herkese açık bir şekilde yayımladığınız çalışmayı yeniden temellemenin nasıl sorunlara yol açabileceğine dair bir örneğe bakalım. Merkezi bir sunucudan bir repo kopyaladığınızı ve ardından biraz çalışma yaptığınızı düşünelim. katkı geçmişiniz şu şekilde görünüyor: @@ -163,13 +163,13 @@ Siz bunu çeker ve yeni uzak dalı kendi çalışmanıza birleştirirsiniz, geç .Daha fazla katkı getir ve onları kendi çalışmana birleştir image::images/perils-of-rebasing-2.png["Daha fazla katkı getir ve onları kendi çalışmana birleştir."] -Ardından, birleştirilmiş çalışmayı iten kişi, bunun yerine, geriye gidip çalışmaya temelleme yapmaya karar verir. +Ardından, birleştirilmiş çalışmayı iten kişi, bunun yerine, geriye gidip çalışmaya yeniden temellemeye karar verir. Bunun için `git push --force` kullanarak sunucudaki geçmişin üzerine yazar. Siz de bu sunucudan çekerseniz, yeni katkıları getirirsiniz. [[_pre_merge_rebase_work]] -.Birisi çalışmanıza temellediğiniz katkıları terkedip, temellenmiş katkıları iter -image::images/perils-of-rebasing-3.png["Birisi çalışmanıza temellediğiniz katkıları terkedip, temellenmiş katkıları iter."] +.Birisi çalışmanıza temellediğiniz katkıları terkedip, yeniden temellenmiş katkıları iter +image::images/perils-of-rebasing-3.png["Birisi çalışmanıza temellediğiniz katkıları terkedip, yeniden temellenmiş katkıları iter."] Şimdi her ikiniz de çıkmazdasınız. Eğer bir `git pull` yaparsanız, her iki geçmiş çizgisini de içeren birleştirme katkısı oluşturursunuz ve repo şu şekilde görünecektir: @@ -179,21 +179,21 @@ Eğer bir `git pull` yaparsanız, her iki geçmiş çizgisini de içeren birleş image::images/perils-of-rebasing-4.png[Aynı çalışmayı tekrar yeni bir birleştirme katkısına dahil edersiniz.] Eğer geçmişiniz bu şekilde göründüğünde bir `git log` komutu çalıştırırsanız; aynı yazar, tarih ve mesajı taşıyan iki katkı göreceksiniz ki bu da kafa karıştırıcı olacaktır. -Dahası, eğer bu geçmişi tekrar sunucuya iterseniz, tüm bu temellenmiş katkıları merkezi sunucuya tekrar eklemiş olursunuz ki bu insanların kafasını daha da karıştırabilir. -Diğer geliştiricinin (en başta temelleme yaptığı için), `C4` ve `C6`'nın geçmişte olmasını istemediğini varsayabiliriz. +Dahası, eğer bu geçmişi tekrar sunucuya iterseniz, tüm bu yeniden temellenmiş katkıları merkezi sunucuya tekrar eklemiş olursunuz ki bu insanların kafasını daha da karıştırabilir. +Diğer geliştiricinin (en başta yeniden temelleme yaptığı için), `C4` ve `C6`'nın geçmişte olmasını istemediğini varsayabiliriz. [[_rebase_rebase]] -==== Temelleme Yaparken Dikkat Edilmesi Gerekenler +==== Yeniden Temelleme Yaparken Dikkat Edilmesi Gerekenler Eğer kendinizi böyle bir durumda bulunursanız, Git size yardımcı olabilecek bazı ek özellikler sunar. -Eğer takımınızdaki birisi, temellediğiniz bir işin üzerine yazan değişiklikleri zorla iterse (force push), karşılaşacağınız gerçek sorun hangi kodun size ait olduğu ve hangisinin üzerine yeniden yazılan olduğunu bulmaktır. +Eğer takımınızdaki birisi, yeniden temellediğiniz bir işin üzerine yazan değişiklikleri zorla iterse (force push), karşılaşacağınız gerçek sorun hangi kodun size ait olduğu ve hangisinin üzerine yeniden yazılan olduğunu bulmaktır. Git, katkının SHA-1 sağlamasına ek olarak, yalnızca katkı ile tanıtılan yamaya dayalı bir sağlama da hesaplar. Buna ``patch-id`` denir. -Eğer üzerine yeniden yazılan işi çekerseniz ve bu işi meslektaşınızın yeni katkıları üzerine temellerseniz; Git genellikle sizin çalışmanızın hangisi olduğunu başarılı bir şekilde bulabilir ve bunları yeni dalın üzerine uygulayabilir. +Eğer üzerine yeniden yazılan işi çekerseniz ve bu işi meslektaşınızın yeni katkıları üzerine yeniden temellerseniz; Git genellikle sizin çalışmanızın hangisi olduğunu başarılı bir şekilde bulabilir ve bunları yeni dalın üzerine uygulayabilir. -Örneğin, önceki senaryoda, <<_pre_merge_rebase_work>> noktasındayken birleştirme (merge) yerine `git rebase teamone/master` komutunu çalıştırırsak, Git şunları yapacaktır: +Örneğin, önceki senaryoda, <<_pre_merge_rebase_work>> noktasındayken birleştirme yerine `git rebase teamone/master` komutunu çalıştırırsak, Git şunları yapacaktır: * Dalımıza özgü işleri belirle (C2, C3, C4, C6, C7) * Hangilerinin birleştirme katkısı olmadığını belirle (C2, C3, C4) @@ -203,27 +203,27 @@ Eğer üzerine yeniden yazılan işi çekerseniz ve bu işi meslektaşınızın Bu durumda, <<_merge_rebase_work>> görüntüsündeki sonuç yerine, daha ziyade <<_rebase_rebase_work>> benzeri bir sonuç elde ederiz. [[_rebase_rebase_work]] -.Zorla itilmiş temelleme (force-push rebase) üzerine temelleme -image::images/perils-of-rebasing-5.png[Zorla itilmiş temelleme üzerine temelleme] +.Zorla itilmiş yeniden temelleme (force-push rebase) üzerine temelleme +image::images/perils-of-rebasing-5.png[Zorla itilmiş yeniden temelleme üzerine temelleme] Bu sadece meslektaşınızın yaptığı C4 ve C4' katkılarının neredeyse tamamen aynı yama olması durumunda çalışır. -Aksi takdirde, temelleme bunun bir kopya olduğunu anlayamaz ve başka bir C4 benzeri yama ekler (değişiklikler zaten en azından bir dereceye kadar mevcut olacağı için, bu muhtemelen düzgün bir şekilde uygulanamaz). +Aksi takdirde, yeniden temelleme bunun bir kopya olduğunu anlayamaz ve başka bir C4 benzeri yama ekler (değişiklikler zaten en azından bir dereceye kadar mevcut olacağı için, bu muhtemelen düzgün bir şekilde uygulanamaz). Bunu normal bir `git pull` yerine `git pull --rebase` komutunu çalıştırarak daha da basitleştirebilirsiniz. Veya bu durumda bir `git fetch` ve ardından `git rebase teamone/master` komutu kullanarak manuel olarak da gerçekleştirebilirsiniz. Eğer `git pull` kullanıyorsanız ve `--rebase` varsayılan olsun istiyorsanız, `git config --global pull.rebase true` gibi bir komutla `pull.rebase` yapılandırmasını ayarlayabilirsiniz. -Eğer sadece kendi bilgisayarınızdan hiç ayrılmamış katkıları temelliyorsanız, sorun yaşamazsınız. -Eğer itilmiş ancak kimsenin bunlardan temellemediği katkıları temelliyorsanız, yine sorun yaşamazsınız. +Eğer sadece kendi bilgisayarınızdan hiç ayrılmamış katkıları yeniden temelliyorsanız, sorun yaşamazsınız. +Eğer itilmiş ancak kimsenin bunlardan temellemediği katkıları yeniden temelliyorsanız, yine sorun yaşamazsınız. Ancak eğer zaten herkese açık bir şekilde itilmiş ve birileri bu katkılardan temelleme yapmışsa, o zaman sıkıntılı bir durumla karşılaşabilir ve takım arkadaşlarınızın tepkisini çekebilirsiniz. Eğer siz veya bir meslektaşınız bunu gerekli görürse, bu sıkıntıyı biraz daha basitleştirmeye çalışmak için, herkesin `git pull --rebase` komutunu çalıştırmayı bildiğinden emin olun. -==== Temelleme (rebase) ve Birleştirme (merge) +==== Yeniden Temelleme ve Birleştirme (((rebasing, vs. merging)))(((merging, vs. rebasing))) -Temelleme ve birleştirmeyi öğrendiğinize göre hangisinin daha iyi olduğunu merak ediyor olabilirsiniz. +Yeniden temelleme ve birleştirmeyi öğrendiğinize göre hangisinin daha iyi olduğunu merak ediyor olabilirsiniz. Bunu yanıtlayabilmek için biraz geriye gitmek ve geçmişin ne anlama geldiğini konuşmak gerekiyor. Bu konudaki bir bakış açısı, repo katkı geçmişinin *aslında nelerin gerçekleştiğinin bir kaydı* olduğudur. @@ -235,10 +235,10 @@ Yani karışık bir dizi birleştirme katkısı varsa ne olmuş ki? Karşıt bakış açısı, katkı geçmişinin *projenizin nasıl yapıldığını anlatan bir hikaye* olduğudur. Bir kitabın ilk taslağını yayımlamazsınız ve yazılımınızı nasıl sürdüreceğiniz konusundaki kılavuz, dikkatli bir düzenlemeyi hak eder. -Bu görüştekiler "temelleme" ve "dal filtreleme" gibi araçları kullanarak hikayeyi gelecekteki okuyucular için en iyi şekilde anlatan kişilerdir. +Bu görüştekiler "yeniden temelleme" ve "dal filtreleme" gibi araçları kullanarak hikayeyi gelecekteki okuyucular için en iyi şekilde anlatan kişilerdir. -Şimdi, birleştirmenin mi yoksa temellemenin mi daha iyi olduğu sorusuna gelince: bunun o kadar da basit bir soru olmadığını anladığınızı ümidediyorum. +Şimdi, birleştirmenin mi yoksa yeniden temellemenin mi daha iyi olduğu sorusuna gelince: bunun o kadar da basit bir soru olmadığını anladığınızı ümidediyorum. Git geçmişinizle ilgili birçok şey yapmanıza izin veren güçlü bir araçtır, ancak her ekip ve her proje de farklıdır. Her iki işlemin de nasıl çalıştığını bildiğinize göre, hangisinin sizin özel durumunuz için en iyi olduğuna siz karar vereceksiniz. -Genel olarak, her iki yaklaşımdan da en iyi şekilde faydalanmanın yolu, henüz paylaşmadığınız yerel değişiklikleri itmeden önce temelleme yaparak geçmişi temizlemektir, ancak herhangi bir sunucuya ittiğiniz bir şeyi asla temelleme yapmamaktır. +Genel olarak, her iki yaklaşımdan da en iyi şekilde faydalanmanın yolu, henüz paylaşmadığınız yerel değişiklikleri itmeden önce yeniden temelleme yaparak geçmişi temizlemektir, ancak herhangi bir sunucuya ittiğiniz bir şeyi asla yeniden temelleme yapmamaktır. From 51b44ddc97a1de7b07036c5c8c4f8ac71f02619c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 07:57:22 +0100 Subject: [PATCH 122/210] Update remote-branches.asc --- .../sections/remote-branches.asc | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 4b81cee8..d665730f 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -2,7 +2,7 @@ === Uzak Dallar (((branches, remote)))(((references, remote))) -Uzak işaretçiler, uzak repolarınızdaki dalları, etiketleri ve benzerlerini içeren işaretçilerdir. +Uzak işaretçiler, uzak repolarınızdaki dalları, etiketleri ve benzerlerini içeren referanslardır. `git ls-remote [remote]` veya `git remote show [remote]` komutları ile uzak işaretçilerin tam listesini alabilir ve daha fazla bilgi edinebilirsiniz. Daha yaygın bir yöntem ise uzak izleme dallarından yararlanmaktır. @@ -33,7 +33,7 @@ Eğer `git clone -o booyah` şeklinde bir komut çalıştırırsanız, o zaman v .Kopyalamamadan sonra sunucu ve yerel repolar image::images/remote-branches-1.png[Kopyalamamadan sonra sunucu ve yerel repolar.] -Eğer yerel `master` dalında çalışıyorsanız ve aynı zamanda başka birisi `git.ourcompany.com` üzerine bir değişiklik itiyorsa (push), kendi `master` dalını güncelledikce, geçmişleriniz farklı yönlere ilerler. +Eğer yerel `master` dalında çalışıyorsanız ve aynı zamanda başka birisi `git.ourcompany.com` üzerine bir değişiklik itiyorsa, kendi `master` dalını güncelledikce, geçmişleriniz farklı yönlere ilerler. Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/master` işaretçisi yer değiştirmez. @@ -41,16 +41,16 @@ Ayrıca, kendi origin sunucunuzla iletişimde olmadığınız sürece, `origin/m image::images/remote-branches-2.png[Yerel ve uzak çalışma farklılaşabilir.] Belirli bir uzak repo ile çalışmanızı eşzamanlamak (synchronize) için `git fetch ` komutunu çalıştırırsınız (bizim durumumuzda, `git fetch origin`). -Bu komut, `origin` 'in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri getirir (fetch), yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. +Bu komut, `origin` 'in hangi sunucuda olduğuna (bu durumda, `git.ourcompany.com`) bakar, henüz alınmayan verileri getirir, yerel veritabanınızı günceller ve `origin/master` işaretçisini yeni ve daha güncel konumuna taşır. .`git fetch` uzak takip dallarınızı günceller image::images/remote-branches-3.png[`git fetch` zak takip dallarınızı günceller.] -Çoklu uzak sunuculara sahip olmanın ve bu uzak projelerin uzak dallarının nasıl göründüğünü anlamak için, şu hayali senaryoya başvuralım: Diyelim ki sadece çevik takımlarınızdan birisi tarafından geliştirme amaçlı kullanılan başka bir iç Git sunucunuz var ve bu sunucu `git.team1.ourcompany.com` adresinde bulunmaktadır. +Çoklu uzak sunuculara sahip olmanın ve bu uzak projelerin uzak dallarının nasıl göründüğünü anlamak için, şu hayali senaryoya başvuralım: Diyelim ki sadece çevik (agile) takımlarınızdan birisi tarafından geliştirme amaçlı kullanılan başka bir iç Git sunucunuz var ve bu sunucu `git.team1.ourcompany.com` adresinde bulunmaktadır. Bunu şu an üzerinde çalıştığınız projeye <> bölümünde ele aldığımız gibi `git remote add` komutu ile yeni bir uzak işaretçi olarak ekleyebilirsiniz. Bu uzak sunucuyu kısaca `teamone` olarak adlandırın. -.Başka bir sunucuyu uzak (remote) olarak eklemek +.Başka bir sunucuyu uzak olarak eklemek image::images/remote-branches-4.png[Başka bir sunucuyu uzak olarak eklemek.] Şimdi, `git fetch teamone` komutunu çalıştırarak, henüz sahip olmadığınız tüm verileri uzak `teamone` sunucusundan getirebilirsiniz. @@ -60,10 +60,10 @@ Bu sunucu şu anda `origin` sunucunuzun sahip olduğu verilerin bir alt kümesin image::images/remote-branches-5.png[`teamone/master` için uzak takip dalı.] [[_pushing_branches]] -==== İtme (pushing) +==== İtme (((pushing))) -Bir dalı dünyayla paylaşmak istediğinizde, yazma erişimine sahip olduğunuz bir uzak sunucuya itmeniz (push) gerekiyor. +Bir dalı dünyayla paylaşmak istediğinizde, yazma erişimine sahip olduğunuz bir uzak sunucuya itmeniz gerekiyor. Yerel dallarınız, yazma işlemi yapabileceğiniz uzak sunuculara otomatik olarak eşzamanlandırılmaz; paylaşmak istediğiniz dalları açıkça itmeniz gerekir. Bu şekilde, paylaşmak istemediğiniz işler için özel (private) dallar kullanabilir ve yalnızca işbirliği yapmak istediğiniz tematik dalları itebilirsiniz. @@ -94,11 +94,11 @@ Eğer uzakta `serverfix` olarak adlandırılmış bir dal istemiyorsanız, bunun [NOT] .Her defasında şifrenizi yazmayın ==== -Eğer bir HTTPS URL'si kullanarak itme (push) işlemi yapıyorsanız, Git sunucusu sizden kimlik doğrulaması için kullanıcı adı ve şifrenizi isteyecektir. +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. Varsayılan olarak, Git bu bilgileri size terminal üzerinden sorması için bir istekte bulunur. Böylece sunucu itmeye izin verip vermediğinizi kontrol edebilir. -Her itme (push) işlemi yaparken bunu her seferinde yazmak istemiyorsanız, bir 'credential cache' (kimlik bilgisi önbelleği) kurabilirsiniz. En basit olanı, bunu birkaç dakika boyunca bellekte tutmaktır ve bunu kolayca `git config --global credential.helper cache` komutunu çalıştırarak yapabilirsiniz. +Her itme işlemi yaparken bunu her seferinde yazmak istemiyorsanız, bir 'credential cache' (kimlik bilgisi önbelleği) kurabilirsiniz. En basit olanı, bunu birkaç dakika boyunca bellekte tutmaktır ve bunu kolayca `git config --global credential.helper cache` komutunu çalıştırarak yapabilirsiniz. Çeşitli kimlik bilgisi önbelleği seçenekleri hakkında daha fazla bilgi için <> bölümüne bakabilirsiniz. @@ -136,7 +136,7 @@ Böylelikle, `origin/serverfix`'in başladığı yerden devam eden ve üzerinde ==== Dalları Takip (((branches, tracking)))(((branches, upstream))) -Bir uzak takip dalından yerel bir dala geçmek, otomatik olarak bir 'takip dalı' (tracking branch) oluşturur (ve takip ettiği dal 'üst-akım dalı' (upstream branch) olarak adlandırılır). +Bir uzak takip dalından yerel bir dala geçmek, otomatik olarak bir 'takip dalı' oluşturur (ve takip ettiği dal 'üst-akım dalı' (upstream branch) olarak adlandırılır). Takip eden dallar, bir uzak dal ile doğrudan ilişkisi olan yerel dallardır. Bir takip dalındaysanız ve `git pull` yazarsanız, Git otomatik olarak hangi sunucudan getirileceğini ve hangi dalın birleştirileceğini bilir. @@ -184,7 +184,7 @@ Branch serverfix set up to track remote branch serverfix from origin. [NOT] .Üstakım (upstream) kısayolu ==== -Eğer kurulu bir takip dalınız varsa, onun yukarı akış dalını `@{upstream}` veya `@{u}` kısaltmasıyla işaretleyebilirsiniz. +Eğer kurulu bir takip dalınız varsa, onun üst-akım dalını `@{upstream}` veya `@{u}` kısaltmasıyla işaretleyebilirsiniz. Yani eğer `master` dalındaysanız ve bu dal `origin/master` 'ı takip ediyorsa, isterseniz `git merge origin/master` yerine `git merge @{u}` gibi bir şey söyleyebilirsiniz.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== @@ -217,7 +217,7 @@ Bunu şu şekilde yapabilirsiniz: $ git fetch --all; git branch -vv ---- -==== Çekme (pulling) +==== Çekme (((pulling))) `git fetch` komutu, henüz sahip olmadığınız sunucudaki tüm değişiklikleri getirir, ancak çalışma dizininizi hiç değiştirmez. From 9a783136d199c67025388c4f2b4226a9968778c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 07:57:54 +0100 Subject: [PATCH 123/210] Update summary.asc --- book/03-git-branching/sections/summary.asc | 6 ------ 1 file changed, 6 deletions(-) diff --git a/book/03-git-branching/sections/summary.asc b/book/03-git-branching/sections/summary.asc index 33f9195b..8b137891 100644 --- a/book/03-git-branching/sections/summary.asc +++ b/book/03-git-branching/sections/summary.asc @@ -1,7 +1 @@ -[[_git_branching_summary]] -=== Özet -Git'te temel dal oluşturma ve birleştirme konularını ele aldık. -Artık yeni dallar oluşturmak, dallar arasında geçiş yapmak ve yerel dalları birleştirmek konularında kendinizi rahat hissediyor olmalısınız. -Ayrıca, dallarınızı paylaşabilir ve bunları paylaşılan bir sunucuya iterek başkalarıyla çalışabilir, dallarınızı paylaşılmadan önce temelleyebilirsiniz. -Sırada, kendi Git repo barındırma sunucunuzu çalıştırmak için neleri bilmeniz gerektiğini ele alacağız. From 269b20a1da5d08569e7234fd48b9eb35243bd3d0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 07:58:14 +0100 Subject: [PATCH 124/210] Delete book/03-git-branching/sections/summary.asc --- book/03-git-branching/sections/summary.asc | 1 - 1 file changed, 1 deletion(-) delete mode 100644 book/03-git-branching/sections/summary.asc diff --git a/book/03-git-branching/sections/summary.asc b/book/03-git-branching/sections/summary.asc deleted file mode 100644 index 8b137891..00000000 --- a/book/03-git-branching/sections/summary.asc +++ /dev/null @@ -1 +0,0 @@ - From 31905ab04e4ea1989d08f9d40c87a9dc34f564f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:05:42 +0100 Subject: [PATCH 125/210] Update workflows.asc --- book/03-git-branching/sections/workflows.asc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index d2169221..b57f05da 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,6 +1,6 @@ === İş Akışı Dallandırması -Artık dallandırma ve birleştirmenin temellerini öğrendiğinize göre bunları ne yapabilirsiniz? +Artık dallandırma ve birleştirmenin temellerini öğrendiğinize göre bunlarla ne yapabilirsiniz? Bu bölümde, bu hafif dallandırma ile mümkün olan bazı yaygın iş akışlarını ele alacağız, böylece bunları kendi geliştirme döngünüze dahil edip etmek istemediğinize karar verebilirsiniz. ==== Uzun Ömürlü (long-running) Dallar @@ -12,7 +12,7 @@ Bu, her zaman açık olan ve geliştirme döngünüzün farklı aşamalarında k Birçok Git geliştiricisi, bu yaklaşımı benimseyen bir iş akışına sahiptir. Örneğin, `master` dallarında hatasız çalışan (muhtemelen yayımlanmış veya yayımlanacak) dengeli (stabil) kodu bulundurabilirler. Bunun yanında üzerinde çalışmak veya düzgün çalıştığını test etmek amacıyla `develop` veya `next` adında başka bir paralel dalları daha vardır. Bunların her zaman dengeli olması gerekmez, ancak kararlı (hatasız çalışan) bir duruma geldiğinde `master` dalına birleştirilebilir. -Bu dal, daha altta yer alan konu dallarını (önceki `iss53` dalı gibi kısa ömürlü dalları) içeri çekmek için kullanılır; hazır olduklarında yani tüm testleri geçip hata vermediklerinde ana dala (master) birleştirilir. +Bu dal, daha altta yer alan konu dallarını (önceki `iss53` dalı gibi kısa ömürlü dalları) içeri çekmek için kullanılır; hazır olduklarında yani tüm testleri geçip hata vermediklerinde ana dala (master veya main) birleştirilir. Aslında bahsettiğimiz şey, işlediğiniz katkı çizgisinde yukarı yönlü hareket eden işaretçilerdir. Dengeli dallar, katkı geçmişinizde daha aşağıda yer alırken, en güncel dallar geçmişin daha yukarısındadır. @@ -28,20 +28,20 @@ image::images/lr-branches-2.png[dengeli-ilerleme (progressive-stability) yaklaş Bu yaklaşımı farklı denge seviyelerinde sürdürebilirsiniz. Bazı büyük projeler, henüz `next` veya `master` dallarına bütünleşmeye hazır olmayan birleşik dalları içeren bir `proposed` veya `pu` (proposed updates) dalına sahiptir. -Temel fikir, dallarınızın çeşitli denge (stability) düzeylerinde olmasıdır; daha kararlı (hatasız çalışan) bir düzeye ulaştıklarında, bir üstlerindeki dala birleştirilirler. +Temel fikir, dallarınızın çeşitli denge düzeylerinde olmasıdır; daha kararlı bir düzeye ulaştıklarında, bir üstlerindeki dala birleştirilirler. Tekrar belirtmek gerekirse, birden çok uzun ömürlü dala sahip olmak zorunlu değildir, ancak özellikle çok büyük veya karmaşık projelerle uğraşılıyorsa genellikle faydalı olur. [[_topic_branch]] -==== Tematik Dallar (topic branch) +==== Tematik Dallar (((branches, topic))) -Ancak, tematik dallar herhangi bir boyuttaki projelerde faydalıdır. +Ancak, tematik dallar (topic branch) herhangi bir boyuttaki projelerde faydalıdır. Bir tematik dal, yalnızca belirli bir özellik veya ilgili çalışma için oluşturduğunuz kısa ömürlü bir şubedir. Bu genellikle dalı oluşturmak ve birleştirmek çok maliyetli olduğu için bir sürüm kontrol sistemiyle daha önce muhtemelen yapmadığınız bir şeydir. Ancak Git'te bir günde birkaç kez dal oluşturmak, üzerinde çalışmak, birleştirmek ve silmek yaygındır. Bunu, oluşturduğunuz `iss53` ve `hotfix` dalları ile bir önceki bölümde gördünüz. -Bu dallarda birkaç katkı işlediniz ve onları ana dalınıza (master) birleştirdikten hemen sonra sildiniz. +Bu dallarda birkaç katkı işlediniz ve onları ana dalınıza birleştirdikten hemen sonra sildiniz. Bu teknik, hızlı ve tam bir bağlam değişimi sağlar. Çünkü çalışmanız, tüm değişikliklerin o konuyla ilgili olduğu dallara ayrılmış durumda, böylece kod incelemesi ve benzeri durumlarda neler olduğunu görmek daha kolaydır. Değişiklikleri orada dakikalarca, günlerce veya aylarca tutabilir ve hazır olduklarında (oluşturuldukları veya üzerinde çalışıldıkları sıraya bakılmaksızın) birleştirebilirsiniz. From 8dd192407d159663bba2717e7e58c60f9c58ec15 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:12:02 +0100 Subject: [PATCH 126/210] Update git-on-a-server.asc --- book/04-git-server/sections/git-on-a-server.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) 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 e3cc034d..b247aaeb 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -6,13 +6,13 @@ [NOT] ==== 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ı (production) 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. +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. ==== -Herhangi bir Git sunucusunu başlangıçta kurabilmek için mevcut bir repoyu yeni bir çıplak repo olmak üzere (çalışma dizini içermeyen bir repo) dışa aktarmanız gerekir. +Herhangi bir Git sunucusunu başlangıçta kurabilmek için mevcut bir repoyu yeni bir yalın repo (bare repository) olmak üzere (çalışma dizini içermeyen bir repo) dışa aktarmanız gerekir. Bunu yapmak oldukça basittir. -Yeni bir çıplak repo oluşturmak üzere reponuzu kopyalamak için kopyalama komutunu `--bare` seçeneği ile çalıştırırsınız.(((git commands, clone, bare))) -Geleneksel olarak, çıplak repo dizin adları, `.git` soneki ile biter. +Yeni bir yalın repo oluşturmak üzere reponuzu kopyalamak için kopyalama komutunu `--bare` seçeneği ile çalıştırırsınız.(((git commands, clone, bare))) +Geleneksel olarak, yalın repo dizin adları, `.git` soneki ile biter. Şu şekildedir: [source,console] @@ -31,7 +31,7 @@ Bu, şuna benzer bir şeye karşılık gelir: $ cp -Rf my_project/.git my_project.git ---- -Yapılandırma (configuration) dosyasında birkaç küçük fark vardır, ancak sizin amacınız için bu neredeyse aynı şeydir. +Yapılandırma dosyasında birkaç küçük fark vardır, ancak sizin amacınız için bu neredeyse aynı şeydir. Çalışma dizini olmadan yalnızca Git reposunu alır ve ona özel bir dizin oluşturur. [[_bare_repo]] @@ -56,7 +56,7 @@ $ git clone user@git.example.com:/srv/git/my_project.git Eğer `/srv/git/my_project.git` dizinine yazma erişimine sahip bir kullanıcı, sunucuya SSH ile bağlanırsa, otomatik olarak itme erişimine de sahip olacaktır. `git init` komutunu `--shared` seçeneği ile çalıştırırsanız, Git otomatik olarak bir repoya grup yazma izinlerini ekler. -Bu komutu çalıştırarak, bu süreçte hiçbir commit, ref vb. yok edilmeyecektir.(((git commands, init, bare))) +Bu komutu çalıştırarak, bu süreçte hiçbir katkı, referans vb. yok edilmeyecektir.(((git commands, init, bare))) [source,console] ---- @@ -65,7 +65,7 @@ $ cd /srv/git/my_project.git $ git init --bare --shared ---- -Bir Git reposunu almanın, yalın bir versiyon oluşturmanın ve iş arkadaşlarınızla birlikte SSH erişimine sahip olduğunuz bir sunucuya yerleştirmenin ne kadar kolay olduğunu gördünüz. +Bir Git reposunu almanın, yalın bir sürüm oluşturmanın ve iş arkadaşlarınızla birlikte SSH erişimine sahip olduğunuz bir sunucuya yerleştirmenin ne kadar kolay olduğunu gördünüz. Şimdi aynı projede işbirliği yapmaya hazırsınız. Birkaç kişinin erişimi olan kullanışlı bir Git sunucusunu çalıştırmak için yapmanız gereken tek şey budur. @@ -80,7 +80,7 @@ Yine de birkaç kişiyle özel bir projede işbirliği yapmak için ihtiyacını Eğer küçük bir ekip veya organizasyonunuzda Git'i denemek için sadece birkaç geliştiriciniz varsa, işler sizin için basit olabilir. Git sunucusu kurmanın en karmaşık yönlerinden biri kullanıcı yönetimidir. -Bazı depoların belirli kullanıcılar için salt okunur, diğerleri için ise okuma/yazma izinli olmasını istiyorsanız, erişim ve izinleri düzenlemek biraz daha zor olabilir. +Bazı repoların belirli kullanıcılar için salt okunur, diğerleri için ise okuma/yazma izinli olmasını istiyorsanız, erişim ve izinleri düzenlemek biraz daha zor olabilir. ===== SSH Erişimi From 9b2d8112cf98a634d41b7ea7a1deef704410c194 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:18:04 +0100 Subject: [PATCH 127/210] Update gitlab.asc --- book/04-git-server/sections/gitlab.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 42d22eb4..7d00f671 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -18,7 +18,7 @@ Bitnami'nin eklediği hoş bir özellik, giriş ekranıdır (alt+→ tuşların .Bitnami GitLab sanal makine giriş ekranı. image::images/bitnami.png[Bitnami GitLab sanal makine giriş ekranı.] -Başka bir şey için, GitLab Community Edition readme (oku-beni) dosyasındaki yönergeleri takip edin (bu dosyayı https://gitlab.com/gitlab-org/gitlab-ce/tree/master[] adresinde bulabilirsiniz). +Başka bir şey için, GitLab Community Edition readme (beni-oku) dosyasındaki yönergeleri takip edin (bu dosyayı https://gitlab.com/gitlab-org/gitlab-ce/tree/master[] adresinde bulabilirsiniz). Buradaki şef tarifleri, Digital Ocean üzerinde bir sanal makine ile RPM ve DEB paketleri kullanarak (yazıldığı tarih itibariyle beta sürümünde olanlar) size GitLab'ı nasıl kuracağınıza dair yardım sulabilir. Ayrıca, standart olmayan işletim sistemleri ve veritabanlarıyla GitLab'ı çalıştırma, tamamen manuel bir kurulum betiği ve birçok başka konuyla ilgili "resmi olmayan" yönergeler bulabilirsiniz. @@ -62,7 +62,7 @@ Her grup (kullanıcılar gibi) bir proje adalanına sahiptir, bu nedenle +traini image::images/gitlab-groups.png[GitLab grup yönetim ekranı.] Her bir grup, grubun kendisine ve projelerine, belli bir düzeyde erişim iznine sahip, bir dizi kullanıcı ile ilişkilidir. -Bu izinler, "Misafir" (yalnızca sorunlar ve sohbet) ile "Sahip" (grubun, üyelerin ve projelerin tam denetimi) arasında değişmektedir. +Bu izinler, "Misafir" (yalnızca konu ve sohbet) ile "Sahip" (grubun, üyelerin ve projelerin tam denetimi) arasında değişmektedir. İzin türleri burada listelenmek için fazla sayıda, ancak GitLab'ın yönetim ekranında yardımcı bir bağlantı bulunmaktadır. ===== Projeler @@ -74,7 +74,7 @@ Eğer proje bir gruba aitse, grup düzeyindeki kullanıcı izinleri de etkili ol Her proje ayrıca bir görünürlük seviyesine sahiptir, bu da projenin sayfalarına ve reposuna kimlerin okuma erişimine sahip olduğunu denetler. Bir proje _Private_ (özel) ise, proje sahibi belirli kullanıcılara erişimi açıkça vermelidir. -_Internal_ (iç) bir proje sadece oturum açmış her kullanıcı tarafından görülebilir, _Public_ (herkese açık) bir proje ise herkese görünür. +_Internal_ (iç) bir proje sadece oturum açmış her kullanıcı tarafından görülebilir, _Public_ (açık) bir proje ise herkese görünür. Unutmayın ki, bu hem `git fetch` erişimini hem de o projenin web arayüzüne erişimi kontrol eder. ===== Kancalar (Hooks) @@ -123,7 +123,7 @@ Doğrudan erişimi olan kullanıcılar basitçe bir dal oluşturabilir, işlemle Depoya itme izinleri olmayan kullanıcılar onu "çatallayabilir" (kendi kopyalarını oluşturabilir), işlemleri bu kopyaya iter ve kendi çatalından ana projeye birleştirme isteği açabilir. Bu model "güvenilmeyen kullanıcılardan" katkı alınmasına olanak tanırken, sahibin (owner) de repoya neyin, ne zaman gireceği konusunda tam bir kontrol sahibi olmasını sağlar. -Birleştirme istekleri ve sorunlar, GitLab'da uzun süreli tartışmanın ana birimleridir. +Birleştirme istekleri ve konular, GitLab'da uzun süreli tartışmanın ana birimleridir. Her birleştirme isteği, önerilen değişikliğin satır bazında tartışılmasına (hafif bir kod incelemesi) ve genel bir genel tartışma başlığına izin verir. Her ikisi de kullanıcılara atanabilir veya kilometre taşlarına düzenlenebilir. From a5faea2695b1ba4c31e20ca0e2814458051cd755 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:21:36 +0100 Subject: [PATCH 128/210] Update hosted.asc --- book/04-git-server/sections/hosted.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index ac1f3913..abee4a4b 100644 --- a/book/04-git-server/sections/hosted.asc +++ b/book/04-git-server/sections/hosted.asc @@ -1,6 +1,6 @@ -=== Üçüncü Taraf Barındırma Seçenekleri +=== Üçüncü Taraf Barındırma (Hosting) Seçenekleri -Kendi Git sunucunuzu kurmak için gereken tüm işlemleri yapmak istemiyorsanız, Git projelerinizi barındırabileceğiniz (hosting) harici bir siteden yayın yapma seçenekleriniz de bulunmaktadır. +Kendi Git sunucunuzu kurmak için gereken tüm işlemleri yapmak istemiyorsanız, Git projelerinizi barındırabileceğiniz harici bir siteden yayın yapma seçenekleriniz de bulunmaktadır. Bunu yapmanın birçok avantajı vardır: bir barındırma sitesi genellikle hızlı kurulur, projeleri başlatmak kolaydır ve sunucu bakım veya izlemesi gerekmez. Dahili olarak kendi sunucunuzu kurup çalıştırsanız bile, açık kaynak kodunuz için genel bir barındırma sitesini kullanmak isteyebilirsiniz. Bu şekilde genellikle açık kaynak topluluğunun sizi bulması ve yardım etmesi daha kolay olur. From 1cd11957a7c15e468754f28b1f4c5538dbd743e2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:24:16 +0100 Subject: [PATCH 129/210] Update protocols.asc --- book/04-git-server/sections/protocols.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index ad4e8cab..f4fc89a4 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -44,7 +44,7 @@ Ardından, bu uzak repoya, ağ üzerinden işlem yapıyormuş gibi, yeni uzak ad Dosya tabanlı repoların avantajları, basit olmaları ve mevcut dosya ve ağ erişimi izinlerini kullanmalarıdır. Eğer takımınızın tamamının erişebildiği paylaşılan bir dosya sistemine sahipseniz, bir repo kurmak çok kolaydır. -Bir yalın repo (bare repository) kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. +Bir yalın repo kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. Bu amaçla bir yalın repo kopyasını nasıl dışa aktaracağınızı <> bölümünde ele alacağız. Bu ayrıca başka birinin çalışma reposundan hızlı bir şekilde çalışma almak için de güzel bir seçenektir. From 670ca5860c1aaa0c6a518058f7443223bec86472 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:26:26 +0100 Subject: [PATCH 130/210] Delete book/04-git-server/sections/summary.asc --- book/04-git-server/sections/summary.asc | 9 --------- 1 file changed, 9 deletions(-) delete mode 100644 book/04-git-server/sections/summary.asc diff --git a/book/04-git-server/sections/summary.asc b/book/04-git-server/sections/summary.asc deleted file mode 100644 index eac8b167..00000000 --- a/book/04-git-server/sections/summary.asc +++ /dev/null @@ -1,9 +0,0 @@ -[[_git_server_summary]] -=== Özet - -Başkalarıyla işbirliği yapmak veya çalışmalarınızı paylaşmak için uzaktan bir Git reposunu kurabileceğiniz birkaç seçeneğiniz bulunmaktadır. - -Kendi sunucunuzu çalıştırmak size büyük bir kontrol ve sunucuyu kendi güvenlik duvarınız içinde çalıştırmanıza olanak tanır, ancak bu tür bir sunucu genellikle kurmak ve bakımını yapmak için önemli ölçüde zaman gerektirir. -Verilerinizi barındırılan bir sunucuya yerleştirirseniz, kurulumu ve bakımı kolay olur, ancak kodunuzu başka birinin sunucularında tutmanız gerekeceği için bazı kurumlar buna izin vermez. - -Hangi çözümün veya çözüm karmasının sizin ve kuruluşunuz için uygun olduğunu belirlemek oldukça basittir. From 505506d6717a5e08891396299a6e29a25c379900 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:36:30 +0100 Subject: [PATCH 131/210] Update contributing.asc --- .../05-distributed-git/sections/contributing.asc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index cfdb77ab..0a594a33 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -42,7 +42,7 @@ Eğer bunu katkılamadan önce çalıştırırsanız, diğer geliştiricileri ra Sonraki adım, her bir katkıyı mantıksal olarak ayrı bir değişim seti olarak ayarlamaktır. Mümkünse, değişikliklerinizi sindirilebilir hale getirmeye çalışın: bütün hafta sonu beş farklı sorun üzerinde kod yazıp, Pazartesi günü hepsini tek bir devasa katkı olarak göndermeyin. -Hafta sonu boyunca hiç katkı işlemeseniz bile, pazartesi günü çalışmanızı her soruna (iş paketine) -faydalı bir katkı mesajı da içeren- en az bir katkı olacak şekilde ayırın. +Hafta sonu boyunca hiç katkı işlemeseniz bile, pazartesi günü çalışmanızı her konuya (iş paketine) -faydalı bir katkı mesajı da içeren- en az bir katkı olacak şekilde ayırın. Değişikliklerden bazıları aynı dosyayı değiştiriyorsa, dosyaları kısmen aşamalandırmak için `git add --patch` kullanmaya çalışın (<> bölümünde detaylı olarak ele alınmıştır). Tüm değişiklikler bir şekilde eklendikten sonra, ister tek katkıda işleyin ister beş, dalın ucu üzerinde yer alan nihai proje pozu aynıdır. Bu yüzden değişikliklerinizi inceleyen diğer geliştiricilerin işlerini kolaylaştırmaya çalışın. @@ -360,7 +360,7 @@ To jessica@githost:simplegit.git Jessica John'a: çalışmalarını `featureA` adında bir dalda ittiğini ve isterse bakabileceğini söylemek için bir e-posta gönderir. Jessica John'dan geri bildirim beklerken, Josie ile `featureB` üzerinde çalışmasına başlamaya karar verir. -Başlamak için, sunucunun `master` dalından temel alarak (rebase) alarak tematik bir dal açar: +Başlamak için, sunucunun `master` dalından temelleyerek tematik bir dal açar: [source,console] ---- @@ -499,10 +499,10 @@ image::images/managed-team-flow.png[Yönetilen ekip iş akışının temel sıra ==== Çatallanmış Açık Projeler (((contributing, public small project))) -Açık (açık kaynak kodlu) projelere katkı sağlamak biraz farklıdır. +Açık (herkese açık kaynak kodlu) projelere katkı sağlamak biraz farklıdır. Projedeki dalları doğrudan güncelleme izniniz olmadığı için, çalışmanızı yürütücülere (maintainer) başka bir şekilde ulaştırmalısınız. Bu ilk örnek, çatal oluşturma imkanı sunan Git barındırma siteleri üzerinden katkı sağlama sürecini açıklar. -GitHub, BitBucket, repo.or.cz ve benzeri birçok barındırma sitesi (host) bunu destekler ve birçok proje yürütücüsü bu tarz bir katkı bekler. +GitHub, BitBucket, repo.or.cz ve benzeri birçok barındırma sitesi bunu destekler ve birçok proje yürütücüsü bu tarz bir katkı bekler. Sonraki bölüm, katkı sağlanan yamaların e-posta aracılığıyla kabul edildiği projeleri ele alır. İlk olarak ana repoyu kopyalamanız gerekmektedir. @@ -522,7 +522,7 @@ $ git commit [NOT] ==== -İşinizi tek katkı (commit) 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. +İş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. ==== @@ -538,7 +538,7 @@ $ git remote add myfork Sonra, yeni çalışmanızı bu repoya göndermeniz gerekir. Çalıştığınız tematik dalınızı çatallamış olduğunuz depoya göndermek, onu master dalınıza birleştirip ardından da itmekten daha kolaydır. Bunun nedeni, çalışmanızın kabul edilmemesi veya ayıklanması (cherry-pick) durumunda ana dalınızı geri sarmanız gerekmemesidir (Git `cherry-pick` işlemi <> bölümünde daha ayrıntılı olarak ele alınmıştır). -Eğer yürütücüler çalışmanızı birleştirir (merge), temeller (rebase) veya ayıklarsa (cherry-pick), çalışmanızı onların reposundan çekerek alabilirsiniz. +Eğer yürütücüler çalışmanızı birleştirir, yeniden temeller veya ayıklarsa, çalışmanızı onların reposundan çekerek alabilirsiniz. Her durumda, çalışmanızı şu şekilde itebilirsiniz: @@ -597,7 +597,7 @@ Artık her bir başlığımız, yama kuyruğunda (patch queue) olduğu gibi: yen image::images/public-small-1.png[`featureB` çalışmasının öncel katkı geçmişi.] Diyelim ki, yürütücü birçok başka yamayı çekmiş ve sizin ilk dalınızı çekmeyi de denemiş, ancak artık temiz bir şekilde birleşmiyor. -Bu durumda, bu dalı `origin/master`'ın üzerine temellemeyi (rebase) deneyebilir ve yürütücü için çatışmaları çözüp, ardından değişikliklerinizi yeniden gönderebilirsiniz. +Bu durumda, bu dalı `origin/master`'ın üzerine temellemeyi deneyebilir ve yürütücü için çatışmaları çözüp, ardından değişikliklerinizi yeniden gönderebilirsiniz. [source,console] ---- @@ -612,7 +612,7 @@ Bu, şimdi geçmişinizi <> gibi yeniden yazar. .`featureA` çalışmasından sonra katkı geçmişi. image::images/public-small-2.png[`featureA` çalışmasından sonra katkı geçmişi.] -Dalı yeniden temellendirdiniz; bu yüzden sunucudaki `featureA` dalını, kendi soyundan gelmeyen bir katkıyla değiştirebilmek için itme (push) komutunuza `-f` bayrağı eklemelisiniz. +Dalı yeniden temellendirdiniz; bu yüzden sunucudaki `featureA` dalını, kendi soyundan gelmeyen bir katkıyla değiştirebilmek için itme komutunuza `-f` bayrağı eklemelisiniz. Başka bir alternatif ise, bu yeni çalışmayı sunucuda farklı (mesela `featureAv2` olarak adlandırılmış) bir dala itmektir. Bir başka olası senaryoya bir göz atalım: yürütücü ikinci dalınızdaki çalışmayı inceledi ve yaklaşımınızı beğendi, ancak uygulamadi bir detayı değiştirmenizi istiyor. From 4645ab4735784b264e75a78ec849a520430bba52 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:41:41 +0100 Subject: [PATCH 132/210] Update distributed-workflows.asc --- .../05-distributed-git/sections/distributed-workflows.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 3c3dc085..7fae7709 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,7 +1,7 @@ === Dağıtık İş Akışları (((workflows))) -Merkezi Sürüm Denetim Sistemleri (CVCS'ler) ile karşılaştırıldığında, Git'in dağıtık yapısı, geliştiricilerin projelerde nasıl işbirliği yapacakları konusunda çok daha esnek olmalarını sağlar. +Merkezi Sürüm Denetim Sistemleri (CVCS) ile karşılaştırıldığında, Git'in dağıtık yapısı, geliştiricilerin projelerde nasıl işbirliği yapacakları konusunda çok daha esnek olmalarını sağlar. Merkezi sistemlerde, her geliştirici merkezi bir dağıtım göbeğiyle (hub) neredeyse eşit olarak çalışan bir düğümdür (node). Ancak, Git'te her geliştirici potansiyel olarak hem bir düğüm hem de bir göbektir: yani, her geliştirici hem diğer repolara kod katkısında bulunabilir, hem de diğerlerinin çalışmalarını temel alabilecekleri ve katkıda bulunabilecekleri bir açık repoyu yürütebilir. Bu, projeniz ve/veya ekibiniz için geniş bir olası iş akışı yelpazesi sunar, bu esneklikten faydalanabileceğiniz birkaç yaygın paradigmayı ele alacağız. @@ -18,7 +18,7 @@ Geliştiriciler (o göbeğin tüketicileri olan) düğümlerdir ve işlerini bu .Merkezi iş akışı. image::images/centralized_workflow.png[Merkezi iş akışı.] -Bunun anlamı, iki geliştiricinin göbekten (hub, repo) kopyaladığı ve her ikisinin de değişiklikler yaptığı durumda, değişikliklerini ilk gönderen birinci geliştiricinin bunu herhangi bir sorun yaşamadan yapabileceğidir. +Bunun anlamı, iki geliştiricinin göbekten (hub/repo) kopyaladığı ve her ikisinin de değişiklikler yaptığı durumda, değişikliklerini ilk gönderen birinci geliştiricinin bunu herhangi bir sorun yaşamadan yapabileceğidir. İkinci geliştirici değişiklikleri göndermeden önce, birinci geliştiricinin çalışmasını birleştirmelidir. Böylece birinci geliştiricinin değişikliklerini üzerine yazmamış olur. Bu kavram, Subversion(((Subversion))) (veya herhangi bir başka CVCS) gibi Git'te de geçerlidir ve bu model Git'te mükemmel bir şekilde çalışır. @@ -76,10 +76,10 @@ Tüm yardımcılar, "benevolent dictator" (yardımsever diktatör) olarak biline Tüm yardımcıların bu yardımsever diktatörün kendi dizininden referans repoya ittiği kodu çekmesi gereklidir. Süreç şöyle işler (bkz. <>): -1. Normal geliştiriciler tematik dallarda çalışır ve çalışmalarını `master` üzerine temeller (rebase). +1. Normal geliştiriciler tematik dallarda çalışır ve çalışmalarını `master` üzerine temeller. `master` dalı yöneticinin ittiği referans reposunun dalıdır. 2. Yardımcılar, geliştiricilerin konu dallarını kendi `master` dallarına birleştirir. -3. Diktatör yardımcıların `master` dallarını kendi `master` dalına birleştirir. +3. Diktatör, yardımcıların `master` dallarını kendi `master` dalına birleştirir. 4. Son olarak, diktatör bu `master` dalını referans reposuna iter, böylece diğer geliştiriciler bunun üzerine temelleme yapabilir. [[wfdiag_c]] From 0b87f76d49633f690c778fd13c4996b8dc8d8d4d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Wed, 6 Mar 2024 08:47:57 +0100 Subject: [PATCH 133/210] Update maintaining.asc --- book/05-distributed-git/sections/maintaining.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index f1f03771..984e1a4a 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -340,7 +340,7 @@ image::images/merging-workflows-3.png[Tema dalı birleşmesi öncesi.] image::images/merging-workflows-4.png[Tema dalı birleşmesi sonrası.] [[merwf_e]] -.Yeni sürümü sonrası. +.Yeni sürüm sonrası. image::images/merging-workflows-5.png[Yeni sürümü sonrası.] Bu şekilde, insanlar reponuzu kopyaladığında; ya en son "kararlı" sürümü derlemek ve bunu kolayca güncellemek için `master` dalına geçebilir ya da daha en "güncel" içeriği içeren `develop` dalına. @@ -379,12 +379,12 @@ Bu iş akışını daha iyi anlamak için https://github.com/git/git/blob/master ===== Temelleme ve Ayıklama (Cherry-Picking) İş Akışları (((workflows, rebasing and cherry-picking))) -Diğer yürütücüler, doğrusal bir geçmişe sahip olmak için genellikle için katkılanan çalışmaları master dalının üstüne yeniden temellemeyi (rebase) veya ayıklamayı (cherry-pick) tercih ederler. +Diğer yürütücüler, doğrusal bir geçmişe sahip olmak için genellikle için katkılanan çalışmaları master dalının üstüne yeniden temellemeyi (rebase) veya ayıklamayı tercih ederler. Bir tema dalında birleştirmek istediğiniz bir çalışmanız varsa, o dala geçer ve değişiklikleri mevcut `master` (veya `develop`, vb.) dalı üstüne yeniden inşa etmek için temelleme (rebase) komutunu çalıştırırsınız. Bu işlem sorunsuz tamamlanırsa, `master` dalınızı ileri sarabilir ve sonuçta doğrusal bir proje geçmişine sahip olursunuz. (((git commands, cherry-pick))) -Tanıtılan bir çalışmayı bir daldan başka bir dala taşımanın bir diğer yolu da onu ayıklamaktır (cherry-pick). +Tanıtılan bir çalışmayı bir daldan başka bir dala taşımanın bir diğer yolu da onu ayıklamaktır. Git'te ayıklama işlemi, bir tek katkı için bir yeniden temelleme gibidir. Bir katkıyla yapılan değişiklikleri alır ve bunları şu anda bulunduğunuz dala tekrar uygulamaya çalışır. Bir tema dalında birkaç katkımız varsa ve bunları ayıklayıp yalnızca birini almak istiyorsanız veya bir tema dalında yalnızca bir katkınız varsa ve yeniden temellemek yerine bunu tercih etmek istiyorsanız, bu özellik kullanışlıdır. From c35492019a00af82602724b965e74ca5ea53cb45 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 7 Mar 2024 12:05:45 +0100 Subject: [PATCH 134/210] Update 3-maintaining.asc --- book/06-github/sections/3-maintaining.asc | 3 --- 1 file changed, 3 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 8c382ba2..a19d7b30 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -359,9 +359,6 @@ Genel olarak, tek bir projede yapabileceğiniz çok fazla yönetim işi yoktur, Eğer varsayılan olarak insanların birleştirme isteği açmaları veya varsayılan olarak görmeleri için "main" (ana) dışında bir dal kullanıyorsanız, bunu repo ayarları sayfasında ``Options`` (Seçenekler) sekmesi altında değiştirebilirsiniz. - -If you are using a branch other than ``master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository's settings page under the ``Options'' tab. - [[_default_branch]] .Bir projenin varsayılan dalını değiştirmek. image::images/maint-10-default-branch.png[Varsayılan dal] From b4d55f4a3f1d0c289cc2a91d14de0f874a82c42a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Thu, 7 Mar 2024 13:06:47 +0100 Subject: [PATCH 135/210] Translate revision-selection.asc up to line: 88 --- .../sections/revision-selection.asc | 62 +++++++++---------- 1 file changed, 30 insertions(+), 32 deletions(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 14fb2373..7e1dcded 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -1,19 +1,18 @@ [[_revision_selection]] -=== Revision Selection +=== Düzeltme Seçimi -Git allows you to refer to a single commit, set of commits, or range of commits in a number of ways. -They aren't necessarily obvious but are helpful to know. +Git, bir veya birkaç katkı veya katkı aralığına birkaç şekilde atıfta bulunmanızı sağlar. Bunlar her zaman açık olmayabilir, ancak bilmeniz faydalı olabilir. -==== Single Revisions +==== Tekli Düzeltmeler (Tashihler) -You can obviously refer to any single commit by its full, 40-character SHA-1 hash, but there are more human-friendly ways to refer to commits as well. -This section outlines the various ways you can refer to any commit. +Herhangi tek bir katkıyı 40 karakterlik tam bir SHA-1 karmasıyla (hash) gösterebilirsiniz, ancak katkıları daha insan dostu yollarla da belirtebilirsiniz. +Bu bölüm, herhangi bir katkıyı belirtmek için kullanabileceğiniz çeşitli yolları açıklar. -==== Short SHA-1 +==== Kısa SHA-1 -Git is smart enough to figure out what commit you're referring to if you provide the first few characters of the SHA-1 hash, as long as that partial hash is at least four characters long and unambiguous; that is, no other object in the object database can have a hash that begins with the same prefix. +Bir katkıyı belirtmek için SHA-1 karmasının ilk birkaç karakterini yazarsanız, yazdığınız karma en az dört karakter uzunluğunda ve belirsiz olmadığı sürece, Git hangi katkıya atıfta bulunduğunuzu anlayacak kadar akıllıdır. Başka bir deyişle, nesne veritabanında aynı önek ile başlayan başka bir nesne olmadığı müddetçe sorun yaşamazsınız. -For example, to examine a specific commit where you know you added certain functionality, you might first run the `git log` command to locate the commit: +Örneğin, belirli bir işlev eklediğinizi bildiğiniz bir katkıyı incelemek için, ilk önce `git log` komutunu çalıştırarak o katkıyı bulabilirsiniz: [source,console] ---- @@ -38,8 +37,8 @@ Date: Thu Dec 11 14:58:32 2008 -0800 added some blame and merge stuff ---- -In this case, say you're interested in the commit whose hash begins with `1c002dd...`. -You can inspect that commit with any of the following variations of `git show` (assuming the shorter versions are unambiguous): +Diyelim ki, SHA-1 özetinin `1c002dd...` ile başladığı bir katkıyla ilgileniyorsunuz. +Bu katkıyı incelemek için aşağıdaki `git show` çeşitlemelerinden herhangi birini kullanabilirsiniz (kısa versiyonların belirsiz olmadığı varsayılmaktadır): [source,console] ---- @@ -48,8 +47,8 @@ $ git show 1c002dd4b536e7479f $ git show 1c002d ---- -Git can figure out a short, unique abbreviation for your SHA-1 values. -If you pass `--abbrev-commit` to the `git log` command, the output will use shorter values but keep them unique; it defaults to using seven characters but makes them longer if necessary to keep the SHA-1 unambiguous: +Git, SHA-1 değerleriniz için kısa, benzersiz bir kısaltma bulabilir. +`git log` komutuna `--abbrev-commit` seçeneğini eklerseniz, çıktı daha kısa değerler kullanacak ancak bunları benzersiz tutacaktır; SHA-1'in belirsiz olmaması (benzersiz olması) için, varsayılan olarak yedi karakter kullanır ancak bu onu daha uzun hale getirir: [source,console] ---- @@ -59,35 +58,34 @@ ca82a6d changed the version number a11bef0 first commit ---- -Generally, eight to ten characters are more than enough to be unique within a project. -For example, as of February 2019, the Linux kernel (which is a fairly sizable project) has over 875,000 commits and almost seven million objects in its object database, with no two objects whose SHA-1s are identical in the first 12 characters. +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. -[NOTE] -.A SHORT NOTE ABOUT SHA-1 +[NOT] +.SHA-1 HAKKINDA KISA BİR NOT ==== -A lot of people become concerned at some point that they will, by random happenstance, have two distinct objects in their repository that hash to the same SHA-1 value. -What then? +Birçok insan, rastgele bir olay sonucu, repolarında birbirinden farklı iki nesnenin aynı SHA-1 değerine sahip olabileceğinden endişelenir. +Peki sonra ne olur? -If you do happen to commit an object that hashes to the same SHA-1 value as a previous _different_ object in your repository, Git will see the previous object already in your Git database, assume it was already written and simply reuse it. -If you try to check out that object again at some point, you'll always get the data of the first object. +Eğer repoya daha önceden işlenmiş _farklı_ bir nesnenin SHA-1 değerine sahip yeni bir nesne eklerseniz, Git önceki nesneyi zaten Git veritabanınızda görecek, bu nesnenin zaten yazıldığını varsayacak ve onu yeniden kullanacaktır. +Bir noktada o nesneye geçmeye çalışırsanız, her zaman ilk nesnenin verisini alacaksınız. -However, you should be aware of how ridiculously unlikely this scenario is. -The SHA-1 digest is 20 bytes or 160 bits. -The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80^ -(the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80^ -is 1.2 x 10^24^ -or 1 million billion billion. -That's 1,200 times the number of grains of sand on the earth. +Ancak, bu senaryonun gerçekleşme ihtimalinin, imkansıza yakın derecede olanaksız olduğunun farkında olmalısınız. +SHA-1 özeti 20 bayt veya 160 bit'tir. +Bu eşleşme olasılığının %50 olması için gerekli rastgele özetlenmiş nesne sayısı yaklaşık 2^80 (2 üzeri 80) civarındadır +(çarpışma olasılığını belirleme formülü `p = (n(n-1)/2) * (1/2^160)`). +2 üzeri 80 yaklaşık olarak 1,2 x 10^24 veya kelimelere dökersek "milyon kere milyar kere milyar"dır. +Bu da dünyadaki kum tanelerinin toplam sayısının yaklaşık 1,200 katıdır. -Here's an example to give you an idea of what it would take to get a SHA-1 collision. -If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. -Thus, a SHA-1 collision is less likely than every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night. +İşte bir SHA-1 çarpışmasını elde etmek için gerekenleri anlamanıza yardımcı olacak bir başka örnek: +Dünyadaki 6,5 milyar insanın hepsi programlama yapıyor olsaydı ve bunların her biri, Linux çekirdeğine saniyede bir katkı işleyip (saniyede 6,5 milyon Git nesnesi) bunları devasa bir Git reposuna itseydi; bu repoda bir tek SHA-1 nesnesinin çarpışma olasılığının %50 olması, yaklaşık 2 yıl sürerdi. +Bu nedenle, bir SHA-1 çarpışmasının gerçekleşme ihtimali, programlama ekibinizin tüm üyelerinin, aynı gece, farklı yerlerde, farklı şeylerle ilgilenirken, aniden kurtlar tarafından saldırıya uğraması ve öldürülmesinden daha düşüktür. ==== [[_branch_references]] -==== Branch References +==== Dal Referansları One straightforward way to refer to a particular commit is if it's the commit at the tip of a branch; in that case, you can simply use the branch name in any Git command that expects a reference to a commit. For instance, if you want to examine the last commit object on a branch, the following commands are equivalent, assuming that the `topic1` branch points to commit `ca82a6d...`: From e3e52712e0bffcda7e2435a2bc82d84be4e35e63 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 11 Mar 2024 08:14:13 +0100 Subject: [PATCH 136/210] Translate revision-selection up to line: 182 --- .../sections/revision-selection.asc | 51 ++++++++++--------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 7e1dcded..3ce1d86f 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -3,7 +3,7 @@ Git, bir veya birkaç katkı veya katkı aralığına birkaç şekilde atıfta bulunmanızı sağlar. Bunlar her zaman açık olmayabilir, ancak bilmeniz faydalı olabilir. -==== Tekli Düzeltmeler (Tashihler) +==== Tekli Düzeltmeler Herhangi tek bir katkıyı 40 karakterlik tam bir SHA-1 karmasıyla (hash) gösterebilirsiniz, ancak katkıları daha insan dostu yollarla da belirtebilirsiniz. Bu bölüm, herhangi bir katkıyı belirtmek için kullanabileceğiniz çeşitli yolları açıklar. @@ -87,8 +87,8 @@ Bu nedenle, bir SHA-1 çarpışmasının gerçekleşme ihtimali, programlama eki [[_branch_references]] ==== Dal Referansları -One straightforward way to refer to a particular commit is if it's the commit at the tip of a branch; in that case, you can simply use the branch name in any Git command that expects a reference to a commit. -For instance, if you want to examine the last commit object on a branch, the following commands are equivalent, assuming that the `topic1` branch points to commit `ca82a6d...`: +Belirli bir katkıya başvurmanın basit bir yolu, o dalın uç noktasındaki bir katkı olduğunda; bu durumda, bir katkı başvurusunu bekleyen herhangi bir Git komutunda sadece dal adını kullanabilirsiniz. +Örneğin, bir daldaki son katkı nesnesini incelemek istiyorsanız, `topic1` dalının `ca82a6d...` katkısına işaret ettiğini varsayarsak, aşağıdaki komutlar eşdeğerdir: [source,console] ---- @@ -96,10 +96,10 @@ $ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1 ---- -If you want to see which specific SHA-1 a branch points to, or if you want to see what any of these examples boils down to in terms of SHA-1s, you can use a Git plumbing tool called `rev-parse`. -You can see <> for more information about plumbing tools; basically, `rev-parse` exists for lower-level operations and isn't designed to be used in day-to-day operations. -However, it can be helpful sometimes when you need to see what's really going on. -Here you can run `rev-parse` on your branch. +Bir dalın hangi SHA-1'e işaret ettiğini görmek istiyorsanız veya bu örneklerden herhangi birinin SHA-1'ler açısından neye denk geldiğini görmek istiyorsanız, `rev-parse` adlı bir Git aracını kullanabilirsiniz. +Daha fazla bilgi için <> adresine bakabilirsiniz; temelde, `rev-parse` daha düşük düzeyli işlemler için var ve günlük işlemlerde kullanılmak üzere tasarlanmamıştır. +Ancak, bazen gerçekte ne olduğunu görmek gerektiğinde yardımcı olabilir. +Burada dalınız üzerinde `rev-parse` çalıştırabilirsiniz. [source,console] ---- @@ -108,11 +108,11 @@ ca82a6dff817ec66f44342007202690a93763949 ---- [[_git_reflog]] -==== RefLog Shortnames +==== Referans Günlüğü (Reflog) Kısa Adları -One of the things Git does in the background while you're working away is keep a ``reflog'' -- a log of where your HEAD and branch references have been for the last few months. +Git'in arka planda çalışırken yaptığı şeylerden biri, "reflog" olarak adlandırılan, HEAD ve dal referanslarınızın son birkaç ay boyunca nerede olduğunu kaydettiği bir günlük tutmaktır. -You can see your reflog by using `git reflog`: +Referans günlügünüzü `git reflog` komutunu kullanarak görebilirsiniz: [source,console] ---- @@ -126,27 +126,27 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy. 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD ---- -Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. -You can use your reflog data to refer to older commits as well. -For example, if you want to see the fifth prior value of the HEAD of your repository, you can use the `@{5}` reference that you see in the reflog output: +Herhangi bir nedenle dal ucu güncellendiğinde, Git bu bilgiyi geçici bir geçmişte sizin için saklar. +Reflog verilerinizi eski katkılara başvurmak için de kullanabilirsiniz. +Örneğin, repo ucunuzun beş önceki değerini görmek istiyorsanız, reflog çıktısında gördüğünüz `@{5}` referansını kullanabilirsiniz: [source,console] ---- $ git show HEAD@{5} ---- -You can also use this syntax to see where a branch was some specific amount of time ago. -For instance, to see where your `master` branch was yesterday, you can type +Bu sözdizimini ayrıca bir dalın belirli bir süre önce nerede olduğunu görmek için de kullanabilirsiniz. +Örneğin, `master` dalınızın dün nerede olduğunu görmek için şunu yazabilirsiniz: [source,console] ---- $ git show master@{yesterday} ---- -That would show you where tip of your `master` branch was yesterday. -This technique only works for data that's still in your reflog, so you can't use it to look for commits older than a few months. +Bu, `master` dalınızın ucunun dün nerede olduğunu gösterir. +Bu teknik, hala referans günlüğünüzde olan veriler için çalışır, bu nedenle birkaç aydan daha eski katkıları aramak için kullanamazsınız. -To see reflog information formatted like the `git log` output, you can run `git log -g`: +`git log` çıktısı gibi biçimlendirilmiş referans günlüğü bilgilerini görmek için `git log -g` komutunu çalıştırabilirsiniz: [source,console] ---- @@ -168,17 +168,18 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -It's important to note that reflog information is strictly local -- it's a log only of what _you've_ done in _your_ repository. -The references won't be the same on someone else's copy of the repository; also, right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository. -Running `git show HEAD@{2.months.ago}` will show you the matching commit only if you cloned the project at least two months ago -- if you cloned it any more recently than that, you'll see only your first local commit. +Reflog bilgilerinin kesinlikle yerel olduğunu bilmelisinizi - yalnızca _sizin kendi reponuzda yaptığınız_ işlemlerin günlüğüdür. +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. -[TIP] -.Think of the reflog as Git's version of shell history +[İPUCU] +.Reflog'u Git'in kabuk (shell) geçmişi versiyonu olarak düşünebilirsiniz. ==== -If you have a UNIX or Linux background, you can think of the reflog as Git's version of shell history, which emphasizes that what's there is clearly relevant only for you and your ``session'', and has nothing to do with anyone else who might be working on the same machine. +UNIX veya Linux geçmişiniz varsa, reflog'u Git'in kabuk geçmişinin versiyonu olarak düşünebilirsiniz. +Bu, oradaki şeylerin sadece "sizle" ve "oturumunuzla" için açıkça ilgili olduğunu vurgular ve aynı makinede çalışan başka birinin bununla ilgisi olmadığını belirtir. ==== -==== Ancestry References +==== Soy Referansları The other main way to specify a commit is via its ancestry. If you place a `^` (caret) at the end of a reference, Git resolves it to mean the parent of that commit. From a86edd5814403b018fef022539acfb8cfb003c96 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 11 Mar 2024 09:13:34 +0100 Subject: [PATCH 137/210] Translate revision-selection.asc complete --- .../sections/revision-selection.asc | 105 +++++++++--------- 1 file changed, 53 insertions(+), 52 deletions(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 3ce1d86f..ee4ed1a2 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -181,9 +181,9 @@ Bu, oradaki şeylerin sadece "sizle" ve "oturumunuzla" için açıkça ilgili ol ==== Soy Referansları -The other main way to specify a commit is via its ancestry. -If you place a `^` (caret) at the end of a reference, Git resolves it to mean the parent of that commit. -Suppose you look at the history of your project: +Başka bir katkıyı belirtmenin ana yolu, onun kökenidir. +Bir referansın sonuna bir `^` (caret) işareti koyarsanız, bunun Git'te temsil ettiği şey, o katkının öncelidir. +Projenizin geçmişine bir göz atarsanız: [source,console] ---- @@ -198,7 +198,7 @@ $ git log --pretty=format:'%h %s' --graph * 9b29157 add open3_detach to gemspec file list ---- -Then, you can see the previous commit by specifying `HEAD^`, which means ``the parent of HEAD'': +Ardından, `HEAD^` belirterek önceki katkıyı görebilirsiniz, bu da "HEAD'in önceli" anlamına gelir: [source,console] ---- @@ -211,12 +211,12 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -[NOTE] -.Escaping the caret on Windows +[NOT] +.Windows'ta caret işaretinden kaçınmak ==== -On Windows in `cmd.exe`, `^` is a special character and needs to be treated differently. -You can either double it or put the commit reference in quotes: +Windows'ta `^` 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] ---- @@ -227,8 +227,8 @@ $ git show "HEAD^" # OK ==== -You can also specify a number after the `^` to identify _which_ parent you want; for example, `d921970^2` means ``the second parent of d921970.'' -This syntax is useful only for merge commits, which have more than one parent -- the _first_ parent of a merge commit is from the branch you were on when you merged (frequently `master`), while the _second_ parent of a merge commit is from the branch that was merged (say, `topic`): +Kaçıncı önceli istediğinizi belirtmek için `^` karakterinin hemen ardından bir sayı belirtebilirsiniz: örneğin, `d921970^2`, "d921970'nin ikinci önceli" anlamına gelir. +Bu sözdizimi, birden fazla önceli olan birleştirme katkıları için yararlıdır: bir birleştirme katkısının _ilk_ önceli, birleştirdiğinizde üzerinde bulunduğunuz dalın (genellikle `master`) olduğu dal, bir birleştirme katkısının _ikinci_ önceli ise birleştirilen dalın (örneğin, `topic`) olduğu daldır: [source,console] ---- @@ -247,11 +247,11 @@ Date: Wed Dec 10 22:22:03 2008 +0000 Some rdoc changes ---- -The other main ancestry specification is the `~` (tilde). -This also refers to the first parent, so `HEAD~` and `HEAD^` are equivalent. -The difference becomes apparent when you specify a number. -`HEAD~2` means ``the first parent of the first parent,'' or ``the grandparent'' -- it traverses the first parents the number of times you specify. -For example, in the history listed earlier, `HEAD~3` would be +Diğer ana soy belirteci de `~` (tilde) karakteridir. +Bu da ilk öncele atıfta bulunur, bu yüzden `HEAD~` ve `HEAD^` eşdeğerdir. +Fark, bir sayı belirttiğinizde ortaya çıkar. +`HEAD~2`, "ilk öncelin önceli" veya "ikinci öncel" anlamına gelir - belirttiğiniz sayı kadar birinci önceli geçer. +Örneğin, önceki listede, `HEAD~3` şöyle olurdu: [source,console] ---- @@ -263,7 +263,7 @@ Date: Fri Nov 7 13:47:59 2008 -0500 ignore *.gem ---- -This can also be written `HEAD~~~`, which again is the first parent of the first parent of the first parent: +Bu, `HEAD~~~` olarak da yazılabilir, yani yine ilk öncelin ilk öncelidir. [source,console] ---- @@ -275,27 +275,28 @@ Date: Fri Nov 7 13:47:59 2008 -0500 ignore *.gem ---- -You can also combine these syntaxes -- you can get the second parent of the previous reference (assuming it was a merge commit) by using `HEAD~3^2`, and so on. +Bu sözdizimlerini birleştirebilirsiniz: (bir birleştirme katkısı olduğunu varsayarsak) önceki referansın ikinci önceline `HEAD~3^2` kullanarak ulaşabilirsiniz, vs. + [[_commit_ranges]] -==== Commit Ranges +==== Katkı Aralığı -Now that you can specify individual commits, let's see how to specify ranges of commits. -This is particularly useful for managing your branches -- if you have a lot of branches, you can use range specifications to answer questions such as, ``What work is on this branch that I haven't yet merged into my main branch?'' +Şimdi tek tek katkıları belirtebildiğimize göre, katkı aralıklarını nasıl belirleyeceğimizi görelim. +Özellikle dallarınızı yönetmek için oldukça kullanışlı bir yöntemdir: eğer birçok dalınız varsa, aralık belirlemelerini kullanarak "Bu dalda, henüz ana dalıma birleştirmediğim hangi işler var?" gibi soruları yanıtlayabilirsiniz. -===== Double Dot +===== İki Nokta (..) -The most common range specification is the double-dot syntax. -This basically asks Git to resolve a range of commits that are reachable from one commit but aren't reachable from another. -For example, say you have a commit history that looks like <>. +Aralık belirtmekte kullanılan en yaygın sözdizimi "çift nokta"dır. +Temel olarak Git'ten, bir katkıdan erişilebilen ancak diğerinden erişilemeyen bir katkı aralığını çözmesini istemektir. +Örneğin, <> gibi bir katkı geçmiğiniz olsun: [[double_dot]] -.Example history for range selection. -image::images/double-dot.png[Example history for range selection.] +.Aralık seçimi için örnek bir geçmiş. +image::images/double-dot.png[Aralık seçimi için örnek bir geçmiş.] -Say you want to see what is in your `experiment` branch that hasn't yet been merged into your `master` branch. -You can ask Git to show you a log of just those commits with `master..experiment` -- that means ``all commits reachable from experiment that aren't reachable from master.'' -For the sake of brevity and clarity in these examples, the letters of the commit objects from the diagram are used in place of the actual log output in the order that they would display: +Diyelim ki `experiment` dalınızdan `master` dalınıza henüz birleştirilmemiş olan değişiklikleri görmek istiyorsunuz. +Git'ten, `master`'dan erişilemeyen ancak `experiment`'ten erişilebilen tüm katkıların bir günlüğünü göstermesini isteyebilirsiniz; yani "experiment dalından erişilebilen ancak master dalından erişilemeyen tüm katkılar". +Bu örneklerde kısaltma ve açıklık için, diyagramdaki katkı nesnelerinin harfleri gerçek günlük çıktısı yerine kullanılmıştır ve gösterilecek sırayla kullanılmıştır: [source,console] ---- @@ -304,8 +305,8 @@ D C ---- -If, on the other hand, you want to see the opposite -- all commits in `master` that aren't in `experiment` -- you can reverse the branch names. -`experiment..master` shows you everything in `master` not reachable from `experiment`: +Öte yandan, tam tersini görmek istiyorsanız; yani `experiment`'te olmayan tüm katkıları `master`'da görmek istiyorsanız, dal isimlerini ters çevirebilirsiniz. +`experiment..master`, `experiment`'ten erişilemeyen her şeyi `master`'da size gösterir: [source,console] ---- @@ -314,24 +315,24 @@ F E ---- -This is useful if you want to keep the `experiment` branch up to date and preview what you're about to merge. -Another frequent use of this syntax is to see what you're about to push to a remote: +Bu, `experiment` dalını güncel tutmak ve birleştirmek üzere olduğunuz şeyi önizlemek istiyorsanız kullanışlıdır. +Bu sözdiziminin sık kullanılan bir başka kullanımı da, uzak bir repoya neyi iteceğinizi görmektir: [source,console] ---- $ git log origin/master..HEAD ---- -This command shows you any commits in your current branch that aren't in the `master` branch on your `origin` remote. -If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server. -You can also leave off one side of the syntax to have Git assume `HEAD`. -For example, you can get the same results as in the previous example by typing `git log origin/master..` -- Git substitutes `HEAD` if one side is missing. +Bu komut size, mevcut dalınızda olup, `origin` uzak reposu `master` dalında olmayan tüm katkıları gösterir. +Bir `git push` çalıştırırsanız ve mevcut dalınız `origin/master`'ı takip ediyorsa, `git log origin/master..HEAD` tarafından listelenen katkılar, sunucuya aktarılacak olan katkılardır. +Ayrıca, sözdiziminin bir tarafını bırakarak Git'in `HEAD`'i varsaymasını sağlayabilirsiniz. +Örneğin, `git log origin/master..` yazarak önceki örnekteki aynı sonuçları alabilirsiniz; bir taraf eksikse, Git `HEAD`'i otomatik olarak eksik kısmın yerine koyar. -===== Multiple Points +===== Çoklu Noktalar -The double-dot syntax is useful as a shorthand, but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren't in the branch you're currently on. -Git allows you to do this by using either the `^` character or `--not` before any reference from which you don't want to see reachable commits. -Thus, the following three commands are equivalent: +İki dalı belirtmek için "çift nokta" sözdizimi kullanışlı olabilir, ancak belki de mevcut daldan farklı olan birkaç dalı belirtmek istersiniz: örneğin, şu anda bulunduğunuz dalda olmayan birkaç dalda hangi katkıların olduğunu görmek gibi. +Git, erişilebilir katkıları görmek istemediğiniz herhangi bir referansın önüne `^` karakterini veya `--not` kullanarak bunu yapmanıza izin verir. +Bu nedenle, aşağıdaki üç komut eşdeğerdir: [source,console] ---- @@ -340,8 +341,8 @@ $ git log ^refA refB $ git log refB --not refA ---- -This is nice because with this syntax you can specify more than two references in your query, which you cannot do with the double-dot syntax. -For instance, if you want to see all commits that are reachable from `refA` or `refB` but not from `refC`, you can use either of: +Bunun güzelliği, bu sözdizimi ile sorgunuzda iki referanstan fazlasını belirtebilmenizdedir - bu çift nokta sözdizimi ile yapamadığınız bir şeydir. +Örneğin, `refA` veya `refB`'den erişilebilen ancak `refC`'den erişilemeyen tüm katkıları görmek istiyorsanız, aşağıdaki komutlardan herhangi birini kullanabilirsiniz: [source,console] ---- @@ -349,14 +350,14 @@ $ git log refA refB ^refC $ git log refA refB --not refC ---- -This makes for a very powerful revision query system that should help you figure out what is in your branches. +Bu, dallarınızdaki içeriği belirlemenize yardımcı olacak oldukça güçlü bir revizyon sorgu sistemi oluşturur. [[_triple_dot]] -===== Triple Dot +===== Üçlü Nokta (...) -The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by _either_ of two references but not by both of them. -Look back at the example commit history in <>. -If you want to see what is in `master` or `experiment` but not any common references, you can run: +Son büyük aralık seçimi sözdizimi üç noktalı yazımdır (...), bu da iki referansın herhangi biri tarafından erişilebilen ancak her ikisinden erişilemeyen tüm katkıları belirtir. +<> örneği katkı geçmişine geri dönün. +`master` veya `experiment`'te bulunan ancak ortak referanslardan herhangi birinde bulunmayan katkıları görmek istiyorsanız şunu çalıştırabilirsiniz: [source,console] ---- @@ -367,10 +368,10 @@ D C ---- -Again, this gives you normal `log` output but shows you only the commit information for those four commits, appearing in the traditional commit date ordering. +Bu size yine normal `log` çıktısı verir, ancak sadece bu dört katkı için, geleneksel katkı tarihi sıralamasında görünür. -A common switch to use with the `log` command in this case is `--left-right`, which shows you which side of the range each commit is in. -This helps make the output more useful: +Bu durumda `log` komutu ile kullanılan yaygın bir anahtar değişimi `--left-right`'dır: bu size her katkının, aralığın hangi tarafında olduğunu gösterir. +Bu da, çıktıyı daha kullanışlı hale getirir: [source,console] ---- @@ -381,4 +382,4 @@ $ git log --left-right master...experiment > C ---- -With these tools, you can much more easily let Git know what commit or commits you want to inspect. +Bu araçlarla, Git'e incelemek istediğiniz katkı veya katkıları belirtmeniz çok daha kolay olur. From a818ab1cea2e91660e3f43c8022d2caf759e212a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Murat=20Ya=C5=9Far?= <127419303+murat-yasar@users.noreply.github.com> Date: Mon, 11 Mar 2024 17:35:39 +0100 Subject: [PATCH 138/210] Translate interactive-staging complete --- .../sections/interactive-staging.asc | 104 +++++++++--------- 1 file changed, 52 insertions(+), 52 deletions(-) diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index affa704b..b06e9eb6 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -1,11 +1,11 @@ [[_interactive_staging]] -=== Interactive Staging +=== Etkileşimli İzlemleme (Staging) -In this section, you'll look at a few interactive Git commands that can help you craft your commits to include only certain combinations and parts of files. -These tools are helpful if you modify a number of files extensively, then decide that you want those changes to be partitioned into several focused commits rather than one big messy commit. -This way, you can make sure your commits are logically separate changesets and can be reviewed easily by the developers working with you. +Bu bölümde, belirli karmaları ve dosya parçalarını içerecek şekilde katkılarınızı hazırlamanıza yardımcı olabilecek birkaç etkileşimli Git komutunu göreceksiniz. +Bu araçlar, birçok dosyayı büyük ölçüde değiştirip, daha sonra bu değişikliklerin kocaman ve karışık tek bir katkı yerine, her biri odaklanmış birkaç farklı katkıya bölünmesini istediğinizde yardımcı olur. +Böylece, katkılarınızın mantıksal olarak ayrı değişiklik setleri olduğundan emin olabilirsiniz ve sizinle çalışan geliştiriciler tarafından kolayca incelenebilirler. -If you run `git add` with the `-i` or `--interactive` option, Git enters an interactive shell mode, displaying something like this: +`git add` komutunu `-i` veya `--interactive` seçeneğiyle çalıştırırsanız, Git etkileşimli bir kabuk moduna girer ve şuna benzer bir şey görüntüler: [source,console] ---- @@ -21,14 +21,14 @@ $ git add -i What now> ---- -You can see that this command shows you a much different view of your staging area than you're probably used to -- basically, the same information you get with `git status` but a bit more succinct and informative. -It lists the changes you've staged on the left and unstaged changes on the right. +Bu komut, muhtemelen alışık olduğunuzdan çok farklı bir şekilde izlem alanınızı görüntüler: temelde, `git status` ile aynı bilgileri alırsınız, ancak biraz daha özlü ve bilgilendiricidir. +Sol tarafta izleme aldığınız değişiklikleri, sağ tarafta ise izleme alınmamış değişiklikleri listeleyerek, size gösterir. -After this comes a ``Commands'' section, which allows you to do a number of things like staging and unstaging files, staging parts of files, adding untracked files, and displaying diffs of what has been staged. +Bunun ardından bir "Commands" (Komutlar) bölümü gelir. Bu bölüm size; dosyaları izleme alma ve izlemden kaldırma, dosyanın parçalarını izleme alma, izlenmeyen dosyaları ekleme ve izlemdeki dosyaların ne olduğunu görüntüleme gibi birçok şey yapmanıza olanak tanır. -==== Staging and Unstaging Files +==== Dosyaları İzleme Alma ve İzlemden Çıkarma -If you type `u` or `2` (for update) at the `What now>` prompt, you're prompted for which files you want to stage: +`What now>` sorusunda (güncelleme için) `u` veya `2` yazarsanız, hangi dosyaları izlemlemek istediğinizi seçmeniz istenir: [source,console] ---- @@ -40,7 +40,7 @@ What now> u Update>> ---- -To stage the `TODO` and `index.html` files, you can type the numbers: +`TODO` ve `index.html` dosyalarını izleme almak için numaralarını yazabilirsiniz: [source,console] ---- @@ -52,8 +52,8 @@ Update>> 1,2 Update>> ---- -The `*` next to each file means the file is selected to be staged. -If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you: +Her dosyanın yanındaki `*`, dosyanın izleme konacağı anlamına gelir. +`Update>>` sorusuna bir şey yazmadan Enter tuşuna bastığınızda, Git seçilen her şeyi alır ve sizin için izleme ekler: [source,console] ---- @@ -70,8 +70,8 @@ What now> s 3: unchanged +5/-1 lib/simplegit.rb ---- -Now you can see that the `TODO` and `index.html` files are staged and the `simplegit.rb` file is still unstaged. -If you want to unstage the `TODO` file at this point, you use the `r` or `3` (for revert) option: +Şimdi `TODO` ve `index.html` dosyalarının izleme alındığını ve `simplegit.rb` dosyasının hala izleme alınmadığını görebilirsiniz. +Bu noktada `TODO` dosyasını izlemlemek istemiyorsanız, `r` veya geri almak için (revert) `3` seçeneğini kullanabilirsiniz: [source,console] ---- @@ -92,7 +92,7 @@ Revert>> [enter] reverted one path ---- -Looking at your Git status again, you can see that you've unstaged the `TODO` file: +Tekrar Git durumunuza baktığınızda, `TODO` dosyasını izleme alınmadığını görebilirsiniz: [source,console] ---- @@ -106,9 +106,9 @@ What now> s 3: unchanged +5/-1 lib/simplegit.rb ---- -To see the diff of what you've staged, you can use the `d` or `6` (for diff) command. -It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. -This is much like specifying `git diff --cached` on the command line: +İzleme aldığınız değişikliklerin farkını (diff) görmek için `d` veya `6` (diff için) komutunu kullanabilirsiniz. +Bu, izlemlediğiniz dosyaların bir listesini gösterir ve izlemlenenlerin farkını görmek istediğiniz dosyaları seçebilirsiniz. +Bu, komut satırına `git diff --cached` yazmak gibidir: [source,console] ---- @@ -133,14 +133,14 @@ index 4d07108..4335f49 100644