Başlangıçtan Uzmanlığa GitHub: Kapsamlı Bir Rehber

GitHub ile para kazanmak istiyorsanız, en doğrudan yol karmaşık değildir: lisans izni dahilinde, değerli açık kaynak projeler bulun, dağıtım, Türkçe dokümantasyon ve satış sonrası desteği bir hizmete dönüştürün ve teslimatı Xianyu gibi platformlarda satın.

Ancak, asıl para kazandıran şey bilgi filtreleme ve uygulama becerisidir. Yapay zeka yapmak, FDE (Full-stack Geliştirme Mühendisi) olmak veya kendinizi bir OPC (Tek Kişilik Şirket) haline getirmek istiyorsanız, kod, dokümantasyon, sürümler ve iş birliği eninde sonunda GitHub'a dayanacaktır.

Yaratıcılık ve kişisel medya ile uğraşıyor olsanız bile, GitHub'da çok sayıda konu seçme aracı, otomasyon projesi ve içerik üretim süreci bulunur. Dosyalar arttığında ve yapay zeka değişiklikler yaptığında, Git ile sürümleri yönetmezseniz, işler hızla kontrolden çıkar. Bu nedenle, programcıların öğrenmesi gerektiği gibi, proje yöneticileri ve içerik üreticilerinin de öğrenmesi gerekir; bu, ilhamı yönetilebilir, yeniden kullanılabilir ve teslim edilebilir bir projeye dönüştürüp dönüştüremeyeceğinizi belirler.

Bu makaleyi yarım aydan fazla bir süre boyunca, Git, GitHub, Commit'ler, dallar, PR'ler ve yaygın hataları 0'dan 1'e uygulayarak titizlikle hazırladım. Gelecekteki canlı yayınlar da aynı süreci takip edecek. Resmi yayından önce, bu eğitimi önce açık kaynak olarak yayınlıyorum. Yer imlerine ekleyebilir veya tamamen takip edebilirsiniz.

1. Git ve GitHub: Kim Neyi Yönetir?

Git, bilgisayarınıza kurulu bir sürüm yönetim aracıdır. Çevrimdışıyken bile commit yapabilir, geçmişi görüntüleyebilir, dallar oluşturabilir ve birleştirme yapabilirsiniz. GitHub ise uzak bir depo ve iş birliği platformudur; Git tarafından gönderilen commit'leri alır ve Issues, Pull Requests, Actions, kod incelemeleri ve izin yönetimi sağlar.

Git'te en kolay karıştırılan şey, aynı değişikliğin dört farklı konumda bulunabilmesidir. Aşağıdaki infografik, çalışma alanını, hazırlık alanını, yerel depoyu ve uzak depoyu dört katmana ayırır.

Kaydetmeye basmak yalnızca içeriği sabit diske yazar. git add seçmekten sorumludur, git commit yerel olarak bir sürüm bırakır ve git push bu commit'leri GitHub'a gönderir.

Bu nedenle, commit yapmadan önce diff'i kontrol edin, çalıştırın veya test edin; başarılı bir şekilde gönderdikten sonra, web sayfasına geri dönüp tekrar kontrol edin. Bu şekilde, bir sorun oluşursa, hangi katmanda durduğunu hemen anlayabilirsiniz.

2. Başlamadan Önce: Sadece Dört Şey Hazırlayın

Git, bir GitHub hesabı, bir düzenleyici ve bir uygulama projesine ihtiyacınız var. Düzenleyici için VS Code yeterlidir ve proje bir web sayfası veya bir Markdown belgesi olabilir.

İlk olarak, terminalde Git'i doğrulayın:

1git --version

Bu alıştırma macOS ve Git 2.49.0 kullanır. Windows kullanıcıları Git Bash veya VS Code yerleşik terminalini kullanabilir; aşağıdaki Git komutları aynıdır.

Ardından, commit yazarını yapılandırın:

1git config --global user.name "Adınız Soyadınız"
2git config --global user.email "E-posta Adresiniz"

Bu, commit kaydına yazılan yazar bilgisidir; GitHub'a giriş yapmaktan sorumlu değildir. Yalnızca mevcut uygulama projesi için yapılandırmak istiyorsanız, --global yerine --local kullanın.

GitHub girişi ayrı bir konudur. Komut satırı yaygın olarak üç yöntem kullanır:

