ısı konusunda da tecrübelerimi yazayım; Disco elisyum'u high yada medium'da test etmiştim m1 desteği var oyunda, gayet güzel oynayabildim ama işlemci 85+ derecelerde geziyordu ve kasa harbiden ısındığını hissettiriyordu, böylesi ısınmayı 4k x264 videoyu handbrake ile 4k x265'e çevirirken de gördüm fakat o zaman handbrake'in m1 desteği yoktu sanırsam. Onun haricinde imovie'den video editledim yine 4k'ydı o kadar ısınmamıştı, davinci resolve'de yine 4k ortalama 100e yakın küçük videoyu birleştirip düzenlerken yine kasa alev atmıştı 🙂 Oyun ve ağır video işlerine girilmeyecekse ısınmıyor ama bunlara bulaşınca harbiden alüminyum kasa sıcaklığı fena hissettiriyor.

Markdown olarak kaydedip okursan daha okunaklı olur senin için;

# GİT KULLANIMI
## Genel Şeyler

> yerel deponuz git tarafından yönetilen üç "ağaçtan" oluşur.
birincisi gerçek dosyaları tutan Çalışma Dizini.
ikinci etap Stage ve sonuncusu yaptığınız son commit'i gösteren HEAD.
Aslında bu komutların hepsi birer graph manipülasyon'dur(çizgi üzerinde yaptığımız değişiklik hareketleri).

