- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Csapatmunkára git, egyéni programokhoz fossil.
- A hozzászóláshoz be kell jelentkezni
Git SourceTree-vel nagy kar hogy linuxra nincs, pedig egy elmeny a hasznalata a parancssor-karate utan. Ezen a teruleten az IDE-k nagyon le vannak maradva.
- A hozzászóláshoz be kell jelentkezni
Azért elég jó az Eclipse-es EGit (JGit) is, ha nagyon nem akarsz parancssorozni.
- A hozzászóláshoz be kell jelentkezni
Csak kíváncsiságból, lehetséges-e és mennyi kattintással a következő task ebben a guis dologban:
- van egy repód x (sok) committal amiben valahol van egy subdir
- ki akarod emelni ezt a subdir -t top levelre, a többit eldobni
- végeredményben minden olyan commit -ot kidobni, aminek nincs köze ahhoz a subdirhez, a megmaradó commitokat újraírni úgy, hogy csak a releváns fájlokat módosítsa
- végeredményben egy olyan repository -t kapni ami úgy tűnik mintha mindig is csak ezt a subfoldert tartalmazta
(hasznos például ha egy appból kiemelsz valamit library -ként és szeretnéd külön repóban kezelni)
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
- A hozzászóláshoz be kell jelentkezni
Azért azt szerintem te is elismered, hogy nem ez a tipikis napi git használat.....
Mondjuk a napi használathoz se nagyon kell gui (nekem), főleg ha van valami github-szerű felület....
- A hozzászóláshoz be kell jelentkezni
Igen, a napi clone fetch pull rebase push stb dologhoz éppen jó a CLI felület, mert gyorsabb, komolyabb feladatokhoz meg már nem is alkalmas a gui, nem is értem, hogy mi szükség rá egyáltalán.
(jó, valamennyire értem hogy a newcomer-eknek kicsit nehézkes a git, ismerős a sztori nekem is)
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
- A hozzászóláshoz be kell jelentkezni
Mert mondjuk egy szép listát látok, hogy mi módosult, törlődött, mi nincs hozzáadva, stb., amit 1-2 kattintással kényelmesen tudok orvosolni és nem kilométernyi parancsok beirkálásával.
Pl. mikor bővítem egy pluginnel a rendszerünket, lesz egy egész új könyvtár, onnan be kell emelni ami szükséges, 1-2 dolgot ignorera rakni, stb. Ez néhány kattintással megvan TortoiseSVN-ben, CLI-ben hadd ne mondjam, hogy mennyi plusz idő.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"Mert mondjuk egy szép listát látok, hogy mi módosult, törlődött, mi nincs hozzáadva, stb., amit 1-2 kattintással kényelmesen tudok orvosolni és nem kilométernyi parancsok beirkálásával."
git status
git diff [ path... ]
gitk / gitg / gitx
Nem látom a kilométereket :)
Én még nem döntöttem el egyértelműen hogy pl. az új Eclipse-ben a default EGit integráció jó dolog-e. Lehet. (pl. fájlok mappák ikonjait megpróbálja informatívan dekorálni)
Valahogy úgy vagyok vele hogy az IDE -vel a kódot túrom, a fájlokat meg a VCS -vel, és zavar ha a kettő beleugat a másik dolgába.
"CLI-ben hadd ne mondjam, hogy mennyi plusz idő."
Nem ismerem az svn -t (hálistennek? 10 fogorvosból 9 inkább ellenjavasolja)
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
- A hozzászóláshoz be kell jelentkezni
"gitk / gitg / gitx"
Ezek is gui-k, csak parancssorból indítva.
Amikor csúnya konfliktusos fájlokat ki kell bogozni, abban is sokat segít egy gui-s diff.
- A hozzászóláshoz be kell jelentkezni
Példában az svn irreleváns. Bármelyik TortoiseXXX "Xheck for modifications" vagy commit ablaka megteszi. De amugy, ugy latom, te ugy irtad le a gui-s dolgokat, hogy azt sem tudod, h miről beszélek: a fenti példa az svn status kimenetet dolgozza tovább es teszi szerkeszthető e, ahol egy fájlra meg kulon dulpaclixkkel tudsz nézni diffet, vagy kezelni konfliktust. Diffet meg nézzen parancssorban az, akinek 6 anyja van, foleg, hogy mar reg a 3 utas siff tooloknal kellene tartani, nem a 2-nel.
---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"De amugy, ugy latom, te ugy irtad le a gui-s dolgokat, hogy azt sem tudod, h miről beszélek"
Pontosan odaírtam 1-el feljebb hogy szerencsére nem volt szerencsém még az svn-hez (és különösebben nem is érdekel)
Illetve ha jobban megnézed ez a thread a gitről és a rárakott guik értelméről szól.
Az SVN-es példát te hoztad, nem konkrétan arra válaszoltam.
szerk.: a git diff nem kapcsolódik szorosan a conflict kezeléshez, a 3 utas diffelés totál másra való. Egyszerűen veszi a dirty változtatásaidat és diff formátumban kiköpi (pl. hogy patch fájlt gyárts, ha valami miatt az jó neked)
--
http://developersideas.blogspot.hu/
http://neurogadget.com/
- A hozzászóláshoz be kell jelentkezni
Nagyszerű, de a topic az verziókezelő. És mint mondtam, van mindenféléhez Tortoise*, pl. van TortoiseGIT is. És mint mondtam a check for modification nem a diff megfelelője, hanem a status megfelelője.
Patch gyártására meg ott a create patch opció, de nem értem, hogy jön ahhoz, hogy egyszerűbb GUI-n azt kezelni, hogy mit commitolok és mit nem.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
egyszerűbb GUI-n azt kezelni, hogy mit commitolok és mit nem.
Nekem a git add és a git commit tab-complete-ol parancssorból, csak azokkal a fileokkal amik újak vagy változtak. Nekem ez tökéletes, mert nincs a git tree tele mindenféle szeméttel (out-of-tree compilation).
- A hozzászóláshoz be kell jelentkezni
Nagyszerű, akkor nézzük a következő scenariót:
- Adott egy C#-os solution, benne mondjuk 100 projekttel, többezer fájljal, amiből mondjuk 10 a keretrendszer, 60 modul, maradék meg plugin a modulokhoz. 2-3 Application, többi class library (gyk.: ".exe" és ".dll")
- Hozzáadok egy új modult/plugint, AnkhSVN (Visual Studio plugin) ilyenkor automatikusan hozzáaddolja (illetve törli, áthelyezi, etc.) az SVN-hez a dolgokat.
- Fejlesztem a dolgomat, majd rájövök, hogy egy általánosan használt libben el lett valami cseszve, emiatt javítani kell benne. Tfh. ez refactoringgal is jár, mittom törlök egy paramétert, a másik kettőt meg átrendezem. Tfh. a refactor emiatt módosít 50 projektben 100 fájlt random helyen az egész solutionból.
- Szeretném commitolni ezt a bugfixet, de úgy, hogy ne legyen benne az új modulom/pluginem 15 új fájlja, mert logikailag nem egy commitba tartozik.
Ilyenkor mind a 100 fájlt autocompleteljem be neki? Ugye csak viccelsz? :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Neked olyan workflow-d van, amihez kell a GUI, az enyémhez nem kell, ill. nagyon ritkán. Ha nekiállok valami tök más dolognak hirtelen, akkor egyszerűen git stash, és tiszta lappal indulok, megcsinálom amit akarok, aztán git commit -a, git stash pop, és máris visszakaptam ahol tartottam, nem keverednek össze a dolgok.
Szerintem nem jó gyakorlat _egyszerre_ két (al)projekten dolgozni ugyanabban a fában, előbb-utóbb hibázik az ember és nem odavaló dolgok kerülnek egy commitba, és SVN esetén még javításra se nagyon van lehetőség.
Egyébként ha tényleg nem tart az ember szemetet a source treeben, és az ignore file jól van beállítva, akkor még tab completion sem kell, csak git add . && git commit és kész. Ezt én nem csinálom, mert egyszerre max 5-10 filet/könyvtárat adok hozzá a repóhoz, azokat meg lehet kézzel addolni és néha azért bekerül a szemét.
- A hozzászóláshoz be kell jelentkezni
Itt a projekt az nem az egesz projektet jelenti, hanem, amit a Visual Studio hiv projektnek. "A" projekt az nalam jelen esetben kb. 5 solutionbol (1 kliens, 1 szerver, 1 tools, es 2 plugingyujtemeny, hogy ne a szerver forditasanal huzza az idot) es kb. osszessegeben 80-90 projektbol (amibol kb. 6 .exe-ve, maradek .dll-e fordul) all ossze.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Ez mit változtat a dolgokon?
Szerintem, ha az ember kettő különböző dolgon (pl. feature-ön, akár ugyanabban a projektben) dolgozik, akkor rakja azokat külön branch-be, ha megfelelően nagyok. De azt írtad, hogy valami 100 file változik, ez már megér egy branchet, git-tel legalábbis, mert ott olcsó egy branch. Akár lehet csak lokális branch is, nem kell a központi repoban branchet csinálni ehhez. Ha tudom hogy tíznél több file fog változni, akkor tuti branchet csinálok, akár menet közben is, amikor összejött a tíz.
Ha meg kevés változtatást igényel egy feature, akkor meg csak válassza el őket egymástól, git stash és kész, minden tiszta, nincs keveredés.
Hangsúlyozom, ez csak szubjektív véleményem. Ha te egyszerre implementálsz akár csak kettő feature-t, úgy, hogy mindkettő több tíz vagy száz filet érint, és soha nem kevered össze a változásokat egy commitba véletlenül, akkor szerintem legalábbis szupermen lehetsz.
- A hozzászóláshoz be kell jelentkezni
Most ebbol a szempontbol mindegy, hogy mit csinaltam. A lenyeg az volt, hogy N db fajlbol X db-ot kellett kivalasztanom, hogy mit commitolok es mit nem. Es ez az X nem 2 db volt, hanem sok.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem mindegy, mert a use-case amit leírsz a legtöbb ember számára nem létezik, vagy csak nagyon ritkán. Ha gyakran jön elő, akkor szvsz rosszul használják a verziókezelőt.
De egyébként még az n-ből x esetben is jobb a cli szvsz, pl. git add --patch és minden változott fileról eldöntheted, hogy akarod committálni, vagy sem, egy gombnyomással, per file. Vagy akár részleteket is választhatsz egy fileból ha akarsz. Vagy csinálhatod ezt könyvtáranként is. Pl.
git add fontos1 fontos2 # innen minden kell
git add --patch kevesbe # innen egyesevel valogatok
git commit
Persze svn cli-ben gondolom nincsenek erre eszközök, és marad a gui. Viszont ez a szál gitről indult.
- A hozzászóláshoz be kell jelentkezni
Azert a "git add --patch" -ot merhetetlenul nagy mertekben konnyiti meg egy GUI.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
arra vagyok kivancsi, hogy az a nehany ember, aki clearcase-t jelolte kedvencnek, annak milyen mentalis problemaja van? :-)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Már vártam ezt a hozzászólást :-)
- A hozzászóláshoz be kell jelentkezni
nagy :-)
- A hozzászóláshoz be kell jelentkezni
Amúgy mi a baj vele? Sose hasznaltam, csak érdekekel.
- A hozzászóláshoz be kell jelentkezni
Nem egy tiszta ugy :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
Lassan a monotone meg a gnu arch ki is eshetne... mindig rakerdezunk, es mindig ilyen eredmenyeket produkal.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
Hát új felhasználókat már nem szereznek, ezt ki lehet jelenteni szerintem......
- A hozzászóláshoz be kell jelentkezni