Yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7leri, \u00f6zellikle ekip halinde \u00e7al\u0131\u015f\u0131rken karma\u015f\u0131k hale gelebilir. \u00c7e\u015fitli \u00f6zelliklerin ayn\u0131 anda geli\u015ftirilmesi, hatalar\u0131n giderilmesi ve t\u00fcm bu de\u011fi\u015fikliklerin ana kod taban\u0131na sorunsuz bir \u015fekilde entegre edilmesi, modern s\u00fcr\u00fcm kontrol sistemleri olmadan neredeyse imkans\u0131zd\u0131r. Bu makale, Git’in sundu\u011fu en g\u00fc\u00e7l\u00fc \u00f6zelliklerden biri olan dallanma (branching) ve birle\u015ftirme (merging) kavramlar\u0131n\u0131 OSD600Lab3 ba\u011flam\u0131nda detayl\u0131ca inceleyecek ve geli\u015ftirme ak\u0131\u015f\u0131n\u0131z\u0131 nas\u0131l optimize edebilece\u011finizi g\u00f6sterecektir.<\/p>\n

Git’in dallanma \u00f6zelli\u011fi, geli\u015ftiricilere ana kod taban\u0131ndan (genellikle

main<\/code> veya master<\/code> olarak adland\u0131r\u0131l\u0131r) ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fma alanlar\u0131 olu\u015fturma imkan\u0131 sunar. T\u0131pk\u0131 bir a\u011fac\u0131n ana g\u00f6vdesinden \u00e7\u0131kan farkl\u0131 dallar gibi, projenizin ana ge\u00e7mi\u015finden ayr\u0131lan yeni bir geli\u015ftirme hatt\u0131 d\u00fc\u015f\u00fcnebilirsiniz. Peki, bu \u00f6zellik neden bu kadar kritik?<\/p>\n

\u00d6ncelikle, izolasyon sa\u011flar. Yeni bir \u00f6zellik \u00fczerinde \u00e7al\u0131\u015f\u0131rken veya bir hatay\u0131 d\u00fczeltirken, yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fiklikler ana projeyi (main<\/code> dal\u0131) do\u011frudan etkilemez. Bu, ana dal\u0131n her zaman kararl\u0131 ve \u00fcretime haz\u0131r kalmas\u0131n\u0131 garanti eder. Diyelim ki, bir e-ticaret uygulamas\u0131nda yeni bir \u00f6deme sistemi entegrasyonu \u00fczerinde \u00e7al\u0131\u015f\u0131yorsunuz. Bu s\u00fcre\u00e7, haftalar s\u00fcrebilir ve bir\u00e7ok ara de\u011fi\u015fikli\u011fi i\u00e7erebilir. E\u011fer t\u00fcm bu de\u011fi\u015fiklikleri do\u011frudan main<\/code> dal\u0131nda yapsayd\u0131n\u0131z, bu dal s\u00fcrekli olarak karars\u0131z bir durumda olurdu. Ancak bir feature\/yeni-odeme-sistemi<\/code> dal\u0131 olu\u015fturarak, t\u00fcm denemelerinizi, geli\u015ftirmelerinizi ve hatalar\u0131n\u0131z\u0131 bu dalda izole edebilir, main<\/code> dal\u0131n\u0131 etkilemeden ilerleyebilirsiniz. Bu, paralel geli\u015ftirmenin temelidir; birden fazla ekip \u00fcyesi ayn\u0131 anda, birbirlerinin i\u015flerini engellemeden farkl\u0131 g\u00f6revler \u00fczerinde \u00e7al\u0131\u015fabilir.<\/p>\n

Ayr\u0131ca, dallar farkl\u0131 geli\u015ftirme a\u015famalar\u0131n\u0131 y\u00f6netmek i\u00e7in de kullan\u0131l\u0131r. \u00d6rne\u011fin, development<\/code> dal\u0131 t\u00fcm yeni \u00f6zelliklerin birle\u015fti\u011fi yer olabilirken, staging<\/code> dal\u0131 test i\u00e7in haz\u0131rlanan versiyonu temsil edebilir ve main<\/code> dal\u0131 ise canl\u0131daki (production) kararl\u0131 s\u00fcr\u00fcm\u00fc bar\u0131nd\u0131r\u0131r. Bu yap\u0131, riskleri minimize eder ve daha kontroll\u00fc bir yay\u0131n d\u00f6ng\u00fcs\u00fc sa\u011flar. Bir hata d\u00fczeltmesi gerekti\u011finde, sadece o hata i\u00e7in k\u00fc\u00e7\u00fck bir dal olu\u015fturup, h\u0131zl\u0131ca d\u00fczeltmeyi yap\u0131p ana dala geri birle\u015ftirebilirsiniz. Bu esneklik, modern yaz\u0131l\u0131m geli\u015ftirme metodolojilerinin (\u00f6rne\u011fin Agile) vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r. \u00d6rne\u011fin, acil bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 tespit edildi\u011finde, canl\u0131daki main<\/code> daldan bir hotfix\/guvenlik-acigi<\/code> dal\u0131 olu\u015fturulur, d\u00fczeltme yap\u0131l\u0131r, h\u0131zl\u0131ca test edilir ve tekrar main<\/code> dal\u0131na birle\u015ftirilir. Bu sayede, uygulaman\u0131n kritik i\u015flevselli\u011fi kesintiye u\u011framadan sorun giderilmi\u015f olur. Dolay\u0131s\u0131yla, Git dallanmas\u0131, sadece kod d\u00fczenlemekten \u00f6te, t\u00fcm geli\u015ftirme s\u00fcrecini daha d\u00fczenli, verimli ve risksiz hale getiren stratejik bir ara\u00e7t\u0131r.<\/p>\n

