1. Yeni başlayanlar için ayrıntılı bir Git kılavuzu

Bugün bir sürüm kontrol sistemi olan Git'ten bahsedeceğiz.

Bu aracı bilmeden ve anlamadan gerçekten tam teşekküllü bir programcı olamazsınız. Tabii ki, sürekli çalışmak için tüm Git komutlarını ve özelliklerini kafanızda tutmanıza gerek yok. Olan her şeyi anlamanıza yardımcı olacak bir dizi komut bilmeniz gerekir.

Git'in temelleri

Git, kodumuz için dağıtılmış bir sürüm kontrol sistemidir. Neden buna ihtiyacımız var? Ekipler işlerini yönetmek için bir tür sisteme ihtiyaç duyarlar. Zaman içinde meydana gelen değişiklikleri izlemek için gereklidir.

Yani hangi dosyaların nasıl değiştiğini adım adım görebilmemiz gerekiyor. Bu, özellikle tek bir görev bağlamında nelerin değiştiğini araştırırken önemlidir ve değişiklikleri geri almayı mümkün kılar.

Şu durumu hayal edelim: çalışan bir kodumuz var, içindeki her şey iyi, ama sonra bir şeyi geliştirmeye veya değiştirmeye karar veriyoruz. Önemli değil, ancak "geliştirmemiz" programın özelliklerinin yarısını bozdu ve çalışmayı imkansız hale getirdi. Şimdi ne olacak? Git olmasaydı, oturup her şeyin başlangıçta nasıl olduğunu hatırlamaya çalışarak saatlerce düşünmeniz gerekirdi. Ancak Git ile taahhüdü geri alıyoruz - hepsi bu.

Veya aynı anda kendi kod değişikliklerini yapan iki geliştirici varsa ne olur? Git olmadan orijinal kod dosyalarını kopyalar ve ayrı ayrı değiştirirler. Her ikisinin de değişikliklerini ana dizine eklemek istedikleri bir zaman gelir. Bu durumda ne yaparsın?

Git kullanıyorsanız böyle bir sorun olmayacak.

Git'i Yükleme

Bilgisayarınıza Java yükleyelim Bu işlem, farklı işletim sistemleri için biraz farklılık gösterir.

Windows'a yükleme

Her zamanki gibi, bir exe dosyası indirmeniz ve çalıştırmanız gerekir. Burada her şey basit: ilk Google bağlantısını tıklayın , kurulumu gerçekleştirin ve hepsi bu. Bunu yapmak için Windows tarafından sağlanan bash konsolunu kullanacağız.

Windows'ta Git Bash'i çalıştırmanız gerekir. Başlat Menüsünde şöyle görünür:

Şimdi bu, birlikte çalışabileceğiniz bir komut istemidir.

Git'i orada açmak için her seferinde projeyle birlikte klasöre gitmek zorunda kalmamak için, ihtiyacımız olan yolla proje klasöründeki komut istemini farenin sağ tuşuyla açabilirsiniz:

Linux'ta Kurulum

Genellikle Git, Linux dağıtımlarının bir parçasıdır ve orijinal olarak Linux çekirdek geliştirmesi için yazılmış bir araç olduğu için zaten kuruludur. Ancak olmadığı durumlar vardır. Kontrol etmek için bir terminal açmanız ve şunu yazmanız gerekir: git --version. Anlaşılır bir yanıt alırsanız, hiçbir şeyin yüklenmesi gerekmez.

Bir terminal açın ve kurun. Ubuntu için şunu yazmanız gerekir: sudo apt-get install git. İşte bu kadar: Artık Git'i herhangi bir terminalde kullanabilirsiniz.

macOS'ta yükleme

Burada da önce Git'in orada olup olmadığını kontrol etmeniz gerekir (yukarıya bakın, Linux'ta olduğu gibi).

Elinizde yoksa, onu almanın en kolay yolu en son sürümü indirmektir . Xcode kuruluysa, Git kesinlikle otomatik olarak kurulacaktır.

Git ayarları

