Yazılım Geliştirme

7’den 70’e Git Temelleri25 min read

25 Ocak 2019 13 min read

7’den 70’e Git Temelleri25 min read

Reading Time: 13 minutes

Şu an çalıştığım şirket olan OpenZeka, geçen sene olduğu gibi bu sene de mini otonom araç yarışması MARC’ı düzenliyor. 7 günlük çok geniş ve yoğun bir eğitim programı hazırlandı bunun için. Kontrol teorisi, Python temellerinden başlayıp nesne tespiti ve semantik segmentasyona kadar uzanan programın içerisinde doğal olarak git’i de anlatıyoruz. Bütün derslerle ilgili yaklaşık 1000 sayfalık bir döküman hazırlandı. Eğitimin git kısmını da ben hazırladım. Eğitime hem liseliler hem üniversiteliler hem de şirketler katılacağı için büyükleri sıkmayacak küçükleri caydırmayacak bir eğitim hazırlamaya çalıştım. Şimdi de o eğitimdeki materyallerden buraya bir derleme yaptım. Eklemer, çıkarmalar ve düzeltmeler yapmak isterseniz yorum bölümünden yapabilirsiniz 🙂

Dökümandaki bilgilerin hepsini tek seferde anlamayabilir veya aklınızda tutamayabilirsiniz. Bu çok normal. Terimler İngilizce olduğu için de karışık görünüyor olabilir. Kelimelerin Türkçe anlamları da yaptıkları işlerle alakalı, anlamlarını öğrenerek de aklınızda tutabilirsiniz. Yine de zamanla kullandıkça ve kendiniz kurcaladıkça mantığını anlayacak ve aklınızda tutacaksınız. Bu aşamaya gelene kadar unuttukça ve takıldıkça buradaki dökümandan veya orijinal git dökümanından faydalanabilirsiniz.

Konu Başlıkları

  • Versiyon Kontrol Sistemi Nedir? Ne İşe Yarar? Neden Kullanırız?
  • Git Nedir? GitHub, GitLab Nedir?
  • Git Kurulumu / SSH Key Ayarları
  • Bazı Terimler: Repo, Branch, Commit, Push, Origin, Conflict, Merge, Pull, Ignore, Clone, Fork
  • Repo Oluşturmak / Klonlamak
  • Commit Yapmak / Commit Pushlamak
  • Ignore Etmek
  • Reset İşlemi
  • Branchler
  • Conflictleri Çözmek
  • Fork / Pull Request
  • GUI ile Kullanım
  • Tavsiyeler / İyi Geliştirme Pratikleri
  • Cheatsheet
  • Sorun Yaşadığınızda Başvurabileceğiniz Kaynaklar

Versiyon Kontrol Sistemi Nedir? Ne İşe Yarar? Neden Kullanırız?

Eski Yaklaşım

Eskiden kod yazarken yazdığımız kodları canlı sunucuya atmak için FTP kullanırdık. Tabi ki o zamanlar git’in maharetlerinden haberimiz yoktu. Aslında tek başımıza çalıştığımız için ihtiyacımız da yoktu. Git kullanmadan yaptığımız işlerin çeşitli dezavantajları var.

  • Geçmişe yönelik kimin ne yaptığı, nerelerden sorumlu olduğu belli değildir.
  • Kalabalık bir ekiple çalışmak zulümdür.
  • listeler.pdf, listeler_son.pdf, listeler_bugun_son.pdf, listeler_en_son.pdf gibi manuel isimlendirmeler ve her şeyin karmakarışık olması.
  • Bir değişikliğin neden yapıldığı yorum satırı eklenmemişse bilinmeyebilir.
  • Aynı proje üzerinde ortak çalışmak için dosyaların FTP gibi bir sistemle taşınması gerekir.

Versiyon Kontrol Sistem Yaklaşımı

Versiyon kontrol sistemi bizim kod yazarken çeşitli yerlerde kodumuzu kaydedip paketlememize yarayan, herkesin kod yazdığı ama düzgün kullanılınca kimsenin kodlarının birbirine karışmasını engelleyen, servis sağlayıcılar sayesinde kodumuzu test imkanı sağlayan bir sistem. Adı üstünde versiyon kontrolü dediğimiz gibi büyük büyük güncellemeler yerine küçük küçük basamaklar şeklinde kodlamamızı sağlıyor.

