Dosyalarımın Geçmişini tutmak için Subversion, Git veya benzeri Sürüm Kontrol Sistemine Başlarken? [kapalı]

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 yapıyorum, ancak bu dosyaların eski sürümlerine geri dönme yolum mükemmel değil. 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şlanabileceğine dair herhangi bir öneriniz var mı?

Sürüm kontrolünü kullanma hakkında ne kadar bilginiz olduğunu bilmiyorum ama yakın zamanda SVN'den Git'e gidip 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 ayarım var, bunun gibi bir dal deniyor production. Yerel olarak bir şeyi uygulamayı / onarımını bitirdiğimde, onu productionşubeye, ardından SSH'yi canlı sitenin sunucusuna birleştirip değişiklikleri çekiyorum. Değişikliklerin üzerine yazıp yazmadığınızı asla bilmediğinizde dosyaları FTP üzerinden sürükleyerek atıyor.

Git ile tanışmak için biraz zaman ayırmanızı öneririm (eğer henüz yapmadıysanız), bir sürü dosyayı değiştirmek / eklemek konusunda SVN'den çok daha kolay ve daha az güçlük çekiyorum (ve SVN'in aksine aptal değil) her yerde.svn klasörler ).

Mac'tayım, eğer bunlardan hiçbiri geçerli değilse üzgünüm ama kod editörü olarak Coda kullanıyorum ve Git (Porticus kullanarak) Port'ları kurdum.

Her şeyi yeniden ayarlayacak olsaydım, yapardım:

1. Koda yükleyin

2. Porticus'u yükleyin (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. GitX 7-5 indirin ve yükleyin

5. Burada bir git repo kurma konusunda iyi bir rehber var , ancak temelde: 1. Terminal'i açın. 2. cdSitenizin oturmasını istediğiniz yere. $: mkdir mysite && cd mysite3. $: git initve 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. adımdaki bağlantı size nasıl uzak bir repo ekleyeceğinizi gösterir, böylece canlı sitenizi denklem haline getirmek istediğinize kadar bunu yapmanız gerekmez. Her şeyin önce yerel olarak çalışmasını öneriyorum (SVN'den farklı olarak, GIT uzak bir depo gerektirmez, bu nedenle şu anda makinenizdeki her şeyi yapabilirsiniz).

SVN'yi her şeyle birlikte sürüm kontrolü için kullanıyorumWordPress geliştirmede yaptığım . Aslında bu şekilde 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, doğrudan bir eklentiyi kontrol ediyorum. /wp-content/plugins/ yerel WordPress kurulumumun dizinine 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 depo oluşturdum ( Rözellikle bu amaç için sabit diskimde bir bölüm var ) ve boş depoyu doğrudan/wp-content/themes . Sonra gerektiğinde değişiklikler yapıyorum ve hazır olana kadar geliştiriyorum, ilerledikçe revizyonlar yapıyorum.

Temayı 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 .svnklasörler 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 (hangisinin değişip hangisinin olmadığını izlemek zorunda kalmazsınız). WordPress'in kullandığı eski 5 dakikalık kurulum gibi - her şeyi yeni sürümle değiştirin.

Şahsen, SVN / GIT'i kurmak 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üt ettiğimde 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 açılan kutu klasörünü paylaşabilirsiniz. Bu, sandıklar, birleştirmeler, vb. Yapmaz, ancak dağıtılmış bir ekibin bir web sitesinde çalışmasını çok kolaylaştırır. Sadece aynı anda aynı dosyalar üzerinde çalışamazsınız.

SVN çalışma kopyasını dropbox'ta saklıyoruz, sonra yazarken dosyaları işlediğimde kabul ediyorum. 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.

Aptana'yı çok seviyorum , entegre bir çöküntüye sahip ve sunucunuza kolayca ftp / sftp ile bağlanıp dosyaları yukarı çekebiliyorsunuz, başka bir harika özelliği de yeni bir php projesi oluşturup "tüm" WordPress'i içeriyor olması. klasöründe (wp-admin, wp-içerir) tema dosyalarınızda kod tamamlama elde edersiniz.

Kurulumumda depo yerel.

"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İ 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 örneğin 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). Gereksinimler herhangi bir araçla doldurulabilir.

Planın yazılmamasının nedeni, hemen hemen tüm WordPress uygulamalarının hala basit bir geliştirme-üretim kurulumuyla 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 nelerin değişikliklere neden olduğuna karar verin, örneğin bir hata düzeltmesi için müşteri çağrısı veya gereken 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ı (IEEE'ye göre) yazdığında, 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ş / çok ağır değil mi: bir şirketiniz olup olmadığına bağlı olarak değişir: iyi bir CM planına sahip olmak bir gün kıçınızdan büyük zaman kazandırabilir.

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.

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. bir şey olduğunda gerçekten makullar.