it-swarm.asia

Dosyalarımın Tarihini saklamak için Subversion, Git veya benzeri Sürüm Kontrol Sistemine Başlarken?

Bunun yüzey üzerinde geniş bir soru olabileceğinin farkındayım, ancak insanların WordPress sitesinde düzenlenmiş dosyaların sürüm geçmişini tutmak için kullandıkları belirli kurulum/iş akışlarına örnekler arıyorum. Örneğin, bir site geliştirirken (ve yayınlandıktan sonra bile), genellikle CSS ve PHP dosyalarında değişiklikler yaparım, ancak bu dosyaların eski sürümlerine geri dönme biçimim mükemmel değildir. Amaçlarım için, yerel bir geliştirme kurulumunda değişiklik yapmak ve ardından bu değişiklikleri canlı siteye kopyalamak genellikle istediğimden daha fazla sorun. Canlı bir sitedeki dosyalara yapılan düzenlemeleri izlemek için bir sürüm oluşturma aracı kullanmaya nasıl başlanacağına dair herhangi bir öneriniz var mı?

31
Travis Northcutt

Sürüm kontrolünü kullanmak hakkında ne kadar şey bildiğinizden emin değilim, ancak son zamanlarda SVN'den GIT'ye geçiş yaptım ve bunu harika buldum!

Size bağlı olmasına rağmen canlı sitenin sunucusunda GIT yüklü (veya size izin verecek). Ayrıca canlı sunucuda bir GIT kurulumum var, production adı verilen bir dalın çalıştırılması. Ne zaman yerel olarak bir şeyi uygulamaya koymayı/düzeltmeyi bitirsem, onu production dalına, ardından SSH'yi canlı sitenin sunucusuna birleştirip değişiklikleri çekerim. Değişikliklerin üzerine yazıp yazmadığınızı asla bilmediğinizde dosyaları FTP üzerinden sürükleyerek atıyor.

GIT ile sulandırmaya biraz zaman ayırmanızı öneririm (eğer henüz yapmadıysanız), dosya yükünü değiştirmek/eklemek konusunda SVN'den daha kolay ve daha az güçlük çekiyorum (ve SVN'in aksine aptal değil) .svn klasörü her yerde ).

Yani:

Tabii, ben bir Mac'im, bunlardan hiçbiri geçerli değilse, üzgünüm.

Kod Düzenleyicisi: Koda GIT Bağlantı Noktalarına GIT (Porticus kullanarak) Git: GitX

Her şeyi yeni kurarsam, yapardım:

  1. Kur Coda

  2. Yükle Porticus (bu, Bağlantı Noktalarını yüklemenizi gerektirir, ancak bu sayfada bilgi vardır)

  3. Porticus'u kurduktan sonra açın, "git-core" aratın ve kurun.

  4. İndir ve Yükle GitX 7-5

  5. Git repo here kurulumunda iyi bir rehber var, ancak temelde: 1. Terminal'i açın. 2. cd, sitenizin oturmasını istediğiniz yere. $: mkdir mysite && cd mysite 3. $: git init ve bu kadar! Bu klasöre dosya eklerseniz bir sonraki adıma geçin.

  6. Yerel olarak bir GIT deposu kurduğunuzda (yukarıdaki makalenin yukarısındaki) o zaman GitX'te bu dizini açarsanız malzeme vb. İşlem yapabilirsiniz.

Her şeyi sunucuda ayarlamak biraz zor olabilir, her ikisi de kutudan GIT'i olan bir MediaTemple ve bir Dreamhost hesabım var. 5. bölümdeki bağlantı size nasıl uzak bir repo ekleyeceğinizi anlatıyor, canlı sitenizi denklem haline getirmek istediğinize kadar bunu yapmanız gerekmez. Öncelikle yerel olarak çalışan her şeyi almanızı tavsiye ederim (SVN'den farklı olarak, GIT uzak bir depo gerektirmez, bu nedenle şu anda makinenizdeki her şeyi çalıştırabilirsiniz)

14
Joe Hoyle

SVN'yi sürüm kontrolü için everything ile WordPress geliştirmede kullanıyorum. Aslında bu yoldan başladım çünkü eklenti geliştirme için SVN'ye ihtiyacım vardı ... oraya başladığımda, temalar ve müşteri sitelerinde özel komut dosyaları için SVN kullanmaya devam etmek doğal bir uzantıydı.

Eklentiler