Git, işi gönderecek kullanıcı için kullanıcı ayarlarına sahiptir. Bu mantıklı ve gereklidir, çünkü Git bir taahhüt oluşturulduğunda Yazar alanı için bu bilgiyi alır.

Aşağıdaki komutları çalıştırarak tüm projeleriniz için bir kullanıcı adı ve parola oluşturun:

Belirli bir proje için (örneğin kişisel bir proje için) yazarını değiştirmeniz gerekirse, "--global" ifadesini kaldırabilirsiniz. Bu bize aşağıdakileri verecektir:

biraz teori

Konuya dalmak için sizi birkaç yeni kelime ve eylemle tanıştırmalıyız... Aksi takdirde konuşacak bir şey kalmayacak. Tabii bu bize İngilizce'den gelen bir jargon, bu yüzden parantez içinde çevirileri ekleyeceğim.

Hangi sözler ve eylemler?

• git deposu
• işlemek
• dal
• birleştirmek
• çatışmalar
• çekmek
• itmek
• bazı dosyalar nasıl yoksayılır (.gitignore)

Ve benzeri.

Git'teki durumlar

Git'in anlaşılması ve hatırlanması gereken birkaç statüsü vardır:

• izlenmemiş
• değiştirilmiş
• sahnelenmiş
• bağlılık

Bunu nasıl anlamalısınız?

Bunlar, kodumuzu içeren dosyalara uygulanan durumlardır. Başka bir deyişle, yaşam döngüleri genellikle şöyle görünür:

• Oluşturulan ancak depoya henüz eklenmemiş bir dosyanın durumu "izlenmemiş" olur.
• Git deposuna zaten eklenmiş olan dosyalarda değişiklik yaptığımızda, durumları "değiştirildi".
• Değiştirdiğimiz dosyalar arasından ihtiyacımız olanları seçiyoruz (örneğin derlenmiş sınıflara ihtiyacımız yok) ve bu sınıflar "staged" durumuna geçiyor.
• Aşamalı durumda hazırlanan dosyalardan bir taahhüt oluşturulur ve Git deposuna gider. Bundan sonra, "aşamalı" durumdaki dosya yok. Ancak durumu "değiştirilmiş" olan dosyalar olabilir.

İşte böyle görünüyor:

taahhüt nedir?

Sürüm kontrolü söz konusu olduğunda ana olay bir taahhüttür. Taahhüt başladığından beri yapılan tüm değişiklikleri içerir. Taahhütler, tek bağlantılı bir liste gibi birbirine bağlanır.

Spesifik olarak, bir ilk taahhüt vardır. İkinci taahhüt oluşturulduğunda, (ikincisi) birinciden sonra ne geldiğini bilir. Ve bu şekilde bilgiler takip edilebilir.

Bir taahhüdün ayrıca meta veriler adı verilen kendi bilgileri vardır:

• taahhüdün onu bulmak için kullanılabilecek benzersiz tanımlayıcısı
• onu oluşturan taahhüdün yazarının adı
• taahhüdün oluşturulduğu tarih
• taahhüt sırasında ne yapıldığını açıklayan bir yorum

İşte nasıl göründüğü:

şube nedir?

Şube, bazı taahhütlerin göstergesidir. Bir taahhüt, hangi taahhüdün kendisinden önce geldiğini bildiğinden, bir şube bir taahhüdü işaret ettiğinde, önceki tüm taahhütler de ona uygulanır.

Buna göre aynı commite işaret ederek istediğiniz kadar şubeye sahip olabilirsiniz diyebiliriz.

İş şubelerde gerçekleşir, bu nedenle yeni bir taahhüt oluşturulduğunda, şube işaretçisini daha yeni taahhüde taşır.

Git'e başlarken

Yalnızca yerel bir havuzla çalışabileceğiniz gibi uzak bir depoyla da çalışabilirsiniz.

Gerekli komutları uygulamak için kendinizi yerel depoyla sınırlayabilirsiniz. Yalnızca tüm proje bilgilerini yerel olarak .git klasöründe depolar.

