Linear ve GitHub Arasında Geçişi Durdurun
Mühendislerin Linear ve GitHub arasında neden saatler kaybettiği, yerel entegrasyonun gerçekte ne yaptığı ve iki aracı birlikte çalıştırmanın yolu.
By Ellis Keane · 2026-03-17
Dal adı feat/onboarding-email-verification idi. Linear ticket şunu yazıyordu: "Implement email verification flow – priority: urgent." GitHub PR'ında üç inceleme yorumu vardı, ikisi çözümlenmemişti. Ve geçen Salı günkü bir Slack yazışmasında, tasarımcımız doğrulama e-postası metninin bu yayınlanmadan önce güncellenmesi gerektiğini belirtmişti.
Bunların hepsinin var olduğunu biliyordum. Sadece hepsinin aynı iş parçasıyla ilgili olduğunu anlayamamıştım – ta ki Linear, GitHub, Slack ve giderek güvenilmez hale gelen kendi hafızam arasında yirmi dakika geçirene kadar.
Hem Linear hem de GitHub kullanan bir ekipte çalıştıysanız (ki bu noktada Jira'nın bir araçtan çok bir ceza olduğuna karar vermiş hemen her mühendislik ekibini tanımlar), ne hakkında konuştuğumu tam olarak biliyorsunuzdur. Linear ve GitHub arasındaki sürekli bağlam değiştirme küçük bir rahatsızlık değil – aynı anda kod tabanınızda ve proje planınızda gerçekte ne olduğunu anlamanıza gerçek bir vergidir.
Efsane: Bu Araçlar Zaten Birbiriyle Konuşuyor
Linear'ın bir GitHub entegrasyonu var. Kurduğunuz ilk şeylerden biri. Ve çalışıyor – belirli, sınırlı bir şekilde; bunu tam olarak anlamak değerlidir, çünkü insanların ne yaptığını düşündüğü ile gerçekte ne yaptığı arasındaki boşluk, acının büyük bölümünün yaşandığı yerdir.
Linear'ın GitHub entegrasyonunun gerçekte yönettiği şey şudur: bir Linear issue'dan bir dal oluşturduğunuzda, dal adı issue ID'yi içerir. O issue ID'ye atıfta bulunan bir PR birleştirildiğinde, Linear issue'yu otomatik olarak "Done" durumuna geçirebilir. Linear issue ayrıntı sayfasında PR bağlantılarını görebilirsiniz. Bu gerçekten kullanışlı ve küçümsemek istemiyorum.
Yönetmediği şey şudur: iki platform arasında yorumları senkronize etmek. Bir PR'ın çözümlenmemiş inceleme yorumları varken Linear ticket'ın "Done" durumuna taşındığını işaretlemek. Yaklaşımın tartışıldığı Slack konuşmasını issue'ya veya PR'a bağlamak. Figma tasarımlarının PR açıldıktan sonra güncellendiğini göstermek. Bu ticket'ın arkasındaki gereksinimin geçen hafta bir Notion belgesinde sessizce düşük önceliğe alındığını bilmek.
Entegrasyon mekanik bağlantıyı yönetir – issue ile PR. İkisinin çevresindeki bağlamsal ağı yönetmez. Ve bu bağlamsal ağ, Linear ile GitHub arasında her geçiş yaptığınızda yeniden oluşturmaya çalıştığınız şeydir.
Geçiş Yaptığınızda Gerçekte Neler Olur
Tipik bir Linear-GitHub bağlam değiştirmenin nasıl göründüğünü anlatayım, çünkü insanların ne kadar bilişsel çalışma gerektirdiğini küçümsediğini düşünüyorum.
Linear'dasınız. "In Review" olarak işaretlenmiş bir ticket görüyorsunuz. İncelemenin durumunu öğrenmek istiyorsunuz, bu yüzden GitHub'daki PR'a tıklıyorsunuz. Şimdi inceleme yorumlarını okuyorsunuz, ancak Linear ticket'ın bağlamını kaybettiniz – öncelik, kabul kriterleri, bağlantılı alt görevler. Linear'a geri dönüyorsunuz. Şimdi inceleme yorumlarındaki yerinizi kaybettiniz. GitHub'a geri dönüyorsunuz. Bir inceleyici bir Slack konuşmasından bahsetti, bu yüzden Slack'i açıp konuyu arıyorsunuz. Yirmi dakika geçti (tam olarak bunu kendim zamanlayarak yaptım) ve hâlâ bu ticket'ın gerçekten yayınlanmaya hazır olup olmadığına dair tam bir resme sahip değilsiniz.
Sorun, herhangi bir aracın kötü olması değil. Linear yaptığı işte mükemmel. GitHub yaptığı işte mükemmel. Sorun, "yaptığı şeyin" her aracın sınırında durması ve anlamaya çalıştığınız işin bu sınırlara uymayacak olması.
Linear ve GitHub arasında geçiş yapmak sadece sekme yönetimi sorunu değil. Bağlam yeniden oluşturma sorunudur – her bağlam değiştirme sizi farklı bir aracın perspektifinden işin zihinsel modelini yeniden oluşturmaya zorlar.
Neden "Sadece Her Şeyi Bağla" Ölçeklenmez
Buradaki standart tavsiye, bağlamalar konusunda disiplinli olmaktır. Her PR açıklaması Linear ticket URL'sini içermelidir. Her Linear ticket PR'ına bağlantı içermelidir. Her commit mesajı issue'ya atıfta bulunmalıdır.
Ve bu gerçekten işe yarar – üç ya da dört kişilik bir ekipteyseniz. Bu ölçekte herkes diğerinin ne üzerinde çalıştığını bilir, bağlama zorunluluktan çok güzel bir ek gibi görünür ve arada bir kaçırılan bağlantı önemli değildir çünkü sadece sorabilirsiniz.
Projenin tamamını artık kafanızda tutamadığınız noktada çalışmayı bırakır. Dört iş akışı yönetiyorsanız ve kendinizin spec etmediğiniz özellikler için PR'ları inceliyorsanız, bağlama disiplini kritik hale gelir – ve aynı zamanda baskı altında bozulan ilk şeydir. Kimse tembel olduğu için PR'ını bağlamayı unutmaz. Kod yazarken, üç sekme açıkken ve bir Linear URL'sini PR açıklamasına kopyalamanın insan beyninin sürekli olarak yapmakta son derece kötü olduğu türde küçük, sıfır geri bildirimli bir görev olduğu için unuturlar.
Asıl Sorun: İki Doğruluk Kaynağı
İşte bu belirli araç yorgunluğu hakkında anlamam uzun süren ve asıl kök neden olduğunu düşündüğüm şey.
Bu iki araç aynı işi temelden farklı perspektiflerden temsil eder. Linear size proje yönetimi görünümünü gösterir – öncelikler, sprint'ler, kime atandı, ne engellendi. GitHub size kod görünümünü gösterir – ne yazıldı, ne incelendi, ne birleştirildi. Her ikisi de geçerli. Her ikisi de gerekli. Ancak aynı gerçeği farklı kelimelerle tanımlıyorlar ve aralarındaki çeviri tamamen manüeldir.
"Her ikisi de geçerli. Her ikisi de gerekli. Ancak aynı gerçeği farklı kelimelerle tanımlıyorlar ve aralarındaki çeviri tamamen manüeldir." – Chris Calo
GitHub'da bir PR birleştirildiğinde, kod görünümü "done" diyor. Linear ticket henüz güncellenmediğinde, proje görünümü "in progress" diyor. Her ikisi de kendi bağlamlarında doğru ve her ikisi de diğeri olmadan yanıltıcı.
Bu çift kaynaklı doğruluk problemi (bence) sürekli sekme geçişinin bu kadar yorucu hissettirmesinin temel nedenidir. Sadece araç değiştirmiyorsunuz. Dünya görüşü değiştiriyorsunuz ve ardından bir karar verebilmeden önce bunları kafanızda uzlaştırmaya çalışıyorsunuz.
Bugün Yapabileceğiniz Pratik Şeyler
Mimari çözüme geçmeden önce (ki evet, bir bilgi grafiği içeriyor – bir tane inşa eden bir şirkette çalışıyorum, bu yüzden uygun bir şüpheyle alın), geçiş maliyetini azaltmaya yardımcı olan somut şeyler şunlardır:
Dal adlandırma kuralları. Linear'ın otomatik oluşturulan dal adları varsayılan olarak issue ID'yi içerir. Buna karşı koymayın. Bağlamayı makinenin yapmasına izin verin.
PR şablonları. "Linear ticket" alanını içeren bir PR şablonu oluşturun. GitHub, .github/PULL_REQUEST_TEMPLATE.md aracılığıyla PR şablonlarını destekler – bunu kurmak için gereken on dakika, kaçırılan bağlantılardan kaynaklanan saatleri tasarruf ettirecektir.
Çift yönlü durum. CI pipeline'ınız yeterince gelişmişse, bir PR birleştirildiğinde, incelendiğinde veya değişiklik istendiğinde ticket durumunu otomatik olarak güncellemek için Linear'ın API'sini kullanabilirsiniz. Bunu inşa etmek önemsiz değil (webhook yönetimi draft PR'lar ve force-push'lar etrafında bazı uç durumlar içeriyor), ancak büyük bir eski durum sorunları kategorisini ortadan kaldırıyor.
Haftalık mutabakat. Her Cuma on dakika ayırarak Linear board'unuzu GitHub'daki açık PR'larınızla karşılaştırın. Durumların uyuşmadığı her şeyi işaretleyin. Evet, bu yaşam için yazılım yazan insanlar açısından utanç verici derecede manüel – ironi benden kaçmıyor – ancak sapmaları sorun haline gelmeden yakalar ve bir sprint incelemesi sırasında uyuşmazlığı keşfetmekten sonsuz derecede daha iyidir.
Bunlar iyi uygulamalar. Hepsini kullanıyoruz. Sürekli bağlam değiştirmenin acısını azaltıyorlar, ancak ortadan kaldırmıyorlar, çünkü temel sorun – iki araç, iki perspektif, tek bir gerçeklik – devam ediyor.
Bağlantılı Bir Görünüm Gerçekte Nasıl Görünür
Sürekli geçişe alternatif, her iki aracı da anlayan ve her iki zihinsel modeli aynı anda tutmanızı gerektirmeden bir işin birleşik durumunu gösterebilen bir sistemdir.
Somut olarak bu şu anlama gelir: bir göreve bakarsınız ve GitHub PR'ının inceleme durumu ve CI sonuçlarının yanı sıra Linear ticket'ın önceliğini ve sprint'ini görürsünüz – yaklaşımın tartışıldığı Slack konusuyla birlikte, dün güncellenen Figma tasarımlarıyla birlikte. Tıklayarak geçeceğiniz bağlantılar olarak değil – ilişkiler zaten çözülmüş olarak, tek bir yerde, bağlam olarak.
İşte Sugarbug ile inşa ettiğimiz bu ve bu sorunu çözmenin tek yolu değil (bazı ekipler webhook'lar ve iyi bir frontend ile dahili araçlar inşa eder), ancak prensip aynı: insanların başından beri bağlı olması gereken iki aracı bağlama işini yapmasını durdurun.
---
Sugarbug, Linear issue'larını, GitHub PR'larını, Slack yazışmalarını ve Figma yorumlarını tek bir bilgi grafiğine bağlar – böylece geçişi durdurur ve tam resmi görmeye başlarsınız. Bekleme listesine katılın
---
Linear, GitHub, Slack ve Figma'yı tek bir bilgi grafiğine bağlayın – ve bağlamı elle yeniden oluşturmayı durdurun.
Q: Sugarbug, Linear ve GitHub arasında geçiş yapma ihtiyacını azaltıyor mu? A: Evet. Sugarbug her iki araca da API aracılığıyla bağlanır ve issue'ları, PR'ları, dalları ve konuşmaları birbirine bağlayan bir bilgi grafiği oluşturur. Her aracı ayrı ayrı kontrol etmek yerine, ilgili Slack tartışmaları ve Figma tasarımları dahil bir işin nasıl ilerlediğine dair birleşik bir görünüm elde edersiniz.
Q: Sugarbug, bir GitHub PR'ını otomatik olarak bir Linear issue'ya bağlayabilir mi? A: Sugarbug, bir GitHub PR'ının bir Linear issue'ya atıfta bulunduğunu (dal adı, PR açıklaması veya commit mesajı aracılığıyla) tespit eder ve bunları bilgi grafiğinde otomatik olarak birbirine bağlar. Ayrıca ilgili Slack tartışmalarını ve Figma yorumlarını aynı iş öğesine bağlar; böylece her araca tıklamadan tam bağlam her zaman görünür olur.
Q: Yerleşik Linear-GitHub entegrasyonu gerçekte ne yapıyor? A: Linear'ın dahili GitHub entegrasyonu, PR durumunu Linear issue'larıyla senkronize eder – bir PR birleştirildiğinde, bağlantılı issue otomatik olarak kapatılabilir. Ayrıca issue ayrıntı sayfasında PR bağlantılarını gösterir. Yapmadığı şeyler: yorumları senkronize etmek, ilgili Slack konuşmalarını bağlamak veya bir PR ile issue'nun çelişkili durumlarda olduğunu işaretlemek ("Done" olarak işaretlenmiş bir ticket üzerinde çözümlenmemiş inceleme yorumlarıyla birleştirilmiş bir PR gibi).
Q: İşi Linear'da mı yoksa GitHub Issues'da mı takip etmek daha iyidir? A: Farklı amaçlara hizmet ederler. Linear, proje planlaması için tasarlanmıştır – sprint'ler, döngüler, öncelikler, yol haritaları. GitHub Issues, kod düzeyinde takip için tasarlanmıştır – belirli depolara bağlı hatalar, özellik talepleri. Çoğu mühendislik ekibi her ikisini de (veya en azından Linear artı GitHub PR'larını) kullanır; bu da geçiş maliyetinin önemli olmasının ve bunları düzgün bağlamanın çabaya değer olmasının tam nedenidir.