Git ve Github Ayrıntılı Kullanım Rehberi

GitHub’da Repository (Depo) Oluşturma: İlk olarak, GitHub hesabınıza gidin ve sağ üst köşede bulunan “New” veya “Yeni” butonuna tıklayarak yeni bir repository oluşturun. Repository adını ve isteğe bağlı açıklamayı ekleyin.
Git Yükleme: Eğer bilgisayarınızda Git yüklü değilse, Git resmi sitesinden indirip kurun ve bilgisayarınıza yükleyin.
Komut Satırını Açma: Git Bash (Windows) veya Terminal (Mac/Linux) gibi bir komut istemcisini açın.

Git Global ayarları yapma.

Git yüklendikten sonra, sistemi kullanmaya başlamadan önce kimlik bilgilerini tanımlamak önemlidir. Bu sayede, ilk commit işleminden itibaren yaptığın tüm değişiklikler doğru bir şekilde senin adın ve e-posta adresinle ilişkilendirilir.

Genellikle, Git’i yükledikten sonra ilk adım olarak bu kimlik bilgilerini tanımlaman önerilir:

Git’i yükle.
git config –global user.name “Adın Soyadın” ve git config –global user.email “email@example.com” komutlarını çalıştırarak bilgilerini ekle.

git config --global user.name "Adın Soyadın"
git config --global user.email "email@example.com"

1 2	git config --global user.name "Adın Soyadın" git config --global user.email "email@example.com"

// Global olarak dal varsayılan dal ismini ayarlamak. 
git config --global init.defaultBranch main

1 2	// Global olarak dal varsayılan dal ismini ayarlamak. git config --global init.defaultBranch main

Bu işlemleri bir kez yaptığında, tüm projelerin için geçerli olur. Eğer sadece belirli bir proje için bu bilgileri ayarlamak istersen, bu adımları o projenin dizininde --global bayrağını kullanmadan gerçekleştirebilirsin.

Git’te, mevcut konfigürasyonda user.name ve user.email bilgilerini listelemek için şu komutu kullanabilirsin:

git config --list

1	git config --list

Bu komut, Git’in mevcut konfigürasyon ayarlarını listeleyecektir. Ancak sadece user.name ve user.email bilgilerini görmek istersen, şu komutları kullanabilirsin:

git config user.name
git config user.email

1 2	git config user.name git config user.email

Bu komutlar sırasıyla kullanıcı adını ve e-posta adresini gösterecektir.

Proje Klasörünü Oluşturma İşlemleri

Yerel Bir Klasör Oluşturma ve İlgili Yapılandırma: İlgili proje dosyalarını içerecek bir klasör oluşturun ve içine gidin.

mkdir proje_klasoru
cd proje_klasoru

1 2	mkdir proje_klasoru cd proje_klasoru

// Tüm dosyaları izinleri ile birlikte listeler.
ls -l 
// Gizli olan dosya ve klasörleri listeler.
ls -a
// f1.txt dosyasını nano ile açar. İçerisini düzenledikten sonra :wq ile kaydedip çıkış yapılabilir.
nano f1.txt

// Tüm dosyaları izinleri ile birlikte listeler.

ls -l

// Gizli olan dosya ve klasörleri listeler.

ls -a

// f1.txt dosyasını nano ile açar. İçerisini düzenledikten sonra :wq ile kaydedip çıkış yapılabilir.

nano f1.txt

Git’i Başlatma: Bu klasörü Git ile izlemeye başlatın.

// Bu şekilde bir kurulum yaparsanız dal olarak master seçmiş olursunuz. Eğer bu seçiminizi ilerde değiştirmek ister
//seniz ilk commit işleminden sonra "git branch -M main" dal ismini main olarak değiştirebilirsiniz. 
git init

// Bu şekilde bir kurulum yaparsanız dal olarak master seçmiş olursunuz. Eğer bu seçiminizi ilerde değiştirmek ister

//seniz ilk commit işleminden sonra "git branch -M main" dal ismini main olarak değiştirebilirsiniz.

git init

// Eğer main dalında ilerlemek isterseniz git init'i parametreli kullanabilirsiniz. Default değer olarak dal master
//tanımlanmaktadır.
git init --initial-branch=main

// Eğer main dalında ilerlemek isterseniz git init'i parametreli kullanabilirsiniz. Default değer olarak dal master

//tanımlanmaktadır.

git init --initial-branch=main

Git, varsayılan olarak boş klasörleri takip etmez. Eğer klasörün içinde hiçbir dosya yoksa, git add . komutuyla staging area’ya eklenmez. Bu durumda, klasöre bir dosya (örneğin .gitkeep adında boş bir dosya) ekleyebilirsin:

touch klasor_adi/.gitkeep
git add .

1 2	touch klasor_adi/.gitkeep git add .

Eğer bir şekilde local depoyu silmek isterseniz aşağıdaki komutu kullanabilirsiniz.

rm -rf .git/

1	rm -rf .git/

git status komutu, Git ile çalışırken mevcut çalışma dizininin ve staging (aşama) alanının durumunu kontrol etmenizi sağlar. Bu komut, çalışma dizinindeki dosyaların ve staging alanındaki değişikliklerin durumunu gösterir.

git status

1	git status

# Short gösterim
git status -s

1 2	# Short gösterim git status -s

Aşama Alanı (Staging Area): Commit işlemine dahil edilmek üzere hazırlanan değişikliklerin geçici olarak toplandığı yer.

Aşama Alanına Dosya Ekleme: Bir dosyayı veya değişikliği aşama alanına eklemek için git add komutunu kullanırsın. Bu komut, dosyaları staging alanına ekler, böylece bunlar commit işlemine dahil olur.

Tek Bir Dosyayı Eklemek:

git add dosya.txt

1	git add dosya.txt

Bu komut, dosya.txt dosyasındaki değişiklikleri staging alanına ekler.

Birden Fazla Dosyayı Eklemek:

git add dosya1.txt dosya2.txt

1	git add dosya1.txt dosya2.txt

Aynı anda birden fazla dosyayı staging alanına ekleyebilirsin.

Tüm Değişiklikleri Eklemek:

git add .

git add .

Bu komut, tüm değişiklikleri (yeni, değiştirilmiş, silinmiş dosyalar) staging alanına ekler.

