Git Clone Komutu: Temel Kullanımdan İleri Tekniklere

Git URL’leri ve Protokoller

Yukarıdaki “aws-cli” deposunu klonlama örneğinde görüldüğü gibi, git clone kullanarak bir depoyu klonlamak için uzak deponun konumunu sağlamamız gerekir; bu da bir Git URL’si aracılığıyla yapılır. 

Git, uzak depolara erişmek için her birinin kendi yapısı, güvenlik modeli ve en iyi kullanım alanları olan birden çok protokolü destekler. Farklı Git URL türlerini ve her birini ne zaman kullanmanız gerektiğini anlamak; özellikle ekipler arasında iş birliği yaparken veya dağıtımları otomatikleştirirken daha güvenli ve verimli çalışmanıza yardımcı olur.

Git URL türleri

Bir depoyu klonlarken sağladığınız URL, Git’e uzak sunucuya nasıl bağlanacağını söyler. En yaygın Git URL türleri şunlardır:

HTTPS

Hyper Text Transfer Protocol Secure (HTTPS). Çoğunlukla bir web tarayıcısı aracılığıyla web sayfalarına erişmek için kullanılır. Bu URL türü kullanımı kolaydır ve herkese açık bir depoyu klonlarken herhangi bir kurulum gerektirmez. İşte bazı örnekler:

git clone https://github.com/<username>/<repo>.git
git clone https://github.com/aws/aws-cli.git
git clone https://gitlab.com/gitlab-org/gitlab.gitAltyapı:

Yapı Ayrımı:

• https:// – İletişim için kullanılan protokol (güvenli ve güvenlik duvarı dostu).
• github.com – Git barındırma hizmetinin alan adı.
• username/repo.git – Depoya giden yol:
• username sahip (kullanıcı veya organizasyon)
• repo.git Git deposunun adı

SSH

Secure Shell (SSH). Bağlanmadan önce barındırma sunucusunda kimlik bilgileri oluşturmanızı gerektiren kimlik doğrulamalı bir ağ protokolü. Bir SSH anahtar çifti üretmeyi ve genel anahtarı Git sağlayıcınıza (ör. GitHub, GitLab) eklemeyi gerektirir

git clone [email protected]:<username>/<repo>.git
git clone [email protected]:aws/aws-cli.git
git clone [email protected]:gitlab-org/gitlab.gitAltyapı:

Yapı Ayrımı:

• git@ – SSH kullanıcı hesabını belirtir (genellikle sadece git).
• github.com: – Git sunucusunun alan adı, ardından iki nokta üst üste : (eğik çizgi değil).
• username/repo.git – Sunucudaki deponun yolu.

GitHub hesabımda herhangi bir SSH anahtarı yapılandırmadığım için, SSH URL’sini kopyalamaya çalıştığımda aşağıdaki mesajı gösteriyor.

SSH anahtarı kurulmamış

SSH anahtarlarının kurulumunu bir sonraki bölümde ele alacağım.

GIT

Yalnızca okuma erişimi için hafif, kimlik doğrulaması olmayan bir protokol. Git’e özgü bir protokoldür. Güvenlik endişeleri ve GitHub, GitLab gibi büyük sağlayıcıların kullanım dışı bırakması nedeniyle günümüzde nadiren kullanılır. GitHub veya GitLab’da git protokolünü kullanarak klonlama seçeneğini bile bulamazsınız.

# Not recommended
git clone git://github.com/<username>/<repo>.gitAltyapı:

Yapı Ayrımı:

• git// – Git protokolü (salt okunur, kimlik doğrulamasız).
• github.com: – Git sunucusunun alan adı.
• username/repo.git – Sunucudaki deponun yolu.

Hangi klonlama protokolü kullanılırsa kullanılsın, aşağıdaki komutları çalıştırarak kullanılan URL ve protokolü kontrol edebilirsiniz:

git remote -v
git remote show originAltyapı:

Doğru URL protokolünü seçmek

Her protokolün artıları ve eksileri vardır. Aşağıdaki tabloyu kullanarak kullanım durumunuz için uygun protokolü seçmenin avantaj ve dezavantajlarını karşılaştırıyoruz.

Protoko­le Özgü Klonlama Prosedürleri

Bir Git URL protokolünü seçtikten sonra, gerçek klonlama süreci ve kimlik doğrulama akışı farklılık gösterir. Her iki yöntem de nihayetinde aynı hedefe (uzak depoyu yerel makinenize klonlama) ulaşsa da, farklı güvenlik tercihleri, kullanıcı ihtiyaçları ve kurulum karmaşıklıklarına hitap eder. 

Bu bölümde, HTTPS ve SSH kullanarak bir depoyu klonlamayı; güvenli ve sorunsuz bir klonlama süreci için en iyi uygulamalar, kurulum adımları ve hata giderme önerileriyle birlikte ele alacağım.

HTTPS Git klonlama iş akışı

Bir Git deposunu HTTPS üzerinden klonlamak en basit yöntemdir; bu da onu yeni başlayanlar ve kısıtlı ortamlar (kurumsal güvenlik duvarları veya kısıtlı ağlar gibi) için ideal kılar.

Bir depoyu klonlamak için, depoya gidin ve HTTPS URL’sini kopyalayın. Aşağıdaki görsel GitHub’dan alınmıştır. Kendi Git sağlayıcınızda benzer olacaktır.

