{"id":34368,"date":"2025-11-15T20:31:14","date_gmt":"2025-11-15T17:31:14","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/depolama-sunucusuna-git-deposu-klonlama-rehberi\/"},"modified":"2025-11-15T20:31:14","modified_gmt":"2025-11-15T17:31:14","slug":"depolama-sunucusuna-git-deposu-klonlama-rehberi","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/depolama-sunucusuna-git-deposu-klonlama-rehberi\/","title":{"rendered":"Depolama Sunucusuna Git Deposu Klonlama Rehberi"},"content":{"rendered":"

<\/p>\n

Yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde kod taban\u0131m\u0131z\u0131n g\u00fcvenli\u011fi, eri\u015filebilirli\u011fi ve s\u00fcrd\u00fcr\u00fclebilirli\u011fi kritik \u00f6neme sahiptir. Peki, de\u011ferli Git depolar\u0131m\u0131z\u0131 bir depolama sunucusuna klonlamak, bu hedeflere ula\u015fmam\u0131z\u0131 nas\u0131l sa\u011flar? Bu detayl\u0131 rehberde, Git depolar\u0131n\u0131 depolama sunucular\u0131na klonlaman\u0131n inceliklerini, sundu\u011fu avantajlar\u0131 ve ad\u0131m ad\u0131m nas\u0131l uygulanaca\u011f\u0131n\u0131 ke\u015ffedece\u011fiz. Geli\u015ftirme ekipleri i\u00e7in felaket kurtarma senaryolar\u0131ndan da\u011f\u0131t\u0131k i\u015f ak\u0131\u015flar\u0131na kadar geni\u015f bir yelpazede \u00e7\u00f6z\u00fcmler sunan bu y\u00f6ntemin, modern yaz\u0131l\u0131m altyap\u0131lar\u0131n\u0131n vazge\u00e7ilmez bir par\u00e7as\u0131 oldu\u011funu g\u00f6receksiniz. \u00d6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli projelerde veya hassas veri i\u00e7eren depolarda, bu strateji hem veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korur hem de operasyonel esnekli\u011fi art\u0131r\u0131r.<\/p>\n

Modern yaz\u0131l\u0131m geli\u015ftirme, s\u00fcrekli de\u011fi\u015fen ve b\u00fcy\u00fcyen kod tabanlar\u0131n\u0131 y\u00f6netme zorunlulu\u011funu beraberinde getirir. Git gibi da\u011f\u0131t\u0131k versiyon kontrol sistemleri (VCS) bu karma\u015f\u0131kl\u0131\u011f\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde hafifletse de, sadece yerel kopyalarla \u00e7al\u0131\u015fmak veya tek bir merkezi depoya g\u00fcvenmek ciddi riskler ta\u015f\u0131r. \u0130\u015fte tam da bu noktada, Git depolar\u0131n\u0131 ayr\u0131 bir depolama sunucusuna klonlama stratejisi devreye girer. Bu yakla\u015f\u0131m, basit bir yedekleme i\u015fleminden \u00e7ok daha fazlas\u0131n\u0131 sunar; geli\u015ftirme i\u015f ak\u0131\u015flar\u0131n\u0131 g\u00fc\u00e7lendirir, veri g\u00fcvenli\u011fini art\u0131r\u0131r ve ekiplere daha fazla esneklik sa\u011flar. \u00d6zellikle kritik projelerde, ana depo sunucusunun aniden eri\u015filemez hale gelmesi veya veri kayb\u0131 ya\u015famas\u0131 durumunda, klonlanm\u0131\u015f bir depolama sunucusu, felaket kurtarma senaryolar\u0131nda hayati bir rol oynar. Bu durum, geli\u015ftirme s\u00fcre\u00e7lerinin kesintisiz devam etmesini garanti alt\u0131na alman\u0131n en etkili yollar\u0131ndan biridir. Ayr\u0131ca, farkl\u0131 co\u011frafi konumlardaki ekiplerin ayn\u0131 kod taban\u0131 \u00fczerinde e\u015f zamanl\u0131 \u00e7al\u0131\u015fabilmesi i\u00e7in de klonlama, merkezi bir eri\u015fim noktas\u0131 sunarak senkronizasyon sorunlar\u0131n\u0131 minimize eder. Bu sayede, geli\u015ftiriciler kendi b\u00f6lgelerine en yak\u0131n sunucudan klonlama yaparak hem veri transfer h\u0131z\u0131n\u0131 art\u0131r\u0131r hem de genel geli\u015ftirme verimlili\u011fini y\u00fckseltir.<\/p>\n

Bir depolama sunucusuna klonlama yapman\u0131n temel faydalar\u0131ndan biri, ku\u015fkusuz, veri yedeklemesidir. Ana Git depo sunucusu (\u00f6rne\u011fin GitHub, GitLab veya Bitbucket) hizmet d\u0131\u015f\u0131 kald\u0131\u011f\u0131nda, veri b\u00fct\u00fcnl\u00fc\u011f\u00fc bozuldu\u011funda veya yanl\u0131\u015fl\u0131kla silindi\u011finde, depolama sunucusundaki klonlanm\u0131\u015f kopya bir cankurtaran halini al\u0131r. Bu, sadece bir kopya bulundurmak de\u011fil, ayn\u0131 zamanda bu kopyan\u0131n ba\u011f\u0131ms\u0131z bir altyap\u0131da saklanmas\u0131 anlam\u0131na gelir. Bu ba\u011f\u0131ms\u0131zl\u0131k, tek hata noktas\u0131n\u0131 ortadan kald\u0131rarak, i\u015f s\u00fcreklili\u011fini maksimize eder. Dolay\u0131s\u0131yla, bu strateji, beklenmedik felaketler kar\u015f\u0131s\u0131nda projenizin “Plan B”sini olu\u015fturur. \u00d6rne\u011fin, bir DevOps ekibi, ana Git sunucusunda planl\u0131 bak\u0131m yaparken veya bir siber sald\u0131r\u0131 durumunda, depolama sunucusundaki klonlanm\u0131\u015f depoyu h\u0131zl\u0131ca devreye alarak geli\u015ftirme s\u00fcrecini duraksatmadan devam ettirebilir. Bu senaryo, operasyonel \u00e7evikli\u011fi art\u0131r\u0131rken, potansiyel maliyetli duru\u015f s\u00fcrelerini de \u00f6nler. Ayr\u0131ca, yasal uyumluluk gerektiren sekt\u00f6rlerde (finans, sa\u011fl\u0131k vb.) veri yedeklemesi ve ar\u015fivleme zorunluluklar\u0131 bulunur. Klonlanm\u0131\u015f depolar, bu t\u00fcr reg\u00fclasyonlara uyum sa\u011flamak i\u00e7in de ideal bir \u00e7\u00f6z\u00fcm sunar, \u00e7\u00fcnk\u00fc belirli bir tarihteki kod taban\u0131n\u0131n de\u011fi\u015ftirilemez bir kopyas\u0131n\u0131 tutma imkan\u0131 sa\u011flar.<\/p>\n

Klonlama, ayn\u0131 zamanda performans ve i\u015f ak\u0131\u015f\u0131 optimizasyonu i\u00e7in de \u00f6nemli avantajlar sunar. B\u00fcy\u00fck projelerde, binlerce dosya ve uzun commit ge\u00e7mi\u015fi i\u00e7eren depolar\u0131n her geli\u015ftirici taraf\u0131ndan do\u011frudan merkezi sunucudan indirilmesi veya g\u00fcncellenmesi a\u011f trafi\u011fini art\u0131rabilir ve gecikmelere neden olabilir. Depolama sunucusuna yap\u0131lan klonlama sayesinde, \u00f6zellikle yerel a\u011fdaki veya daha yak\u0131n bir co\u011frafyadaki bir sunucudan \u00e7ekim (pull) i\u015flemleri daha h\u0131zl\u0131 ger\u00e7ekle\u015ftirilebilir. Bu durum, da\u011f\u0131t\u0131k geli\u015ftirme ekipleri i\u00e7in b\u00fcy\u00fck bir avantaj sa\u011flar. Geli\u015ftiriciler, ana sunucu yerine, kendilerine en yak\u0131n depolama sunucusundan g\u00fcncellemeleri \u00e7ekerek zaman kazan\u0131r ve daha ak\u0131c\u0131 bir geli\u015ftirme deneyimi ya\u015farlar. Ayr\u0131ca, baz\u0131 senaryolarda, ana Git sa\u011flay\u0131c\u0131s\u0131n\u0131n bant geni\u015fli\u011fi veya eri\u015fim limitleri olabilir. Klonlanm\u0131\u015f bir depo, bu t\u00fcr k\u0131s\u0131tlamalar\u0131 a\u015farak ba\u011f\u0131ms\u0131z bir eri\u015fim noktas\u0131 sunar. \u00d6zellikle CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) boru hatlar\u0131nda, test ve derleme sunucular\u0131n\u0131n depolama sunucusundaki klonlanm\u0131\u015f depolara eri\u015fimi, ana Git sunucusundaki y\u00fck\u00fc azalt\u0131r ve CI\/CD s\u00fcre\u00e7lerinin daha verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Bu sayede, hem geli\u015ftiricilerin hem de otomasyon sistemlerinin verimlili\u011fi art\u0131r\u0131larak genel proje teslim s\u00fcreleri k\u0131sal\u0131r.<\/p>\n

