it-swarm.dev

Začínáme se systémem Subversion, Git nebo podobným systémem pro správu verzí, abyste udrželi historii svých souborů?

Uvědomuji si, že to může být široká otázka na povrchu, ale hledám konkrétní příklady nastavení/pracovních postupů, které lidé používají k udržování historie verzí upravovaných souborů na stránkách aplikace WordPress. Například při vývoji webu (a to i poté, co je živý) často provádím změny souborů CSS a PHP, ale nemám skvělý způsob, jak se vrátit ke starším verzím těchto souborů. Změny na lokálním vývojovém prostředí a následné kopírování těchto změn do živého webu jsou pro mé účely často obtížnější, než bych chtěl. Jakékoli návrhy, jak začít používat nástroj pro správu verzí ke sledování úprav souborů na živém webu?

31
Travis Northcutt

Nejsem si jistý, kolik toho víte o používání řízení verzí, ale nedávno jsem přešel z SVN na GIT a zjistil jsem, že je to skvělé!

Ačkoli to záleží na tom, že váš webový server má nainstalovaný GIT (nebo vám umožní). Mám také GIT nastavení na živém serveru, provozování větve nazvané něco jako production. Kdykoliv dokončím implementaci/opravení místně, sloučím to do větve production, pak SSH do živého serveru a zatáhnu změny. Beats přetáhne soubory přes FTP, když nikdy nevíte, zda přepisujete změny atd.

Doporučil bych dát nějaký čas dostat akvatinted s GIT (pokud ještě nemáte), zjistím, že je mnohem jednodušší a méně potíží než SVN, pokud jde o změnu/přidání zatížení souborů (a na rozdíl od SVN to nedává hloupý .svn složka všude ).

Tak:

Jsem si jistý, že jsem na Macu, takže je mi líto, že se nic z toho netýká.

Editor kódu: Coda Instalovaný GIT přes Porty (pomocí Porticus) Git: GitX

Kdybych měl všechno připravit, udělal bych:

  1. Instalovat Coda

  2. Instalovat Porticus (který bude vyžadovat instalaci Portů, ale na této stránce jsou informace)

  3. Po instalaci aplikace Porticus jej otevřete, vyhledejte "git-core" a Install that.

  4. Stáhnout a nainstalovat GitX 7-5

  5. Existuje dobrý průvodce nastavením git repo zde , ale na jeho základní úrovni: 1. Otevřete Terminál. 2. cd na místo, kde chcete, aby vaše stránky bydlely. $: mkdir mysite && cd mysite 3. $: git init a to je vše! Pokud do této složky přidáte soubory, pokračujte dalším krokem

  6. Jakmile si lokálně nastavíte úložiště GIT (nad článkem), pak pokud tento adresář otevřete v GitXu, budete moci spouštět věci atd.

Nastavení na server může být trochu složitější, mám účet MediaTemple a Dreamhost, které mají GIT mimo krabici. Odkaz v 5. vám řekne, jak přidat vzdálené repo, nemusíte to dělat, dokud nechcete, aby vaše živé stránky do rovnice. Doporučil bych nejprve, aby vše fungovalo lokálně (na rozdíl od SVN, GIT nevyžaduje vzdálené úložiště, takže můžete v současné době vše na svém počítači)

14
Joe Hoyle

Používám SVN pro řízení verzí s all I in WordPress development. Vlastně jsem začal tímto způsobem, protože jsem potřeboval SVN pro plug-in vývoj ... jakmile jsem tam začal, bylo to přirozené rozšíření pokračovat v používání SVN pro motivy a vlastní skripty na klientských stránkách.

Doplňky

Vzhledem k tomu, plug-iny jsou již hostovány na serveru WordPress ', já jsem se jen podívat na plug-in přímo do /wp-content/plugins/ adresáře mé místní instalace WordPress (jsem spustit WAMP na můj vývoj box). Poté provedu změny v místní kopii, a když je připravena na showtime, zavolejte do úložiště. Je to hladký proces, žádné nahrávání/stahování a okamžité ověření, že mé změny fungovaly.

Témata

Témata jsou trochu odlišná, zejména při budování klienta. Vytvořím lokální repozitář (mám na svém pevném disku oddíl R) a prostudujte si prázdný repozitář přímo do mého adresáře /wp-content/themes. Pak dělám změny podle potřeby a vyvíjím se, dokud není připravený, a já jdu dělat revize.

Když jsem připraven publikovat téma na produkční server klienta, exportuji úložiště, Zip a používám nativní Témata >> Přidat novou funkcionalitu ve WordPressu. To funguje také s vlastními plug-iny (které nejsou hostovány WordPressem).

Nástroje

Jak jsem řekl, používám WAMP na svém lokálním počítači, abych spustil vývojovou instalaci WordPressu. Funguje to perfektně na mém boxu a umožňuje mi běžet tolik instancí WordPressu, kolik potřebuji pro konkrétní projekt.

Pro SVN používám Tortoise SVN . Je to zdarma, pozoruhodně snadné použití a integruje se se strukturou souborů a příkazů systému Windows. Aktualizace, potvrzení a export jsou jednoduché, klepněte pravým tlačítkem myši, vyberte příkaz operace. Pomocí "Export" můžete poslat celou složku (bez otravných .svn složek) přímo na libovolné místo dle Vašeho výběru - často exportuji na plochu. Zipování složky je také operace pravým tlačítkem myši a aplikace WordPress zpracovává odesílání.

Manuální přenos souborů může být hádka, zejména pokud stále měníte jeden soubor, ale ne všechny. Pokud místo toho FTP přes celý adresář s "přepsat všechny" vybrané, je to mnohem jednodušší nahradit staré soubory (a nemusíte sledovat, které se změnily a které ne). Je to jako stará 5minutová instalace WordPress, kterou kdysi používali - stačí vše nahradit novou verzí.

8
EAMann

Osobně si myslím, že je to zábavné cvičení nainstalovat SVN/GIT a spravovat to, ale pokud můžete swing $ 15 za měsíc, Beanstalk stojí za každý cent. Řídí celý server pro vás. http://beanstalkapp.com/ Nástroje pro nasazení FTP jsou úžasné. Důl automaticky zavádí verzi na můj pracovní server, když se například dopustím

Dalším způsobem, jak získat nějaké osobní verze souboru, je použít rozbalovací box. Pokaždé, když uložíte soubor do vaší schránky, sleduje jeho verzi a později můžete obnovit jakoukoli předchozí verzi. Vy a další vývojář nebo skupina mohou sdílet složku se seznamem. Připouští se, že to nedělá kmeny, slučuje, atd., Ale dělá to velmi snadné pro distribuovaný tým pracovat na jedné webové stránce. Nemůžete skutečně pracovat na stejných souborech najednou.

Udržujeme pracovní kopii SVN v rozbalovacím seznamu, poté spouštím soubory při zápisu. Moji designéři nebudou spáchat soubory ani se SVN zabývat, takže je to komprimace.

Dávám přednost SVN, protože nepotřebuji všechny trunkingy, které GIT je tak skvělé a jsou k dispozici lepší GUI nástroje SVN.

3
Andrew

Líbí se mi Aptana hodně, jeho Subversion je integrován a můžete se připojit k vašemu serveru pomocí ftp/sftp snadno a Push soubory nahoru, další skvělá vlastnost, kterou má je, že pokud vytvoříte nový php projekt a zahrnete "celá" složka WordPressu (s wp-admin, wp-includes) získáte doplnění kódu v motivových souborech.

V mém nastavení je repo lokální.

2
Amit

Ptáte se na "ale já jsem hledal konkrétní příklady nastavení/workflow, které lidé používají, aby historii verzí upravených souborů na stránkách WordPress", ale také zmínit produkty :)

Dostanete se výše jako odpověď na seznam nástrojů a některých osvědčených postupů, ale zaměřím se zde na pracovní postupy: NEJSOU SPECIFIKOVANÉ:

Pro obecné příklady/nastavení/pracovní postupy:

Pro začátek: tam jsou vzory CM, tak nezávislé na nástrojích. Google na CM vzory, mnoho knih tam, dokonce i wiki komunity, např. http://www.cmcrossroads.com/forums .

Existují také příručky pro nastavení platné strategie toku dat (strategie pro streamování Google) atd.

Nemyslím si, že by bylo něco zvláštního o nasazení WordPressu ve srovnání s CM Managementem včetně distribuovaného paralelního vývoje na velkých továrnách Siebel, SAP, Informatica, Java atd.. Je to opravdu téměř výchozí.

Co mi chybí, myslím, že nikdo nemá napsaný CMplan pro vývoj WordPressu (zatím) (IEEE). Jakmile to někdo udělal (nezávislý na nástroji). Myslím, že požadavky mohou být vyplněny jakýmkoliv nástrojem.

Myslím, že důvodem, proč plán nebyl napsán, je, že téměř všechny implementace WordPressu stále provádí 1 osoba s jednoduchým vývojovým nastavením, takže s více vývojáři/designéry ve fázi budování nemusí nasadit různé verze, které jsou spuštěny prostředí.

plán CMP začíná tím, že identifikuje všechna CI v jiných slovech: vytvořte seznam všech typů CI přítomných v implementaci WordPressu, včetně aplikací, pluginů, databáze, dokumentace, nápovědy, obsahu, konfiguračních souborů, poznámek k vydání (!) atd. ..). To je dobrý začátek. Pak se rozhodněte, které z nich chcete pod CM.

Dále rozhodnout, co způsobuje změny na těchto CI, např. Zákazník zavolá na opravu chyby nebo na upgrade, který je potřeba. Pokud se to udělá správně, vede to k situaci, kdy máte pocit, že věci jsou pod kontrolou.

Rozhodnutí jako sloučení zpět z výroby do vývoje a způsob zpracování, který je součástí této kapitoly (2 hlavní vzory zde) (i když samozřejmě byste se měli snažit tyto opravy hotfix minimalizovat).

Teprve později hledejte nástroj na CM na jedné straně (který zahrnuje správu verzí jako jeden z nástrojů) a nástroje pro správu změn na druhé straně (což vás udrží v klidu).

Myslím si, že je to nejlepší pracovní postup, který začíná, protože, pokud jsem googled, nikdo ještě neudělal. Myslím, že jakmile první osoba napsala plán WordPress CM (podle IEEE), každá další osoba WordPress na světě může kopírovat tento plán a provádět úpravy a implementovat vzory do svých nástrojů.

Není to příliš mnoho práce/příliš těžké: záleží na tom, zda máte společnost nebo ne: může vám zachránit zadek velký čas, aby měl dobrý plán CM.

1
edelwater

Jsem na sdíleném hostiteli, takže nemohu nainstalovat SVN ani nic podobného. Používám Mercurial ke kontrole verzí na svém domácím počítači. Používám Beyond Compare's FTP-sync, aby byly místní a vzdálené složky synchronizovány.

0
CAD bloke

používám git. je to jednoduché. budete muset pochopit jednoduchý příkaz, jako je klon, comit, Push, tah a jste připraveni jít. to je základní.

i když, pokud používáte git více, jako je koordinace týmu pracovat na produktech, pak je to další úroveň. ale nakonec to stálo za to použít git nebo jakoukoliv kontrolu verzí. tam jsou reálné, když se to stane.

0
justjoe