Aşama Alanını Temizleme

Staging alanını temizlemek, oraya eklenmiş dosyaları geri alarak onları staging alanından çıkarmak anlamına gelir. Bu işlem, dosyaların staging alanından çıkarılmasını sağlar, ancak dosyaların çalışma dizinindeki durumunu değiştirmez.

Belirli Bir Dosyayı Staging Alanından Çıkarma:

git reset dosya.txt

1	git reset dosya.txt

Bu komut, dosya.txt dosyasını staging alanından çıkarır ve bu dosya commit işlemine dahil edilmez.

Tüm Dosyaları Staging Alanından Çıkarma:

# "git reset ." kullanılabilir.
git reset

1 2	# "git reset ." kullanılabilir. git reset

Bu komut, staging alanındaki tüm dosyaları çıkarır.

Aşama Alanının Durumunu Kontrol Etme

Aşama alanında hangi dosyaların olduğunu görmek için git status komutunu kullanabilirsin.

# git status -s Kısa gösterim tercih edilebilir.
git status

1 2	# git status -s Kısa gösterim tercih edilebilir. git status

Bu komut, staging alanındaki ve çalışma dizinindeki dosyaların durumunu gösterir. Hangi dosyaların staging alanına eklenmiş olduğunu, hangilerinin henüz eklenmediğini görebilirsin.

Commit Yapın: Değişiklikleri onaylayın ve bir commit (işlem) yapın.

git commit -m "İlk commit"

1	git commit -m "İlk commit"

# Dal adını <strong>master</strong> dalından, <strong>main</strong> dalına değiştirir. Bu işlem için öncesinde bir commit işleminin olması gerekir.

git branch -M main

# Dal adını <strong>master</strong> dalından, <strong>main</strong> dalına değiştirir. Bu işlem için öncesinde bir commit işleminin olması gerekir.

git branch -M main

Commitleri Görüntüleyin : Commitleri görüntülemek için git log komutu kullanılır. Görüntüleme yöntemleri aşağıdadır.

1. Temel git log Kullanımı

git log

git log

Bu komut, commit geçmişini baştan sona listeler. Her commit hakkında aşağıdaki bilgileri gösterir:

Commit hash’i
Yazar (Author)
Tarih
Commit mesajı

2. Sadece Commit Hash’lerini Görmek

Eğer sadece commit hash’lerini görmek istersen:

git log --oneline

1	git log --oneline

•Bu komut, her commit’i tek satırda, kısa bir commit hash’i ve commit mesajı ile gösterir. Örneğin:

abc1234 Initial commit
def5678 Added new feature

1 2	abc1234 Initial commit def5678 Added new feature

3. Sadece Son N Commit’i Görmek

Eğer son birkaç commit’i görmek istersen, sayısını belirleyebilirsin:

git log -n 5

1	git log -n 5

•Bu komut, son 5 commit’i listeler.

4. Belirli Bir Dosyaya Yapılan Commit’leri Görmek

Bir dosya üzerinde yapılan commit’leri görmek için:

git log <dosya_adi>

1	git log <dosya_adi>

•Örneğin:

git log README.md

1	git log README.md

•Bu komut sadece README.md dosyasında yapılan değişikliklerin olduğu commit’leri gösterir.

5. Commit’leri Grafik Olarak Görmek

Commit geçmişini daha görsel bir şekilde görmek için:

git log --graph --oneline --all

1	git log --graph --oneline --all

•–graph: Commit’ler arasındaki ilişkiyi dallar halinde grafiksel olarak gösterir.

•–oneline: Commit’leri tek satırda ve kısa gösterir.

•–all: Tüm dalları gösterir.

Çıktı şöyle görünebilir:

* abc1234 (HEAD -> main) Added feature X
* def5678 Refactor code
| * 789xyz Merge branch 'feature'
|/

* abc1234 (HEAD -> main) Added feature X

* def5678 Refactor code

| * 789xyz Merge branch 'feature'

•–since: Belirli bir tarihten itibaren yapılan commit’leri gösterir.

•–until: Belirli bir tarihe kadar yapılan commit’leri gösterir.

7. Yazar Adına Göre Filtreleme

Belirli bir kişinin yaptığı commit’leri görmek için:

git log --author="yazar_adı"

1	git log --author="yazar_adı"

•Örneğin:

git log --author="Jane Doe"

1	git log --author="Jane Doe"

8. Commit Mesajına Göre Arama

Commit mesajları içinde belirli bir anahtar kelimeyi aramak için:

git log --grep="anahtar kelime"

1	git log --grep="anahtar kelime"

•Bu komut, commit mesajlarında “anahtar kelime” geçen commit’leri gösterir.

9. Değişiklikleri Görmek (Diff ile)

Her commit’te hangi dosya değişikliklerinin yapıldığını görmek için:

git log -p

1	git log -p

•Bu komut, her commit’teki değişikliklerin (diff) detaylarını gösterir.

•-p yerine –stat kullanarak sadece değişen dosyaların listesini ve ne kadar değişiklik yapıldığını görebilirsin:

git log --stat

1	git log --stat

10. Commit’leri Tersine Sıralamak

Commit’leri ters sırayla (en eski commit’ten en yeni commit’e) görmek için:

git log --reverse

1	git log --reverse

11. Sadece Merge Commit’leri Görmek

Eğer sadece “merge” commit’lerini görmek istiyorsan:

git log --merges

1	git log --merges

Özet

git log komutu çok güçlü bir araçtır ve commit geçmişini detaylıca incelemek için birçok farklı seçenek sunar. İşte yaygın kullanılan opsiyonların kısa bir listesi:

–oneline: Commit’leri tek satırda gösterir.
–graph: Commit ilişkilerini grafiksel olarak gösterir.
–author: Belirli bir yazarın commit’lerini gösterir.
–since / –until: Zaman filtrelemesi yapar.
–stat / -p: Değişiklik detaylarını gösterir.

Bu seçeneklerle commit geçmişini ihtiyaçlarına göre özelleştirebilirsin.

Son yapılan commit ile ilgili düzenlemeler yapmak :

git commit --amend komutu, son yaptığın commit’i düzenlemek veya değiştirmek için kullanılır. Bu komutla, en son commit’e eklemeler yapabilir, commit mesajını güncelleyebilir veya hata yaptığın bir durumu düzeltebilirsin.