Uzak depodan bahsediyorsak, tüm bilgiler uzak sunucuda bir yerde depolanır: yerel olarak projenin yalnızca bir kopyası depolanır. Yerel kopyanızda yapılan değişiklikler uzak depoya gönderilebilir (git push).

Buradaki ve aşağıdaki tartışmamızda, konsolda Git ile çalışmaktan bahsediyoruz. Tabii ki, bir tür GUI tabanlı çözüm kullanabilirsiniz (örneğin, IntelliJ IDEA), ancak önce hangi komutların yürütüldüğünü ve bunların ne anlama geldiğini anlamalısınız.

Yerel bir depoda Git ile çalışma

Yerel bir havuz oluşturmak için şunu yazmanız gerekir:

Bu, konsolun geçerli dizininde gizli bir .git klasörü oluşturacaktır.

.git klasörü, Git deposuyla ilgili tüm bilgileri saklar. silmeyin ;)

Ardından, dosyalar projeye eklenir ve bunlara "İzlenmeyen" durumu atanır. Çalışmanızın mevcut durumunu kontrol etmek için şunu yazın:

Ana şubedeyiz ve başka bir şubeye geçene kadar burada kalacağız.

Bu, hangi dosyaların değiştiğini ancak henüz "aşamalı" durumuna eklenmediğini gösterir. Bunları "staged" durumuna eklemek için "git add" yazmanız gerekir. Burada birkaç seçeneğimiz var, örneğin:

• git add -A - tüm dosyaları "aşamalı" durumuna ekler
• git ekle . — bu klasördeki tüm dosyaları ve tüm alt klasörleri ekleyin. Esasen bir öncekiyle aynı;
• git add <file name> — belirli bir dosya ekler. Burada, bazı kalıplara göre dosya eklemek için normal ifadeleri kullanabilirsiniz. Örneğin, git add *.java: Bu, yalnızca java uzantılı dosyaları eklemek istediğiniz anlamına gelir.

İlk iki seçenek açıkça basittir. Son eklemeyle işler daha da ilginçleşiyor, o yüzden yazalım:

Durumu kontrol etmek için zaten bildiğimiz komutu kullanıyoruz:

Burada normal ifadenin doğru çalıştığını görebilirsiniz: test_resource.txt artık "aşamalı" durumdadır.

Ve son olarak, yerel bir havuzla çalışmanın son aşaması (uzak depoyla çalışırken bir tane daha vardır;)) — yeni bir taahhüt oluşturmak:

Sırada, bir daldaki taahhüt geçmişine bakmak için harika bir komut var. Bundan yararlanalım:

Burada ilk taahhüdümüzü oluşturduğumuzu ve komut satırında sağladığımız metni içerdiğini görebilirsiniz. Bu metnin, bu taahhüt sırasında ne yapıldığını olabildiğince doğru bir şekilde açıklaması gerektiğini anlamak çok önemlidir. Bu gelecekte bize birçok kez yardımcı olacaktır.

Henüz uyumamış meraklı bir okuyucu, GitTest.java dosyasına ne olduğunu merak ediyor olabilir. Hemen öğrenelim. Bunu yapmak için şunları kullanıyoruz:

Gördüğünüz gibi hala "takip edilmemiş" durumda ve kanatlarda bekliyor. Peki ya onu projeye hiç eklemek istemiyorsak? Bazen bu olur.

İşleri daha ilginç hale getirmek için şimdi test_resource.txt dosyamızı değiştirmeye çalışalım. Oraya biraz metin ekleyelim ve durumu kontrol edelim:

Burada "izlenmemiş" ve "değiştirilmiş" durumları arasındaki farkı açıkça görebilirsiniz.

GitTest.java "takip edilmemiştir", test_resource.txt ise "değiştirilmiştir".

Artık değiştirilmiş durumda dosyalarımız olduğuna göre, üzerlerinde yapılan değişiklikleri inceleyebiliriz. Bu, aşağıdaki komut kullanılarak yapılabilir:

Yani metin dosyamıza ne eklediğimi burada açıkça görebilirsiniz: merhaba dünya!