Git’i öğrendikten sonra olaylara bakış açım birkaç kat daha değişti. Daha da derine indikçe “bunu da düşünmüşler” demekten kendimi alamadım. Eski yaklaşıma göre çeşitli avantajları var tabi ki.

  • Herkes kendi alanında çalışır, kimin ne zaman hangi değişikliği yaptığı bellidir.
  • Herkesin yaptığı değişiklikler ortak bir yerde toplanır.
  • Sonradan dahil olan birisi bile bütün kodu okumasına gerek kalmadan hızlıca adapte olabilir.
  • Toplanan değişiklikler otomatik test ve deployment sistemleriyle hızlıca yayınlanabilir.
  • Aynı proje üzerinde farklı branchler üzerinden çalışarak birleştirilebilir.

Git Nedir? GitHub, GitLab, Bitbucket Nedir?

Git versiyon kontrol sistemlerinden sadece bir tanesi, belki de en sık kullanılanı. GitHub, GitLab, Bitbucket ise git için servis sağlayıcılardır. Biz bugün git’i konuşacağız.

Git Kurulumu ve SSH Key Ayarları

Kodların hepsinin ezbere bilimesine gerek yok. Sık kullanılanlar bilinse yeterlidir. Diğer kodlar ihtiyaç oldukça buradan veya sondaki cheatsheetten ihtiyaç oldukla bakılabilir. Bu yüzden detaylı anlatıma girmiyoruz.

Git Kurulumu

Bazı dağıtımlarda git kurulu olarak gelmektedir. Kurulu olup olmadığına bakıp kurulmadıysa apt paket yöneticisi sayesinde hızlıca kurabilirsiniz. Kurduktan sonra git ayarlarına kendi e-posta adresimizi ve ismimizi kaydedip ileride yapacağımız işlemlerin kendi ismimizle kaydedilmesini sağlamış olacağız.

  • Yüklü mü değil mi? git –version
  • Yüklü değilse yüklemek için : sudo apt install git-all
  • Ayarlara adımızı eklemek için: git config –global user.name “ADINIZ”
  • Ayarlara e-posta adresimizi eklemek için: git config –global user.email example@gmail.com

SSH Key Oluşturma ve GitHub’a Eklemek

GitHub’da sadece yetkisi olan kişilerin eriştiği özel repolar olur. Bu repolara erişebilmek için kullanıcı adı ve şifre gereklidir. Kendi bilgisayarımızdan SSH key oluşturup GitHub’a ekleyerek bilgisayarımızdan şifre kullanmaya gerek olmadan özel repolarımıza erişim sağlayabiliriz.

  • Key oluşturmak: ssh-keygen -t rsa -b 4096 -C
  • Key’i agent’a eklemek: eval “$(ssh-agent -s)” sonrasında ssh-add -K ~/.ssh/id_rsa
  • Oluşturulan public key’i görüntülemek: cat ~/.ssh/id_rsa.pub
  • Görüntülenen keyi kopyalayın.
  • https://github.com/settings/ssh/new sayfasını hesabınıza giriş yaptıktan sonra açın. Başlık kısmına herhangi bir isim yazın, key kısmına da bu keyiyapştırıp kaydedin.

Terimler

  • Repo: Projeleri tuttuğumuz depoların her biri. Repository’nin kısaltması. Mesela: https://github.com/keras-team/keras bir repo örneğidir.
  • Branch: Kodların farklı yönlenderdeki geliştirme doğrultuları. Birbirinden ayrılıp ileride birleşen yollar gibi.
  • Commit: Kodlarda yapılan işlemlerin gönderilmek üzere paketlenmesi.
  • Push: Paketlenen değişikliklerin sunucuya gönderilmesi.
  • Origin: Ana veya aktif branhc’e verilen isim. Genelde ilk oluşturulan branch master’dır. İlk origin de dolayısıyla odur.
  • Conflict: Farklı kişiler tarafından paketlenip suncuya gönderilmeye çalışılan kodların birbiriyle çelişmesi.
  • Merge: Farklı doğrultuda ilerleyen branch’lerin birleştirilip tek parça şeklinde devam etmesi.
  • Pull: Başkalarının sunucuya gönderdiği değişiklikleri kendi bilgisayarımızdakine uygulamak için yapılan işlem.
  • Ignore: Bilgisayarımızda sunucuya göndermek için değişiklik yaptığımızda paketlemeye dahil edilmeyecek dosyaların veya klasörlerin tutulduğu dosya.
  • Clone: Sunucuda bulunan repoyu aynı şekilde kendi bilgisayarımıza çekmek, klonlamak.
  • Fork: Başkasına ait bir reponun aynısından kendi hesabımıza klonlamak.

Repo Oluşturmak / Klonlamak / Forklamak

Repo Oluşturmak

