Arka fon

gitGeçmişte mevcut birçok projeyi yönetmek için VCS'yi (çoğunlukla ) kullandım ve harika çalışıyor. Tipik olarak mevcut bir projeyle, genel işlevselliği optimize eden veya değiştiren koda yaptığım her değişikliği kontrol ederim (ne demek istediğimi biliyorsunuz, uygun adımlarda, değiştirdiğim her satırda değil).

Sorun

Çok fazla pratik yapmadığım bir şey yeni projeler yaratmak. Muhtemelen oldukça büyüyecek yeni bir projeye başlama sürecindeyim, ancak ilk birkaç gün / saat / hafta / dönem içinde yapılacak çok şey olduğunu ve çok değiştiğini görüyorum ürün en temel biçiminde çalışana kadar.

Mevcut bir projede yaptığım gibi sürecin her adımında kontrol etmemin bir anlamı var mı? Henüz çalışmadığı için projeyi yaptığım değişikliklerle kırmıyorum. Şu anda bilgisayardan çıktığımda her günün sonunda VCS'yi yedek olarak kullanıyorum.

İlk birkaç taahhüdüm "Temel dizin yapısı yerinde" ve "DB tabloları oluşturuldu" gibi şeylerdi. Yeni bir projeye başlarken VCS'yi nasıl kullanmalıyım?

Basit Başlat

git init

Check-In Erken, Check-In Sıklıkla

Normalde herhangi bir projeyle ne yaptığınızı yapın: belirli bir görev veya eylem grubuyla ilgili her değişiklik kümesi için "check-in" yapın. Bir sorun izleyici kullanıyorsanız, her kararlı durumda olduğunda bir görevle ilgili değişiklikleri yapın ( ne sıklıkta taahhütte bulunacağınız hakkındaki bu SO sorusuna bakın ). Bir tamamlanma durumunda olmayabilir, sadece yazılımın çalışmadığı veya sitenin oluşturulamadığı kararlı bir durum olabilir. As Jeff Atwood görevinden diyor:

Kod kaynak denetiminde işaretli değilse, yok. [...]

Geliştiriciler kırık kod kontrol önermiyorum - ama aynı zamanda kırık kod ve eksik kod arasında büyük bir fark olduğunu iddia ediyorum.

Sıklıkla, Daha Sonra Mükemmelleştir, Bir Kez Yayınla

Ürün bile yakın çalışılabilir bir duruma değilse, o zaman sadece size uygun biçimde, değişiklikleri kontrol kullanmaya devam iyi muhakeme ve sağduyu birlikte bunları gruba. Her bir dosyanın satır değişikliğini tek tek yapmanız gerekmez, ancak her şeyi büyük bir yığın olarak taahhüt etmek, gerektiğinde geri dönmenizi zorlaştıracaktır.

Sonunda, VCS'niz size yardımcı olmak için burada . Yani VCS size yardımcı olmak için yardım !!

Düşünme

İlk taahhütleriniz iyiydi. Fazla düşünmeyin. En önemli şey check-in yapılmasıdır. Mevcut bir kod tabanından değil, sıfırdan başlayan tüm mevcut açık kaynaklı projelere bakarsanız, ilk revizyonları aşağıdaki gibidir:

dizin yapısını yarattı (yay!)

Alışkanlık Edin

Her günün sonunda, taahhüt günlüklerinize dayanarak yaptığınız işlemlerin bir günlüğünü oluşturmaya çalışın. Eğer elde ettiğiniz git shortlogve git logtatmin edici ve yararlı görünmüyor , yine de gün boyunca projede önemli miktarda çaba sarf ettiyseniz ve bu değişiklikleri kontrol ettiyseniz, muhtemelen doğru yapmadınız .

• git shortlogyaptığınız şeylere genel bir bakış gibi okunmalıdır .
• git logprojenizin tarihi VE hikayesi gibi okumalıdır .

Yaptığınız doğru yaklaşım.

İlk günden itibaren kaynak kontrolünü kullanıyorsunuz - bu, kaynak kontrolünde ihtiyacınız olan her şeye sahip olmanızı sağlayacak ve söyleyebileceğiniz hiçbir nokta yok:

Kaynak kontrolünü kullanmalıyım ama tüm bu şeyleri ilk kez kontrol etmek çok uzun sürecek.

Bu, kaynak kontrolüne geç gelen insanlar için büyük bir engeldir, çünkü daha sonra kullanmak için "çok zor" olduğunu düşünürler. Erken başlayarak ve değişiklikleri sık sık yaparak bu engeli küçük bir adımda azaltmış olursunuz ve projede size katılan herkes hemen çalışmaya başlayabilir.