Git nedir? GitHub ile farkı ve pazarlama ekibi için sürüm kontrolü

Git, bir projedeki dosya değişikliklerini açıklamalı kayıtlarla izleyen, kendi kopyamızda çalışmamızı ve ekip arkadaşlarımızın değişikliklerini birleştirmemizi sağlayan, geçmiş sürümlere dönüşü destekleyen ücretsiz ve açık kaynaklı dağıtık bir sürüm kontrol sistemidir. Biz her anlamlı düzenlemeyi bir commitCommitBir değişikliğin açıklamalı kaydı. ile saklar, neyi neden değiştirdiğimizi kayda geçiririz.

Git bir araçtır; GitHub, bu aracı kullanan ve projeleri bulutta barındıran bir hizmettir. Biz pazarlama ekibinde site dosyalarını, içerik takvimini ve yayın hazırlığını bu düzenle yürütürüz. Bir başlığın neden değiştiğini veya bir izleme kodunun hangi düzenlemeyle eklendiğini geçmişten takip ederiz.

Git nedir, ne işe yarar?

Git, dosyalardaki değişikliklerin geçmişini tutmaya, ayrı çalışmaları birleştirmeye ve hatalı düzenlemeleri geri almaya yarar. Sürüm kontrolü, projenin dosyalarıyla birlikte bu dosyaların nasıl değiştiğini de izlemektir. Git’in dağıtık yapısı sayesinde projenin bizdeki kopyasında çalışır, değişikliklerimizi ekipteki diğer çalışmalarla birleştiririz.

Biz bir açılış sayfasının metnini düzenlerken değişen satırları ve düzenleme gerekçesini birlikte kaydederiz. Daha sonra sayfanın önceki hâline bakmamız gerektiğinde ilgili kaydı buluruz. Kimin neyi, ne zaman ve neden değiştirdiği bu geçmiş üzerinden görünür hâle gelir.

Aynı yaklaşımı içerik takvimine, brief dosyalarına ve raporlama betiklerine uygularız. Her kayıt için anlaşılır bir açıklama yazarız. Örneğin “Kategori bağlantıları düzeltildi” ifadesi, geçmişi okurken yapılan işi gösterir. Biz açıklamayı yazarken sonraki oturumda dosyayı açacak ekip arkadaşımızın hangi değişiklikle karşılaşacağını düşünürüz.

GitHub nedir, Git’ten farkı ne?

GitHub, Git depolarını bulutta barındıran hizmettir; Git ise dosyalardaki değişiklikleri izleyen sürüm kontrol aracıdır. GitHub, kayıtların ve çalışmaların ekipçe paylaşılacağı ortamı sağlar. Platformun sunduğu planlama ve iş birliği araçları, işi planlamaktan yazılımı yayına almaya kadar geliştirme sürecini destekler.

Biz GitHub’da bir depo üzerinden projenin dosyalarına ve değişiklik geçmişine erişiriz. Bir ekip arkadaşımızın düzenlemesini gözden geçirir, ortak çalışmaya alınacak değişikliği değerlendiririz. Dosyanın son hâliyle birlikte ona nasıl gelindiğini de okuruz; açıklamalı kayıtlar incelemenin dayanağını oluşturur.

GitHub Desktop, değişiklikleri komut satırı kullanmadan yönetmemizi sağlayan uygulamadır. Biz ilk kez sürüm kontrolü kullanacak ekip üyesiyle dosya değişikliğini, açıklamasını ve paylaşım adımını bu arayüzde ele alırız. GitLab da Git depolarını barındıran başka bir platformdur.

Git’in temel kavramları nelerdir?

Git’in temel kavramları depo, commit, dal, birleştirme ve geri almadır; ekipçe gözden geçirme aşamasında çekme isteğiniÇekme isteğiBir daldaki değişikliklerin ana dala birleştirilmeden önce ekipçe incelenmesi için açılan istek; İngilizcesi pull request. de kullanırız. Biz bu kavramları yaptığımız işle eşleştirerek öğreniriz.

Dalın İngilizce karşılığı branch, deponun karşılığı repository’dir. Klonlama, projenin bir kopyasını kendi çalışma alanımıza almamızdır. Çekme işlemiyle paylaşılan güncel değişiklikleri alır, gönderme işlemiyle kendi kayıtlarımızı paylaşırız. Biz işe başlamadan önce güncel sürümü çeker, anlamlı düzenlemeyi kaydettikten sonra göndeririz.