Repo dediğimiz şey aslında repository‘nin kısaltması. Türkçe söyleyeceksek depo da diyebiliriz. Ama yazılımcılar arasında da günlük dilde repo olarak kullanıldığı için repo şeklinde devam edelim. Repo oluşturma işlemini 2 farklı şekilde yapabiliriz. İster önce kendi bilgisayarınızda oluşturup sonra karşı sunucuya(GitHub’a) atın, isterseniz GitHub’da oluşturup sonra kendi bilgisayarımıza çekebiliriz. İkinci yöntem daha anlaşılır olacağı için oradan devam edelim.

  • https://github.com/new adresini açalım.
  • Repository name kısmına repomuza vermek istediğimiz ismi yazalım. Bu alan kendi GitHub hesabımıza özel olduğu için başkasının daha önceden kullandığı ismi de kullanabilirsiniz. Repoya verdiğimiz isim sonucu repomuz KULLANICI-ADIMIZ/REPO-ADIMIZ şeklinde kısaca isimlendirilir. Bu isimlendirmeyi ileride başka yerlerde de kullanacağız.
  • Açıklama kısmına bir şey yazmayabilirsiniz. Ama iyi kullanım açısından reponun amacını kısaca yazmak gerekir.
  • Public veya private seçebilirsiniz. Public seçerseniz herkes görebilir, private seçerseniz sadece sizin yetki verdiğiniz insanlar görebilir. Artık belli bir miktarda private repo GitHub’da ücretsiz olduğu için private seçebilirsiniz. Ayrıca private olarak açtığınız repoyu sonradan public, public açtığınızı da sonradan private’a çevirebilirsiniz.
  • Initalize with README kutusunu işaretleyelim. Bu kutuyu işaretleyince GitHub otomatik olarak repomuzu açıp içine bir adet README örnek dosyası koyar. Seçmezsek direk boş repo gelir.
  • Gitignore kısmı şimdilik none olarak kalsın, ileride değineceğiz.
  • Lisans’ı da yapacağımız projenin hangi lisansa tabi olacağına göre seçebiliriz. Bunu da şimdilik none olarak bırakalım.
  • Create repository butonuna tıklayıp repomuzu oluşturalım.
  • Repomuz oluştu. Tebrikler!

Repomuzu Klonlayalım

Repolarımızla çalışırken iki farklı kaynak vardır. Bunlardan birisi geliştirme yapanların kendi bilgisayarlarıdır, diğeri ise geliştirenlerin değişikliklerini gönderdiği GitHub sunucularındaki depodur. Çalışırken bu iki kaynak birbirisi ile etkileşim halinde olur. Kendi bilgisayarımızda yaptığımız değişiklikler biz göndermediğimiz sürece GitHub’a gitmez, bizim bilgisayarımızda kalır. Dolayısıyla bu değişiklikleri göndermediğimiz sürece bizden başkası görmez, diğerlerinin yaptığı değişiklikleri de biz GitHub’dan almadan göremeyiz.

Daha önce bilgisayarımızda olmayan bir repoda çalışmaya başlamak için o repoyu GitHub’dan kendi bilgisayarımıza çekmemiz gerekir. Bu işleme clone yani klonlamak denir. Bu işlemde GitHub’daki bir repoyu kendi bilgisayarımıza kopyalarız ve çalışmaya hazır hale getiririz.

  • Klonlayacağımız repoyu açalım. Biz şimdi az önce oluşturduğumuz repomuzu klonlayacağız. https://github.com/draaslan/test-repo
  • Sağ tarafta bulunan clone or download butonuna tıklayalım. Use SSH linkine tıklayalım ve yazan kodu kopyalayalım. **git@github.com:draaslan/test-repo.git* buna benzer bir yapıda kod olması gerekiyor. *HTTPS kullanımını public repolarda kullanabilirsiniz ama SSH her zaman için en güvenilir yoldur.
  • Terminalimizi açalım ve git clone KOPYALADIĞIMIZ ADRES şeklinde komutu girelim. Benim oluşturduğum repoya göre git clone git@github.com:draaslan/test-repo.git şeklinde bir kod girmem gerekiyor.
  • Kodu girdikten sonra herhangi bir error yani hata görmediyseniz ve bulunduğunuz dizinde reponuzun isminde bir klasör oluşturulmuşsa kendinizi tebrik edebilirsiniz, artık bir reponuz var.
  • Eğer bu aşamada bir hata aldıysanız muhtemelen private repo oluşturmuşsunuzdur ayrıca SSH Key Oluşturma ve GitHub’a ekleme kısmında bir hata yapmışsınızdır. O kısımları tekrar gözden geçirmeniz gerekir. Buradaki sorun private repo oluşturmanızda değil GitHub’ın sizin siz olduğunuzu tanımasını sağlayan SSH key’in doğru girilmemiş olmasıdır. Sizi tanıyamadığı için size özel repoya başkasının erişmesine izin vermez.

