bir giriş yerine
Merhaba! Bugün bir sürüm kontrol sistemi olan Git'ten bahsedeceğiz.
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:

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)
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:- 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 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 yoktur. Ancak durumu "değiştirilmiş" olan dosyalar olabilir.

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

ş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

git status

- 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.
git add *.txt
Durumu kontrol etmek için zaten bildiğimiz komutu kullanıyoruz:
git status

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

git log

git status

git status

git diff

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

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.
git status


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

Ş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

- 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

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

git branch -a

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

git checkout -b feature/update-txt-files

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

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

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

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"

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: 

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

git status

git add *.txt

git commit

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…
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


git add test_resource.txt
git commit -m "prepared txt for pushing"
Bunu uzak depoya gönderme komutu şöyledir:
git push

Yararlı bağlantı
- Resmi Git belgeleri . Referans olarak tavsiye ederim.
GO TO FULL VERSION