Git komutları bu işlemlerin komut satırındaki karşılıklarıdır. Örneğin git commit değişikliği kaydetmek, git pull güncel değişiklikleri çekmek için kullanılır. Biz komut adından önce işlemin amacını öğreniriz; hangi dosyanın kayda gireceğini ve açıklamanın yapılan işi anlatıp anlatmadığını kontrol ederiz.

Pazarlama ekibi Git’i neden kullanır?

Pazarlama ekibi Git’i site, içerik ve ölçüm dosyalarında yapılan değişiklikleri izlemek ve ortak çalışmayı yönetmek için kullanır. Açılış sayfası kodu, site şablonları, izleme ve dönüşüm kodları, içerik takvimi, brief’ler, prompt şablonları ve raporlama betikleri bu çalışmanın kapsamındadır.

Biz markention’da bu blogun metinlerini, brief’lerini, görsellerin HTML kaynaklarını ve yayın betiklerini özel bir GitHub deposunda tutarız. Yazı hazırlanırken aynı depodaki kayıtların dağılımı şöyleydi:

Her yazının zamanlanmasını bir commit ile kaydederiz. Açıklamaya projeyi, oturumu ve yapılan işi yazarız. Çalışmayı kişisel bir dalda yürütür, ardından ana dala birleştiririz. Böylece bir yayın düzenlemesinin hangi çalışmaya ait olduğunu geçmişte buluruz.

Aynı depoda Claude ve Codex oturumları paralel çalışır. Biz dosyaya dokunmadan önce güncel sürümü çeker, her anlamlı adımdan sonra kaydı oluşturup göndeririz. Oturumlar arasındaki devri bir devir dosyasında tutarız. Yapay zekâ kod ajanlarının her anlamlı adımını ayrı commit olarak kaydeder, değişikliği okuyup birleştiririz.

Pazarlama ekibi Git’e nasıl başlar?

Pazarlama ekibi Git’e bir depo açarak, dosya kurallarını belirleyerek ve küçük bir değişikliği açıklamasıyla kaydederek başlar. Biz başlangıç çalışmasında dosyanın değişmeden önceki hâlini, yapılan düzenlemeyi ve kayıt açıklamasını birlikte inceleriz.

1. Depoyu açarızProjenin dosyalarıyla değişiklik geçmişini tutacağımız alanı oluşturur, ilk çalışmanın kapsamını belirleriz.
2. GitHub Desktop ya da kod düzenleyicinin Git panelini kurarızDosya değişikliklerini göreceğimiz ve kayıtları yöneteceğimiz arayüzü hazırlarız.
3. Gizli bilgi kuralını ve yok sayılacak dosyaları yazarızParolaları, API anahtarlarını, müşteri verisini ve veritabanı dökümlerini kapsam dışında tutarız.
4. İlk commit’i açıklamalı atarızKayda girecek dosyaları inceler, açıklamada yapılan işi açıkça belirtiriz.
5. Değişikliği dalda yapıp çekme isteğiyle birleştiririzDüzenlemeyi ortak çalışmaya almadan önce değişen satırları okur, amaca uygunluğunu kontrol ederiz.
6. Her yayından önce güncel sürümü çekerizYayın hazırlığında ekip arkadaşlarımızın paylaştığı değişiklikleri kendi çalışma kopyamıza alırız.

Başlangıç düzenini birlikte çalışacağımız kişilere ve dosyalara göre seçeriz:

1. Yalnız dosya geçmişi ve geri alma istiyoruz → GitHub Desktop ile tek dalda başlar, her anlamlı değişikliği açıklamasıyla kaydederiz.
2. Ekip aynı dosyalarda çalışıyor → Her birimiz kendi dalımızda çalışır, değişiklikleri çekme isteğiyle gözden geçirip ana dala birleştiririz.
3. Yapay zekâ kod ajanı kullanıyoruz → Ajanın her adımını ayrı commit olarak kaydeder, değişikliği okuyup birleştiririz.

Biz ilk denemeyi bir brief düzenlemesiyle yaparız. Kaydın açıklamasını okuyup dosyadaki değişiklikle eşleştiririz. Ekip arkadaşımız aynı kayıttan yapılan işi anlayabiliyorsa açıklama görevini yerine getirir. Sonraki çalışmaya geçerken güncel sürümü çekme ve değişikliği inceleme sırasını koruruz.

Depoya neler girmez?

Depoya parolalar, API anahtarları, müşteri verisi ve veritabanı dökümleri girmez. Biz bu kuralı projenin başında yazar, yok sayılacak dosyaları.gitignoreGit’in izlemeyeceği ve depoya almayacağı dosyaların listelendiği dosya. belirler ve commit oluşturmadan önce gizli bilgi taraması yaparız.