Commit Yapmak / Commit Pushlamak

Bu kısımda bahsedeceğimiz şeyler git ile ilgili yapacağımız şeylerin %90’ını oluşturduğu için buraya dikkatli bakmanızı öneririm. Zira geri kalan şeyler sık ihtiyaç duyulmayan ve ihtiyaç olduğunda dökümandan bakabileceğiniz şeyler.

Az önce kendi bilgisayarımızda iki farklı depo kaynağı olduğunu söyledik. Kodumuzdaki değişiklikleri GitHub’a göndermek için öncelikle bu değişiklikleri commitlememiz gerekir.

Somutlaştırmak gerekirse kodlarımızı önce bir kutunun içerisine koyuyoruz bu işleme git add diyoruz. Sonra bu kutuyu kapatıp etrafını bantlayıp üstüne keçeli kalemle içinde ne olduğunu yazıyoruz, buna da git commit diyoruz. Sonra bu kutuyu kargocuya teslim edip ana depomuza gönderiyoruz, buna da git push diyoruz. Tabii ki kargocu 404 geldik bulamadık demezse 🙂

Şimdi bunları terminalde nasıl yapacağımızı görelim.

  • Repomuzu açalım ve içine örnek bir dosya oluşturup içine bir şeyler yazalım. test.txt içine “Merhaba OpenZeka!” yazalım ve kaydedelim.
  • Böylece repomuz içerisinde bir değişiklik yapmış olduk. Git bu değişikliği otomatik olarak algılar ve biz sorduğumuzda hangi dosyada değişiklik olduğunu bize söyleyebilir. Bir değişiklik olup olmadığını veya nerelerde değişiklik olduğunu terminalden git status komutuyla görebiliriz. Bu git kodlarını terminalden girerken şu an bulunduğumuz dizinin repomuzun içi olduğuna dikkat etmemiz gerekir. Linux dersinde bahsedilen şekilde repomuzun bulunduğu klasöre gidebilirisniz.
  • Şimdi değişiklik yapılan kodumuzu kutulayalım: git add DOSYA ADI şeklinde tek bir dosyayı kutuya koymuş oluruz. Bizim örneğimizde git add test.txtolarak deneyebilirsiniz. Eğer bütün dosyaları kutuya koymak istersek git add . şeklinde sadece nokta koyarak bütün dosyaları tek seferde kutulamış oluruz.
  • Kutumuzu bantlayıp içindekileri yazmak için git commit -m “İÇİNDE GÜZEL ŞEYLER VAR” komutunu kullanabiliriz. Komutu girdiğimizde paketli commit içerisindeki değişiklikleri ve değişen dosyaları gösterir.
  • Tekrar git status komutunu girdiğimizde artık değişikliklerin görünmediğini ve branchimizin origin/master’a yani GitHub’daki depomuza göre 1 commit ileride olduğunu görebiliriz. Henüz bilgisayarımızdaki değişiklikler GitHub’a aktarılmadı.
  • Paketlerimizi kargocuya vermek için git push komutunu girip paketlerimizi GitHub’a gönderelim.
  • GitHub’daki repo sayfamızdan güncellemelerimizin GitHub repomuza da yansıdığını görebilirsiniz. Tebrikler!
  • Commitlerinizi düzenli olarak biriktirmeden yapmanız ve anlamlı mesajlar girmeniz, geçmişe yönelik bir şeylere ihtiyaç duyduğunuzda kolay bulmanızı, dışarıdan başkası projeye dahil olduğunda projeye hızlı adapte olmasını sağlar. Aynı şekilde commitlerinizi sık sık pushlamanız da olası bir problemde en güncel halini yedeklemiş gibi olmanızı sağlar. Bunlar iyi kullanım örnekleri olarak tavsiyelerimdir.

Ignore Etmek

