Başlamak İçin En İyi 20 GIT Komutu

Bildiğiniz gibi GIT, dağıtılmış sürüm kontrol sistemidir. Mühendisler, yazılım geliştirme sürecinde kaynak kodda yapılan değişiklikleri izlemek için kullanırlar. Bir geliştiriciyseniz, özellikle mesleğe yeni başlıyorsanız, daha kullanışlı GIT komutlarından birkaçını öğrenmelisiniz.

Öğrenmeniz gereken en iyi GIT bash komutlarına bir göz atalım.

Projeyi Kurmak İçin: GIT İstemlerinin Açıklaması

Sizin için önerilenler: Kodlamayı Öğrenmenize Yardımcı Olacak 5 Harika Ücretsiz Uygulama.

GİT BAŞLAT

Diyelim ki en sevdiğiniz IDE'de bir proje oluşturdunuz ve PowerShell GIT istemleri hakkında bilgi sahibi olmanız gerekiyor. Çalışabilir bir GIT deposu kurmanız gerekecek.

Bunu yaparken, GIT'e hangi dizinin kullanılması ve çalıştırılması gerektiğini söylemelisiniz. Git init özelliği, bunu nasıl yapacağınızdır. GIT bir gizli oluşturacaktır. git dizini ve dosyalarını diğer alt dizinler gibi düzenli tutmak için kullanın.

Sonraki popüler editörler için git init komutlarının bir listesi:

YAPILANDIRMA

Deponuzu oluşturduktan sonra, kullanıcı adınızı ayarlamak gibi bazı temel öğeleri yapılandırabilirsiniz. Bu yüzden bir CONFIG komutuna ihtiyacınız olacak. Bir GIT listesinin herhangi bir komutu bunu içerecektir.

Kullanıcı adınızı aşağıdakileri yürüterek ayarlayabilirsiniz:

 git config user.name=<replace_with_your_username>.

Bu, kullanıcı adını yakındaki depoya yerleştirecektir. Ancak, daha sonra ikinci bir depo oluşturmak isterseniz, kullanıcı bilgilerinizi bir kez daha ayarlamanız gerekeceğini unutmayın.

Global bir komut seçeneği eklerseniz bunu yapmanıza gerek yoktur. Bilgilerinizi küresel olarak ayarlayacaktır:

 git config --global user.name=<replace_with_your_username>.

Diğer yönleri yapılandırmak için bir CONFIG komutu da kullanabilirsiniz. Komutu yapılandırma dosyasına yerleştirebilirsiniz.

KLON

Bilgisayarınızda uzak bir depo almak için bir CLONE komutu ayarlamanız gerekir. Bunu git klon ayarınızla ve URL'yi parametre olarak ileterek yaparsınız. Bu komut, makinenizdeki tüm uzak depoyu klonlamalıdır. Bu, bir dev olarak size iyi hizmet edecek GIT hub komutlarından bir diğeridir.

 $ git clone git://git.kernel.org/pub/scm/git/git.git

Takma ad

ALIAS komutuyla favori komutlarınıza kısayollar oluşturabilirsiniz. Bir dizi komutu sarmanıza ve bunları bir ad altında kaydetmenize yardımcı olan bir araçtır. Bu, geliştirici olarak sıklıkla kullanacağınız yaygın GIT komutlarından biri olarak kabul edilir.

Takma adları doğrudan yapılandırma dosyanıza da ekleyebilirsiniz. Bu durumda, örnekteki yönerge, global yapılandırma dosyasında aşağıdaki yapılandırmaya dönüştürülecektir. Örneğin, en sık kullanılan komutlar için sonraki kısayolları ayarlayabilirsiniz:

 $ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status

Değişiklikleri Yapma ve Geri Alma Komutları

DURUM

Bu, hazırlama alanının durumunu ve çalışma yapılandırmanızı görüntülemek istediğinizde kullanacağınız komuttur. Bunu kullanarak, hangi değişikliklerin yapıldığına ve hangilerinin yapılmadığına bakabilirsiniz.

EKLEMEK

Değiştirilmiş veya yeni dosyanızı kaydetmeden önce, hazırlama alanınıza eklenmesi gerekir. Bunu bir git add yönergesi çalıştırarak yapın. Dosya ve dizinin adını parametre olarak iletmelisiniz. f_your_file> yazabilirsiniz. Bu noktada, dosyanız "işlenecek değişiklikler" listenizden kaldırılacaktır.

-p (veya —patch) eklemek, izlenen her dosyanın kaydedilecek bölümlerini seçmenize olanak tanır. Ardından, her bir taahhüt yalnızca ilgili değişiklikleri içerir.

İŞLEMEK