Değişikliklerimizi metin dosyasına ekleyelim ve bir taahhüt oluşturalım:

Tüm taahhütlere bakmak için şunu yazın:

Gördüğünüz gibi, artık iki taahhüdümüz var.

GitTest.java'yı da aynı şekilde ekleyeceğiz. Burada yorum yok, sadece komutlar:

.gitignore ile çalışmak

Açıkçası, depoda yalnızca kaynak kodunu ve başka hiçbir şeyi tutmak istemiyoruz. Peki başka ne olabilir? En azından, geliştirme ortamları tarafından oluşturulan derlenmiş sınıflar ve/veya dosyalar.

Git'e onları yok saymasını söylemek için özel bir dosya oluşturmamız gerekiyor. Bunu yapın: projenin kök dizininde .gitignore adlı bir dosya oluşturun. Bu dosyadaki her satır, yok sayılacak bir modeli temsil eder.

Bu örnekte, .gitignore dosyası şöyle görünecektir:

Hadi bir bakalım:

• İlk satır, .class uzantılı tüm dosyaları yok saymaktır.
• İkinci satır, "hedef" klasörü ve içerdiği her şeyi yok saymaktır.
• Üçüncü satır, .iml uzantılı tüm dosyaları yok saymaktır.
• Dördüncü satır, .idea klasörünü yok saymaktır.

Bir örnek kullanmayı deneyelim. Nasıl çalıştığını görmek için derlenmiş GitTest.class'ı projeye ekleyelim ve proje durumunu kontrol edelim:

Açıkçası, derlenmiş sınıfı bir şekilde yanlışlıkla projeye eklemek istemiyoruz (git add -A kullanarak). Bunu yapmak için bir .gitignore dosyası oluşturun ve daha önce açıklanan her şeyi ekleyin:

Şimdi .gitignore dosyasını projeye eklemek için bir taahhüt kullanalım:

Ve şimdi gerçek anı: Git deposuna eklemek istemediğimiz, "takip edilmeyen" derlenmiş bir GitTest.class sınıfımız var.

Şimdi .gitignore dosyasının etkilerini görmeliyiz:

Mükemmel! .gitignore +1 :)

Şubelerle çalışma

Doğal olarak, tek bir geliştirici için tek bir şubede çalışmak sakıncalıdır ve bir ekipte birden fazla kişi olduğunda bu imkansızdır. Bu nedenle şubelerimiz var.

Şube, taahhütler için yalnızca taşınabilir bir işaretçidir.

Bu bölümde, farklı dallarda çalışmayı keşfedeceğiz: değişikliklerin bir daldan diğerine nasıl birleştirileceğini, hangi çatışmaların ortaya çıkabileceğini ve çok daha fazlasını.

Depodaki tüm şubelerin bir listesini görmek ve hangisinde olduğunuzu anlamak için şunu yazmanız gerekir:

Gördüğünüz gibi sadece bir master şubemiz var. Önündeki yıldız işareti, içinde olduğumuzu gösterir. Bu arada hangi şubede olduğumuzu öğrenmek için "git status" komutunu da kullanabilirsiniz.

Daha sonra dal oluşturmak için birkaç seçenek vardır (daha fazlası olabilir — benim kullandıklarım bunlar):