Bir bilgi depoya kaydedildiğinde geçmişte kalır. Bu nedenle yanlışlıkla eklenen anahtarı yalnız dosyanın son hâlinden kaldırmak yeterli değildir. Biz önce anahtarı iptal edip yenisini üretir, geçmişten temizleme işini uzmanla yürütürüz. Geri alma kaydı da bu güvenlik işleminin yerine geçmez.

Dosya kontrolünde metni ve içindeki bilgiyi birlikte okuruz. Bir raporlama betiğini kaydederken içine yazılmış bir anahtar bulunmadığını kontrol ederiz. Brief veya içerik dosyasına müşteri verisi taşımayız. Aynı gizli bilgi kuralını ekip arkadaşlarımızın ve kod ajanlarının yaptığı düzenlemelerde uygularız; kayıt öncesi taramayı çalışma düzeninin parçası olarak sürdürürüz.

Yok sayılacak dosya listesini hazırlarken dosyanın proje için gerekli olup olmadığını ve içinde hangi bilgilerin bulunduğunu birlikte değerlendiririz. Kayda girecek içerik seçimini yalnız dosya adına göre yapmayız.

Hatalı değişiklik nasıl geri alınır?

Hatalı değişikliği, ilgili commit’in etkisini yeni bir commit ile geri çevirerek geri alırız. Bu işleme revert denir. Biz önce hangi kaydın soruna yol açtığını bulur, içindeki değişiklikleri okur ve geri alınacak işi belirleriz.

Üç farklı ihtiyaç, üç farklı karşılık:

1. Yanlış değişiklik yayına girdi → İlgili commit’i geri alır, son çalışan sürüme döneriz.
2. İki kişi aynı satırı değiştirdi → Çakışmadaki değişiklikleri okur, doğru olanı seçer ya da birleştiririz.
3. Depoya parola ya da anahtar girdi → Parolayı değiştirir veya anahtarı hemen iptal edip yenisini üretir, geçmişten temizlemeyi uzmanla yaparız.

Çakışma, aynı satıra dokunan değişiklikleri birlikte değerlendirmemizi gerektirir. Örneğin bir açılış sayfasındaki cümle farklı çalışmalarda düzenlendiyse, her değişikliğin gerekçesini okuruz. Son metni sayfanın amacıyla karşılaştırır, korunacak ifadeye karar veririz.

Biz geri alma açıklamasına hangi değişikliği neden geri çevirdiğimizi yazarız. İnceleme sırasında yalnız kayıt başlığına bakmayız; kaydın dokunduğu dosyaları da kontrol ederiz. Küçük ve açıklamalı commit’ler, düzeltilecek işi bulmamıza yardımcı olur. Sorunu çözdükten sonra devir notuna yapılan düzeltmeyi ekler, sonraki oturumun bu bilgiyle başlamasını sağlarız.

Git’i site işlerinde nasıl kullanırız?

Git’i site işlerinde değişikliği dalda deneyerek, gözden geçirerek ve incelenen çalışmayı ana dala birleştirerek kullanırız. Biz işe güncel sürümü çekerek başlar, düzenlemenin hangi dosyalara dokunacağını belirleriz.

Örneğin bir açılış sayfasının metniyle dönüşüm kodu aynı çalışmada değişiyorsa, her düzenlemenin ne amaçla yapıldığını açıkça yazarız. Kaydı incelerken metnin istenen içeriği taşıdığını ve kod değişikliğinin planlanan işe karşılık geldiğini kontrol ederiz. Birleştirme kararını bu incelemeye göre veririz.

Biz kurumsal web sitesi çalışmalarında şablon ve içerik değişikliklerini dalda dener, gözden geçirip birleştiririz. Bir prototipi vibe coding ile geliştirirken de anlamlı değişiklikleri ayrı sürümler olarak kaydederiz. Her yayından önce güncel sürümü çeker, paylaşılacak değişikliklerde gizli bilgi taramasını tamamlarız.

İşi devrederken yapılan düzenlemeyi ve kalan adımı devir dosyasına yazarız. Böylece sonraki çalışmada hangi kaydın hangi işe ait olduğunu dosyalarla birlikte okuruz. Mobil uygulama kodunu da aynı depoda tutarız; çatı seçimini Flutter nedir yazımızda ele aldık. Biz web geliştirme yazılarımız üzerindeki güncellemeleri de aynı geçmiş içinde takip ederiz.

Sık sorulan sorular