\n        Uzman \u0130pucu: K\u00fc\u00e7\u00fck ve odakl\u0131 dallar olu\u015fturmak, hem kod inceleme s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131r hem de birle\u015ftirme \u00e7ak\u0131\u015fmalar\u0131n\u0131n (merge conflicts) olu\u015fma ihtimalini azalt\u0131r. Bir dalda yaln\u0131zca tek bir \u00f6zellik veya hata d\u00fczeltmesi \u00fczerinde \u00e7al\u0131\u015fmaya \u00f6zen g\u00f6sterin.\n    <\/div>\nBir Git Dal\u0131 Nas\u0131l Olu\u015fturulur ve Y\u00f6netilir? Ad\u0131m Ad\u0131m Rehber<\/h2>\nGit dallar\u0131n\u0131 kullanmaya ba\u015flamak olduk\u00e7a basittir, ancak etkili y\u00f6netim pratikleri benimsemek uzun vadede size b\u00fcy\u00fck faydalar sa\u011flayacakt\u0131r. \u0130\u015fte ad\u0131m ad\u0131m bir dal olu\u015fturma, \u00fczerinde \u00e7al\u0131\u015fma ve y\u00f6netme s\u00fcreci:<\/p>\n
1. Mevcut Dallar\u0131 G\u00f6r\u00fcnt\u00fcleme<\/h3>\n\u00c7al\u0131\u015fmaya ba\u015flamadan \u00f6nce mevcut dallar\u0131 g\u00f6rmek iyi bir ad\u0131md\u0131r. Bu komut, yerel deponuzdaki t\u00fcm dallar\u0131 listeler ve \u00fczerinde bulundu\u011funuz dal\u0131 y\u0131ld\u0131z i\u015faretiyle belirtir:<\/p>\n
\ngit branch\n<\/pre>\n<\/code><\/p>\n
Benzer \u015fekilde, uzaktaki (remote) dallar\u0131 g\u00f6rmek i\u00e7in -r<\/code>, hem yerel hem de uzak dallar\u0131 g\u00f6rmek i\u00e7in -a<\/code> parametresini kullanabilirsiniz.<\/p>\n
\ngit branch -a\n<\/pre>\n<\/code><\/p>\n
2. Yeni Bir Dal Olu\u015fturma<\/h3>\nYeni bir \u00f6zellik \u00fczerinde \u00e7al\u0131\u015fmak i\u00e7in genellikle main<\/code> dal\u0131ndan yeni bir dal olu\u015ftururuz. Diyelim ki, \"kullan\u0131c\u0131 profili\" \u00f6zelli\u011fi \u00fczerinde \u00e7al\u0131\u015facaks\u0131n\u0131z:<\/p>\n
\ngit branch feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
Bu komut, bulundu\u011funuz dal\u0131n mevcut durumundan yeni bir dal olu\u015fturur. Ancak bu dal\u0131 olu\u015fturduktan sonra hala eski dal\u0131n\u0131zda (\u00f6rne\u011fin main<\/code>) olacaks\u0131n\u0131z.<\/p>\n
3. Yeni Dala Ge\u00e7i\u015f Yapma<\/h3>\nOlu\u015fturdu\u011funuz yeni dalda \u00e7al\u0131\u015fmaya ba\u015flamak i\u00e7in o dala ge\u00e7i\u015f yapman\u0131z gerekir. Bunu git checkout<\/code> veya daha modern olan git switch<\/code> komutuyla yapabilirsiniz:<\/p>\n
\ngit checkout feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
veya<\/p>\n
\ngit switch feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
Hem dal\u0131 olu\u015fturup hem de ona ge\u00e7i\u015f yapmak i\u00e7in k\u0131sa yolu da kullanabilirsiniz:<\/p>\n
\ngit checkout -b feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
veya<\/p>\n
\ngit switch -c feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
Art\u0131k feature\/kullanici-profili<\/code> dal\u0131ndas\u0131n\u0131z ve burada yapt\u0131\u011f\u0131n\u0131z t\u00fcm de\u011fi\u015fiklikler bu dala \u00f6zg\u00fc olacakt\u0131r. Bu dalda geli\u015ftirmelerinizi yaparken, main<\/code> dal\u0131n\u0131z tamamen g\u00fcvende ve izole kal\u0131r.<\/p>\n
4. De\u011fi\u015fiklikleri Kaydetme (Commit)<\/h3>\nDal\u0131n\u0131zda kod de\u011fi\u015fiklikleri yapt\u0131ktan sonra, bunlar\u0131 d\u00fczenli olarak kaydetmeniz (commit) \u00f6nemlidir:<\/p>\n
\ngit add .\ngit commit -m \"Kullan\u0131c\u0131 profili aray\u00fcz\u00fc eklendi\"\n<\/pre>\n<\/code><\/p>\n
Unutmay\u0131n, bu commit'ler sadece bulundu\u011funuz feature\/kullanici-profili<\/code> dal\u0131na kaydedilir.<\/p>\n
5. Uzak Depoya G\u00f6nderme (Push)<\/h3>\n\u00c7al\u0131\u015fmalar\u0131n\u0131z\u0131 di\u011fer ekip \u00fcyeleriyle payla\u015fmak veya yedeklemek i\u00e7in dal\u0131n\u0131z\u0131 uzak depoya g\u00f6ndermeniz gerekir:<\/p>\n
\ngit push -u origin feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
-u<\/code> (veya --set-upstream<\/code>) parametresi, yerel dal\u0131n\u0131z\u0131 uzak depodaki ayn\u0131 isimli dal ile ili\u015fkilendirir, b\u00f6ylece sonraki git push<\/code> komutlar\u0131n\u0131 daha k\u0131sa yazabilirsiniz.<\/p>\n
6. Dallar\u0131 Silme<\/h3>\n\u00d6zellik tamamlan\u0131p main<\/code> dala ba\u015far\u0131yla birle\u015ftirildikten sonra, art\u0131k o dala ihtiyac\u0131n\u0131z kalmaz ve onu silebilirsiniz. Bu, deponuzun d\u00fczenli kalmas\u0131n\u0131 sa\u011flar:<\/p>\n
\ngit branch -d feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
E\u011fer dal\u0131n\u0131zda birle\u015ftirilmemi\u015f de\u011fi\u015fiklikler varsa ve yine de silmek istiyorsan\u0131z -D<\/code> (b\u00fcy\u00fck harf D) kullanabilirsiniz, ancak bunu dikkatli yapmal\u0131s\u0131n\u0131z, \u00e7\u00fcnk\u00fc bu i\u015flem kaybolan de\u011fi\u015fikliklere yol a\u00e7abilir.<\/p>\n
\ngit branch -D tehlikeli-dal\n<\/pre>\n<\/code><\/p>\n
Uzak depodaki dal\u0131 silmek i\u00e7in ise:<\/p>\n
\ngit push origin --delete feature\/kullanici-profili\n<\/pre>\n<\/code><\/p>\n
Bu ad\u0131mlar, Git dallar\u0131n\u0131 etkin bir \u015fekilde olu\u015fturman\u0131za, \u00fczerinde \u00e7al\u0131\u015fman\u0131za ve y\u00f6netmenize yard\u0131mc\u0131 olacakt\u0131r. Dallanma, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde d\u00fczeni ve i\u015fbirli\u011fini sa\u011flayan temel bir mekanizmad\u0131r.<\/p>\n
Dallar\u0131 Birle\u015ftirme (Merging) Kavram\u0131 ve \u00c7ak\u0131\u015fma Y\u00f6netimi Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\nBir dalda yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fiklikleri tamamlad\u0131ktan ve bunlar\u0131n ana kod taban\u0131na dahil edilmeye haz\u0131r oldu\u011funa karar verdikten sonra, bu de\u011fi\u015fiklikleri birle\u015ftirme (merging) i\u015flemi devreye girer. Birle\u015ftirme, bir dal\u0131n ge\u00e7mi\u015fini ve i\u00e7eri\u011fini ba\u015fka bir dala entegre etmek anlam\u0131na gelir. Git, bu birle\u015ftirme i\u015flemini olduk\u00e7a ak\u0131ll\u0131ca y\u00f6netir, ancak bazen insan m\u00fcdahalesi gerektiren durumlar da ortaya \u00e7\u0131kar: \u00e7ak\u0131\u015fmalar (conflicts).<\/p>\n
Genel olarak iki ana birle\u015ftirme t\u00fcr\u00fc vard\u0131r:<\/p>\n
\n\n            Fast-Forward Birle\u015ftirme:<\/strong> E\u011fer hedef dalda (\u00f6rne\u011fin main<\/code>) sizin dal\u0131n\u0131z olu\u015fturulduktan sonra hi\u00e7bir yeni commit yap\u0131lmam\u0131\u015fsa, Git h\u0131zl\u0131 ilerleme birle\u015ftirmesi yapar. Bu durumda, hedef dal\u0131n i\u015faret\u00e7isi basit\u00e7e sizin dal\u0131n\u0131z\u0131n son commit'ine do\u011fru ilerletilir. Ge\u00e7mi\u015f do\u011frusal kal\u0131r ve yeni bir birle\u015ftirme commit'i olu\u015fmaz. \u00d6rne\u011fin, main<\/code> dal\u0131ndan feature\/login<\/code> dal\u0131 olu\u015fturuldu ve siz bu dalda de\u011fi\u015fiklikler yapt\u0131n\u0131z. Bu s\u00fcre\u00e7te main<\/code> dal\u0131nda ba\u015fka hi\u00e7bir de\u011fi\u015fiklik olmad\u0131. Bu durumda main<\/code> dal\u0131na geri d\u00f6n\u00fcp git merge feature\/login<\/code> komutunu verdi\u011finizde, main<\/code> dal\u0131 i\u015faret\u00e7isi feature\/login<\/code> dal\u0131n\u0131n son commit'ine ilerletilir.\n        <\/li>\n
\n            Three-Way Birle\u015ftirme (\u00dc\u00e7 Y\u00f6nl\u00fc Birle\u015ftirme):<\/strong> E\u011fer hedef dalda, sizin dal\u0131n\u0131z olu\u015fturulduktan sonra yeni commit'ler yap\u0131lm\u0131\u015fsa, Git birle\u015ftirme commit'i olu\u015fturarak \u00fc\u00e7 y\u00f6nl\u00fc birle\u015ftirme yapar. Bu, her iki dal\u0131n ortak atas\u0131 (common ancestor) ile mevcut durumlar\u0131 aras\u0131ndaki farklar\u0131 tespit eder ve bu de\u011fi\u015fiklikleri birle\u015ftirir. Bu durumda, ge\u00e7mi\u015f do\u011frusal olmaz ve yeni bir \"merge commit\" olu\u015fur. Bu commit, birle\u015ftirilen iki dal\u0131n t\u00fcm ge\u00e7mi\u015fini ve de\u011fi\u015fikliklerini i\u00e7erir. Bu, daha karma\u015f\u0131k ama yayg\u0131n bir senaryodur ve genellikle birle\u015ftirme \u00e7ak\u0131\u015fmalar\u0131n\u0131n ortaya \u00e7\u0131kt\u0131\u011f\u0131 yerdir.\n        <\/li>\n<\/ul>\nBirle\u015ftirme i\u015flemini ger\u00e7ekle\u015ftirmek i\u00e7in \u00f6nce hedef dala ge\u00e7meniz gerekir:<\/p>\n
\ngit switch main\ngit pull origin main # Ana dal\u0131 g\u00fcncel tutmak \u00f6nemlidir\ngit merge feature\/yeni-odeme-sistemi\n<\/pre>\n<\/code><\/p>\n
E\u011fer birle\u015ftirme sorunsuz tamamlan\u0131rsa, Git size ba\u015far\u0131l\u0131 bir birle\u015ftirme mesaj\u0131 g\u00f6sterecektir. Ancak, e\u011fer her iki dalda da ayn\u0131 dosyan\u0131n ayn\u0131 sat\u0131rlar\u0131nda veya birbirine \u00e7ok yak\u0131n kod bloklar\u0131nda farkl\u0131 de\u011fi\u015fiklikler yap\u0131ld\u0131ysa, Git otomatik olarak nas\u0131l birle\u015ftirece\u011fine karar veremez. \u0130\u015fte bu noktada bir birle\u015ftirme \u00e7ak\u0131\u015fmas\u0131 (merge conflict)<\/strong> ortaya \u00e7\u0131kar. \u00d6rne\u011fin, bir ekip \u00fcyesi README.md<\/code> dosyas\u0131n\u0131n ba\u015fl\u0131\u011f\u0131n\u0131 de\u011fi\u015ftirirken, siz de ayn\u0131 dosyan\u0131n ilk paragraf\u0131n\u0131 d\u00fczenlerseniz, Git genellikle bu t\u00fcr \u00e7ak\u0131\u015fmalar\u0131 kolayca \u00e7\u00f6zer. Ancak e\u011fer ikiniz de README.md<\/code> dosyas\u0131n\u0131n *ayn\u0131 sat\u0131r\u0131n\u0131* farkl\u0131 \u015fekillerde de\u011fi\u015ftirdiyseniz, i\u015fte o zaman bir \u00e7ak\u0131\u015fma ya\u015fan\u0131r.<\/p>\n
Bir \u00e7ak\u0131\u015fma meydana geldi\u011finde, Git birle\u015ftirme i\u015flemini durdurur ve size hangi dosyalar\u0131n \u00e7ak\u0131\u015ft\u0131\u011f\u0131n\u0131 bildirir. Bu dosyalar\u0131 manuel olarak d\u00fczenlemeniz ve \u00e7ak\u0131\u015fmalar\u0131 \u00e7\u00f6zmeniz gerekir. Bu durum genellikle korkutucu g\u00f6r\u00fcnse de, Git'in sa\u011flad\u0131\u011f\u0131 ara\u00e7larla ve biraz pratikle kolayca y\u00f6netilebilir bir s\u00fcre\u00e7tir. \u00c7ak\u0131\u015fmalar, Git'in geli\u015ftiricilere kontrol\u00fc tam olarak verdi\u011fi anlard\u0131r, b\u00f6ylece hangi de\u011fi\u015fikliklerin kalaca\u011f\u0131na siz karar verirsiniz. Bu, kod taban\u0131n\u0131z\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve do\u011frulu\u011funu koruman\u0131n kritik bir par\u00e7as\u0131d\u0131r.<\/p>\n
Birle\u015ftirme \u00c7ak\u0131\u015fmalar\u0131yla Ba\u015fa \u00c7\u0131kmak: Uygulamal\u0131 \u00c7\u00f6z\u00fcmler Nelerdir?<\/h2>\nGit birle\u015ftirme \u00e7ak\u0131\u015fmalar\u0131 (merge conflicts), ekip \u00e7al\u0131\u015fmas\u0131n\u0131n ve paralel geli\u015ftirmenin do\u011fal bir par\u00e7as\u0131d\u0131r. Korkulacak bir durum de\u011fil, aksine Git'in size \"Burada iki farkl\u0131 de\u011fi\u015fiklik var, hangisinin kalaca\u011f\u0131na veya nas\u0131l birle\u015fece\u011fine sen karar ver\" dedi\u011fi bir an olarak g\u00f6r\u00fclmelidir. Bir \u00e7ak\u0131\u015fma meydana geldi\u011finde, Git birle\u015ftirme i\u015flemini durdurur ve size hangi dosyalarda \u00e7ak\u0131\u015fma oldu\u011funu bildirir. Bu dosyalar\u0131 git status<\/code> komutuyla g\u00f6rebilirsiniz:<\/p>\n
\ngit status\n<\/pre>\n<\/code><\/p>\n
Bu komut, \"Unmerged paths\" (Birle\u015ftirilmemi\u015f yollar) alt\u0131nda \u00e7ak\u0131\u015fan dosyalar\u0131 listeler. \u00c7ak\u0131\u015fan dosyalar\u0131 bir metin d\u00fczenleyiciyle a\u00e7t\u0131\u011f\u0131n\u0131zda, Git'in ekledi\u011fi \u00f6zel i\u015faret\u00e7ileri g\u00f6receksiniz. Bu i\u015faret\u00e7iler, \u00e7ak\u0131\u015fman\u0131n nerede oldu\u011funu ve hangi kodun hangi daldan geldi\u011fini g\u00f6sterir:<\/p>\n
\n<<<<<<< HEAD\nBu k\u0131s\u0131m sizin mevcut dal\u0131n\u0131zdan (genellikle \u00fczerine birle\u015ftirdi\u011finiz dal) geliyor.\n=======\nBu k\u0131s\u0131m birle\u015ftirmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z daldan geliyor.\n>>>>>>> feature\/yeni-ozellik\n<\/pre>\n<\/code><\/p>\n
\n<<<<<<< HEAD<\/code>: Bu i\u015faret\u00e7inin alt\u0131ndaki kod, \u015fu anda \u00fczerinde bulundu\u011funuz daldaki (yani birle\u015ftirmeyi yapt\u0131\u011f\u0131n\u0131z dal, genellikle main<\/code>) versiyonudur.<\/li>\n
=======<\/code>: Bu \u00e7izgi, iki farkl\u0131 versiyon aras\u0131ndaki ay\u0131r\u0131c\u0131d\u0131r.<\/li>\n
>>>>>>> feature\/yeni-ozellik<\/code>: Bu i\u015faret\u00e7inin alt\u0131ndaki kod ise, birle\u015ftirmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z feature\/yeni-ozellik<\/code> dal\u0131ndan gelen versiyondur.<\/li>\n<\/ul>\n\u00c7ak\u0131\u015fmay\u0131 \u00e7\u00f6zmek i\u00e7in yapman\u0131z gereken, bu i\u015faret\u00e7ileri ve istemedi\u011finiz kod par\u00e7alar\u0131n\u0131 silerek dosyan\u0131n nihai halini olu\u015fturmakt\u0131r. \u00dc\u00e7 farkl\u0131 yol izleyebilirsiniz:<\/p>\n
\nSizin De\u011fi\u015fikli\u011finizi Koruma:<\/strong> Sadece <<<<<<< HEAD<\/code> ve =======<\/code> aras\u0131ndaki kodu koruyup di\u011ferlerini silmek.<\/li>\n
Birle\u015ftirdi\u011finiz Dal\u0131n De\u011fi\u015fikli\u011fini Koruma:<\/strong> Sadece =======<\/code> ve >>>>>>> feature\/yeni-ozellik<\/code> aras\u0131ndaki kodu koruyup di\u011ferlerini silmek.<\/li>\n
Her \u0130ki De\u011fi\u015fikli\u011fi Birle\u015ftirme:<\/strong> Her iki kodu da al\u0131p, mant\u0131ksal bir s\u0131ra i\u00e7inde birle\u015ftirmek ve ortaya \u00e7\u0131kan kodu korumak. Bu genellikle en s\u0131k ba\u015fvurulan y\u00f6ntemdir.<\/li>\n<\/ol>\nManuel olarak \u00e7\u00f6z\u00fclm\u00fc\u015f bir \u00f6rnek:<\/p>\n
Orijinal \u00e7ak\u0131\u015fan kod:<\/p>\n
\n<<<<<<< HEAD\nfunction helloWorld() {\n    console.log(\"Merhaba, D\u00fcnya!\");\n}\n=======\nfunction greeting() {\n    console.log(\"Hello there!\");\n}\n>>>>>>> feature\/greeting\n<\/pre>\n<\/code><\/p>\n
\u00c7ak\u0131\u015fmay\u0131 \u00e7\u00f6zd\u00fckten sonra (\u00f6rne\u011fin her ikisini de koruyarak):<\/p>\n
\nfunction helloWorld() {\n    console.log(\"Merhaba, D\u00fcnya!\");\n}\n\nfunction greeting() {\n    console.log(\"Hello there!\");\n}\n<\/pre>\n<\/code><\/p>\n
T\u00fcm \u00e7ak\u0131\u015fmalar\u0131 \u00e7\u00f6zd\u00fc\u011f\u00fcn\u00fczde ve dosyalar\u0131 istedi\u011finiz duruma getirdi\u011finizde, Git'e bu dosyalar\u0131 \u00e7\u00f6zd\u00fc\u011f\u00fcn\u00fcz\u00fc bildirmeniz gerekir. Bu, normal bir commit i\u015flemi gibi git add<\/code> ile yap\u0131l\u0131r:<\/p>\n
\ngit add <\u00e7ak\u0131\u015fan-dosya-ad\u0131>\n<\/pre>\n<\/code><\/p>\n
T\u00fcm \u00e7ak\u0131\u015fan dosyalar\u0131 git add<\/code> ile ekledikten sonra, birle\u015ftirme i\u015flemini tamamlayan bir commit yapman\u0131z gerekir:<\/p>\n
\ngit commit -m \"feature\/yeni-ozellik dal\u0131 main dal\u0131na birle\u015ftirildi, \u00e7ak\u0131\u015fmalar \u00e7\u00f6z\u00fcld\u00fc.\"\n<\/pre>\n<\/code><\/p>\n
Git, bu commit mesaj\u0131n\u0131 genellikle otomatik olarak sizin i\u00e7in doldurur, ancak a\u00e7\u0131klay\u0131c\u0131 bir mesajla d\u00fczenlemek her zaman iyi bir pratiktir. Bu commit, birle\u015ftirme i\u015fleminin tamamland\u0131\u011f\u0131n\u0131 ve \u00e7ak\u0131\u015fmalar\u0131n ba\u015far\u0131yla \u00e7\u00f6z\u00fcld\u00fc\u011f\u00fcn\u00fc g\u00f6sterir. \u00c7\u00f6z\u00fcm s\u00fcrecinde bir sorun ya\u015farsan\u0131z veya ba\u015ftan ba\u015flamak isterseniz, birle\u015ftirme i\u015flemini git merge --abort<\/code> komutuyla iptal edebilirsiniz. Bu, deponuzu birle\u015ftirme i\u015fleminden \u00f6nceki haline d\u00f6nd\u00fcr\u00fcr ve yeni bir stratejiyle tekrar deneme imkan\u0131 sunar.<\/p>\n
\u0130leri D\u00fczey Git Birle\u015ftirme Stratejileri: Rebase, Squash ve Daha Fazlas\u0131 Nas\u0131l Kullan\u0131l\u0131r?<\/h2>\nGit'in temel birle\u015ftirme i\u015flevleri \u00e7o\u011fu zaman yeterli olsa da, daha karma\u015f\u0131k senaryolarda veya belirli bir ge\u00e7mi\u015f temizli\u011fi ihtiyac\u0131nda ileri d\u00fczey stratejiler devreye girer. \u00d6zellikle git rebase<\/code> ve git merge --no-ff<\/code> gibi komutlar, projenizin Git ge\u00e7mi\u015fini daha d\u00fczenli ve okunabilir hale getirmek i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r.<\/p>\n
Rebase vs Merge: Hangi Durumda Hangisi?<\/h3>\ngit rebase<\/code>, bir dal\u0131n commit'lerini ba\u015fka bir dal\u0131n \u00fczerine \"yeniden temel alma\" i\u015flemidir. Yani, bir dal\u0131n t\u00fcm ge\u00e7mi\u015fini al\u0131p, sanki o dal di\u011fer dal\u0131n en son commit'inden yeni olu\u015fturulmu\u015f gibi g\u00f6sterir. Bu, projenizin ge\u00e7mi\u015fini do\u011frusal ve temiz tutar, birle\u015ftirme commit'lerinden ka\u00e7\u0131n\u0131r. \u00d6rne\u011fin, main<\/code> dal\u0131ndan feature\/x<\/code> dal\u0131n\u0131 olu\u015fturdunuz. main<\/code> dal\u0131nda bu s\u00fcre\u00e7te yeni commit'ler yap\u0131ld\u0131. feature\/x<\/code> dal\u0131n\u0131 main<\/code> \u00fczerine birle\u015ftirmeden \u00f6nce, feature\/x<\/code> dal\u0131na ge\u00e7ip git rebase main<\/code> komutunu verirseniz, feature\/x<\/code> dal\u0131ndaki commit'ler main<\/code> dal\u0131n\u0131n en son commit'inin \u00fczerine ta\u015f\u0131n\u0131r. Bu i\u015flemden sonra main<\/code> dal\u0131na ge\u00e7ip git merge feature\/x<\/code> yapt\u0131\u011f\u0131n\u0131zda, genellikle fast-forward bir birle\u015ftirme ger\u00e7ekle\u015fir ve ge\u00e7mi\u015fte birle\u015ftirme commit'i olu\u015fmaz.<\/p>\n
Ne zaman rebase<\/code> kullan\u0131l\u0131r?<\/strong><\/p>\n
\nYerel, hen\u00fcz uzaktan payla\u015f\u0131lmam\u0131\u015f bir dalda \u00e7al\u0131\u015f\u0131rken ve ge\u00e7mi\u015fi temizlemek, do\u011frusal bir tarih olu\u015fturmak istedi\u011finizde.<\/li>\n
K\u00fc\u00e7\u00fck, ki\u015fisel \u00f6zellik dallar\u0131nda s\u0131k s\u0131k main<\/code> ile senkronize olmak ve ge\u00e7mi\u015fi basitle\u015ftirmek i\u00e7in.<\/li>\n<\/ul>\nAncak, uzak depoyla payla\u015f\u0131lm\u0131\u015f dallar\u0131 rebase etmekten ka\u00e7\u0131nmal\u0131s\u0131n\u0131z.<\/strong> Rebase, commit ID'lerini de\u011fi\u015ftirir ve bu, ba\u015fkalar\u0131yla ayn\u0131 dal \u00fczerinde \u00e7al\u0131\u015fanlar i\u00e7in sorunlara yol a\u00e7ar, \u00e7\u00fcnk\u00fc onlar\u0131n ge\u00e7mi\u015fi sizin ge\u00e7mi\u015finizle uyu\u015fmaz hale gelir.<\/p>\n
Ne zaman merge<\/code> kullan\u0131l\u0131r?<\/strong><\/p>\n
\nPayla\u015f\u0131lan dallar\u0131 birle\u015ftirirken veya bir dal\u0131n ge\u00e7mi\u015fini oldu\u011fu gibi korumak istedi\u011finizde.<\/li>\n
Birle\u015ftirme commit'lerinin, birle\u015ftirme olay\u0131n\u0131 ve ilgili dallar\u0131 kaydetmesini istedi\u011finizde (ki bu bir\u00e7ok ekip i\u00e7in izlenebilirlik a\u00e7\u0131s\u0131ndan \u00f6nemlidir).<\/li>\n<\/ul>\nSquash Merge (S\u0131k\u0131\u015ft\u0131rma Birle\u015ftirmesi)<\/h3>\nBazen, bir \u00f6zellik dal\u0131 \u00fczerinde \u00e7al\u0131\u015f\u0131rken bir\u00e7ok k\u00fc\u00e7\u00fck, deneysel veya ara commit yapars\u0131n\u0131z. Bu commit'lerin her birinin ana dal\u0131n ge\u00e7mi\u015finde yer almas\u0131n\u0131 istemeyebilirsiniz, ancak t\u00fcm bu de\u011fi\u015fikliklerin tek bir anlaml\u0131 commit olarak g\u00f6r\u00fcnmesini tercih edersiniz. \u0130\u015fte bu noktada squash merge<\/code> devreye girer. Squash merge, bir dal\u0131n t\u00fcm commit'lerini tek bir yeni commit'e s\u0131k\u0131\u015ft\u0131r\u0131r ve bu tek commit'i hedef dala birle\u015ftirir. Bu, ana dal\u0131n ge\u00e7mi\u015fini \u00e7ok daha temiz ve okunabilir hale getirir. Github veya GitLab gibi platformlar genellikle Pull Request'leri birle\u015ftirirken \"Squash and Merge\" se\u00e7ene\u011fini sunar.<\/p>\n
\ngit merge --squash feature\/kirli-dal # Bu komut, t\u00fcm commit'leri tek bir commit olarak haz\u0131rlar\ngit commit -m \"feature\/kirli-dal: Yeni \u00f6zellik eklendi\" # Ard\u0131ndan manuel olarak commit edilir\n<\/pre>\n<\/code><\/p>\n
Cherry-Picking (Belirli Commit'leri Se\u00e7me)<\/h3>\nBazen, bir daldaki t\u00fcm de\u011fi\u015fiklikleri birle\u015ftirmek yerine, sadece belirli bir veya birka\u00e7 commit'i ba\u015fka bir dala almak isteyebilirsiniz. \u00d6rne\u011fin, bir test dal\u0131nda yapt\u0131\u011f\u0131n\u0131z acil bir hata d\u00fczeltmesi, hen\u00fcz tamamlanmam\u0131\u015f di\u011fer \u00f6zelliklerle birlikte ana dala birle\u015ftirilemeyecek durumdad\u0131r. Bu durumda, hata d\u00fczeltmesini i\u00e7eren commit'i se\u00e7ip do\u011frudan ana dala uygulayabilirsiniz. Bu i\u015flem git cherry-pick<\/code> komutuyla yap\u0131l\u0131r.<\/p>\n
\ngit switch main\ngit cherry-pick \n<\/pre>\n<\/code><\/p>\n
Bu, belirtilen commit'i hedef dala yeni bir commit olarak uygular. \u00c7ok dikkatli kullan\u0131lmal\u0131 ve gereksiz \"duplicate\" commit'lerden ka\u00e7\u0131n\u0131lmal\u0131d\u0131r.<\/p>\n
\n        Uzman \u0130pucu: Proje ge\u00e7mi\u015finizi d\u00fczenli tutmak i\u00e7in ekip i\u00e7inde belirli Git ak\u0131\u015f\u0131 (Git Flow, GitHub Flow vb.) ve birle\u015ftirme stratejileri (\u00f6rne\u011fin, \u00f6zellik dallar\u0131n\u0131 her zaman squash merge ile birle\u015ftirme) konusunda anla\u015fmaya var\u0131n. Bu, tutarl\u0131l\u0131k sa\u011flar ve gelecekteki bak\u0131m s\u00fcre\u00e7lerini kolayla\u015ft\u0131r\u0131r.\n    <\/div>\nBu ileri d\u00fczey teknikler, Git'i daha etkili bir \u015fekilde kullanman\u0131z\u0131 ve projenizin s\u00fcr\u00fcm ge\u00e7mi\u015fini daha temiz ve y\u00f6netilebilir hale getirmenizi sa\u011flar. Do\u011fru stratejiyi se\u00e7mek, ekibinizin ve projenizin \u00f6zel ihtiya\u00e7lar\u0131na ba\u011fl\u0131d\u0131r.<\/p>\n
Projelerinizde Mobil Uyumlu HTML Yap\u0131s\u0131 Nas\u0131l Sa\u011flan\u0131r? Pratik Yakla\u015f\u0131mlar<\/h2>\nGit, kodunuzun versiyonlar\u0131n\u0131 y\u00f6netir ve ekip \u00e7al\u0131\u015fmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Ancak Git'in y\u00f6netti\u011fi web projelerinin kalitesi, kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan hayati \u00f6neme sahiptir. G\u00fcn\u00fcm\u00fcz d\u00fcnyas\u0131nda, web sitelerinin ve uygulamalar\u0131n mobil cihazlarda da sorunsuz \u00e7al\u0131\u015fmas\u0131 bir zorunluluktur. Mobil uyumlu HTML (Responsive Web Design), i\u00e7eri\u011fin ve tasar\u0131m\u0131n farkl\u0131 ekran boyutlar\u0131na ve cihazlara otomatik olarak uyum sa\u011flamas\u0131n\u0131 ifade eder. OSD600Lab3 gibi bir derste, Git \u00f6\u011frenirken ayn\u0131 zamanda \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z projenin teknik kalitesine de dikkat etmek, tam donan\u0131ml\u0131 bir geli\u015ftirici olman\u0131n anahtar\u0131d\u0131r. \u0130\u015fte Git ile y\u00f6netti\u011finiz projelerde mobil uyumlu HTML yap\u0131s\u0131 sa\u011flaman\u0131n temel ad\u0131mlar\u0131 ve pratik yakla\u015f\u0131mlar:<\/p>\n
1. Viewport Meta Etiketi<\/h3>\nMobil uyumlu tasar\u0131m\u0131n ilk ad\u0131m\u0131, taray\u0131c\u0131ya sayfan\u0131n cihaz\u0131n geni\u015fli\u011fine g\u00f6re \u00f6l\u00e7eklenmesi talimat\u0131n\u0131 veren viewport<\/code> meta etiketini eklemektir. Bu etiket, genellikle HTML belgesinin <\/code> b\u00f6l\u00fcm\u00fcnde yer al\u0131r:<\/p>\n
\n\n<\/pre>\n<\/code><\/p>\n
Bu etiket olmadan, mobil taray\u0131c\u0131lar sayfan\u0131z\u0131 masa\u00fcst\u00fc boyutunda render edip k\u00fc\u00e7\u00fcltebilir, bu da okunabilirlik sorunlar\u0131na yol a\u00e7ar. width=device-width<\/code>, sayfan\u0131n geni\u015fli\u011fini cihaz\u0131n ekran geni\u015fli\u011fine ayarlarken, initial-scale=1.0<\/code> ise sayfan\u0131n ilk y\u00fcklemede %100 oran\u0131nda yak\u0131nla\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flar.<\/p>\n
2. Esnek Izgaralar ve Medya Sorgular\u0131 (Media Queries)<\/h3>\nSabit geni\u015flikler yerine esnek birimler (y\u00fczdeler, em<\/code>, rem<\/code>, vw<\/code>, vh<\/code>) kullanarak d\u00fczenlerinizi dinamik hale getirmelisiniz. Ayr\u0131ca, CSS Media Queries, belirli ekran geni\u015fliklerine, y\u00fcksekliklerine veya cihaz \u00f6zelliklerine g\u00f6re farkl\u0131 stiller uygulaman\u0131za olanak tan\u0131r. Bu, mobil cihazlar i\u00e7in farkl\u0131 d\u00fczenler ve stiller tan\u0131mlaman\u0131n temelidir.<\/p>\n
\n