Git
Bu cevap GitHub'ı da içeriyor, çünkü birçok insan da bunu sordu.
Yerel depolar
Git (yerel olarak) .gitdosyalarınızı kaydettiğiniz bir dizine ( ) sahiptir ve bu 'yerel deponuz'dur. Bu, uzak depoyu hemen ekleyip taahhüt ettiğiniz SVN gibi sistemlerden farklıdır.
Git, dosyanın tamamını kaydederek değişen her dosyanın sürümünü saklar. Bu açıdan SVN'den de farklıdır, çünkü delta değişiklikleri yoluyla 'yeniden yaratmadan' herhangi bir tek versiyona gidebilirsiniz.
Git, dosyaları hiç 'kilitlemez' ve bu nedenle bir düzenleme için 'özel kilit' işlevinden kaçınır (pvcs gibi eski sistemler akla gelir), bu nedenle çevrimdışı olduğunda bile tüm dosyalar her zaman düzenlenebilir. Aslında, GitHub gibi uzak bir depoya çekme veya getirme / aktarma sırasında dosya değişikliklerini (aynı dosya içinde!) Birleştirme ile inanılmaz bir iş çıkarır. Manuel değişiklikler yapmanız gereken tek zaman (aslında bir dosyayı düzenlemek), iki değişikliğin aynı kod satırlarını içermesi.
Dallar
Dallar, ana kodu ('ana' dal) korumanıza, bir kopya oluşturmanıza (yeni bir dal) ve daha sonra bu yeni dalda çalışmanıza olanak tanır. Eğer çalışma biraz zaman alırsa veya şube yapıldığından beri master çok fazla güncelleme alırsa, master şubeye karşı birleştirme veya yeniden basma (genellikle daha iyi tarih ve çatışmaları çözmek için daha kolay) tercih edilmelidir. İşiniz bittiğinde, şubede yapılan değişiklikleri ana depoya geri birleştirirsiniz. Birçok kuruluş, bir özellik, hata veya angarya öğesi olsun, her iş parçası için dallar kullanır. Diğer kuruluşlar dalları yalnızca sürüm yükseltmeleri gibi önemli değişiklikler için kullanır.
Çatal: Bir branşmanla branşmanı kontrol edip yönetirken, bir çatalla başka biri kodu tekrar kabul etmeyi denetler.
Genel olarak konuşursak, dal yapmak için iki ana yaklaşım vardır. Birincisi, ana daldaki değişikliklerin çoğunu korumaktır, yalnızca farklı ihtiyaçlar için iki dal olmasını istediğiniz sürüm değişiklikleri gibi daha büyük ve daha uzun süren işler için dallar kullanmaktır. İkincisi, temel olarak her özellik isteği, hata düzeltme veya angarya için bir dal oluşturup, daha sonra bu ana dalları ana ana dalda ne zaman birleştireceğinize elle karar vermenizdir. Bu sıkıcı görünse de, bu yaygın bir yaklaşımdır ve şu anda kullandığım ve önerdiğim yaklaşımdır, çünkü bu ana dalı daha temiz tutar ve üretime teşvik ettiğimiz ustadır, bu yüzden yeniden tamamlama yoluyla sadece tamamlanmış, test edilmiş kod istiyoruz ve dalların birleştirilmesi.
Bir dalı master yapmak için 'standart' yol a merge. Şubeler ayrıca geçmişi temizlemek için "yeniden temel alınabilir". Mevcut durumu etkilemez ve 'daha temiz' bir tarih vermek için yapılır.
Temel olarak, fikir belli bir noktadan (genellikle ustadan) dallanmış olmanızdır. Dallandığınızdan beri, “usta” nın kendisi o dallanma noktasından ileriye taşınmıştır. Bir dalda yaptığınız tüm değişiklikler, en son değişikliklerin tümü ile mevcut master durumuna karşı oynatılırsa 'daha temiz' olacaktır (sorunları çözmek daha kolay ve geçmişi anlamak daha kolay olacaktır). Yani, süreç: değişiklikleri kaydetmek; 'yeni' efendiyi alın ve değişiklikleri tekrar uygulayın (bu yeniden taban kısmıdır). Yeniden birleştirmenin, tıpkı birleştirme gibi, manuel olarak çözmeniz gereken (örneğin, düzenleme ve düzeltme) çakışmalara neden olabileceğini unutmayın.
Dikkat edilmesi gereken bir kılavuz:
Sadece şube yerelse ve henüz uzaktan kumandaya itmediyseniz yeniden pazarlayın!
Bunun nedeni, yeniden baslamanın, diğer insanların kendi taahhütlerini de içerebileceği tarihi değiştirebilmesidir.
Takip şubeleri
Bunlar adlandırılmış dallardır origin/branch_name(tam tersine branch_name). Kodu uzak depolara / depolara doğru itip çektiğinizde bu aslında gerçekleşen mekanizmadır. Örneğin, git pushbir şube çağırdığınızda building_groups, dalınız önce gider origin/building_groupsve ardından uzak depoya gider. Benzer şekilde, a yaparsanız git fetch building_groups, alınan dosya dalınıza yerleştirilir origin/building_groups. Daha sonra bu dalı yerel kopyanızla birleştirmeyi seçebilirsiniz. Bizim uygulamamız git fetchsadece birgit pull .
Yeni şubeler getiriliyor.
Yeni dallar edinme: Bir klonun ilk noktasında tüm dallara sahip olacaksınız. Bununla birlikte, diğer geliştiriciler şube ekleyip uzaktan kumandaya iterse, onları yerel olarak aşağı çekebilmek için bu dallar ve isimleri hakkında 'bilmenin' bir yolu olmalıdır. Bu, git fetchtüm yeni ve değiştirilmiş dalları izleme dalları (örn origin/.) Kullanılarak yerel depoya alacak olan bir yolla yapılır . fetchEd edildikten sonra git branch --remote, izleme dallarını listelemek ve git checkout [branch]gerçekte herhangi bir taneye geçmek mümkündür.
birleştirme
Birleştirme, farklı dallardan veya aynı dalın farklı sürümlerindeki kod değişikliklerini birleştirme işlemidir (örneğin, yerel bir dal ve uzaktan kumanda eşitlenmediğinde). Kişi bir dalda iş geliştirdiyse ve iş tamamlanmış, hazır ve test edilmişse, masterdalda birleştirilebilir . Bu, şubeye git checkout mastergeçmek için yapılır . Birleştirme tüm farklı dosyaları ve hatta farklı değişiklikleri aynı dosyalarda bir araya getirecektir. Bu, tüm değişiklikleri birleştirmek için dosyaların içindeki kodu değiştireceği anlamına gelir.mastergit merge your_branch
Yaparken checkoutbir mastero aynı zamanda bir yapmak önerilir git pull origin masteruzak ustanın en son sürümünü almak için yerel efendi birleştirilecek. Uzak yönetici değiştiyse, yani, moved forwardbunu sırasında yansıtan bilgileri görürsünüz git pull. Eğer durum buysa (master değişti) tavsiye edilir git checkout your_branchve sonra rebasemaster'ınızın değişmesi 'yeni' master'ın üstüne 'tekrar' oynatılır. Ardından, bir sonraki paragrafta gösterildiği gibi master'ı güncellemeye devam edersiniz.
Çakışma yoksa, master'a yeni değişiklikler eklenir. Çakışmalar varsa, aynı dosyaların otomatik olarak birleştirilemediği benzer kod satırlarında değişiklikler olduğu anlamına gelir. Bu durumda git merge new_branchçözülmesi gereken çakışma (lar) olduğunu bildirir. Dosyaları (her ikisinde de değişiklik olacak) düzenleyerek, istediğiniz değişiklikleri seçerek, istemediğiniz değişiklik satırlarını silerek ve ardından dosyayı kaydederek 'çözersiniz'. Değişiklikler ========ve gibi ayırıcılar ile işaretlenir <<<<<<<<.
Herhangi bir çatışmayı çözdükten sonra bir kez daha git addve git commitbirleştirmeye devam etmek için bu değişiklikler yapacaksınız (bu işlem sırasında size yol göstermesi için git'ten geri bildirim alacaksınız).
İşlem iyi çalışmadığında git merge --abort, şeyleri sıfırlamak için çok kullanışlı olduğunu göreceksiniz .
Etkileşimli yeniden bastırma ve ezme / yeniden sıralama / kaldırma işlemleri
Çok sayıda küçük adımda iş yaptıysanız, örneğin, kodu her gün 'devam eden çalışma' olarak taahhüt ediyorsanız, bu çok sayıda küçük taahhüdü birkaç daha büyük işin içine 'ezmek' isteyebilirsiniz. Bu özellikle meslektaşlarınızla kod incelemeleri yapmak istediğinizde yararlı olabilir. Attığınız tüm 'adımları' (taahhütler aracılığıyla) tekrarlamak istemezsiniz, sadece bu iş için yaptığım tüm değişikliklerin tek bir taahhütte nihai etkisi (fark) olduğunu söylemek istersiniz.
Bunu yapıp yapmamaya karar verirken değerlendirilecek temel faktör, birden çok işlemin aynı dosya veya dosyalara birden çok kez karşı olup olmadığıdır (bu durumda taahhütleri ezmek daha iyidir). Bu, etkileşimli yeniden bastırma aracıyla yapılır. Bu araç, taahhütleri ezmenize, taahhütleri silmenize, mesajları geri almanıza vb. Olanak tanır. Örneğin, git rebase -i HEAD~10( not: bu a ~değil, a- ) aşağıdakileri getirir:
Yine de dikkatli olun ve bu aracı 'zencefil' kullanın. Her seferinde bir squash / delete / reorder yapın, bu işlemden çıkın ve kaydedin, ardından aracı yeniden girin. Taahhütler bitişik değilse, bunları yeniden sıralayabilirsiniz (ve sonra gerektiği gibi ezebilirsiniz). Burada da taahhütleri silebilirsiniz, ancak bunu yaparken ne yaptığınızdan emin olmanız gerekir!
çatallar
Git depolarında işbirliği için iki ana yaklaşım vardır. Yukarıda detaylandırılan ilk, doğrudan insanların çektiği ve ittiği şubelerdir. Bu ortak çalışanların uzak depoya kayıtlı SSH anahtarları vardır. Bu, doğrudan bu depoya itmelerine izin verecektir. Dezavantajı, kullanıcı listesini tutmanız gerektiğidir. Diğer yaklaşım - çatallama - herkesin depoyu 'çatallamasına' izin verir, temel olarak kendi Git depo hesabında yerel bir kopya oluşturur. Daha sonra değişiklik yapabilirler ve bittiğinde kodu kabul etmek için bir 'çekme isteği' (gerçekten onlardan bir 'itme' ve gerçek depo bakımcısı için bir 'çekme' isteği) gönderir.
Bu ikinci yöntem, çatal kullanarak yok değil deposu için kullanıcıların bir listesini tutmak için birini gerektirir.
GitHub
GitHub (uzak bir depo) normalde böyle bir deponuz varsa (veya bunlara eklenirseniz) taahhüt edilen değişiklikleri ittiğiniz ve çektiğiniz uzak bir kaynaktır, bu nedenle yerel ve uzak aslında oldukça farklıdır. Uzak depoyu düşünmenin başka bir yolu .gitda uzak bir sunucuda yaşayan bir dizin yapısı olmasıdır.
Size 'çatal' Zaman - GitHub web tarayıcısı GUI bu düğmeye tıklamak gibi 
- Eğer kodun kopyasını ( 'klon') oluşturmak için GitHub hesabında. İlk kez yaptığınızda biraz ince olabilir, bu nedenle, depo sahibi bir kod tabanının altında listelenen - orijinal sahibi veya 'çataldan' ve aşağıdaki gibi baktığınızdan emin olun:
Yerel kopyaya sahip olduğunuzda, istediğiniz gibi değişiklikler yapabilirsiniz (bunları yerel bir makineye çekerek). İşiniz bittiğinde, orijinal depo sahibine / admin'e bir 'çekme isteği' gönderirsiniz (kulağa hoş geliyor, ancak aslında bunu tıklıyorsunuz:
:) ve onu 'çekiyorlar'.
Kod üzerinde birlikte çalışan bir ekip için daha yaygın olan veri havuzunu klonlamaktır (deponun ana ekranındaki 'kopyala' simgesine tıklayın). Ardından, yerel olarak yazıngit clone ve yapıştırın. Bu sizi yerel olarak kurar ve ayrıca (paylaşılan) GitHub konumuna itebilir ve çekebilirsiniz.
Klonlar
GitHub'daki bölümde belirtildiği gibi, bir klon bir deponun kopyasıdır. Uzak bir deponuz olduğunda, git clonekomutun URL'sine karşı komut verirsiniz ve ardından deponun yerel bir kopyası veya klonuyla sonuçlanırsınız. Bu klon, her şeye sahiptir , dosyalar, ana dal, diğer dallar, mevcut tüm taahhütler, bütün mesele. Bu klon ekler ve karşı taahhütte ve daha sonra uzak depo kendisi taahhüt bu itmek olduğunu. Git'i (ve Mercurial gibi sistemlere benzer) DVCS ( Dağıtılmış sistemleri) SVN, PVCS, CVS vb. Gibi daha geleneksel CVS'lerin (Kod Sürümleme Sistemleri) aksine Sürüm Kontrol Sistemi) . doğrudan uzak depoya bağlısınız.
görüntüleme
Temel kavramların görselleştirilmesi
http://marklodato.github.com/visual-git-guide/index-en.html ve http://ndpsoftware.com/git-cheatsheet.html#loc=index adresinde görülebilir.
Değişikliklerin nasıl çalıştığının görsel olarak görüntülenmesini istiyorsanız görsel aracı yenemezsiniz gitg(gitx macOS için) 'metro haritası' (özellikle Londra Metrosu) olarak adlandırdığım bir GUI ile kimin ne yaptığını göstermek için harika, işlerin nasıl değiştiği, saptığı ve birleştiği vb.
Değişikliklerinizi eklemek, uygulamak ve yönetmek için de kullanabilirsiniz!
Gitg / gitx oldukça az olsa da, GUI araçlarının sayısı artmaya devam ediyor. Birçok Mac kullanıcısı brotherbard'ın gitx çatalını kullanır ve Linux için harika bir seçenek, sezgisel ama güçlü bir arayüze sahip smart-git'tir:
Bir GUI aracıyla bile, muhtemelen komut satırında çok sayıda komut yapacağınızı unutmayın.
Bunun için, dosyamda ~/.bash_aliases( ~/.bashrcher terminal oturumu için dosyamdan çağrılır) aşağıdaki diğer adlar var :
# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '
AND benim ~/.gitconfigdosyada aşağıdaki "git aliases" var - neden bunlar?
Böylece şube tamamlama (SEKME tuşu ile) çalışıyor!
Yani bunlar:
[alias]
co = checkout
cob = checkout -b
Örnek kullanım: git co [branch]<- şubeler için sekme tamamlama çalışması yapılacaktır.
GUI Öğrenme Aracı
Bazı temel kavramları öğrenirken https://learngitbranching.js.org/ adresini faydalı bulabilirsiniz . Ekran görüntüsü:
Video: https://youtu.be/23JqqcLPss0
Son olarak, 7 kilit hayat kurtarıcı!
Değişiklikler yaparsınız, ekler ve taahhüt edersiniz (ama itmeyin) ve sonra oh! usta olduğunuzu anlıyorsunuz!
git reset [filename(s)]
git checkout -b [name_for_a_new_branch]
git add [file(s)]
git commit -m "A useful message"
Voila! You've moved that 'master' commit to its own branch !
Yerel bir şubede çalışırken bazı dosyaları karıştırırsınız ve en son yaptığınız şeye geri dönmek istersiniz git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
Yerel olarak değişiklik yapmaya başlarsınız, yarım düzine dosyayı düzenlersiniz ve sonra, ah, hala ana (veya başka bir) daldasınız:
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit them
Geçerli dalınızdaki belirli bir dosyayı dağıtırsınız ve temelde o dosyayı uzak depodan en son çektiğinizde nasıl "sıfırlamak" (değişiklikleri kaybetmek) istersiniz:
git checkout your/directories/filename
Bu aslında dosyayı sıfırlar (birçok Git komutu gibi burada yaptığı şey için iyi adlandırılmamıştır).
Sen bunu yaparken bunları kaybetmek yok emin olmak için, yerel olarak bazı değişiklikler yapmak bir git resetveya rebase: Sık sık tüm proje manuel kopyasını (yapmak cp -r ../my_project ~/ı Git veya önemli kaybetmek de pisliği olabilir eğer emin değilim ne zaman) değiştirir.
Yeniden temellendiriyorsunuz ama işler bozuluyor:
git rebase --abort # To abandon interactive rebase and merge issues
Git şubenizi PS1isteminize ekleyin (bkz. Https://unix.stackexchange.com/a/127800/10043 ), ör.
Şube selenium_rspec_conversion.