Örnek Senaryo – Yeni dosyayı son commite ekleme.

Senaryo Adımları:

1. Proje Dizini Hazırlama

Öncelikle bir proje dizini oluştur ve içine birkaç dosya ekle.

mkdir git-amend-senaryo
cd git-amend-senaryo
git init

mkdir git-amend-senaryo

cd git-amend-senaryo

git init

Yeni bir Git deposu oluşturmuş oldun. Şimdi birkaç dosya ekleyelim.

echo "Bu ilk dosya." > file1.txt
echo "Bu ikinci dosya." > file2.txt

1 2	echo "Bu ilk dosya." > file1.txt echo "Bu ikinci dosya." > file2.txt

2. Dosyaları Staging Area’ya Ekleme

Şimdi bu dosyaları staging area’ya ekleyelim:

git add .

git add .

3. İlk Commit Yapma

Dosyaları ekledikten sonra bir commit yapalım, ancak commit mesajında küçük bir hata yapalım:

git commit -m "İlk comit yapıldı"

1	git commit -m "İlk comit yapıldı"

Fark ettiysen commit mesajında bir yazım hatası var: “comit” yerine “commit” olmalıydı. Şimdi bunu düzelteceğiz.

4. Commit Mesajını Düzeltme (–amend)

Commit yaptıktan sonra, yanlış yazılan commit mesajını düzeltmek için git commit –amend komutunu kullanacağız:

git commit --amend -m "İlk commit yapıldı"

1	git commit --amend -m "İlk commit yapıldı"

Bu komut ile commit mesajını düzelttik. Artık Git geçmişinde bu commit’in yeni, düzeltilmiş mesajı kaydedildi.

5. Yeni Bir Dosya Ekleyip Son Commit’e Ekleme

Şimdi projeye yeni bir dosya ekleyelim ama bunu yeni bir commit yapmak yerine son commit’e dahil edelim:

echo "Bu üçüncü dosya." > file3.txt
git add file3.txt

1 2	echo "Bu üçüncü dosya." > file3.txt git add file3.txt

Son commit’e yeni dosyayı eklemek için tekrar git commit –amend komutunu kullanacağız:

git commit --amend --no-edit

1	git commit --amend --no-edit

Burada –no-edit kullanarak commit mesajını değiştirmeden son commit’e dosya eklemiş olduk. Yani, üçüncü dosya commit’e dahil edildi ama commit mesajı aynı kaldı.

6. Commit Geçmişini Kontrol Etme

Commit geçmişini kontrol etmek için şu komutu kullanabilirsin:

git log --oneline

1	git log --oneline

Bu komut ile son commit’i ve commit mesajını görebilirsin.

Eğer commit içindeki dosyaları görmek isterseniz git show ile görebilirsiniz.

git show <commit-hash>

1	git show <commit-hash>

7. Commit’i Düzenleme Özet

İlk olarak bir commit yaptık, ama commit mesajında hata vardı.
git commit –amend -m ile commit mesajını düzelttik.
Yeni bir dosya ekledik ve git commit –amend –no-edit ile bu dosyayı son commit’e dahil ettik.

Bu, git commit –amend komutunun hem commit mesajını düzeltme hem de dosya ekleyerek commit içeriğini güncelleme gücünü gösteren bir senaryoydu.

Örnek Senaryo – Commitler arası geçiş – Git Reset

git reset komutu, Git’te bir dalın başını (HEAD) belirli bir commit’e geri almak için kullanılır. Üç farklı modda çalışır: soft, mixed ve hard. Her bir modun farklı etkileri vardır ve hangi aşamada neyin sıfırlanacağını kontrol eder. Bu senaryoları açıklarken, 3 commit’in olduğunu ve bir dosyada farklı değişiklikler içerdiğini varsayalım.

Commit’ler:

Commit 1 (abc1234): file.txt dosyasına yapılan ilk değişiklik.
Commit 2 (def5678): file.txt dosyasına yapılan ikinci değişiklik.
Commit 3 (ghi9012): file.txt dosyasına yapılan üçüncü değişiklik.

git reset Kullanım Senaryoları:

1. git reset –soft <commit-hash>: Sadece HEAD Geri Alınır

Bu mod, HEAD’i belirtilen commit’e geri alır, ancak çalışma dizini ve staging area (index) değişmeden kalır. Yani, commit’ler geri alınır ama tüm değişiklikler staging area’da kalır. Bu durumda, commit’leri tekrar düzenleyebilir ve yeniden commit yapabilirsin.

Senaryo:

Son commit’i (ghi9012) geri almak ve aynı değişiklikleri staging area’da tutmak istiyorsun, böylece commit mesajını düzeltip yeniden commit edebilirsin.

Komut:

git reset --soft def5678

1	git reset --soft def5678

Bu komut HEAD’i ikinci commit’e geri alır (def5678). Üçüncü commit’in (ghi9012) değişiklikleri ise staging area’da kalır.
Şimdi bu değişiklikler üzerinde tekrar çalışabilir veya commit mesajını düzeltebilirsin.

Durum:

HEAD ikinci commit’e geri döner.
Çalışma dizininde hiçbir değişiklik yapılmaz.
Üçüncü commit’teki değişiklikler staging area’da bekler.

2. git reset –mixed <commit-hash>: Staging Area ve HEAD Geri Alınır

Bu mod, HEAD’i belirtilen commit’e geri alır ve staging area’daki değişiklikleri sıfırlar. Ancak, çalışma dizini değişmez. Yani, commit’ler geri alınır ve staging area’daki değişiklikler çalışma dizinine geri aktarılır. Böylece değişiklikler hala mevcut olur ama staging area’dan çıkarılır.

Senaryo:

Üçüncü commit’i geri almak istiyorsun ama o commit’teki değişikliklerin çalışma dizininde kalmasını istiyorsun, böylece değişiklikleri gözden geçirip yeniden staging area’ya ekleyebilirsin.

Komut:

git reset --mixed def5678

1	git reset --mixed def5678

HEAD ikinci commit’e (def5678) geri döner, ancak üçüncü commit’teki (ghi9012) değişiklikler çalışma dizininde kalır.
Bu değişiklikler tekrar staging area’ya eklenmediği için git status ile “çalışma dizininde” olduğunu görürsün.

