Gerekli girişler:
- Git hakkındaki makalemi okuyun, takip edin ve anlayın . Bu, her şeyin kurulu ve kullanıma hazır olduğundan emin olmanıza yardımcı olacaktır.
- IntelliJ IDEA'yı kurun.
- Tam ustalık elde etmek için bir saatlik kişisel zaman ayırın.
Projeyi yerel olarak klonlayınBurada iki seçenek vardır:
- Halihazırda bir GitHub hesabınız varsa ve daha sonra bir şeyi zorlamak istiyorsanız, projeyi çatallamak ve kendi kopyanızı klonlamak daha iyidir.
- Depomu klonlayın ve her şeyi sunucuya itme yeteneği olmadan her şeyi yerel olarak yapın. Sonuçta burası benim arşivim :)
-
Proje adresini kopyalayın:
-
IntelliJ IDEA'yı açın ve "Sürüm Kontrolünden Al"ı seçin:
-
Proje adresini kopyalayıp yapıştırın:
-
Bir IntelliJ IDEA projesi oluşturmanız istenecektir. Teklifi kabul et:
-
Derleme sistemi olmadığından ve bu, bu makalenin kapsamı dışında olduğundan, Mevcut kaynaklardan proje oluştur'u seçiyoruz :
-
Sonra bu güzel ekranı göreceksiniz: Artık klonlamayı çözdüğümüze göre, etrafa bir göz atabilirsiniz.
Git kullanıcı arabirimi olarak IntelliJ IDEA'ya ilk bakışKlonlanan projeye daha yakından bakın: sürüm kontrol sistemi hakkında zaten birçok bilgi edinebilirsiniz. İlk olarak, sol alt köşede Sürüm Kontrol bölmesine sahibiz . Burada tüm yerel değişiklikleri bulabilir ve taahhütlerin bir listesini alabilirsiniz ("git log"a benzer). Log tartışmasına geçelim . Geliştirmenin tam olarak nasıl ilerlediğini anlamamıza yardımcı olan belirli bir görselleştirme var. Örneğin, txt commit'e eklenmiş bir başlıkla yeni bir dalın oluşturulduğunu ve bunun daha sonra ana dalda birleştirildiğini görebilirsiniz . Bir taahhüdü tıklarsanız, sağ köşede taahhütle ilgili tüm bilgileri görebilirsiniz: tüm değişiklikleri ve meta verileri.Ayrıca, gerçek değişiklikleri görebilirsiniz. Orada da bir ihtilafın çözüldüğünü görüyoruz. IDEA da bunu çok iyi sunuyor. Bu taahhüt sırasında değiştirilen dosyaya çift tıklarsanız, çakışmanın nasıl çözüldüğünü göreceğiz: Solda ve sağda aynı dosyanın birleştirilmesi gereken iki versiyonu olduğunu not ediyoruz. Ve ortada, nihai birleştirilmiş sonuca sahibiz. Bir projede birçok şube, commit ve kullanıcı varsa şube, kullanıcı ve tarihe göre ayrı ayrı arama yapmak gerekiyor: Başlamadan önce anlatmak istediğim son şey hangi şubede olduğumuzu nasıl anlayacağımız. anlamak için bir dakika... Buldun mu? Pes etmek? :D Sağ alt köşede Git:master diye bir buton var. "Git:"ten sonra gelen her şey geçerli daldır. Düğmeye tıklarsanız pek çok faydalı şey yapabilirsiniz: başka bir şubeye geçin, yeni bir şube oluşturun, mevcut bir şubeyi yeniden adlandırın vb.
Bir depo ile çalışma
Yararlı kısayol tuşlarıGelecekteki çalışmalar için birkaç çok yararlı kısayol tuşunu hatırlamanız gerekir:
- CTRL+T — Uzak havuzdan en son değişiklikleri alın (git çekme).
- CTRL+K — Bir taahhüt oluştur / mevcut tüm değişiklikleri gör. Bu, hem izlenmeyen hem de değiştirilen dosyaları içerir (bunu açıklayan git hakkındaki makaleme bakın) (git commit).
- CTRL+SHIFT+K — Bu, değişiklikleri uzak havuza gönderme komutudur. Yerel olarak oluşturulan ve henüz uzak depoda olmayan tüm taahhütler gönderilir (git push).
- ALT+CTRL+Z — Belirli bir dosyadaki değişiklikleri, yerel depoda oluşturulan son işlemin durumuna geri alın. Sol üst köşede tüm projeyi seçerseniz, tüm dosyalardaki değişiklikleri geri alabilirsiniz.
Ne istiyoruz?İşi bitirmek için her yerde kullanılan temel bir senaryoda ustalaşmamız gerekiyor. Amaç, yeni işlevselliği ayrı bir dalda uygulamak ve ardından onu uzak bir depoya iletmektir (daha sonra ana şubeye bir çekme isteği de oluşturmanız gerekir, ancak bu, bu makalenin kapsamı dışındadır). Bunu yapmak için ne gerekli?
-
Ana daldaki tüm mevcut değişiklikleri alın (örneğin, "master").
-
Bu ana şubeden işiniz için ayrı bir şube oluşturun.
-
Yeni işlevselliği uygulayın.
-
Ana şubeye gidin ve biz çalışırken herhangi bir yeni değişiklik olup olmadığını kontrol edin. Değilse, o zaman her şey yolunda. Ancak değişiklikler varsa, o zaman aşağıdakileri yaparız: çalışan şubeye gidin ve değişiklikleri ana şubeden bizimkine yeniden temellendirin. Her şey yolunda giderse, o zaman harika. Ancak çatışmaların olması tamamen mümkündür. Olduğu gibi, uzak depoda zaman kaybetmeden önceden çözülebilirler.
Bunu neden yapmanız gerektiğini merak ediyor musunuz? Bu iyi bir davranıştır ve şubenizi yerel depoya gönderdikten sonra çatışmaların oluşmasını önler (tabii ki çatışmaların yine de olma olasılığı vardır, ancak çok daha küçük hale gelir).
- Değişikliklerinizi uzak depoya aktarın.
Değişiklikler uzak sunucudan alınsın mı?README'ye yeni bir taahhütle bir açıklama ekledim ve bu değişiklikleri almak istiyorum. Hem yerel depoda hem de uzak depoda değişiklikler yapıldıysa, birleştirme ve yeniden temellendirme arasında seçim yapmaya davet ediliriz. birleştirmeyi seçiyoruz. CTRL+T girin : Artık BENİOKU'nun nasıl değiştiğini görebilirsiniz, yani uzak havuzdaki değişiklikler çekildi ve sağ alt köşede sunucudan gelen değişikliklerin tüm ayrıntılarını görebilirsiniz.
Master'a dayalı yeni bir şube oluşturBurada her şey basit.
-
Sağ alt köşeye gidin ve Git: master'ı tıklayın . + Yeni Şube öğesini seçin .
Checkout şubesi onay kutusunu seçili bırakın ve yeni şubenin adını girin. Benim için readme-improver olacak .
Git: master daha sonra Git: readme-improver olarak değişecektir .
Paralel çalışmayı simüle edelimÇatışmaların ortaya çıkması için, birisinin onları yaratması gerekir :D BENİOKU'yu tarayıcı aracılığıyla yeni bir taahhütle düzenleyeceğim, böylece paralel çalışmayı simüle edeceğim. Sanki ben üzerinde çalışırken biri aynı dosyada değişiklik yapmış gibi. Sonuç bir çatışma olacaktır. 10. satırdan "fully" kelimesini kaldıracağım.
İşlevlerimizi uygulayınGörevimiz BENİOKU'yu değiştirmek ve yeni makaleye bir açıklama eklemek. Yani Git'teki çalışma IntelliJ IDEA'dan geçer. Bunu ekleyin: Değişiklikler yapılır. Şimdi bir taahhüt oluşturabiliriz. CTRL+K tuşlarına basarak bize şunu verir: Bir taahhüt oluşturmadan önce, bu pencerenin neler sunduğuna yakından bakmamız gerekir. Nereye bakacağınızı göstermek için kırmızı oklar ekledim. Burada çok ilginç şeyler var. Commit Message bölümünde commit ile ilgili text yazıyoruz. Sonra onu oluşturmak için Commit'e tıklamamız gerekiyor.. Bunu bir kısayol tuşuyla nasıl yapacağımı hala öğrenemedim. Birisi nasıl olduğunu öğrenirse, lütfen bana yaz - bu beni çok mutlu eder. README'nin değiştiğini yazıp commit'i oluşturuyoruz. Sol alt köşede, taahhüdün adıyla bir uyarı açılır:
Ana dalın değişip değişmediğini kontrol edinGörevimizi tamamladık. İşe yarıyor. Testler yazdık. Herşey yolunda. Ancak sunucuya göndermeden önce, bu arada ana dalda herhangi bir değişiklik olup olmadığını kontrol etmemiz gerekiyor. Bu nasıl olabilir? Oldukça kolay: Birisi sizden sonra bir görev alıyor ve bu kişi görevi sizin tamamlamanızdan daha hızlı bitiriyor. Yani master şubeye gitmemiz gerekiyor. Bunu yapmak için aşağıdaki ekran görüntüsünde sağ alt köşede gösterileni yapmamız gerekiyor: Ana dalda, uzak sunucudan en son değişikliklerini almak için CTRL+T tuşlarına basın. Değişikliklere baktığınızda, ne olduğunu kolayca görebilirsiniz:"fully" kelimesi kaldırıldı. Belki de pazarlamadan biri bunun böyle yazılmaması gerektiğine karar verdi ve geliştiricilere onu güncelleme görevi verdi. Artık ana dalın en son sürümünün yerel bir kopyasına sahibiz. Readme-improver'a geri dönün . Şimdi değişiklikleri ana şubeden bizimkine yeniden temellendirmemiz gerekiyor. Bunu yapıyoruz: Her şeyi doğru yaptıysanız ve benimle birlikte takip ettiyseniz, sonuç README dosyasında bir çakışma göstermelidir: Burada ayrıca anlamamız ve özümsememiz gereken birçok bilgi var. Burada gösterilen, çakışmaları olan dosyaların (bizim durumumuzda bir dosya) listesidir. Üç seçenek arasından seçim yapabiliriz:
- sizinkini kabul edin — yalnızca beni oku geliştiriciden gelen değişiklikleri kabul edin.
- onlarınkini kabul et — yalnızca anadan gelen değişiklikleri kabul et.
- birleştir — neyi saklamak ve neyi atmak istediğinizi kendiniz seçin.
- Bunlar, beni oku iyileştirmeden gelen değişikliklerdir.
- Birleştirilmiş sonuç. Şimdilik, değişikliklerden önce var olan şey bu.
- Ana daldaki değişiklikler.