GitHub nasıl kullanılır

Sponge’un oluşturulmasına yardımcı olmak mı istiyorsunuz? API’ye harika bir eklentiniz mi var? veya Google Dokümanlarımızı iyileştirmek mi istiyorsunuz? git ve GitHub konusunda bilgi sahibi olmanız gerekir. Zincirleme, dallar, sorun, çekme isteği ve işleme hakkında zaten bilginiz varsa, o zaman bu konuyu atlayın. Ne hakkında konuştuğumuzu bilmiyorsanız okumaya devam edin.

Not

This guide assumes that you’ve read Git’i kurmak and that you’ve already setup your machine with a Git client of your choice.

Git ve GitHub’un Temel Kavramı

Git birçok farklı geliştiricinin aynı anda tek bir yazılım geliştirmesine olanak tanır. GitHub, geliştiricilerin ortak çalışma yapabilecekleri ve çalışmalarını başkalarıyla paylaşabilecekleri bir web sitesidir. GitHub söz konusu çalışmanın yönetimi için Git’e güveniyor.

Tüyo

Git ve GitHub kelime dağarcıklarını bilmiyorsanız, GitHub’daki sözlük sayfasına bir göz atın.

Bu durumda repo “SpongePowered” olarak adlandırılır, “master” ve “feature 1” isimli iki şubeye sahiptir ve bazıları her iki şubeye de taahhüt eder.

Bu şartları bağlam içine koyalım - depo * ile başlayalım-. Depo (kısa: * repo *), bir projenin dosyalarını depoladığı yerdir. SpongePowered depoları `GitHub <https://github.com/SpongePowered>` __ adresinde bulunur. Bununla birlikte, bu repo’nun istenmeyen veya kötü amaçlı değişikliklerden korunması için bazı erişim kısıtlamaları var. Repo, normal kullanıcılar için salt okunur olduğundan, kendi kendinize basitçe değişiklik yapamazsınız. Şimdi, teklif ve değişiklikleri nasıl yapmanız gerektiğini merak ediyorsunuzdur. İşte, burada *çatallar devreye giriyor. SpongePowered repolarının bir kopyasını alabilir ve orada değişiklikleri yapabilirsiniz. İşiniz bittiğinde depomuzda bir çekme isteği (PR) olarak açarsınız. Önerilen eklemeleriniz ve değişiklikleriniz daha sonra incelenebilir ve personel, bir şeyler yanlış ise veya iyileştirme ihtiyacı duyuluyorsa size söyleyecek ve sonuçta son PR’yi birleştirecektir.

Aşağıda, ayrıntılara girmeden önce açıklanan yordamın kısa bir özetini bulabilirsiniz:

1. İstediğin repoyu çatalla

2. Yerel makinenize kopyalayın

3. Yeni bir şube oluştur

4. İstediğiniz değişiklikleri yapın

5. Her şeyin yolunda olup olmadığını test edin

6. Değişiklikleri uygula

7. Onları GitHub’a senkronize et

8. PR’deki değişiklikleri SpongePowered Repo’ya önerin

9. Gerekirse PR’nize değiştirin

10. PR’ın senin profilin üzerinden yöneticiye ilet

Detaylar lütfen!

1. Bir Repo çatallanıyor

Not

Bu adım, yalnızca değişiklik yaptığınız repo üzerinde itme haklarınız yoksa gereklidir. Kendi reponuz üzerinde çalışıyorsanız, çatala gerek yoktur. Bu adımı atlayın ve doğrudan clone yapın. Sponge değişikliği yapıyorsanız ve personel değilseniz, bu adım gereklidir.

Artık temel konsepti bildiğinize göre ayrıntıları tartışacağız. Öncelikle, değişiklik yapmak istediğiniz depoyu çatallamanız gerekir. Bu GitHub.com’da, depolar sayfasının üst kısmında bulabileceğiniz bir yerde “Çatal” butonuyla yapılabilir. Tıkladıktan sonra, GitHub biraz iş yapacak ve orijinal repo kopyasını size sunacak. Klonun şimdi `` YourGitHubAccount / ClonedRepoName`` konumunda bulunduğunu göreceksiniz. Tamam, ilk adım tamamlandı.

Not

All branches from the original repository will get forked too, you receive an exact clone of the forked repo.

2. Çatalın Yerel Makinenize Klonlanması

Now you need to get this fork to your local machine to make your changes. Open the Git Client of your choice (Git’i kurmak) and clone your fork to your local machine. The client will ask you for a folder to store everything in. Second step finished, well done!

