Git’te Main Dal\u0131ndan Yeni Dal Olu\u015fturmak: Tam Bir Rehber<\/p>\n
Git kullan\u0131rken s\u0131k kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z bir durum, ana dal\u0131m\u0131z olan “main”den yeni bir \u00f6zellik dal\u0131 olu\u015fturma ihtiyac\u0131d\u0131r. Bu i\u015flem, kod taban\u0131n\u0131z\u0131 d\u00fczenli tutmak, yeni \u00f6zellikler \u00fczerinde \u00e7al\u0131\u015f\u0131rken main dal\u0131n\u0131 etkilememek ve i\u015f birli\u011fini kolayla\u015ft\u0131rmak i\u00e7in hayati \u00f6nem ta\u015f\u0131r. Bu rehberde, Git’te main dal\u0131ndan yeni bir dal olu\u015fturmay\u0131, farkl\u0131 senaryolar\u0131 ve ileri d\u00fczey teknikleri ad\u0131m ad\u0131m \u00f6\u011frenece\u011fiz.<\/p>\n
Git, da\u011f\u0131t\u0131k bir s\u00fcr\u00fcm kontrol sistemidir. Temel olarak, projenizin dosyalar\u0131n\u0131n farkl\u0131 s\u00fcr\u00fcmlerini takip etmenizi ve de\u011fi\u015fiklikleri y\u00f6netmenizi sa\u011flar. Bunun i\u00e7in “dallar\u0131” (branches) kullan\u0131r. Main dal\u0131 genellikle projenizin ana, kararl\u0131 s\u00fcr\u00fcm\u00fcn\u00fc temsil eder. Yeni \u00f6zellikler, hata d\u00fczeltmeleri veya deneysel kodlar i\u00e7in ise main dal\u0131ndan yeni dallar olu\u015ftururuz. Bu, main dal\u0131n\u0131n stabil kalmas\u0131n\u0131 ve yeni geli\u015ftirmelerin ana koda etki etmeden yap\u0131lmas\u0131n\u0131 sa\u011flar. Bir nevi, projenizin farkl\u0131 versiyonlar\u0131nda ayn\u0131 anda \u00e7al\u0131\u015fman\u0131za olanak tan\u0131r. Her dal ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilir ve daha sonra main dala birle\u015ftirilebilir (merge).<\/p>\n
Yeni ba\u015flayanlar i\u00e7in anla\u015f\u0131lmas\u0131 gereken en \u00f6nemli kavram, dallar\u0131n ba\u011f\u0131ms\u0131z olmas\u0131d\u0131r. main dal\u0131nda yapt\u0131\u011f\u0131n\u0131z de\u011fi\u015fiklikler, yeni olu\u015fturdu\u011funuz bir dal\u0131 etkilemez ve tam tersi de ge\u00e7erlidir. Bu, risksiz bir \u015fekilde deney yapman\u0131z\u0131 ve kodunuzu geli\u015ftirmenizi sa\u011flar. Ayr\u0131ca, ekip \u00e7al\u0131\u015fmas\u0131nda farkl\u0131 geli\u015ftiricilerin farkl\u0131 dallarda \u00e7al\u0131\u015f\u0131p daha sonra de\u011fi\u015fikliklerini birle\u015ftirmelerine olanak tan\u0131r, b\u00f6ylece \u00e7at\u0131\u015fmalar (conflicts) olas\u0131l\u0131\u011f\u0131 minimum seviyede tutulur.<\/p>\n
Main dal\u0131ndan yeni bir dal olu\u015fturmak olduk\u00e7a basittir. \u0130lk ad\u0131m olarak, Git deponuzda bulunman\u0131z ve main dal\u0131n\u0131n aktif (checkout edilmi\u015f) olmas\u0131 gerekir. Daha sonra a\u015fa\u011f\u0131daki komutu kullanabilirsiniz:<\/p>\n
\ngit checkout -b yeni-dal-adi\n<\/pre>\n<\/code><\/p>\n
Bu komut, \"-b\" se\u00e7ene\u011fiyle yeni bir dal olu\u015fturur ve ayn\u0131 anda bu yeni dala ge\u00e7er. \"yeni-dal-adi\" k\u0131sm\u0131n\u0131 projeniz i\u00e7in anlaml\u0131 bir isimle de\u011fi\u015ftirmeniz \u00f6nemlidir (\u00f6rne\u011fin: \"feature-login\", \"bugfix-database\"). Anlaml\u0131 isimlendirme, projenizin organizasyonunu ve kodun izlenebilirli\u011fini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Daha uzun isimler kullan\u0131yorsan\u0131z tire (-) kullanarak kelimeleri ay\u0131rmay\u0131 tercih edin. <\/p>\n
Alternatif olarak, \u00f6nce yeni bir dal olu\u015fturabilir, sonra da bu dala ge\u00e7ebilirsiniz:<\/p>\n
\ngit branch yeni-dal-adi\ngit checkout yeni-dal-adi\n<\/pre>\n<\/code><\/p>\n
Bu iki komut da ayn\u0131 sonucu \u00fcretir, fakat ilk y\u00f6ntem daha k\u0131sa ve kullan\u0131\u015fl\u0131d\u0131r.<\/p>\n
Yeni Dalda Geli\u015ftirme ve Main Dala Birle\u015ftirme<\/h2>\n
Yeni dal\u0131n\u0131z\u0131 olu\u015fturduktan sonra, \u00fczerinde de\u011fi\u015fiklikler yapmaya ba\u015flayabilirsiniz. Dosyalar\u0131n\u0131z\u0131 d\u00fczenleyin, yeni kod ekleyin, test edin. De\u011fi\u015fikliklerinizden sonra, \"git add\" ve \"git commit\" komutlar\u0131yla de\u011fi\u015fiklikleri kaydetmeyi unutmay\u0131n.<\/p>\n
\ngit add .\ngit commit -m \"Yeni \u00f6zellik eklendi\"\n<\/pre>\n<\/code><\/p>\n
T\u00fcm de\u011fi\u015fiklikleri yapt\u0131ktan ve test ettikten sonra, yeni dal\u0131n\u0131z\u0131 main dala birle\u015ftirebilirsiniz. \u00d6nce main dala geri d\u00f6nmeniz gerekir:<\/p>\n
\ngit checkout main\n<\/pre>\n<\/code><\/p>\n
Daha sonra, yeni dal\u0131n\u0131z\u0131 main dala birle\u015ftirmek i\u00e7in a\u015fa\u011f\u0131daki komutu kullan\u0131n:<\/p>\n
\ngit merge yeni-dal-adi\n<\/pre>\n<\/code><\/p>\n
E\u011fer yeni dal\u0131n\u0131zda main dal\u0131nda olmayan de\u011fi\u015fiklikler varsa, Git bir birle\u015ftirme i\u015flemi yapar ve genellikle otomatik olarak birle\u015ftirir. Ancak, \u00e7at\u0131\u015fma (conflict) durumunda, Git size hangi dosyalarda \u00e7at\u0131\u015fma oldu\u011funu bildirir ve el ile \u00e7\u00f6zmeniz gerekir. \u00c7at\u0131\u015fmalar\u0131 \u00e7\u00f6zmek i\u00e7in ilgili dosyalar\u0131 d\u00fczenleyin, \u00e7at\u0131\u015fma i\u015faretlerini kald\u0131r\u0131n ve kaydedin. Daha sonra \"git add\" ve \"git commit\" komutlar\u0131n\u0131 kullanarak de\u011fi\u015fiklikleri kaydedin.<\/p>\n
Vaka Analizi: Yeni Bir \u00d6deme Ge\u00e7idi Entegrasyonu<\/h2>\n
\u00d6rne\u011fin, bir e-ticaret sitesinde yeni bir \u00f6deme ge\u00e7idi entegre etmek istedi\u011finizi d\u00fc\u015f\u00fcnelim. Bu i\u015flemi main dal\u0131nda yapmak yerine, \"feature-new-payment-gateway\" ad\u0131nda yeni bir dal olu\u015fturursunuz. Bu dalda, yeni \u00f6deme ge\u00e7idini entegre etmek i\u00e7in gereken t\u00fcm kod de\u011fi\u015fikliklerini yapars\u0131n\u0131z. Testlerden sonra, bu dal\u0131 main dala birle\u015ftirip yeni \u00f6deme ge\u00e7idini canl\u0131 ortama al\u0131rs\u0131n\u0131z. Bu sayede, main dal\u0131n\u0131n stabilitesi korunur ve olas\u0131 sorunlar daha kolay tespit edilebilir ve d\u00fczeltilebilir.<\/p>\n
\u0130leri D\u00fczey Teknikler: Remote Dallar ve Pull Requestler<\/h2>\n
Ekip \u00e7al\u0131\u015fmas\u0131 yap\u0131yorsan\u0131z, genellikle uzak (remote) bir depo kullan\u0131rs\u0131n\u0131z (\u00f6rne\u011fin, GitHub, GitLab, Bitbucket). Bu durumda, yerel dallar\u0131n\u0131z\u0131 uzak depoya g\u00f6ndermeniz ve di\u011fer geli\u015ftiricilerin de\u011fi\u015fikliklerini alman\u0131z gerekir. Yeni dal\u0131n\u0131z\u0131 uzak depoya g\u00f6ndermek i\u00e7in a\u015fa\u011f\u0131daki komutu kullan\u0131n:<\/p>\n
\ngit push origin yeni-dal-adi\n<\/pre>\n<\/code><\/p>\n
Bu komut, \"origin\" adl\u0131 uzak depoya \"yeni-dal-adi\" adl\u0131 dal\u0131 g\u00f6nderir. Daha sonra, di\u011fer geli\u015ftiriciler bu dal\u0131 klonlayabilir veya \u00e7ekip (pull) de\u011fi\u015fiklikleri inceleyebilir ve birle\u015ftirme iste\u011fi (pull request) g\u00f6nderebilir. Pull requestler, kod incelemesi ve i\u015f birli\u011fini kolayla\u015ft\u0131ran \u00f6nemli bir Git \u00f6zelli\u011fidir. Pull request sayesinde, kod de\u011fi\u015fiklikleri incelenir, yorumlan\u0131r ve onayland\u0131ktan sonra main dala birle\u015ftirilir.<\/p>\n
Performans Kar\u015f\u0131la\u015ft\u0131rmas\u0131: Farkl\u0131 Birle\u015ftirme Stratejileri<\/h2>\n
| Birle\u015ftirme Stratejisi | Performans | Avantajlar | Dezavantajlar |
\n|---|---|---|---|
\n| git merge<\/code> | Orta | Basit ve h\u0131zl\u0131 (\u00e7at\u0131\u015fma yoksa) | \u00c7at\u0131\u015fmalar\u0131 \u00e7\u00f6zmek zaman alabilir |
\n| git rebase<\/code> | Y\u00fcksek (genellikle) | Daha temiz bir tarih\u00e7e olu\u015fturur | Daha karma\u015f\u0131k, yanl\u0131\u015f kullan\u0131mda hata riski |
\n| \u00d6zel \u00e7\u00f6z\u00fcmler (cherry-pick vb.) | De\u011fi\u015fken | Belirli commitleri se\u00e7ici bir \u015fekilde birle\u015ftirmek i\u00e7in ideal | Daha karma\u015f\u0131k, uzmanl\u0131k gerektirir |<\/p>\nG\u00fcvenlik Uyar\u0131lar\u0131<\/h2>\n