Bazı özellik uygulamalarını tamamladığınızı ve değişiklikleri kaydetmek istediğinizi varsayalım. “Taahhüt edilecek değişiklikler” listesine bakın. Bu bittiğinde, gerekli tüm dosyaların hazırlandığını bileceksiniz. İşte o zaman git commit komutunu çalıştırabilirsiniz.

Bu komutu yürüttükten sonra, varsayılan düzenleyici açılacaktır. Daha sonra COMMIT mesajınızı girmelisiniz.

Mesajınız kısaysa, GIT COMMIT komutuna şu şekilde ekleyin:

 git commit -m “Your_first_commit_message.”

-a seçeneğini de ekleyebilirsiniz. Bunu yaparak, GIT'in çalışan ağacınıza bakmasını sağlayabilirsiniz. Ardından, yeni ve değiştirilmiş dosyalar için GIT ADD'nin yanı sıra, taahhütten önce silinen dosyalar için git rm'yi gerçekleştirir.

Belki taahhüdünüze bir dosya eklemeyi unutmuşsunuzdur. O dosya için başka bir taahhüt komutu oluşturmak istemiyorsunuz. Bunun yerine bir değiştirme seçeneğini kullanabilirsiniz.

Kamu taahhütleri asla değiştirilmemelidir. Meslektaşlarınızın çalışmalarını bu taahhüde dayandırmış olabileceğini unutmayın. Yaptıkları herhangi bir değişiklik nedeniyle kafalarını karıştırmak istemezsiniz.

SIFIRLA

git reset, bir dev olarak iş hayatınıza başlarken işinize yaraması gereken başka bir araçtır. Bu, değişiklikleri yeniden biçimlendirmenize yardımcı olan bir komuttur. Kullanılabileceği birçok yol vardır, ancak yaygın bir örnek, aşağıdaki gibi argümanlar varmış gibi bir mod ve taahhüt tanımlaması sağlamanızdır:

 git reset <mode> <commit>.

Birden fazla sıfırlama olasılığı vardır. Bunları anlamak için üç GIT ağacının farkında olmalısınız.

SAKLAMAK

Diyelim ki bir süredir belirli bir özellik alanı üzerinde çalışıyorsunuz. Tam o anda düzeltilmesi gereken bir hata olduğunu görüyorsunuz. Ancak, özellik uygulamalarınız hala devam ediyor ve herhangi bir tamamlanmamış dal değişikliği yapmak istemiyorsunuz. Git stash komutunuz, ihtiyacınız olan şeydir.

Bu yöntem, değişikliklerinizi STASH yığınında tutmanızı sağlar. Daha sonra, git stash listesiyle birlikte bunların bir listesini yapabilirsiniz.

Zulanızı uygulayabileceğiniz şube için kısıtlama yoktur. Değişiklikleri bir dalda saklayabilir ve istediğiniz zaman bunları farklı bir dalda uygulayabilirsiniz.

Saklanan değişiklikleri yürürlüğe koymak için git stash uygulama yönergenizi kullanın. Yığında saklanan en son değişiklikleri uygular. Daha eski değişiklikleri uygulamak isterseniz, adı git stash Apply [email protected]{1} gibi belirtebilirsiniz. Bu, yığındaki başka bir zula için geçerlidir.

Apply yönergesini kullanarak bir stash uyguladığınızda, bu yığından kaldırılmaz. Bunu sık kullanacağınız bir GIT akış komutu olarak görebilirsiniz.

İlginizi çekebilir: 2020'de Mobil Uygulama Geliştirmeyle İlgili Trendler Neler?

GERİ DÖN

Belki tamamlanmış değişikliklerinizi orijinal şubesine göndermeyi uygun gördünüz ve taahhütlerinizden birinin orada olması gerekmediğini fark ettiniz. Bir öncekinden kurtulacak başka bir yönerge ekleyerek düzeltin. REVERT direktifi size orada yardımcı olur. İşlem kimliğinizi belirtmeli ve bir parametre olarak geri almalısınız: git revert <commit_id> .

Komut, şubenin adı, uzaktan gitmeden önce veya sonra yapılan taahhütlerin sayısı dahil olmak üzere kullanışlı bilgileri çözecektir. Ayrıca, yeni ve değiştirilmiş dosyaları birden çok liste olarak görebilirsiniz:

Ekip Çabaları için Git Komutları

DAL

Git şube yönergeleri ile sisteminiz şubeler listesinden yararlanacaktır. Uzak şubelere bakmak istiyorsanız, git şubesi -r bunu nasıl yapacağınızdır. Yerel ve uzak şubeleri görmek istiyorsanız, git şubesi -a'yı kullanın.

Bir dalı şunu kullanarak silebilirsiniz: git branch -d <branch_name>.

Kontrol etmek