Not

Most steps can be done via GUI of your choice. If you’re experienced with a command line interface, then you can use it too. Each step will show you the required commands to achieve the desired result.

Alternatively, you can do this via CLI (command line interface, CMD or powershell on windows). Note that you need to create the folder everything is getting cloned to yourself before typing this command:

git clone git://github.com/YourGitHubAccount/ClonedRepoName.git

3. Yeni Şube Oluşturma

Çatalınızın yerel bir kopyasına sahip olduğunuza göre, üzerinde çalışılacak bir dal oluşturmanın zamanı geldi. dallar, eklemelerin müdahalelerinden kaynaklanan sorunlara ve hatalara neden olmaksızın aynı anda farklı özellikler veya eklemeler geliştirebilmek ve/veya test edebilmek için tasarlandı. Yaptığınız değişikliklerin master üzerinde yapılmaması önerilir. Bunun yerine kendiniz yeni bir dal oluşturun (mantıklı bir adla) ve değişiklikleri oradan yapın.

Bu ilk olarak bir bölüm oluşturmamız gerektiğini belirtir, o zaman hadi başlayalım! Bunu kullanıcı yoluyla yapabilirsin (burada bir yerde bölüm oluştur tuşu olmalı), ve ya gir ile CLI kullanabilirsin:

git checkout -b [name_of_your_new_branch]

This will create a branch with the name of your choice and switch to it. All changes you’re about to make will be on this branch. If you need to switch to another branch (for example master), just reuse this command. Third step done! Good job so far! To get an overview of your branches, just have a look at your git client or use:

git branch

Şimdi değişikliklerini yapma zamanı. Kendi isteğine bağlı bir düzenleyici yada IDE kullan.

4. Değişikliklerinin çalışıp çalışmadığını kontrol et

SpongeAPI ve çalıştırman gereken uygulamalar için gradle compileJava. Eğer hatasız bitti ise sonraki adıma geç. Eğer bitmedi ise, uygun düzeltmeleri yap ve tekrar dene.

SpongeDocs için sadece PR’ını gönderebilirsin. O otomatik kurulmuş olacak ve olası hataları ortaya çıkaracak. Başka bir seçenek ise dökümanları yerel olarak kurmaktır. Daha fazla bilgi için `<https://githup.com/SpongePowered/SpongeDocs/blob/master/README.md> üzerindeki Readme.md`_ dökümanına göz at.

5. Değişiklikleri uygula

When you’re done, you need to bundle them into a single package (a commit) and get them into the branch. Again, your git client will help you out. Add a meaningful name to your commit and a short description if needed. This can be done via CLI too:

İlk olarak bir tamamlama işlemine koymak istediğiniz tüm dosyaları ve klasörleri toplayın:

git add <file>
git add <folder>

Şimdi dosyalar senin işlemde bulunmasını istediğin değişiklik listesine eklendiğine göre, sadece yap

git commit

Arzu ederseniz mesaj ekleyebileceğiniz bir metin penceresi açılır. Aşağıdaki resme bir göz atın. İşlerinizin hala GitHub’da değil, yerel olarak saklandığını farkedeceksiniz.

Not

Bir PR’da çeşitli işlemlere sahip olabilirsin. Sadece devam et ve değiştirmen gereken her şeyi değiştir ve değişiklikleri kaydet. İşlemleri daha sonra tek bir işlem üzerinde birleştirebilirsin.

Böylece, altıncı adım tamamlandı. Neredeyse işlem bitmek üzere!

GitHub’u senkronize et

Şimdi değişiklikleri GitHub üzerindeki yere almamız gerekiyor. Şimdiye kadar yaptığın her şey sadece yerel olarak depolandı. Her zamanki gibi, git hesabını kullanabilirsin bunu yapmak için (senin GUI’nde bir tuş var), yada işlemini CLI yardımıyla yapabilirsin:

git push <remote> <branch>

Bu durumda olmalı:

git push origin feature/YourFeature

7. PR’deki değişiklikleri SpongePowered hesabına gönderin

You can either go to your forks page on GitHub.com (there should be a notice at the top of your forks page to guide you), or you can use your GitHub client to create a pull-request. The official GitHub for Win client uses the top right corner of the window for this.

8. PR’ını gerekli ise düzelt

Eğer biz senin PR’ına değişiklik yapılmasını istiyorsak, yukarıda oluşturulan bölüme daha fazla işlem yapman gerekir. Yapılan işlemler otomatik olarak PR’ına eklenmiş olacaktır.

9. senin PR çekti

İşte böyle. Her şey ayarlandı! Büyük iş!

İleri Git

Rebase ile araştırmak

Let’s say you have finished your additions to the repo, and let’s pretend that you made 137 commits while getting it done. Your commit history will certainly look cluttered. It would be a shame if they were all recorded into the repo, wouldn’t it? Too many trivial commits also clutters the project commit history. Fortunately, Git has a nice tool to circumvent this, it’s called a rebase. Rebasing can take your 137 small commits and just turn them into one big commit. Awesome, isn’t it? Instead of reinventing the wheel, we’ll just pass you a link to a very short and easily understandable squashing tutorial:

‘ Gitready: Rebase ile < http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html > ezici ‘ _

Bu ne, güzel görüntülenir.

Bir uzaktan kurma

Naturally the original repo is the direct parent of your fork and your fork is the direct parent of your local clone. However, the original repo isn’t the direct parent of your clone. This isn’t a problem in the first place, but it prevents you from updating your clone to the latest changes on the original repo. If you setup the original repo as a remote (read: “parent”) of your clone, you’ll be able to grab all changes made to this repo and apply it to your local clone. Look below to see how grabbing and updating works.

Tamam. Çoğu GUI’leri (oldukça gelişmiş) bu işlevi eksik gibi bu adımı CLI yapılır:

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

Bunun planlandığı gibi çalışıp çalışmadığından emin değilseniz veya şu anda hangi uzaktan kumandanın ayarlandığını kontrol etmek isterseniz şu yollarla kontrol edebilirsiniz:

git remote -v

çıkış gibi görünmelidir:

origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

Not

Uyarıyı görürseniz ‘’ ölümcül: Geçerli dalı YourBranchName ters yönde hiçbir şube. vardır ‘’, şube ters yönde uzaktan kumandanızda olmayabilir sonra. Bu bu ilk defa ise yeni dal için bir yürütme bastırıyorlar ortaya çıkabilir. Geçerli dalı itmek ve Uzaktan akış yukarı olarak ayarlamak için ‘’ git itme–kümesi ters yönde kökenli YourBranchName’’ kullanın.

Tekrar kur

İstediğiniz dalda bazı değişiklikler yaptınız ama bu arada depo’da başka biri tarafından güncellendi. Bu, çatalınız ve klonunuzun modası geçmiş olduğu anlamına gelir. Bu büyük bir sorun değil, ancak eklemelerinizi daha sonra birleştireceğinizde sorunlardan kaçınmak için, orijinal repo üzerindeki en son değişikliklere karşı yaptığınız değişiklikleri rebase’lemek şiddetle tavsiye edilir. Uzak depo’yu daha henüz kurmadıysanız, rebase’e başlamadan önce yapın.

A successful rebase requires several steps:

1. Değişiklikleri Remote Repo içinde kaydet

İlk olarak değişiklikleri uzak depo üzerine getirmen gerekiyor. Bu da (yine) CLI yöntemiyle tamamlanır:

git fetch upstream

Bu uygulama upstream den bütün değişiklikleri ekleyecek ve onları geçici olarak upstream/master deposu içinde saklayacak.

2. uzaktan değişiklikleri yerel olarak Birleştir

Artık yerel ‘’ ana ‘’ şubemiz seçmeniz gerekir:

git checkout master

Ondan sonra biz ‘’ ters yönde/ana ‘’ yerel ‘’ ana ‘’ şubemiz dahil edilen değişiklikleri birleştirmek:

git merge upstream/master

Tamam, bu defa yaptığımız şeyi.

3. Yerel şube Güncellenme Zamanı Master karşı rebase

Sonraki kadar yerel ‘’ ana ‘’ karşı çalıştığınız Yerel şube rebasing. Senin çalışma şube geçmeniz gerekir (burada: ‘’ özelliği/yourfeature”) ve bir rebase gerçekleştirin. Bu üzerinden yapılır:

git checkout feature/yourfeature
git rebase master

Bu senin şube geri sarma, iptalleri ustadan eklemek ve kendi değişikliklerinizi yeniden uygulayın. Sonuç şuna benzer:

4. Çatalınıza Herşeyi İtin

Yapmamız gereken son şey her şey için çatal bas etmektir. Bir PR zaten oluşturduysanız, bu otomatik olarak güncel:

git checkout master
git push -f
git checkout feature/yourfeature
git push -f

Başardın, harika! İyi bir iş ve iyi yapılmış ve Rebase-hava uçtuğunuz için teşekkürler!