1. git init >> yeni bir depo oluşturmak için, bir klasör oluşturup içerisinde komutu çalıştır
2. git add >> Değişiklikleri belirtmek (Index'e eklemek) için ("git add ." . eklenirse bütün dosyaları ekle anlamına gelir)
3. git commit -m "Teslim mesajı" >> Değişiklikleri depoya eklemek için Şimdi dosyalar HEAD'e eklendi
4. git status >> en son yapılan kayıttan (commit) sonra yapılan değişiklikleri gösterir
5. git commit -am "Teslim mesajı" >> Burada ek olarak kullandığımız a harfi kayıt işlemini yaparken bütün değişikliğe uğramış dosyaları da kayıta ekleyecektir.
6. git diff >> kaydedilmeyen değişikliklerin (eklenen ve çıkarılan satırların) ne olduğunu görebilirsiniz
7. git push origin master >> Şimdi değişiklikleriniz yerel deponuzun HEAD'i içerisinde. Bu değişiklikleri uzak depomuzun master branch'ine göndermek için kullanırız
8. git pull >> en son değişiklikleri (commit) yerel deponuza almak için(fetch+merge işlemi yapar)
10. git log >> İşlem kimlik numaralarını görmek için
11. git branch blabla >> yeni bir branch
12. git checkout blabla >> blabla branch'ine geçtim
13. git merge blabla >> masterdeyden dersem, masterla blabla mergelenir. merge conflit(çakışma) 3 yönlüdür a - b - ve ikisinin ortak atası olan son commit
14. git branch -d blabla >> branch'ı sildik eğer daha önce merge olduysa sadece tag'i silinir, olmadıysa erişilemez hale gelir.
15. git rebase master >> aşağıda açıklaması var
16. git reflog >> local'de tüm head'ın haraketlerini loglar
17. git cherry-pick Birinci İkinci Üçüncü .... >> Git'de kod cımbızlamak(detaylı açıklama aşağıda.)
18. git reset HEAD~2 >> Head'ın bulunduğu commit'ten 2 commit öncesine git demiş oluyoruz. (detaylı açıklama aşağıda.)
19. git rm dosya >> file'ları commit'ten ve local'den silmek için. (detaylı açıklama aşağıda.)
20. git rm-cached dosya >> file'ları commit'ten local'de bırakarak silmek için.
21. git fetch >> Repo'dan değişiklik bilgisini local'e çeker(kaynak dosyalarda değişiklik yapmaz!)
22. git tag tag_ismi id >> tag'ler sabit etiketlerdir, o an içinde bulunduğumuz commit'e yapışır (haraket ettiremeyiz sadece silebiliriz.) versiyonlamada kullanabiliriz.
23. git revert id >> commit ettiğiniz herhangi bir değişikliği geri almak için kullanılır (commit oluşturarak yapar!)
---
## Merge İşlemi

**Merge işleminin 2 tipi vardır**
1. Fast Forward Merge
2. NON Fast Forward Merge

Kodun commit graph'ı lineer ise(örneğin master banch geride kalmış blabla ilerlemiş ama farklılaşma olmamış yani
masterdeki tüm kodlar hala blabla brach'inde duruyor) işte o zaman git merge dediğimizde master branchini alır
blabla'ya taşır bu Fast Forward Merge'dir.

Eğer farklılaşma var ise(örneğin masterdeki bazı kodular blabla'da yok, blabla'dakiler master'de yok) bu iki
branch'i merge etmenin yolu NON Fast Forward Merge

---

## Rebase işlemi

Bir brach'in base'inin(ana başlangıç noktasının yönünü) değiştiriyor
rebase işleminin sonunda commit graph'ımız lineer'dir.
rebase şöyle çalışır; blabla branch'ımızdeki commit'lerden ilkini alır master branch'ının sonuna ekler
devamında gelen commit'leri de teker teker alıp bir önceki commit'in arkasına ekler.

Merge komutu ile A dalındaki değişiklikler B dalı ile birleştirildiğinde B dalının commit tarihçesinde
merge işleminden kaynaklanan ve merge commit adı verilen otomatik oluşturulmuş bir commit yer alır.
Bu commit A ve B dallarının tarihçelerini birbiri ile ilişkilendirir.

rebase komutu kullandığımızda ise ile A dalındaki her bir commit B dalına sanki commit işlemi
B dalında yapılmış gibi yeniden yazılır. Bu sayede B dalının commit tarihçesi sanki tüm değişiklikler
bu dalda olmuş gibi düz ve kesintisiz görünür.

---

>**Git'de kod kaybolmaz bir komut haricinde;**
bir branch'ten bir commit'e checkout olursak(checkout branch'e yapılır! tag'e de yapılmaz tag commit'e isim vermek gibi düşün)
kodlarımızı bu checkout içerisinde yazdık yazdık daha sonra sonra tekrar master veya başka bir branch'e checkout olursak
yazdığımız kodlar kaybolur(bu branch'te kodu yazıp yazıp merge etmeden silmeye benziyor) bu kodlar oradan silinmez ama
bizde göremeyiz. ve kaynak kodlar local'imizden silinir.

>**bunu çözmenin yolu;**
oraya bir branch açmaktır git branch blabla a45f3c(buraya o tag'i veya commit'in id'sini yazıyoruz) bu id'i bulmak
için git reflog kullanbiliriz.
*/

---

## Git'de kod cımbızlamak

örneğin blabla branch'inde ihtiyacımız olan 2 commit'i almak istiyoruz fakat blabla branch'inde 3 commit var
o 3'üncü commit'i almak istemiyoruz bunun için; git cherry-pick Birinci İkinci

---

## Git'de hatalardan geri dönüş

**git reset komutunun 3 çeşiti vardır**

> 1. örneğin git add . deyip herşeyi ekledik daha sonra git commit -m "eklendi" vb gibi birşey demiş olalım
git reset --soft dediğimizde commit objesi yokolur, yani git add . demişiz de commit etmemişiz gibi bi hale dönüşür.

> 2. yukarıdaki durumdayken git reset --mixed yaparsak yada doğrudan git reset dersek(default'u --mixed'tir)
hem commit'imiz kaybolur hemde onun ilgili cache'deki tanımı kaybolur(git add dediğimiz), commit'imizin
içeriği yeni değiştirilmiş, yeni eklenmiş gibiye dönüşür, kodumuz değiştirilmiş haline dönüşür(modified durumuna).

> 3. git reset --hard ise kaynak kodumuzdan da o değişikliği siler ve unmodified durumuna geri getirir bizi.
ne zaman hard reset yapılır; birşeyler deneyip commitlenmemiş değişikliği tamamen kaybetmek istediğimizde.
DİKKAT! KOD KAYBEDİLEBİLİR 🙂

> git rm komutu ise
örneğin commit'e yanlışlıka password.txt'yi attık, git rm password.txt dersek git'ten de filesystem'de
password.txt dosyasını sileriz, sonrada commit etmemiz gerekir.

>dosya localde kalsın ama git'ten sileyim dersek > git rm-cached

---

## Repoyu url'den ssh'a geçirmek

1. git remote -v -> repo url olarak mı ssh olarak mı bağlı localde

2. url ise ->
git remote set-url [email protected]:USERNAME/REPOSITORY.git

---