Evreleme alanının amacı, taahhüdünüz için esnek bir alana sahip olmaktır . Sanırım yıkım gibi merkezileştirilmiş sürüm kontrol sistemlerine gittiğinizde bu daha net olacak.
yıkılma
Subversion'da, çalışma kopyanızın belirli dosyalarını teslim etmeyi seçebilirsiniz. Ama sadece tam dosyalar. Şimdi: Dosyaya Adeğil, dosyaya Bve dosyanın dosyayla Cilgili Akısımlarına değil, dosyadaki değişikliklere bağlı olan kısımlara değil B(o zamandan beri taahhüt tutarlılığıyla ilgili bir sorun yaşarsınız).
Git
Git, sahnelemenin ikinci çalışma kopyası olarak sağlayarak bunu çözer. Evreleme alanı içinde (kabaca konuşacağınız) bir anlık görüntü oluşturuyorsunuz.
Bu nedenle, hazırlama alanında, değişiklikleri içeren bir anlık görüntü Ave Cyalnızca değişiklikleri yansıtan bir dosya sürümü oluşturabilirsiniz A.
Özel sorular için
İstediğiniz noktada sahne alabilirsiniz. Taahhüdü başlatmadan hemen önce şahsen sahnelemeyi tercih ederim.
Hazırlanmış bir dosyada değişiklik yaptıktan sonra çalışma kopyasında bu dosyayı değiştirirken, aşamalı dosyayı elbette değiştirmediniz. Bunları da sahneleyip yerleştirmeyeceğinize veya bu değişiklikleri sahneleyip yerleştirmeyeceğinize karar verebilirsiniz. Yani git gui citoolkoşarsanız aşamalı ve düzensiz sürümlerin farklarını göreceksiniz (satır bazında evreleme ve taahhüt için güzel ve basit araçlar).
Git burada temkinli, muhtemelen iyi bir şey.
Genel taahhüt stratejisi: Ayrıntılı taahhütler
Bence "Ne zaman sahnelemeliyim" sorusundan bahsederken, taahhüt alışkanlıkları hakkında da konuşmak gerekir.
Merkezi VCS
Merkezi bir sunucuya bağlı olduğunuz merkezi sürüm kontrol sistemlerinde, iş arkadaşlarınız için taahhütlerinizin eksiksiz ve iyi test edilmiş olması önemlidir. Böylece insanlar sık sık işlememeye ve sonra hata olasılığını en aza indirmek için tam dosyaların durumunu taahhüt etmeye çalışırlar. Bu nedenle, bir taahhüt, çok sayıda değişiklik içeren (basit düzeltmeler değilse) oldukça büyük parçalar olma eğilimindedir. Bir taahhütteki değişiklikler tamamen ilgisiz olabilir.
Git
Git'te yerel olarak bir işlem yapılır, yalnızca sunucuya iletilmesi onları herkese açık hale getirir. Dolayısıyla bir taahhüt bir anlamda ucuzdur . Yıkım anlamında bir taahhüt, git commitbunu takip eden birkaç kişi ile karşılaştırılabilir git push. Bu fark önemlidir.
Git, aynı dosyadaki diğer satırları değiştirmiş olsanız bile, tek bir kod satırı uygulamanızı sağlar. Yeni bir özellik getiren 300-350 satırlarını değiştirirken 100. satırda bir güvenlik hatası düzeltmesi uygulayabileceğiniz için bu size birçok avantaj sağlar.
- Farklı taahhütlerde farklı değişiklikleri ayırabilirsiniz. Bu, onları sürüm geçmişinizde güzel bir şekilde ayırır ve hatta birini geri döndürmenize izin verir, ancak diğerini değil.
- Taahhüdünüzün mutlaka çalışma kopyanızın "derleme" durumunu yansıtması gerekmez (her ne kadar ben böyle tutmaya çalışsam da).
Peki, bir yıkım kullanıcısının beklediği bir taahhütte "kalite kontrol" ve inşa garantisi nerede? Git'teki diğer eylemlere kaydırılır. Yine de halka açık bir depoda programın işleyen bir durumunu dışarı itmek istiyorsunuz. Bu nedenle değişikliklerinizi yapmadan önce testlerin başarılı olduğundan ve programın çalıştığından emin olursunuz.
Ayrıca, dalları maks. Çok sayıda küçük değişiklik yaparken, oldukça büyük bir sürüm geçmişi elde edersiniz. Dallarda çalışıyorsanız, bu parçalı taahhütleri dal adına göre kategorize edebilir ve daha sonra birleştirebilirsiniz (seçenek --no-ffayrıca bu özelliklerin benzersiz bir dalda yaşandığını da koruyacaktır).
Yani master, şube iyi durumda ise, şubeye birleşme alışkanlığını koruyabilirsiniz . Etiketleri ayrıca kilometre taşlarını ve sürümleri izlemek için de kullanabilirsiniz.
Şimdi evrelemeye geri dönelim: Her taahhütte birkaç satır taahhüt ettiğinizde, taahhütte bulunmadan önce doğrudan sahne alacaksınız. (En azından ben böyle yaparım).
git diffvegit diff --cachediyi, ama bazen daha fazlasını istiyorum).