diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index df26e5c6..b846b9d2 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,44 +1,44 @@ -=== 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 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), 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 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 +==== 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 (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))) -Uzun yıllar boyunca bu sistem, versiyon kontrol sistemleri için standart oldu. +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, 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 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. @@ -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 (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. +İş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 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. 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. 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: 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] ---- 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: <>) 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] ---- diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 6ece57e8..a29a3130 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 +==== Farklılıklar Değil, Anlık Pozlar -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 halini 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: diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 2c9c7c02..13e1b91d 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 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. -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, 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,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ı 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] ---- $ 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,16 @@ $ 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 +59,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] ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index ea7a21ca..21994f0e 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 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 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. + + [[_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 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. -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 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. -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ı 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] ---- @@ -50,38 +57,39 @@ $ 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 Kopyalama (Klonlama) -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 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: <>). -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 kopyalayabilirsiniz.(((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 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: +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] ---- $ 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. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index d6b30b74..2aba4ee3 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,27 @@ -=== 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 pozlarını (snapshot) 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 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. -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 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. -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, 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. -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] +.Dosyalarınızın durumunun yaşam döngüsü. +image::images/lifecycle.png[Dosyalarınızın durumunun yaşam döngüsü.] [[_checking_status]] -==== Checking the Status of Your Files +==== Dosyalarınızın Durumunu Denetleme -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 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,14 +31,16 @@ 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 yoktur. +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. +Bunda endişelenmenizi gerektirecek bir durum yoktur. +<> ünitesinde dalları (branch) ve işaretçileri (reference) 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 +49,31 @@ $ 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) ---- -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ü `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 "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]] -==== 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ırın: [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 takip edildiğini (tracked) ve kaydedilmek üzere izleme alındığını görebilirsiniz: [source,console] ---- @@ -83,15 +87,17 @@ 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 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ı izleme ekler. -==== Staging Modified Files +==== Değiştirilmiş Dosyaları İzleme 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 +117,12 @@ 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 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ı 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] ---- @@ -131,10 +138,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 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: [source,console] ---- @@ -156,12 +163,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ş. +Peki neden böyle oldu!? +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ü izleme almak için tekrar `git add` çalıştırmanız gerekir: [source,console] ---- @@ -176,11 +183,11 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== Özet-Durum 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 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] ---- @@ -192,18 +199,19 @@ 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 `??`, 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 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]] -==== 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 +220,77 @@ $ 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` (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. +Böylece Git reponuzda görmek istemediğiniz dosyaları yanlışlıkla katkı olarak işlemezsiniz. -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 şunlardır: -* 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 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 +# .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 dizinlerindeki 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 +==== İzleme Alınmış (Staged) ve Alınmamış (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` 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. -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 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] ---- @@ -295,7 +309,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 izleme almadığınızı görmek için herhangi bir bayrak (parametre) kullanmadan `git diff' yazın: [source,console] ---- @@ -316,11 +330,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, 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. -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 katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız `git diff --staged` komutunu kullanabilirsiniz. +Bu komut, izlemdeki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır: [source,console] ---- @@ -334,11 +348,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 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. -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ı 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] ---- @@ -359,7 +373,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged: +Artık neyin izleme alınmamış olduğunu görmek için '`git diff` komutunu kullanabilirsiniz: [source,console] ---- @@ -375,7 +389,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 izleme aldığınızı görmek için `git diff --cached` (`--staged` ve `--cached` eşanlamlıdır) komutunu kullanabilirsiniz: [source,console] ---- @@ -396,33 +410,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 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. ==== [[_committing_changes]] -==== Committing Your Changes +==== Değişiklikleri Katkı Olarak İşlemek -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 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ğ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] ---- $ 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 +456,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 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) 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. -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 katkı mesajınızı `commit` komutuyla aynı satırda yazabilirsiniz: [source,console] ---- @@ -458,19 +472,20 @@ $ 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 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. -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. +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. -==== Skipping the Staging Area +==== İzlem 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: +İ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] ---- @@ -489,18 +504,20 @@ $ 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 katkı işlemeden ö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 katkılarınıza 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 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. -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 +534,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 izlem alanına almış olursunuz: [source,console] ---- @@ -532,58 +549,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 katkı işleminizde dosya kaybolacak ve artık izlenmeyecektir. +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. -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 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 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] ---- $ 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 +614,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 +623,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ğ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. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index a150fbf6..140bd3c5 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,26 +1,27 @@ [[_remote_repos]] -=== Working with Remotes - -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. - -[NOTE] -.Remote repositories can be on your local machine. +=== Uzak Repo ile Çalışmak + +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 repolar 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 sunucularda olduğu gibi yine de tüm standart itme (push), çekme (pull) ve getirme (fetch) 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 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] ---- @@ -36,7 +37,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 +46,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 +65,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 bu ekrandan bu çıkarımda bulunmak 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 +88,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 +103,59 @@ 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 Getirme ve Çekme -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 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. -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), 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]] -==== Pushing to Your Remotes +==== Kodlarınızı Uzak Sunucuya İtmek -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 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: [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 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]] -==== 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 +173,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 söyler. +Ayrıca çekme yaptığı 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 +204,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 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. -==== 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 +220,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 (referans) 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 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] ---- @@ -225,4 +232,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. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 0ae6ae7a..094efd3c 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 (((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 (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. -==== Listing Your Tags +==== Etiketlerinizi Listeleme -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 çok 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,33 @@ v1.8.5.4 v1.8.5.5 ---- -[NOTE] -.Listing tag wildcards requires `-l` or `--list` option +[NOT] +.Joker 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 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 katkının 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. +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]] -==== Annotated Tags +==== Açıklamalı Etiketler (((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` (annotated) bayrağı da belirtmektir:(((git commands, tag))) [source,console] ---- @@ -73,10 +76,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` (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. -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 katkıyla birlikte görebilirsiniz: [source,console] ---- @@ -94,14 +97,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 katkı bilgisini göstermeden önce etiketleme bilgisini, etiketleme tarihini ve açıklama mesajını gösterir. -==== Lightweight Tags +==== Hafif Etiketler (((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: +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: [source,console] ---- @@ -114,8 +117,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 katkıyı gösterir: [source,console] ---- @@ -127,10 +130,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: +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 ---- -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`` katkısını işlerken "v1.2" şeklinde etiketlemeyi unuttuğunuzu varsayalım. +Bunu sonradan da ekleyebilirsiniz. +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 ---- -You can see that you've tagged the commit:(((git commands, tag))) +Artık katkıyı etiketlediğinizi görebilirsiniz:(((git commands, tag))) [source,console] ---- @@ -183,11 +186,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 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 +204,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 +218,20 @@ 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 kopyaladığı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 iter ==== -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 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. ==== -==== Deleting Tags +==== 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: -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 +239,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 +251,20 @@ 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 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. -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 Denetlemek -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 +287,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 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 "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] ---- @@ -289,4 +297,5 @@ $ 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 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. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index a6780602..cedbe9d8 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 -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. +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. -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 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ı izlem alın ve `--amend` seçeneğini kullanarak yeniden katkılayı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 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. -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ı "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. -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, 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] ---- @@ -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 katkınızın ilk katkınızın yerini aldığı tek bir katkı 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 (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 ö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. -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 +==== İzleme Alınmış Dosyayı izlemden Çıkarmak -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 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] ---- @@ -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ı aşamadan çıkarmak için bu yönergeyi 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 (izlemde) 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 ş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. -==== Unmodifying a Modified File +==== Değiştirilmiş Dosyadaki Değişikliği Geri Alma -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 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: [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ğiniz oldukça açık bir şekilde anlatmaktadır. +Hadi söyleneni yapalım: [source,console] ---- @@ -125,17 +126,19 @@ 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 ö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! ===== -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, <> 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. -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_ 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. diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 373cc128..d82178db 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 +=== Katkı 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ç 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. -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,15 @@ 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 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. -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ı 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. -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 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 ---- -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 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 katkı işlemine ilişkin bazı kısaltılmış istatistikleri görmek istiyorsanız `--stat` seçeneğini kullanabilirsiniz: [source,console] ---- @@ -127,14 +128,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 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. -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 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` (tastamam) 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 +146,9 @@ 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 +158,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`'ın 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` | 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 +| `%p` | Ana hashler (kısa) +| `%an` | Yazar adı +| `%ae` | Yazar e-posta adresi +| `%ad` | Yazım tarihi (--date=option) +| `%ar` | Yazım tarihi, göreli +| `%cn` | Geliştirici adı +| `%ce` | Geliştirici e-posta 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 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. -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: +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] ---- @@ -202,85 +205,86 @@ $ 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 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` | 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 (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 |================================ -==== 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 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 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. -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 katkıların 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öreli 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 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. -[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 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. + ==== -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: +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] ---- $ 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` 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. -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 örnek 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 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 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 |================================ -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 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] ---- @@ -294,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 ---- -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 katkıdan, bu kıstaslara uyan sadece 6'sını görebilirsiniz. -[TIP] -.Preventing the display of merge commits +[İPUCU] +.Birleştirme katkılarının 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 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. ==== 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..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,31 +1,31 @@ -=== Basic Branching and Merging +=== Kısaca Dallandırma ve Birleştirme Temelleri -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 iş paketi (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 itin. +. Asıl iş paketinize geri dönün ve çalışmaya devam edin. [[_basic_branching]] -==== Basic Branching +==== 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` (branch) 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 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: [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] ---- @@ -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` (delete) 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 +==== Birleştirme (((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 üç poz +image::images/basic-merging-1.png[Tipik bir birleştirmede kullanılan üç poz.] -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 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. -.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 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: [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ı izleme almak, 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 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] ---- @@ -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 izleme 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. diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index 3b384bab..a1591c0f 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` 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. -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 diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 1041d564..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]] -=== Branches in a Nutshell +=== 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ünden hatırlayabileceğiniz gibi Git, verileri bir dizi değişiklik veya farklılık olarak değil, bir dizi _poz_ 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, 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. -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 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,65 +17,68 @@ $ 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 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))) -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ı metaverisini 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, 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 öncel katkılar +image::images/commits-and-parents.png[Katkı ve öncel 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 `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. -[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 -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] ---- @@ -85,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] ---- @@ -113,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 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. -[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] ---- @@ -148,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] ---- @@ -171,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 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. -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 `. ==== diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index c9e48ede..52779b53 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -1,29 +1,28 @@ [[_rebasing]] -=== Rebasing +=== Yeniden 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` (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. -==== The Basic Rebase +==== Kısaca Yeniden Temelleme -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 _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))) -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 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 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. -.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 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. -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 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. -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 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. -==== More Interesting Rebases +==== Daha Detaylıca Yeniden 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. +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. +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 yeniden 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 yeniden 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 dala yeniden temelleme +image::images/interesting-rebase-2.png[Tematik bir daldan yeni bir tematik dala yeniden 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 ana dal üzerine (burada `master`) yeniden 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 yeniden 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 yeniden temelleme +image::images/interesting-rebase-4.png[`server` dalını `master` dalının üzerine yeniden temelleme.] -Then, you can fast-forward the base branch (`master`): +Ardından, ana 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] ---- @@ -129,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 +==== Yeniden 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: +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: -*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ı yeniden 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 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. -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ı 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: -.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 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]] -.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, 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."] -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 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]] -==== Rebase When You Rebase +==== Yeniden 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, 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. -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 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. -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 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ş yeniden temelleme (force-push rebase) üzerine temelleme +image::images/perils-of-rebasing-5.png[Zorla itilmiş yeniden 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, 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). -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` varsayılan olsun 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ı 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. -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 +==== Yeniden Temelleme ve Birleştirme (((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. +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. -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 "yeniden 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 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. -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 yeniden temelleme yaparak geçmişi temizlemektir, ancak herhangi bir sunucuya ittiğiniz bir şeyi asla yeniden temelleme yapmamaktır. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 7da23f97..d665730f 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -1,71 +1,75 @@ [[_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 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. + +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 -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 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. -.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 getirir, 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 (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. -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 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 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]] -==== Pushing +==== İtme (((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 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. + +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. -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] ---- @@ -79,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 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 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 getirdiğinde, sunucunun `serverfix` dalının versiyonuna dair referansı, uzak dal `origin/serverfix` altında olacaktır: [source,console] ---- @@ -111,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 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. -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] ---- @@ -124,20 +130,20 @@ 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 +==== 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ı' 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. -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] ---- @@ -146,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] ---- @@ -156,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] ---- @@ -165,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] ---- @@ -175,15 +181,15 @@ $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ---- -[NOTE] -.Upstream shorthand +[NOT] +.Üstakım (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 ü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}+++))) ==== -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] ---- @@ -194,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))) -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] ---- @@ -234,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. diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 4ae66a76..b57f05da 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 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. -==== 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 veya main) 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 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]] -==== Topic Branches +==== Tematik Dallar (((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 (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. -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 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." diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 6ed59b1f..477eec76 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ı 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. +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 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. -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[]. diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 1bc42577..d752959c 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. 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..b247aaeb 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ı 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 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 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] ---- @@ -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 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 katkı, referans 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 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. -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ı 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 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. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index a17d0e5d..7d00f671 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 (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. -==== 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 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. -===== 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_ (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 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. -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. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index b0c4572d..1fa25c5f 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. diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index 6828f64e..abee4a4b 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 (Hosting) 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 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. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 946cf5ae..f4fc89a4 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -1,98 +1,99 @@ -=== 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] ---- $ 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 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. -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 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, 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: [source,console] ---- @@ -103,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 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). -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. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 17fd9dbd..3a64c720 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))) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 60bdd309..28293722 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[] ==== diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 56a13aa2..0a594a33 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şiminde Rol Almak (((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ş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? +Ç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 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. -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 Ekipler (((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, 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. -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.] -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: +.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 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 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: [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,32 +307,34 @@ 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 +==== Ö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. + +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 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. +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: -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: +Önce `featureA` için yeni bir dal oluşturur ve orada bazı çalışmalar yapar: [source,console] ---- @@ -349,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] ---- @@ -360,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 temelleyerek tematik bir dal açar: [source,console] ---- @@ -372,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] ---- @@ -386,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] ---- @@ -403,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] ---- @@ -414,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. +Zaten Josie'nin bir kökdal olarak başlattığı `featureBee` mevcut olduğundan, Jessica _oraya_ itmek istiyor. +Ve bunu şöyle yapıyor: [source,console] ---- @@ -425,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] ---- @@ -440,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] ---- @@ -452,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] ---- @@ -465,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] ---- @@ -478,36 +477,37 @@ 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 +==== Ç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 (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 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] ---- @@ -520,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ı 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, yeniden temeller veya ayıklarsa, ç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] ---- @@ -546,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] ---- @@ -571,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] ---- @@ -588,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 deneyebilir ve yürütücü için çatışmaları çözüp, ardından değişikliklerinizi yeniden gönderebilirsiniz. [source,console] ---- @@ -603,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 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] @@ -626,25 +629,27 @@ $ 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 +==== 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] ---- @@ -656,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] ---- @@ -667,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] ---- @@ -702,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] ---- @@ -725,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] ---- @@ -738,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] ---- @@ -752,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] ---- @@ -765,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] ---- @@ -785,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. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 124fbad7..7fae7709 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) 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. + `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. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 81de7af8..984e1a4a 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,20 +64,21 @@ 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` +===== `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] ---- @@ -87,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] ---- @@ -99,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] ---- @@ -117,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] ---- @@ -136,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] ---- @@ -147,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] ---- @@ -162,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] ---- @@ -177,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 +==== Uzak Dallara Geçmek (((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] ---- @@ -196,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] ---- @@ -218,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] ---- @@ -246,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] ---- @@ -282,109 +287,113 @@ 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 +===== İş 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ı 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. +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] ---- @@ -394,44 +403,45 @@ 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 +==== 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] ---- @@ -441,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] ---- @@ -455,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] ---- @@ -463,30 +474,30 @@ $ 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. -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] ---- @@ -494,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] ---- @@ -517,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] ---- @@ -553,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. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 56fc5c84..fe522fc5 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,95 +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. -.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. +E-posta ile gönderilen linki tıklayın ve işleme devam edin. +Daha sonra göreceğiniz üzere bu çok önemlidir. -[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 keys" (SSH anahtarı) bağlantısı. +image::images/ssh-keys.png["SSH keys" (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" (profil) bağlantısı. +image::images/your-profile.png["Profile" (profil) 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] +.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. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index edcc081a..c58a6c6e 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -1,68 +1,69 @@ -=== 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 "ç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. -[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. -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] ---- @@ -107,135 +108,142 @@ 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. + +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. -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. -.Pull Request creation page -image::images/blink-03-pull-request-open.png[Pull Request creation] +."Birleştirme İsteği" oluşturma sayfası +image::images/blink-03-pull-request-open.png["Birleştirme İsteği" oluşturma] -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. +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. -[NOTE] +[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 +===== 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 + +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. -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. +===== Yama Olarak Birleştirme İsteği -===== Pull Requests as Patches +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. -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. +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. -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. +Ö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. -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. +===== Ana Repoyla Güncel Tutmak -===== Keeping up with Upstream +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] ---- @@ -270,122 +278,125 @@ 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. +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. -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]] -.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] ---- @@ -397,20 +408,20 @@ 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. -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] ---- @@ -420,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] ---- @@ -451,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 Tututun -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] ---- @@ -504,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] ---- @@ -518,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] ---- @@ -532,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. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 6a8c9bb0..a19d7b30 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -1,134 +1,136 @@ [[_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 + +<> 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. -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. +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. -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. -.Responses to emails are included in the thread. -image::images/maint-03-email-resp.png[Email response] +.E-postalara verilen yanıtlar zincirde yer alır. +image::images/maint-03-email-resp.png[E-posta cevabı] -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. +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. -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. +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 +===== 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] ---- @@ -143,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] ---- @@ -161,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] ---- @@ -177,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] ---- @@ -190,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] ---- @@ -203,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] ---- @@ -214,86 +216,85 @@ 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. +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>>. +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] ---- @@ -308,71 +309,71 @@ 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. -===== Changing the Default Branch +===== Varsayılan Dalı Değiştirmek -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. +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. [[_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 +===== 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. 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. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index b85917d7..ece13141 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -1,63 +1,64 @@ -=== 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. -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,32 +167,31 @@ 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. +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] ---- @@ -215,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] ---- @@ -276,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. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index d8b7e9d9..daf282b9 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -1,28 +1,28 @@ [[_advanced_merging]] -=== Advanced Merging +=== İleri Seviye Birleştirme -Merging in Git is typically fairly easy. -Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be surprised by one enormous conflict at the end of the series. +Git'te birleştirme genellikle çok kolaydır. +Git, başka bir dalı bir çok defa birleştirmeyi kolaylaştırdığı için; ufak çakışmaları sık sık çözerek, çok uzun ömürlü dallarınızı bile sürekli güncel tutabilir ve böylece en sonda devasa tek bir çakışmayla karşılaşmazsınız. -However, sometimes tricky conflicts do occur. -Unlike some other version control systems, Git does not try to be overly clever about merge conflict resolution. -Git's philosophy is to be smart about determining when a merge resolution is unambiguous, but if there is a conflict, it does not try to be clever about automatically resolving it. -Therefore, if you wait too long to merge two branches that diverge quickly, you can run into some issues. +Ancak, bazen zorlu çatışmalar ortaya çıkabilir. +Diğer bazı sürüm kontrol sistemlerinin aksine, Git birleştirme çakışması çözümünde "aşırı akıllı" olmaya çalışmaz. +Git'in felsefesi, birleştirme çözümünün net olduğunu belirlemede akıllı olmaktır. Ancak bir çakışma varsa, onu otomatik olarak çözmeye çalışmak konusunda akıllı davranmaz. +Bu nedenle, hızla ayrılan iki dalı birleştirmek için çok uzun süre beklerseniz, bazı sorunlarla karşılaşabilirsiniz. -In this section, we'll go over what some of those issues might be and what tools Git gives you to help handle these more tricky situations. -We'll also cover some of the different, non-standard types of merges you can do, as well as see how to back out of merges that you've done. +Bu bölümde, bu sorunların neler olabileceğini ve Git'in size bu daha zorlu durumlarla başa çıkmada yardımcı olmak için hangi araçları sunduğunu ele alacağız. +Ayrıca, yapabileceğiniz farklı, standart olmayan birleştirmelerin bazılarını ele alacak ve yaptığınız birleştirmelerden nasıl geri adım atılacağını göreceğiz. -==== Merge Conflicts +==== Birleştirme Çakışmaları -While we covered some basics on resolving merge conflicts in <>, for more complex conflicts, Git provides a few tools to help you figure out what's going on and how to better deal with the conflict. +Çok karmaşık çatışmalar için bazı temel adımları <> bölümünde ele almış olsak da, Git daha karmaşık çatışmaları çözmenize ve bunlarla daha iyi başa çıkmanıza yardımcı olmak için birkaç araç sağlar. -First of all, if at all possible, try to make sure your working directory is clean before doing a merge that may have conflicts. -If you have work in progress, either commit it to a temporary branch or stash it. -This makes it so that you can undo *anything* you try here. -If you have unsaved changes in your working directory when you try a merge, some of these tips may help you preserve that work. +Öncelikle, mümkünse, çatışma olabilecek birleştirmeyi yapmadan önce çalışma dizininizin temiz olduğundan emin olmaya çalışın. +Geliştirmeye devam ettiğiniz bir çalışmanız varsa, bunu geçici bir dalda katkılayın veya `stash` ile saklayın. +Bu burada denediğiniz *herhangi bir şeyi* geri almanızı sağlar. +Birleştirmeyi yaparken çalışma dizininizde kaydedilmemiş değişiklikleriniz varsa, verdiğimiz ipuçlarından bazıları bu çalışmayı korumanıza yardımcı olabilir. -Let's walk through a very simple example. -We have a super simple Ruby file that prints 'hello world'. +Şimdi çok basit bir örnek üzerinden ilerleyelim. +'hello world' yazısını yazdıran çok basit bir Ruby dosyamız var. [source,ruby] ---- @@ -35,8 +35,8 @@ end hello() ---- -In our repository, we create a new branch named `whitespace` and proceed to change all the Unix line endings to DOS line endings, essentially changing every line of the file, but just with whitespace. -Then we change the line ``hello world'' to ``hello mundo''. +Repomuzda, `whitespace` adında yeni bir dal oluşturuyoruz ve tüm Unix satır sonlarını DOS satır sonlarına çevirerek yolumuza devam ediyoruz. Esasında dosyanın her satırını sadece boşluklarla değiştirmiş olduk. +Ardından da ``hello world`` satırını ``hello mundo`` olarak değiştiriyoruz. [source,console] ---- @@ -70,7 +70,7 @@ $ git commit -am 'hello mundo change' 1 file changed, 1 insertion(+), 1 deletion(-) ---- -Now we switch back to our `master` branch and add some documentation for the function. +Şimdi `master` dalımıza geçiyoruz ve fonksiyon için bazı dokümentasyon belgeleri ekliyoruz. [source,console] ---- @@ -96,7 +96,7 @@ $ git commit -am 'document the function' 1 file changed, 1 insertion(+) ---- -Now we try to merge in our `whitespace` branch and we'll get conflicts because of the whitespace changes. +Şimdi `whitespace` dalını birleştirmeyi deneriz ve boşluk değişiklikleri nedeniyle çatışma alırız. [source,console] ---- @@ -107,11 +107,11 @@ Automatic merge failed; fix conflicts and then commit the result. ---- [[_abort_merge]] -===== Aborting a Merge +===== Birleştirmeyi İptal -We now have a few options. -First, let's cover how to get out of this situation. -If you perhaps weren't expecting conflicts and don't want to quite deal with the situation yet, you can simply back out of the merge with `git merge --abort`. +Şimdi birkaç seçeneğimiz var. +Öncelikle, bu durumdan nasıl çıkacağımızı ele alalım. +Belki de çatışmaları beklemiyordunuz ve şu anda durumla uğraşmak istemiyorsunuz; bu durumda `git merge --abort` komutu ile birleştirmeyi hemen iptal edebilirsiniz. [source,console] ---- @@ -125,21 +125,21 @@ $ git status -sb ## master ---- -The `git merge --abort` option tries to revert back to your state before you ran the merge. -The only cases where it may not be able to do this perfectly would be if you had unstashed, uncommitted changes in your working directory when you ran it, otherwise it should work fine. +`git merge --abort` seçeneği, birleştirmeyi çalıştırmadan önceki durumunuza geri çevirmeye çalışır. +Bu işlemi mükemmel bir şekilde yapamayabileceğiz tek durum, çalışma dizinizde birleştirmeyi çalıştırdığınızda kaydedilmemiş veya katkılanmamış değişiklikleriniz olmasıdır. Aksi takdirde sorunsuz çalışması beklenir. -If for some reason you just want to start over, you can also run `git reset --hard HEAD`, and your repository will be back to the last committed state. -Remember that any uncommitted work will be lost, so make sure you don't want any of your changes. +Eğer bir sebeple sıfırdan başlamak istiyorsanız, `git reset --hard HEAD` komutunu da çalıştırabilir ve reponun en son katkı işlenmiş durumuna geri dönebilirsiniz. +Unutmayın ki, katkılanmamış çalışmalarınız kaybolur, bu yüzden değişikliklerinizden hiçbirini birini istemediğinizden emin olun. -===== Ignoring Whitespace +===== Boşlukları (Whitespace) Yoksayma -In this specific case, the conflicts are whitespace related. -We know this because the case is simple, but it's also pretty easy to tell in real cases when looking at the conflict because every line is removed on one side and added again on the other. -By default, Git sees all of these lines as being changed, so it can't merge the files. +Bu özel senaryoda, çakışmalar boşluklarla ilgilidir. +Örnek basit olduğundan bunu biliyoruz, ancak gerçek durumlarda da çakışmayı incelediğinizde bu oldukça kolay anlaşılır. Çünkü her satır bir taraftan kaldırılır ve diğer tarafta yeniden eklenir. +Varsayılan olarak, Git tüm bu satırları değişmiş olarak görür, bu yüzden dosyaları birleştiremez. -The default merge strategy can take arguments though, and a few of them are about properly ignoring whitespace changes. -If you see that you have a lot of whitespace issues in a merge, you can simply abort it and do it again, this time with `-Xignore-all-space` or `-Xignore-space-change`. -The first option ignores whitespace *completely* when comparing lines, the second treats sequences of one or more whitespace characters as equivalent. +Ancak varsayılan birleştirme stratejisi argümanlar alabilir ve bunlardan birkaçı boşluk değişikliklerini doğru şekilde yok saymayla ilgilidir. +Birleştirmede çok sayıda boşluk sorunu olduğunu görürseniz, doğrudan birleştirmeyi iptal edip `-Xignore-all-space` veya `-Xignore-space-change` ile tekrarlayabilirsiniz. +İlk seçenek, satırları karşılaştırırken boşlukları *tamamen* yoksayar; ikincisi ise bir veya daha fazla boşluk karakteri dizilerini eşit kabul eder. [source,console] ---- @@ -150,28 +150,28 @@ Merge made by the 'recursive' strategy. 1 file changed, 1 insertion(+), 1 deletion(-) ---- -Since in this case, the actual file changes were not conflicting, once we ignore the whitespace changes, everything merges just fine. +Bu örnekte, gerçek dosya değişiklikleri çatışmıyordu. Dolayısıyla boşluk değişikliklerini yoksaydığımızda, her şey sorunsuz bir şekilde birleşir. -This is a lifesaver if you have someone on your team who likes to occasionally reformat everything from spaces to tabs or vice-versa. +Ekip üyelerinizden birinin ara sıra her şeyi (boşluklardan sekme karakterlerine veya tersi yönde) yeniden biçimlendirmek gibi bir karakteri varsa, bu özellik gerçekten hayat kurtarıcıdır. [[_manual_remerge]] -===== Manual File Re-merging +===== Manuel Olarak Yeniden Birleştirme -Though Git handles whitespace pre-processing pretty well, there are other types of changes that perhaps Git can't handle automatically, but are scriptable fixes. -As an example, let's pretend that Git could not handle the whitespace change and we needed to do it by hand. +Git boşluk ön işlemesini oldukça iyi bir şekilde ele alsa da, Git'in otomatik olarak halledemediği ancak betikle düzeltilebilecek diğer türde değişiklikler olabilir. +Örnek olması açısından, Git'in boşluk değişikliğini halledemediğini ve bunu kendimizin düzeltmesi gerektiğini varsayalım. -What we really need to do is run the file we're trying to merge in through a `dos2unix` program before trying the actual file merge. -So how would we do that? +Aslında yapmamız gereken şey, birleştirmeye çalıştığımız dosyayı, birleştirmeden önce bir `dos2unix` programından geçirmektir. +Peki, bunu nasıl yapabiliriz? -First, we get into the merge conflict state. -Then we want to get copies of my version of the file, their version (from the branch we're merging in) and the common version (from where both sides branched off). -Then we want to fix up either their side or our side and re-try the merge again for just this single file. +Öncelikle, çakışma durumuna geliyoruz. +Sonra, dosyanın kendi sürümümüzün, onların (birleştirmek istediğimiz dalın) sürümünün ve ortak sürümün (her iki tarafın da dallandığı yerden) kopyalarını almak istiyoruz. +Daha sonra, onların tarafını veya kendi tarafımızı düzeltip sadece bu tek dosya için birleştirmeyi tekrar denemek istiyoruz. -Getting the three file versions is actually pretty easy. -Git stores all of these versions in the index under ``stages'' which each have numbers associated with them. -Stage 1 is the common ancestor, stage 2 is your version and stage 3 is from the `MERGE_HEAD`, the version you're merging in (``theirs''). +Üç dosya sürümünü almak aslında oldukça kolaydır. +Git, bu sürümlerin hepsini izlemde `stages` altında, her birini kendiyle ilişkilendirilmiş numaralara sahip olmak üzede saklar. +1: ortak öncel, 2: sizin sürümünüz, ve 3: birleştirmeyi yaptığınız sürüm olan `MERGE_HEAD` 'den gelir. -You can extract a copy of each of these versions of the conflicted file with the `git show` command and a special syntax. +Çakışan dosyanın her bir sürümünü `git show` komutunu ve özel bir sözdizimini kullanarak çıkarabilirsiniz. [source,console] ---- @@ -180,7 +180,7 @@ $ git show :2:hello.rb > hello.ours.rb $ git show :3:hello.rb > hello.theirs.rb ---- -If you want to get a little more hard core, you can also use the `ls-files -u` plumbing command to get the actual SHA-1s of the Git blobs for each of these files. +Daha detaylı bir şekilde ilerlemek isterseniz, `ls-files -u` tesisat komutunu kullanarak bu dosyaların her biri için Git bloblarının gerçek SHA-1'lerini alabilirsiniz. [source,console] ---- @@ -190,9 +190,9 @@ $ git ls-files -u 100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb ---- -The `:1:hello.rb` is just a shorthand for looking up that blob SHA-1. +`:1:hello.rb`, bu blobun SHA-1'ini aramak için kullanılan bir kısaltmadır. -Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known `git merge-file` command which does just that. +Artık çalışma dizinimizde her üç izlem'in de içeriğine sahip olduğumuza göre, boşluk sorununu çözmek için onların tarafını elle düzeltebilir ve az bilinen `git merge-file` komutunu kullanarak dosyayı yeniden birleştirebiliriz. [source,console] ---- @@ -219,14 +219,14 @@ index 36c06c8,e85207e..0000000 hello() ---- -At this point we have nicely merged the file. -In fact, this actually works better than the `ignore-space-change` option because this actually fixes the whitespace changes before merge instead of simply ignoring them. -In the `ignore-space-change` merge, we actually ended up with a few lines with DOS line endings, making things mixed. +Bu noktada dosyayı güzel bir şekilde birleştirdik. +Aslında bu, boşluk değişikliklerini doğrudan yoksaymak yerine, gerçekte onları birleştirme öncesinde düzelttiği için `ignore-space-change` seçeneğinden daha iyi çalışır. +`ignore-space-change` birleştirmesinde, DOS satır sonlarına sahip olan satırlar biraz kafa karıştırıcıdır. -If you want to get an idea before finalizing this commit about what was actually changed between one side or the other, you can ask `git diff` to compare what is in your working directory that you're about to commit as the result of the merge to any of these stages. -Let's go through them all. +Bu katkıyı işlemeden önce, son bir kontrol amacıyla, gerçekte hangi tarafın hangi değişiklikleri yaptığını görmek isterseniz; katkılamak üzere çalışma dizinizde olup birleştirme sonucu olarak katkılayacağınız çalışmayı bu izlemlerdekilerle kıyaslamak için `git diff` komutunu kullanabilirsiniz. +Şimdi hepsini deneyelim. -To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours` +Sonucunuzu birleştirmeden önce dalınızdaki son durumuyla karşılaştırmak, diğer bir deyişle birleştirmenin ne tür değişiklikler getirdiğini görmek için `git diff --ours` komutunu çalıştırabilirsiniz. [source,console] ---- @@ -247,10 +247,11 @@ index 36c06c8..44d0a25 100755 hello() ---- -So here we can easily see that what happened in our branch, what we're actually introducing to this file with this merge, is changing that single line. +Bu şekilde, dalımızda olup biteni, bu dosyaya bu birleştirmeyle tanıttığımız şeyin, o tek satırı değiştirmek olduğunu kolaylıkla görebiliriz. -If we want to see how the result of the merge differed from what was on their side, you can run `git diff --theirs`. -In this and the following example, we have to use `-b` to strip out the whitespace because we're comparing it to what is in Git, not our cleaned up `hello.theirs.rb` file. + +Birleştirmenin sonucunun, onların tarafındakinden nasıl farklı olduğunu görmek istiyorsak, `git diff --theirs` komutunu çalıştırabiliriz. +Bu ve aşağıdaki örnekte, boşlukları çıkarmak için `-b' kullanmamız gerekiyor çünkü onu temizlenmiş 'hello.theirs.rb' dosyamızla değil, Git'tekiyle karşılaştırıyoruz. [source,console] ---- @@ -269,7 +270,7 @@ index e85207e..44d0a25 100755 end ---- -Finally, you can see how the file has changed from both sides with `git diff --base`. +Son olarak, dosyanın her iki taraftan da nasıl değiştiğini `git diff --base` ile görebilirsiniz. [source,console] ---- @@ -291,7 +292,7 @@ index ac51efd..44d0a25 100755 hello() ---- -At this point we can use the `git clean` command to clear out the extra files we created to do the manual merge but no longer need. +Bu noktada, manuel birleştirmeyi yapmak için oluşturduğumuz, ancak artık ihtiyaç duymadığımız ek dosyaları temizlemek için `git clean` komutunu kullanabiliriz. [source,console] ---- @@ -302,12 +303,12 @@ Removing hello.theirs.rb ---- [[_checking_out_conflicts]] -===== Checking Out Conflicts +===== Çakışmaları Kontrol Etme -Perhaps we're not happy with the resolution at this point for some reason, or maybe manually editing one or both sides still didn't work well and we need more context. +Belki bu aşamada bir nedenle çözümden memnun değilizdir. Ya da belki bir veya her iki tarafı manuel olarak düzenlemek çok da iyi çalışmamıştır ve daha fazla bağlam gerekmektedir. -Let's change up the example a little. -For this example, we have two longer lived branches that each have a few commits in them but create a legitimate content conflict when merged. +Örneği biraz değiştirelim. +Bu örnekte, her birinde birkaç katkı olan iki uzun ömürlü dalımız var, ancak birleştirildiğinde meşru bir içerik çakışması oluşturuyorlar. [source,console] ---- @@ -322,8 +323,8 @@ $ git log --graph --oneline --decorate --all * b7dcc89 initial hello world code ---- -We now have three unique commits that live only on the `master` branch and three others that live on the `mundo` branch. -If we try to merge the `mundo` branch in, we get a conflict. +Şimdi, yalnızca `master` dalında bulunan üç benzersiz katkımız var ve diğer üçü de `mundo` dalında bulunuyor. +`mundo` dalını birleştirmeye çalışırsak, bir çakışma alırız. [source,console] ---- @@ -333,8 +334,8 @@ CONFLICT (content): Merge conflict in hello.rb Automatic merge failed; fix conflicts and then commit the result. ---- -We would like to see what the merge conflict is. -If we open up the file, we'll see something like this: +Çakışmanın ne olduğunu görmek istiyoruz. +Dosyayı açarsak, şuna benzer bir şey göreceğiz: [source,ruby] ---- @@ -351,25 +352,24 @@ end hello() ---- -Both sides of the merge added content to this file, but some of the commits modified the file in the same place that caused this conflict. +Her iki tarafın da bu dosyaya içerik eklemiş, ancak bazı katkılar bu çakışmaya sebep olan dosyayı değiştirmiştir. -Let's explore a couple of tools that you now have at your disposal to determine how this conflict came to be. -Perhaps it's not obvious how exactly you should fix this conflict. -You need more context. +Şimdi, bu çatışmayı nasıl düzelteceğiniz tam olarak açık değilse, kullanabileceğiniz birkaç aracı keşfedelim. +Belki de bu çatışmayı nasıl çözeceğiniz tam olarak belli değil ve daha fazla bağlama ihtiyacınız var. -One helpful tool is `git checkout` with the `--conflict` option. -This will re-checkout the file again and replace the merge conflict markers. -This can be useful if you want to reset the markers and try to resolve them again. +Yararlı bir araç, `git checkout` komutuna eklenen `--conflict` seçeneğidir. +Bu komut dosyayı yeniden kontrol eder ve çakışma işaretlerini değiştirir. +İşaretleri sıfırlamak ve yeniden çözmeyi denemek istiyorsanız, bu faydalı olabilir. -You can pass `--conflict` either `diff3` or `merge` (which is the default). -If you pass it `diff3`, Git will use a slightly different version of conflict markers, not only giving you the ``ours'' and ``theirs'' versions, but also the ``base'' version inline to give you more context. +`--conflict` seçeneğine `diff3` veya `merge` (varsayılan) değerlerinden herhangi birini ekleyebilirsiniz. +Eğer `diff3` 'ü eklerseniz, Git biraz farklı bir çatışma işareti versiyonu kullanır; size sadece `ours` (bizimki) ve `theirs` (onlarınki) versiyonlarını değil, aynı zamanda daha fazla bağlam için `base` versiyonunu da içerir. [source,console] ---- $ git checkout --conflict=diff3 hello.rb ---- -Once we run that, the file will look like this instead: +Bunu çalıştırdıktan sonra, dosya şuna benzer olacaktır: [source,ruby] ---- @@ -388,25 +388,25 @@ end hello() ---- -If you like this format, you can set it as the default for future merge conflicts by setting the `merge.conflictstyle` setting to `diff3`. +Eğer bu formatı begendiyseniz, gelecekteki birleştirme çakışmalarında varsayılan olarak ayarlamak için `merge.conflictstyle` ayarını `diff3` olarak değiştirebilirsiniz. [source,console] ---- $ git config --global merge.conflictstyle diff3 ---- -The `git checkout` command can also take `--ours` and `--theirs` options, which can be a really fast way of just choosing either one side or the other without merging things at all. +`git checkout` komutu ayrıca `--ours` ve `--theirs` seçeneklerini alabilir, bu da bir tarafı seçmek veya diğerini tamamen birleştirmeden önce seçmenin çok hızlı bir yoludur. -This can be particularly useful for conflicts of binary files where you can simply choose one side, or where you only want to merge certain files in from another branch - you can do the merge and then checkout certain files from one side or the other before committing. +Bu, özellikle sadece bir tarafı seçmek istediğiniz ikili (binary) dosya çatışmaları veya başka bir dalda belirli dosyaları birleştirmek istediğiniz durumlar için kullanışlı olabilir; birleştirmeyi yapabilir ve ardından katkıyı işlemeden önce belirli dosyaları bir taraftan veya diğerinden seçebilirsiniz. [[_merge_log]] -===== Merge Log +===== Merge Günlüğü -Another useful tool when resolving merge conflicts is `git log`. -This can help you get context on what may have contributed to the conflicts. -Reviewing a little bit of history to remember why two lines of development were touching the same area of code can be really helpful sometimes. +Git birleştirme çatışmalarını çözerken yararlı bir başka araç da `git log` komutudur. +Bu komut çatışmalara katkıda bulunan faktörleri anlamanıza yardımcı olabilir. +Bazen iki geliştirme hattının aynı kod bölgesine dokunmasının nedenlerini hatırlamak için, biraz geçmişi gözden geçirmek gerçekten yardımcı olabilir. -To get a full list of all of the unique commits that were included in either branch involved in this merge, we can use the ``triple dot'' syntax that we learned in <>. +Bu birleştirmeye dahil olan her iki dalın da içerdiği benzersiz tüm katkıların tam bir listesini almak için, <> sözdizimini kullanabiliriz. [source,console] ---- @@ -419,10 +419,10 @@ $ git log --oneline --left-right HEAD...MERGE_HEAD > c3ffff1 changed text to hello mundo ---- -That's a nice list of the six total commits involved, as well as which line of development each commit was on. +Bu, her katkının hangi geliştirme hattında olduğuyla birlikte, sürece dahil olan toplam altı katkının güzel bir listesidir. -We can further simplify this though to give us much more specific context. -If we add the `--merge` option to `git log`, it will only show the commits in either side of the merge that touch a file that's currently conflicted. +Ancak, bunu çok daha spesifik bir bağlama sahip olması için biraz daha basitleştirebiliriz. +`git log` komutuna `--merge` seçeneğini eklersek, çakışmada olan bir dosyayı değiştiren katkıları gösterecektir. [source,console] ---- @@ -431,15 +431,15 @@ $ git log --oneline --left-right --merge > c3ffff1 changed text to hello mundo ---- -If you run that with the `-p` option instead, you get just the diffs to the file that ended up in conflict. -This can be *really* helpful in quickly giving you the context you need to help understand why something conflicts and how to more intelligently resolve it. +Eğer `-p` seçeneği ile çalıştırırsanız, çakışmaya neden olan dosyalara ilişkin farklılıkları alırsınız. +Bu, bir şeyin neden çakıştığını anlamanıza ve daha akıllıca nasıl çözeceğinize dair ihtiyacınız olan bağlamı hızlı bir şekilde sağlamak için *gerçekten* faydalı olabilir. -===== Combined Diff Format +===== Birleşik Fark Formatı -Since Git stages any merge results that are successful, when you run `git diff` while in a conflicted merge state, you only get what is currently still in conflict. -This can be helpful to see what you still have to resolve. +Git, başarılı olan her birleştirmeyi izleme alır; bu nedenle çakışma durumunda `git diff` komutunu çalıştırdığınızda sadece hala çakışma durumunda olanları alırsınız. +Bu, çözmeniz gerekenleri görmek için faydalı olabilir. -When you run `git diff` directly after a merge conflict, it will give you information in a rather unique diff output format. +Birleştirme çakışmasının hemen ardından `git diff` komutunu çalıştırdığınızda, size benzersiz bir formatta bir fark çıktısı verecektir. [source,console] ---- @@ -462,13 +462,13 @@ index 0399cd5,59727f0..0000000 hello() ---- -The format is called ``Combined Diff'' and gives you two columns of data next to each line. -The first column shows you if that line is different (added or removed) between the ``ours'' branch and the file in your working directory and the second column does the same between the ``theirs'' branch and your working directory copy. +Bu format ``Birleşik Fark`` olarak adlandırılır ve her satırın yanında iki sütun veriye sahiptir. +İlk sütun, bu satırın ``ours`` (bizim) dalı ve çalışma dizininizdeki dosya arasında farklı olup olmadığını (eklenmiş veya kaldırılmış olarak) gösterir ve ikinci sütun aynı şeyi ``theirs`` (onların) dalı ve çalışma dizininizdeki kopya arasında yapar. -So in that example you can see that the `<<<<<<<` and `>>>>>>>` lines are in the working copy but were not in either side of the merge. -This makes sense because the merge tool stuck them in there for our context, but we're expected to remove them. +Bu örnekte `<<<<<<<` ve `>>>>>>>` satırlarının çalışma kopyasında olduğunu ancak birleştirmenin her iki tarafında da olmadığını görebilirsiniz. +Birleştirme aracı bunları nelerin eklenip çıkarıldığını anlamamız için yerleştirdiğinden mantıklıdır, ancak bunları kaldırmamız beklenir. -If we resolve the conflict and run `git diff` again, we'll see the same thing, but it's a little more useful. +Çatışmayı çözer ve `git diff` komutunu yeniden çalıştırırsak, aynı şeyi göreceğiz, ancak bu sefer biraz daha kullanışlıdır. [source,console] ---- @@ -490,11 +490,11 @@ index 0399cd5,59727f0..0000000 hello() ---- -This shows us that ``hola world'' was in our side but not in the working copy, that ``hello mundo'' was in their side but not in the working copy and finally that ``hola mundo'' was not in either side but is now in the working copy. -This can be useful to review before committing the resolution. +Bu, ``hola world`` 'un tarafımızda olduğunu ancak çalışma kopyasında olmadığını, ``hello mundo`` 'nun onların arafında olduğunu ancak çalışma kopyasında olmadığını ve son olarak ``hola mundo`` 'nun her iki tarafta da olmadığını ancak şimdi çalışma kopyasında olduğunu gösterir. +Bu, çözümü katkı olarak işlemeden önce bir gözden geçirmek açısından faydalı olabilir. -You can also get this from the `git log` for any merge to see how something was resolved after the fact. -Git will output this format if you run `git show` on a merge commit, or if you add a `--cc` option to a `git log -p` (which by default only shows patches for non-merge commits). +Ayrıca, birleştirmenin nasıl çözüldüğünü sonradan görmek için herhangi bir birleştirmenin `git log` çıktısından da yararlanabilirsiniz. +Git, bir birleştirme katkısı üzerine `git show` komutunu çalıştırdığınızda veya bir `git log -p` komutuna (varsayılan olarak yalnızca birleştirme katkısı olmayan yamaları gösterir) `--cc` seçeneği eklediğinizde karşınıza bu formatı çıkarır. [source,console] ---- @@ -526,44 +526,44 @@ index 0399cd5,59727f0..e1d0799 ---- [[_undoing_merges]] -==== Undoing Merges +==== Birleştirmeyi Geri Almak -Now that you know how to create a merge commit, you'll probably make some by mistake. -One of the great things about working with Git is that it's okay to make mistakes, because it's possible (and in many cases easy) to fix them. +Artık bir birleştirme katkısı oluşturmayı nasıl yapacağınızı bildiğinize göre, muhtemelen bazen kazara kullanacaksınız. +Git ile çalışmanın harika yanlarından biri, hata yapmanın sorun olmadığıdır, çünkü onları düzeltmek mümkündür (ve birçok durumda kolaydır). -Merge commits are no different. -Let's say you started work on a topic branch, accidentally merged it into `master`, and now your commit history looks like this: +Birleştirme komutları da istisna değildir. +Diyelim ki bir konu dalında çalışmaya başladınız, bunu yanlışlıkla `master` dalına birleştirdiniz ve şimdi katkı geçmişiniz şöyle görünüyor: -.Accidental merge commit -image::images/undomerge-start.png[Accidental merge commit.] +.Kazara birleştirme katkısı +image::images/undomerge-start.png[Kazara birleştirme katkısı.] -There are two ways to approach this problem, depending on what your desired outcome is. +Bu sorunu çözmek için istediğiniz sonuca bağlı olarak iki farklı yaklaşım bulunmaktadır. -===== Fix the references +===== Referansları Düzeltmek -If the unwanted merge commit only exists on your local repository, the easiest and best solution is to move the branches so that they point where you want them to. -In most cases, if you follow the errant `git merge` with `git reset --hard HEAD~`, this will reset the branch pointers so they look like this: +Eğer istenmeyen birleştirme katkısı yalnızca yerel repoda varsa; en kolay ve en iyi çözüm, dalları istediğiniz yere işaret edecek şekilde taşımaktır. +Çoğu durumda, yanlış `git merge` işleminden sonra `git reset --hard HEAD~` komutunu takip ederseniz, bu, dal işaretçilerini aşağıdaki gibi sıfırlayacaktır: -.History after `git reset --hard HEAD~` -image::images/undomerge-reset.png[History after `git reset --hard HEAD~`.] +.`git reset --hard HEAD~` sonrası geçmiş +image::images/undomerge-reset.png[`git reset --hard HEAD~` sonrası geçmiş.] -We covered `reset` back in <>, so it shouldn't be too hard to figure out what's going on here. -Here's a quick refresher: `reset --hard` usually goes through three steps: +Bir önceki konumuzda `reset` komutunu ele aldık (`<>`), bu yüzden burada neler olup bittiğini anlamak çok zor olmamalı. +Hemen hatırlatalım: `reset --hard` genellikle üç adımdan oluşur: -. Move the branch HEAD points to. - In this case, we want to move `master` to where it was before the merge commit (`C6`). -. Make the index look like HEAD. -. Make the working directory look like the index. +1. Dalın HEAD'inin işaret ettiği yeri taşı. + Bu durumda, `master` 'ı birleştirme katkısından önceki konuma (`C6`) taşımak istiyoruz. +2. İndeksi HEAD'e benzet. +3. Çalışma dizinini indekse benzet. -The downside of this approach is that it's rewriting history, which can be problematic with a shared repository. -Check out <> for more on what can happen; the short version is that if other people have the commits you're rewriting, you should probably avoid `reset`. -This approach also won't work if any other commits have been created since the merge; moving the refs would effectively lose those changes. +Bu yaklaşımın dezavantajı, geçmişi yeniden yazmasıdır ve bu, paylaşılan bir repoda sorun olabilir. +Neler olabileceğine dair daha fazla bilgi için <> bölümüne göz atabilirsiniz; kısaca, yeniden yazdığınız katkıları kullanan başkaları da varsa, `reset` 'ten kaçınmanız gerekebilir. +Bu yaklaşım, birleştirmenin ardından başka bir katkı oluşturulduğu durumlarda da çalışmaz; işaretçileri taşımak bu değişiklikleri kaybetmeye yol açar. [[_reverse_commit]] -===== Reverse the commit +===== Katkıyı Geri Alma -If moving the branch pointers around isn't going to work for you, Git gives you the option of making a new commit which undoes all the changes from an existing one. -Git calls this operation a ``revert'', and in this particular scenario, you'd invoke it like this: +Eğer dal işaretçilerini taşımak sizin işinizi görmeyecekse, Git size mevcut bir katkıdan kaynaklanan tüm değişiklikleri geri alacak yeni bir katkı işleme seçeneği sunar. +Git, bu işlemi `revert` (geri alma) olarak adlandırır, ve bu senaryoda, onu şu şekilde çağırırsınız: [source,console] ---- @@ -571,17 +571,17 @@ $ git revert -m 1 HEAD [master b1d8379] Revert "Merge branch 'topic'" ---- -The `-m 1` flag indicates which parent is the ``mainline'' and should be kept. -When you invoke a merge into `HEAD` (`git merge topic`), the new commit has two parents: the first one is `HEAD` (`C6`), and the second is the tip of the branch being merged in (`C4`). -In this case, we want to undo all the changes introduced by merging in parent #2 (`C4`), while keeping all the content from parent #1 (`C6`). +`-m 1` bayrağı, hangi öncelin `mainline` (ana hat) olduğunu ve korunması gerektiğini belirtir. +`HEAD` 'e birleştirme çağrısında bulunduğunuzda (`git merge topic`), yeni katkı iki öncele sahiptir: birinci öncel `HEAD` (`C6`) ve ikinci öncel birleştirilen dalın ucudur (`C4`). +Burada, ikinci öncelin (`C4`) birleştirmesiyle gelen tüm değişiklikleri geri almak ama birinci öncelin (`C6`) tüm içeriğini de korumak istiyoruz. -The history with the revert commit looks like this: +Geri alma katkısı sonrasında geçmişimiz şöyle görünür: -.History after `git revert -m 1` -image::images/undomerge-revert.png[History after `git revert -m 1`.] +.`git revert -m 1` sonrası geçmiş +image::images/undomerge-revert.png[`git revert -m 1` sonrası geçmiş.] -The new commit `^M` has exactly the same contents as `C6`, so starting from here it's as if the merge never happened, except that the now-unmerged commits are still in `HEAD`'s history. -Git will get confused if you try to merge `topic` into `master` again: +Yeni katkı olan `^M`, tam olarak `C6` ile aynı içeriğe sahiptir. Bu yüzden buradan itibaren, birleştirilmemiş katkıların halâ `HEAD` 'in geçmişinde bulunması dışında, sanki birleştirme hiç olmamış gibidir. +`topic` 'i tekrar `master` 'a birleştirmeye çalışırsanız Git'in kafası karışır: [source,console] ---- @@ -589,13 +589,13 @@ $ git merge topic Already up-to-date. ---- -There's nothing in `topic` that isn't already reachable from `master`. -What's worse, if you add work to `topic` and merge again, Git will only bring in the changes _since_ the reverted merge: +`topic` 'te `master` 'dan ulaşılamayan bir şey yoktur. +Daha fenası, `topic` 'e iş ekler ve tekrar birleştirirseniz, Git _geri alınan birleştirmeden_ sonraki değişiklikleri getirecektir: -.History with a bad merge -image::images/undomerge-revert2.png[History with a bad merge.] +.Kötü birleştirilmiş geçmiş +image::images/undomerge-revert2.png[Kötü birleştirilmiş geçmiş.] -The best way around this is to un-revert the original merge, since now you want to bring in the changes that were reverted out, *then* create a new merge commit: +Bu durumda en iyi çözüm, özgün birleştirmeyi geri alıp (çünkü şimdi geri alınan değişiklikleri getirmek istiyorsunuz), *ardından* yeni bir birleştirme katkısı oluşturmaktır: [source,console] ---- @@ -604,31 +604,31 @@ $ git revert ^M $ git merge topic ---- -.History after re-merging a reverted merge -image::images/undomerge-revert3.png[History after re-merging a reverted merge.] +.Geri alınan bir birleştirmeyi yeniden birleştirdikten sonra geçmiş: +image::images/undomerge-revert3.png[Geri alınan bir birleştirmeyi yeniden birleştirdikten sonra geçmiş.] -In this example, `M` and `^M` cancel out. -`^^M` effectively merges in the changes from `C3` and `C4`, and `C8` merges in the changes from `C7`, so now `topic` is fully merged. +Bu örnekte, `M` ve `^M` birbirini iptal eder. +`^^M` katkısı, `C3` ve `C4` 'ten gelen değişiklikleri etkin bir şekilde birleştirirken, `C8` de, `C7`den gelen değişiklikleri birleştirir; böylece `topic` tamamen birleştirilmiş olur. -==== Other Types of Merges +==== Diğer Birleştirme Tipleri -So far we've covered the normal merge of two branches, normally handled with what is called the ``recursive'' strategy of merging. -There are other ways to merge branches together however. -Let's cover a few of them quickly. +Şimdiye kadar iki dalın normal birleştirilmesini ele aldık, bunlar genellikle birleştirmenin "özyinelemeli" (recursive) stratejisiyle ele alınır. +Ancak, dalları birleştirmenin başka yolları da vardır. +Hızlı bir şekilde birkaçını ele alalım. -===== Our or Theirs Preference +===== Bizim (ours) veya onların (theirs) tercihi -First of all, there is another useful thing we can do with the normal ``recursive'' mode of merging. -We've already seen the `ignore-all-space` and `ignore-space-change` options which are passed with a `-X` but we can also tell Git to favor one side or the other when it sees a conflict. +Öncelikle, normal "özyinelemeli" birleştirme moduyla yapabileceğimiz başka bir yararlı işlev daha var. +Zaten bir `-X` ile iletilen `ignore-all-space` ve `ignore-space-change` seçeneklerini gördük, ancak Git'e bir çakışma gördüğünde belli bir tarafı tercih etmesini söyleyebiliriz. -By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it. -If you would prefer for Git to simply choose a specific side and ignore the other side instead of letting you manually resolve the conflict, you can pass the `merge` command either a `-Xours` or `-Xtheirs`. +Varsayılan olarak, Git birleştirilmekte olan iki dal arasında bir çakışma gördüğünde; kodunuza birleştirme çakışma işaretçilerini ekler, dosyayı çakışmış olarak işaretler ve sizin çakışmayı çözmenize izin verir. +Eğer manuel olarak çözmenize gerek kalmadan, Git'in belli bir tarafı seçerek çakışmayı otomatik olarak çözmesini tercih ederseniz; `merge` komutuna `-Xours` veya `-Xtheirs` bayraklarını ekleyebilirsiniz. -If Git sees this, it will not add conflict markers. -Any differences that are mergeable, it will merge. -Any differences that conflict, it will simply choose the side you specify in whole, including binary files. +Eğer Git bunu görürse, çakışma işaretçilerini eklemeyecektir. +Birleştirilebilir tüm farkları ise birleştirir. +İkili (binary) dosyalar da dahil, çakışan tüm farklarda ise, tamamen belirttiğiniz tarafları seçer. -If we go back to the ``hello world'' example we were using before, we can see that merging in our branch causes conflicts. +Eğer önceki "hello world" örneğimize geri dönersek, kendi dalımıza birleştirmenin çatışmalara neden olduğunu görebiliriz. [source,console] ---- @@ -639,7 +639,7 @@ Resolved 'hello.rb' using previous resolution. Automatic merge failed; fix conflicts and then commit the result. ---- -However if we run it with `-Xours` or `-Xtheirs` it does not. +Ancak `-Xours` veya `-Xtheirs` ile çalıştırırsak, bu işaretçileri eklemeyecektir. [source,console] ---- @@ -652,17 +652,17 @@ Merge made by the 'recursive' strategy. create mode 100644 test.sh ---- -In that case, instead of getting conflict markers in the file with ``hello mundo'' on one side and ``hola world'' on the other, it will simply pick ``hola world''. -However, all the other non-conflicting changes on that branch are merged successfully in. +Bu durumda, dosyada bir tarafta ``hello mundo`` ve diğer tarafta ``hola world`` olan çatışma işaretçilerini almak yerine, sadece ``hola world`` 'ü seçecektir. +Ancak, bu dalda diğer çakışmayan tüm değişiklikler başarıyla birleştirilir. -This option can also be passed to the `git merge-file` command we saw earlier by running something like `git merge-file --ours` for individual file merges. +Bu seçenek ayrıca önceki gördüğümüz `git merge-file` komutuna da geçirilebilir, örneğin, bireysel dosya birleştirmeleri için `git merge-file --ours` şeklinde. -If you want to do something like this but not have Git even try to merge changes from the other side in, there is a more draconian option, which is the ``ours'' merge _strategy_. -This is different from the ``ours'' recursive merge _option_. +Eğer bunun gibi bir şey yapmak istiyorsanız ve Git'in diğer taraftaki değişiklikleri bile birleştirmeye çalışmasını istemiyorsanız, daha katı bir seçenek olan `ours` birleştirme _stratejisi_ vardır. +Bu, `ours` özyinelemeli birleştirme _seçeneğinden_ farklıdır. -This will basically do a fake merge. -It will record a new merge commit with both branches as parents, but it will not even look at the branch you're merging in. -It will simply record as the result of the merge the exact code in your current branch. +Bununla aslında sahte bir birleştirme yapılacaktır. +Birleştirmeye çalıştığınız dala bile bakmadan, her iki dalı da öncel kabul ederek yeni bir birleştirme katkısı kaydedecektir. +Sadece birleştirmenin sonucunu, mevcut dalınızdaki kodun tamamı olarak kaydeder. [source,console] ---- @@ -672,11 +672,11 @@ $ git diff HEAD HEAD~ $ ---- -You can see that there is no difference between the branch we were on and the result of the merge. +Görebileceğiniz gibi, bulunduğumuz dal ile birleştirmenin sonucu arasında herhangi bir fark yoktur. -This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on. -For example, say you branched off a `release` branch and have done some work on it that you will want to merge back into your `master` branch at some point. -In the meantime some bugfix on `master` needs to be backported into your `release` branch. -You can merge the bugfix branch into the `release` branch and also `merge -s ours` the same branch into your `master` branch (even though the fix is already there) so when you later merge the `release` branch again, there are no conflicts from the bugfix. +Birleştirme yaparken bunu, Git'i bir dalın zaten birleştirilmiş olduğu şeklinde kandırmak için kullanabilirsiniz. +Örneğin, bir `release` dalından yeniden dallandınız, bu dalda bazı çalışmalar yaptınız ve bu işleri bir noktada `master` dalınıza geri birleştirmek istiyorsunuz. +Ama bu arada, `master` üzerindeki bazı hata düzeltmelerinin `release` dalına alınması gerekiyor. +Hata düzeltme (bugfix) dalını `release` dalına birleştirebilir ve aynı dalı `master` dalınıza da `merge -s ours` ile (`bugfix` dalı zaten orada olmasına rağmen) birleştirebilirsiniz. Böylece daha sonra `release` dalını tekrar birleştirdiğinizde `bugfix` yüzünden çakışmalar olmaz. include::subtree-merges.asc[] diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 018b5054..12509f04 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -1,16 +1,16 @@ -=== Debugging with Git +=== Git'le Hata Ayıklama -In addition to being primarily for version control, Git also provides a couple commands to help you debug your source code projects. -Because Git is designed to handle nearly any type of content, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. +Git, öncelikle sürüm kontrolüne yönelik olmasının yanı sıra, kaynak kodu projelerinizde hata ayıklamanıza yardımcı olacak birkaç komut da sağlar. +Git neredeyse her türlü içeriği işleyecek şekilde tasarlandığından, bu araçlar oldukça genel amaçlı olsa dahi; işler ters gittiğinde hata veya sorumluyu bulmanıza yardımcı olabilirler. [[_file_annotation]] -==== File Annotation +==== Dosya Açıklaması (git blame) -If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. -It shows you what commit was the last to modify each line of any file. -So if you see that a method in your code is buggy, you can annotate the file with `git blame` to determine which commit was responsible for the introduction of that line. +Eğer kodunuzda bir hatayı bulduğunuzda, ne zaman ve neden eklendiğini öğrenmek istiyorsanız; herhangi bir dosyanın her bir satırını değiştiren son katkıyı gösteren dosya açıklaması genellikle en iyi aracınızdır. +Hir. +Bu nedenle, projenizde hatalı bir kod olduğunu görürseniz, `git blame` ile dosyayı açımlayarak; o satırın eklenmesinden sorumlu olan katkıyı belirleyebilirsiniz. -The following example uses `git blame` to determine which commit and committer was responsible for lines in the top-level Linux kernel `Makefile` and, further, uses the `-L` option to restrict the output of the annotation to lines 69 through 82 of that file: +Aşağıdaki örnekte, Linux çekirdeğindeki `Makefile` satırlarının hangisinden, hangi katkı ve katkılayıcının sorumlu olduğunu belirlemek için `git blame` kullanılır ve daha da ileri giderek, `-L` seçeneğini kullanarak bu dosyanın 69 ile 82 satırları arasındaki acıklamanın çıktısı kısıtlanır: [source,console] ---- @@ -31,18 +31,18 @@ b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $ 066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 82) endif ---- -Notice that the first field is the partial SHA-1 of the commit that last modified that line. -The next two fields are values extracted from that commit -- the author name and the authored date of that commit -- so you can easily see who modified that line and when. -After that come the line number and the content of the file. -Also note the `^1da177e4c3f4` commit lines, where the `^` prefix designates lines that were introduced in the repository's initial commit and have remained unchanged ever since. -This is a tad confusing, because now you've seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here. +Dikkat ederseniz, ilk alan, bu satırı son değiştiren katkının kısmi SHA-1'idir. +Sonraki iki alan, bu katkıdan çıkarılan değerlerdir -- katkı yazarı ve katkı tarihi -- böylece bu satırı kimin ve ne zaman değiştirdiğini kolayca görebilirsiniz. +Sonrasında satır numarası ve dosyanın içeriği gelir. +Ayrıca, `^1da177e4c3f4` katkı satırlarına dikkat edin, burada `^` ön eki, repo'nun ilk katkısında tanıtılan ve o zamandan beri değişmeden kalan satırları belirtir. +Git'in bir katkının SHA-1'ini değiştirmek için `^` ön ekini en az üç farklı şekilde kullandığını gördüğünüz için bu biraz kafa karıştırabilir, ancak burada ne anlama geliyor! -Another cool thing about Git is that it doesn't track file renames explicitly. -It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. -One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. -If you pass `-C` to `git blame`, Git analyzes the file you're annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. -For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`. -By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from: +Git'in başka harika bir özelliği de dosya adı değişikliklerini açıkça izlemiyor olmasıdır. +Anlık pozları kaydeder ve neyin ne şekilde yeniden adlandırıldığını sonradan örtük olarak çözmeye çalışır. +Bunun ilginç bir yanı da, ona kod hareketlerini çözmesini isteyebilmenizdir. +`git blame` komutuna `-C` seçeneğini işlerseniz, işaretlediğiniz dosyayı analiz eder ve eğer içindeki kod parçaları başka yerden kopyalanmışsa, orijinal olarak nereden geldiğini bulmaya çalışır. +Örneğin, `GITServerHandler.m` adlı bir dosyayı, içlerinden biri `GITPackUpload.m` adında, birden fazla dosyaya böldüğünüzü düşünelim. +`GITPackUpload.m` komutunu `-C` seçeneği ile işaretlediğinizde, kodun hangi bölümlerinin orijinal olarak nereden geldiğini görebilirsiniz: [source,console] ---- @@ -62,22 +62,23 @@ ad11ac80 GITPackUpload.m (Scott 2009-03-24 150) 56ef2caf GITServerHandler.m (Scott 2009-01-05 153) ---- -This is really useful. -Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file. -Git tells you the original commit where you wrote those lines, even if it was in another file. +Bu gerçekten kullanışlıdır. +Normalde, kodu kopyaladığınızda orijinal katkı, bu dosyadaki bu satırlara ilk dokunduğunuz zamandır. +Git size, başka bir dosyada olsa bile, bu satırları yazdığınız orijinal katkıyı söyler. + [[_binary_search]] -==== Binary Search +==== İkilik (binary) Arama (git bisect) -Annotating a file helps if you know where the issue is to begin with. -If you don't know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you'll likely turn to `git bisect` for help. -The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue. +Sorunun nerede başladığını bildiğinizde, dosyayı açıklamak daha olur. +Eğer neyin bozulduğunu bilmiyorsanız ve kodun en son düzgün çalıştığını bildiğiniz durumdan bu yana onlarca veya yüzlerce katkı yapıldıysa, muhtemelen yardım için `git bisect` yöntemine başvuracaksınız. +`bisect` komutu, bir sorunu tanımlamanıza yardımcı olmak için katkı geçmişinizde ikilik bir arama yapar ve olabildiğince hızlı bir şekilde hangi katkının soruna yol açtığını belirlemenize yardımcı olur. -Let's say you just pushed out a release of your code to a production environment, you're getting bug reports about something that wasn't happening in your development environment, and you can't imagine why the code is doing that. -You go back to your code, and it turns out you can reproduce the issue, but you can't figure out what is going wrong. -You can _bisect_ the code to find out. -First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you're on is broken. -Then, you must tell bisect when the last known good state was, using `git bisect good `: +Diyelim ki kodunuzu üretim ortamına yeni bir sürüm olarak gönderdiniz, geliştirme ortamınızda olmayan bir şey hakkında hata raporları alıyorsunuz ama kodun neden böyle bir şey yaptığını anlayamıyorsunuz. +Koda geri dönüyorsunuz ve sorunu yeniden üretebildiğinizi fark ediyorsunuz, ancak neyin yanlış gittiğini yine anlayamıyorsunuz. +Sorunu bulmak için _bisect_ komutunu kullanarak kodunuzu bölebilirsiniz. +Öncelikle işleri başlatmak için `git bisect start` komutunu çalıştırırsınız, sonra sistemde bulunduğunuz mevcut katkının bozuk olduğunu söylemek için `git bisect bad` komutu çalıştırırsınız. +Daha sonra, en son bilinen iyi durumun ne zaman olduğunu bisect'e bildirmeniz gerekir, bunu `git bisect good ` kullanarak yaparsınız: [source,console] ---- @@ -88,10 +89,10 @@ Bisecting: 6 revisions left to test after this [ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo ---- -Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. -At this point, you can run your test to see if the issue exists as of this commit. -If it does, then it was introduced sometime before this middle commit; if it doesn't, then the problem was introduced sometime after the middle commit. -It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey: +Git, son iyi katkı olarak işaretlediğiniz katkı (v1.0) ile şu anki kötü sürüm arasında yaklaşık 12 katkı olduğunu çözümledi ve sizin için ortadakini getirdi. +Bu noktada, bu katkı ile aynı sorunun var olup olmadığını görmek için testinizi çalıştırabilirsiniz. +Eğer varsa, o zaman sorun bu ortadaki katkıdan önceki bir zamanda ortaya çıkmıştır; eğer yoksa, o zaman sorun bu ortadaki katkıdan sonra bir zamandaki bir katkıdan kaynaklanmıştır. +Burada sorun olmadığını anlaşıldı ve bunu Git'e `git bisect good` yazarak bildirir ve yolculuğunuza devam edersiniz: [source,console] ---- @@ -100,8 +101,8 @@ Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing ---- -Now you're on another commit, halfway between the one you just tested and your bad commit. -You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`: +Şimdi, biraz önce test ettiğiniz katkıyla, kötü katkınız arasında bir katkıda bulunuyorsunuz. +Testinizi tekrar çalıştırırsınız ve bu katkının da bozuk olduğunu bulursunuz, bu yüzden bunu Git'e `git bisect bad` ile bildirirsiniz: [source,console] ---- @@ -110,8 +111,8 @@ Bisecting: 1 revisions left to test after this [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table ---- -This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. -It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug: +Bu katkı sorunsuzdur ve şimdi Git sorunun nerede başladığını belirlemek için gereken tüm bilgilere sahip olmuştur. +İlk kötü katkının SHA-1'ini size söyler ve bu katkıda değiştirilen bazı dosyaların bilgilerini gösterir, böylece bu hataya yol açabilecek olan şeyin ne olduğunu anlayabilirsiniz: [source,console] ---- @@ -127,17 +128,17 @@ Date: Tue Jan 27 14:48:32 2009 -0800 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config ---- -When you're finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you'll end up in a weird state: +İşiniz bittiğinde, başladığınız yere HEAD'inizi sıfırlamak için `git bisect reset` komutunu çalıştırmalısınız, aksi takdirde garip bir durumda kalırsınız: [source,console] ---- $ git bisect reset ---- -This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes. -In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`. -First, you again tell it the scope of the bisect by providing the known bad and good commits. -You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second: +Bu, bir projede ortaya çıkan bir hatayı kontrol etmek için yüzlerce katkıyı dakikalar içinde kontrol etmenize yardımcı olabilecek çok güçlü bir araçtır. +Aslında, eğer proje iyiyse "0" (sıfır) ve proje kötüyse "non-0" (sıfırdışı) sonuç dönderecek bir betiğiniz varsa, `git bisect` 'i tamamen otomatik hale getirebilirsiniz. +İlk olarak, bilinen kötü ve iyi katkıları belirterek bisect'in kapsamını tekrar söylersiniz. +Bunu yapmak için: ilk olarak bilinen kötü katkıları ve ikinci olarak bilinen iyi katkıları, `bisect start` komutuyla listeleyebilirsiniz: [source,console] ---- @@ -145,5 +146,5 @@ $ git bisect start HEAD v1.0 $ git bisect run test-error.sh ---- -Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit. -You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you. +Bunu yaparak, Git'in ilk bozuk katkıyı bulana kadar her bir çıkan katkıda `test-error.sh` betiğini otomatik olarak çalıştırmasını sağlarsınız. +Ayrıca, `make` veya `make tests` gibi sizin için otomatik testleri çalıştıran herhangi bir betiği de çalıştırabilirsiniz. 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