Ha valaki nem hasznalja a gyakorlatban permanensen, annak valoban se nem gyors, se nem konnyu. gitnel meg a commit se egy modosithatatlan valami, a git commit --amend paranccsal barmit hozzafuzhetsz az elozo commithoz, amit kifelejtettel. Ezzel vegre el lehet kerulni a "missing source" cimu commitokat, pl.
Egyebkent pedig a git-nel a commitot es a push-t kulon kell kezelni. Az a gond, hogy az svn szemleleteben a ketto egy, tehat ha egyszer commitolsz, az egyreszt publikus, masreszt vegleges, egyiken se lehet valtoztatni. Git-nel az svn commit-nak nagyjabol a push felel meg, ez az, ami vegleges, es nem lehet rajta valtoztatni, csak egy masik push-sal. A commit azonban kulon eletet el, amig fel nem pusholjak, addig akarmit is lehet vele csinalni, meg visszavonni is lehet, ha az ember azt latja jonak.
A brancheles megint egy kulon dolog, amit megint a maga lenyegeben kell latni. Mig az svn szemleleteben a branch az majdnem egy kulon repo, addig a gitnel a branch nem mas, mint commitok egy halmaza. Hogy nalam hany branch van a lokalis gepemen, az a vilagon senkit nem erdekel. A kozponti repoban levo branchek az erdekesek, mert az publikus, azokat intaktnak kell hagyni amig nincs olyan commitod, ami megegyezes szerint belemehet (ez akar a projvez engedelyet is jelentheti, ezert tud a git alapbol patch mailokat irogatni). Ugyanakkor a git-nel a branch merge az opcionalisan hozza magaval a history-t is, tehat a logban nem csak az latszik, hogy mergeltuk az X fat, hanem az is, hogy az X faban mi tortent. Persze, van squash merge is, ami csak a merge commitot dobja be, illetve rebase is, ami csak a history-t jelzes nelkul, de ezeket normalis projvez kezlevagassal dijazza.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal