ugrás a tartalomhoz

git repok szinkronba hozása

inf · 2013. Jan. 7. (H), 02.47
Sziasztok!

Git-ben sajnos még mindig tapasztalatlan vagyok. Szeretnék ezen javítani, ha lehet gyakorlati alkalmazásokon keresztül. Addig eljutottam, hogy sikerült godaddy-nél beállítanom a szervert, hogy a push és minden más frankón működjön a gittel. Most egy oldalt szeretnék migrálni erre a szerverre. Sajnos voltam olyan bárgyú, hogy felmásoltam a fájlokat ftp-vel, ez az én feltöltésemmel 2-3 órát is igénybe vett. :S

Most valahogy úgy szeretném szinkronba hozni a szervert az itthoni repommal, hogy bizonyos fájlok ne vesszenek el. Vannak képek, amiket a felhasználók töltenek fel, illetve vannak éles szerverre jellemző konfig beállítások is bizonyos mappákban. Ezeket valahogy ignorálni kéne a push alól. Az összes többi fájlt tőlem felülírhatja az első push, elvileg ugyanaz, mint ami az itthoni repoban is van... Szerintetek, ha az itthoni változaton beállítom a .gitignore-ban, akkor békén fogja hagyni őket?
‹ Tervezési minták Commit utólagos módosítása? ›
 ■
1

Btw. közben az a fantasztikus

inf · 2013. Jan. 7. (H), 02.48
Btw. közben az a fantasztikus ötletem támadt, hogy csinálok itthon több repot, aztán elkezdek játszadozni velük, hogy hogyan viselkednek ilyen esetekben... :-)
2

Na most az a gyanúm, hogy egy

inf · 2013. Jan. 7. (H), 03.48
Na most az a gyanúm, hogy egy sima push-nál ha ignorálom a megfelelő könyvtárakat, akkor nem fognak módosulni. Valszeg egy init és push elég lenne így. Viszont ha már itt tartunk, akkor jobb szeretném, ha lehetne verziózni a nem közös dolgokat. Az éles szerverre feltesznek képeket, illetve törlődnek is képek róla, szeretnék backupot csinálni ezekről, meg az adatbázisról is, a verziókezelés erre meg nagyon jó lenne...

Szóval a fejlesztések push-al mennének fel a környezet specifikus fájlok kivételével, a backupot meg pull-al le lehetne rántani. Na most itt vagy git branch-ek jönnek be a témába, vagy két eltérő build-et kell csinálni az éles és a fejlesztői változathoz, elég tájékozatlan vagyok mindkét témában :S Ti hogy csinálnátok?
3

Én a user tartalmakat

deejayy · 2013. Jan. 7. (H), 08.18
Én a user tartalmakat ignoráltatom a gittel, mondjuk ez nálam általában 1-2 könyvtárat jelent.

.gitignore vagy .git/info/exclude

Azért az csekkold le előtte, hogy nem szerepelnek-e már az érintett fájlok az indexben, mert akkor nem ér semmit az ignore.
4

Szerepelnek, de nem is így

inf · 2013. Jan. 7. (H), 15.23
Szerepelnek, de nem is így oldanám meg. Valami olyasmit szeretnék, hogy 2 repo lenne, az egyik a production env a másik meg a development env. A production-t meg már viszonylag egyszerű szinkronba hozni a szerverrel. A kód változásokat pusholni kell, a felhasználói mappa változásokat meg pullozni. Kérdés az, hogy hogyan lehet elérni, hogy a közös kódrész az egyszerre változzon a production és a development env-ekben.
5

Development és production az

eddig bírtam szó nélkül · 2013. Jan. 7. (H), 15.30
Development és production az két külön repo?
Nem csak a "branch"(??? vagy HEAD??) kell hozzá? Rég volt, lehet, hogy én emlékszem rosszul.
7

De, csak én ilyen szinten nem

inf · 2013. Jan. 7. (H), 17.27
De, csak én ilyen szinten nem vagyok tisztában az alapokkal sem. Most kezdtem el olvasni, az erről szóló cikkeket...
6

re

Greg · 2013. Jan. 7. (H), 16.05
Szerintem rosszul kozelited meg a problemat. A repo-t nem backupra talaltak ki, arra vannak backup megoldasok. A fejlesztoi verziobol pedig valamilyen deploy cuccal told fel a szerverre a valtoztatasokat, ami nem modositja azokat a reszeket amiket nem kell(pl felhasznalok altal feltoltott kepek, etc). Ilyen peldaul a capistrano, amit igazabol rails-hez keszitettek, de mas alkalmazashoz is hasznalhato.
8

