Pontosan azért jöttem fel ide, hogy ezt megkérdezzem :D
Szerintem is katasztrófa a SourceTree, pedig milyen jól indult. A legrosszabb, hogy az ékezetes karaktereket egyáltalán nem tudja kezelni fájl nevekben és olyan szinten belerondít a gitbe, hogy utána hard reset és mindenféle trükközésekkel tudom visszaállítani a rendet. Rászoktam, hogy most már terminálból nyomom a commitokat viszont ott nem tudom részekre szedni ha esetleg több különböző feladatot oldottam meg egyszerre.
Azért az ékezetes fájlnevek nem tartoznak a természetes dolgok közé… 
Nem értem. Terminalban is ugyanúgy kell stagelni commit előtt. Kézzel összeszeded az összetartozó file-okat, és rájuk nyomsz egy commitot. A maradék fileokra meg egy (vagy több) másikat.
1 kedvelés
Fájlokon belül is szoktam egy-egy sort kivenni/betenni a commitból/commitba.
Amúgy szeretem megrendelőnként különválasztani a porjektet és a megrendelőnek a nevét szoktam adni a mappának. Valamint, ha magyar az alkalmazás, akkor a magyar nevét adom meg a mappának. És ebből szokott gond lenni.
A másik gond amibe ütköztem nemrég, hogy az Apple fájlrendszere nem különbözteti meg a kis/nagybetűt és emiatt ha egy kis/nagybetű változás történik a fájlban, akkor azt a git nem tölti fel. Volt már ebből problémánk és 1 óra volt mire rájöttünk, hogy nem került átnevezésre a fájl egy másik gépen, ahol letöltötték a legújabb commitokat…
Azert ott akkor nem (csak) a GIT a hibas…
Ha mar sorokat kell kommitol elol elrejteni akkor ott valami munkaszervezesi gond van. Lehet az eszkozzel kuzdeni, csak nem erdemes. Inkabb erdemes vegiggondolni, hogy tenyleg olyan egyedi-e a Te eseted, hogy azt nem lehet lefedni a GIT alap eszkozeivel.
(Az ekezetes fajlneveket most hagyjuk. Ami nem 7bit ascii, az nem fajlrendszerbe, nekem ez a velemenyem, de mindegy.)
Nem egészen. Hanem sokszor az van, hogy van több feladat és a feladatok átfedik egymást. Tehát hogy megoldjak egy feladatot, ahhoz meg kell oldanom egy másikat is egyszerre. És nem lehet őket szétválasztani két külön részre, mert külön-külön egyik sem működik ezáltal nem tesztelhető.
Én még mindig nem értem. Szerintem teljesen ok, hogy akár egy soros változtatásokat is elkommitolsz, könnyebb revertelni, átnézni. Átírsz három fileban egy-egy sort, git add file1, file2, file3, git commit. Mondjuk a Tower azért kényelmesebb. :)
Én sem használok soha ékezetet filenévben, spacet sem, helyette ekezetes_filenev.txt. Úgy tuti soha sehol nem lehet gond, mindegy, hogy hova kerül.
Egyébként ti tudtátok, hogy van Macre egy Tortoise-hoz hasonló cucc, ami ugyanazt tudja, vagyis a file-okon látod a státusukat, és van gites menü jobbklikkre?
Van belőle ingyenes verzió is az App Storeban, nem tudom, mi a különbség közöttük.
Trollkodósoknak:
Szintén van belőle ingyenes verzió.
Nálam az eclipse és svn van használatban
Mutatom:
Mindkét képen ugyanazok a változások vannak egy fájlon belül. A fájlon belül alapból két részre osztja változásokat, mert két külön helyen vannak a változások (látszik a sor számánál, hogy van egy kis “szakadás”). Nos ezt már eleve külön commitba tudom tenni, nem kell az egész fájlt egy commitba tenni. Ezen kívül a Sourctreeben ha kijelölök sorokat, akkor ezeket a sorokat külön is be tudom tenni egy commitba és nem kell úgy betennem, ahogy a program ajánlja.
Természetesen itt is egy kattintással az egész fájlt egy commitba tudom tenni.
You are a hero… :D
Ugyan. En is svn parti vagyok.
Nade, hogy a temahoz is hozzaszoljak. En ugy szoktam, hogy 1 ticket/feladat legalabb 1 commit, es a commit commentben hivatkozok a ticketre. Ezt egy normalis projektkezelo be is linkelni az adott tickethez.
Ha pedig tobb ticket ugyonaz a problema, es kozos a megolas, akkor szoktam letrehozni egy osszefoglalo ticketet, a tobbit pedig e ticket duplikaltjanak nevezni, es a duplikalt ticketre hivatkozva a commit commentben.
Ááá nekem bejön, mondjuk én kimerülök egy kis XML vagy properties fájl szerkesztésében. Ja az kimaradt, hogy a redmine-ban kezeljük a ticketeket és az svn commitok be vannak linkelve a tickethez.
Tudtok esetleg olyan text editort, ami automatikusan szinkonizálja a helyi fájlokat a remote szerverrel, ha git branchet váltasz? Az IntelliJ-ben van ilyen feature, de néha elég lenne egy editor is, ha menne ez.
en a git utalok taboraba tartozom :D
És miért?
En az alabbi hatranyokkal talalkoztam eddig git eseten:
- a verzio azonositojabol szemmel nem lehet eldonteni, hogy melyik az ujabb/regebbi
- nem kozpontositott a repo, minden kliens tart maganal egy sajat repot, aminek a szinkronizalasat is a kliens vegzi, igy hiaba van backup a szerverrol, ha ott nincs fenn az informacio, akkor adatvesztes elofordulhat.
- http-n keresztul nem mukodott a push, csak a clone, a pushhoz anno ssh hozzaferest kellett volna adni.
- remalom windowsra leforditani
Viszont utoljara akkor probaltam, amikor vegigment a neten, hogy Linus megalkotta a legjobb verziokezelot. Akkor en mar evek ota svnt hasznaltam. Az elso verziok nekem nem tuntek jobbnak az svnnel. Azt tudom, hogy sokat valtozott azota (pl. van mar normalis http feletti mukodes, vagy vannak prebuild binarisok windowsra) de semmi olyan elonyet nem latom, amire szuksegem volna es az svn nem tudja megoldani.
Egy svn/git hitvitat (mint az amd/intel, vagy amd/nvidia) pedig nincs ertelme elinditani.
2 kedvelés
+1
Igen, azóta már azért nagyon sokat frissült. Hogy jobb-e, mint az svn vagy mercury, arról fogalmam sincs. Ezt a verzió dolgot nem értem. A branch verziójára gondolsz? Mert alapból tényleg így van, de ha van egy jobb git kliens, akkor abból egyértelműen kiderül vizuálisan, hogy melyik branch melyik másik branchből készült. Persze arról még a merge ugyanúgy rémálom lehet…
Szóval én nem mondom, hogy szeretem, de használom. És jobb, mint a semmi :D …
Ne haragudj. :D Nem nyúlok hozzá, töröld, amelyiket szeretnéd.
Semmi baj, elküldtem a választ, néztem, hogy átkerültek máshová, mondom, akkor onnan kitörlöm, ide berakom… :)