• GitHub CLI, gh auth login ile tarayıcı üzerinden yetkilendirme;
• HTTPS, Kişisel Erişim Belirteci veya kimlik bilgisi yöneticisi kullanma;
• SSH, GitHub'a genel bir anahtar ekleme ve daha sonra anahtar aracılığıyla kimlik doğrulama.

Yeni başlayanlar GitHub CLI veya HTTPS'yi seçebilir. HTTPS kullanırken, terminal bir Şifre isterse, Belirteci girin; normal hesap şifreleri artık geçerli değildir. Belirteci komutlara, uzak URL'lere, README'lere, sohbetlere veya ekran görüntülerine yazmayın.

3. init Yapmak İçin Acele Etmeyin: Terminalin Gerçekte Nerede Olduğunu Doğrulayın

Bu alıştırma basit bir web sayfasıyla başlar. Tarayıcıda açılabilir ancak henüz Git geçmişi yoktur.

Projede üç dosya var:

1index.html
2style.css
3.gitignore

VS Code'da "Klasör Aç"ı seçin, yalnızca bir HTML dosyasına tıklamayın. Ardından yerleşik terminalde şunu çalıştırın:

1pwd
2ls

pwd geçerli dizini gösterir ve ls dosyaları listeler. index.html ve style.css dosyalarını gördükten sonra devam edin.

Bu kontrol aptalca görünebilir, ancak en sorunlu kaza türünü önler: birinin Masaüstü, Belgeler veya hatta kullanıcı ana dizininde git init çalıştırması ve ardından git add . ile binlerce ilgisiz dosyayı hazırlık alanına koyması. Git bozuk değildir; dizin yanlıştır.

4. git init Ne Yapar?

Şimdi depoyu başlatın:

1git init -b main
2git status --short

git init -b main, geçerli klasörde bir .git dizini oluşturur ve ilk dalı main olarak adlandırır. .git, commit'ler, dallar, hazırlık alanları ve uzak adresler gibi bilgilerin depolandığı gizli bir dizindir. Proje dosyaları yerinde kalır; Git bu andan itibaren onları gözlemlemeye başlar.

Ekran görüntüsündeki ?? işareti, izlenmeyen dosyaları gösterir. Dosyalar mevcuttur, ancak Git henüz bunları kaydedip kaydetmeyeceğine karar vermemiştir.

Depo kök dizinini doğrulamak için şunu çalıştırabilirsiniz:

1git rev-parse --show-toplevel

Çıktı, geçerli proje klasörü olmalıdır. fatal: not a git repository yazıyorsa, önce dizini kontrol edin, ardından git init'in çalıştırılıp çalıştırılmadığına bakın.

5. İlk Commit: Güvenilir Bir Başlangıç Noktası Tutun

Proje henüz değiştirilmedi, peki neden önce commit yapmalı? Çünkü sonraki tüm değişikliklerin karşılaştırılabilir bir başlangıç noktasına ihtiyacı vardır. İlk olarak, web sayfasını bir tarayıcıda açarak başlığın, kartların ve kayıt alanının görüntülendiğini doğrulayın; mobil genişlikte yatay kaydırma olup olmadığını görmek için pencereyi daraltın.

Ardından .gitignore dosyasına bakın. Bu sefer kullanılan içerik şudur:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore, anahtarları, günlükleri, bağımlılıkları ve derleme yapılarını engellemek için kullanılır. Esas olarak henüz izlenmeyen dosyalar üzerinde çalışır. Bir anahtar zaten commit edilmişse ve daha sonra .gitignore dosyasına eklerseniz, bu geçmiş hala oradadır; gerçek işlem ayrıca anahtarı iptal etmeyi veya döndürmeyi de içerir.

İlk commit için dosyaları seçmeye başlayın:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

Durumdaki A, Eklendi (Added) anlamına gelir ve dosyanın hazırlık alanına girdiğini gösterir. git diff --cached --stat size commit'e hazırladığınız dosya sayısını ve yaklaşık olarak kaç satırın değiştirildiğini söyleyecektir. Belirli içeriği görmek için şunu çalıştırın:

1git diff --cached

Onaydan sonra commit yapın:

1git commit -m "chore: Kampüs yapay zeka işe alım sayfasını başlat"
2git log --oneline
3git status