• içinde bulunduğumuz şubeye göre yeni bir şube oluştur (vakaların %99'u)
• belirli bir taahhüde dayalı bir şube oluşturun (vakaların %1'i)

Belirli bir taahhüde dayalı bir dal oluşturalım

Taahhüdün benzersiz tanımlayıcısına güveneceğiz. Bulmak için şunu yazıyoruz:

"Merhaba dünya eklendi..." yorumuyla taahhüdü vurguladık Benzersiz tanımlayıcısı 6c44e53d06228f888f2f454d3cb8c1c976dd73f8'dir. Bu taahhütten başlayan bir "geliştirme" dalı oluşturmak istiyoruz. Bunu yapmak için şunu yazıyoruz:

Ana şubeden yalnızca ilk iki taahhütle bir şube oluşturulur. Bunu doğrulamak için önce farklı bir şubeye geçtiğimizden emin oluyoruz ve oradaki taahhüt sayısına bakıyoruz:

Ve beklendiği gibi, iki taahhüdümüz var. Bu arada, burada ilginç bir nokta var: Bu dalda henüz bir .gitignore dosyası yok, bu nedenle derlenmiş dosyamız (GitTest.class) artık "izlenmemiş" durumuyla vurgulanıyor.

Şimdi şunu yazarak şubelerimizi tekrar gözden geçirebiliriz:

İki şube olduğunu görebilirsiniz: "usta" ve "geliştirme". Şu anda geliştirme aşamasındayız.

Mevcut olana göre bir şube oluşturalım

Bir dal oluşturmanın ikinci yolu, onu başka bir daldan oluşturmaktır. Ana şubeye dayalı bir şube oluşturmak istiyoruz. İlk önce ona geçmemiz gerekiyor ve sonraki adım yeni bir tane oluşturmak. Hadi bir bakalım:

• git checkout master — ana dala geçiş yapın
• git durumu - aslında ana dalda olduğumuzu doğrulayın

Burada ana şubeye geçtiğimizi, .gitignore dosyasının etkin olduğunu ve derlenen sınıfın artık "izlenmemiş" olarak vurgulanmadığını görebilirsiniz.

Şimdi ana dalı temel alan yeni bir dal oluşturuyoruz:

Bu dalın "master" ile aynı olup olmadığından emin değilseniz, "git log" komutunu çalıştırarak ve tüm taahhütlere bakarak kolayca kontrol edebilirsiniz. Dört tane olmalı.

Çatışma çözümü

Çatışmanın ne olduğunu keşfetmeden önce, bir dalı diğeriyle birleştirmekten bahsetmemiz gerekiyor.

Bu resim, bir dalı diğerine birleştirme sürecini göstermektedir:

Burada bir ana şubemiz var. Bir noktada, ana daldan ikincil bir dal oluşturulur ve sonra değiştirilir. İş bittiğinde, bir dalı diğerine birleştirmeliyiz.

Örneğimizde, feature/update-txt-files dalını oluşturduk. Şube adından da anlaşılacağı gibi, metni güncelliyoruz.

Şimdi bu iş için yeni bir taahhüt oluşturmamız gerekiyor:

Şimdi, feature/update-txt-files dalını master'da birleştirmek istiyorsak, master'a gidip "git merge feature/update-txt-files" yazmamız gerekiyor:

Sonuç olarak, ana şube artık feature/update-txt-files'a eklenen taahhüdü de içeriyor.

Bu işlevsellik, bir özellik dalını silebilmeniz için eklenmiştir. Bunu yapmak için şunu yazıyoruz:

Durumu karmaşıklaştıralım: şimdi txt dosyasını yeniden değiştirmeniz gerektiğini varsayalım. Ama şimdi bu dosya master dalında da değiştirilecek. Başka bir deyişle, paralel olarak değişecektir. Git, yeni kodumuzu ana dalda birleştirmek istediğimizde ne yapacağımızı çözemeyecektir.

Master'a dayalı yeni bir dal oluşturacağız, text_resource.txt dosyasında değişiklikler yapacağız ve bu iş için bir taahhüt oluşturacağız:

... dosyada değişiklikler yapıyoruz

Ana şubeye gidin ve ayrıca bu metin dosyasını özellik şubesindekiyle aynı satırda güncelleyin:

… test_resource.txt dosyasını güncelledik

Ve şimdi en ilginç nokta: feature/add-header dalındaki değişiklikleri master'a birleştirmemiz gerekiyor. Master dalındayız, bu yüzden sadece şunu yazmamız gerekiyor:

Ancak sonuç, test_resource.txt dosyasında bir çakışma olacaktır:

Burada Git'in bu kodu nasıl birleştireceğine kendi başına karar veremediğini görebiliriz. Bize önce çatışmayı çözmemiz gerektiğini ve ancak ondan sonra taahhüdü gerçekleştirmemiz gerektiğini söyler.

TAMAM. Çakışan dosyayı bir metin düzenleyicide açıyoruz ve şunu görüyoruz:

Git'in burada ne yaptığını anlamak için hangi değişiklikleri nerede yaptığımızı hatırlamamız ve ardından karşılaştırmamız gerekiyor:

1. Master dalında bu satırda olan değişiklikler "<<<<<<< HEAD" ve "=======" arasında bulunur.
2. feature/add-header dalında olan değişiklikler "=======" ve ">>>>>>> feature/add-header" arasında bulunur.

Git bize dosyadaki bu konumda birleştirme işlemini nasıl gerçekleştireceğini çözemediğini bu şekilde söyler. Bu bölümü farklı dallardan iki kısma ayırdı ve bizi birleştirme çatışmasını kendimiz çözmeye davet ediyor.

Haklısın. Yalnızca "başlık" kelimesini bırakarak her şeyi kaldırmaya cesaretle karar verdim:

Değişikliklerin durumuna bakalım. Açıklama biraz farklı olacaktır. "Değiştirilmiş" bir durum yerine, "birleştirilmemiş" durumdayız. Öyleyse beşinci bir durumdan söz edebilir miydik? Bunun gerekli olduğunu düşünmüyorum. Görelim:

Bunun özel, sıra dışı bir durum olduğuna kendimizi inandırabiliriz. Devam edelim:

Açıklamanın yalnızca "git commit" yazmayı önerdiğini fark edebilirsiniz. Bunu yazmaya çalışalım:

Ve aynen böyle yaptık — konsoldaki çatışmayı çözdük.

Tabii entegre geliştirme ortamlarında bu biraz daha kolay yapılabilir. Örneğin, IntelliJ IDEA'da her şey o kadar iyi ayarlanmıştır ki, gerekli tüm işlemleri doğrudan içinde gerçekleştirebilirsiniz. Ancak IDE'ler pek çok şeyi "gizli gizli" yapar ve genellikle orada tam olarak ne olduğunu anlamıyoruz. Ve anlayış olmadığında sorunlar ortaya çıkabilir.

Uzak depolarla çalışma

Son adım, uzak havuzla çalışmak için gereken birkaç komutu daha bulmaktır.

Dediğim gibi, uzak depo, havuzun depolandığı ve onu klonlayabileceğiniz bir yerdir.

Ne tür uzak depolar var? Örnekler:

• GitHub, havuzlar ve işbirliğine dayalı geliştirme için en büyük depolama platformudur.
• GitLab, açık kaynaklı DevOps yaşam döngüsü için web tabanlı bir araçtır. Kendi wiki'si, hata izleme sistemi, CI/CD ardışık düzeni ve diğer işlevleriyle kod depolarını yönetmek için Git tabanlı bir sistemdir.
• BitBucket, Mercurial ve Git sürüm kontrol sistemlerine dayalı, proje barındırma ve işbirlikçi geliştirme için bir web hizmetidir. Bir zamanlar ücretsiz özel depolar sunması nedeniyle GitHub'a göre büyük bir avantajı vardı. Geçen yıl GitHub da bu özelliği herkese ücretsiz olarak tanıttı.
• Ve benzeri…

Uzak bir havuzla çalışırken yapılacak ilk şey, projeyi yerel deponuza klonlamaktır.

Bunun için local olarak yaptığımız projeyi export ettik. Artık herkes şunu yazarak kendisi için klonlayabilir:

Artık projenin tam bir yerel kopyası var. Projenin yerel kopyasının en güncel olduğundan emin olmak için, projeyi şunu yazarak çekmeniz gerekir:

Bizim durumumuzda, şu anda uzak depodaki hiçbir şey değişmedi, dolayısıyla yanıt: Zaten güncel.

Ancak uzak depoda herhangi bir değişiklik yaparsak, yerel depo biz onları çektikten sonra güncellenir.

Ve son olarak, son komut, verileri uzak depoya göndermektir. Yerel olarak bir şey yaptığımızda ve onu uzak depoya göndermek istediğimizde, önce yerel olarak yeni bir taahhüt oluşturmalıyız. Bunu göstermek için metin dosyamıza bir şey daha ekleyelim:

Şimdi bizim için oldukça yaygın olan bir şey — bu iş için bir taahhüt oluşturuyoruz:

Bunu uzak depoya gönderme komutu şöyledir:

Şimdilik bu kadar!

2. IntelliJ'de Git ile nasıl çalışılır IDEA

Bu bölümde IntelliJ IDEA'da Git ile nasıl çalışılacağını öğreneceksiniz.

Gerekli girişler:

1. Önceki bölümü okuyun, takip edin ve anlayın. Bu, her şeyin kurulu ve kullanıma hazır olduğundan emin olmanıza yardımcı olacaktır.
2. IntelliJ IDEA'yı kurun. Burada her şey yolunda olmalı :)
3. Tam ustalık elde etmek için bir saat ayırın.

Git ile ilgili makale için kullandığım demo projesi üzerinde çalışalım .

Projeyi yerel olarak klonlayın

Burada iki seçenek vardır:

1. 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. Çatal oluşturma iş akışının bir örneği başlığı altındaki başka bir makalede çatal oluşturma hakkında bilgi edinebilirsiniz .
2. Depoyu klonlayın ve her şeyi sunucuya itme yeteneği olmadan her şeyi yerel olarak yapın.

GitHub'dan bir projeyi klonlamak için proje bağlantısını kopyalayıp IntelliJ IDEA'ya iletmeniz gerekir:

1. Proje adresini kopyalayın:

2. IntelliJ IDEA'yı açın ve "Sürüm Kontrolünden Al"ı seçin:

3. Proje adresini kopyalayıp yapıştırın:

4. Bir IntelliJ IDEA projesi oluşturmanız istenecektir. Teklifi kabul et:

5. Derleme sistemi olmadığı için "Mevcut kaynaklardan proje oluştur" u seçiyoruz:

6. 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 versiyonuna sahip olduğumuzu not ediyoruz. Ve ortada, nihai birleştirilmiş sonuca sahibiz.

Bir projede çok sayıda dal, taahhüt ve kullanıcı varsa, şubeye, kullanıcıya ve tarihe göre ayrı ayrı arama yapmanız gerekir:

Başlamadan önce hangi branşta olduğumuzu nasıl anlayacağımızı da açıklamakta fayda var.

Sağ alt köşede "Git: master" etiketli bir düğme 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:

1. CTRL+T — Uzak depodan (git çekme) en son değişiklikleri alın.
2. 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 (git commit).
3. CTRL+SHIFT+K — Bu, değişiklikleri uzak havuza gönderme komutudur. Yerel olarak oluşturulan ve henüz uzak havuzda olmayan tüm taahhütler gönderilir (git push).
4. 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 halletmek 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 dersin kapsamı dışındadır).

Bunu yapmak için ne gerekli?

1. Ana daldaki tüm mevcut değişiklikleri alın (örneğin, "master").

2. Bu ana şubeden işiniz için ayrı bir şube oluşturun.

3. Yeni işlevselliği uygulayın.

4. 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 gideriz ve değişiklikleri ana şubeden bizimkine yeniden temel alırız . 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 görgü kurallarıdı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).