GitHub’da bir deponun HTTPS URL’sini alma

Ardından, deponun klonlanmasını istediğiniz hedefte (ör. dizüstü bilgisayarınız veya bir CI/CD hattı) git clone komutunu çalıştırın.

git clone https://github.com/aws/aws-cli.gitAltyapı:

Temel git clone komutu

“aws-cli” gibi herkese açık bir depoyu klonlarken, depo herkese açık olduğu için kimlik doğrulaması gerekmez. Sisteminizde git kurulu olduğu sürece, herhangi bir yapılandırma olmadan hemen herkese açık depoyu klonlayabilirsiniz.

Ancak özel bir depoyu klonluyorsanız kimlik doğrulaması gerekir. Şu yollarla kimlik doğrulayabilirsiniz:

• Kişisel Erişim Belirteci (PAT)
• Geçiş Anahtarları (Passkeys)

Kişisel erişim belirteci ile kimlik doğrulamayı göstermek için AWS EC2’de bir sunucu başlattım ve Git kurdum. Özel bir depoda git clone komutunu çalıştırdığımda kullanıcı adı ve parola istendi. Kullanıcı adı olarak GitHub kullanıcı adınızı, parola olarak da kişisel erişim belirtecinizi girin.

Kullanıcı adı/parola ile HTTPS kimlik doğrulaması

Artan güvenlik politikaları nedeniyle, GitHub ve diğer sağlayıcılar artık parola yerine kişisel erişim belirteci kullanılmasını zorunlu kılıyor.

 

HTTPS URL’leriyle klonlama için erişim belirteci talimatları. Kaynak: GitHub

Kişisel erişim belirtecinizi girmezseniz aşağıdaki hatayla karşılaşırsınız:

Parola ile kimlik doğrulama desteği kaldırıldı.

Bir kişisel erişim belirteci oluşturmak için Create a GitHub Token sayfasına gidin ve talimatları izleyin: 

GitHub’da kişisel erişim belirteci oluşturun

Git’in HTTPS üzerinden kimlik doğrulama gerektirdiği her seferde belirtecinizi girmemek için kimlik bilgilerinizi güvenli bir şekilde önbelleğe alan bir kimlik bilgisi yardımcısı kullanabilirsiniz. Popüler bir seçenek Git Credential Manager’dır. 

macOS’te Git, macOS Anahtarlık ile sorunsuz entegre olur; ben de kimlik bilgilerimi saklamak için bunu kullanıyorum. Benim durumumda, Anahtarlık’ta saklanan geçiş anahtarlarıyla kimlik doğrulaması yapıyorum; bu da güvenli ve sorunsuz bir deneyim sağlıyor.

Kimlik bilgisi yardımcısını görüntüleyin

macOS’te geçiş anahtarları

Bir geçiş anahtarı ayarlamak için GitHub’ın parola ve kimlik doğrulama ayarlarına gidin ve istemleri izleyin.

GitHub’da geçiş anahtarı oluşturun

GitHub, süresi dolmayan bir kişisel erişim belirteci oluşturmanıza izin verse de, çoğu kuruluş belirteçlerin son kullanma tarihine sahip olmasını gerektiren güvenlik politikaları uygular. Bu, bir belirteç CI/CD hatları gibi otomatik ortamlarda kullanılır ve süresi dolarsa, hattın kimlik doğrulama hataları nedeniyle başarısız olacağı anlamına gelir. Belirtecin süresi dolmadan önce proaktif olarak yeniden oluşturmak ve kullanımını buna göre güncellemek önemlidir.

Uygun kontroller olmadan, geliştiriciler farkında olmadan birden fazla kişisel erişim belirteci oluşturup kullanabilir ve bunları net bir şekilde belgelemeden ya da takip etmeden yönetebilir. Bu da hangi belirtecin nerede kullanıldığına dair kafa karışıklığına yol açabilir ve bakımı ile denetimi zorlaştırabilir. Daha iyi hijyen için belirteç kullanımını en aza indirmek, belgelemek ve belirli kullanım durumlarına bağlamak önerilir.

SSH klonlama yöntemi

SSH, özellikle düzenli katkı sağlayanlar ve ileri düzey kullanıcılar için uygun, güvenli ve kalıcı bir kimlik doğrulama yöntemi sunar. Kurulumdan sonra, kimlik bilgisi istemleri olmadan depolarla sorunsuz etkileşim sağlar.

SSH kimlik doğrulamasını kurmak için önce biri genel, diğeri özel olmak üzere bir SSH anahtar çifti üretmeliyiz.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "[email protected]"Altyapı:

SSH anahtar çifti oluşturma

Benim ~/.ssh/id_ed25519 yolunda zaten bir SSH anahtarım olduğundan, anahtarların bulunacağı varsayılan dizini ezdim. Ancak cihazınızda ilk kez SSH anahtarı oluşturuyorsanız, varsayılan dizini kabul edin.

Şuraya gidin: GitHub’da SSH ve GPC anahtarları ve SSH anahtarınızı kurun.

GitHub’da SSH anahtarı kurun

Genel anahtarın içeriğini “Key” bölümüne yapıştırın. Benim durumumda bu, id_ed25519.pub dosyasının içeriği.