Bir Commit, yazar, zaman, açıklama ve üst commit ile bir proje anlık görüntüsü olarak anlaşılabilir. ffdf4ff, bu commit hash'inin kısa versiyonudur; geçerli depoda kullanmak, sürümü doğru bir şekilde bulabilir.

feat, fix, docs, style, chore yaygın commit türleridir, zorunlu Git sözdizimi değildir. Önekten daha önemli olan, onu takip eden Türkçe (veya İngilizce) açıklamadır: ne yapıldı, hangi nesne değiştirildi ve neden.

6. İkinci Commit: Yapay Zeka Değişikliklerini İnceleme Taslağı Olarak Ele Alın

Ardından, sayfaya bir "Kayıt Yöntemini Görüntüle" düğmesi ekleyin. Yapay zeka programlama araçlarını kullanırken, sınırları isteme yazarım:

1Yalnızca index.html dosyasını değiştir, giriş metninin altına sayfa içindeki #apply'ye bağlanan bir "Kayıt Yöntemini Görüntüle" bağlantısı ekle. style.css dosyasını değiştirme, Git commit'leri yapma. İşin bittiğinde hangi dosyanın değiştirildiğini söyle.

Manuel değişiklik de basittir:

1<a class="cta" href="#apply">Kayıt Yöntemini Görüntüle</a>

Yapay zeka işin bittiğini söylüyor, ancak henüz commit yapmayın. Şunu çalıştırın:

1git status --short
2git diff -- index.html
3git diff --check

git diff, henüz hazırlanmamış çalışma alanındaki değişiklikleri gösterir. Yeşil + eklenen satır, kırmızı - silinen satırdır. git diff --check çıktı vermez, bu da sondaki boşluklar gibi belirgin biçimlendirme sorunlarının bulunmadığı anlamına gelir; düğmenin tıklanabilir olup olmadığını sizin için kontrol etmez.

Tarayıcıya geri dönün ve yenileyin, düğmeye tıklayın, ardından pencereyi daraltın. Sayfa kayıt alanına kaydırılmalı ve düğme ile kartlar dar ekranlarda hala normal görünmelidir.

Yalnızca test geçtikten sonra commit yapın:

1git add index.html
2git diff --cached
3git commit -m "feat: Başvuru yöntemlerini hızlı görüntülemek için kayıt girişi ekle"
4git log --oneline -2

Bu noktada, depoda iki net sürüm vardır: başlangıç sayfası ve kayıt düğmesi. Düğmede daha sonra sorun olursa, onu hangi commit'in eklediğini doğrudan bulabilirsiniz.

Bu arada, iki diff'i ayırt edin:

1git diff             # Çalışma alanı ile hazırlık alanı arasındaki fark
2git diff --cached    # Hazırlık alanı ile en son commit arasındaki fark

git diff çıktı vermezse, dosya kaydedilmemiş olabilir veya zaten hazırlanmış veya commit edilmiş olabilir. Sırayla git status, git diff --cached ve git log kontrol etmek, tekrar tekrar git add . yazmaktan daha güvenilirdir.

7. Dallar: Belirsiz Değişiklikler İçin Bir Test Noktası Bırakın

Düğme yalnızca bir satır ekler, bu nedenle risk küçüktür. Tüm temayı mordan turuncuya değiştirmek iyi görünebilir veya kötü görünebilir; bu tür bir değişiklik bir dal için uygundur.

1git switch -c experiment/warm-theme
2git branch --show-current

Bir dal, kavramsal olarak belirli bir commit'i işaret eden bir addır. Yeni bir dal ilk oluşturulduğunda, main ile aynı commit'i işaret eder, bu nedenle dosyalar tamamen aynıdır. Yalnızca deneysel dal yeni commit'ler oluşturduğunda iki çizgi birbirinden ayrılır.

Diyagramda, mavi main hala ikinci commit'i işaret ederken, turuncu experiment zaten üçüncü commit'i işaret etmektedir. Proje iki dosya kümesini kopyalamadı; yalnızca iki dal adının işaretçileri değişti.

style.css dosyasındaki renk değişkenlerini değiştirin, sayfayı yenileyerek onaylayın ve ardından commit yapın:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Deneysel dalda sıcak temayı dene"
5git log --oneline --graph --decorate --all

HEAD, şu anda nerede durduğunuzu gösterir. Ekran görüntüsünde, HEAD, experiment/warm-theme'i işaret ederken, main düğme commit'inde kalır.