5. Değişikliklerinizi uzak depoya aktarın.

Uzak sunucudan değişiklikler nasıl alınır?

README'ye yeni bir taahhütle bir açıklama ekledik ve bu değişiklikleri almak istiyoruz. 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'yi girin :

Artık README'nin nasıl değiştiğini görebilirsiniz, yani uzak depodaki 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ştur

Burada 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. Bizim durumumuzda: bu benioku-geliştirici olacaktır .

Git: master daha sonra Git: readme-improver olarak değişecektir .

Paralel çalışmayı simüle edelim

Çatışmaların ortaya çıkması için birinin onları yaratması gerekir.

BENİOKU'yu tarayıcı aracılığıyla yeni bir taahhütle düzenleyeceğiz, böylece paralel çalışmayı simüle edeceğiz. Sanki biz üzerinde çalışırken biri aynı dosyada değişiklik yapmış gibi. Sonuç bir çatışma olacaktır. 10. satırdan "fully" kelimesini kaldıracağız.

İşlevlerimizi uygulayın

Görevimiz README'yi değiştirmek ve yeni makaleye bir açıklama eklemek. Yani Git'teki çalışma IntelliJ IDEA'dan geçer. Bunu ekle:

Değişiklikler yapıldı. Şimdi bir taahhüt oluşturabiliriz. Bize şunu veren CTRL+K tuşlarına basın :