Bu özellik sadece bizim bilgisayarımızda olmasını istediğimiz dosyaların GitHub reposuna commit edilmesini engeller, onlar yokmuş gibi davranır, görmezden gelir. İçlerinde değişiklik yapılsa bile git status komutunu çalıştırdığımızda onlarda değişiklik olduğunu görmeyiz. Dolayısıyla commit de etmeyiz. Buna neden ihtiyaç duyalım diyorsanız bir örnek verelim. Mesela kendiniz geliştirme yaparken sistemde eposta bilgilerinizi girmeniz gereken bir yer var. Bu bilgilere kimsenin ulaşamaması için GitHub’a gönderilmemesi lazım bunun için de ignore edilmesi lazım. Ignore etmek istediğimiz dosya ve klasörleri .gitignore isimli bir dosyada satır satır saklarız.

  • Metin editörümüzü açalım.
  • Repomuzun içine .gitignore isminde bir dosya oluşturalım.
  • Oluşturduğumuz dosyanın içine bir satıra /ignore yazıp kaydedelim.
  • Daha sonra repomuzun içine ignore isimli bir klasör oluşturalım.
  • Kontrol etmek için terminale git status yazalım. Gelen sonuçta ignore klasörünün olmadığını ama .gitignore dosyasının olduğunu görebilirsiniz. Çünkü ignore klasörünü ignore ettik, yani görmezden geldik.
  • .gitignore dosyasının içine *.uzanti şeklinde satırlar ekleyerek dosya uzantısı .uzanti olan dosyaları da topluca ignore edebilirsiniz.

Reset İşlemi

Yazılım geliştirirken her zaman işler yolunda gitmeyebilir. Bazen sorunları çözmek adına yaptığımız değişikliklerden bir sonuç alınamaz olur ve manuel olarak değişiklikleri silmek imkansızdır çünkü çok karışmıştır her şey. Bu durumda reset işlemini kullanabiliriz. Reset işleminin de farklı seçenekleri var fakat biz en sık soft, mixed ve hard reset türlerini kullanıyoruz.

Git reset komutuna soft parametresini verip bir commit belirtirseniz eğer, Git bu belirttiğimiz commiti ve sonrasındaki commitleri silecektir, düzenlenmiş dosyalar da Git’e eklenmiş yani git add komutu kullanılmış ama commit edilmemiş hale gelecektir. Dosyalardaki değişiklikler bozulmayacaktır.

Git reset komutuna mixed parametresini verdiğimiz zaman ise Git, bu belirttiğimiz commiti ve sonrasındaki commitleri silecektir. Dosyalarımızdaki değişiklikler gitmeyecek ancak dosyalarımız Git’e eklenmemiş yani hem git add komutu girilmemiş hem de commit edilmemiş olacaktır.

Git reset komutuna hard parametresini verip bir commit belirttiğinizde ise bu belirttiğiniz commiti ve sonrasındaki commitleri tamamen silip dosyalarda yaptığınız değişiklikleri de geri alıyor. Yani yaptığınız her şey uçup gidiyor. Bunu kullanacağınız zamanlarda çok dikkatli olun.

Hangi commite reset edeceğimizi ise git log komutuyla görüp commit hashini alarak belirleyebiliriz.

  • Reset işlemi git reset –RESET TİPİ <RESETLENECEK COMMİT> şeklinde kullanılır. Örnek olarak git reset –hard 8f3a4a30b51262b913fadb2437e32823301dc125 şeklinde kullanabiliriz. Burada en sonraki anlamsız karışık harfler ve rakamlar git log komutuyla reset ile dönmek istediğimiz commiti tanımlayan bir bilgidir.

Branchler

Branchler, Türkçe söyleyişle dallar, adı üstünde projemizi dallara ayırmamızı sağlar. Bir projede birden fazla kişi çalışacağı zaman herkesin kendi branchinde kendi göreviyle alakalı yerleri geliştirip özellikler tamamlandıkça bunları birleştirip, yani merge edip, herhangi bir bozulmaya sebep vermeden projenin geliştirmesinin devam etmesini sağlar. Veya projenin yeni bir sürümü üzerinde çalışılmaya başlanacaksa şu anki halinden başka bir branche geçip yeni geliştirmeleri o branch üzerinden yapmak için kullanılabilir.

Yeni Branch Oluşturmak

Biz repomuzu oluşturduğumuzdan beri zaten bir branchimiz var. Ama henüz dallanıp budaklanmamış bir branch. Repoyu ilk oluşturduğumuzda buna masterbranchi diyoruz. Şimdi bu branchimizi köken alarak yeni bir branch oluşturacağız. Bu branch şu anki master branchimizin birebir kopyası olacak.

  • Yeni branch oluşturmak için git branch -b branch_adi komutunu kullanabiliriz. Örnek olarak git branch -b yeni_ozellik komutuyla yeni_ozellik adında bir branch oluşturmuş oluyoruz.