Sıcak temayı korumaya karar verin, main'e geri dönün ve birleştirin:

1git switch main
2git merge experiment/warm-theme

Burada bir Hızlı-ileri (Fast-forward) gerçekleşir çünkü main deney sırasında yeni commit'lere sahip değildi. Git, main işaretçisini doğrudan sıcak tema commit'ine ilerletir; değişiklikler başarıyla birleştirilmiştir.

Birleştirilmiş dallar güvenle silinebilir:

1git branch -d experiment/warm-theme

Küçük harf -d, dalın birleştirilip birleştirilmediğini kontrol eder. Büyük harf -D zorla siler ve daldaki birleştirilmemiş commit'ler referanslarını kaybedebilir; günlük temizlik komutu olarak kullanmayın.

8. Çakışmalar Gizemli Değildir; Git Sadece Sizin İçin Seçmeye Cesaret Edemez

Çakışmaları doğrulamak için depoyu çoğalttım. main, ana başlığı "Kampüs yaratıcılığının daha fazla kişi tarafından görülmesine izin verin" olarak değiştirdi ve feature dalı aynı satırı "Bir fikri gerçekten kullanılabilir bir çalışmaya dönüştürün" olarak değiştirdi. Git, birleştirme sırasında durdu:

Çakışma işaretçileri üç bölüme ayrılır:

1<<<<<<< HEAD
2Geçerli dalın içeriği
3=======
4Birleştirilecek dalın içeriği
5>>>>>>> feature/rewrite-heading

İşleme yöntemi, dosyayı düzenlemek, istenen son metni bırakmak, üç işaretçi kümesini silmek, test etmek ve ardından şunu çalıştırmaktır:

1git add index.html
2git commit

O anda işlemek istemiyorsanız, birleştirmeyi iptal edebilirsiniz:

1git merge --abort

Bir çakışma, iki kişinin veya iki Ajan'ın aynı konum için farklı cevaplar verdiği ve Git'in kendi başına seçim yapamadığı anlamına gelir.

9. Yerel Depoyu GitHub'a Gönderme

Projenin zaten yerel bir geçmişi var; şimdi bir depo oluşturmak için GitHub'a gidin. Sağ üst köşedeki + işaretine tıklayın, "Yeni depo" seçeneğini seçin ve depo adını doldurun, örneğin:

1campus-ai-demo

İlk uygulama için Özel (Private) olarak ayarlamanız önerilir. Yerel depoda zaten bir README, .gitignore ve commit geçmişi olduğundan, yeni GitHub deposunu boş tutun; web tarafında README, lisans veya .gitignore başlatmayın. Aksi takdirde, yerel ve uzak deponun her biri bir parça başlangıç ​​geçmişine sahip olur ve ilk gönderme, iki taraf arasındaki ilişkiyi ele almayı gerektirir. GitHub'ın resmi "Yerel olarak barındırılan kodu ekleme" kılavuzu da bunu açıkça hatırlatır.

HTTPS adresini kopyalayın:

1https://github.com/KullaniciAdiniz/campus-ai-demo.git

Proje terminaline dönün:

1git remote add origin https://github.com/KullaniciAdiniz/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin, uzak adres için bir takma addır; diğer adlarla çalışabilir, ancak topluluk ana uzak depoyu alışkanlıkla origin olarak adlandırır. -u, yerel main ile origin/main arasında bir izleme ilişkisi kuracaktır; sonraki işlemler genellikle yalnızca git push çalıştırır.

Aşağıdaki terminal diyagramı, push ve clone işlemlerini gerçekleştirmek için yerel bir boş depo kullandı, bu nedenle mevcut GitHub hesabını değiştirmedi. GitHub'a geçerken, yalnızca origin URL'sini değiştirin; Git'in commit'leri iletme ve izleme ilişkileri kurma mantığı aynıdır.

Gerçek push tamamlandıktan sonra, GitHub web sayfasına geri dönün ve dosyaların, README'nin, varsayılan dalın ve commit geçmişinin görünür olduğunu doğrulamak için yenileyin. Terminaldeki başarı mesajı bir kanıt katmanıdır ve web kontrolü başka bir katmandır.

10. Bir GitHub Deposunu İlk Kez Okumak: Sayfadaki Şeyler Nasıl Okunur

