Mucahid Yazar
mucahid.dev

Follow

mucahid.dev

Follow
Github’da Open Source Projeye Katkıda Bulunmak ve Rebase İşlemleri

Github’da Open Source Projeye Katkıda Bulunmak ve Rebase İşlemleri

Mucahid Yazar's photo
Mucahid Yazar
·May 14, 2021·

8 min read

Bildiğiniz gibi Github üzerinde paylaşılan milyonlarca open-source proje bulunmaktadır. Bunlar çoğu zaman gönüllü kişiler tarafından, bazen de firmalar tarafından geliştirilip herkesin kullanımına sunulan kaynaklar diyebiliriz. Ve kimi zaman kendimizi geliştirmek için, kimi zaman kullandığımız herhangi bir open source kaynağın hatalarından veya zaman aşımından olan bir eksikliğini tespit edebiliriz.

İşte bu durumlarda bizim bir open source projesine nasıl katkıda bulunuruz bugün sizlere bunu anlatacağım.

Contribute.md

Katkıda bulunmak istediğimiz bazı open source projelerde contribute.md adında markdown dosyası bulunur. Bu markdown dosyasında bizim bu projeye nasıl katkıda bulunacağımızla alakalı adımları anlatılır. Bazı küçük projelerde bu olmayabilir o zaman direk bu adımı atlayıp aşağıda ki adımlarla devam edebilirsiniz.

Get Started

Step 1 - Fork the project

  • İlk önce katkıda bulunmak istediğimiz projeyi forkluyoruz. Daha sonra projeyi kod editörümüzden ve terminalimizden açıyoruz.

Step 2 - Set your branch to be ready for developing

  • Bunun içinde orjinal projenin repositorysine gidiyoruz ve ssh urlini kopyalıyoruz ve aşağıda ki kodla ayarlamasını gerçekleştiriyoruz.
    git remote add upstream githubSshUrl
    git remote add upstream
    github.com/fridays/next-routes.git
  • Bu remotedeki repositoryden info almak için aşağıda ki kodu kullanıyoruz.
    git fetch upstream
  • master branchimize, upstream ettiğimiz remote branchinde ki master branchini referans gösteriyoruz ve böylece contribute edeceğimiz repoda herhangi bir değişiklik olduğunda biz pull yaparsak bu remotedaki branchde ki değişiklikleri çekebileceğiz.
    git branch --set-upstream-to=upstream/master master

Yukarıda ki işlemlere dair kısa bir özet

  • Sonra npm install, npm test ve npm run build diyerek kontrollerimizi gerçekleştiriyoruz projenin sorunsuzca çalıştığıyla alakalı. Her şey sorunsuz çalışıp geçtiyse artık değişiklik yapabiliriz.
    npm install && npm test && npm build

Step 3 - Before/After changes

  • İlk önce bir bracnh oluşturuyoruz ve daha sonra değişikliklerimizi yapıyoruz.
    git checkout -b pr/nextUpdate
  • Değişikliklerimizi yapıp, branchimizi kendi forkladığımız branchimize pushluyoruz. Örnek olarak aşağıda ki gibi
    git add .
    git commit -m “Changed new rouiting method”
    git push origin pr/nextUpdate
  • Daha sonra contibute yani katkıda bulunmak için upstream yaptığımız branche pushlamamız gerekiyor. Bunun içinde aşağıdaki kod ile yapabiliyoruz. Veya sade -u ile kısa halini de uygulayabiliriz.
    git push --set-upstream origin pr/nextUpdate
    git push -u origin pr/nextUpdate (Bundan sonra, uzaktaki pr a commitlerimizi kodlarımızı göndermek için ki pushlama işlemlerimiz için sadece git push dememiz yeterlidir.)

Step 4 - Create a pull request

  • Daha sonra contribute etmek istediğimiz reponun github sayfasını açıyoruz. Ve **New pull request** butonuna tıklıyoruz.

  • Daha sonra bu selectboxdan kendi gönderdiğimiz repositoryi seçiyoruz.

  • Sonra yine kendi gönderdiğimiz repositoryde ki yaptığımız değişiklikleri içinde bulunduran, oluşturduğumuz branchi seçiyoruz.

  • Sonra bu sayfaya geliyoruz. Burada yaptığımız değişiklikle alakalı gerekli bilgileri yazıyoruz. Ve **Create pull request** diyoruz.

  • Ve aşağıda ki gibi pull requestimizi görüntüleyebiliyoruz artık.

Step 5 - After Creating a Pull Request

  • Pull requestimizi oluşturduktan sonra bazı projeler aşağıda ki gibi kendileri entegre ettikleri botlarla code özetimizi bize gösterebilirler.

  • Ve branch sahipleri yani maintainerlar, bizim PRımıza aşağıda ki gibi yorumlar bırakabilirler ve bizden düzeltmemizi istedikleri yerleri söyleyebilir veya kodumuzla alakalı bir şey sorabilirler.

  • Ve burada da başka bir bot olan, travis ci bize yine otomatik mesaj olarak, mesaj bırakarak test coveragemizle ilgili bilgi verebilir. Mesela aşağıda test coveragemizin eksik olduğunu söylemiş.