Temel Kavramlar: Git, Depolar ve Depolama Sunucular\u0131 Nedir?<\/h2>\n

Git deposunu bir depolama sunucusuna klonlamadan \u00f6nce, ilgili temel kavramlar\u0131 iyi anlamak \u00f6nemlidir. Bu temel bilgiler, i\u015flemlerinizi daha bilin\u00e7li bir \u015fekilde yapman\u0131z\u0131 ve potansiyel sorunlar\u0131 daha kolay \u00e7\u00f6zmenizi sa\u011flayacakt\u0131r. \u00d6ncelikle, konunun merkezinde yer alan Git nedir? Git, Linus Torvalds taraf\u0131ndan 2005 y\u0131l\u0131nda Linux \u00e7ekirde\u011fi geli\u015ftirme s\u00fcrecini y\u00f6netmek i\u00e7in olu\u015fturulmu\u015f, da\u011f\u0131t\u0131k bir versiyon kontrol sistemidir (DVCS). Di\u011fer merkezi sistemlerden (SVN gibi) farkl\u0131 olarak, Git’te her geli\u015ftiricinin yerel makinesinde kod taban\u0131n\u0131n tam bir kopyas\u0131, yani tam bir depo bulunur. Bu, \u00e7evrimd\u0131\u015f\u0131 \u00e7al\u0131\u015fmaya olanak tan\u0131r ve merkezi sunucuya olan ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 azalt\u0131r. Git’in bu da\u011f\u0131t\u0131k yap\u0131s\u0131, klonlama kavram\u0131n\u0131n temelini olu\u015fturur; bir depoyu klonlad\u0131\u011f\u0131n\u0131zda, asl\u0131nda o deponun t\u00fcm commit ge\u00e7mi\u015fiyle birlikte eksiksiz bir kopyas\u0131n\u0131 al\u0131rs\u0131n\u0131z. Bu, projenin ba\u015f\u0131ndan itibaren yap\u0131lan t\u00fcm de\u011fi\u015fiklikleri, t\u00fcm dallar\u0131 ve etiketleri i\u00e7erir, b\u00f6ylece tam bir ge\u00e7mi\u015fe sahip olursunuz. Git, de\u011fi\u015fiklikleri izleme, birle\u015ftirme (merge), dallanma (branching) ve geri alma (revert) gibi g\u00fc\u00e7l\u00fc \u00f6zellikler sunarak geli\u015ftiricilerin i\u015fbirli\u011fi i\u00e7inde verimli bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.<\/p>\n

Peki, bir “depo” (repository) tam olarak nedir? Git ba\u011flam\u0131nda bir depo, projenizin t\u00fcm dosyalar\u0131n\u0131, her dosyan\u0131n zaman i\u00e7indeki de\u011fi\u015fiklik ge\u00e7mi\u015fini ve bu de\u011fi\u015fiklikleri izleyen Git meta verilerini i\u00e7eren bir dizindir. Depolar genellikle iki ana t\u00fcre ayr\u0131l\u0131r: yerel depolar ve uzak depolar. Yerel depo, geli\u015ftiricinin kendi bilgisayar\u0131nda bulunan ve \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131 kopyad\u0131r. Uzak depo ise, genellikle bir sunucuda bar\u0131nd\u0131r\u0131lan ve birden fazla geli\u015ftiricinin \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131 projenin ana kopyas\u0131d\u0131r. GitHub, GitLab, Bitbucket gibi platformlar, uzak depolar\u0131n bar\u0131nd\u0131r\u0131lmas\u0131 i\u00e7in pop\u00fcler hizmet sa\u011flay\u0131c\u0131lar\u0131d\u0131r. Bir depoyu klonlad\u0131\u011f\u0131n\u0131zda, uzak depodaki t\u00fcm verileri yerel makinenize (veya ba\u015fka bir sunucuya) kopyalayarak, o deponun t\u00fcm tarih\u00e7esi ve dallar\u0131yla birlikte tam bir yerel kopyas\u0131n\u0131 olu\u015fturmu\u015f olursunuz. Bu yerel kopya \u00fczerinde \u00e7al\u0131\u015fabilir, de\u011fi\u015fiklikler yapabilir ve daha sonra bu de\u011fi\u015fiklikleri uzak depoya geri g\u00f6nderebilirsiniz (push). Bu, da\u011f\u0131t\u0131k versiyon kontrol sistemlerinin temel i\u015fleyi\u015fini ve geli\u015ftiricilerin nas\u0131l ba\u011f\u0131ms\u0131z ama senkronize bir \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6sterir. Depolar aras\u0131ndaki bu etkile\u015fim, projenin geli\u015fim s\u00fcrecinde hem esneklik hem de veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sa\u011flar.<\/p>\n