Aşağıda, resmi GitHub dokümantasyon deposunun 15 Ağustos 2026'da alınmış gerçek sayfası bulunmaktadır.

Bir depoyu açarken, önce şu konumlara bakın:

• Code: Dosyalar, dizinler, dallar ve commit'ler;
• Issues: Hatalar, gereksinimler, görevler ve tartışmalar;
• Pull requests: İnceleme veya birleştirme bekleyen değişiklikler;
• Actions: Otomatik test, derleme ve dağıtım;
• Security: Güvenlik politikaları ve güvenlik açığıyla ilgili işlevler;
• Insights: Katkılar, trafik ve depo etkinliği;
• README: Proje tanıtımı ve kullanım girişi;
• LICENSE: Nasıl kullanılmasına, değiştirilmesine ve dağıtılmasına izin verildiği.

Bilinmeyen bir projeyi okurken, önce Yıldızlara bakmayın. Önce beş soruyu yanıtlayın: Hangi sorunu çözüyor, nasıl çalışıyor, neye bağlı, yakın zamanda bakımı yapılıyor mu ve lisans ne yapmama izin veriyor. Yıldızlar dikkati yansıtır; sizin için güvenliği, uyumluluğu veya yetkilendirmeyi kontrol etmezler.

11. clone, fetch, pull, push: Dört Yönü Karıştırmayın

Uzak bir depoyu ilk kez bilgisayarınıza almak:

1git clone https://github.com/SAHIP/DEPO.git

Clone, dosyaları, commit geçmişini ve uzak yapılandırmaları getirir ve genellikle uzak depoyu otomatik olarak origin olarak adlandırır. Bir ZIP indirmek, yalnızca o andaki dosyaların bir anlık görüntüsünü verir, tam geçmişi vermez ve bir uzak ilişki kurmaz.

Daha sonraki yaygın olarak kullanılan üç eylem şunlardır:

1git fetch origin   # Uzak bilgileri indirir, mevcut çalışma dosyalarını değiştirmez
2git pull           # fetch yapar ve ardından geçerli dala entegre eder
3git push           # Yerel commit'leri uzak depoya gönderir

Uzakta ne olduğunu önce görmek için şunları yapabilirsiniz:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Yerel olarak bir ayrışma olmadığını doğruladığınızda ve yalnızca hızlı-ileri güncellemeleri kabul etmek istediğinizde:

1git pull --ff-only

pull önce fetch yapacak, ardından yapılandırmaya göre merge veya rebase gerçekleştirecektir. Ekipler, ilk iş birliğinden önce entegrasyon yöntemi üzerinde anlaşmalı ve bir ayrışma meydana geldiğinde sorunları düzeltmek için force push'a güvenmemelidir.

12. Kişisel Depodan GitHub İş Birliğine

Bir Pull Request, bir birleştirme teklifidir ve iş birliğinin gerçekleştiği yerdir. Tartışmalar, kod incelemeleri ve otomatik kontrollerin tümü aynı değişiklik kümesi etrafında döner ve onaylandıktan sonra main dalına birleştirilir.

Sorunun "Etkinlik zamanı açıklaması ekle" olduğunu varsayalım, yerel işlemler şu şekilde yapılabilir:

1git switch -c feat/event-time
2# Sayfayı değiştirin ve test edin
3git add index.html
4git commit -m "feat: Etkinlik zamanı açıklaması ekle"
5git push -u origin feat/event-time

Gönderdikten sonra, GitHub genellikle bir Pull Request oluşturmayı önerir. Bir PR, açıklamaları, commit'leri, dosya farklılıklarını, yorumları, incelemeleri ve otomatik kontrolleri görüntüleyen bir birleştirme teklifidir. Oluşturulduğu için otomatik olarak main dalına girmez.

İnsanların incelemeye istekli olduğu bir PR en az üç şeyi açıklamalıdır: ne değiştirildi, neden değiştirildi ve nasıl doğrulanacağı. Değişiklikler ne kadar odaklı olursa, inceleyenlerin sorunları tespit etmesi o kadar kolay olur.

Aynı ekipte, depoya yazma erişiminiz varsa, doğrudan bir daldan PR gönderebilirsiniz. Bilinmeyen bir açık kaynak projesine katkıda bulunurken, yaygın uygulama önce projeyi kendi hesabınıza Fork'lamak ve ardından kendi Fork'unuzu clone'lamaktır:

1git clone https://github.com/KullaniciAdiniz/ProjeAdi.git
2cd ProjeAdi
3git remote add upstream https://github.com/OrijinalYazar/ProjeAdi.git
4git remote -v

Burada genellikle iki uzak depo bulunur:

1origin    Kendi Fork'unuz
2upstream  Orijinal yazarın deposu

Orijinal projeyi senkronize edin:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Ardından değişiklikleri yeni bir dalda tamamlayın, kendi Fork'unuza gönderin ve ardından upstream'e bir PR gönderin. Fork, clone ve dal üç farklı şeyi çözer: Fork, GitHub'da bir depo alanı kümesidir; clone, depoyu yerel bilgisayara getirir; dal ise bir depo içindeki bir geliştirme hattıdır.

13. README ve LİSANS Başkalarının Kullanmaya Cesaret Edip Etmediğini Belirler

Bir README en azından şu soruları yanıtlamalıdır:

1. Proje nedir;
2. Hangi sorunu çözer;
3. Nasıl kurulur veya çalıştırılır;
4. Şu ana kadar ne kadar tamamlandı;
5. Ana dosyalar nerede bulunur;
6. Yazarlar, materyaller ve alıntı kaynakları kimlerdir.

Kod çalışabiliyor ancak README belirsizse, üç ay sonra onu kendiniz bile alamayabilirsiniz. Minimal bir README'nin güzel olması gerekmez; sadece projeyi, çalıştırma yöntemini ve durumu net bir şekilde yazın.

Genel depolar ayrıca otomatik olarak bir açık kaynak lisansı almak anlamına gelmez. GitHub'ın resmi lisans açıklaması, lisans olmadığında varsayılan telif hakkı kurallarının hala geçerli olduğunu ve yazarın kopyalama, dağıtma ve türev çalışmalar oluşturma haklarını elinde tuttuğunu açıkça belirtir. Genel, başkalarının onu görebileceği ve GitHub'ın hizmet şartlarına göre Fork'layabileceği anlamına gelir; kodu kendi genel veya ticari projenize almak için ayrıca depodaki LİSANSA bakmanız gerekir.

MIT, Apache-2.0, GPL vb.'nin farklı yükümlülükleri vardır. Ticari kullanım, yeniden dağıtım veya karma lisanslarla karşılaştığınızda, tam dosyayı okuyun ve gerekirse bir profesyonele danışın; sadece bir yapay zekaya "Ticari amaçlarla kullanabilir miyim?" diye sormayın.

14. Hata Yaptıktan Sonra: Değişikliğin Hangi Katmanda Olduğunu Belirleyin

Pişmanlık ilacı duruma göre seçilmelidir.

Yanlış dosyayı hazırladınız ancak dosya içeriğini korumak istiyorsunuz:

1git restore --staged dosyaadi

En son commit mesajı yanlış yazıldı ve henüz gönderilmedi:

1git commit --amend -m "Yeni commit mesajı"

Paylaşılan bir daldaki bir commit'in geri alınması gerekiyor:

1git revert commit_hash

revert yeni bir ters commit üretecek ve eski geçmiş görünür kalacaktır; bu, zaten gönderilmiş ve birden çok kişi tarafından kullanılan dallar için uygundur.

git restore dosyaadi, commit edilmemiş değişiklikleri atar; git reset --hard, commit'leri, hazırlık alanını ve çalışma alanını belirtilen bir konuma döndürür; git push --force, uzak commit'lerin üzerine yazabilir. Bu üç tür işlem, yürütmeden önce hedefin ve yedeklemenin onaylanmasını gerektirir; bunları sıfır taban aşamasında genel onarım düğmeleri olarak kullanmayın.

15. En Yaygın Sekiz Hata: Bu Sırayla Kontrol Edin

1. fatal: not a git repository

1pwd
2ls
3git status

Genellikle dizin yanlıştır veya mevcut proje henüz git init yapılmamıştır.

2. Author identity unknown

1git config --local user.name "Adınız Soyadınız"
2git config --local user.email "E-posta Adresiniz"

3. nothing to commit

Dosyanın kaydedilip kaydedilmediğini, başka bir kopyayı değiştirip değiştirmediğinizi ve değişikliklerin zaten commit edilip edilmediğini kontrol edin:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin DogruGitHubAdresi