Step 6 - Updating our Pull Request

  • Değişiklikler yaptıktan sonra daha önce dediğim gibi tek yapmamız gereken git add, commit ve push yapmak, fakat yukarıda gördüğünüz uzere yaptığımız değişiklikler tam olarak standartlara uymadığı için bu repo kodlarımızı kod test coveragesi yaparak göndermemizi bekliyor bizden.
  • travis botunun komutlarini görmek için cat .travis.yml diyoruz. Ve aşağıda ki gibi dosyamızın içini görüyoruz. Veya direk dizinde ki .travis.yml dosyasına gidip de bakabiliriz.

  • Burada travis botunun bize gönderdiği hataları gösteren scripti görüyoruz. Travis bize testler yüzünden hata göndermişti. Testleri yaptıktan sonra bu 2 komutu localimiz de çalıştırarak deniyoruz. Eğer sorunsuz bir şekilde geçerse değişikliklerimizi pushlayabiliriz.
    npm run cover
    npm run build
  • Değişikliklerimiz git hooksunda takılırsa --no-verify ile git hooksunu geçebiliriz.
    git add .
    git commit -m “Added tests”
  • Ve daha sonra git push diyerek commitimizi göndeririz. Buda aslında parantez içinde ki işlemi yapar çünkü bunun sebebini Step 3 son satırında göreceksiniz.
    git push (git push -u origin pr/nextUpdate)

UPSTREAM

  • Orijinal repodan upstream almak için kullanırız. (yerel kopyanızı katkıda bulunmak istediğiniz projeyle senkronize tutmak için yani). Bu tüm commitlerimizi alır ve o anki uzak sunucudaki master branchinden yeni taze bir kopya alır ve bizim bu ana kadar gönderdiğimiz commitlerimizi bu taze masterın üzerine koyar gibi düşünebilirsiniz.
    git fetch upstream

REBASE

  • Rebase alma işlemlerimizi gerçekleştiririz. rebase almak istediğimiz branch adını yazarız branchName yerine.
    git rebase branchName
  • Buda commitlerimizi alır ve o ana kadar mastera atılmış commitlerin hemen üzerine bizim commitlerimizi ekler. Yani burada uzaktaki reponun master branchinden rebase almış oluyoruz.
    git rebase upstream/master

Resolving Conflicts

  • Yukarıda ki kodla rebase almayı denerken eğer conflict varsa rebase işlemi yarım kalır. Conflictleri çözmek için kod editörümüzü açabiliriz veya yine terminalden yapabilirsiniz ben kod editöründen yapmayı tercih ediyorum.
  • Örnek olması açısından aşağıda bir conflict ekranı görüyorsunuz. Bilgi vermek gerekirse Conflictler şu şekilde oluşur. v1 master branchinden ben yeni branch oluşturdum ve bu branch üzerinde package.json içinde **next-dev** olan scritin adını ben **dev** yaptım. Başka biriside yine v1 branchinden yeni branch oluşturdu ve yine **next-dev** olan scrıptin adını **next:dev** yaptı ve bizden önce işini bitirip pull request açtı ve master branchini v2 ye yükseltti. Fakat bu yükseltmede aynı yerde değişiklik yaptığımız için yani bizim değişiklik yaptığımız yerde bu diğer kişide değişiklik yaptığını için conflict oluşuyor. Ve rebase alırken git hangisini uygulayacağını bilmiyor. Bu yüzden bunu bize soruyor. Ve biz bu sorunu çözünce conflicti çözmüş oluyoruz.

Accept Current Change: rebase etmek istediğimiz branchde uygulanmış, bizim yaptığımız değişikliklerle çakışan değişikliği kabul et demektir. Eğer bunu seçersek bizim branchde ki değişiklikler hiç uygulanmaz ve masterda ki değişiklikler kabul edilmiş olur.

Accept Incoming Change: Bizim branchte yaptığımız değişiklikleri kabul et demektir. Eğer bunu seçersek sadece bizim branchte yaptığımız değişiklikler uygulanır.

Accept Both Changes: Hem rebase etmek istediğimiz branchdeki, hemde bizim branchimizde değişikliklerin ikisini birden ekleriz.

  • Conflict çözerken şunu gözardı etmemiz gerekiyor. Sadece burada ki seçeneklerden birisini seçtikten sonra her zaman conflicti çözmüş olmazsınız. Bazı durumlarda bu seçeneklerin birini seçtikten sonra kodu da bu seçtiğimiz seçeneğe göre düzeltmelisiniz. Ama yukarıda ki seçenek için buna gerek yok, current veya incoming seçeneklerinden birisi bizim için sorunumuzu çözer.