Durum:

HEAD ikinci commit’e döner.
Üçüncü commit’teki değişiklikler çalışma dizininde kalır.
Staging area sıfırlanır.

3. git reset –hard <commit-hash>: HEAD, Staging Area ve Çalışma Dizini Geri Alınır

Bu mod, HEAD’i belirtilen commit’e geri alır ve hem staging area’yı hem de çalışma dizinini o commit’in durumuna getirir. Tüm değişiklikler geri alınır ve commit yapılmamış olan her şey kaybolur. Bu, oldukça güçlü bir komuttur ve dikkatli kullanılmalıdır.

Senaryo:

Üçüncü commit’i geri almak istiyorsun ve o commit’teki tüm değişiklikleri silmek istiyorsun (hem çalışma dizininde hem de staging area’dan).

Komut:

git reset --hard def5678

1	git reset --hard def5678

HEAD ikinci commit’e geri döner ve üçüncü commit’teki (ghi9012) değişiklikler tamamen kaybolur.
Çalışma dizini ve staging area, ikinci commit’in (def5678) durumu ile aynı hale gelir.

Durum:

HEAD ikinci commit’e döner.
Üçüncü commit’teki tüm değişiklikler silinir (hem çalışma dizininden hem de staging area’dan).

Özetle:

git reset –soft <commit>: Commit’i geri alır, değişiklikler staging area’da kalır.
git reset –mixed <commit> (Varsayılan): Commit’i geri alır, değişiklikler çalışma dizininde kalır, staging area sıfırlanır.
git reset –hard <commit>: Commit’i geri alır, tüm değişiklikler silinir (çalışma dizini ve staging area geri alınır).

Her bir senaryo, commit’lerin geri alınmasına yönelik farklı seviyelerde esneklik sağlar. –soft değişiklikleri kaybetmeden commit’leri geri almanı sağlarken, –hard tüm değişiklikleri siler. –mixed ise çalışma dizinindeki değişiklikleri koruyarak commit’leri ve staging area’yı sıfırlar.

Örnek Senaryo – Commit Override – Git revert

Senaryoda üç commit ve her commit’in içerdiği dosya değişiklikleri olacak. Ardından git revert ile bir commit’i geri alacağız.

Senaryo

Proje Yapısı

Bir yazılım projesi üzerinde çalışıyorsun. Proje şu üç dosyadan oluşuyor:

index.html
style.css
app.js

Başlangıç Durumu (İlk Commit)

İlk commit’te, bu üç dosya oluşturulmuş ve temel içerikleri eklenmiş.

Commit 1 (abc1234):

git commit -m "Initial commit with basic HTML, CSS, and JS files"

1	git commit -m "Initial commit with basic HTML, CSS, and JS files"

Dosyalar:

•index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Project</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <h1>Welcome to My Project</h1>
    <script src="app.js"></script>
</body>
</html>

<!DOCTYPE html>

<head>

<title>My Project</title>

</head>

<body>

<h1>Welcome to My Project</h1>

</body>

</html>

•style.css:

body {
    font-family: Arial, sans-serif;
}

body {

font-family: Arial, sans-serif;

}

•app.js:

console.log('Welcome to My Project');

1	console.log('Welcome to My Project');

Commit 2: CSS Dosyasına Değişiklik Eklemek

İkinci commit’te, style.css dosyasına bir değişiklik eklenmiş ve stil özelliği değiştirilmiş.

Commit 2 (def5678):

git commit -m "Update style.css to change body background color"

1	git commit -m "Update style.css to change body background color"

style.css:

body {
    font-family: Arial, sans-serif;
    background-color: lightblue;
}

body {

font-family: Arial, sans-serif;

background-color: lightblue;

}

Commit 3: JavaScript Dosyasına Yeni Özellik Eklemek

Üçüncü commit’te, app.js dosyasına yeni bir özellik eklenmiş.

Commit 3 (ghi9012):

git commit -m "Add alert feature to app.js"

1	git commit -m "Add alert feature to app.js"

app.js:

console.log('Welcome to My Project');
alert('Welcome to My Project');

1 2	console.log('Welcome to My Project'); alert('Welcome to My Project');

Geri Alma Senaryosu

Projede fark ettin ki, Commit 3 (JavaScript dosyasına eklenen alert özelliği) gereksizmiş ve bu değişikliği geri almak istiyorsun.

1. Commit Geçmişini Kontrol Et

İlk önce commit geçmişine bakalım:

git log --oneline

1	git log --oneline

Çıktı:

ghi9012 Add alert feature to app.js
def5678 Update style.css to change body background color
abc1234 Initial commit with basic HTML, CSS, and JS files

ghi9012 Add alert feature to app.js

def5678 Update style.css to change body background color

abc1234 Initial commit with basic HTML, CSS, and JS files

2. Commit 3’ü Geri Al (app.js Değişikliklerini Tersine Çevir)

Commit 3te yapılan değişiklikleri geri almak istiyorsun, yani alert özelliğini silmek istiyorsun.

git revert ghi9012

1	git revert ghi9012

Bu komut app.js dosyasındaki alert komutunu geri alacak ve bir tersine commit oluşturacak. Git otomatik olarak bir mesaj açar, buraya istersen bir açıklama ekleyebilirsin.

Yeni Oluşan Commit:

Revert "Add alert feature to app.js"
This reverts commit ghi9012.

1 2	Revert "Add alert feature to app.js" This reverts commit ghi9012.

Son Commit Durumu:

git log --oneline

1	git log --oneline

Çıktı:

jkl3456 Revert "Add alert feature to app.js"
ghi9012 Add alert feature to app.js
def5678 Update style.css to change body background color
abc1234 Initial commit with basic HTML, CSS, and JS files

jkl3456 Revert "Add alert feature to app.js"

ghi9012 Add alert feature to app.js

def5678 Update style.css to change body background color

abc1234 Initial commit with basic HTML, CSS, and JS files

Yeni Commit ile Dosyalar:

app.js:

console.log('Welcome to My Project');
// alert('Welcome to My Project'); // Bu satır geri alındı

1 2	console.log('Welcome to My Project'); // alert('Welcome to My Project'); // Bu satır geri alındı