id_ed25519.pub içeriğini yapıştırın

SSH, açık/özel anahtar şifrelemesi kullanır. Özel anahtarınızı makinenizde güvende tutun. Artık deponuz ister herkese açık ister özel olsun, SSH ile klonlamaya hazırsınız.

SSH başarılı bir şekilde kurulduktan sonra, SSH URL’sini seçmek artık yukarıdaki “Git URL türleri” bölümünde görülen uyarı mesajını göstermez.

GitHub’da bir deponun SSH URL’sini alma

SSH özel anahtarım yerel cihazımda bulunduğundan, git clone’u EC2 sunucusu yerine yerelimde SSH ile göstereceğim.

git clone [email protected]:aws/aws-cli.gitAltyapı:

Herkese açık ve özel depoları SSH ile klonlayın

SSH kullanarak git clone işlemini başarıyla gerçekleştirdik!

SSH’nin avantajları arasında güvenlik ve kuruluşlarda yaygın kullanım bulunur; parola gerektirmeyen kimlik doğrulama sayesinde sık etkileşimler için idealdir. SSH bağlantıları ağ kesintilerine karşı dayanıklıdır ve çoğu zaman uzun mesafelerde HTTPS’ten daha hızlıdır.

Bununla birlikte, geliştiriciler SSH anahtarı kurulumunda sıkça sorun yaşar; örneğin yanlış genel anahtarı Git sağlayıcısına kopyalarlar. Farklı amaçlar için birden fazla özel anahtarınız varsa, ~/.ssh/config dosyasında her ana bilgisayar için hangi anahtarın kullanılacağını tanımlamanız gerekir. Aksi halde GitHub’a kimlik doğrulaması yaparken Bitbucket için olan özel anahtar kullanılabilir ve bu da kimlik doğrulama hatasına neden olur.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519Altyapı:

Bağlantıyı test etmek ve kullanılan anahtarı doğrulamak için:

SSH bağlantısını doğrulayın

git clone Kullanımına Örnekler

Şimdiye kadarki git clone örnekleri, komutun sunduğu temel işlevselliği kapsıyor. 

Bu bölümde, bir deponun yerel makinenize klonlanma sürecini özelleştirmenize olanak tanıyan çeşitli seçenekler üzerinden size rehberlik edeceğim. Belirli dallarla çalışıyor olun veya hızı optimize etmeye çalışıyor olun, bu varyasyonları anlamak git clone’u daha etkili kullanmanıza yardımcı olacaktır.

Temel depo klonlama

Gördüğümüz gibi, git clone’un en basit kullanımı, bir uzak depoyu yerel makinenize klonlamaktır.

# HTTPS protocol
git clone https://github.com/aws/aws-cli.git

# SSH protocol
git clone [email protected]:aws/aws-cli.gitAltyapı:

Bu komutlar “aws-cli” adlı bir klasör oluşturur ve içinde sürüm geçmişi ile uzak izleme kurulumu tamamlanmış yerel bir kopya başlatır.

Belirli bir klasöre klonlama

Varsayılan olarak git clone, depoyla aynı ada sahip bir dizin oluşturur. Farklı bir hedef dizin adı belirtmek için bunu ikinci argüman olarak verin. 

Bu, aws-cli.git içeriğini my-project-folder adlı yerel klasöre klonlar:

git clone https://github.com/aws/aws-cli.git my-project-folderAltyapı:

Belirli bir klasöre klonlama

Belirli bir dalı veya etiketi klonlama

Uzak depodaki tüm dallar klonlandıktan sonra belirtilen dala checkout etmek için --branch (veya -b) bayrağını kullanın. Belirtilen dal, “HEAD” olarak checkout edilir; diğer dallar ise yerelde checkout için hazır bulunur.

“aws-cli” depo örneğimizde varsayılan dal develop. Bunun yerine master dalını klonlayıp checkout etmeyi deneyelim.

# Clone a branch
git clone --branch master https://github.com/aws/aws-cli.gitAltyapı:

Belirli bir dalı klonlama

Ayrıca belirli bir etiketi de klonlayabiliriz: 

# Clone a tag (read-only snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.gitAltyapı:

Belirli bir etiketi klonlama

Bu bayrak, belirli bir sürüm veya ortama özgü dal (ör. staging, hotfix veya release) üzerinde çalışırken kullanışlıdır.

Sığ klon (derinlik sınırlı)

Projenin yalnızca en son sürümüne ihtiyaç duyuyor ve tam commit geçmişini istemiyorsanız, sığ klon yapmak için --depth bayrağını kullanın. --depth bayrağı, kaç commit klonlamak istediğinizi belirtir.

# Download only the latest commit history
git clone --depth 1 https://github.com/aws/aws-cli.gitAltyapı:

Sığ klon

Bu işlem klonlama süresini hızlandırır ve disk kullanımını azaltır; CI/CD hatları veya commit geçmişiyle ilgilenmediğiniz durumlar için idealdir. Özellikle klonladığımız “aws-cli” deposu için faydalıdır. “aws-cli” depounda uzun bir commit geçmişi olduğundan, --depth bayrağını dahil etmenin zaman farkı büyüktür.

Sığ klon ile ve sığ klon olmadan zaman farkı

Yalnızca en son commit geçmişini tutmak, indirilecek bilgi miktarını azalttı ve dolayısıyla gereken süreyi düşürdü.