Eklentiler zaten WordPress sunucusunda barındırıldığından, yerel WordPress kurulumumun /wp-content/plugins/ dizinine doğrudan bir eklenti ekliyorum (geliştirme kutumda WAMP kullanıyorum). Sonra yerel kopyamda değişiklikler yapıyorum ve şov zamanı hazır olduğunda depoya bağlı kalıyorum. Orada sorunsuz bir işlem var, yükleme/indirme ve değişikliklerimin işe yaradığını doğruladım.

Temalar

Temalar, özellikle bir müşteri için oluştururken biraz farklıdır. Yerel bir veri havuzu oluşturuyorum (özellikle bu amaçla sabit diskimde R bölümüm var) ve boş veri havuzunu doğrudan /wp-content/themes dizinime yönlendiriyorum. Sonra gerektiğinde değişiklikler yapıyorum ve hazır olana kadar geliştiriyorum, ilerledikçe revizyonlar yapıyorum.

Temayı bir müşterinin üretim sunucusunda yayınlamaya hazır olduğumda, depoyu dışa aktarıyorum, sıkıştırıyorum ve yerel Temalar >> WordPress içinde Yeni işlevler ekle'yi kullanıyorum. Bu, özel eklentilerle (WordPress tarafından barındırılmayan) da çalışır.

Araçlar

Dediğim gibi, WordPress'in bir geliştirme kurulumunu çalıştırmak için yerel makinemde WAMP kullanıyorum. Kutumda mükemmel çalışıyor ve belirli bir proje için ihtiyaç duyduğum kadar WordPress örneği çalıştırmamı sağlıyor.

SVN için, Tortoise SVN kullanıyorum. Ücretsizdir, kullanımı oldukça kolaydır ve Windows'un dosya ve komut yapısıyla bütünleşir. Güncelleme, taahhüt etme ve dışa aktarma işlemlerinin tümü basit sağ tıklamayla yapılır, komut işlemlerini seçin. "Dışa Aktar" seçeneğini kullanmak, tüm klasörü (rahatsız edici .svn klasörleri olmadan) doğrudan istediğiniz herhangi bir yere göndermenizi sağlar - Sık sık masaüstüne aktarırım. Klasörü sıkıştırmak da sağ tıklatma işlemidir ve WordPress yüklemeyi gerçekleştirir.

Dosyaların manuel olarak aktarılması, özellikle de bir dosyayı değiştirmeye devam ediyorsanız hepsini değil, güçlük yaratabilir. Bunun yerine, "dizinin üstüne yaz" seçiliyken dizinin tamamında FTP kullanıyorsanız, eski dosyaları değiştirmek çok daha kolaydır (ve hangisinin değiştiğini ve hangilerinin değişmediğini takip etmeniz gerekmez). WordPress'in kullandığı eski 5 dakikalık kurulum gibi - her şeyi yeni sürümle değiştirin.

8
EAMann

Şahsen, SVN/GIT'i yüklemek ve yönetmek için eğlenceli bir egzersiz olduğunu düşünüyorum, ancak ayda 15 dolar sallayabiliyorsanız, Beanstalk her kuruşa değer. Tüm sunucuyu sizin için yönetiyorlar. http://beanstalkapp.com/ FTP dağıtım araçları harika. Mine, örneğin, taahhütte bulunduğumda sürümü otomatik olarak hazırlama sunucuma dağıtıyor

Bazı kişisel dosya sürümlerini almanın başka bir yolu da drop box kullanmaktır. Bir dosyayı dropbox'ınıza her kaydettiğinizde sürümü izler ve daha sonra herhangi bir önceki sürüme geri yükleyebilirsiniz. Siz ve başka bir geliştirici veya grup bir drop box klasörünü paylaşabilirsiniz. Bu, sandıklar, birleştirmeler, vb. Yapmaz, ancak dağıtılmış bir ekibin bir web sitesinde çalışmasını kolaylaştırır. Sadece aynı anda aynı dosyalar üzerinde çalışamazsınız.

SVN çalışma kopyasını dropbox'ta tutuyoruz, sonra zaman yazıldığında dosyaları işlediğimde. Tasarımcılarım dosya işlemeyecek veya SVN ile uğraşmayacak, yani bu bir karşılaştırma.

SVN'yi tercih ediyorum çünkü GIT'in çok iyi olduğu bütün kanallara ihtiyacım yok ve SVN'de daha iyi GUI araçları var.

3
Andrew

Ben Aptana lot'u seviyorum, Subversion'un entegre bir sürümü var ve sunucunuza kolayca ftp/sftp ile bağlanabilirsiniz ve Dosyaları yukarı itin, yeni bir php projesi oluşturun ve ekleyin. "bütün" WordPress klasörü (wp-admin, wp-içerir) ile tema dosyalarında kod tamamlama elde edersin.

