Git'e başlarken: yeni başlayanlar için kapsamlı bir rehber

bir giriş yerine

Merhaba! Bugün bir sürüm kontrol sistemi olan Git'ten bahsedeceğiz. Git'i bilmiyorsanız/anlamıyorsanız, programlama ile hiçbir ilginiz yoktur. Ama güzel olan şu 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? Dağıtılmış ekipler, işlerini yönetmek için bir tür sisteme ihtiyaç duyar. 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.

Git'i Yükleme

Java'yı bilgisayarınıza yükleyelim.

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: Artık 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 Git'i Ubuntu'ya kurun . Ubuntu üzerinde çalışıyorum, bu yüzden size bunun için ne yazmanız gerektiğini söyleyebilirim: sudo apt-get install git.

macOS'ta yükleme

Burada da öncelikle Git'in orada olup olmadığını kontrol etmeniz gerekiyor. Eğer sahip değilseniz, onu almanın en kolay yolu en son sürümü buradan 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:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Belirli bir projenin yazarını değiştirmeniz gerekirse "--global" ifadesini kaldırabilirsiniz. Bu bize aşağıdakileri verecektir:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Biraz teori...

Konuya dalmak için, sizi birkaç yeni kelime ve eylemle tanıştırmalıyız...

• 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 dosyalar için geçerli olan durumlardır:

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

İşte göründüğü gibi:

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. Daha spesifik olarak: Bir ilk taahhüt var. İkinci taahhüt oluşturulduğunda, 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, Git ile konsolda ç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

Ardından, makaleyi okurken yaptığım tüm adımları takip etmenizi ve uygulamanızı öneririm. Bu, materyali anlamanızı ve ustalığınızı geliştirecektir. Afiyet olsun! :) Yerel bir havuz oluşturmak için şunu yazmanız gerekir:

git init

Bu, konsolun geçerli dizininde bir .git klasörü oluşturacaktır. .git klasörü, Git deposuyla ilgili tüm bilgileri depolar. 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:

git status

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, bu 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:

git add *.txt

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

git status

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:

git commit -m "all txt files were added to the project"

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

git log

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:

git status

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:

git status

Burada "takip edilmeyen" ve "değiştirilen" 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:

git diff

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:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

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

git log

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:

git add GitTest.java
git commit -m "added GitTest.java"
git status

.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:

```
*.class
target/
*.iml
.idea/
```

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:

git status

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:

git add .gitignore
git commit -m "added .gitignore file"

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:

git status

Mükemmel! .gitignore +1 :)

Şubeler ve benzeri ile çalışmak

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. Daha önce de söylediğim gibi, dal, 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:

git branch -a

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 dalda 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:

git log

Taahhüdü "merhaba dünya eklendi ..." yorumuyla vurguladım Benzersiz tanımlayıcısı 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Bu taahhütten başlayan bir "geliştirme" dalı oluşturmak istiyorum. Bunu yapmak için yazıyorum:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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:

git status
git log

Ve beklendiği gibi, iki taahhüdümüz var. Bu arada, ilginç bir nokta: 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:

git branch -a

İ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 istiyorum. İlk önce ona geçmem 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:

git checkout -b feature/update-txt-files

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österiyor: Burada bir ana dalımız var. Bir noktada, ana daldan ikincil bir dal oluşturulur ve sonra değiştirilir. İş bittiğinde, bir dalı diğerine birleştirmeliyiz. Çeşitli özellikleri tarif etmeyeceğim: Bu yazıda sadece genel bir anlayış iletmek istiyorum. Ayrıntılara ihtiyacınız varsa, bunları kendiniz arayabilirsiniz. Ö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:

git add *.txt
git commit -m "updated txt files"
git log

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

git checkout master
git merge feature/update-txt-files
git log

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 eklendi. Bunu yapmak için şunu yazıyoruz:

git branch -D feature/update-txt-files

Buraya kadar her şey açık, değil mi? 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. Hadi gidelim! 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:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

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

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

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:

git merge feature/add-header

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 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. Sadece "başlık" kelimesini bırakarak her şeyi kaldırmaya cesaretle karar verdim: Değişikliklerin durumuna bakalım. Açıklama biraz farklı olacak. "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:

git status

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

git add *.txt

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

git commit

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. Daha önceki yazılarımda anlatmıştım. GitHub'da
  beni takip edin . İş için çalıştığım alanlarda sık sık işimi orada sergiliyorum.

• 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 havuzlarını yönetmek için Git tabanlı bir sistemdir . Microsoft'un GitHub'ı satın aldığı haberinin ardından bazı geliştiriciler projelerini GitLab'da çoğalttı.
  

• 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 ettim ve artık herkes şunu yazarak kendine klonlayabilir:

git clone https://github.com/romankh3/git-demo

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:

git pull

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 yaparsam, yerel olan 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 başka bir şey ekleyelim: Şimdi bizim için oldukça yaygın olan bir şey — bu iş için bir taahhüt oluşturuyoruz:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Bunu uzak depoya gönderme komutu şöyledir:

git push

Tüm söylemek istediğim buydu. İlginiz için teşekkürler. Kişisel çalışmam ve çalışmamla ilgili çeşitli harika örnek projeler yayınladığım GitHub'da beni takip edin .

Yararlı bağlantı

• Resmi Git belgeleri . Referans olarak tavsiye ederim.