İleri Klonlama Yapılandırmaları

git clone komutu en yaygın olarak temel haliyle kullanılsa da, Git klonlama sürecinde daha fazla kontrol, verimlilik ve özelleştirme sağlayan birkaç gelişmiş seçenek sunar. 

Bu özellikler, büyük depolarla uğraşırken, altyapı düzeyindeki depoları yönetirken veya belirli geliştirme iş akışlarını optimize ederken özellikle kullanışlıdır. 

Bu bölümde, geliştiricilere ve DevOps mühendislerine güç kazandıran dal-özel işlemleri, sığ ve kısmi klonlar, depo uzmanlaşmaları ve ince ayarlı klonlama yapılandırmalarını inceleyeceğiz.

Dal-özel klonlama işlemleri

Varsayılan olarak git clone tüm dalları fetch eder ve varsayılan olanı checkout eder. Ancak büyük depolarla çalışırken veya belirli bir özelliğe katkı sağlarken, yalnızca tek bir dalı klonlamak daha verimli olur. Bu, --single-branch bayrağıyla sağlanabilir.

git clone --branch <branch-name> --single-branch <repo-url>
git clone --branch feature/cliq --single-branch https://github.com/aws/aws-cli.gitAltyapı:

Belirli bir dalı klonlayın

Avantajları arasında indirilen boyut ve sürenin azalması, özellik-odaklı geliştirme için daha hızlı kurulum ve gereksiz dal geçmişinden kaçınma bulunur.

Bu yaklaşım, bir sürüm dalı üzerinde çalışmak istediğinizde veya aktif CI/CD depolarındaki tüm dalları indirmekten kaçınmak istediğinizde idealdir. Komutta dal adı belirtilmezse, Git yalnızca varsayılan dalı klonlar.

Belirli bir dalı klonlama hakkında daha fazla bilgi için Git Clone Branch öğreticisine göz atın.

Uzmanlaşmış depo türleri

Bir depoyu klonladığımızda iki bileşen klonlanır: depo (.git klasörü) ve çalışma dizini. Çalışma dizini; çalışma kopyası, çalışma ağacı (work tree) veya çalışma alanı olarak da anılır.

Çalışma dizini ve depo arasındaki fark

.git klasörünün içeriği şu şekildedir:

.git klasörünün içeriği

Bu da bizi “çıplak (bare) depo” konusuna getiriyor.

Bare depolar

Bare bir depo yalnızca .git klasörünü içerir ve çalışma dizinine sahip değildir.

git clone --bare <repo-url>
git clone --bare https://github.com/aws/aws-cli.gitAltyapı:

Bare bir depoyu klonlayın

Yukarıdan görebileceğimiz gibi, --bare bayrağıyla klonlanan içeriğin, bare olmayan deponun .git klasöründeki içeriklerden ibaret olduğunu görüyoruz. Bu bare bir depo olduğu için çalışma dizini yoktur; bu da aşağıdaki görselde gösterildiği gibi git komutlarını çalıştıramayacağımız anlamına gelir:

İşlem bir çalışma ağacında yürütülmelidir

Bare depolar genellikle iş birliği veya yansılama (mirroring) için paylaşılan ortamlarda merkezi depo olarak kullanılır; aktif geliştirme için değil. Bare depodan klonlamayı göstermek için yerelimdeki “aws-cli” bare deposunu kullanacağım.

Yerel bare depomdan klonlama

“aws-cli-non-bare” deposunun bir çalışma dizini içerdiğini görebiliriz. git remote -v çalıştırarak bare depoya referans verdiğini görebilirsiniz.

Yansılanmış depolar

git clone --mirror komutu, kaynak deponun bir yansımasını kurar. --mirror bayrağı --bare anlamına da gelir; yani yansı depo da bir çalışma dizini içermez. 

git clone --mirror <repo-url>
git clone --mirror https://github.com/aws/aws-cli.gitAltyapı:

Bir (merkezi) depoyu klonlayarak yansı depo oluşturma

Ancak --bare ile karşılaştırıldığında, --mirror yalnızca kaynağın yerel dallarını hedefin yerel dallarına eşlemekle kalmaz, tüm ref’leri (uzak izleme dalları, notlar vb.) de eşler ve hedef depoda git remote update çalıştırıldığında bu ref’lerin tümünü üzerine yazacak bir refspec yapılandırması kurar. Bu, tüm referansları (dallar, etiketler vb.) içeren daha kapsamlı bir kopya sağlar.

Yansı bir depo oluşturmanın tüm adımları için GitHub dokümantasyonuna başvurabilirsiniz.

Bir depoyu başka bir konumda yansılama. Kaynak: GitHub

Kısmi klon filtreleri ve klon boyutunu azaltma

Kısmi klonlar, --filter bayrağını kullanarak depo nesnelerinin yalnızca bir alt kümesinin getirilebilmesini sağlar; bu da özellikle bant genişliği veya disk kısıtlamaları olan ortamlarda, kod tabanının yalnızca bir kısmına ihtiyaç duyan geliştiriciler için uygundur. --filter bayrağına ilişkin yaygın örnekler şunlardır:

• --filter=blob:none: dosya içeriklerini (blob’ları) atlar
• --filter=blob:limit=<size>: belirli bir boyut ve üzerindeki dosyaları hariç tutar
• --filter=tree:<depth>: kök ağaçtan derinliği tanımlanan derinliğe eşit veya daha fazla olan tüm blob ve ağaçları hariç tutar.

blob:none

--filter=blob:none bayrağı, dosya içeriklerinin (blob’ların) anında indirilmesini önleyerek klonlama işlemlerini optimize etmek için kullanılır. 

# Binary Large Objects (BLOB)
git clone --filter=blob:none <repo-url>
git clone --filter=blob:none https://github.com/aws/aws-cli.gitAltyapı:

filter=blob:none ile klonlama

Bu, büyük depolarda veya projenin yalnızca bir alt kümesine ihtiyaç duyulduğunda özellikle kullanışlıdır. Örneğin monorepo’larda, tüm ekiplerin veya geliştiricilerin tüm kod tabanına ihtiyacı yoktur. 

Yalnızca frontend/ üzerinde çalışan bir frontend mühendisi, backend servislerine veya paylaşılan kütüphanelere ihtiyaç duymaz. --filter bayrağı, dosya blob’unu dosya açıldığında olduğu gibi gerektiğinde indirerek klonlamayı hızlandırır ve depolamayı azaltır. Aşağıdaki görüntü, bir dosyayı açtığımda Git’in arka planda ne yaptığını ve dosya blob’unu talep üzerine indirdiğini gösterir.

Git dosya blob’unu talep üzerine indirir

Bir diğer örnek CI/CD hatlarıdır. Hatlar çoğu zaman tam depo geçmişine veya her dosyaya ihtiyaç duymaz. Sparse-checkout ile birlikte kullanıldığında --filter=blob:none, hattın yalnızca ilgili dizinleri (ör. dağıtım betikleri) klonlamasına olanak tanır.

blob:limit=<size>

--filter=blob:limit=<size> bayrağı, geliştiricilerin klonlama sırasında büyük dosyaları (blob’ları) indirmekten kaçınırken küçük dosyaları anında almasını sağlar. Bu, Git’in kısmi klon işlevinin bir parçasıdır ve karışık boyutlu içerik barındıran depolarla çalışırken özellikle faydalıdır.

Örneğin, özellikle Git LFS kullanılan projelerde veya medya varlıklarının (videolar, büyük veri setleri, oyun varlıkları gibi) commitlendiği projelerde, geliştiriciler klonlama sırasında büyük dosyaları atlamak, böylece ilk klonlamayı hızlandırmak ve büyük dosyaların indirilmesini açıkça ihtiyaç duyulana kadar ertelemek isteyebilir.

# Binary Large Objects (BLOB)
git clone --filter=blob:limit=<size> <repo-url>
#  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB
git clone --filter=blob:limit=<n>[kmg] <repo-url>
git clone --filter=blob:limit=1m https://github.com/aws/aws-cli.gitAltyapı:

filter=blob:limit ile klonlama

tree:<depth>

--filter=tree:<depth> bayrağı, klon sırasında Git’in ağaç nesnelerini dizin yapısında ne kadar derine kadar getireceğini sınırlandırmak için kullanılır; bu da özellikle monorepo gibi derin dizin yapılarında çalışanlar için veri aktarımını azaltmaya yardımcı olur. Örneğin, büyük bir monorepo yapısını hızla incelemek istiyorsanız (denetim, işe alıştırma veya gözden geçirme amaçlı), derin ağaçları indirmek israftır.

git clone --filter=tree:<depth> <repo-url>
git clone --filter=tree:0 https://github.com/aws/aws-cli.gitAltyapı:

filter=tree ile klonlama

Klonladığınız Git sunucusunun (bu durumda GitHub) ağaç filtreleme derinliği için yalnızca belirli değerleri destekleyebileceğini unutmayın.

Ağaç filtresi için izin verilen azami derinlik 0

Klonlamaya özgü yapılandırma

Git, klonlama sırasında davranışı özelleştirmek için çeşitli seçenekler sağlar:

• --origin <name>: origin yerine özel bir uzak adı ayarlar
• --template <dir>: ilk .git kurulumu için şablon dosyaları içeren bir dizin kullanır
• --single-branch: diğer dalları fetch etmeyi önler
• --recurse-submodules: alt modülleri otomatik olarak başlatır ve klonlar

Bu seçenekler, standartlaştırılmış ortamlar kurarken, modüler depolarla çalışırken veya dağıtım araçlarıyla entegrasyon yaparken faydalıdır.

origin

--origin <name> bayrağı, geliştiricilerin deponun klonlandığı uzak adını özelleştirmesine olanak tanır. Varsayılan olarak Git uzak adı olarak origin’i kullanır; ancak bu bayrakla klonlama sırasında bunu başka bir şeyle değiştirebilirsiniz.

git clone --origin <remote name> <repo-url>
# Name the remote as “upstream”
git clone --origin upstream https://github.com/aws/aws-cli.gitAltyapı:

Uzağı origin’den upstream’e yeniden adlandırın

Geliştiricilerin, daha sonra başka bir uzak eklemeleri gerekebileceğinden (ör. upstream vs. çatallanmış origin), netlik için uzak adını değiştirmeleri gerekebilir. İlk uzak adını değiştirmek kafa karışıklığını ve çakışmaları önlemeye yardımcı olur.