Bir taahhüt oluşturmadan önce, bu pencerenin neler sunduğuna yakından bakmamız gerekiyor.

Commit Message bölümünde commit ile ilgili text yazıyoruz. Ardından oluşturmak için Commit'e tıklamamız gerekiyor .

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 edin

Gö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. Bunun için aşağıdaki ekran görüntüsünde sağ alt köşede gösterilenleri 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. Biz bunu yaparız:

Her şeyi doğru yaptıysanız ve beni takip ettiyseniz, sonuç README dosyasında bir çakışma göstermelidir:

Burada ayrıca anlamak ve özümsemek için birçok bilgiye sahibiz. Burada gösterilen, çakışmaları olan dosyaların (bizim durumumuzda bir dosya) listesidir. Üç seçenek arasından seçim yapabiliriz:

1. sizinkini kabul edin — yalnızca beni oku geliştiriciden gelen değişiklikleri kabul edin.
2. onlarınkini kabul et — yalnızca anadan gelen değişiklikleri kabul et.
3. birleştir — neyi saklamak ve neyi atmak istediğinizi kendiniz seçin.

Neyin değiştiği belli değil. Ana dalda değişiklikler varsa, bunlara orada ihtiyaç duyulmalıdır, bu nedenle değişikliklerimizi öylece kabul edemeyiz. Buna göre, birleştirmeyi seçiyoruz :