Son olarak, bir “depolama sunucusu” nedir ve neden \u00f6nemlidir? Bir depolama sunucusu, b\u00fcy\u00fck miktarda veriyi depolamak ve eri\u015filebilir k\u0131lmak \u00fczere optimize edilmi\u015f bir bilgisayar sistemidir. Bu sunucular genellikle RAID dizileri, y\u00fcksek h\u0131zl\u0131 diskler ve g\u00fcvenilir a\u011f ba\u011flant\u0131lar\u0131 gibi donan\u0131mlarla donat\u0131lm\u0131\u015ft\u0131r. Bizim ba\u011flam\u0131m\u0131zda, bir depolama sunucusu, Git depolar\u0131n\u0131n klonlanaca\u011f\u0131 veya yedeklenece\u011fi bir hedef sunucuyu ifade eder. Bu sunucu, ana Git depo hizmetinden (\u00f6rne\u011fin GitHub) fiziksel veya mant\u0131ksal olarak ayr\u0131 olabilir. Amac\u0131, Git depolar\u0131n\u0131n ek bir kopyas\u0131n\u0131 bar\u0131nd\u0131rarak veri g\u00fcvenli\u011fini art\u0131rmak, felaket kurtarma senaryolar\u0131na haz\u0131rl\u0131kl\u0131 olmak veya farkl\u0131 co\u011frafi konumlardaki ekiplere daha yak\u0131n bir eri\u015fim noktas\u0131 sunmakt\u0131r. Depolama sunucular\u0131, sadece dosya depolama de\u011fil, ayn\u0131 zamanda bu verilere g\u00fcvenli ve h\u0131zl\u0131 eri\u015fim sa\u011flamak i\u00e7in SSH, SCP veya \u00e7e\u015fitli a\u011f protokollerini de destekler. \u00d6rne\u011fin, kurumsal bir ortamda, \u015firket i\u00e7i bir depolama sunucusu, hassas kod tabanlar\u0131n\u0131n bulut tabanl\u0131 platformlar yerine kendi veri merkezlerinde tutulmas\u0131n\u0131 sa\u011flayabilir, bu da veri egemenli\u011fi ve g\u00fcvenlik politikalar\u0131 a\u00e7\u0131s\u0131ndan \u00f6nemli bir avantajd\u0131r. Klonlama i\u015flemi, bu depolama sunucusunu, projenizin versiyon kontrol sisteminin kritik bir yedek par\u00e7as\u0131 haline getirir. Bu sayede, olas\u0131 bir kesinti durumunda bile projenizin kod taban\u0131na eri\u015fiminiz garanti alt\u0131na al\u0131nm\u0131\u015f olur.<\/p>\n

Uzman \u0130pucu: Depolama sunucunuzun g\u00fcvenli\u011fini sa\u011flamak i\u00e7in yaln\u0131zca gerekli portlar\u0131 a\u00e7\u0131k b\u0131rak\u0131n ve SSH eri\u015fimi i\u00e7in parola yerine anahtar tabanl\u0131 kimlik do\u011frulama kullan\u0131n. Bu, siber sald\u0131r\u0131lara kar\u015f\u0131 \u00f6nemli bir koruma katman\u0131 sa\u011flar.<\/div>\n

Depolama Sunucusuna Git Deposu Klonlaman\u0131n Faydalar\u0131 Nelerdir?<\/h2>\n

Git depolar\u0131n\u0131 bir depolama sunucusuna klonlamak, sadece teknik bir i\u015flemden \u00f6te, yaz\u0131l\u0131m geli\u015ftirme ekosisteminde bir\u00e7ok stratejik avantaj sunar. Bu avantajlar, projenizin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rmaktan, operasyonel verimlili\u011fi y\u00fckseltmeye kadar geni\u015f bir yelpazeyi kapsar. \u00d6ncelikle, en belirgin faydalardan biri, Yedekleme ve Felaket Kurtarma<\/b> yeteneklerinin g\u00fc\u00e7lendirilmesidir. Ana Git depo sa\u011flay\u0131c\u0131n\u0131z\u0131n (GitHub, GitLab vb.) hizmet d\u0131\u015f\u0131 kalmas\u0131, b\u00f6lgesel bir kesinti ya\u015famas\u0131 veya bir veri kayb\u0131 senaryosu ile kar\u015f\u0131 kar\u015f\u0131ya kalmas\u0131, geli\u015ftirme s\u00fcre\u00e7lerinizin durmas\u0131na ve ciddi i\u015f kay\u0131plar\u0131na yol a\u00e7abilir. Bu t\u00fcr kritik durumlarda, depolama sunucusundaki ba\u011f\u0131ms\u0131z bir klon, projenizin t\u00fcm ge\u00e7mi\u015fiyle birlikte sa\u011flam bir kopyas\u0131n\u0131 sunar. Bu kopya, ana sistem geri gelene kadar geli\u015ftirmenin devam etmesini sa\u011flayabilir veya acil durumlarda h\u0131zl\u0131ca yeni bir ana depo olarak devreye al\u0131nabilir. \u00d6rne\u011fin, bir veri merkezinde ya\u015fanan b\u00fcy\u00fck bir elektrik kesintisi sonucu ana Git sunucusu eri\u015filemez hale geldi\u011finde, depolama sunucusundaki klon sayesinde ekipler \u00e7al\u0131\u015fmalar\u0131na ara vermeden devam edebilir. Bu, i\u015f s\u00fcreklili\u011fi ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fc a\u00e7\u0131s\u0131ndan paha bi\u00e7ilmez bir g\u00fcvence sa\u011flar ve beklenmedik olaylar\u0131n etkisini minimize eder.<\/p>\n

\u0130kinci olarak, klonlama, Da\u011f\u0131t\u0131lm\u0131\u015f Geli\u015ftirme Ortamlar\u0131<\/b> i\u00e7in kritik bir rol oynar. B\u00fcy\u00fck ve co\u011frafi olarak da\u011f\u0131lm\u0131\u015f ekiplerde, merkezi bir Git sunucusuna olan uzakl\u0131k, gecikmelere ve performans sorunlar\u0131na yol a\u00e7abilir. Her geli\u015ftiricinin kendi yerel makinesinde bir Git deposuna sahip olmas\u0131, Git’in da\u011f\u0131t\u0131k yap\u0131s\u0131n\u0131n bir avantaj\u0131 olsa da, uzak sunucularla senkronizasyon hala bir darbo\u011faz olabilir. Bir depolama sunucusuna yap\u0131lan klonlama, \u00f6zellikle farkl\u0131 co\u011frafyalarda bulunan geli\u015ftirme merkezlerine daha yak\u0131n bir eri\u015fim noktas\u0131 sunarak bu sorunu \u00e7\u00f6zer. \u00d6rne\u011fin, A ekibi \u0130stanbul’da, B ekibi ise Berlin’de \u00e7al\u0131\u015f\u0131yorsa, Berlin’deki bir depolama sunucusuna yap\u0131lan klonlama, B ekibinin \u00e7ok daha h\u0131zl\u0131 bir \u015fekilde \u00e7ekme (pull) ve g\u00f6nderme (push) i\u015flemleri yapmas\u0131n\u0131 sa\u011flar. Bu durum, a\u011f gecikmelerini azalt\u0131r, geli\u015ftiricilerin daha verimli \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r ve genel i\u015fbirli\u011fi deneyimini iyile\u015ftirir. Ayr\u0131ca, bu t\u00fcr bir kurulum, farkl\u0131 projeler veya mod\u00fcller i\u00e7in \u00f6zel depolama sunucular\u0131 olu\u015fturarak, her ekibin kendi ihtiya\u00e7lar\u0131na g\u00f6re optimize edilmi\u015f bir Git ortam\u0131na sahip olmas\u0131n\u0131 da sa\u011flayabilir, b\u00f6ylece kaynak izolasyonu da sa\u011flanm\u0131\u015f olur.<\/p>\n