template

--template bayrağı, geliştiricilerin yeni klonlanan depoda .git dizini oluşturulurken Git’in kullanacağı özel bir şablon dizini belirtmesine olanak tanır. Şablon dizinleri, başlatma sırasında depoya otomatik olarak uygulanacak kancalar (hooks), yapılandırma dosyaları veya dizin yapıları tanımlamanıza izin verir.

# Specify the directory from which templates will be used
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.gitAltyapı:

--template bayrağının kullanımı

Template bayrağını “Şablon dizini uygulaması” bölümünde daha ayrıntılı ele alacağım.

single-branch

--single-branch bayrağı, uzak depodaki tüm dallar yerine yalnızca belirtilen dalın geçmişini klonlamak için kullanılır. Bu, çok sayıda uzun ömürlü dala veya büyük bir commit geçmişine sahip depolarda klonlanan veri miktarını önemli ölçüde azaltabilir.

Belirli bir özellik veya sürüm dalında görevlendirildiğinizde (ör. feature/login-ui, release/v2.0), diğer ilgisiz dalların geçmişini klonlamanıza gerek yoktur.

git clone --branch feature/login-ui --single-branch <repo-url>

# If you do not specify a branch, Git will clone only the remote's default branch, usually main or master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.gitAltyapı:

Tipik bir git clone tüm uzak dalları izler; aşağıdaki git branch -r çıktısında görüldüğü gibi.

Tüm uzak dallar izlenir

Oysa --single-branch eklendiğinde yalnızca belirtilen dalın geçmişi klonlanır.

Yalnızca varsayılan dal izlenir

recurse-submodules

Git alt modülleri, belirli bir commit’e sabitlenmiş başka bir depoya referanstır. Diğer Git deposunu, Git deponuzun bir alt dizini olarak tutmanıza olanak tanır; genellikle üçüncü taraf kodu, paylaşılan kütüphaneler veya tedarikçi bileşenleri dahil etmek için kullanılır. 

Bu kavramı göstermek için herkese açık bir GitHub deposu oluşturdum.

Alt modülleri gösterme

Alt modül içeren bir projeyi klonladığımızda, varsayılan olarak alt modülleri içeren dizinleri alırız; ancak içlerindeki dosyaları almayız.

Boş alt modül klasörü

Yerel yapılandırma dosyanızı başlatmak için git submodule init ve o projeden tüm verileri almak için git submodule update çalıştırmak yerine, git clone komutuyla birlikte --recurse-submodules bayrağını kullanarak bir deponun .gitmodules dosyasında tanımlanan tüm alt modülleri otomatik olarak başlatıp klonlayabiliriz.

git clone --recurse-submodules <repo-url>Altyapı:

Alt modül dizini içindeki dosyaları klonlama

Şablon dizini uygulaması

Git, klonlama veya depo başlatma sırasında varsayılan kancaları, yapılandırmaları ve diğer dosyaları tanımlamak için şablon dizinlerin kullanılmasına izin verir:

Şablon dizininin yapısı aşağıdakine benzer olabilir; burada hooks/pre-commit JIRA ID’si olmayan commit’leri engelleyen bir kabuk betiği kancası içerir; hooks/commit-msg ise commit mesajları için bir şablon içerir.

/home/devops/git-template/
├── config
├── description
├── hooks/
│   ├── pre-commit
│   └── commit-msg
├── info/
│   └── excludeAltyapı:

Şablon dizininde gerekli dosyaları tanımladıktan sonra, bunu git clone işlemlerinizde kullanabilirsiniz.

git clone --template=</path/to/template> <repo-url>
git clone --template=/home/devops/git-template https://github.com/aws/aws-cli.gitAltyapı:

Şunlar için idealdir:

• Kancalar aracılığıyla depo politikalarını zorlamak (ör. pre-commit)
• CI/CD veya araçlar için yapılandırma dosyalarını önceden tanımlamak
• Ortak bir yapıyla projeleri hızlı başlatmak

Şablon dizinleri, ekip iş akışlarını kolaylaştırır ve klonlanan depolar arasında tutarlılık sağlar.

Farklı İşletim Sistemlerinde Klonlama

git clone komutu çekirdekte tüm platformlarda aynı şekilde çalışsa da, deneyim işletim sistemine bağlı olarak biraz farklılık gösterebilir. 

Terminal araçları, dosya yolu biçimleri ve izin yönetimi gibi ortama özgü hususlar, geliştiricilerin Git ile nasıl etkileşime geçtiğini etkileyebilir. Bu bölümde, Windows, Linux/Ubuntu ve macOS’te klonlama sürecini, olası nüansları aşmanıza yardımcı olmak için anlatacağım.

Windows

Windows’ta geliştiriciler genellikle Git komutlarını çalıştırmak için Git Bash, PowerShell veya Komut İstemi’ni kullanır. indirme sayfasından Git’i kurabiliriz; bu sayfa Git Bash’i de birlikte getirir; bu, Windows’ta Git kullanımı için uyarlanmış Unix benzeri bir kabuktur.

Git Bash’te git clone

PowerShell’de git clone

Dikkat edilmesi gereken birkaç husus:

• Git Bash’te dosya yolları Unix tarzı biçimi kullanır (/c/Users/username/), PowerShell ve Komut İstemi ise Windows biçimini kullanır (C:\Users\username\).
• PowerShell kullanıyorsanız, Git’in sistem PATH’inize eklendiğinden emin olun.

Linux/Ubuntu

Ubuntu gibi Linux dağıtımları, yerel terminal aracılığıyla sorunsuz bir Git deneyimi sunar. Aşağıdaki örnek için AWS’de bir Ubuntu EC2 örneği başlattım ve SSH ile bağlandım.

Ubuntu EC2 örneğine SSH ile bağlanın

Git varsayılan olarak kurulmuştu. Yine de sizde yüklü değilse, sudo apt install git komutunu çalıştırmanız yeterlidir.

Ubuntu’da git kurulumu

İstediğiniz dizine gidin ve git clone komutunu çalıştırın.

Ubuntu’da git clone

Dikkat edilmesi gereken birkaç husus:

• Özel depolar için SSH anahtarlarının düzgün yapılandırıldığından emin olun (~/.ssh/id_rsa).
• Özellikle sistem düzeyi yollara klonlarken, dosya izinleri ve dizin sahipliği depo işlemlerini etkileyebilir.

Mac

macOS, Linux’a çok benzeyen Unix tabanlı bir ortam sunar; bu da Git işlemlerini sezgisel hale getirir. Git genellikle önceden kurulu gelir. Eğer yoksa, Xcode Komut Satırı Araçlarını (xcode-select --install) kurmak Git’i de kuracaktır.

Terminal’i açın ve git clone komutunu çalıştırın.

Mac’te git clone

Dikkat edilmesi gereken birkaç husus:

• Linux’te olduğu gibi, özel depolar için SSH anahtar yönetimi önemlidir.
• macOS kullanıcıları sıklıkla GitHub Desktop veya Sourcetree gibi GUI istemcileri kullanır; alttaki Git kurulumunun doğru yapılandırıldığından emin olun.

Pratik Uygulama Senaryoları

git clone çoğu zaman yalnızca bir deponun kopyasını edinmek için kullanılsa da, gerçek dünyadaki mühendislik iş akışlarında bunun ötesine uzanan bir faydaya sahiptir. 

Bu bölümde, verimliliği ve tutarlılığı en üst düzeye çıkarmak için özel bir yaklaşım gerektiren pratik senaryolarda klonlama stratejilerinin nasıl uygulanacağını inceliyorum.

Kurumsal geliştirme iş akışı

Büyük kuruluşlarda, verimli depo klonlama, geliştirici işe alımını kolaylaştırmak ve proje kurulumunu standartlaştırmak için kritik öneme sahiptir. Aşağıdaki stratejiler benimsenebilir:

• İlk olarak sığ klonlar (--depth=1). Tam commit geçmişine ihtiyaç duymayan yeni geliştiriciler için kurulum süresini kısaltmak amacıyla sıklıkla kullanılır.
• İkincisi, şablon depolar. Şablon dizinleri ile karıştırılmamalıdır. Şablon depolar; hızlı proje başlatma için klonlanacak ön tanımlı klasör yapıları, kancalar ve alt modüller içerir. GitHub’da ayarlara giderek bir depoyu şablon depo olarak etkinleştirebilirsiniz.

Şablon depo ayarı

Bunu etkinleştirdikten sonra, depo ana sayfanızda “Use this template” düğmesini bulacaksınız.

Depoyu şablon olarak kullanın

• Son olarak, harici depoların dahili yansıları (mirror) kamu ağlarına bağımlılığı azaltır ve güvenli ortamlarda klonlamayı hızlandırır.

Depo taşıma prosedürü

Kuruluşlar çeşitli nedenlerle (güvenlik, uyumluluk veya finansal) depolarını platformlar arasında (ör. GitHub’dan GitLab’a) taşıyabilir. Taşıma, tüm dallar, etiketler ve commit geçmişi dahil olmak üzere eksiksiz bir kopya için mirror klon gerektirir.

Tipik bir süreç şu şekilde olabilir:

# --mirror flag clones all refs and configuration.
git clone --mirror https://source-url.com/your-repo.git
cd your-repo.git
git push --mirror https://target-url.com/your-new-repo.gitAltyapı:

Bu yöntem, standart bir klon ve ardından push işlemine göre Git metaverilerini daha iyi korur. Taşıma sonrası uzak URL’leri güncelleyin ve erişim izinlerini doğrulayın.

CI/CD hattı optimizasyonu

Otomatik ortamlarda, klonlama işlemlerini optimize etmek zamandan tasarruf sağlar ve kaynak kullanımını azaltır; özellikle yüksek frekanslı dağıtımlarda. Verimli bir hat akışı için şu en iyi uygulamalara uyabiliriz:

• İlk olarak, iş başlangıç zamanlarını hızlandırmak için sığ klonlar (--depth=1) kullanın.

git clone --depth 1 <repository-url>Altyapı:

• İkinci olarak, gereksiz referanslardan kaçınmak için yalnızca gerekli dalı klonlayın.

git clone --branch <branch-name> --single-branch <repo-url>Altyapı:

• Son olarak, CI/CD hattınızdaki birden çok aşama aynı depo içeriğine erişmeyi gerektiriyorsa, tekrarlanan git clone işlemlerinden kaçınmak için bir önbellekleme mekanizması uygulamayı düşünün. Depoyu her aşamada klonlamak yerine, ilk checkout’tan sonra çalışma dizinini önbelleğe alın ve bunu sonraki aşamalara yapıt (artifact) veya paylaşılan birim olarak aktarın. 

Bu yaklaşım, gereksiz işlemleri önemli ölçüde azaltır, hattın yürütülmesini hızlandırır ve bilgi işlem ile ağ kaynaklarını korur.

Sorun Giderme ve Teşhis

git clone yaygın ve basit bir komut olsa da, özellikle sıkı kimlik doğrulama kontrollerinin, özel depo yapılandırmalarının veya sınırlı ağ erişiminin olduğu ortamlarda geliştiriciler zaman zaman klonlama sürecinde sorunlarla karşılaşabilir. 

Bu bölümde, yaygın klonlama sorunlarını ve bunları verimli bir şekilde nasıl çözeceğinizi anlatacağım.

Kimlik doğrulama hatalarının çözümü

Kimlik doğrulama hataları genellikle özel depolara erişirken veya süresi dolmuş kimlik bilgileri kullanıldığında ortaya çıkar. Protokole (HTTPS veya SSH) bağlı olarak farklı hata mesajları ve düzeltmeler söz konusudur. MFA etkin ortamlar için her zaman SSH’yi veya PAT’lerle HTTPS’yi tercih edin.

HTTPS için yaygın bir hata kimlik doğrulama hatasıdır. Bu, süresi dolmuş bir kişisel erişim belirtecinin kullanımı sonucu olabilir. MFA etkinse bir diğer olası neden, parola olarak kişisel erişim belirtecinin kullanılmamış olmasıdır.

HTTPS kimlik doğrulama hatası

SSH için yaygın bir hata “Permission denied (publickey)” hatasıdır. Bunun nedeni, genel anahtarın Git sağlayıcı hesabına eklenmemiş olması ya da yerel cihazınızda saklanan özel anahtarın doğru dizinde bulunmaması olabilir.

SSH kimlik doğrulama hatası

Bağlantıyı şu şekilde doğrulayabilirsiniz:

ssh -T [email protected]Altyapı:

Kısmi klonda nesne alma

Nadiren de olsa, kısmi klonlar (--filter veya --depth bayrakları) kullanırken, Git başlangıçta alınmayan depo bölümlerine erişmeye çalışırsa eksik nesneler (“error: object <sha> is missing” gibi) ile karşılaşabilirsiniz. 

Ben bu durumla hiç karşılaşmadım. Yine de, geçmiş commit’lere, dallara veya etiketlere erişirken hatalarla karşılaşabilirsiniz. Bu bir hat içinde ise, derleme araçları veya betikler başarısız olabilir. Eksik veriyi açıkça şu şekilde alabilirsiniz:

# Have Git refetch all objects from the remote, even if it thinks it already has them.
# For dealing with a broken or corrupted partial clone
git fetch --filter=blob:none --refetch

# Convert a shallow clone into a full clone. Retrieves the rest of the commit history that was omitted during the shallow clone.
git fetch --unshallow

# Obtain a deeper history of the branch
git fetch origin <branch> --depth=50

# Fetches 30 more commits from the current branch’s history. Repeat as needed.
git fetch --deepen=30Altyapı:

Git’in uzak depodan tüm nesneleri yeniden almasını sağlayın

Yaygın git clone hata mesajları ve çözümleri

Yukarıdakilere ek olarak, git clone sırasında karşılaşabileceğiniz diğer yaygın hatalar aşağıdaki tabloda yer almaktadır.

Sonuç

git clone komutu ilk bakışta basit görünebilir ve pek çok kişi için temel kullanım yeterli olmuştur. Ancak bu makalenin gösterdiği gibi, kapsamlı uygulamaları olan temel bir araçtır. 

git clone’un nasıl çalıştığını ele aldık; URL türleri ve protokolleri inceledik; gelişmiş yapılandırmalar ve işletim sistemine özgü davranışları gözden geçirdik ve CI/CD, kurumsal iş akışları ve yaygın sorun giderme teknikleri gibi gerçek dünya senaryolarını değerlendirdik.

Ortamınıza göre git clone’u uyarlamak — ister hatlarda sığ klonlar, ister depo taşımaları, ister büyük ölçekli iş birliği — performansı ve ekip verimliliğini önemli ölçüde artırabilir. Modern geliştirme ortamları giderek daha karmaşık ve dağıtık hale geldikçe, bu yapılandırmalara hâkim olmak yalnızca Git’i kullanmakla kalmayıp onu etkili kullanmanızı da sağlar.

İleriye dönük olarak, Git’in klonlama mekanizmaları daha da iyileştirilebilir; örneğin daha akıllı kısmi klonlar, büyük monorepo’lar için daha iyi destek ve alt modüller ile filtrelerin daha sezgisel ele alınması. Git geliştikçe, bu iyileştirmeleri takip etmek geliştiricilerin her sistem ve ölçekte daha hızlı ve verimli çalışmasını sağlayacaktır.

Git hakkında daha fazla bilgi edinmek için şunu öneririm: Introduction to Git kursu. Yeteneklerinizi bir üst seviyeye taşımak isterseniz, Advanced Git kursu tam size göre!