Kurulumumda depo yerel.

2
Amit

"Ancak insanların WordPress sitesinde düzenlenmiş dosyaların sürüm geçmişini tutmak için kullandıkları belirli kurulum/iş akışı örnekleri arıyorum" ancak ürünlerden de bahsediyorsunuz :)

Bir araç listesi ve bazı en iyi uygulamaların bir yanıtı olarak karşınıza çıkıyorsunuz ama burada iş akışlarına odaklanacağım: İŞ YERİNE ÖZEL DEĞİLDİR:

Ancak genel örnekler/kurulumlar/iş akışları için:

Yeni başlayanlar için: ARE CM kalıpları var, yani kalıplamadan bağımsız. Google'da CM Patterns, birçok kitap var, wiki bile toplulukları mesela. http://www.cmcrossroads.com/forums .

Geçerli bir akış stratejisi (google akış stratejisi) vb.

Büyük Siebel, SAP, Informatica, Java vb. Fabrikalarda paralel gelişim dahil, CM Management ile karşılaştırıldığında WordPress dağıtımlarında özel bir şey olduğunu sanmıyorum. Gerçekten neredeyse varsayılan.

Eksik olan, bence kimsenin WordPress gelişimi için bir CMplan yazmamış olması (henüz) (IEEE). Birisi bunu yaptığında (araç bağımsız). İhtiyaçlar herhangi bir araçla doldurulabilir.

Planın yazılmamasının nedeni, neredeyse tüm WordPress uygulamalarının hala basit bir geliştirme-üretim kurulumuna sahip 1 kişi tarafından yapıldığını, bu nedenle yapım aşamasında çalışan farklı sürümleri dağıtmak zorunda kaldıklarını, yapım aşamasında birden fazla geliştirici/tasarımcının kullanmayacağını düşünüyorum. örneğin test ortamı.

cMP planı tüm CI'lerin başka bir deyişle tanımlanmasıyla başlar: uygulamalar, eklentiler, veritabanı, belgeler, yardım, içerik, yapılandırma dosyaları, sürüm notları (!), vb. dahil olmak üzere bir WordPress uygulamasında mevcut olan tüm CI türlerinin bir listesini yapın. ..). Bu iyi bir başlangıç. Öyleyse hangilerini CM altına koymak istediğinizi seçin.

Daha sonra, bu CI'lerde neyin değişmesine neden olduğuna karar verin; Bir hata düzeltmesi için müşteri çağrısı veya gerekli bir yükseltme. Doğru yapılırsa, bu, işlerin kontrol altında olduğu hissine sahip olduğunuz bir duruma yol açar.

Üretimden kalkınmaya geri dönüş ve bu bölümün bir parçası olarak ele alma gibi kararlar (buradaki 2 ana kalıp) (elbette bu düzeltmeleri en aza indirmeye çalışmalısınız).

Ancak daha sonra bir tarafta CM (bir araç olarak sürüm yönetimini içeren) ve diğer tarafta yönetim araçlarını (aklı başında tutar) değiştirecek bir araç arayın.

Sanırım, kimsenin henüz yapmadığı kadarıyla başlangıçtan beri en iyi iş akışı bu. Sanırım ilk kişi bir WordPress CM Planı yazdığında (IEEE'ye göre) dünyadaki diğer tüm WordPress çalışanları bu planı kopyalayabilir ve ayarlamalar yapabilir ve kalıplarını uygulamalarında uygulayabilir.

Çok fazla iş değil mi/çok ağır: bir şirketiniz olup olmadığına bağlı olarak değişir: iyi bir CM planına sahip olmak bir gün kıçınızı büyük bir zaman kazandırabilir.

1
edelwater

Paylaşılan bir Ana Bilgisayardayım, bu yüzden SVN veya benzeri bir şey yükleyemiyorum. Mercurial'ı ev makinemde versiyon kontrolü için kullanıyorum. Yerel ve uzak klasörleri senkronize tutmak için Beyond Compare'in FTP senkronizasyonunu kullanıyorum.

0
CAD bloke

git kullanıyorum. basit. klonlama, itiraz etme, itme, çekme gibi basit komutları anlamalısınız ve gitmeye hazırsınız. bu temel.

olsa da, onu bir ürün üzerinde çalışmak için bir ekibi koordine etmek gibi kullanırsanız, o zaman başka bir seviyedir. ama sonunda git veya herhangi bir versiyon kontrolünü kullanmak için darmadağın oldu. bok olduğunda gerçekten makullar.

0
justjoe