Bu, düzenli olarak kullanılan başka bir GIT yönergesidir. Şubede çalışmak için bir anahtar çalıştırmanız gerekir. git checkout , kişinin bir şubeden farklı bir şubeye kolayca geçiş yapmasıdır. Dosyaları ve taahhütleri incelemek için kullanabilirsiniz. Git checkout <şubenizin adı> bu şekilde yürütülür.

Şubeler arasında başarılı bir şekilde geçiş yapmak istiyorsanız aşağıdakileri unutmayın:

Geçerli şubedeki değişiklikler, geçiş yaptığınızda kaydedilebilir veya saklanabilir

Kontrol ettiğiniz herhangi bir şube yerel bölgenizde bulunmalıdır.

Ayrıca, tek seferde bir şube oluşturmanıza ve şubeye geçmenize izin veren bir kısayol komutu da vardır:

 git checkout -b <name-of-your-branch>.

Bu, yerelinizde farklı bir yönerge oluşturan bir komuttur (-b şube anlamına gelir). Oluşturulduktan hemen sonra en son şubeye bakar.

ÇEKMEK

git pull yönergesi ile uzak bir havuz aracılığıyla yeni bir veri indirme işlemi ve en yakın depo ile entegrasyon gerçekleştirirsiniz. Bu komutu çalıştırdığınızda, yerel dalları, uzak terminalinizdeki tüm değişikliklerle birlikte yenilersiniz.

Yeni değişiklikleri entegre etmenin de varsayılan bir yolu vardır. Birleştirme kullanın. Şu seçeneği kullanırsanız, rebase olarak değiştirebilirsiniz: git pull –rebase .

Değişiklikleri her zaman içinde kaydedilmemiş değişiklikler olmadan yakındaki temiz bir havuza koymanız önerilir.

İŞLEMEK

Bu, "anlık görüntü" alabilecek veya dosyayı sürüm geçmişinizde kaydedebilecek bir yönergedir. git commit -m "[Taahhüt mesajını yazın]" girdiniz ve böylece onu kullanıyorsunuz.

GIT ADD komutuyla birlikte eklediğiniz tüm dosyaları işleyen komuttur. Ayrıca, o zamandan beri değişen dosyaları da etkili bir şekilde taahhüt eder.

İTMEK

Herhangi bir değişiklik yaptıktan sonra, muhtemelen uzak bir depoya göndermek istersiniz. Bu şekilde, takım arkadaşlarınız tarafından kullanılabilirler.

GIT PUSH'ı çalıştırırsanız, bu, geçerli bir alandaki son değişiklikleri uzaktan kumandasına "itecektir". Yerel olarak bir şube oluşturarak, tüm şubeyi uzak bir depoya gönderirseniz, sorun değil. Bu yönerge şunu yapmanızı sağlar: git Push -u Origin <replace_with_branch_name> .

Belirli bir ada sahip bir dalı Origin deposuna bu şekilde gönderirsiniz. Uzak dal, yerel olanla aynı adı kullanmalıdır.

BİRLEŞTİRMEK

Ayrıca MERGE'yi bu GIT istemleri listesine koymak zorunda kaldık. Bir noktada özellik dalını entegre etmek veya başka bir daldaki hataları düzeltmek isteyeceksiniz. Şubenizi birleştirmek bunu yapmanızı sağlar. Git birleştirme komutunu çalıştırmak, yapmanız gereken şeydir.

Komutu çalıştırdıktan sonra, üç yollu birleştirme veya hızlı ileri sarma olmak üzere iki tür birleştirme gerçekleşebilir.

Hızlı ileri birleştirme, birleştirmek istediğiniz dallar arasında doğrusal bir yol olduğunda içindir. Diyelim ki master'dan bir bugfix dalı oluşturdunuz. Sorunu çözdünüz ve onu bir master'da birleştirmek isteyeceksiniz. Ancak, hiç kimse şubenin güncellemesini yapmadı. GIT, sorunu çözecek olan bir dalı kendisi birleştirebilir.

Dallar arasında doğrusal bir yol olmadığında üç yollu birleştirme gerçekleşir. Son örnekte olduğu gibi, ana sürümden bir hata düzeltme dalı tasarladınız. Hatayı düzelttiniz ve şimdi onu git merge <branch> ile birleştirmeniz gerekiyor.

Belki birisinin master'ı güncellediğini keşfedersiniz. Dalları bağlamak için GIT, değişikliklerin birleştiği yeni bir taahhüt oluşturmalıdır.

İşte o zaman bir sorun çıkıyor. Her iki dal da aynı kod bloğunu değiştirmiştir. GIT, sizin yardımınız olmadan değişiklikleri bir araya getiremez. Bir değişikliği kabul etmek, bunu yapmanın en kolay yoludur.