git rebase --continue

  • Conflictleri çözdükten sonra yaptığımız değişikliği kaydederiz ve daha sonra git add ile yaptığımız değişiklikleri staged pozisyonuna çekeriz. Ve daha sonra git rebase --continute diyerek rebase işlemimizi devam ettiririz. Eğer başka conflict çıkmazsa rebase işlemi başarıyla biter. Başka conflict çıkarsa da tekrar bunuda çözüp daha sonra tekrar git rebase --continue demeliyiz.
  • Böyle bir ekran gelecektir CTRL+C yaptıktan sonra :x veya :wq yaparak yaptığınız değişiklikleri kaydederek burayı kapatabilirsiniz. Burası bir terminal text editörüdür.

  • Ve buradaki gibi successfully rebased yazısını gördüysek işlem başarıyla tamamlanmıştır demektir.

git rebase --abort

  • Rebase işlemini iptal eder. rebase yapmadan önceki durumunuza geri dönersiniz. Bunu yukarıdaki şimdiki işlemlerimiz için uygulamayın gerekmedikçe. Yan bilgi olsun diye verdim.
  • Ve rebase işlemimiz başarıyla bittiyse artık değişikliklerimizi pushlayabiliriz. Fakat sebebini bilmek adına burada bir rebase işlemi yaptığımız için buda git historysini değiştireceği için default olarak pushlamamız git tarafından reject edilecektir yani kabul edilmeyecektir. Bu yüzden force pushlamamiz gerekecek. Ve hatırlarsanız bundan sonra sadece push yapmamız yeteceği için tek yapmamız gereken aşağıda ki gibi git push -f demektir. Buda aslında parantez içinde ki işlemi yapar çünkü bunun sebebini Step 3 son satırında göreceksiniz.
    git push (git push -u origin pr/nextUpdate)
  • Ve daha sonra PR açtığımız sayfaya gidip conflictleri çözdüğümüzden emin olup yaptığımız rebase işleminin başarıyla çalışıp güncel masterla eşleştiğine emin oluyoruz. Bitbucketda bunu branch kısmına gidip bunu şu şekilde görüp emin olabilirsiniz. Kırmızı ile seçili alan bize master branchinden kaç commit geride olduğumuzu gösterir. Masterdan rebase alıp force pushladıktan sonra bu kırmızı ile seçili alan 0 olması gerekiyor. Eğer olmazsa siz rebase işlemini eski güncellenmemiş pull yapılmamış bir master branchinden yapmışsınız demektir. İlla master olarak düşünmeyin rebase işlemini nereden yaptıysanız ona göre kıyaslamanız gerekmektedir. Mor ile seçili alan ise bu branchde kaç commit atıldığını gösterir.

git rebase -i HEAD~x

Son x sayıda commiti listeleyerek interactive rebase yapmamızı sağlar.

git rebase -i commitMessageId

Belirtilen commitId sine kadar commitleri listeleyerek interactive rebase yapmamızı sağlar.

  • Ben genelde -i HEAD~x şeklinde olanı kullanıyorum. Aşağıda git rebase -i HEAD~5 yaptıktan sonra kendi şahsi projemde aldığım commitleri görebilirsiniz. Burasıda yine bir terminal text editörüdür.
  • Burada pick olacak commit üstte kalmalıdır.
  • Ben bu interactive rebasedeki sadece squash’ı burada göstereceğim.

  • Ve aşağıda ki gibi 4b8ea29 adlı commiti pick ediyorum diğer alttaki 4 commitide squash ediyorum. Uzunca squash yerine kısaca s de yazabilrisiniz. Ben s yazıyorum göstermek için bu şekilde 2 si ayrı 2 si ayrı oldu.

  • Daha sonra CTRL+C yaparak yine bu text editörümüzü :wq veya :x ile kaydederek kapatıyoruz.
  • Resimdeki # işareti olan yerler yorum satırlarıdır yani etkisiz kısımlardır. Oraları hiç yokmuş gibi düşünebilirsiniz..
  • Ve daha sonra aşağıda ki gibi bir ekran geliyor. Burasıda commit mesajını belirleyeceğimiz alan. pick olan ve squash yapılan tüm commitlerin mesajları aslında burada birleştiriliyor. Ve buraya ellemezseniz eğer buradaki commit mesajlarının hepsi yan yana gelecek ve yeni commit mesajımız olacaktır. Ben bunun yerine burada yine bir tuşa basarak düzenleme moduna geçiyorum ve ilk commit mesajı hariç diğer hepsinin başına # işaretini koyarak diğer kısımları yorum satırı haline çeviriyorum.

  • Ve yukarıyıda düzenledikten sonra CTRL+C yapıyoruz ve :x veya :wq diyerek yine text editörümüzü kaydederek kapatıyoruz.
  • Ve tekrar yaptığımız değişiklikleri force olarak pushluyoruz. Ve daha sonra repomuza giderek branchimizin tek commite inip inmediğini kontrol ediyoruz.
    git push -f

  • PR’lara dönecek olursak, gönderdiğimiz güncellemeler PR’ın sahibi maintainera bildirim olarak gitmiyor. Bunun için update sonrası comment bırakmak en sağlıklısı olur.

  • Ve PR’ımız maintainer tarafından onaylanıp, merge edildikten sonra commit tree sine gidip, aşağıda ki gibi PR’ımıza ait commit mesajını görebiliriz.

 
Share this