Başka bir branche geçtiğimiz zaman bu branchte yaptığımız diğer branchleri etkilemez. Branch özelliğini bizim için faydalı yapan şey de budur. Birisi üzerindeki çalışmalar diğerini etkilemez. Diğer dikkat edilmesi gereken bir özellik ise kendi bilgisayarımızda oluşturduğumuz branchler aynı commitler gibi GitHub’a göndermediğimiz sürece sadece bizim bilgisayarımızda kalır.

  • Oluşturduğumuz yeni branchi GitHub’daki repomuza da göndermek için pushlarken git push –set-upstream origin branch_adi şeklinde pushlamamız gerekir. Yani bizim örneğimizde git push –set-upstream origin yeni_ozellik şeklinde kullanabiliriz.

Branchleri Görmek ve Branchler Arası Geçiş

  • Hangi branchlerin olduğunu görmek için git branch komutunu kullanabiliriz.

Aktif olan branch diğerlerinden farklı renkte ve başında * işareti olarak görülür. Projemizde yapacağımız değişiklikler hangi branch aktifse o branchte yapılmış olur.

  • Branch değiştirmek için ise git checkout branch_adi şeklindeki komutu kullanabiliriz. Biz az önce yeni_ozellik branchine geçmiştik. Tekrardan repoyu ilk oluştururken hazır gelen master branchine dönmek için git checkout master komutunu kullanabiliriz.

Branchleri Birleştirmek

Bu kısım genelde göz korkutan kısımlardan biridir ama alışınca aslında öyle olmadığı görülür. Mantığını tam olarak anlamak için birkaç pratik ve deneme yanılma yeterlidir.

Her branchin bir ömrü vardır. Master branchinden oluşturulan branchlerdeki işimiz bitince master ile birleştirir ve branchi silerek tarihin tozlu sayfalarına kaldırırız. Çünkü branchimiz bütün yükünü mastera devreder ve master, sildiğimiz branchin bütün özelliklerini zaten taşır. Projemizin ana akışı master üzerinden devam eder.

  • Bir branchi diğerine merge etmek yani birleştirmek için öncelikle ana branche git checkout ile geçilir, ana branchten kastımız kodların miras bırakılacağı branch. Sonra git merge branch_adi ile branch_adi branchindeki kodlarımız aktif branche merge edilmiş olur. Biz de yeni_ozellik branchimizi master’a merge etmek için önce git checkout master ile master branchine geçiş yapıyoruz. Sonra git merge yeni_ozellik komutuyla merge ediyoruz.

Yeni branch oluşturduğumuzdaki gibi bu değişiklik ve her değişiklik GitHub’a pushlanmadığı sürece sadece kendi repomuzda kalır. Pushlama işlemi yukarıda bahsettiğimiz şekilde bir değişiklik olmadan yapılabilir.

Branch Silmek

Her branchin bir ömrü vardır demiştik. Bir branchle işimiz bittiğinde diğerleriyle karışmaması ve kalabalık oluşturmaması adına silinmelidir.

  • Branch silmek için git branch -D branch_adi komutu girilebilir. Bizim örneğimizde git branch -D yeni_ozellik komutunu girerek yeni_ozellik branchini silebiliriz.

Merge Request

Aynı projede çalışırken herkesin yetki seviyesi aynı olmayabilir. Yani herkes kendi branchine kodları yazıp pushlarken bu branchleri birleştirme yetkisi sadece proje yöneticisinde veya takım liderinde olabilir. Bu gibi durumlarda direk merge etmek yerine merge request göndeririz ve proje yetkilisi kendisi onaylarsa merge işlemi gerçekleştirilir.

  • Merge request, yani birleştirme talebi GitHub repo sayfası üzerinden oluşturulabilir. Sadece proje yönetimine genel bakış açısı kazandırması açısından bahsettiğimiz için detaya girmiyoruz.

Bazen branchleri merge ederken hata ile karşılaşırız. Bunlara conflict diyoruz. Conflictler apayrı bir mevzu olduğu için sonraki bölümde bahsedeceğiz.

Resim Kaynağı: Voronenko/gitflow-release

Anlattıklarımızı şema ile toparlayalım. Sol üstteki yeşil master satırındaki daire bizim ilk branchimiz. Daha sonra gördüğünüz gibi ondan bir branch ayrılıp mor renkli hotfix oluyor, bir tane daha ayrılıp turuncu develop branchi oluyor. Developtan yeni bir branch daha mavi feature branchi. İleride bunlar yine çeşitli yerlerde ayrılıp birleşiyorlar ve bu süreç böylece devam ediyor. Ne zamana kadar? Yeni bir tam sürüme kadar. En üstte master branchinden v0.1, v1.0 gibi sürümleri görüyorsunuz. Bu branchler sürüm yayınlamada birleşip tekrar ayrılıyorlar sonraki sürüm için. Ayrılmaları yen bir branch oluşturmak, birleşmeleri merge etmek olduğunu tekrar hatırlatalım.

