„Szerkesztő:Madbence/Git tutorial” változatai közötti eltérés

1. sor:

==Leírás==

A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg ~~minden fájl~~, hanem ~~mindenhol elérhető a teljes repó~~.

A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg az egész *version history*, hanem (többnyire) lokálisan is megvan az egész repository.

Rengeteg git parancs van, én csak a legfontosabbakat írom le (minden platformra van GUI is hozzá, nekem ezek nem túl szimpatikusak, sokkal hatékonyabb parancssorból buzgerálni mindent)

9. sor:

$ git init</nowiki>

~~Ez annyira~~ nem ~~izgalmas~~, egy létező ~~repót lekérni annál inkább:~~

Ha nem akarunk tökölni az <code>mkdir project; cd project; git init</code> unalmas folyamattal:

$ git init project</nowiki>

Készen is vagyunk. Jöjjön a másik módszer (a gyakoribb), amikor egy létező repóhoz akarunk hozzáférni. Ezt hívjuk klónozásnak.

$ git clone https://foo.bar/baz.git</nowiki>

Ez a parancs az aktuális könyvtárban csinál egy baz mappát, oda pedig mindent szépen letölt.

Ez a parancs az aktuális könyvtárban csinál egy baz mappát, oda pedig mindent szépen letölt. Ha nem tetszik a baz, utolsó paraméterként odabiggyeszthetjük a célkönyvtár nevét (pl .-ot, ha az aktuális könyvtárba szeretnénk létrehozni a repót)

Kultúráltak vagyunk, úgyhogy konfigoljuk be a gitet:

22. sor:

26. sor:

$ git config --global user.email gipsz@jakab.com</nowiki>

Aki nem szereti a vim editort, az beállíthajta, mivel szeretné a commitokat szerkeszteni:

Aki nem szereti a vim editort (az bizony meleg!), az beállíthajta, mivel szeretné a commitokat szerkeszteni:

$ git config --global core.editor emacs</nowiki>

Emacs helyett persze mást is lehet én notepad++-t szoktam használni (ha panaszkodik az elérési útra windowson, akkor az idézőjelekkel kell babrálni:

Emacs helyett persze mást is lehet én windowson notepad++-t szoktam használni (ha panaszkodik az elérési útra windowson, akkor az idézőjelekkel kell babrálni:

"'C:/npp/npp.exe' -multiInst -nosession")

"'C:/npp/npp.exe' -multiInst -nosession"). De egyébként ne használjunk windowst, nagyon gáz.

==Hozzáadás==

69. sor:

73. sor:

Nem kell mindig egyesével hozzáadni a commithoz a fájlokat, az -a kapcsoló automatikusan minden változást bevesz (az új fájlokat még mindig nekünk kell fölvenni!)

Ha nem vagyunk biztosak benne, mi kerül a commitba, a --verbose kapcsoló a commit üzenet megadásakor az egész diffet berakja (diff=előző és mostani változat közötti különbség)

Villámgyors alias: <code>$ git config --global alias.civ "commit --interactive --verbose"</code>, ezek után a <code>$ git civ</code> egy kényelmes szöveges menüt ad nekünk, ahol kényelmesen összerakhatjuk a kommitot.

==Elkúrás==

77. sor:

83. sor:

Az -m kapcsoló használható természetesen.

Mi van, ha nem az utolsó kommit rossz? Akkor egy kicsit nehezebb dolgod van, de semmi gond: <code>$ git rebase -i xxx</code> ahol xxx a rossz kommit szülője. Kapunk egy editort, ahol szépen fel vannak sorolva a kommitok, ezt lehet bántani, átrendezni, kommitokat egybeolvasztani, stb. Ha kulturáltan akarunk fejleszteni (ilyen elég ritkán fordul elő sajnos), akkor mielőtt feltöltenénk a szerverre a változtatásokat, előtte tegyük rendbe a kommitokat.

Mi van, ha szar az egész commit? A reset pont jól fog jönni:

92. sor:

100. sor:

$ git reset --mixed HEAD~</nowiki>

Ez megcsinálja ugyanazt, mint a --soft, de a commithoz hozzáadott fájlokat (hívjuk indexnek ezután) is visszaállítja a mutatott commitra. Ha nem adunk meg a resetnek semmilyen kapcsolót, akkor ezt csinálja alapból.

Ez megcsinálja ugyanazt, mint a --soft, de a commithoz hozzáadott fájlokat (hívjuk indexnek ezután, mert ez a neve) is visszaállítja a mutatott commitra. Ha nem adunk meg a resetnek semmilyen kapcsolót, akkor ezt csinálja alapból.

Még félelmetesebb a

111. sor:

119. sor:

$ git checkout feature</nowiki>

Vagy a kettő egyben:

$ git checkout -b feature</nowiki>

Ezzel elhagyjuk az eredeti fejlesztési ágat (alapból a fő ág a "master"), és átlépünk a "feature" ágra. Itt commitolhatunk kedvünkre, satöbbi. Sőt, még további ágakat is létrehozhatunk.

120. sor:

133. sor:

$ git checkout master

$ git merge feature

$ git branch -D feature</nowiki>

$ git branch -d feature</nowiki>

Először visszaváltunk a főágra. Aztán összeolvasztjuk a két ágat. Majd töröljük a feature ágat.

130. sor:

143. sor:

==Remote==

Távoli repóba is jó, ha mentünk, ilyeneket tud a github vagy a bitbucket.

Távoli repóba is jó ha mentünk, ilyeneket tud a github vagy a bitbucket (előbbi a preferált, illetve a menő).

Ha esetleg nem klónoztuk volna a repót, hanem initet használtunk, akkor hozzá kell adni a távoli repót a remote paranccsal:

149. sor:

162. sor:

$ git push</nowiki>

$ git push -u origin branch</nowiki>

~~Nagyon sok szót nem is pazarolnék~~ rá.

Ahol origin a remote neve, branch az ág (pl master). Ez összeköti a lokális és távoli brancheket, szóval ezek után már később elég egy sima <code>$ git push</code>.

Ha esetleg lesz rá időm, majd írok a githubos pull-request alapú workflow-ról, elég kúl cucc.

==Hogy is volt?==

193. sor:

208. sor:

* 37b0e0f feature4

* 662833a feature3</nowiki>

Mágikus, a fentihez hasonló nagyon trendi <code>$ git lg</code> alias:

$ git config --global alias.lg "log --graph --date-order --all --pretty='%C(yellow)%h%Creset -%C(red)%d%Creset %s %Cgreen(a: %ar, c: %cr) %C(bold blue)<%an>%Creset'"</nowiki>

Utoljára maradt a blame, ami sorran lebontva jeleníti meg egy fájl utolsó szerkesztőit:

200. sor:

220. sor:

Hasznos, ha tudni akarjuk ki kúrta el a fájlt :)

Bisect, stb egy kicsit ödvenszebb téma, érdemes elolvasni a git könyvet: http://git-scm.com/book

=Megjegyzés=

Az írás 2012 elejéről származik, azóta kicsit jobban belemélyedtem a gitbe, de szerintem a leírás még használható. [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 20., 02:26 (CET)

@@ 1. sor: / 1. sor: @@
 ==Leírás==
-A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg minden fájl, hanem mindenhol elérhető a teljes repó.
+A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg az egész *version history*, hanem (többnyire) lokálisan is megvan az egész repository.
 Rengeteg git parancs van, én csak a legfontosabbakat írom le (minden platformra van GUI is hozzá, nekem ezek nem túl szimpatikusak, sokkal hatékonyabb parancssorból buzgerálni mindent)
@@ 9. sor: / 9. sor: @@
 $ git init</nowiki>
-Ez annyira nem izgalmas, egy létező repót lekérni annál inkább:
+Ha nem akarunk tökölni az <code>mkdir project; cd project; git init</code> unalmas folyamattal:
+ <nowiki>
+$ git init project</nowiki>
+Készen is vagyunk. Jöjjön a másik módszer (a gyakoribb), amikor egy létező repóhoz akarunk hozzáférni. Ezt hívjuk klónozásnak.
   <nowiki>
 $ git clone https://foo.bar/baz.git</nowiki>
-Ez a parancs az aktuális könyvtárban csinál egy baz mappát, oda pedig mindent szépen letölt.
+Ez a parancs az aktuális könyvtárban csinál egy baz mappát, oda pedig mindent szépen letölt. Ha nem tetszik a baz, utolsó paraméterként odabiggyeszthetjük a célkönyvtár nevét (pl .-ot, ha az aktuális könyvtárba szeretnénk létrehozni a repót)
 Kultúráltak vagyunk, úgyhogy konfigoljuk be a gitet:
@@ 22. sor: / 26. sor: @@
 $ git config --global user.email gipsz@jakab.com</nowiki>
-Aki nem szereti a vim editort, az beállíthajta, mivel szeretné a commitokat szerkeszteni:
+Aki nem szereti a vim editort (az bizony meleg!), az beállíthajta, mivel szeretné a commitokat szerkeszteni:
   <nowiki>
 $ git config --global core.editor emacs</nowiki>
-Emacs helyett persze mást is lehet én notepad++-t szoktam használni (ha panaszkodik az elérési útra windowson, akkor az idézőjelekkel kell babrálni:
+Emacs helyett persze mást is lehet én windowson notepad++-t szoktam használni (ha panaszkodik az elérési útra windowson, akkor az idézőjelekkel kell babrálni:
-"'C:/npp/npp.exe' -multiInst -nosession")
+"'C:/npp/npp.exe' -multiInst -nosession"). De egyébként ne használjunk windowst, nagyon gáz.
 ==Hozzáadás==
@@ 69. sor: / 73. sor: @@
 Nem kell mindig egyesével hozzáadni a commithoz a fájlokat, az -a kapcsoló automatikusan minden változást bevesz (az új fájlokat még mindig nekünk kell fölvenni!)
 Ha nem vagyunk biztosak benne, mi kerül a commitba, a --verbose kapcsoló a commit üzenet megadásakor az egész diffet berakja (diff=előző és mostani változat közötti különbség)
+Villámgyors alias: <code>$ git config --global alias.civ "commit --interactive --verbose"</code>, ezek után a <code>$ git civ</code> egy kényelmes szöveges menüt ad nekünk, ahol kényelmesen összerakhatjuk a kommitot.
 ==Elkúrás==
@@ 77. sor: / 83. sor: @@
 Az -m kapcsoló használható természetesen.
+Mi van, ha nem az utolsó kommit rossz? Akkor egy kicsit nehezebb dolgod van, de semmi gond: <code>$ git rebase -i xxx</code> ahol xxx a rossz kommit szülője. Kapunk egy editort, ahol szépen fel vannak sorolva a kommitok, ezt lehet bántani, átrendezni, kommitokat egybeolvasztani, stb. Ha kulturáltan akarunk fejleszteni (ilyen elég ritkán fordul elő sajnos), akkor mielőtt feltöltenénk a szerverre a változtatásokat, előtte tegyük rendbe a kommitokat.
 Mi van, ha szar az egész commit? A reset pont jól fog jönni:
@@ 92. sor: / 100. sor: @@
 $ git reset --mixed HEAD~</nowiki>
-Ez megcsinálja ugyanazt, mint a --soft, de a commithoz hozzáadott fájlokat (hívjuk indexnek ezután) is visszaállítja a mutatott commitra. Ha nem adunk meg a resetnek semmilyen kapcsolót, akkor ezt csinálja alapból.
+Ez megcsinálja ugyanazt, mint a --soft, de a commithoz hozzáadott fájlokat (hívjuk indexnek ezután, mert ez a neve) is visszaállítja a mutatott commitra. Ha nem adunk meg a resetnek semmilyen kapcsolót, akkor ezt csinálja alapból.
 Még félelmetesebb a
@@ 111. sor: / 119. sor: @@
   <nowiki>
 $ git checkout feature</nowiki>
+Vagy a kettő egyben:
+ <nowiki>
+$ git checkout -b feature</nowiki>
 Ezzel elhagyjuk az eredeti fejlesztési ágat (alapból a fő ág a "master"), és átlépünk a "feature" ágra. Itt commitolhatunk kedvünkre, satöbbi. Sőt, még további ágakat is létrehozhatunk.
@@ 120. sor: / 133. sor: @@
 $ git checkout master
 $ git merge feature
-$ git branch -D feature</nowiki>
+$ git branch -d feature</nowiki>
 Először visszaváltunk a főágra. Aztán összeolvasztjuk a két ágat. Majd töröljük a feature ágat.
@@ 130. sor: / 143. sor: @@
 ==Remote==
-Távoli repóba is jó, ha mentünk, ilyeneket tud a github vagy a bitbucket.
+Távoli repóba is jó ha mentünk, ilyeneket tud a github vagy a bitbucket (előbbi a preferált, illetve a menő).
 Ha esetleg nem klónoztuk volna a repót, hanem initet használtunk, akkor hozzá kell adni a távoli repót a remote paranccsal:
@@ 149. sor: / 162. sor: @@
   <nowiki>
-$ git push</nowiki>
+$ git push -u origin branch</nowiki>
-Nagyon sok szót nem is pazarolnék rá.
+Ahol origin a remote neve, branch az ág (pl master). Ez összeköti a lokális és távoli brancheket, szóval ezek után már később elég egy sima <code>$ git push</code>.
+Ha esetleg lesz rá időm, majd írok a githubos pull-request alapú workflow-ról, elég kúl cucc.
 ==Hogy is volt?==
@@ 193. sor: / 208. sor: @@
 * 37b0e0f feature4
 * 662833a feature3</nowiki>
+Mágikus, a fentihez hasonló nagyon trendi <code>$ git lg</code> alias:
+ <nowiki>
+$ git config --global alias.lg "log --graph --date-order --all --pretty='%C(yellow)%h%Creset -%C(red)%d%Creset %s %Cgreen(a: %ar, c: %cr) %C(bold blue)<%an>%Creset'"</nowiki>
 Utoljára maradt a blame, ami sorran lebontva jeleníti meg egy fájl utolsó szerkesztőit:
@@ 200. sor: / 220. sor: @@
 Hasznos, ha tudni akarjuk ki kúrta el a fájlt :)
+Bisect, stb egy kicsit ödvenszebb téma, érdemes elolvasni a git könyvet: http://git-scm.com/book
 =Megjegyzés=
 Az írás 2012 elejéről származik, azóta kicsit jobban belemélyedtem a gitbe, de szerintem a leírás még használható. [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 20., 02:26 (CET)