Bu geri alma işlemi, projenin önceki durumunu etkilemeden app.js dosyasını tersine çevirdi. Böylece commit geçmişinde geri alınan commit’in de kaydı bulunur.

3. git revert Sonrası Durum

Son commit’te ghi9012 numaralı commit’te yapılan değişiklikler (app.js dosyasına eklenen alert) geri alınmıştır. Bu, git revert komutunun bir commit’i tersine çevirdiği, ancak bu işlemi bir yeni commit ile yaptığı anlamına gelir.

Özet:

Başlangıç commit’leri: Projeye HTML, CSS ve JS dosyaları eklenmiş.
Commit 2: style.css dosyasında arka plan rengi değişmiş.
Commit 3: app.js dosyasına alert özelliği eklenmiş.
Geri alma işlemi: git revert ghi9012 komutu ile app.js dosyasındaki alert komutu geri alındı.

Bu senaryo, gerçek dosyalar ve commit’lerle git revert’ün nasıl çalıştığını açıkça gösterir.

Peki biz burada neden son commiti silmedik. ?

Bu senaryoda son commit’i silmedik çünkü git revert ile yapılan işlem commit’i tarihçeden silmek değil, commit’in getirdiği değişiklikleri tersine çevirmek ve bunları yeni bir commit olarak kaydetmek.

git revert kullanarak son commit’i silmek yerine geri almanın birkaç önemli sebebi vardır:

1. Tarihçeyi Korumak

git revert komutu, commit geçmişinde yapılan her değişikliği kayıt altında tutar. Yani, yanlış bir işlem yapılmış olsa bile bu işlem tamamen kaybolmaz, sadece geri alınır.
Özellikle paylaşılan dallarda (örneğin, main ya da develop dalında), geçmişi değiştirmek diğer ekip üyelerine sorun çıkarabilir. Eğer commit’leri silersen ve diğerleri de bu commit’leri çektiyse (pull), tarihçe tutarsız olabilir. Bu yüzden git revert kullanarak geçmişi koruyup, aynı zamanda değişiklikleri geri alabilirsin.

2. Geri Alma Kolaylığı

git revert, bir commit’teki değişiklikleri güvenli bir şekilde geri almak için kullanılır. Bu işlem sırasında yeni bir commit oluşturur ve bu commit, tersine çevrilen değişiklikleri içerir. Böylece, o commit’in etkileri projenin son haline uygulanmış olur, ancak commit geçmişi olduğu gibi kalır.

3. Commit’i Silmeden Tersine Çevirmek

Commit’i silmek yerine tersine çevirmek, özellikle hatalı bir commit’in neden olduğu sorunları düzeltmek için tercih edilir. Bu sayede commit geçmişiyle ilgili bir sorun yaşanmaz, sadece hatalı değişiklikler düzeltilmiş olur.

Commit’i Gerçekten Silmek İstiyorsan: git reset

Eğer commit’i tamamen silmek isteseydik, git reset komutunu kullanırdık. git reset ile commit’ler silinebilir veya staging area’ya geri alınabilir. Ancak bu yöntem geçmişi değiştirdiği için, özellikle paylaşılan dallarda kullanırken dikkatli olunmalıdır.

Son Commit’i Silmek İçin:

git reset --hard HEAD~1

1	git reset --hard HEAD~1

–hard: Hem commit’i hem de dosya değişikliklerini tamamen siler (geri alınamaz hale getirir).
HEAD~1: Bir önceki commit’e dönmek anlamına gelir. Yani, son commit silinir ve HEAD bir önceki commit’e işaret eder.

Not: Bu komut, commit’leri tamamen siler. Eğer başka kişiler bu commit’i kendi sistemlerine çektiyse (pull), geçmişte tutarsızlıklar ve sorunlar yaşanabilir.

Kısaca Özetlersek:

git revert, commit’leri silmez, ancak commit’in getirdiği değişiklikleri tersine çeviren yeni bir commit oluşturur. Bu yöntem commit geçmişini değiştirmediği için güvenlidir.
git reset ile commit’ler tamamen silinebilir. Ancak bu işlem commit geçmişini değiştirdiği için dikkatli kullanılmalıdır.

git revert, özellikle işbirliği yapılan projelerde ve önemli dallarda (örn. main dalı) güvenli bir geri alma işlemidir çünkü commit geçmişini bozmadan tersine çevirme yapar.

Örnek Senaryo – Commitler arası geçiş – Git Checkout

git checkout <commit-hash> komutuyla bir önceki commit’e (örneğin git checkout abc1234) döndüğünde son commit silinmez. Git’te bu işlem, sadece çalışma dizinini ve HEAD pointer’ını geçici olarak o commit’in durumuna getirir. Bu duruma detached HEAD denir, yani bir dal üzerinde çalışmazsın, ama mevcut commit geçmişine dokunulmaz ve son commit kaybolmaz.

Neler Olur?

•Son commit ve commit geçmişin silinmez veya değişmez. Sadece çalışma dizinini, checkout yaptığın commit’in olduğu duruma getirirsin.

•Bu süreçte dosyalarını ve kodlarını inceleyebilirsin, hatta o commit üzerinde çalışmaya devam edebilirsin. Ancak o anda bir dalda değilsindir (detached HEAD).

•Değişiklik yapar ve commit edersen, bu commit şu anki dallarla ilişkili olmaz ve Git geçmişine yeni bir commit eklemiş olursun, ama başka bir dal üzerinde değil.

Örnek Senaryo:

1. Son commit’e bak: git log ile commit geçmişini inceleyebilirsin. Farz edelim şu an 3 commit’in var:

Commit def5678 (Son commit)
Commit abc1234
Commit 789xyz

Commit def5678 (Son commit)

Commit abc1234

Commit 789xyz

2. Commitler arası geçiş: Şimdi abc1234 commit’ine geçmek istiyorsun:

git checkout abc1234

1	git checkout abc1234

• Bu komut seni abc1234 commit’inin olduğu duruma getirir, ama son commit olan def5678 olduğu yerde durur.

3. Geçiş sonrası: Eğer git log komutunu tekrar çalıştırırsan, commit geçmişini hâlâ görebilirsin ve def5678 commit’i silinmez.

4. Dalına geri dönmek: Eğer o commit’i inceledikten sonra tekrar son commit’ine dönmek istiyorsan, mevcut dalına geri dönebilirsin:

git checkout main  # veya çalıştığın başka bir dal varsa onun ismi

1	git checkout main # veya çalıştığın başka bir dal varsa onun ismi

Ya da git switch main komutunu kullanarak tekrar ana dala dönebilirsin. O anda son commit’ini kaybetmeden normal şekilde çalışmaya devam edebilirsin.

Sonuç:

•git checkout <commit-hash> komutunu kullanmak commit’leri silmez. Sadece geçici olarak eski bir commit’e dönersin.

•Dalına geri döndüğünde, son commit de dahil olmak üzere commit geçmişi kaldığı yerden devam eder.

Boş bir commit oluşturmak için:

git commit --allow-empty -m "Commit mesajı"

1	git commit --allow-empty -m "Commit mesajı"

--allow-empty: Staging area’da değişiklik olmasa bile boş bir commit yapmanı sağlar.
Kullanım Alanları: Proje güncellemeleri, CI/CD işlemlerini tetikleme, veya önemli olayları işaretleme için kullanılır.

Örnek Senaryo – Dallanma – Git Branch

git branch, Git’te bir dallanma (branch) yapısı oluşturmanı ve projede farklı yönlerde ilerlemeni sağlayan bir komuttur. Bir dal (branch), bir projede belirli bir noktadan başlayıp farklı değişiklikler üzerinde çalışmanı sağlar ve bu dalları birleştirerek (merge) projeye dahil edebilirsin. Dallar, büyük projelerde farklı özellikler (features), düzeltmeler (bugfixes), veya sürümler (releases) üzerinde aynı anda çalışmayı kolaylaştırır.

git branch Komutunun Kullanımı

Temel anlamda, git branch komutu mevcut dalları listelemek, yeni bir dal oluşturmak, dalları silmek ve dallar arasında geçiş yapmak için kullanılır.

Senaryolarla git branch Kullanımı

Senaryo 1: Yeni Bir Dal (Branch) Oluşturmak

Projede yeni bir özellik geliştirmek istiyorsun ve bunu ana projeden bağımsız olarak yapmak istiyorsun. Bunun için bir dal oluşturabilirsin.

Adımlar:

1. Mevcut dalları kontrol et:

git branch

1	git branch

Çıktı:

* main

* main

Şu an main dalındasın.

2. Yeni bir dal oluştur:

git branch new-feature

1	git branch new-feature

3. Yeni dala geçiş yap:

git checkout new-feature

1	git checkout new-feature

Artık yeni dala geçtin ve buradaki değişiklikler main dalından bağımsız olacak.

Senaryo 2: Yeni Bir Dalda Çalışıp Değişiklikleri Ana Dala (main) Birleştirmek

Bir özellik üzerinde çalışıyorsun ve bu değişiklikleri main dalına eklemek istiyorsun.

Adımlar:

1. Yeni bir dal oluştur ve o dala geç:

git checkout -b feature-login

1	git checkout -b feature-login

Bu komut hem yeni dal oluşturur hem de o dala geçiş yapar. Şimdi bu dalda bir login özelliği eklediğini düşünelim.

2. Değişiklikleri yap ve commit et:

git add .
git commit -m "Add login feature"

1 2	git add . git commit -m "Add login feature"

3. Ana dala (main) geç:

git checkout main

1	git checkout main

4. Yeni dalı ana dala birleştir:

git merge feature-login

1	git merge feature-login

Bu adım, feature-login dalındaki tüm değişiklikleri main dalına ekler. Eğer çatışma (conflict) yoksa, birleştirme işlemi otomatik olarak tamamlanır.

Senaryo 3: Hotfix İçin Yeni Bir Dal Kullanmak

Canlıda olan bir projede bir hata fark ettin. Bu hatayı düzeltmek için main dalından bir hotfix dalı oluşturabilirsin.

Adımlar:

1. Ana dalda olduğunu doğrula:

git checkout main

1	git checkout main

2. Hotfix için yeni bir dal oluştur ve o dala geç:

git checkout -b hotfix-issue-123

1	git checkout -b hotfix-issue-123

3. Hata düzeltmelerini yap ve commit et:

git add .
git commit -m "Fix issue #123: Correct login bug"

1 2	git add . git commit -m "Fix issue #123: Correct login bug"

4. Düzeltmeleri ana dala birleştir:

git checkout main
git merge hotfix-issue-123

1 2	git checkout main git merge hotfix-issue-123

5. Hotfix dalını sil:

Düzeltme işini bitirdiğin için artık bu dala ihtiyacın kalmadı. Düzeltmeyi ana dala birleştirdikten sonra bu geçici dalı silebilirsin.

git branch -d hotfix-issue-123

1	git branch -d hotfix-issue-123

Senaryo 4: Uzaktaki Bir Daldan Çalışmak

Bir ekip üyesi uzaktaki Git sunucusunda (örneğin, GitHub) yeni bir dal oluşturdu ve bu dal üzerinde çalışmanı istiyor. Bu durumda o dala geçebilirsin.

Adımlar:

1. Uzaktaki dalları kontrol et:

git fetch
git branch -r

1 2	git fetch git branch -r

Çıktı:

origin/feature-login
origin/main

1 2	origin/feature-login origin/main

Burada uzaktaki dallar listelenir.

2. Uzaktaki dala geçiş yap:

git checkout -b feature-login origin/feature-login

1	git checkout -b feature-login origin/feature-login

Bu komut, uzaktaki dalın bir kopyasını yerel makinenize getirir ve o dala geçer.

Senaryo 5: Bir Dalı Silmek

İşin bittiği bir dalı artık gereksiz buluyorsan, bu dalı silebilirsin.

Adımlar:

1. Mevcut dalları listele:

git branch

1	git branch

Çıktı:

* main
feature-login

1 2	* main feature-login

2. Bir dalı sil:

git branch -d feature-login

1	git branch -d feature-login

Eğer bu dal başka dallara birleştirilmeden silinmeye çalışılırsa, Git uyarı verir. Eğer zorla silmek istersen:

git branch -D feature-login

1	git branch -D feature-login

Senaryo 6: Geçici Bir Dal Kullanmak

Karmaşık bir proje üzerinde çalışıyorsun ve geçici olarak bir şey denemek istiyorsun. Ancak bu deneme işleminin ana dala etki etmesini istemiyorsun.

Adımlar:

1. Geçici bir dal oluştur ve o dala geç:

git checkout -b temp-experiment

1	git checkout -b temp-experiment

2. Deneme yap ve commit et:

Bu dalda değişiklikler yapabilir, commit edebilirsin. Ancak sonuçları beğenmezsen, o dalı silebilirsin.

3. Ana dala geri dön ve deneme dalını sil:

git checkout main
git branch -D temp-experiment

1 2	git checkout main git branch -D temp-experiment

Bu işlem, temp-experiment dalını tamamen siler. Yaptığın denemeler ana dalı etkilemez.

Eğer son commit değil de belli bir committen dal oluşturmak isterseniz aşadaki komutu kullanabilirsiniz. abc1234 commit id ifade eder.

git branch feature-branch abc1234

1	git branch feature-branch abc1234

Özetle git branch:

git branch, projende dallar oluşturarak paralel bir şekilde çalışmanı sağlar.
Her dal, ana projeden bağımsız olarak değişiklikler yapmana ve bu değişiklikleri daha sonra ana dala sorunsuzca eklemene olanak tanır.
Projende farklı özellikler, hata düzeltmeleri veya deneysel çalışmalar yaparken dalları kullanmak, hem organize olmanı sağlar hem de riskli değişikliklerden projeyi korur.

Örnek Senaryo – Dalları Birleştirme – Git Merge

git merge, Git’te iki dalı birleştirmek için kullanılan bir komuttur. Bu işlem, bir dalda yapılan değişikliklerin diğer bir dala eklenmesini sağlar. Genellikle, bir özelliğin (feature) tamamlanmasından sonra, bu özelliğin ana dala (main/master) eklenmesi için kullanılır. git merge, iki farklı dalı birleştirirken commit geçmişini koruyarak çalışır.

git merge Senaryoları ve Kullanım Alanları

1. Feature Branch’leri Ana Dala Birleştirmek

Bu, en yaygın kullanım senaryosudur. Bir dalda yeni bir özellik geliştiriyorsundur ve bu özellik tamamlandığında, bu değişiklikleri ana dala (main) birleştirmek istersin.

Adımlar:

1.Yeni bir özellik geliştirmek için bir dal oluşturdun:

git checkout -b feature-login

1	git checkout -b feature-login

2.Bu dalda değişiklikler yaptın ve commit ettin:

git add .
git commit -m "Add login feature"

1 2	git add . git commit -m "Add login feature"

3.Özelliği bitirdikten sonra ana dala (main) geçersin:

git checkout main

1	git checkout main

4.Değişiklikleri ana dala birleştirirsin:

git merge feature-login

1	git merge feature-login

5. Eğer çatışma (conflict) yoksa, feature-login dalındaki tüm değişiklikler main dalına eklenir. Eğer çatışma varsa, Git sana bu çatışmaları çözmen gerektiğini söyler.

2. Bir Özelliğin Diğer Bir Özellik Dallarıyla Birleştirilmesi

Projede iki ayrı özellik geliştiriyorsun ve bu özelliklerin birbirleriyle uyumlu çalışıp çalışmadığını görmek istiyorsun. Bu durumda, bir özelliği diğerine birleştirerek test edebilirsin.

Adımlar:

1.İki özellik dalı olduğunu düşünelim: feature-login ve feature-payment.

2.Birinci özelliği diğer özellik dalına birleştirmek için, feature-payment dalına geç:

git checkout feature-payment

1	git checkout feature-payment

3. feature-login dalını bu dala birleştir:

git merge feature-login

1	git merge feature-login

Bu adım, iki dalın birleşmesini sağlar ve birleştirilmiş halde çalışmaları test edebilirsin.

Özetle git merge:

git merge iki dalı birleştirmek için kullanılır ve bu işlem sırasında dallar arasında değişiklikler eklenir.
Genellikle özellik dallarını (feature branches) ana projeye dahil etmek için kullanılır.

GitHub Repository’sini Belirleyin: GitHub’daki repository’nin URL’sini belirtin.

Örnek Senaryo – Daldan dala commit kopyalama – Git Cherry-pick

git cherry-pick, bir Git komutudur ve bir commit’i bir branch’ten alıp başka bir branch’e eklemenize olanak tanır. Bu, belirli commit’lerin başka bir branch’e aktarılmasına ihtiyaç duyulduğunda kullanışlıdır.

git cherry-pick Ne Yapar?

Genel olarak, bir branch’teki belirli commit’i seçip (cherry-pick) o commit’i başka bir branch’e uygular. Özellikle başka branch’lerde bulunan ve yararlı olan küçük değişiklikleri ya da hata düzeltmelerini mevcut branch’inize almanız gerektiğinde kullanılır.

Kullanım Senaryosu

Diyelim ki bir proje üzerinde iki farklı branch’te çalışıyorsunuz: feature-branch ve main. feature-branch üzerinde bir hata düzeltmesi yaptınız, ancak bu hata düzeltmesini hemen main branch’ine de aktarmanız gerekiyor, ancak diğer tüm değişiklikleri değil, sadece bu küçük düzeltmeyi.

Adımlar:

1. Önce feature-branch üzerinde bir commit yaptığınızı varsayalım:

git checkout feature-branch
git commit -m "Küçük hata düzeltmesi"

1 2	git checkout feature-branch git commit -m "Küçük hata düzeltmesi"

2. Bu commit’i main branch’ine almak için:

git checkout feature-branch
git commit -m "Küçük hata düzeltmesi"

1 2	git checkout feature-branch git commit -m "Küçük hata düzeltmesi"

<commit-hash>, almak istediğiniz commit’in hash kodudur (örneğin: abc1234). Bu komut, sadece seçili commit’i main branch’ine ekler, diğer commit’leri almaz.

Ne Zaman Kullanılır?

•Hızlı bir hata düzeltmesini mevcut branch’e aktarmanız gerektiğinde.

•Başka bir branch’teki belirli bir özelliği, diğer tüm değişiklikleri almadan mevcut branch’e eklemek istediğinizde.

•Bir geliştirme süreci sırasında belirli bir commit’i başka bir feature branch’e uygulamak istediğinizde.

