Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Belirli bir değişiklik hattını adlandırabilir, commitlerini o hat üzerinde ilerletebilir ve başka bir hatla ne zaman birleştirileceğini ayrıca kararlaştırabilirsin.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Burada iki ayrı işlem vardır: Yeni branch oluşturmak ve çalışma alanını o branch'e geçirmek. git branch <ad> varsayılan olarak yeni referansı oluşturur, fakat tek başına seni o branch'e geçirmez.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-002'de sana verilen iş için ekibin belirlediği başlangıç branch'ini kontrol edersin. Bu noktadan yeni bir branch oluşturur, çalışma alanının o branch'e geçtiğini doğrular ve ilgili commitleri burada üretirsin.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Branch'i uzak repository'ye göndermek ve GitHub'da Pull Request açmak sonraki, ayrı adımlardır; yerel branch oluşturmak bunları otomatik olarak yapmaz.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Değişikliği ayrı bir branch'te hazırla; commitlerini kontrol ettikten sonra Pull Request açarız.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Current, default, local ve remote-tracking branch ifadelerini bağlam içinde ayırt eder.
- Açıkla: Branch'in bir commit çizgisini adlandırdığını ve commitlerle ilerlediğini açıklar.
- Uygula: Başlangıç branch'ini kontrol eder, yeni branch oluşturur, ona geçer ve commitin doğru branch'e yazıldığını doğrular.
- Şimdilik bilmesi gerekmeyen: Refspec ayrıntıları, reflog kurtarma teknikleri ve organizasyon çapında branching strategy tasarımı.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Bir repository'de aynı anda hata düzeltmesi, yeni özellik veya deneme gibi farklı değişiklikler yürüyebilir. Branch bu geliştirme çizgilerini adlandırır; hangi commitlerin hangi çizgiye ait olduğunu takip etmeyi sağlar.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Review ve onay ise Git'in branch davranışı değil, kullanılan işbirliği platformunun ve ekibin sürecinin parçasıdır.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler aynı repository'deki değişiklikleri ayrı çizgilerde izlemek için branch kullanabilir. GitHub kullanan bir ekip, bir branch'teki değişiklikleri daha sonra Pull Request ile hedef branch'e önerebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Branch adı, ömrü ve birleştirme yöntemi ise Git'in zorunlu kıldığı evrensel kurallar değildir; repository ayarına ve ekip anlaşmasına göre değişir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Branch'ler farklı değişiklikleri ayırmayı kolaylaştırabilir; buna karşılık çok sayıda belirsiz isimli veya uzun süre açık kalan branch hangi çalışmanın güncel olduğunu takip etmeyi zorlaştırabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Ne zaman branch açılacağı, nasıl adlandırılacağı ve ne zaman birleştirileceği ekibin çalışma biçimine bağlıdır. Git Flow veya trunk-based development gibi yaklaşımlardan biri her ekip için tek doğru strateji değildir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- Branch, repository'nin veya dosyaların fiziksel kopyası değildir.
- Branch oluşturmak her zaman branch'e geçildiği anlamına gelmez.
origin/mainüzerinde görülen ref ile yerelmainaynı ref değildir.- Branch açmak Pull Request açmaz; Pull Request GitHub platform davranışıdır.
- Branch değiştirmek kaydedilmemiş çalışma ağacının güvenle saklandığı garantisini vermez; bu konu final içerikte komut ayrıntısına genişletilmemeli.
Gerilim ve çözüm1. bölüm