5 min readMar 5, 2022
- Yazdığımız kodlar kullandığımız cihaz tekelinde kalmasın istediğimizde işe yarar.
- git init projenin versiyon kontrol sisteminde hayata geçirilebilmesi için gerekli komuttur. ilk başlangıçta kullanılır.
- işletim sistemleri değiştiği için projelerin bu OS lerin tamamında çalıştırılabilmesi ve ortak işlemler gerçekleştirilebilmesi için GIT ortaya çıkmıştır. GIT tüm işletim sistemlerindeki çoğu komutu taklit edebilmektedir.
- git commit işlemi ile snapshot (anlık görüntü) yaptığımız versiyona dönebiliriz, hataları böylece daha kolay yönetebiliriz.
- versiyonlanmasını istemediğimiz bir proje, dosya varsa .gitignore içinde belirtebiliriz.
- git ile versiyonlamada git diff dersem en sonki git commit ile snapshot edilmiş durumdan şimdiye kadar ki tüm değişiklikleri gösterir.
- git commit edilen dosyaya “ “ tırnak içinde açıklayıcı bir mesaj eklemek gerekir çünkü sonra unutabiliriz.
- commit lenmeye hazır dosyaya staged denir.
- git checkout komutu branch ler ve commit ler arası geçiş yapmak için kullanılır.
- A: added, U: untracked, M: modified
- her commit benzersiz unique bir ID’ye sahip olur.
- değişmeyecek olan dosyaların versiyon kontrol sistemi içine girmesine gerek yok. o nedenle .gitignore dosyasını kullanıyoruz.
- master branch projenin canlıya alınacak halinin çalıştırıldığı kısım.
- product, development, hotfix, feature, release gibi diğer branch isimleri verilebilir.
- commit işlemi yapılmadan git push komutunu kullanırsak hiçbir hata ile karşılaşmayız ama dosyalarımız aktarılmaz.
- README.md mark down dosyası(md).
- git config -list(çift tire olacak)
- git add . (all)
- git commit -m “açıklama”
- git status
- git diff
- git log -all (çift tire olacak)
- git checkout branchName
- git checkout commitID
- git push
- git pull
- git clone
- versiyon kontrol sistemine yapılan değişikliği göndermek için izlenen yol git add README.md →git commit -m “mesaj” →git push
- Git-1 (Mustafa’dan)
- git config — global user.name “your name here”
- git config — global user.email “your email here”
- git config — global core.editor “nano”
- yukaridaki 3 satiri yazarak Git’e kendimizi tanitiriz
- git config — list: yukaridakilerin uygulanip uygulanmadigini anlamaya yarar bu komut
- bir klasor icindeyken git init yazarak o klasoru Git repository’ye acariz
- ne yapacagimizi bilmedigimiz zaman git help yazabiliriz. mesela init komutunun ne yaptigini bilmiyorsak git init — help yazariz
- git status ise hangi branch icinde oldugumuzu ve commit’lerle alakali bilgi verir
- git clone vebirgithubcodelinki ile github’dan kendi lokal repomuza bir klasor klonlayabiliriz.
- we have three stages in Git: Working Directory, Staging Area(Index), Repository
- Working Directory: where you create/edit/delete files
- Staging Area: before taking a snapshot, you’re taking the files to a stage
- Repository: where the committed snapshot of the project will be stored
- so if we add a file to our repository and edit the file and later check its status with git status command, we’d read ‘untracked files’ on the screen with our file in red. this means our file is not added to the staging area yet. we can add the file to staging area as follows:
- git add filename: this command adds our file to staging area. file will turn green on status after adding it to staging area
- git rm — cached filename: this command unstages your file
- git commit -m “comment here”: this command commits your file with a comment. use git commit -am “comment here” to add and commit all tracked files.
- git commit — amend: bu komut ile daha once girmis oldugumiz commit yorumunu degistirebiliriz
- git log: bu komut ile dosya log detaylarimizi gorebiliriz. git log — all ise tum log’larimizi gosterir
- git checkout idnumber: git log yazdigimizda head master’imizin en son versiyon uzerinde oldugunu goruruz. eger bir sebepten dolayi daha onceki versiyonlar uzerine donmek istersek git log yazdigimizda o versiyon uzerinde cikan commit kodunun ilk 5 hanesini ya da tumunu git checkout komutuna ekleyerek kosturabiliriz
Git-2
- git status’ta dosyamiz kirmizi ise working directory’dedir. bunu yesile cevirmek icin (staging alanina almak icin) klasordeyken git add . deriz
- git commit -m “feat: file1.txt file was added to repo”
- git log ile kayit versiyonlarimiza ulasabiliriz
- git commit — amend changes the message of commit
- git log — all ile butun git log’larimizi gorebiliriz
- git branch BranchName creates a new branch
- git branch local branch’leri gosterir
- git branch -r ile remote branch’lerimizi gorebiliriz
- git branch -a ile tum branch’lerimizi gorebiliriz
- git checkout BranchName komutu ile uzerinde bulundugumuz branch’i degistirebiliriz. mesela iki tane branch’imiz oldugunu varsayalim (main ve dev), hangi branch uzerinde bulundugumuzu git branch yazip hangi branch’in yesil olduguna bakarak anlayabiliriz. diyelim ki mail branch yesil idi. o zaman dev branch’e gecmek icin git checkout dev yazariz
- git checkout -b BranchName ile hem ‘BranchName’ olustururuz hem de o branch’e gireriz (checkout). yani uzunca git branch deneme_branch && git checkout deneme_branch yazmaktansa git checkout -b deneme_branch yazmak daha pratiktir.
- git branch -d BranchName ile ‘branch name’ silinir
- git merge BranchName: merge, bir Branch’in islemlerini baska branch’e aktarmaya denir. mesela diyelim ki yeni_branch isimli branch’imiz uzerindeyken bir degisiklik yaptik ve bunu main branch’e de yansitmak istiyoruz, o zaman yapmamiz gereken sey once git checkout main ile main branch’in uzerine gitmek ve oradayken git merge yeni_branch komutunu kosmaktir
- git log — all — graph: bu komutla log girdilerimizi tree komutuna benzer sekilde, yani daha okunakli olarak gorebiliriz. bu, ozellikle bircok branch actigimiz zamanlarda branch’leri daha net gormemizi saglar.
- Varsayalim ki a ve b adinda iki branch’imiz var ve biz ayni dosyayi © hem a’da hem de b’de farkli sekillerde editledik. Ve isin sonunda c dosyasini b branch’inde editledigimiz sekliyle a’ya merge etmeye calistigimizda conflict uyarisi aldik. c dosyasinin icine girdigimizde gorecegiz ki hem a hem de b’nin ne sekilde edit yaptigi yaziyor. Bizim yapmamiz gereken sey editor ile bu dosyaya girip dosyayi nihai haliyle editleyip (a’nin yaptigi sekilde istiyorsak, b’nin yaptiklarini silmek, ya da vice versa) tekrardan add ve commit yapmaktir. Ayriyeten, commit yorumu olarak da hangi branch’in edit’ine uygun olarak kaydettigimizi yazmak mantikli olur
- Iki tip merge ciktisi vardir: 3-way merge ve fast-forward.
- Conflict hatasi 3-way merge’i yaptigimizdan dolayi gerceklesir genelde. Yani, mesela main’den ayri olarak iki branch’in ayni dosya uzerinde calismasi ve dosyayi main’e merge etmeye calismalarindan kaynaklanan conflict durumlari 3-way merge’dir
- Bir de basit editlemeler icin tek branch acip dosyayi editleyip, conflictsiz sekilde main’e merge etme durumlari vardir ki bu tip merge’ler merge isleminin hatasiz sekilde gerceklestigini bildirir nitelikte fast- forward ciktisi verir.
github/settings/developer settings/generate new token ile süreli yetkilendirme yapılabiliyor. yetkilendirme seçenekleri de belirlenebiliyor.
Yeni açtığımız branch te yaptığımız değişiklikler commit etmeden branch değiştirirsek bizimle birlikte geliyorlar. Bu gibi durumlar için “git stash” komutu var. Bu komut, yaptığımız değişiklikleri git içinde saklamamızı sağlıyor ve değişiklikler bizimle gelmiyor. Sakladıklarımızı geri almak için de “git stash pop” komutunu çalıştırıyoruz.
pull = fetch + merge (mantık)
git log — oneline (logların sade gösterimi)
ATTENTION : her zaman proje üzerinde çalışırken ilk yapılacak işlemler → önce yeni bir branch aç →sonra pull request ile son durumu al → çalışmayı yaptıktan sonra add ve commit işlemlerinin ardından → master branch ına geç → yan branch ı master a git merge ……branch koduyla merge et → git push ve canlıya çık