Ancak değişiklikleri birleştirebilirsiniz. Bu meydana geldiğinde GIT, etkilenen dosyaları bazı görsel göstergelerle değiştirir. Bu, sorunları kolayca bulmanızı sağlar. Bazı görsel işaretler kullanılır:

 <<<<<< — shows the place the conflict began ====== — separates changes from different branches >>>>>> — shows where the conflict ends

Çakışmaları çözüp işaretçilerden kurtulduğunuzda, çakışan alanlar git add ile evreleme alanınıza eklenecektir.

Bir hata yapıldıysa veya farklı bir yöne gitmek istiyorsanız git birleştirme –abort komutunu çalıştırın. Bunu yaptığınızda şubeniz değiştirilmez.

Değilse, git commit komutlarını kullanın. Yeni bir taahhüt oluşturarak birleştirmeyi sonuçlandıracaktır.

Başka bir yararlı komut, Git birleştirmeyle ilgili sorunlarınız olması durumunda git birleştirme aracı komutunun yalnızca harici bir birleştirme yardımcısını başlatmasıdır.

Şunlar da hoşunuza gidebilir: iOS Uygulama Geliştirme için En İyi Programlama Dili.

YENİDEN TEMELLE

Önce REBASE kullanarak değişiklikleri entegre edin ve ardından birleştirin. REBASE ile programın arka planını yeniden yazıyorsunuz. Örneğin, bir ekip üyesi çalışmalarını bunlara dayandırabileceğinden, genel taahhütler hiçbir zaman yeniden temellendirilmemelidir.

Belirli bir şubeyi kendi şubenizle birleştirmeyi seçmek yerine, şubenizi belirli bir şubeye yeniden kurabilirsiniz. Ama kullandığınız bu yeniden temellendirme protokolünü yapan nedir?

Ne olacak, değişiklikler belirli bir şubeden diğerine entegrasyon alacak. İkinci şubenin temeli, bir taahhütten farklı bir taahhütle değiştirilecektir. İkinci şube birinciden yaratılmış gibi görünecek. Bu size net, doğrusal bir tarih verir.

Git rebase <name_of_branch_to_rebase_on>, komutu yürütme şeklinizdir.

Bu, rebase komutunun ilk veya standart modudur. Ardından, etkileşimli mod olarak da adlandırılan ikinci mod vardır. Uzak şube olarak da bilinen başka bir şubeye dahil etmeden önce, bir taahhüt dizisini kolayca değiştirmek için kullanabilirsiniz.

Komutları Yazdıktan Sonra

KAYIT

Bu yönerge, geçerli şubenin sürüm geçmişini listelemek içindir. Çalıştırmak için git log –follow[file] yazın.

Bu direktif bir dosya sürümü geçmişini listeler. Dosyaların yeniden adlandırılması dahil edilecektir. git log bir taahhüt geçmişi yazdırır.

Bu senaryoda birkaç seçenek kullanılabilir. Bunlardan biri git log –stat. Tarihteki her taahhüt için, bir isim listesi yazdırılacaktır. Kaldırılan, değiştirilen veya eklenen dosyalara erişilebilir. Çıkarılan veya eklenen satır tutarları görülebilir. İnceleyebileceğiniz bir özet de olduğunu fark edeceksiniz.

GÖSTERMEK

Devs'in kullandığı Show istemi, çeşitli nesneler için ayrıntıları gösterebilir. "Nesneler" dediğimizde, taahhütlerden veya etiketlerden bahsediyoruz. git show daha eski bir dosya sürümünü görüntülemek için kullanılabilir. Örneğin, bir dosyanın sürümünü iki işlem öncesinden göstermek için bu komutu kullanabilirsiniz.

Umarız bu GIT komutları öğreticisi, bu araca bir giriş niteliğinde olmuştur. Bir geliştirici olarak, GIT hakkında ne kadar çok şey öğrenirseniz, güvenilir bir programcı arayan bir ekip tarafından işe alınmak için o kadar iyi bir konumda olacaksınız.

Bu alanda ilerledikçe, daha fazla GIT komut istemi öğreneceksiniz ve programlamanız çok daha sorunsuz hale gelecek. Takım arkadaşlarınız tarafından eklenebilecek kullanışlı kodlar yazabileceksiniz.

 Bu makale Slava Vaniukov tarafından yazılmıştır. Yazılım ve uygulama geliştirme ajansı Softermii'nin Kurucu Ortağı ve CEO'sudur. Web ve mobil geliştirme endüstrisinde 9 yıldan fazla deneyime sahiptir. Bunun yanı sıra, çok çeşitli diğer web kaynaklarında yer alan Softermii blogunun ve teknoloji blog yazarının yazarlarından biridir. Onu LinkedIn'de takip edebilirsiniz.