\u00dc\u00e7\u00fcnc\u00fc \u00f6nemli fayda, Performans ve Eri\u015fim H\u0131z\u0131<\/b> art\u0131\u015f\u0131d\u0131r. Merkezi bir Git sunucusuna y\u00f6nelik yo\u011fun eri\u015fim, \u00f6zellikle b\u00fcy\u00fck bir geli\u015ftirici ekibi ve s\u0131k commit i\u015flemleri oldu\u011funda, sunucuda y\u00fck olu\u015fturabilir. Bir depolama sunucusuna yap\u0131lan klonlama, bu y\u00fck\u00fc da\u011f\u0131tmaya yard\u0131mc\u0131 olur. Geli\u015ftiriciler ve otomasyon sistemleri (CI\/CD ara\u00e7lar\u0131 gibi) art\u0131k ana sunucuya de\u011fil, daha yak\u0131n veya daha az yo\u011fun olan depolama sunucusundaki klonlara eri\u015febilir. Bu, hem ana sunucunun performans\u0131n\u0131 korur hem de klonlara eri\u015fen sistemlerin daha h\u0131zl\u0131 yan\u0131t vermesini sa\u011flar. \u00d6zellikle otomatik derleme ve test sistemleri, s\u00fcrekli olarak kod depolar\u0131n\u0131 \u00e7ekme ihtiyac\u0131 duyar. Bu sistemlerin depolama sunucusundaki klonlar\u0131 kullanmas\u0131, CI\/CD boru hatlar\u0131n\u0131n \u00e7ok daha h\u0131zl\u0131 ve kesintisiz \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r. D\u00f6rd\u00fcnc\u00fc olarak, G\u00fcvenlik ve \u0130zolasyon<\/b> sa\u011flamas\u0131 da b\u00fcy\u00fck bir art\u0131d\u0131r. Baz\u0131 kurulu\u015flar, hassas kod tabanlar\u0131n\u0131 bulut tabanl\u0131 Git sa\u011flay\u0131c\u0131lar\u0131nda tutmak yerine kendi \u015firket i\u00e7i altyap\u0131lar\u0131nda tutmay\u0131 tercih edebilir. Depolama sunucusuna yap\u0131lan klonlama, bu t\u00fcr g\u00fcvenlik politikalar\u0131n\u0131 destekler. Klonlanm\u0131\u015f depo, \u015firketin kendi g\u00fcvenlik duvarlar\u0131n\u0131n arkas\u0131nda, kendi eri\u015fim kontrol politikalar\u0131yla korunabilir. Bu, d\u0131\u015f tehditlere kar\u015f\u0131 ek bir koruma katman\u0131 olu\u015ftururken, hassas verilerin \u015firket s\u0131n\u0131rlar\u0131 i\u00e7inde kalmas\u0131n\u0131 sa\u011flar. Ayr\u0131ca, geli\u015ftirme ve \u00fcretim ortamlar\u0131 aras\u0131nda izolasyon sa\u011flamak i\u00e7in de kullan\u0131labilir; \u00f6rne\u011fin, \u00fcretim sunucular\u0131 sadece onaylanm\u0131\u015f ve klonlanm\u0131\u015f bir depodan kod \u00e7ekebilir, bu da potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 azalt\u0131r.<\/p>\n

Uzman \u0130pucu: Klonlanm\u0131\u015f deponuzu d\u00fczenli olarak ana depoyla senkronize etmek i\u00e7in otomatik bir cron g\u00f6revi olu\u015fturun. Bu sayede yedeklemeniz her zaman g\u00fcncel kal\u0131r ve veri kayb\u0131 riski minimize edilir.<\/div>\n

Git Deposunu Depolama Sunucusuna Ad\u0131m Ad\u0131m Nas\u0131l Klonlar\u0131z?<\/h2>\n

Bir Git deposunu depolama sunucusuna klonlama i\u015flemi, geli\u015ftirme i\u015f ak\u0131\u015f\u0131n\u0131z\u0131 g\u00fc\u00e7lendiren ve veri g\u00fcvenli\u011finizi art\u0131ran kritik bir ad\u0131md\u0131r. Bu s\u00fcreci ad\u0131m ad\u0131m inceleyelim ve her bir a\u015famay\u0131 detayland\u0131ral\u0131m. \u00d6ncelikle, \u00d6n Haz\u0131rl\u0131klar<\/b> ile ba\u015flamam\u0131z gerekiyor. Depolama sunucunuzda Git’in y\u00fckl\u00fc oldu\u011fundan emin olmal\u0131s\u0131n\u0131z. \u00c7o\u011fu Linux da\u011f\u0131t\u0131m\u0131nda Git, paket y\u00f6neticisi arac\u0131l\u0131\u011f\u0131yla kolayca kurulabilir. \u00d6rne\u011fin, Debian\/Ubuntu tabanl\u0131 sistemler i\u00e7in a\u015fa\u011f\u0131daki komutu kullanabilirsiniz:<\/p>\n

