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:
İstediğin repoyu çatalla
Yerel makinenize kopyalayın
Yeni bir şube oluştur
İstediğiniz değişiklikleri yapın
Her şeyin yolunda olup olmadığını test edin
Değişiklikleri uygula
Onları GitHub’a senkronize et
PR’deki değişiklikleri SpongePowered Repo’ya önerin
Gerekirse PR’nize değiştirin
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!