Conflictler

Normalde sağlıklı bir geliştirme sürecinde bu olmaz fakat çok kişili ekiplerde her zaman mümkündür. Olduğu zaman da projenin büyüklüğüne göre intihara kadar sürükleyebilir.

Merge ederken bir hata aldık ve bize bir conflict olduğunu söylüyor. Aldığımız hatanın sebebi aynı yerde iki farklı kişinin farklı değişiklikler yapmasıdır. Bu durumda merge etmeye çalıştığımızda git hangi kodu saklaması gerektiğine karar veremez, çelişkiye düşer.

Hatayı çözmek için yapılması gereken bizim manuel olarak hangi kodun korunacağını hangisinin iptal edileceğini seçmemizdir. Bu işlemi manuel olarak kod editörünüz üzerinden yapıp tekrar merge edebileceğimiz gibi bir araç sayesinde hangi kodun korunacağını hızlıca seçebiliriz.

Benim tavsiyem bu işlemi bir kullanıcı arayüzü kullanarak yapmaktır. Herhangi bir git kullanıcı arayüzü kullanarak bunu yapabilirsiniz. Kullanıcı arayüzlerinden ilerleyen bölümlerde bahsedeceğiz.

Forklamak

GitHub gibi hizmet sağlayıcılar yazılımcıların ihtiyaç duyduğu çoğu şeyi barındıran, çoğu zaman ihtiyacımız olan şeyleri başkasının zaten çoktan yapmış olduğu bir platform. Mesela yüz tespit etmek için bir derin öğrenme modeli geliştireceğimizi düşünelim, bunu sıfırdan geliştirmek yerine GitHub’da arama yaparak daha önceden başkasının bu işe girişip girişmediğine bakabiliriz. Eğer girişmişse onun projesini kendimize forklayıp daha iyi bir noktaya getirebiliriz. Böylece sıfırdan bir şeyler yapmaya uğraşmamış oluruz. Ayrıca topluluğa da bir faydamız olmuş olur.

İşte başkasına ait bir repoyu kendi hesabımıza kopyalamaya forklamak denir. Forkladığımız repo artık bizim olur. Değişikliklerimizi bu repo üzerinde yapabiliriz. Daha sonra istersek yaptığımız değişiklikleri ana reponun sahibine pull request göndererek “bak ben bu değişiklikleri yaptım, istersen birleştirelim” diyebiliriz. Ana reponun sahibi bu talebimizi onaylarsa bizim yazdığımız kodlar onun kodlarıyla birleştirilir ve biz de o projeye katkıda bulunmuş oluruz.

Bunun benzeri bir senaryoyu hatalar için oluşturabiliriz. GitHub’da barındırılan bir projeyi kendi bilgisayarımızda kullanmak üzere klonladık. Ama projeyi çalıştırdığımızda birkaç hata tespit ettik. Yukarıdaki gibi projeyi forklayıp hataları çözdükten bunları commitleyip pushladıktan sonra pull request atarak hataların giderilmesine de yardımcı olmuş oluruz. Açık kaynak kodlu projelerin çoğunda işleyiş bu mantıkla topluluk eliyle yürütülmektedir.

  • Fork ve pull request işlemleri de yine GitHub arayüzünden yapılabilmektedir. Bu kısımlar da açık kaynak kodun yöntemi hakkında bilgi vermesi açısından anlatılmıştır.

GUI ile Kullanım

Buraya kadar anlattığımız şeylerde hep terminali kullandık. Aslında anlattığımız şeylerin tamamına yakını bir kullanıcı arayüzü ile yapılabilmektedir. Bu arayüzler bizi komut yazma derdinden kurtarmakla birlikte aynı zamanda projeye kuşbakışı bakmamızı da sağlar.

Kullanıcı arayüzlerinin farklı seçenekleri mevcut. Ücretli ve ücretsiz birçok seçeneğe https://git-scm.com/download/gui/linux adresinden ulaşıp deneyebilirsiniz. Benim tavsiyem GitKraken‘dır. Diğerlerini de deneyebilirsiniz, hepsi ortalama aynıdır.

Tavsiyeler & İyi Geliştirme Pratikleri