Jenkins, amibe bele szeretnék

inf · 2013. Jan. 7. (H), 17.30
Jenkins, amibe bele szeretnék tanulni, de egyszerre túl nagy falatnak tűnik branch-eket, deployt, meg minden ilyesmit megtanulni. Egyébként tudsz olyan backup megoldásról, ami csak a különbségeket tölti le, nem a teljes mappát?
9

rsync

Greg · 2013. Jan. 7. (H), 17.41
peldaul rsync sziknronizal, tehat a kulonbsegeket menti le. de inkabb incremental backup megoldasokat nezd meg.
10

Ok. Amúgy szerintem

inf · 2013. Jan. 7. (H), 17.57
Ok. Amúgy szerintem branchinggel is megoldható, most olvastam olyat, hogy

Another reason to use version control is so that you can use your repository as the source to deploy code to your servers. Much like feature and bug-fix branches, environment branches make it easy for you to separate your in-progress code from your stable code. Using environment branches and deploying from them means you will always know exactly what code is running on your servers in each of your environments.


Szóval elvileg lehet külön ágat csinálni környezetenként, és a megfelelőről frissíteni az adott szervert. Elsőnek ennek járok utána, aztán a deploy-os megoldásnak. Egy sima git ignore + rsync a backup-nak pl elég egyszerű megoldás lenne...
11

megoldhato

Greg · 2013. Jan. 7. (H), 18.07
de a branch nem erre van kitalalva.
mi egyebkent tag-elni szoktunk olyan meloknal ahol nincs folyamatos fejlesztes, es mindig az utolso tag amit kuldunk a production szerverre.
ahol folyamatosan megy a fejlesztes ott pedig feature brancheken dolgozunk, amit idonkent merge-elunk a masterba es a masterbol idonkent frissitjuk a production servert.
A gitrol egyebkent ennek a sracnak az irasai/eloadasai erdekesek: http://zachholman.com/
12

Ezzel valami újat mondtál.

eddig bírtam szó nélkül · 2013. Jan. 7. (H), 18.35
Ezzel valami újat mondtál. Vagy nem értem, hogy inf3rno mit is akar.
Nem úgy kellene működnie, hogy a branch kb. az egyes fejlesztési szakaszokat jelenti?
13

branchek

Poetro · 2013. Jan. 7. (H), 18.44
A branch-ek születhetnek új szolgáltatás kifejlesztésére. Akkor a dev ágból leágaztatunk, kifejlesztjük a szolgáltatást, majd vissza integráljuk amikor készen van. Ennek ugye az az előnye, hogy többen tudnak ugyan azon a szolgáltatáson dolgozni, valamint egészen addig nem érinti az alkalmazást, amíg nem lett integrálva.
Használhatunk ágakat az alkalmazás egyes szintjeiről. Például dev, staging, hotfix, production. Ezek az alkalmazás különböző rendszerekre való kikerülését mutatják.
17

Itt egy viszonylag komplex

MadBence · 2013. Jan. 7. (H), 21.23
Itt egy viszonylag komplex példa, ami próbálja maximálisan kihasználni a különböző fejlesztési ágakat.
Nyilván ez nem szentírás, a szerzőnek bejött, másnak más jön be.
18

Érdekelne, hogy egész

inf · 2013. Jan. 8. (K), 02.04
Érdekelne, hogy egész pontosan hogyan működik ez az elágazás dolog. Konkrétan az, hogyha elágaztatsz mondjuk a főágról, és később módosítod a főágat, akkor a mellékágad is módosul e, vagy sem? Alapból gondolom onnantól, hogy elágaztattad új életet kezd élni... Ha mégis lehetséges így megcsinálni, akkor lehetséges a környezetet is beállítani elágazásokkal, függetlenül attól, hogy ez az aktuális divat, vagy sem :-) Ha ez alapból nem támogatott, akkor lehetne egy új repot (aminek más a környezete) frissíteni állandóan, mondjuk hook-al. Ezt mondjuk már lehet akár deploynak is nevezni.

A feature meg bugfix ágak mikéntjét azt egyébként értem, csak próbálgatom a git határait...
20

..

Greg · 2013. Jan. 8. (K), 09.35
A mellekag nem modosul ha a foagat modositod, de barmikor merge-elheted a branch-eket.
Es mint ahogy fentebb is irtam, sokan sokfelekeppen hasznaljak a DVSC-t, ugyhogy hasznalhatod akar kornyezeteknek is a brancheket.
21

Ja, közben én is rájöttem,

inf · 2013. Jan. 8. (K), 13.28
Ja, közben én is rájöttem, nem is annyira bonyolult ez a git :-)

Pl egy php-nél vagy js-nél deploy-ra sincs igazán szükség, legalábbis teszt szerveren...
14

re

Greg · 2013. Jan. 7. (H), 18.53
branch-et en egy adott feature-hoz szoktam letrehozni. Peldaul van egy webshop, ahol eddig nem volt szallitasi koltseg kezeles, es most ezt bele kell fejleszteni. Ebben az esetben csinalok neki egy branchet es elkezdek rajta dolgozni, es ha keszen van, akkor merge-elek a master-ba. Es a branch mehet a kukaba.
A fejlesztesi szakaszokat inkabb a tag-ekkel szokas jelolni(v0.1, v0.2, stb).
De sokan, sokfelekeppen hasznaljak a DVSC rendszereket.
15

Poetro elég jól megfogalmazta

eddig bírtam szó nélkül · 2013. Jan. 7. (H), 19.02
Poetro elég jól megfogalmazta (idézte?) amire utalni próbáltam. :-)
16

ugyanarra gondoltam en is,

Greg · 2013. Jan. 7. (H), 19.05
ugyanarra gondoltam en is, csak ezek szerint nem erthetoen fogalmaztam.
19

Összeállt a kép.Kell

inf · 2013. Jan. 8. (K), 04.23
Összeállt a kép.

Kell csinálni minden környezethez 1-1 branch-et, és arra mergelni rá az aktuális fejlesztéseket egy olyan ágból, ami nem tartalmazza a konfig fájlokat, feltöltött képeket, etc... Az egyik ilyen ágat szinkronban lehet tartani a szerverrel, így a backup is működni fog. Ha szükség van buildre is, mert pl javascriptnél össze kell csomagolni egy fájlba az osztályokat, akkor a kimenetet be lehet tenni egy külön ágba, vagy egy külön repoba, nyilván ilyenkor ez az ág vagy repo lesz szinkronban tartva a szerverrel. A szinkronban tartást és a build-et egyébként meg lehet oldani hook-okkal.

off:
Nem is nagyon értem, hogy ezek a build rendszerek miért annyira elterjedtek... Tök felesleges xml-ben megadni dolgokat, ha egyszer le tudja programozni őket az ember, és ugyanúgy meg tudja hívni őket git hook-ból. Majd utánanézek ennek is.
22

Azt hiszem összedobok egy

inf · 2013. Jan. 8. (K), 16.30
Azt hiszem összedobok egy bevezető jellegű cikket a git használatáról, amint jobban belerázódtam, már ígértem clean code-os cikket, de az sokkal nehezebben megfogható téma, mint ez.
23

Belefutottam még egy

inf · 2013. Jan. 12. (Szo), 06.23
Belefutottam még egy problémába. Tegyük fel, hogy van mondjuk egy local nevű ágam, meg van egy server nevű ágam. A server a local-ból ágazik le, a szerver konfigja van rajta, illetve szinkronban van tartva a szerverre feltöltött fájlokkal, etc... Amikor valami új feature-t vezetek be mondjuk egy topic branch-en, ami a localból ágazik le, akkor utána mergelem a server ágra, ha már fel lehet tenni éles szerverre, utána meg pusholom, hogy fel is kerüljön. Na most itt lehetnek gubancok. A szerveren a HEAD alapból a server ágon van, és kell, hogy legyen folyamatosan, a feltöltött fájlok pedig oda kerülnek be. A kérdés az, hogy amikor push-ot tolok a szerver felé, akkor mi történik a még nem kommittolt, a server ágon leledző, vagy éppen onnan az előző commit óta törölt fájlokkal?

Nyilván nekem az lenne a jó, ha ezek az "egyéb változások" érintetlenül maradnának. Ha ez nem így történik, akkor mit javasoltok?
24

A kérdés az, hogy amikor

Poetro · 2013. Jan. 12. (Szo), 10.44
A kérdés az, hogy amikor push-ot tolok a szerver felé, akkor mi történik a még nem kommittolt, a server ágon leledző, vagy éppen onnan az előző commit óta törölt fájlokkal?

Ha valami nincs még kommitolva, akkor nem létezik a verziókezelőben, ergo nem lesz push-olva. Ugyanakkor a helyen, ahova a push érkezik keletkezhetnek conflict-ok pont amiatt, hogy az ott levő változások nem kompatibilisek a változásokkal.
25

Hát ez nem egy túl konkrét

inf · 2013. Jan. 12. (Szo), 16.25
Hát ez nem egy túl konkrét válasz. Ami a szerveren változna az fájl feltöltések, illetve fájl törlések, a fejlesztésekkel az esetek döntő többségében biztosan nem ütközne. Szerinted ilyen esetben mi történne ezekkel a változásokkal? Itt van egy kis űr a git-es tudásomban. Azt hiszem a legjobb az lenne, ha kipróbálnám teszt repokkal.
26

verziókezelés vs. juzer tartalom

T.G · 2013. Jan. 12. (Szo), 18.00
Milyen haszon származik abból, ha a verziókezelőbe beleteszed a juzerek által feltöltött fájlokat? Én ezt egyszerűen úgy gondolom, hogy a .gitignore fájl tartalmazza az upload mappát, és a továbbiakban egyáltalán nem érdekel, hogy mi van ott. Az upload mappára nincs ilyen szofisztikált verziókezelő, csupán a szerver backup-ja, de az bőven elég.
27

Csak plusz egy felesleges

inf · 2013. Jan. 12. (Szo), 18.03
Csak plusz egy felesleges feature lett volna :-) Annyira nem fontos, majd megnézem, hogy milyen backup lehetőségek vannak még. Igazából egy idő után csak a gond lett volna a verziókezelttel, mert a már törölt fájlok is bent lettek volna a history-ban, és elfogyott volna a tárhely...
28

A tárhely problémák is

inf · 2013. Jan. 14. (H), 17.48
A tárhely problémák is megoldhatóak gittel, a squash commits-al egybe lehet olvasztani commit-okat, szóval mindig csak az utolsó x db tükrözné az aktuális állapotot. Nagyon jól ki van találva ez a git, sok dologra alkalmas... Még nem döntöttem el, hogy mivel fog menni a deploy, most valahogy biztosabbnak érzem, ha egy rsync-el csinálom, de ma tesztelek több dolgot gittel, amik még nem világosak, aztán utána döntök...

A mergelés helyett biztosabb a rebase szerintem, ha a szerver konfigot külön ágon akarom cipelni... Tegyük fel, hogy módosítok a local config-ján, ilyenkor ha mergelni akarom a local-t a szerver config-jával, akkor merge collision lesz, amit persze fel lehet oldani, de az a fejlesztési időből vesz el. Helyette vagy mindkét konfignak külön ágat kell csinálni a master-ről, és mindkettőt mergelni a master változásaival, vagy a server ágat rebase-elni. Esetleg csinálni lehet egy-egy superprojectet, és a konfigurációs dolgokat azokban elhelyezni. A környezetenként egy-egy superproject, ill. az eredeti projekt modulba tétele tűnik jelenleg a legszimpatikusabb megoldásnak nálam.
29

rollback

Greg · 2013. Jan. 14. (H), 18.23
Ha rsync-et hasznalsz akkor a rollback az hogyan fog kinezni ha a szerveren jelentkezik egy hiba a friss deploy-al? En a helyedben erre kitalalt eszkozt hasznalnek, mint pl a capistrano.
30

Csinálok egy checkout-ot az

inf · 2013. Jan. 14. (H), 18.25
Csinálok egy checkout-ot az előző commit-ra, aztán azt rsyncelem. Btw. nem valószínű, hogy az rsync bármilyen szerepet fog játszani nálam. Sokkal valószínűbb, hogy az egészet gittel oldom meg. (Ha már azzal megy, akkor meg megnézem, hogy a deploy rendszerek miben tudnak többet, aztán döntök arról, hogy szükségem van e rájuk.)
31

re

Greg · 2013. Jan. 14. (H), 19.18
Peldaul azzal tud tobbet, hogy
  • a szerveren tart revision-oket a rollbackhez, igy masodprecek alatt tudsz visszaallni az elozo allapotra ha gond van
  • el tudsz vegezni a szerveren elesites elotti processt, peldaul a css fajlok osszefuzese es tomoritese
  • a szerveren mielott elesitened a frissitest le tudod futtatni a tesztjeidet es ha hiba van, akkor nem is frissiti az app-ot


Most hirtelen ennyi jutott eszembe.
32

Egyelőre most ezek nem

inf · 2013. Jan. 14. (H), 19.26
Egyelőre most ezek nem kellenek. Ettől függetlenül hasznosnak tűnnek, a következő project-nél beleásom magam, annál szükség lesz fájlok összefűzésére...
33

További előny, hogy a

inf · 2013. Jan. 20. (V), 02.20
További előny, hogy a build-hez nem kell ágat váltani. Mondjuk ha a teszt rendszer független az env ágaktól, és alapból elérhető a dev ágon is, akkor ez nem annyira számottevő... Ránézésre a build rendszerek tisztább, szárazabb érzést nyújtanak.