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:
İ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
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!