Bu kısımda bahsedeceğim şeyler yazılı kanun olmamakla beraber proje yönetimini ve işbirliğini kolaylaştıran iyi pratikler olduğu için tavsiye ettiğim şeylerdir.

  • Her gün değişikliğe başlamadan ve ara ara git pull ile projenin son halini çekin. Gerideki bir committen geliştirmeye başlarsanız hata alırsınız, tekrar aynı değişiklikleri uygulamak zor gelir.
  • Yaptığınız değişiklikleri biriktirmeden commit edin. Biriktikçe commit yükünüz artar ve zamanla hepsini toplu ekleyip açıklama girmeye bile tenezzül etmeden commit etmeye başlarsınız. Bu da proje ilerledikçe iş yükünüzü artırır.
  • Commitlerinizi ve branchlerinizi isimlendirirken tam olarak amacının ne olduğunu belirtin. Mesela commit mesajında “değişiklikler” yerine “artık üst menüye tıklayınca aşağıya iniyor” şeklinde mesaj yazmak commit geçmişine hızlıca bakan birinin bile projeye az çok hakim olmasını sağlar. Ayrıca sizden başkaları da sizin commitlerinize göz attığında yeni şeyler öğrenebilir. En önemlisi aradan zaman geçtikten sonra projeye tekrar güncelleme yapmanız gerektiğinde commit mesajlarına bakarak bile nerede kaldığınızı hızlıca anlayabilirsiniz.
  • Commitlerinizi sık aralıklarla pushlayın. Olası bir bilgisayar hasarı veya çalınma durumunda başınızı duvarlara vurmamak için buna dikkat edebilirisiniz. Tecrübe konuşuyor 🙂
  • Başkasının commitlerini inceleyin. Kod yazmak kadar kod okumak da birçok şey öğretir. Hatta birebir hangi kodun neden eklendiği ile ilgili bilgi verdiği için daha faydalı bile olabilir.
  • Kurcalamaktan çekinmeyin. Bu tip beceriler kurcaladıkça daha kalıcı hale gelir. Kendi bilgisayarınızda istediğiniz kadar kurcalayabilirsiniz.
  • Repolarınızdan dökümantasyonları eksik etmeyin. Proje ile ilgili genel bilgileri unutmadan README dosyalarına yazmak aradan zaman geçtikten sonra nerede kaldığınız hakkında fikir verir. Aynı commit başlıkları gibi önemlidir.

Cheatsheet

Komutları unuttuğunuzda hatırlamak için bütün dökümanı aramak yerine buraya bakabilirsiniz. <- -> Arasında belirtilen yerlere uygun içerikleri yerleştirerek kullanabilirsiniz.

  • Git yüklü mü değil mi?: git –version
  • Git yüklemek: sudo apt install git-all
  • Ayarlara adımızı eklemek: git config –global user.name “ADINIZ”
  • Ayarlara e-posta adresimizi eklemek: git config –global user.email example@gmail.com
  • SSH Keyi oluşturmak: ssh-keygen -t rsa -b 4096 -C
  • Key’i agent’a eklemek: eval “$(ssh-agent -s)” sonrasında ssh-add -K ~/.ssh/id_rsa
  • Public Keyi görüntülemek: Oluşturulan public key’i görüntülemek: cat ~/.ssh/id_rsa.pub
  • SSH Key ekleme sayfası: https://github.com/settings/ssh/new
  • Yeni repo oluşturma sayfası: https://github.com/new
  • Bilgisayarımıza repo klonlamak: git clone <-REPO ADRESİ->
  • Commitelemeden önce dosya eklemek: git add <-DOSYA YERİ->
  • Commitlemek ve commit mesajı girmek: git commit -m “<-COMMIT MESAJI->”
  • Commitleri pushlamak: git push
  • Repoda değişiklik var mı, durumu ne görmek: git status
  • Bir commite reset atmak: git reset –RESET TİPİ <-RESETLENECEK COMMİT->
  • Yeni branch oluşturmak: git branch -b <-BRANCH ADI->
  • Başka branche geçmek: git checkout <-BRANCH ADI->
  • Var olan branchleri görmek: git branch
  • Branch silmek: git branch -D <-BRANCH ADI->
  • Branchleri birleştirmek: git merge <-BRANCH ADI->
  • Bilgisayarı GitHub’daki reponun son haliyle güncellemek: git pull
  • Repo kayıtlarını ve commit geçmişini görmek: git log
  • GUI indirme linki: https://git-scm.com/download/gui/linux

Sorun Yaşadığınızda Başvurabileceğiniz Kaynaklar

Leave a comment

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir