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

Bu kılavuz, Git’i kurmak komutunu okuduğunuzu ve makinenizi seçtiğiniz bir Git istemcisiyle kurduğunuzu varsayıyor.

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

Orijinal depodaki tüm şubeler de çatallanacak, çatallı Repo’nun tam bir kopyasını alacaksınız.

2. Çatalın Yerel Makinenize Klonlanması

Değişikliklerinizi yapmak için şimdi bu çatalı yerel makinenize almalısınız. İstediğiniz Git İstemcisini (:doc: ../preparing /git) açın ve çatalını yerel makinenize getirin. Müşteri, her şeyi saklamak için bir klasör isteyecektir. İkinci adım tamamlandı, aferin!

Not

Çoğu adım, seçtiğiniz GUI vasıtasıyla yapılabilir. Bir komut satırı arayüzünde deneyimliyseniz, o zaman onu da kullanabilirsiniz. Her adımda istediğiniz sonuca ulaşmak için gerekli komutlar gösterilir.

Alternatif olarak bunu CLI yöntemi ile yapabilirsin ( komut satırı arayüzü, CMD veya powershell windows üzerinde). Bu komutu girmeden önce her şeyin kopyalanacağı bir klasör oluşturmanız gerekmektedir:

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]

Bu kendi seçtiğin isimle bir bölüm oluşturacak ve ona geçiş yapacak. Yapacak olduğun tüm değişiklikler bu bölümde olacak. Eğer başka bir bölüme geçiş yapma ihtiyacı duyuyorsan ( örneğin master), sadece bu komutu tekrar kullan. Üçüncü adım tamamlandı! Şu zamana kadar iyi iş çıkardın! Bölümlerinin genel bir taslağını almak için, sadece git kullanıcısına bir göz at yada kullan:

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

İşiniz bittiğinde onları tek bir paket (bir ‘’ taahhüt ‘’) paket ve onları dalı almak gerekir. Tekrar git müşteri size yardımcı olur. Anlamlı bir ad gerekirse, yürütme ve kısa bir açıklama ekleyin. Bu CLI de yapılabilir:

İ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

GitHub.com’daki çatal sayfanıza gidebilirsiniz (çatal sayfanızın üst kısmında size rehberlik edecek bir uyarı olmalıdır) veya bir çekme isteği oluşturmak için GitHub istemcisini kullanabilirsiniz. WinHelper’in resmi GitHub uygulaması bunun için pencerenin sağ üst köşesini kullanır.

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

Diyelim ki repoya eklemelerinizi bitirdiniz ve işi bitirirken 137 adet işlemede bulunduğunuzu varsayalım. işleme geçmişiniz kesinlikle karışık görünüyor. Repoya kaydedilirlerse, utanç verici olurdu, değil mi? Çok önemsiz işlemeler, proje işleme tarihini karmaşıklaştırmaktadır. Şans eseri Git, bunun önüne geçmek için güzel bir araç buluyor; buna rebase deniyor. 137 adet küçük taahhüdünü alabilir ve sadece onları büyük bir taahhüt haline getirebilir. Harika, değil mi? Tekerleği yeniden icat etmek yerine size kısa ve kolay anlaşılır bir squash eğitimine bir bağlantı gönderelim:

‘ 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

Doğal olarak orijinal depo çatalınızın doğrudan ebeveyni, çatalı ise yerel kopyanızın doğrudan ebeveyni. Bununla birlikte orijinal depo klonunun doğrudan ebeveyni değildir. İlk etapta sorun değil, ancak klonunuzu orijinal depo’daki en son değişikliklere güncellemenizi engelliyor. Orijinal depo’yu klonunuzun uzaktan kumandası olarak ayarlarsanız (read: “parent”), bu repo üzerinde yapılan tüm değişiklikleri alıp yerel klonunuza uygulayabilirsiniz. Yakalamanın ve güncellemenin nasıl çalıştığını görmek için aşağıya bakın.

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.

Başarılı bir kurulum için çeşitli adımları gerektirir:

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!