lucasvbr/first-contributions
1
0
Fork 0
mirror of https://github.com/LucasVbr/first-contributions.git synced 2026-05-13 17:21:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added Turkish language support (#93856)

Browse Source
This commit is contained in:
Talha
2025-02-07 21:07:47 +03:00
committed by GitHub
parent 976b288d12
commit 9de45d6514
17 changed files with 837 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Contributors.md
+6 -2
View File
@@ -3211,8 +3211,11 @@
- [Kelly Sun](https://github.com/xiyuansun)
- [Oladimeji](https://github.com/boladimeji834) Destined for More!
- [HarisChandio](https://github.com/HarisChandio) DhatteBayo!
[Hahaem1ly](https://github.com/hahaem1ly)
[TeefAlfadhli](https://github.com/TeefAlfadhli) Hello Teef is HERE
- [Hahaem1ly](https://github.com/hahaem1ly)
- [Talha Coşkun](https://github.com/ttalhacoskun)
- [Hahaem1ly](https://github.com/hahaem1ly)
- [Hahaem1ly](https://github.com/hahaem1ly)
- [TeefAlfadhli](https://github.com/TeefAlfadhli) Hello Teef is HERE
- [Raeef Chowdhury](https://github.com/Raeef-Chowdhury/) Aspiring 15 year old developer
- [Atilla Ertas](https://github.com/atillaertas1)
- [Rahul Shendre](https://github.com/rahulshendre) let's do it
@@ -3225,6 +3228,7 @@
- [Leon Fray](https://github.com/Leon-Fray)
- [Khizar Nadeem](https://github.com/KhiziNadeem)
- [Josue Ordonez](https://github.com/r4zu)
- [Zach Lindemuth](https://github.com/Zach-Lindemuth)
- [Soleil Herring](https://github.com/soleilherring)
- [Zach Lindemuth](https://github.com/Zach-Lindemuth)
- [Sayudha](https://github.com/mazaya-studio)
docs/additional-material/Things a non Programmer can do.tr.md
+135
View File
@@ -0,0 +1,135 @@
# Programcı Olmayan Birinin Yapabileceği Şeyler
## Dinlemeye Başlayın
Açık kaynak dünyasında her şey diğer insanlarla ilgilidir.
Bir ekibe katılmak istiyorsunuz, bu da topluluğu ve nasıl çalıştığını anlamanız gerektiği anlamına gelir.
Bir projeye girip *"Merhaba, bu projenin böyle olması gerektiğini düşünüyorum."* demek genellikle iyi bir yaklaşım olarak görülmez.
Bazı projeler bu tür bir yaklaşımı kabul edebilir, ancak proje uzun süredir devam ediyorsa bu tavrın benimsenme ihtimali düşüktür.
**Dinlemek, projenin neye ihtiyacı olduğunu anlamanın en iyi yoludur.**
### 1. **Bir e-posta listesine katılın**
Birçok proje için e-posta listesi, proje gelişimi hakkında ana iletişim kanalıdır.
Özellikle büyük projelerde birden fazla e-posta listesi bulunabilir.
Örneğin, *PostgreSQL* projesinin kullanıcı odaklı en az 12 ve geliştiricilere yönelik 6 farklı e-posta listesi vardır.
Başlangıç olarak, ana kullanıcı listesi ve ana geliştirici listesine abone olmanızı öneririm.
### 2. **Bir blog takip edin**
Ana geliştiriciler tarafından tutulan bloglar, gelecekteki sürümler ve gereksinimler hakkında bilgi verir.
Bazı projeler için *planet sitesi* (örneğin, `planet.gnome.org` veya `planet.mysql.com`) tüm güncellemeleri bir araya getirir.
Google'da `"planet <proje adı>"` şeklinde arama yaparak başlayabilirsiniz.
### 3. **Bir IRC kanalına katılın**
Birçok açık kaynak projesinin geliştiriciler ve kullanıcılar için özel IRC kanalları vardır.
Projenin web sitesini ziyaret ederek kanal adı ve bulunduğu IRC ağı hakkında bilgi edinebilirsiniz.
---
## Ticket (Hata Bildirimi) ile Çalışmak
Kod, her açık kaynak projesinin kalbidir, ancak kod yazmak tek katkı yolu değildir.
Projelerde yeni özellikler eklemeye ve hataları düzeltmeye odaklanılırken, sistemlerin bakımına yeterince zaman ayrılmayabilir.
Bu alanlara katkıda bulunarak bir projeye dahil olabilirsiniz.
### 4. **Bir hatayı teşhis edin**
Hatalar çoğu zaman eksik rapor edilir.
Bir hatayı analiz etmek ve sınıflandırmak, geliştiricilere zaman kazandırır.
Bir kullanıcı *"Yazılım X yaptığımda çalışmıyor"* dediyse, şu sorulara cevap arayarak sorunu detaylandırabilirsiniz:
- Hata tekrar edilebilir mi?
- Aynı hatayı oluşturmak için belirli adımlar var mı?
- Belirli bir tarayıcıda veya işletim sisteminde mi ortaya çıkıyor?
Bulduğunuz her şeyi hata raporuna ekleyerek projenin ilerlemesine yardımcı olabilirsiniz.
### 5. **Çözülen hataları kapatın**
Birçok hata raporu çözüldükten sonra sistemde açık olarak kalır.
Bunları temizlemek zaman alıcı olabilir, ancak proje için çok değerlidir.
- Eski hata raporlarını (1 yıl veya daha eski) gözden geçirin.
- Projenin sürüm notlarını kontrol ederek hatanın çözülüp çözülmediğini belirleyin.
- Hatayı yeni sürümde test edin, eğer hata artık yoksa raporu kapatın.
---
## Kod ile Çalışmak
Her seviyeden programcı, bir projeye katkıda bulunabilir.
Bir projede kod yazmak istiyorsanız, projeye nasıl katkı sağlandığını öğrenin.
Bazı projeler değişiklikleri doğrudan kabul ederken, bazıları kodun önce bir inceleme sürecinden geçmesini ister.
### 6. **Beta veya aday sürümü test edin**
Çoklu platform desteği olan projelerde, yeni sürümlerin test edilmesi büyük önem taşır.
Sürüm yöneticileri, beta sürümünü farklı platformlarda test etmek isteyen kullanıcılara ihtiyaç duyar.
Yapmanız gereken:
- Yazılımın son sürümünü indirip derlemek
- Farklı donanım ve işletim sistemlerinde çalışıp çalışmadığını kontrol etmek
- Test sonuçlarını geliştiricilere bildirmek
### 7. **Bir hatayı düzeltin**
Geliştiricilerin genellikle başladığı nokta burasıdır.
- Bir hata bularak çözmeye çalışın
- Çözümünüzü kod içinde belgeleyin
- Gerekirse bir test ekleyin
- Eğer hatayı çözemezseniz bile bulgularınızı hata kaydına ekleyin
### 8. **Bir test yazın**
Projelerin test sistemleri genellikle eksik olabilir.
*gcov* (C için) veya *Devel::Cover* (Perl için) gibi test kapsamı araçlarını kullanarak eksik alanları tespit edin.
Ardından bu alanları kapsayan testler yazın.
### 9. **Derleyici uyarılarını giderin**
Özellikle *C tabanlı projelerde*, derleyiciler bazen uyarılar verir.
Bunlar gerçek bir hataya işaret etmese bile, fazla uyarı almak kodun daha karışık görünmesine sebep olabilir.
Uyarıyı analiz edin ve gerçekten bir hata olup olmadığını belirleyin.
### 10. **Yorum ekleyin**
Eğer bir kod parçasını anlamakta zorlandıysanız, başkaları da zorlanabilir.
Kod içindeki kafa karıştırıcı bölgelere açıklayıcı yorumlar ekleyerek projeye katkıda bulunabilirsiniz.
---
## Dokümantasyon ile Çalışmak
Dokümantasyon genellikle projelerin ihmal edilen kısmıdır.
Projeyi uzun süredir geliştirenler, yeni gelenlerin nelere ihtiyacı olabileceğini gözden kaçırabilir.
### 11. **Bir örnek oluşturun**
Kodun veya aracın nasıl çalıştığını gösteren iyi örnekler, en az teknik belgeler kadar önemlidir.
- API veya kütüphane kullanımı için örnek kodlar yazın
- Komut satırı araçları için gerçek hayattan kullanım senaryoları oluşturun
- Arayüzlü uygulamalar için ekran görüntüleri ile açıklamalar ekleyin
---
## Topluluk ile Çalışmak
Açık kaynak sadece koddan ibaret değildir, topluluk da büyük önem taşır.
### 12. **Bir soruya cevap verin**
Birine yardımcı olmak, projenin büyümesine katkıda bulunmanın en iyi yollarından biridir.
Özellikle yeni başlayanlara karşı sabırlı olun ve onlara yol gösterin.
### 13. **Bir blog yazısı yazın**
Projeyle ilgili deneyimlerinizi paylaşarak iki şekilde yardımcı olabilirsiniz:
1. Projeye olan ilgiyi artırabilirsiniz.
2. Karşılaştığınız sorunlara çözümler sunarak başkalarına rehber olabilirsiniz.
### 14. **Bir web sitesini geliştirin**
Eğer web tasarımı konusunda bilginiz varsa, projenin web sitesini geliştirebilirsiniz.
Grafik tasarım ve logo gibi görsel öğeler konusunda da destek sağlayabilirsiniz.
### 15. **Teknik dokümantasyon yazın**
Bir yazılımın nasıl çalıştığını açıklamak için teknik dokümanlar oluşturabilirsiniz.
Özellikle açık kaynak projeler, güncellenmiş ve anlaşılır dokümanlara her zaman ihtiyaç duyar.
### 16. **Öğretin ve başkalarına yardımcı olun**
Bir konuyu öğretmek, onu öğrenmenin en iyi yoludur.
Açık kaynak projelerine katılan insanlara rehberlik ederek hem kendinizi geliştirir hem de topluluğa katkıda bulunmuş olursunuz.
Paylaşılan bilgi, daha fazla kişinin açık kaynak ekosistemine katkıda bulunmasını sağlar.
---
docs/additional-material/translations/Turkish/Useful-links-for-further-learning.tr.md
+36
View File
@@ -0,0 +1,36 @@
# Faydalı bağlantılar
Bu belge hayatımızı kolaylaştıran tüm ipuçları ve püf noktaları, blog yazıları ve faydalı web sitelerine adanmıştır. İster yeni başlayan olun, ister uzman, tüm ihtiyaçlarımızı karşılayacak harika bir referans noktasıdır. Bu sayfa, açık kaynak alanına yeni başlayan veya daha fazla bilgi edinmek isteyen herkese yardımcı olacak tüm yararlı bağlantıların bir dizini olarak hizmet vermeyi amaçlamaktadır.
## Liste
1. [Interactive tutorial to git](https://try.github.io)
2. [git - the simple guide](http://rogerdudler.github.io/git-guide/)
3. [On undoing, fixing, or removing commits in git](http://sethrobertson.github.io/GitFixUm/fixup.html)
4. [Git and GitHub tutorial translated to many languages](https://github.com/Roshanjossey/first-contributions)
5. [Merge Conflicts](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
6. [Resolving Merge Conflicts](https://githowto.com/resolving_conflicts)
7. [Basics of Git - The Simple Quick Start Guide](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
8. [Git Standards followed in our way of Spotify Agile Methodology](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
9. [Git Shortcuts](https://blog.praveen.science/git-shortcuts/)
10. [Official Git cheat sheet in many languages](https://services.github.com/on-demand/resources/cheatsheets)
11. [Git cheat sheet from Tower](https://www.git-tower.com/learn/cheat-sheets/git)
12. [Common Git Problems](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
13. [Git Rebase](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
14. [Beginner's Guide to Rebasing and Squashing](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
15. [Git Cheatsheet that shows correlations between commands and files](http://ndpsoftware.com/git-cheatsheet.html)
16. [How to contribute](https://opensource.guide/how-to-contribute/)
17. [Getting started with Open Source](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
18. [How to contribute](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
19. [Atlassians Git Tutorials](https://www.atlassian.com/git)
20. [Pull request reviews](https://help.github.com/articles/about-pull-request-reviews/)
21. [Another Interactive tutorial for git](https://learngitbranching.js.org/)
22. [Git commandline cheat-sheet](https://gist.github.com/davfre/8313299)
23. [Programming Books](https://github.com/EbookFoundation/free-programming-books)
24. [E-Book of professional tip and secrets](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
25. [tutorial about simple rules of become git professional](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
26. [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
27. [5 Useful Tips For A Better Commit Message](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
28. [Version Control using Git](https://ourcodingclub.github.io/2017/02/27/git.html)
29. [Version Control with Git](https://www.udacity.com/course/version-control-with-git--ud123)
Yararlı bulduğunuz bağlantıları eklemeye devam edin.
docs/additional-material/translations/Turkish/additional-material.tr.md
+60
View File
@@ -0,0 +1,60 @@
# **Ek Bilgiler**
Burada, temel Git talimatlarını zaten öğrendiğinizi varsayıyoruz.
Bu ek bilgiler, daha karmaşık durumlarda kullanabileceğiniz bazı Git komutlarını içermektedir.
## **Düzeltmeler ve Güncellemeler**
### **[Commitleri Düzeltme](amending-a-commit.by.md)**
Bu belge, uzak bir depodaki commit üzerinde nasıl değişiklik yapacağınızı açıklar.
> Eğer daha önce yaptığınız bir commit'i değiştirmek istiyorsanız, bu belgeyi okuyabilirsiniz.
### **[Git Yapılandırması](configuring-git.by.md)**
Bu belge, Git üzerindeki kullanıcı bilgilerini ve diğer ayarları nasıl değiştireceğinizi anlatır.
> Git ayarlarınızı daha konforlu hale getirmek istiyorsanız bu kılavuz faydalı olacaktır.
### **[Fork’unuzu Ana Depoyla Senkronize Etme](keeping-your-fork-synced-with-this-repository.by.md)**
Bu belge, kendi fork’unuzun ana depo ile nasıl senkronize edileceğini açıklar.
Projede tek başınıza değil, ekip içinde çalışacağınızı düşünerek senkronizasyonun önemli olduğunu unutmayın.
> Fork’unuz ana deponun *master* dalıyla senkronize değilse, buradaki adımları izleyin.
### **[Commit’i Farklı Bir Dala Taşıma](moving-a-commit-to-a-different-branch.by.md)**
Bu belge, bir commit’i farklı bir dala nasıl taşıyacağınızı anlatır.
> Eğer bir commit’i yanlış dala yaptıysanız ve taşımak istiyorsanız, buradaki adımları takip edebilirsiniz.
## **Dosya ve Dal Yönetimi**
### **[Dosya Silme](removing-a-file.by.md)**
Bu belge, bir dosyayı yerel deponuzdan nasıl sileceğinizi anlatır.
> Commit yapmadan önce bir dosyayı kaldırmak istiyorsanız, bu komutları öğrenmelisiniz.
### **[Bir Dalı Depodan Silme](removing-branch-from-your-repository.by.md)**
Bu belge, Git deposundan bir dalın nasıl kaldırılacağını açıklar.
> Bir *pull request* tamamlandıktan sonra ilgili dalı silmek için bu adımları takip edebilirsiniz.
### **[Merge Çakışmalarını Çözme](resolving-merge-conflicts.by.md)**
Bu belge, dal birleştirme sırasında ortaya çıkan çakışmaları nasıl çözebileceğinizi açıklar.
> Merge sırasında oluşabilecek sorunları nasıl çözeceğinizi öğrenmek için buradaki talimatları uygulayın.
## **Commit ve Değişiklik Yönetimi**
### **[Commit’i Geri Alma](reverting-a-commit.by.md)**
Bu belge, uzak bir depodaki commit’i nasıl geri alacağınızı açıklar.
> Eğer bir commit’i GitHub’a *push* ettiyseniz ve geri almak istiyorsanız, buradaki adımları takip edebilirsiniz.
### **[Commit’leri Birleştirme (Squashing)](squashing-commits.by.md)**
Bu belge, commit’leri *interactive rebase* kullanarak nasıl birleştireceğinizi anlatır.
> Eğer bir open-source projeye pull request gönderdiyseniz ve projenin yöneticisi commit’lerinizi tek bir commit’te toplamanızı istiyorsa, bu talimatları kullanabilirsiniz.
### **[Yerel Commit’i Geri Alma](undoing-a-commit.by.md)**
Bu belge, yerel deponuzdaki bir commit’i nasıl geri alacağınızı anlatır.
> Eğer bir commit sonrası değişiklikleri geri almak istiyorsanız, buradaki komutları uygulayabilirsiniz.
## **Ek Kaynaklar ve Bağlantılar**
### **[Faydalı Bağlantılar](Useful-links-for-further-learning.by.md)**
Bu dosya, blog yazıları, faydalı web siteleri, Git ipuçları ve açık kaynak geliştirme hakkında öneriler içermektedir.
> Açık kaynak dünyasına yeni başlayanlar ve kendini geliştirmek isteyenler için oldukça faydalı kaynaklar içerir.
Bu belgeler, Git ile çalışırken karşılaşabileceğiniz karmaşık senaryolar için rehber niteliğindedir.
Herhangi bir işlem yapmadan önce ihtiyacınıza uygun belgeyi okuyarak doğru adımları takip edebilirsiniz.
docs/additional-material/translations/Turkish/amending-a-commit.tr.md
+48
View File
@@ -0,0 +1,48 @@
# Commit Düzeltmeleri
Uzak bir depoya bir commit gönderdiğinizi ve daha sonra commit mesajında bir yazım hatası yaptığınızı veya bu son commite bir satır eklemeyi unuttuğunuzu fark ettiğinizi hayal edin. Bu durumda ne yapmalısınız? İşte bu belgede tam olarak bundan bahsedeceğiz.
## Github'a Gönderilmiş (Push Edilmiş) Son Commit'in Mesajını Nasıl Değiştirirsiniz?
Bunu bir dosyayı düzenlemeye açmadan yapmak için:
* ```git commit --amend -m "yeni commit mesajınız"``` komutunu girin.
* Ardından değişiklikleri Github'a göndermek için ```git push origin <branch-name>``` komutunu çalıştırın.
Not: Eğer sadece ```git commit --amend``` yazarsanız, bir metin editörü açılır ve commit mesajını düzenlemenizi önerir.
``-m`` anahtarını kullanmak editörün açılmasını engeller.
## Bir Committe Nasıl Değişiklik Yapılır?
Eğer bir dosyada küçük bir değişiklik yapmayı unuttuysak, örneğin bir kelimeyi değiştirmeyi unuttuysak ve bu commit zaten uzak depoya gönderildiyse ne yapmalıyız?
Örneğin, commit geçmişim şu şekilde olsun:
`` `
g56123f create file bot file
a2235d updated contributor.md
a5da0d modified bot file
`` `
Diyelim ki bot file dosyasına bir kelime eklemeyi unuttum.
Bunu düzeltmek için iki yol var. İlk yol, bu değişikliği içeren yeni bir commit oluşturmaktır, örneğin:
`` `
g56123f create file botfile
a2235d updated contributor.md
a5da0d modified botfile
b0ca8f added single word to botfile
`` `
İkinci yol ise a5da0d commit'ini düzeltmek, bu eksik kelimeyi eklemek ve bu değişiklikleri Github'a tek bir commit olarak göndermektir.
İkinci yol tercih edilir çünkü bu sadece küçük bir değişiklikle ilgilidir.
Bunu başarmak için şu adımları izleyeceğiz:
* Dosyayı değiştirin. Bu durumda, botfile dosyasını değiştirip daha önce unuttuğum kelimeyi ekleyeceğim.
* Ardından, bu dosyayı ```git add <dosya-adı>``` komutuyla indeksleyin.
Normalde indekslemeden hemen sonra `` `git commit -m" commit mesajımız "` `` yaparız, değil mi? Ancak bu durumda amacımız önceki commit'i düzeltmek olduğu için bunun yerine şu komutu çalıştıracağız:
* ```git commit --amend```
Bu, bir metin editörü penceresi açacak ve commit mesajında değişiklik yapma imkanı sunacaktır. Mesajı gerçekten düzenleyebilir veya olduğu gibi bırakabiliriz.
* Editörden çıkın.
* Değişikliklerimizi ```git push origin <branch-name>``` komutuyla gönderin.
Böylece, her iki düzeltme de tek bir commit'te birleştirilmiş olacaktır.
docs/additional-material/translations/Turkish/configuring-git.tr.md
+65
View File
@@ -0,0 +1,65 @@
# Git Konfigürasyonu
İlk kez bir commit yapmaya çalıştığınızda aşağıdaki mesajı görmüş olabilirsiniz:
```
$ git commit
*** Lütfen kim olduğunuzu söyleyin.
Hesabınızın varsayılan kimliğini ayarlamak için şu komutu çalıştırın:
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
Sadece bu depoda kimliği ayarlamak için --global seçeneğini kullanmayın.
Bir commit oluşturmak için Git, kimin tarafından yapıldığını bilmelidir. Ekip çalışmalarında, projenin belirli kısımlarının kim tarafından ve ne zaman değiştirildiğini bilmek önemlidir. Bu nedenle Git, her commit'in bir kullanıcı adı ve e-posta adresiyle ilişkilendirilmesini gerektirir.
Bu bilgiyi Git ile ilişkilendirmenin birkaç yolu vardır ve burada bazılarını listeleyeceğiz.
Global Konfigürasyon
Global konfigürasyonda kaydedilen bilgiler, tüm sistem için geçerlidir, yani çalıştığınız tüm depoları kapsar. Bu, çoğu kullanım durumu için tercih edilen yöntemdir.
Global konfigürasyona bir şey kaydetmek için config komutunu aşağıdaki şekilde kullanırsınız:
$ git config --global <değişken adı> <değer>
Kullanıcı bilgileri için bu komutları şu şekilde çalıştırabilirsiniz:
$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"
Depo Konfigürasyonu
Adından da anlaşılacağı gibi, bu konfigürasyonlar yalnızca mevcut depo için geçerlidir. Örneğin, işle ilgili bir projede şirket e-posta adresinizi kullanmak istiyorsanız bu yöntemi kullanabilirsiniz.
Depo düzeyinde konfigürasyon yapmak için config komutunda --global anahtarını kullanmazsınız:
$ git config <değişken adı> <değer>
Kullanıcı bilgileri için bu şu şekilde görünür:
$ git config user.email "you@alternate.com"
$ git config user.name "Your Name"
Komut Satırı Konfigürasyonu
Bu konfigürasyon yöntemi yalnızca belirli bir komut için geçerlidir. Tüm Git komutları, komuttan önce -c anahtarını kullanarak geçici konfigürasyon parametreleri ayarlamanıza izin verir.
Konfigürasyon parametrelerini yalnızca belirli bir komut için geçici olarak değiştirmek için Git komutlarını aşağıdaki formatta kullanın:
$ git -c <değişken-1>=<değer> -c <değişken-2>=<değer> <komut>
Commit komutu için bu şu şekilde olacaktır:
git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Commit mesajınız"
Öncelik Sırası Hakkında Not
Üç konfigürasyon türü arasındaki öncelik sırası şu şekildedir: komut satırı > depo > global. Bu, bir değişken hem global hem de komut satırında tanımlanmışsa, komut satırında atanan değerin kullanılacağı anlamına gelir.
Sadece Kullanıcı Bilgisi Değil
Şimdiye kadar Git konfigürasyonunu yalnızca kullanıcı bilgisi bağlamında ele aldık. Ancak Git, başka parametreleri de yapılandırmanıza izin verir. İşte bunlardan bazıları:
core.editor - Commit mesajlarını düzenlemek için kullanılacak metin düzenleyicisini belirtir.
commit.template - Commit mesajları için bir şablon dosyası belirtir.
color.ui - Git mesajlarında renkli çıktı kullanılıp kullanılmayacağını belirten mantıksal bir değişkendir.
Basitlik adına bazı detayları atladık. Daha fazla bilgi için git-scm.com adresine başvurabilirsiniz.
Bu şekilde tüm içerik **tek bir Markdown** dosyasında birleştirilmiş ve Türkçe olarak sunulmuştur.
docs/additional-material/translations/Turkish/keeping-your-fork-synced-with-this-repository.tr.md
+53
View File
@@ -0,0 +1,53 @@
# Dalınızı Ana Depo ile Senkronize Etme
Öncelikle, tam senkronizasyon için akışı anlamak önemlidir. Bu senaryoda 3 farklı depo bulunur: Github'daki açık depom github.com/firstcontributions/first-contributions.git, GitHub'daki çatal deponuz github.com/Your-Name/first-contributions/ ve üzerinde çalıştığınız yerel makinenizdeki depo. Bu tür bir işbirliği, açık kaynak projeler için tipiktir ve Triangle Workflows olarak adlandırılır.
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
Deponuzu benim açık depomla güncel tutmak için önce ana depoyu yerel deponuzla birleştirmeliyiz.
İkinci adımımız, yerel deponuzu GitHub'daki çatal deponuza itmektir. Daha önce gördüğünüz gibi, yalnızca "çatal depo" ile bir "pull request" isteyebilirsiniz. Bu nedenle, GitHub'daki çatal depo, güncellenmesi gereken son depodur.
Şimdi bunu nasıl yapacağımıza bir göz atalım:
Senkronizasyon Adımları
1. Ana Dal (master) Üzerine Geçin
Öncelikle ana dalda olduğunuzdan emin olun. Hangi dalda olduğunuzu öğrenmek için şu komutu çalıştırın:
* git status
Eğer ana dalda (master) değilseniz, ana dala geçin:
* git checkout master
2. Ana Depoyu upstream Olarak Ekleyin
Yerel deponuzu ana depo ile senkronize etmek için önce ana depoyu upstream olarak ekleyin:
* git remote add upstream https://github.com/firstcontributions/first-contributions.git
Bu komut, Git'e belirttiğiniz adreste bu projenin başka bir versiyonunun bulunduğunu ve bunu upstream olarak adlandırdığımızı söyler.
3. upstream'den Son Değişiklikleri Alın
Ardından, ana depodan en son değişiklikleri alın:
* git fetch upstream
Bu komut, upstream (ana depo) üzerindeki tüm son değişiklikleri yerel deponuza indirir.
4. upstream/master ile Birleştirin
Şimdi, ana depodaki değişiklikleri yerel ana dalınızla birleştirin:
git rebase upstream/master
Bu komut, ana depodaki değişiklikleri yerel ana dalınızla birleştirir. Yerel ana dalınız artık günceldir.
5. Yerel Depoyu GitHub Çatal Deponuza İtin
Son olarak, yerel ana dalınızı GitHub'daki çatal deponuza itin:
* git push origin master
Bu komut, yerel deponuzdaki değişiklikleri GitHub'daki çatal deponuza gönderir. Artık tüm depolarınız günceldir!
docs/additional-material/translations/Turkish/moving-a-commit-to-a-different-branch.tr.md
+25
View File
@@ -0,0 +1,25 @@
# Taahhütleri başka bir dala taşıma
Peki ya bir değişiklik yapıp daha sonra başka bir dala geçtiğinizi fark ederseniz?
Bunu nasıl değiştirebilirsiniz? İşte bu eğitim tam da bunu anlatıyor.
## Son yapılan commit'leri mevcut bir dala taşıma
Böyle bir hareket için şunu yazın:
`` `git reset HEAD ~ --soft` `` - Son commit'i geri alır, ancak değişiklikleri kullanılabilir bırakır.
`` `git stash` `` - Bir dizinin durumunu kaydeder.
`` `git checkout <geçerli dal adı>` `` - Başka bir dala geçiş yapar.
`` `git stash pop` `` - Son kaydedilen durumu döndürür.
`` `git add .` `` - Tek tek dosyaları ekler.
`` `git commit -m "mesajınızı buraya yazın"``` - Değişiklikleri kaydeder ve onaylar.
Değişiklikleriniz artık doğru dalda.
### Son yapılan commit'leri yeni bir dala taşıma
Böyle bir hareket için şunu yazın:
`` `git branch newbranch` `` - Tüm commit'leri koruyarak yeni bir dal oluşturur.
`` `git reset --hard HEAD ~ [n]` `` - Ana dalı n adet commit'e geri döndürür. Bu commitlerde yer alan değişikliklerin master dalından tamamen silineceğini aklınızda bulundurun.
`` `git checkout newbranch` `` - Oluşturduğunuz dala geçiş yapar. Bu dal artık tüm commitleri içeriyor.
Unutmayın: Commit'e dahil edilmeyen tüm değişiklikler tamamen kaybolacaktır.
docs/additional-material/translations/Turkish/removing-a-file.tr.md
+23
View File
@@ -0,0 +1,23 @@
# GIT kontrolünden bir dosyayı kaldırma
Bazen bir dosyayı GIT kontrolünden kaldırmanız gerekebilir, ancak onu bilgisayarınızda tutmanız gerekebilir. Bu, aşağıdaki komut kullanılarak gerçekleştirilebilir:
``git rm <dosya> --cached``
## Ne oldu?
GIT artık uzak dosyadaki değişiklikleri izlemiyor. GIT perspektifinden bakıldığında bu dosya eksiktir, ancak bu dosyayı dosya sisteminde bulmaya çalışırsanız, hala orada olduğunu göreceksiniz.
Yukarıdaki örnekte `--cached` bayrağının kullanıldığına dikkat edin. Eğer bu bayrağı eklemezsek Git dosyayı sadece depodan değil aynı zamanda dosya sisteminizden de silecektir.
`git commit -m "Remove file1.js"` ile bir değişikliği onaylayıp `git push origin master` ile uzak depoya gönderirseniz, uzak depo dosyayı silecektir.
## Ek Bilgiler
- Birden fazla dosyayı silmek istiyorsanız, tüm dosyaları tek bir komutta listeleyerek bunu yapabilirsiniz:
`git rm dosya1.js dosya2.js dosya3.js --cached`
- Benzer adlara sahip dosyaları silmek için joker karakteri (*) kullanabilirsiniz; örneğin, yerel depoda bulunan tüm .txt dosyalarını silmek istiyorsanız şunu yazın:
`git rm *.txt --cached`
docs/additional-material/translations/Turkish/removing-branch-from-your-repository.tr.md
+31
View File
@@ -0,0 +1,31 @@
# Depodan bir dalı kaldırma
Eğer şimdiye kadar eğitimi takip ettiyseniz, `<add-your-name>` dalımız amacına ulaşmıştır, onu yerel makinenizin deposundan kaldırmanın zamanı geldi. Bu gerekli değil, ancak bu endüstrinin ismi onun oldukça özel bir amacını gösteriyor. Ömrü de buna paralel olarak kısa olabilir.
Öncelikle `<add-your-name>`'inizi master'ınızla birleştirerek kendi dalınıza taşıyalım:
```
git ödeme ustası
```
`<add-your-name>`'i ana dosyaya birleştir:
```
git merge <adınızı-ekleyin> master
```
`<add-your-name>`'i yerel makinenizin depolarından kaldırın:
```
git branch -d <isminizi-ekleyin>
```
Artık yerel makine dalını `<add-your-name>` sildiniz ve her şey düzgün ve düzenli görünüyor.
Ancak bu noktada GitHub bölümünüzde hala `<add-your-name>` adlı bir dal olması gerekir. Ancak bunu silmeden önce, bu uzak daldan depolarıma bir "Çekme isteği" gönderdiğinizi unutmayın. Yani eğer bunu daha önce birleştirdiysem, bu dalı silmeyin.
Ancak, eğer sizin dalınızı birleştirdiysem ve siz uzak dalı silmek istiyorsanız, şunu kullanın:
```
git push origin --delete <isminizi-ekleyin>
```
Artık dallarınızı nasıl toparlayacağınızı biliyorsunuz.
Zamanla, kamuya açık arşivime birçok komisyon eklenecek. Hem yerel makinenizin ana dalları hem de GitHub çatalınız güncelliğini yitirecektir. Dolayısıyla, depolarınızı benimkilerle senkronize tutmak için şu adımları izleyin.
#### [Çatalınızı bu depoyla senkronize tutma](keeping-your-fork-synced-with-this-repository.md)
docs/additional-material/translations/Turkish/resolving-merge-conflicts.tr.md
+33
View File
@@ -0,0 +1,33 @@
# Birleştirme çatışması nedir?
Mevcut çalışma dalınızla başka bir dalı birleştirmeye çalıştığınızda, farklı bir bağlamda değişiklikler yapıyor ve bunları mevcut dosyalarınızla birleştiriyorsunuz.
Aynı dosyadaki aynı satırlar iki kişi tarafından değiştirilirse veya bir kişi silmeye karar verirken diğeri değiştirmeye karar verirse Git hangi sürümün doğru olduğunu belirleyemeyecektir. Git daha sonra dosyayı bir çakışma olarak işaretleyecektir; çalışmaya devam etmek için bu çakışmayı çözmeniz gerekecektir.
# Birleşme ihtilafı nasıl çözülür?
Bir birleştirme çakışmasıyla karşılaşıldığında, git dosyadaki sorunlu alanı “<<<<<<< HEAD” ve “>>>>>>>>>>[diğer dal adı]” içine ekleyerek işaretler.
İlk işaretleyiciden sonraki içerik mevcut dalınızdan gelir. Git, açılı parantezlerden sonra değişikliklerin nereden (hangi daldan) geldiğini söyler. "=======" satırı, çakışan iki değişikliği ayırır.
Bizim görevimiz bu satırları temizlemek: İşimiz bittiğinde dosya istediğimiz gibi görünmeli. Çelişkili değişiklikleri yazan takım arkadaşınıza danışarak hangi versiyonun nihai olacağına karar vermeniz önerilir. Ya sizin olabilir ya da ikisinin karışımı olabilir.
Örneğin:
```
<<<<<<< HEAD:birleştirmetesti
Bu üçüncü satırım.
=======
Eklediğim dördüncü satır bu.
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:birleştirme testi
```
`<<<<<<`: Birleştirme çakışması olan satırların başlangıcını belirtir. İlk satır kümesi, değişiklikleri birleştirmeye çalıştığınız dosyadaki satırlardır.
`=======`: Karşılaştırma için kullanılan kesme noktasını belirtir. Kullanıcının yaptığı değişiklikleri (yukarıda) birleştirmeden kaynaklanan değişikliklerle (aşağıda) görsel olarak karşılaştırarak farkları görmenizi sağlar.
`>>>>>>>`: Birleştirme çakışması olan satırların sonunu işaretler.
Çakışmayı dosyayı düzenleyip daha sonra manuel olarak birleştirerek çözebilirsiniz. Bir şeyin veya birinin iptali veya değiştirilmesi veya ikisinin bir kombinasyonu anlamına gelebilir. Ayrıca <<<<<<< ',' ======= ', ve' >>>>>>> ' dosyalarını da silmeniz gerekiyor.
Çatışmayı çözdükten sonra `git add` komutunu çalıştırın. Çakışmayı çözdüğünüzden emin olmanız gerektiğinden testleri çalıştırmayı unutmayın.
Birleştirme çakışmalarını daha kolay çözebilmek için kullandığınız IDE'ye bağlı olarak farklı eklentiler de indirebilirsiniz.
# Birleştirme nasıl geri alınır?
Birleştirmeyi iptal etmek istiyorsanız `git merge --abort` komutunu kullanabilirsiniz
docs/additional-material/translations/Turkish/reverting-a-commit.tr.md
+40
View File
@@ -0,0 +1,40 @@
# Taahhüdü geri al
Bir taahhüdü iptal etmek, tüm taahhütleri iptal eden tamamen yeni bir belge oluşturmak anlamına gelir.
Öncekine yapılan değişiklikler. Git'te ``CTRL + Z``` yapmak gibi bir şey.
Git'te dönüştürme işlemi daha kolay hale gelir çünkü uzak deponuza gönderdiğiniz her katkının SHA (Güvenli Karma Algoritması) olarak bilinen benzersiz bir alfanümerik anahtarı vardır.
Yani bu, SHA'nız olduğu sürece herhangi bir commit'i geri alabileceğiniz anlamına geliyor.
Ancak daha sonra depolama alanınızı bozmamak için sırayı dikkatli bir şekilde değiştirmeniz gerekiyor.
Geri almak istediğimiz belirli bir commit'in SHA'sını seçmek için, yaptığımız tüm commit'lerin bir kaydı kullanışlı olacaktır.
Bunu elde etmek için şu komutu çalıştıracağız:
`` `git log --oneline` ``
``git log`` komutunun tek bir çalıştırılması bize SHA'yı (uzun formda) da verecektir
Ancak `` --oneline `` bayrağını kullanmak, git'e kolay okunabilmesi için bunun özlü (tek satırlık) bir düzende görüntülenmesini istediğimizi söyler.
Bu komut çalıştırıldığında görüntülenen ilk 7 karaktere kısa commit hash'i denir.
Örneğin, bu depoda ``git log --oneline`` komutunu çalıştırdığımda şunu elde ediyorum:
```
389004d başlığa boşluk eklendi
c1b9fc1 'master' dalını öğreticilere birleştir
77eaafd bir commit'i geri almak için öğretici ekledi
```
Bu, ``git log --oneline`` komutunu kullanarak depoya yapılan tüm commit'lerin bir listesini, SHA'sının ilk 7 karakteriyle birlikte alabileceğimizi gösteriyor.
"Başlığa boşluk ekle" işlemini geri almak istediğimi varsayalım. İşte adımlar:
* Belgenin SHA'sını kopyalayın, bu durumda ``389004d``
* Daha sonra ```git revert 389004d``` komutunu çalıştırın
Bu, metin düzenleyicimi açacak ve benden commit mesajını düzenlememi isteyecek.
Varsayılan git mesajı olarak, `Revert` kelimesiyle başlayan commit mesajını bırakmaya karar verebilirsiniz.
Veya mesajı kendi zevkinize göre özelleştirmeye de karar verebilirsiniz.
* Daha sonra metin düzenleyiciyi kaydedip kapatacağım.
* Komut satırına geri dön.
* Geri alınan değişiklikleri Github'a göndermek için `` `git push origin <branch-name>` `` komutunu çalıştırın.
Ve işte bu kadar, yapılan değişiklikler geri alınacaktır. Bu durumda, depomuz ``c1b9fc1``'de göründüğü gibi değişecek
docs/additional-material/translations/Turkish/squashing-commits.tr.md
+86
View File
@@ -0,0 +1,86 @@
# Squashing nedir?
Git'te squashing, eylemlerinizin geçmişini yeniden yazmak anlamına gelir, böylece yaptığınız değişikliklerin bir açıklamasıyla karşılaşırsınız.
Bu, açık kaynaklı projelerde sıklıkla yapılır çünkü açık kaynaklı projelerdeki birçok dal geçmişi yalnızca onları oluşturan geliştiriciyle ilgilidir ve yapılan değişiklikleri tanımlamanın ve gerekirse geri almanın daha kolay bir yolunu sağlar.
# Commit'leri nasıl ezersiniz?
Öncelikle, mevcut dalınıza birleştirmek istediğiniz commit'leri analiz etmek için bir git günlüğü çalıştırın.
```
git günlüğü
```
Taahhütlerinizin bir kısmını şu şekilde görmelisiniz:
```
bla bla bla yapmak
Yazar: omguhh
Tarih: 10/10/20
Mesaj 1'i kaydet
blablabla2'yi taahhüt et
Yazar: omguhh
Tarih: 10/10/20
Mesaj 2'yi kaydet
```
Şimdi, birleştirmek istediğimiz commitleri gördüğümüzde ``git rebase`` ile oraya gidebiliriz. ``git rebase`` ile zaten aşina olduğunuzu varsayarak, etkileşimli git rebase modunda commit'leri ezmeye başlayabiliriz; bu şu şekilde etkinleştirilebilir:
```
git rebase -i
```
Artık etkileşimli yeniden temellendirme ile şu şekilde hareketlerle ne kadar ileri gitmek istediğinizin başlangıç ​​ve bitiş noktalarını tanımlayabilirsiniz:
```
git rebase -i HEAD~2
```
Bu komutu çalıştırdığınızda aşağıdakine benzer bir şey göreceksiniz:
```
pick blablabla test01.txt dosyasını değiştirme
blablabla2'yi seçin dummy01.txt dosyası ekleniyor
#
# Komutlar:
# p, seç = kullan commit
# r, reword = commit'i kullan, ancak commit mesajını düzenle
# e, edit = commit kullan, ancak değişiklik yapmak için durdur
# s, squash = commit'i kullan, ancak önceki commit'e birleştir
# f, fixup = "squash" gibi, ancak bu commit'in günlük mesajını at
# x, exec = komutu (satırın geri kalanını) kabuk kullanarak çalıştır
#
# Bu satırlar yeniden sıralanabilir; yukarıdan aşağıya doğru infaz edilirler.
#
# Buradaki bir satırı silerseniz O COMMIT KAYBOLACAĞIZ.
#
# Ancak her şeyi kaldırırsanız, yeniden temellendirme işlemi iptal edilecektir.
#
# Boş commit'lerin yorum satırına alındığını unutmayın
```
Yani, ```blablabla2```'yi ```blablablabla```'ya sıkıştırmak istiyorsanız, aşağıdakileri değiştirmeniz gerekir:
```
pick blablabla test01.txt dosyasını değiştirme
squash blablabla2 dummy01.txt dosyası ekleniyor
```
Her şey yolunda giderse şu sonucu elde edeceksiniz:
```
# Bu 2 commit'in birleşimidir.
# İlk commit'in mesajı şu şekilde:
mesaj 1'i kaydet
# Bu 2. commit mesajıdır:
mesaj 2'yi gönder
```
Değişiklikleri kaydetmek için editörden çıkmadan önce bunları özgürce değiştirebilirsiniz.
Git log'u çalıştırdığınızda, çıkmadan önce girdiğiniz commit mesajı, commit'ler birleştirilerek tek bir commit'te gösterilmelidir.
docs/additional-material/translations/Turkish/stashing-a-file.tr.md
+137
View File
@@ -0,0 +1,137 @@
# Saklamak
Ya büyük bir kod parçası üzerinde çalışıyorsanız ve aniden üzerinde çalıştığınız dalı başka bir dala geçirmeniz gerekirse? Kod tamamlanmamış ve herhangi bir test yapılmamış olduğundan muhtemelen onu commit etmek istemezsiniz. Ama değişiklik yapmadan başka bir dala geçemezsiniz, Git bu akışı bozmanıza izin vermez. Peki ne yapacağız? Dallara atlayabilirken gereksiz commit'leri nasıl engelleriz? İşte bu eğitim tam da bunu anlatıyor.
## Çalışmayı Gizleme
Diyelim ki bir proje dalında çalışıyorsunuz ve bazı dosyaları değiştiriyorsunuz. Şimdi ``git status`` komutunu çalıştırırsanız dosyalardaki değişiklikleri görebilirsiniz.
```
$ git durumu
# Dal ana üzerinde
# Taahhüt edilecek değişiklikler:
# (sahnelemeyi kaldırmak için "git reset HEAD <dosya>..." komutunu kullanın)
#
# değiştirildi: index.html
#
# Değişiklikler commit için hazır değil:
# (ne taahhüt edileceğini güncellemek için "git add <dosya>..." kullanın)
#
# değiştirildi: lib/simplegit.rb
#
```
Şimdi dalınızı değiştirmek istiyorsunuz, ancak henüz herhangi bir değişiklik yapmak istemiyorsunuz; böylece değişikliklerinizi kaydedebilirsiniz.
Yığına yeni bir kaynak eklemek için ``git stash`` komutunu çalıştırın:
```
$ git saklama
Çalışma dizini ve dizin durumu kaydedildi \
"Ana projedeki WIP: 049d078 dizin dosyasını ekledi"
HEAD artık 049d078'de, dizin dosyası eklendi
(Geri yüklemek için "git stash apply" yazın)
```
Artık çalışma dizininiz temiz, ```git status``` kullanın:
```
$ git durumu
# Dal ana üzerinde
taahhüt edilecek bir şey yok, çalışma dizini temiz
```
Artık istediğiniz sektöre girip işinizi yapabilirsiniz; Gizli değişiklikler bir yığın olarak saklanır. Yığınınızda hangi stash'leri sakladığınızı görmek için ``git stash list`` komutunu kullanabilirsiniz:
```
$ git stash listesi
stash@{0}: WIP on master: 049d078 dizin dosyasını ekledi
stash@{1}: Ana dosyada WIP: c264051 "dosya_boyutu eklendi" geri alındı
stash@{2}: WIP ana bilgisayarda: 21d80a5 günlüğe sayı eklendi
```
Az önce sakladığınız değişiklikleri tekrar uygulamak isterseniz ``git stash apply`` komutunu kullanabilirsiniz. Bu komutla son kaydedilen dosyayı tekrar uygulayabilirsiniz. Başka bir dosyayı yeniden uygulamak için, onu şu şekilde adlandırarak belirtebilirsiniz: ```git stash apply <stash-name>```, `` `<stash-name>`` yerine stash'in adını yazın ve yeniden göndermem gerekiyor.
```
$ git stash uygula
# Dal ana üzerinde
# Değişiklikler commit için hazır değil:
# (ne taahhüt edileceğini güncellemek için "git add <dosya>..." kullanın)
#
# değiştirildi: index.html
# değiştirildi: lib/simplegit.rb
#
```
Git'in, pozisyonu kaydettiğinizde sildiğiniz dosyayı yeniden düzenlediğini görebilirsiniz. Bu durumda, stash'i uygulamaya çalıştığınızda temiz bir çalışma dizininiz vardı ve stash'i, stash'i aldığınız aynı şubeye uygulamaya çalıştınız; Ancak kutuları başarılı bir şekilde kullanmak için temiz bir çalışma dizinine sahip olmak ve onu aynı dalda kullanmak gerekli değildir. Kutularınızı bir dala kaydedebilir, daha sonra başka bir dala geçebilir ve değişiklikleri yeni dala yeniden uygulayabilirsiniz. Stash'i uyguladığınızda çalışma dizininizde değiştirilmiş ve açılmamış dosyalar da olabilir, başka hiçbir şey temiz bir şekilde uygulanmazsa git birleştirme çakışmaları verir.
Dosyalarınızda yaptığınız değişiklikler yeniden uygulandı, ancak oluşturduğunuz dosya yeniden yüklenmedi. Bunu yapmak için, komuta aşamalı değişiklikleri yeniden uygulamasını söylemek üzere ``git stash apply`` komutunu ```--index``` ile çalıştırmanız gerekir. Bunu çalıştırırsanız, başlangıç ​​noktasına geri dönersiniz:
```
$ git stash uygula --index
# Dal ana üzerinde
# Taahhüt edilecek değişiklikler:
# (sahnelemeyi kaldırmak için "git reset HEAD <dosya>..." komutunu kullanın)
#
# değiştirildi: index.html
#
# Değişiklikler commit için hazır değil:
# (ne taahhüt edileceğini güncellemek için "git add <dosya>..." kullanın)
#
# değiştirildi: lib/simplegit.rb
#
```
Apply komutu yalnızca kapatılan işe uygulanır, ancak iş hala yığınınızdadır. Bunu kaldırmak için, kaldırılacak yığın adıyla ``git stash drop`` komutunu çalıştırabilirsiniz.
```
$ git stash listesi
stash@{0}: WIP on master: 049d078 dizin dosyasını ekledi
stash@{1}: Ana dosyada WIP: c264051 "dosya_boyutu eklendi" geri alındı
stash@{2}: WIP ana bilgisayarda: 21d80a5 günlüğe sayı eklendi
$ git stash stash@{0}'ı bırak
Stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) düşürüldü
```
Son değişiklikleri yığınınızdan kaldırmak için ``git stash pop`` komutunu kullanabilirsiniz.
## Saklamayı geri al
Bazı durumlarda stash değişikliklerini uygulamak, bir miktar iş yapmak, ancak başlangıçta stash'ten gelen değişiklikleri uygulamak istersiniz. Git, ``git unapply`` gibi bir komut sağlamaz, ancak stash ile ilişkili yamayı alıp ters sırada uygulayarak bu etkiyi elde edebilirsiniz:
```$ git stash show -p stash@{0} | git uygula -R```
Tekrar ediyorum, eğer bir stash belirtmezseniz Git en son stash'i varsayar:
```$ git stash göster -p | git uygula -R```
Bir takma ad oluşturup ``stash-unapply`` komutunu Git'inize eklemek isteyebilirsiniz. Örneğin:
```
$ git config --global alias.stash-unapply '!git stash göster -p | git uygula -R'
$ git stash uygula
$ #... çalış çalış çalış
$ git stash-unapply
```
## Stash'tan bir dal oluşturma
Eğer yaptığınız bir çalışmayı kaydedip bir süre orada bıraktıktan sonra, gizlediğiniz dalda çalışmaya devam ederseniz, tekrar çalıştığınızda sorun yaşayabilirsiniz. Bir uygulama sizin daha önce değiştirdiğiniz bir dosyayı değiştirmeye çalışırsa, birleştirme çakışması oluşur ve bunu çözmeniz gerekir. Stash değişikliklerinizi daha basit bir şekilde test etmek istiyorsanız, sizin için yeni bir dal oluşturan, işinizi stash ettiğinizde yaptığınız commit'leri kontrol eden ve işinizi yeniden yerleştiren ``git stash branch`` komutunu çalıştırabilirsiniz. orada ve ardından başarıyla uygulandığında kutuyu sıfırlar:
```
$ git stash branch testchanges
"testchanges" adlı yeni bir dala geçildi
# Branch testchanges üzerinde
# Taahhüt edilecek değişiklikler:
# (sahnelemeyi kaldırmak için "git reset HEAD <dosya>..." komutunu kullanın)
#
# değiştirildi: index.html
#
# Değişiklikler commit için hazır değil:
# (ne taahhüt edileceğini güncellemek için "git add <dosya>..." kullanın)
#
# değiştirildi: lib/simplegit.rb
#
Refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) düşürüldü
```
Bu, gizli çalışmayı kolayca geri yüklemek ve yeni bir dalda üzerinde çalışmak için iyi bir kısayoldur.
docs/additional-material/translations/Turkish/undoing-a-commit.tr.md
+59
View File
@@ -0,0 +1,59 @@
# Yerel onayları geri al
Yerel onayları geri almak için yapmanız gereken tek şey
```
git sıfırlama
```
Bu komut, staging alanını son commit'e sıfırlayacaktır, ancak çalışma dizininizde yapılan değişiklikler değişmeyecektir. Bu şekilde, yaptığınız değişiklikleri tekrar uygulayabilirsiniz.
Veya, önceki bir commit'ten sadece bir dosyayı kaldırmak istiyorsanız. Daha sonra aşağıdaki komutu uygulayabilirsiniz
```
git reset <dosya>
```
Komut yalnızca belirtilen dosyayı hazırlama alanından kaldıracaktır, ancak dosyada yapılan değişiklikler yine de kalacaktır.
```git reset``` kullanımına örnek
```
# index.php ve tutorial.php'de değişiklikler yapın
# Dosyaları sahneleme alanına ekleyin
$ git add .
# Her iki dosyanın da ayrı ayrı commit edilmesi gerektiğini unutmayın
# Unstage öğreticisi.php
$ git sıfırlama öğreticisi.php
# Önce index.php'yi işleyin
$ git commit -m "index.php değiştirildi"
# Şimdi tutorial.php'yi gönder
$ git add öğretici.php
$ git commit -m "tutorial.php değiştirildi"
```
Diyelim ki yerel depolama alanınızı bozdunuz ve onu sadece son commit'e sıfırlamak istiyorsunuz.
Daha sonra aşağıdaki komutu çalıştırabilirsiniz.
```
git reset --hard
```
Komut sadece hazırlama alanınızı sıfırlamakla kalmayacak, aynı zamanda dosyalardaki tüm değişikliklerinizi son commit'inize geri döndürecektir.
``--hard`` modu Git'e çalışma dizinindeki tüm değişiklikleri geri almasını söyler.
Bunu yalnızca tüm yerel geliştirmeyi çöpe atacağınızdan gerçekten eminseniz çalıştırmalısınız.
```git reset --hard``` kullanım örneği
```
# Çılgın bir deney başlatmaya karar verdim
# Yeni bir 'crazy.php' dosyası oluşturun ve içine biraz kod ekleyin
# crazy.php'yi yükle
$ git add crazy.php
$ git commit -m "Çılgın bir geliştirme başlatıldı"
# crazy.php dosyasını tekrar düzenleyin ve diğer birçok dosyayı değiştirin
# Takip edilen tüm dosyaları kaydet
$ git add .
$ git commit -m "Devam eden geliştirme"
# Test edildi ve işler kontrolden çıktı
# Her şeyi kaldırmaya karar verdim
$ git reset --hard HEAD~2
```
```git reset --hard HEAD~2``` geçerli dalı her seferinde 2 commit geriye taşır, yaptığınız tüm değişiklikleri geri alır ve az önce oluşturduğumuz 2 anlık görüntüyü proje geçmişinden kaldırır.
Not: Eğer commit'lerinizi paylaşımlı bir depoya taşıdıysanız asla ``git reset --hard`` komutunu çalıştırmayın, çünkü bu tüm depolarla sorunlara yol açacaktır.
docs/cli-tool-tutorials/Marathi/github-cli-tutorial.marathi.md → docs/cli-tool-tutorials/translations/Marathi/github-cli-tutorial.marathi.md
View File
docs/cli-tool-tutorials/Spanish/github-cli-tutorial.es.md → docs/cli-tool-tutorials/translations/Spanish/github-cli-tutorial.es.md
View File