Bu sayede, branch’ler arası tam merge yapmadan sadece ihtiyaç duyduğunuz değişiklikleri aktarabilirsiniz.

Örnek Senaryo – Remote Repository – Git Remote

git remote add origin <repository_url>

1	git remote add origin <repository_url>

Burada <repository_url> kısmına GitHub’da oluşturduğunuz repository’nin URL’sini eklemeniz gerekiyor. Ayrıca, main yerine kullandığınız ana dal ismini kullanmalısınız; GitHub’da varsayılan olarak genellikle main veya master olarak adlandırılır.

Değişiklikleri Yükleyin: Yerelde yaptığınız değişiklikleri GitHub’a yükleyin.

git push -u origin main

1	git push -u origin main

Eğer Githubda repo oluştururken uzakta bir README.md dosyası oluşturursanız direkt yukardaki komutu kullandığınızda hata alabilirsiniz.

İlk senaryoda, GitHub’da yeni bir repo oluştururken “Add a README.md” seçeneğini seçtiğinde, GitHub senin için bir README.md dosyası oluşturur ve ilk commit’i gerçekleştirir. Bu yüzden, sen de aynı repo’ya yerel bilgisayarından push etmek istediğinde, iki farklı commit geçmişi oluşmuş olur:

•Yerel bilgisayarındaki commitler: Kendi bilgisayarındaki repository’yi ilk defa push ediyorsun.

•GitHub’daki commit: GitHub senin yerelindeki repository’den önce bir commit yapmış oluyor (README.md dosyasını ekleyerek).

Bu iki commit geçmişi uyuşmadığından dolayı push işlemi başarısız olur. Git, yereldeki ve GitHub’daki commit’lerin aynı olmasını ister.

Çözüm:

•git pull origin main komutunu kullanarak GitHub’daki değişiklikleri (README.md’yi) yerel repository’ne çekmen (pull) gerekir.

•Ardından git push origin main komutuyla push işlemini tekrarlayabilirsin.

Evet, tabii ki! git push -u origin main komutu, yerelde yaptığınız commitleri uzaktaki bir depoya (genellikle GitHub gibi) göndermek için kullanılır. Bu komutun detayları şu şekildedir:

git push: Yereldeki değişiklikleri uzak bir depoya göndermek için kullanılan temel git komutudur.
-u origin main: Bu bölümde kullanılan bayraklar ve ifadeler şunlardır:
- -u: “upstream” anlamına gelir. Bu, yereldeki branch’i uzaktaki bir branch ile eşleştirmek için kullanılır. Ayrıca, bir sonraki git push komutlarında sadece git push şeklinde kullanmanıza olanak tanır.
- origin: Uzaktaki depoya atıfta bulunulan bir kısaltmadır. Genellikle, projenin orijinal halini saklayan uzak depoya atıfta bulunmak için “origin” kullanılır. Bu ismi projeyi klonlarken varsayılan olarak alırsınız.
- main: Yereldeki branch’in adıdır. Eğer kullandığınız Git sürümü 2.28 ve üzeriyse, “main” adı genellikle varsayılan ana dal adıdır. Daha eski sürümlerde ise “master” adı daha yaygındır.

Bu komut, yereldeki değişiklikleri “main” adlı yerel dalınızı takip eden uzak depodaki “main” dala gönderir. İlk kez git push -u origin main komutunu kullanıyorsanız, Git sizden kullanıcı adı ve şifrenizi girmenizi isteyebilir.

Yeni bir dosya ekleme işleminden sonra ne yapmalıyım. ?

Yeni bir dosya ekledikten sonra, bu dosyayı Git’e ekleyerek ve bir commit yaparak değişiklikleri kaydetmeniz gerekiyor. Ardından, bu değişiklikleri uzak depoya (örneğin, GitHub’a) göndermek için git push komutunu kullanabilirsiniz. İşte adım adım yapmanız gerekenler:

Yeni Dosyayı Ekleyin: Önce, yeni oluşturduğunuz dosyayı Git’e ekleyin. Eğer sadece bu yeni dosyayı ekleyecekseniz:

git add yeni_dosya.txt

1	git add yeni_dosya.txt

Eğer tüm dosyaları eklemek istiyorsanız:

git add .

git add .

Commit Yapın: Eklediğiniz dosyayı bir commit yaparak kaydedin. Commit mesajınız, yaptığınız değişikliği açıklamalıdır:

git commit -m "Yeni dosya ekledim"

1	git commit -m "Yeni dosya ekledim"

GitHub Repo’ya Push Edin: Yaptığınız commit’i uzak depoya göndermek için:

git push

git push

Eğer daha önce -u origin main ile branch’i uzak depoya takip ettiyseniz, sonraki push’larınızda sadece git push komutunu kullanabilirsiniz.

Eğer mevcut bir Git depo klasörünüzdeki tüm geçmişi ve değişiklikleri temizlemek istiyorsanız, aşağıdaki adımları takip edebilirsiniz:

Mevcut Değişiklikleri İptal Etme: Eğer mevcut çalışma dizinizde değişiklikler varsa, bunları iptal edin.

git reset --hard

1	git reset --hard

Bu komut, mevcut branch’teki son commit’e geri döner ve tüm değişiklikleri iptal eder.

Mevcut Geçmişi Temizleme:

git clean -fdX

1	git clean -fdX

Uzaktaki Bağlantıyı Kaldırma (Opsiyonel):

git remote remove origin

1	git remote remove origin

Bu komut, uzak depo bağlantısını kaldırır.

Uzaktaki Dalları Listeleme :

git branch -r

1	git branch -r

Bu çıktıda, origin uzak deposundaki dallar listelenir. Bu dallar, yerel bilgisayarınızda değil, uzak depoda mevcut olan dallardır.

Git ile İlgili Dosyaları Silme:

Klasörün içindeki tüm Git ile ilişkili dosyaları silebilirsiniz. Aşağıdaki komutlarla bu işlemi gerçekleştirebilirsiniz:

rm -rf .git/

1	rm -rf .git/

Eğer uzaktaki sunucudaki bir değişikliği locale çekmek istersek:

git pull origin main

1	git pull origin main

Kaynak: Bilgi desteği için ChatGPT, OpenAI tarafından sağlanan yapay zeka tabanlı asistan.

Git ve Github Ayrıntılı Kullanım Rehberi