\n  sudo apt update\n  sudo apt install git\n<\/pre>\n
<\/code><\/p>\n
CentOS\/RHEL tabanl\u0131 sistemlerde ise:<\/p>\n
\n  sudo yum install git\n<\/pre>\n
<\/code><\/p>\n
Windows veya macOS kullan\u0131yorsan\u0131z, Git'in resmi web sitesinden (git-scm.com) indirme ve kurulum talimatlar\u0131n\u0131 takip edebilirsiniz. Ayr\u0131ca, depolama sunucusuna SSH veya HTTPS \u00fczerinden eri\u015fim yetkilerinizin olmas\u0131 gerekmektedir. Genellikle SSH daha g\u00fcvenli ve otomatize edilebilir oldu\u011fu i\u00e7in tercih edilir. SSH ile eri\u015fim i\u00e7in sunucuya SSH anahtar\u0131n\u0131z\u0131 kopyalad\u0131\u011f\u0131n\u0131zdan ve sunucudaki kullan\u0131c\u0131 hesab\u0131n\u0131z\u0131n gerekli izinlere sahip oldu\u011fundan emin olun. Bu, klonlama i\u015flemini sorunsuz bir \u015fekilde ger\u00e7ekle\u015ftirmenizi sa\u011flayacakt\u0131r. Sunucuda klonlamak istedi\u011finiz deponun yer alaca\u011f\u0131 bir dizin olu\u015fturmak da iyi bir uygulamad\u0131r, \u00f6rne\u011fin \/var\/git\/repos<\/code> gibi.<\/p>\n
\u0130kinci ad\u0131m, SSH ile Klonlama<\/b>d\u0131r. Bu y\u00f6ntem, genellikle daha g\u00fcvenli oldu\u011fu ve anahtar tabanl\u0131 kimlik do\u011frulama ile daha kolay otomasyon sa\u011flad\u0131\u011f\u0131 i\u00e7in tercih edilir. Klonlamak istedi\u011finiz uzak deponun SSH URL'sini alman\u0131z gerekmektedir. Bu URL genellikle GitHub, GitLab veya Bitbucket gibi platformlarda \"Clone\" (Klonla) veya \"Code\" (Kod) butonuna t\u0131kland\u0131\u011f\u0131nda g\u00f6r\u00fcn\u00fcr. \u00d6rne\u011fin, bir GitHub deposunun SSH URL'si genellikle git@github.com:kullaniciadi\/repoadi.git<\/code> format\u0131ndad\u0131r. Depolama sunucunuzda, olu\u015fturdu\u011funuz dizine gidin ve a\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131r\u0131n:<\/p>\n
\n  cd \/var\/git\/repos\n  git clone git@github.com:kullaniciadi\/repoadi.git\n<\/pre>\n
<\/code><\/p>\n
Bu komut, deponun tam bir kopyas\u0131n\u0131 (t\u00fcm dallar\u0131 ve commit ge\u00e7mi\u015fi dahil) belirtilen dizine indirir. E\u011fer deponun ad\u0131n\u0131 de\u011fi\u015ftirmek isterseniz, klonlama komutunun sonuna yeni ad\u0131 ekleyebilirsiniz:<\/p>\n
\n  git clone git@github.com:kullaniciadi\/repoadi.git yeni_repo_adi\n<\/pre>\n
<\/code><\/p>\n
SSH anahtar\u0131n\u0131z\u0131n do\u011fru yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131ndan ve sunucuda SSH ajan\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olun. \u0130lk klonlama s\u0131ras\u0131nda SSH parolas\u0131n\u0131 veya anahtar parolas\u0131n\u0131 girmeniz istenebilir. Ba\u015far\u0131l\u0131 bir klonlamadan sonra, belirtilen dizinde deponuzun bir kopyas\u0131n\u0131 bulacaks\u0131n\u0131z. Bu klas\u00f6re girerek Git komutlar\u0131n\u0131 (git log<\/code>, git branch<\/code> vb.) kullanmaya ba\u015flayabilirsiniz. SSH \u00fczerinden klonlama, genellikle tek seferlik bir kurulum gerektirir ancak sonras\u0131nda parola girmeden h\u0131zl\u0131 ve g\u00fcvenli bir \u015fekilde i\u015flem yapman\u0131z\u0131 sa\u011flar.<\/p>\n
\u00dc\u00e7\u00fcnc\u00fc se\u00e7enek, HTTPS ile Klonlama<\/b>d\u0131r. E\u011fer SSH anahtar\u0131 kurulumu size karma\u015f\u0131k geliyorsa veya sunucuda SSH eri\u015fimi s\u0131n\u0131rl\u0131ysa, HTTPS \u00fczerinden klonlama yapabilirsiniz. HTTPS URL'leri genellikle https:\/\/github.com\/kullaniciadi\/repoadi.git<\/code> format\u0131ndad\u0131r. Klonlama komutu SSH'ye benzerdir:<\/p>\n
\n  cd \/var\/git\/repos\n  git clone https:\/\/github.com\/kullaniciadi\/repoadi.git\n<\/pre>\n
<\/code><\/p>\n
HTTPS ile klonlama yaparken, ilk defa klonlad\u0131\u011f\u0131n\u0131zda veya her bir push\/pull i\u015fleminde uzak Git servisine ait kullan\u0131c\u0131 ad\u0131n\u0131z\u0131 ve parolan\u0131z\u0131 (veya ki\u015fisel eri\u015fim belirtecinizi - Personal Access Token) girmeniz istenebilir. Bu, \u00f6zellikle otomasyon senaryolar\u0131nda bir dezavantaj olabilir, \u00e7\u00fcnk\u00fc manuel m\u00fcdahale gerektirir. Ancak, k\u00fc\u00e7\u00fck veya ki\u015fisel projeler i\u00e7in veya h\u0131zl\u0131 bir \u00e7\u00f6z\u00fcm gerekti\u011finde pratik bir y\u00f6ntemdir. Parola yerine token kullanmak daha g\u00fcvenlidir ve bir\u00e7ok Git sa\u011flay\u0131c\u0131s\u0131 taraf\u0131ndan \u00f6nerilir. Klonlama Sonras\u0131 \u0130lk Ad\u0131mlar<\/b> olarak, klonlad\u0131\u011f\u0131n\u0131z deponun do\u011fru \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 kontrol etmelisiniz. Deponun dizinine girerek git log<\/code> veya git status<\/code> gibi komutlar\u0131 \u00e7al\u0131\u015ft\u0131rabilirsiniz. Ayr\u0131ca, deponun orijinal uzak kayna\u011f\u0131n\u0131 kontrol etmek i\u00e7in git remote -v<\/code> komutunu kullanabilirsiniz. Bu, size hem \u00e7ekme (fetch) hem de g\u00f6nderme (push) i\u00e7in yap\u0131land\u0131r\u0131lm\u0131\u015f uzak kaynaklar\u0131 g\u00f6sterecektir. Klonlad\u0131\u011f\u0131n\u0131z depo art\u0131k tam te\u015fekk\u00fcll\u00fc bir Git deposudur ve buradan di\u011fer uzak depolara push\/pull yapabilir veya yeni dallar olu\u015fturabilirsiniz. D\u00fczenli olarak ana depoyla senkronize etmek i\u00e7in git pull<\/code> komutunu kullanman\u0131z gerekti\u011fini unutmay\u0131n. Bu ad\u0131mlar, Git depolar\u0131n\u0131 depolama sunucunuza ba\u015far\u0131l\u0131 bir \u015fekilde klonlaman\u0131za olanak tan\u0131r ve b\u00f6ylece veri g\u00fcvenli\u011finiz ve i\u015f ak\u0131\u015f\u0131n\u0131z i\u00e7in sa\u011flam bir temel olu\u015fturur.<\/p>\n
\n# Depolama sunucusunda bir dizin olu\u015fturma \u00f6rne\u011fi\nmkdir -p \/mnt\/data\/git_backups\ncd \/mnt\/data\/git_backups\n\n# SSH ile bare repository klonlama \u00f6rne\u011fi\ngit clone --bare git@github.com:org\/my-project.git my-project.git\n\n# HTTPS ile normal repository klonlama \u00f6rne\u011fi\ngit clone https:\/\/gitlab.com\/another-org\/another-project.git\n<\/pre>\n
<\/code><\/p>\n
Bare ve Mirror Klonlar: \u0130leri D\u00fczey Kullan\u0131m Senaryolar\u0131 Nelerdir?<\/h2>\n
Git deposunu bir depolama sunucusuna klonlamak, basit bir kopyalama i\u015fleminden \u00e7ok daha fazlas\u0131n\u0131 i\u00e7erebilir. \u00d6zellikle ileri d\u00fczey kullan\u0131m senaryolar\u0131nda, \"bare\" (\u00e7\u0131plak) ve \"mirror\" (ayna) klonlama gibi \u00f6zel teknikler, farkl\u0131 ihtiya\u00e7lara y\u00f6nelik g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler sunar. Bu yakla\u015f\u0131mlar, \u00f6zellikle yedekleme, replikasyon ve CI\/CD s\u00fcre\u00e7lerinde hayati \u00f6nem ta\u015f\u0131r. \u00d6ncelikle, Bare Repository nedir ve Neden kullan\u0131l\u0131r?<\/b> sorusunu ele alal\u0131m. Normal bir Git deposu (non-bare repository), projenin \u00e7al\u0131\u015fma dizinini (yani, kod dosyalar\u0131n\u0131) ve Git'in meta verilerini i\u00e7eren .git<\/code> dizinini i\u00e7erir. Bu t\u00fcr depolar, geli\u015ftiricilerin \u00fczerinde kod yaz\u0131p test etti\u011fi ortamlard\u0131r. Ancak, bir Git deposunu bir sunucuda yaln\u0131zca bir depolama veya uzak kaynak olarak kullanmak istiyorsan\u0131z, \u00e7al\u0131\u015fma dizinine ihtiyac\u0131n\u0131z yoktur. \u0130\u015fte bu noktada bare repository'ler devreye girer. Bare bir depo, sadece .git<\/code> dizininin i\u00e7eri\u011fini do\u011frudan i\u00e7erir; yani, \u00e7al\u0131\u015fma dizini (kod dosyalar\u0131) bulunmaz. \u0130smi de buradan gelir: \"\u00e7\u0131plak\" veya \"ham\" depo. Genellikle sunucularda uzak depo olarak bar\u0131nd\u0131r\u0131lan depolar bare depolard\u0131r, \u00e7\u00fcnk\u00fc geli\u015ftiriciler do\u011frudan bu depoda \u00e7al\u0131\u015fmak yerine, kendi yerel depolar\u0131na klonlay\u0131p de\u011fi\u015fiklikleri geri g\u00f6nderirler.<\/p>\n
Bare repository olu\u015fturmak i\u00e7in git clone --bare<\/code> komutu kullan\u0131l\u0131r. \u00d6rne\u011fin:<\/p>\n
\n  git clone --bare https:\/\/github.com\/ornek\/proje.git proje.git\n<\/pre>\n
<\/code><\/p>\n
Bu komut, proje.git<\/code> ad\u0131nda bir dizin olu\u015fturur ve i\u00e7ine sadece .git<\/code> dizininin i\u00e7eri\u011fini kopyalar. Bare depolar, merkezi bir uzak depo g\u00f6revi g\u00f6rmesi i\u00e7in idealdir. \u00d6rne\u011fin, kendi \u015firket i\u00e7i Git sunucunuzu kurarken, t\u00fcm projeleri bare depolar olarak tutars\u0131n\u0131z. Geli\u015ftiriciler bu bare depolardan klonlar, \u00fczerinde \u00e7al\u0131\u015f\u0131r ve de\u011fi\u015fikliklerini geri g\u00f6nderirler. Bare depolar\u0131n avantaj\u0131, \u00e7ak\u0131\u015fma (merge conflict) riskini ortadan kald\u0131rmas\u0131d\u0131r, \u00e7\u00fcnk\u00fc \u00fczerinde do\u011frudan \u00e7al\u0131\u015f\u0131lan bir \u00e7al\u0131\u015fma dizini yoktur. Ayr\u0131ca, disk alan\u0131ndan tasarruf sa\u011flar ve daha verimli bir yedekleme s\u00fcrecine olanak tan\u0131r. Klonlanm\u0131\u015f bare depo, ana deponun t\u00fcm commit ge\u00e7mi\u015fi ve dallar\u0131yla birlikte, \u00fczerinde herhangi bir aktif geli\u015ftirme yap\u0131lmaks\u0131z\u0131n g\u00fcvenli bir kopyas\u0131d\u0131r.<\/p>\n
Bir di\u011fer g\u00fc\u00e7l\u00fc klonlama y\u00f6ntemi ise Mirror Klonlama nedir ve Senkronizasyon i\u00e7in \u00f6nemi nedir?<\/b> sorusunun cevab\u0131nda yatar. Mirror klonlama, bare klonlaman\u0131n \u00f6zel bir t\u00fcr\u00fcd\u00fcr ve git clone --mirror<\/code> komutu ile ger\u00e7ekle\u015ftirilir. Bu komut, bir deponun sadece bare bir kopyas\u0131n\u0131 olu\u015fturmakla kalmaz, ayn\u0131 zamanda t\u00fcm uzak referanslar\u0131 (remote references) da kopyalar. Yani, orijinal deponun t\u00fcm dallar\u0131, etiketleri, uzak takip dallar\u0131 (remote-tracking branches) ve hatta Git konfig\u00fcrasyonu bile birebir kopyalan\u0131r. Bir ayna klonu, bir deponun tam ve eksiksiz bir yede\u011fini veya bir kopyas\u0131n\u0131 olu\u015fturmak i\u00e7in kullan\u0131l\u0131r. \u00d6zellikle, ana deponun bir kopyas\u0131n\u0131 bir depolama sunucusunda tutmak ve bunu s\u00fcrekli olarak senkronize etmek istedi\u011finizde mirror klonlama \u00e7ok kullan\u0131\u015fl\u0131d\u0131r.<\/p>\n
\n  git clone --mirror git@gitlab.com:kurumsal\/ana-proje.git ana-proje.git\n<\/pre>\n
<\/code><\/p>\n
Mirror klonlama, \u00f6zellikle bir deponun tam bir yedeklemesini almak ve bu yede\u011fi ana depoyla tamamen ayn\u0131 tutmak istedi\u011finizde devreye girer. Vaka Analizi: B\u00fcy\u00fck \u00d6l\u00e7ekli Yedekleme ve Replikasyon<\/b> senaryolar\u0131nda mirror klonlar kritik \u00f6neme sahiptir. B\u00fcy\u00fck bir kurulu\u015f d\u00fc\u015f\u00fcn\u00fcn; hem GitHub hem de \u015firket i\u00e7i GitLab \u00fczerinde y\u00fczlerce depoya sahip. Felaket kurtarma planlar\u0131 kapsam\u0131nda, bu depolar\u0131n tamam\u0131n\u0131n ayr\u0131 bir depolama sunucusunda (\u00f6rne\u011fin bir NAS veya SAN cihaz\u0131na ba\u011fl\u0131 bir Linux sunucusunda) ayna kopyalar\u0131n\u0131 tutmak isteyebilirler. Her gece veya belirli aral\u0131klarla, bir cron g\u00f6revi arac\u0131l\u0131\u011f\u0131yla, t\u00fcm mirror klonlar git remote update --prune<\/code> veya git fetch --all<\/code> komutlar\u0131yla g\u00fcncellenir. Bu sayede, ana depolar\u0131n her an tam ve g\u00fcncel bir kopyas\u0131 depolama sunucusunda bulunur. Orijinal deponun ba\u015f\u0131na bir \u015fey gelirse, bu mirror klonlar h\u0131zla yeni ana depolar olarak devreye al\u0131nabilir ve geli\u015ftirme s\u00fcreci kesintiye u\u011framadan devam eder. Bu, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flarken, ayn\u0131 zamanda \u00e7oklu co\u011frafi b\u00f6lgelerde yedekli sistemler kurma imkan\u0131 sunar, b\u00f6ylece kesinti s\u00fcreleri \u00f6nemli \u00f6l\u00e7\u00fcde azal\u0131r. Mirror klonlar ayr\u0131ca, bir Git sa\u011flay\u0131c\u0131s\u0131ndan di\u011ferine ge\u00e7i\u015f yaparken (\u00f6rne\u011fin GitHub'dan GitLab'a) deponun t\u00fcm tarih\u00e7esi ve referanslar\u0131yla birlikte ta\u015f\u0131nmas\u0131nda da kullan\u0131l\u0131r, bu da ge\u00e7i\u015f s\u00fcrecini sorunsuz hale getirir.<\/p>\n
G\u00fcvenlik ve Otomasyon: Klonlama S\u00fcre\u00e7lerini Nas\u0131l \u0130yile\u015ftirebiliriz?<\/h2>\n
Bir Git deposunu depolama sunucusuna klonlama i\u015flemini yaln\u0131zca ger\u00e7ekle\u015ftirmek yeterli de\u011fildir; bu s\u00fcreci g\u00fcvenli ve otomatik hale getirmek, uzun vadede verimlili\u011fi ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc garanti alt\u0131na al\u0131r. G\u00fcvenlik ve otomasyon, modern yaz\u0131l\u0131m geli\u015ftirme pratiklerinin temel ta\u015flar\u0131d\u0131r ve klonlama s\u00fcre\u00e7lerinde de vazge\u00e7ilmezdir. \u00d6ncelikle, SSH Anahtarlar\u0131 ve Eri\u015fim Kontrol\u00fc<\/b> konusuna odaklanal\u0131m. Git depolar\u0131na SSH \u00fczerinden eri\u015fim, kullan\u0131c\u0131 ad\u0131 ve parola yerine anahtar \u00e7iftleri (public-private key pair) kullanarak kimlik do\u011frulama yapar. Bu y\u00f6ntem, parolalar\u0131n \u00e7al\u0131nmas\u0131 veya tahmin edilmesi riskini ortadan kald\u0131rarak \u00e7ok daha g\u00fcvenli bir eri\u015fim sa\u011flar. Depolama sunucusunda klonlama yapacak kullan\u0131c\u0131n\u0131n (genellikle bir servis hesab\u0131 veya \u00f6zel bir kullan\u0131c\u0131) SSH genel anahtar\u0131n\u0131, klonlanacak ana deponun bar\u0131nd\u0131r\u0131ld\u0131\u011f\u0131 Git servisine (GitHub, GitLab vb.) eklemeniz gerekir. Bu sayede, sunucudan klonlama veya senkronizasyon yaparken herhangi bir parola girmenize gerek kalmaz, bu da otomasyon i\u00e7in zemin haz\u0131rlar. Sunucu taraf\u0131nda ise, bu kullan\u0131c\u0131n\u0131n sadece Git depolar\u0131n\u0131 okuma (pull) veya yazma (push) yetkilerine sahip olmas\u0131 gereken dizinlere eri\u015fimi oldu\u011fundan emin olun. \u00d6rne\u011fin, \/home\/gituser\/.ssh\/authorized_keys<\/code> dosyas\u0131 do\u011fru izinlere sahip olmal\u0131 ve gereksiz SSH anahtarlar\u0131 i\u00e7ermemelidir. Eri\u015fim kontrol\u00fcn\u00fc detayland\u0131rmak i\u00e7in, SSH anahtarlar\u0131n\u0131 belirli komutlarla s\u0131n\u0131rlayabilir veya belirli IP adreslerinden eri\u015fime izin verebilirsiniz, bu da g\u00fcvenlik katman\u0131n\u0131 daha da art\u0131r\u0131r.<\/p>\n
\u0130kinci olarak, Webhooklar ve Otomatik Senkronizasyon (post-receive hooks)<\/b>, klonlama s\u00fcre\u00e7lerini otomatize etmenin en etkili yollar\u0131ndan biridir. Manuel olarak git pull<\/code> komutunu \u00e7al\u0131\u015ft\u0131rmak yerine, uzak depoda bir de\u011fi\u015fiklik (\u00f6rne\u011fin bir push i\u015flemi) oldu\u011funda depolama sunucusundaki klonun otomatik olarak g\u00fcncellenmesini sa\u011flayabiliriz. Bu, \"Git hooks\" ad\u0131 verilen \u00f6zel komut dosyalar\u0131 arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. En yayg\u0131n kullan\u0131lan hook'lardan biri post-receive<\/code> hook'udur. Diyelim ki, ana Git depomuzda (GitHub'da) bir push i\u015flemi ger\u00e7ekle\u015fti\u011finde, depolama sunucusundaki mirror klonumuzun otomatik olarak g\u00fcncellenmesini istiyoruz. Bunun i\u00e7in iki ana yakla\u015f\u0131m vard\u0131r:<\/p>\n
    \n
  1. Git Servisi Webhooklar\u0131:<\/b> GitHub, GitLab gibi platformlar, belirli olaylar (\u00f6rne\u011fin, push, pull request) tetiklendi\u011finde \u00f6nceden tan\u0131mlanm\u0131\u015f bir URL'ye HTTP POST iste\u011fi g\u00f6nderme yetene\u011fi sunar. Depolama sunucunuzda, bu webhook iste\u011fini dinleyecek basit bir web servisi (\u00f6rne\u011fin Python Flask veya Node.js Express ile yaz\u0131lm\u0131\u015f) kurabilirsiniz. Bu servis, webhook iste\u011fini ald\u0131\u011f\u0131nda, klonlanm\u0131\u015f deponun dizinine gider ve git pull --all<\/code> veya git remote update --prune<\/code> gibi komutlar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131r. B\u00f6ylece, ana depodaki her de\u011fi\u015fiklik an\u0131nda depolama sunucusundaki klona yans\u0131r.<\/li>\n
  2. Sunucu Taraf\u0131 Git Hooklar\u0131 (post-receive):<\/b> E\u011fer depolama sunucunuz ayn\u0131 zamanda \"uzak\" bir Git deposu olarak kullan\u0131l\u0131yorsa (yani geli\u015ftiricilerin push yapt\u0131\u011f\u0131 bir bare repo ise), .git\/hooks\/post-receive<\/code> dosyas\u0131n\u0131 d\u00fczenleyerek her push i\u015fleminden sonra belirli komutlar\u0131 \u00e7al\u0131\u015ft\u0131rabilirsiniz. Bu senaryo, genellikle ana Git servisi yerine, kendi kontrol\u00fcn\u00fczdeki bir sunucuda ek i\u015flem yapmak istedi\u011finizde kullan\u0131l\u0131r. Ancak, genellikle ilk y\u00f6ntem (webhook ile harici bir sunucuyu g\u00fcncelleme) daha yayg\u0131nd\u0131r, \u00f6zellikle \u00fc\u00e7\u00fcnc\u00fc taraf Git servisleri kullan\u0131ld\u0131\u011f\u0131nda.<\/li>\n<\/ol>\n
    Vaka Analizi: CI\/CD Entegrasyonu<\/b> \u00f6rne\u011fi, g\u00fcvenlik ve otomasyonun birle\u015fti\u011fi \u00f6nemli bir senaryodur. Bir yaz\u0131l\u0131m \u015firketinin, birden fazla projesi i\u00e7in karma\u015f\u0131k bir CI\/CD boru hatt\u0131 oldu\u011funu d\u00fc\u015f\u00fcnelim. Bu boru hatlar\u0131, her commit sonras\u0131 kodu derler, test eder ve da\u011f\u0131t\u0131ma haz\u0131rlar. Her bir CI\/CD sunucusunun (Jenkins, Travis CI, GitLab CI Runner vb.) do\u011frudan ana Git deposundan kod \u00e7ekmesi, \u00f6zellikle yo\u011fun bir geli\u015ftirme temposunda, ana depo sunucusunda gereksiz bir y\u00fck olu\u015fturabilir ve a\u011f gecikmelerine neden olabilir. Bu durumu a\u015fmak i\u00e7in, depolama sunucusundaki klonlanm\u0131\u015f depolar kullan\u0131labilir. CI\/CD sunucular\u0131, ana Git deposu yerine, daha h\u0131zl\u0131 ve yerel a\u011fdaki depolama sunucusundaki mirror klonlardan kodu \u00e7ekecek \u015fekilde yap\u0131land\u0131r\u0131l\u0131r. Bu klonlar, yukar\u0131da bahsedilen webhook mekanizmas\u0131yla ana depodan otomatik olarak g\u00fcncel tutulur. Bu kurulumun faydalar\u0131 \u015funlard\u0131r:<\/p>\n
      \n
    • Performans Art\u0131\u015f\u0131:<\/b> CI\/CD s\u00fcre\u00e7leri, kodu daha h\u0131zl\u0131 \u00e7ekerek daha \u00e7abuk ba\u015flar ve tamamlan\u0131r.<\/li>\n
    • Y\u00fck Da\u011f\u0131t\u0131m\u0131:<\/b> Ana Git sunucusundaki y\u00fck azal\u0131r, bu da ana geli\u015ftirme i\u015f ak\u0131\u015f\u0131n\u0131n daha ak\u0131c\u0131 olmas\u0131n\u0131 sa\u011flar.<\/li>\n
    • G\u00fcvenlik:<\/b> CI\/CD sunucular\u0131, ana depo yerine sadece depolama sunucusundaki belirli bir klona eri\u015fim iznine sahip olabilir, bu da yetki matrisini basitle\u015ftirir ve g\u00fcvenlik risklerini azalt\u0131r.<\/li>\n
    • \u0130zolasyon:<\/b> E\u011fer ana Git deposu bir nedenle eri\u015filemez hale gelirse, depolama sunucusundaki klonlar \u00fczerinden CI\/CD s\u00fcre\u00e7leri \u00e7al\u0131\u015fmaya devam edebilir, b\u00f6ylece \u00fcretim hatt\u0131 kesintisiz kal\u0131r.<\/li>\n<\/ul>\n
      Bu stratejiler, Git depolar\u0131n\u0131 sadece klonlamakla kalmay\u0131p, ayn\u0131 zamanda onlar\u0131 sa\u011flam, g\u00fcvenli ve verimli bir altyap\u0131n\u0131n ayr\u0131lmaz bir par\u00e7as\u0131 haline getirir.<\/p>\n
      Mobil Uyumlu Y\u00f6netim Aray\u00fczleri Olu\u015fturma: HTML ve CSS \u0130pu\u00e7lar\u0131<\/h2>\n
      Git depolar\u0131n\u0131n bir depolama sunucusunda y\u00f6netilmesi genellikle komut sat\u0131r\u0131 \u00fczerinden yap\u0131l\u0131r, ancak \u00f6zellikle birden fazla depo klonlanm\u0131\u015fsa veya teknik olmayan bir ekibin bu depolar\u0131n durumunu h\u0131zl\u0131ca kontrol etmesi gerekiyorsa, basit bir web tabanl\u0131 y\u00f6netim aray\u00fcz\u00fc olduk\u00e7a faydal\u0131 olabilir. Bu t\u00fcr bir aray\u00fcz\u00fc tasarlarken, g\u00fcn\u00fcm\u00fcz\u00fcn \u00e7ok \u00e7e\u015fitli cihaz ortam\u0131nda mobil uyumluluk (responsive design) olmazsa olmazd\u0131r. Responsive Tasar\u0131m\u0131n \u00d6nemi<\/b>, kullan\u0131c\u0131lar\u0131n masa\u00fcst\u00fc bilgisayarlardan tablet ve ak\u0131ll\u0131 telefonlara kadar farkl\u0131 ekran boyutlar\u0131na sahip cihazlarda sorunsuz bir deneyim ya\u015famas\u0131n\u0131 sa\u011flamakt\u0131r. Bir y\u00f6netim aray\u00fcz\u00fc, bu ba\u011flamda, depolama sunucusundaki klonlanm\u0131\u015f depolar\u0131n listesini, son senkronizasyon zamanlar\u0131n\u0131, disk kullan\u0131m\u0131n\u0131 veya hata mesajlar\u0131n\u0131 g\u00f6sterebilir. Mobil uyumlu bir tasar\u0131m olmadan, k\u00fc\u00e7\u00fck ekranlarda metinler okunaks\u0131z hale gelebilir, butonlar eri\u015filemez olabilir ve genel kullan\u0131c\u0131 deneyimi olumsuz etkilenebilir. Bu da, geli\u015ftirme veya operasyon ekiplerinin h\u0131zl\u0131 bilgiye eri\u015fimini zorla\u015ft\u0131r\u0131r. Dolay\u0131s\u0131yla, HTML ve CSS kullanarak olu\u015fturaca\u011f\u0131m\u0131z basit aray\u00fcz\u00fcn, t\u00fcm cihazlarda d\u00fczg\u00fcn g\u00f6r\u00fcnmesi i\u00e7in modern responsive tasar\u0131m tekniklerini uygulamam\u0131z gerekmektedir.<\/p>\n
      Mobil uyumlulu\u011fun temelini, HTML'de viewport meta etiketi ve CSS'te medya sorgular\u0131 (media queries) olu\u015fturur. \u0130lk olarak, HTML dosyan\u0131z\u0131n <\/code> b\u00f6l\u00fcm\u00fcne a\u015fa\u011f\u0131daki meta etiketini ekleyerek taray\u0131c\u0131n\u0131n sayfan\u0131n geni\u015fli\u011fini cihaz\u0131n geni\u015fli\u011fine g\u00f6re \u00f6l\u00e7eklendirmesini sa\u011flamal\u0131s\u0131n\u0131z:<\/p>\n
      \n  \n<\/pre>\n
      <\/code><\/p>\n
      Bu etiket, sayfan\u0131n varsay\u0131lan olarak mobil cihazlarda do\u011fru \u00f6l\u00e7ekte g\u00f6sterilmesini sa\u011flar. Daha sonra, \u00d6rnek CSS Media Query Kullan\u0131m\u0131<\/b> ile farkl\u0131 ekran boyutlar\u0131 i\u00e7in farkl\u0131 stil kurallar\u0131 tan\u0131mlayabiliriz. Medya sorgular\u0131, belirli ko\u015fullar (\u00f6rne\u011fin, ekran geni\u015fli\u011fi) kar\u015f\u0131land\u0131\u011f\u0131nda CSS kurallar\u0131n\u0131n uygulanmas\u0131na olanak tan\u0131r. Bir depolama sunucusu y\u00f6netim panelinde, depolar\u0131n listelendi\u011fi bir tablo d\u00fc\u015f\u00fcnelim. Masa\u00fcst\u00fcnde her s\u00fctun g\u00f6r\u00fcn\u00fcrken, mobil cihazlarda sadece en \u00f6nemli bilgilerin g\u00f6r\u00fcnmesini isteyebiliriz. \u0130\u015fte basit bir \u00f6rnek:<\/p>\n
      \n