-
1. Başlangıç
- 1.1 Sürüm Denetimi
- 1.2 Git’in Kısa Tarihçesi
- 1.3 Git Nedir?
- 1.4 Komut Satırı
- 1.5 Git’i Yüklemek
- 1.6 Git’i İlk Defa Kurmak
- 1.7 Yardım Almak
- 1.8 Özet
-
2. Git Temelleri
-
3. Git Dalları
- 3.1 Dallar
- 3.2 Kısaca Dallandırma ve Birleştirme Temelleri
- 3.3 Dal Yönetimi
- 3.4 İş Akışı Dallandırması
- 3.5 Uzak Dallar
- 3.6 Yeniden Temelleme (rebase)
- 3.7 Özet
-
4. Bir Sunucuda Git Kurma
- 4.1 İletişim Kuralları (Protocols)
- 4.2 Bir Sunucuda Git Kurma
- 4.3 SSH Ortak Anahtarınızı Oluşturma
- 4.4 Sunucu Kurma
- 4.5 Git Cini (Daemon)
- 4.6 Akıllı HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Taraf Barındırma (Hosting) Seçenekleri
- 4.10 Özet
-
5. Dağıtık Git
- 5.1 Dağıtık İş Akışları
- 5.2 Projenin Gelişiminde Rol Almak
- 5.3 Bir Projeyi Yürütme
- 5.4 Özet
-
6. GitHub
- 6.1 Bir Projeye Katkıda Bulunmak
- 6.2 Proje Bakımı
- 6.3 Kurumsal Yönetim
- 6.4 GitHub’ı otomatikleştirme
- 6.5 Özet
-
7. Git Araçları
- 7.1 Düzeltme Seçimi
- 7.2 Etkileşimli İzlemleme (Staging)
- 7.3 Saklama ve Silme
- 7.4 Çalışmanızı İmzalama
- 7.5 Arama
- 7.6 Geçmişi Yeniden Yazma
- 7.7 Reset Komutunun Gizemleri
- 7.8 İleri Seviye Birleştirme
- 7.9 Rerere
- 7.10 Git’le Hata Ayıklama
- 7.11 Alt Modüller
- 7.12 Demetleme (Bundling)
- 7.13 Git Nesnesini Değiştirme
- 7.14 Kimlik Bilgisi Depolama
- 7.15 Özet
-
8. Git’i Özelleştirmek
- 8.1 Git Yapılandırması
- 8.2 Git Nitelikleri
- 8.3 Git Kancaları (Hooks)
- 8.4 Bir Örnek: Mecburi Git Politikası
- 8.5 Özet
-
9. Git ve Diğer Sistemler
- 9.1 İstemci Olarak Git
- 9.2 Git’e Geçiş
- 9.3 Özet
-
10. Dahili Git Ögeleri
- 10.1 Tesisat ve Döşeme (Plumbing ve Porcelain)
- 10.2 Git Nesneleri
- 10.3 Git Referansları
- 10.4 Packfiles
- 10.5 Refspec
- 10.6 Transfer Protokolleri
- 10.7 Bakım ve Veri Kurtarma
- 10.8 Ortam Değişkenleri
- 10.9 Özet
-
A1. Ek bölüm A: Diğer Ortamlarda Git
- A1.1 Görsel Arayüzler
- A1.2 Visual Studio ile Git
- A1.3 Visual Studio Code ile Git
- A1.4 Eclipse ile Git
- A1.5 Sublime Text ile Git
- A1.6 Bash ile Git
- A1.7 Zsh ile Git
- A1.8 PowerShell ile Git
- A1.9 Özet
-
A2. Ek bölüm B: Git’i Uygulamalarınıza Gömmek
- A2.1 Git Komut Satırı
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Ek bölüm C: Git Komutları
- A3.1 Kurulum ve Yapılandırma Komutları
- A3.2 Proje Oluşturma Komutları
- A3.3 Kısaca Poz (Snapshot) Alma
- A3.4 Dallandırma ve Birleştirme Komutları
- A3.5 Projeleri Paylaşma ve Güncelleme Komutları
- A3.6 İnceleme ve Karşılaştırma Komutları
- A3.7 Hata Ayıklama (Debugging) Komutları
- A3.8 Yamalama (Patching)
- A3.9 E-Posta Komutları
- A3.10 Harici Sistemler
- A3.11 Yönetim
- A3.12 Tesisat (Plumbing) Komutları
7.14 Git Araçları - Kimlik Bilgisi Depolama
Kimlik Bilgisi Depolama
Eğer uzak sunuculara bağlanmak için SSH taşıyıcısını kullanıyorsanız, şifresiz bir anahtarınız olabilir ve bu da kullanıcı adı ve şifrenizi yazmadan veri aktarmanıza olanak sağlar. Ancak, HTTP protokolleri için bu mümkün değildir; her bağlantıda bir kullanıcı adı ve şifre gereklidir. Bu durum, iki faktörlü kimlik doğrulama sistemlerinde daha da zorlaşır, çünkü şifreniz için kullandığınız belirteç rastgele oluşturulmuştur ve okunması zor olabilir.
Neyse ki, Git’in bu konuda yardımcı olabilecek bir kimlik bilgisi sistemi vardır. Git’in heybesinde sakladığı bazı seçenekler şunlardır:
-
Varsayılan olarak hiçbir şey önbelleğe alınmaz. Her bağlantı, kullanıcı adınızı ve şifrenizi girmenizi isteyecektir.
-
``cache`` (Önbellek) modu, belirli bir süre boyunca kimlik bilgilerini bellekte tutar. Hiçbir şifre hiçbir zaman diskte saklanmaz ve bunlar 15 dakika sonra önbellekten silinir.
-
``store`` (Depolama) modu, kimlik bilgilerini düz metin dosyası halinde diskte kaydeder ve bunlar hiçbir zaman zamanaşımına uğramaz. Bu, git hesabınız için şifrenizi değiştirene kadar kimlik bilgilerinizi bir daha asla girmeniz gerekmeyeceği anlamına gelir. Bu yaklaşımın dezavantajı, şifrelerinizin açık metin olarak home dizininizde düz bir dosyada saklanmasıdır.
-
Bir Mac kullanıyorsanız, Git ``osxkeychain`` moduyla gelir; bu da kimlik bilgilerini sisteminize bağlı güvenli anahtar zincirinde önbelleğe alır. Bu yöntem, kimlik bilgilerini diske kaydeder ve bunların süresi hiçbir zaman dolmaz, ancak bunlar HTTPS sertifikalarını ve Safari otomatik doldurmalarını saklayan aynı sistemle şifrelenir.
-
Bir Windows kullanıyorsanız, ``Git Credential Manager for Windows`` adlı bir yardımcı programı yükleyebilirsiniz. Bu, yukarıda açıklanan ``osxkeychain`` yardımcı programına benzer, ancak hassas bilgileri kontrol etmek için Windows Kimlik Bilgisi Deposunu kullanır. Onu şu adresten bulabilirsiniz: https://github.com/Microsoft/Git-Credential-Manager-for-Windows.
Bu yöntemlerden birini, bir Git yapılandırma değeri belirleyerek seçebilirsiniz:
$ git config --global credential.helper cache
Bazı yardımcı programların çeşitli seçenekleri vardır.
``store`` yardımcısı, --file <dosya_yolu>
argümanını alabilir, bu da düz metin dosyasının nerede kaydedileceğini özelleştirir (varsayılan ~/.git-credentials
dizinidir).
``cache`` yardımcısı, daemon işlemin ne kadar süreyle tutulacağını değiştiren --timeout <saniye>
seçeneğini kabul eder (varsayılan ``900 saniye``, veya 15 dakikadır).
İşte ``store`` yardımcısını özel bir dosya adıyla nasıl yapılandıracağınıza dair bir örnek:
$ git config --global credential.helper 'store --file ~/.my-credentials'
Git, birkaç yardımcıyı yapılandırmanıza bile izin verir. Belirli bir sunucu için kimlik bilgilerini ararken, Git bunları sırayla sorgular ve bir kez cevap verildikten sonra durur. Kimlik bilgilerini kaydederken, Git kullanıcı adını ve şifreyi liste içindeki tüm yardımcılara gönderir ve onlar bunlarla ne yapacaklarına karar verebilirler.
Eğer taşınabilir sürücünüzde bir kimlik bilgileri dosyanız varsa, ancak sürücü takılı değilken bazı yazma işlemlerini kaydetmek için bellek içindeki önbelleği kullanmak istiyorsanız, .gitconfig
şu şekilde görünecektir:
[credential]
helper = store --file /mnt/thumbdrive/.git-credentials
helper = cache --timeout 30000
Şapkanın Altı
Peki tüm bunlar nasıl çalışıyor?
Git’in kimlik bilgisi yardımcı sistemine yönelik kök komutu git credential
'dır. Bir komutu argüman olarak ve daha sonra daha fazla veri girişini stdin
üzerinden alır.
Bir örnek ile bunu anlamak daha kolay olacaktır.
Diyelim ki yapılandırılmış bir kimlik bilgisi yardımcısı, mygithost
için kimlik bilgilerini saklamış olsun.
İşte, Git’in bir sunucu için kimlik bilgilerini bulmaya çalışırken çağrılan ``fill`` komutunu kullanan bir oturum:
$ git credential fill (1)
protocol=https (2)
host=mygithost
(3)
protocol=https (4)
host=mygithost
username=bob
password=s3cre7
$ git credential fill (5)
protocol=https
host=unknownhost
Username for 'https://unknownhost': bob
Password for 'https://bob@unknownhost':
protocol=https
host=unknownhost
username=bob
password=s3cre7
-
Bu etkileşimi başlatan komut satırıdır.
-
Ardından, Git-credential stdin üzerinden giriş bekler. Bildiklerimizi giriyoruz: protokol ve sunucu adı.
-
Boş bir satır, girişin tamamlandığını ve kimlik bilgisi sisteminin ne bildiğini yanıtlaması gerektiğini gösterir.
-
Daha sonra, Git-credential işi devralır ve bulduğu bilgileri stdout ile yazar.
-
Kimlik bilgileri bulunamazsa; Git kullanıcıya kullanıcı adını ve şifreyi sorup, bunları başlatan stdout’a sağlar (burada aynı konsola bağlanmışlardır).
Kimlik bilgisi sistemi aslında Git’ten ayrı bir programı çağırır. Hangi programın çağrıldığı ve nasıl olduğu, credential.helper
yapılandırma değerine bağlıdır.
Bu, birkaç farklı biçimde olabilir:
Yapılandırma Değeri | Davranış |
---|---|
|
|
|
|
|
|
|
|
Yukarıda tanımlanan yardımcılar aslında git-credential-cache
, git-credential-store
, vb. şeklinde adlandırılmıştır ve onları komut satırı argümanları alacak şekilde yapılandırabiliriz.
Bunun genel formu ``git-credential-foo [args] <eylem>.`` şeklindedir.
Stdin/stdout protokolü git-credential ile aynıdır, ancak biraz farklı bir eylem kümesi kullanırlar:
-
get
: Kullanıcı adı/şifre isteği. -
store
: Bu yardımcının belleğine, bir kimlik bilgisi kümesini kaydetme isteği. -
erase
: Belirtilen özelliklere sahip kimlik bilgilerini, bu yardımcının belleğinden silme işlemi.
store
ve erase
eylemleri için yanıt gerekli değildir (zaten Git tarafından görmezden gelinir).
Ancak Git, get
eylemi için yardımcının ne söylediğini çok önemser.
Yardımcı işe yarar bir şey bilmiyorsa, herhangi bir çıktı olmadan doğrudan çıkış yapabilir; ancak biliyorsa, sağlanan bilgiyi depoladığı bilgilerle genişletmesi gerekir.
Çıktı, bir dizi atama ifadesi gibi işlenir; sağlanan her bir şey, Git’in zaten bildiği şeyi değiştirecektir.
İşte yukarıdaki örneğin, git-credential’ı atlayarak doğrudan git-credential-store’a geçen bir şekli:
$ git credential-store --file ~/git.store store (1)
protocol=https
host=mygithost
username=bob
password=s3cre7
$ git credential-store --file ~/git.store get (2)
protocol=https
host=mygithost
username=bob (3)
password=s3cre7
-
Burada
git-credential-store
'a bazı kimlik bilgilerini kaydetmesini söylüyoruz:https://mygithost
erişildiğinde kullanıcı adı olarak ``bob`` ve şifre olarak ``s3cre7`` kullanılacaktır. -
Şimdi bu kimlik bilgilerini alacağız. Zaten bildiğimiz bağlantının parçalarını sağlıyoruz (
https://mygithost
) ve bir boş satır ekliyoruz. -
git-credential-store
, yukarıda sakladığımız kullanıcı adı ve şifre ile yanıt verir.
İşte ~/git.store
dosyasının içeriği:
https://bob:s3cre7@mygithost
Bu sadece kimlik bilgisiyle bezenmiş URL’lerini içeren bir dizi satırdır.
osxkeychain
ve wincred
yardımcıları, destek depolarının doğal formatını kullanırken, cache
kendi bellek içi formatını kullanır (ki bu diğer hiçbir süreç tarafından okunamaz).
A Custom Credential Cache
git-credential-store
ve benzerleri, Git’ten bağımsız ayrı programlardır, bu nedenle herhangi bir programın bir Git kimlik bilgisi yardımcısı olabileceğini anlamak pek de zor değildir.
Git’in sağladığı yardımcılar birçok yaygın kullanım durumunu kapsar, ancak hepsini değil.
Örneğin, diyelim ki ekibinizin, belki de dağıtım için, tüm ekiple paylaşılan bazı kimlik bilgileri var.
Bu kimlik bilgileri, paylaşılan bir dizinde saklanır, ancak sık sık değiştiği için bunları kendi kimlik bilgisi deposuna kopyalamak istemezsiniz.
Mevcut yardımcıların hiçbiri bu durumu kapsamaz. Şimdi kendimiz bir tane yazmak istersek ne gerektiğini görelim.
Bu programın sahip olması gereken birkaç temel özellik bulunmaktadır:
-
Dikkat etmemiz gereken tek işlem
get
işlemidir:store
veerase
yazma işlemleri olduğu için, bunları aldığımızda sadece temiz bir şekilde çıkış yaparız. -
Paylaşılan kimlik bilgisi dosyasının dosya biçimi,
git-credential-store
tarafından kullanılan dosya biçimi ile aynıdır. -
Dosyanın yeri oldukça standarttır, ancak her ihtimale karşı kullanıcının özel bir dizin geçmesine izin vermeliyiz.
Bu uzantıyı yine Ruby’de yazacağız, ancak Git, bitmiş kodu çalıştırabileceği sürece herhangi bir dil de işe yarayacaktır. İşte yeni kimlik bilgisi yardımcımızın tam kaynak kodu:
#!/usr/bin/env ruby
require 'optparse'
path = File.expand_path '~/.git-credentials' # (1)
OptionParser.new do |opts|
opts.banner = 'USAGE: git-credential-read-only [options] <action>'
opts.on('-f', '--file PATH', 'Specify path for backing store') do |argpath|
path = File.expand_path argpath
end
end.parse!
exit(0) unless ARGV[0].downcase == 'get' # (2)
exit(0) unless File.exists? path
known = {} # (3)
while line = STDIN.gets
break if line.strip == ''
k,v = line.strip.split '=', 2
known[k] = v
end
File.readlines(path).each do |fileline| # (4)
prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first
if prot == known['protocol'] and host == known['host'] and user == known['username'] then
puts "protocol=#{prot}"
puts "host=#{host}"
puts "username=#{user}"
puts "password=#{pass}"
exit(0)
end
end
-
Burada komut satırı seçeneklerini ayrıştırıyoruz ve kullanıcının giriş dosyasını belirtmesine izin veriyoruz. Varsayılan
~/.git-credentials
'dır. -
Bu program, sadece eylem
get
ise ve destek dosyası mevcutsa yanıt verir. -
Bu döngü, ilk boş satıra ulaşılıncaya kadar stdin’den okur. Girişler daha sonra başvurmak üzere
known
hash’inde saklanır. -
Bu döngü, depolama dosyasının içeriğini okur ve eşleşmeleri arar.
known
'dan gelen protokol ve sunucu bu satırla eşleşiyorsa, program sonuçları stdout’a yazdırır ve çıkar.
Yardımcımızı git-credential-read-only
olarak kaydedeceğiz, bunu PATH
içinde bir yere koyacağız ve çalıştırılabilir olarak işaretleyeceğiz.
İşte etkileşimli bir oturumun nasıl göründüğü:
We’ll save our helper as git-credential-read-only
, put it somewhere in our PATH
and mark it executable.
Here’s what an interactive session looks like:
$ git credential-read-only --file=/mnt/shared/creds get
protocol=https
host=mygithost
protocol=https
host=mygithost
username=bob
password=s3cre7
Adı "git-" ile başladığından, yapılandırma değeri için basit sözdizimini kullanabiliriz:
$ git config --global credential.helper 'read-only --file /mnt/shared/creds'
Gördüğünüz gibi, bu sistemi genişletmek oldukça basit ve sizin ve ekibinizin bazı yaygın sorunlarını çözebilir.