5. src refspec main does not match any

Depoda henüz bir commit olmayabilir veya geçerli dal main olarak adlandırılmamış olabilir:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Uzak URL'yi, depo sahipliğini, hesap izinlerini ve kimlik doğrulama yöntemini kontrol edin. Sorun giderme için Belirteci başkalarına göndermeyin.

7. rejected non-fast-forward

Uzakta yerel olmayan commit'ler var. Önce fetch yapın ve farklılıkları görüntüleyin; sadece force push yapmayın:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

UU dosyalarını bulmak için git status çalıştırın, nihai içeriği manuel olarak belirleyin, test edin, ardından add ve commit yapın; şimdilik işlem yapmıyorsanız, git merge --abort.

Bir öğrenci veya iş arkadaşın sadece "Git bozuldu" dediğinde, onlardan şu beş çıktıyı istemelerini sağla:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Ardından işletim sistemini, az önce çalıştırılan tam komutu ve tam hata mesajını ekle. Çoğu sorun hızla şu katmanlardan birine düşecektir: dizin, durum, kimlik, uzak adres veya izin.

16. Yapay Zeka Çağında Git Daha Çok Bir Kabul Sistemi Gibi

Yapay zeka sizin için komutlar yazabilir, ancak hangi değişikliklerin iş hedeflerini karşıladığını otomatik olarak bilemez. Bir komut dosyası 20 dosyayı değiştirirse ve siz diff'e bakmaz, projeyi çalıştırmaz ve anahtarları kontrol etmezseniz, Git bu karmaşayı sadakatle kaydedecektir.

Daha istikrarlı bir yol, görevi daraltmak ve insanı kabul pozisyonuna koymaktır. Kapsam, farklılıklar, testler ve anahtar kontrolleri geçtikten sonra, insan bu değişikliklerin bir commit olup olamayacağına karar verir.

Yapay zekanın Git'i kullanmasına izin verirken, ayrıca sınırlar da koyun:

1Lütfen önce git status ve git diff'i kontrol edin ve yalnızca mevcut değişiklikleri özetleyin.
2Commit'lenmemiş hiçbir içeriği atmayın, reset --hard, clean veya force push yapmayın.
3Değişiklikleri tamamladıktan sonra doğrulama sonuçlarını sağlayın, otomatik olarak commit veya push yapmayın.

Komutları ezberleyip ezberleyemediğiniz artık o kadar önemli değil. Durumu okuyabilmeniz, yapay zekanın neyi taşıdığını bilmeniz, doğrulamanın yeterli olup olmadığına karar vermeniz ve tehlikeli işlemler göründüğünde durdurmanız gerekir.

17. Tüm Süreci Tekrar Çalıştırın

1# 1. Konumu onayla
2pwd
3ls
4
5# 2. Başlat
6git init -b main
7git status
8
9# 3. İlk commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialize project"
13
14# 4. Değiştir, kontrol et, test et, tekrar commit yap
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Add registration entry"
20
21# 5. Dal denemesi
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experiment with warm theme"
25git switch main
26git merge experiment/warm-theme
27
28# 6. GitHub'a bağlan
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Son kontrol
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Her bir komutun hangi katmanı değiştirdiğini açıklayabildiğinizde ve yanlış bir dizini, hazırlama hatasını ve birleştirme çakışmasını bağımsız olarak halledebildiğinizde, GitHub artık sadece kod depolamak için bir web sitesi değildir. Kişisel projelerinizi incelenebilir, denetlenebilir ve üzerinde işbirliği yapılabilir depolara dönüştürebilecek duruma gelmişsinizdir.

Bir sonraki adım, komut toplamaya devam etmeyi gerektirmez. Gerçek, küçük bir proje bulun ve bunu 7 gün üst üste yapın: her gün yalnızca küçük bir değişiklik tamamlayın, diff'e bakın, test edin, commit yapın ve ardından GitHub'a push edin. Commit geçmişi, bu şeyler kümesini yavaş yavaş çalışma alışkanlığınıza dönüştürecektir.

Ben Miles, büyük bir şirketten FDE'ye geçiş yapmış bir AI algoritma uzmanıyım. Algoritma Ar-Ge'si, optimizasyon dağıtımı ve kurumsal eğitim yaptım. Beni takip edin @miles_mazy Birlikte büyüyelim, birlikte para kazanalım.