Burada üç kısım olduğunu görebiliriz:

1. Bunlar, beni oku iyileştirmeden gelen değişikliklerdir.
2. Birleştirilmiş sonuç. Şimdilik, değişikliklerden önce var olan şey bu.
3. Ana daldaki değişiklikler.

Herkesi memnun edecek birleşik bir sonuç üretmemiz gerekiyor. Değişikliklerimizden ÖNCE nelerin değiştirildiğini incelediğimizde, basitçe "fully" kelimesini kaldırdıklarını anlıyoruz. Tamam sorun yok! Bu, onu birleştirilmiş sonuçta da kaldıracağımız ve ardından değişikliklerimizi ekleyeceğimiz anlamına gelir. Birleştirilmiş sonucu düzelttikten sonra, Uygula'ya tıklayabiliriz .

Ardından, yeniden düzenlemenin başarılı olduğunu bildiren bir bildirim açılır:

Orada! İlk çatışmamızı IntelliJ IDEA aracılığıyla çözdük.

Değişiklikleri uzak sunucuya gönder

Bir sonraki adım, değişiklikleri uzak sunucuya iletmek ve bir çekme isteği oluşturmaktır. Bunu yapmak için CTRL+SHIFT+K tuşlarına basmanız yeterlidir . Sonra şunu elde ederiz:

Solda, uzak depoya gönderilmemiş taahhütlerin bir listesi olacaktır. Sağda değişen tüm dosyalar olacak. Ve bu kadar! Push'a basın ve mutluluğu yaşayacaksınız :)

Push başarılı olursa, sağ alt köşede buna benzer bir bildirim göreceksiniz:

Bonus: çekme isteği oluşturma

Bir GitHub deposuna gidelim ve GitHub'ın ne istediğimizi zaten bildiğini görüyoruz:

Karşılaştır ve çekme talebi ' ne tıklayın . Ardından Çekme isteği oluştur'u tıklayın . Çakışmaları önceden çözdüğümüz için, artık bir çekme isteği oluştururken hemen birleştirebiliriz:

Şimdilik bu kadar!