Упатство:Вовед во git: Разлика помеѓу преработките
Нема опис на уредувањето |
с (7 ревизии: initial) |
||
(Не се прикажани 4 меѓувремени преработки од еден друг корисник) | |||
Ред 1: | Ред 1: | ||
''Текстот е во главно превод на официјалниот водич кој се наоѓа на [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html]'' | ''Текстот е во главно превод на официјалниот водич кој се наоѓа на [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html]'' | ||
== Вовед == | |||
Упатството ќе ви објасни како да увезите нов проект во git, да направите промени, и да ги споделите со други. | Упатството ќе ви објасни како да увезите нов проект во git, да направите промени, и да ги споделите со други. | ||
Ред 23: | Ред 24: | ||
Сега снимката е зачувана во во привремена област на премин која git ја нарекува „index“. Промените перменантно можете да ги зачувате со | Сега снимката е зачувана во во привремена област на премин која git ја нарекува „index“. Промените перменантно можете да ги зачувате со | ||
git commit | git commit | ||
Ова ќе ве праша за commit порака (во вашиот едитор), која треба да е кратка и јасна. Честито, ја зачувавте вашата прва ревизија во git. | Ова ќе ве праша за commit порака (во вашиот едитор), која треба да е кратка и јасна. Честито, ја зачувавте вашата прва ревизија во git. | ||
== Правење промени == | == Правење промени == | ||
Ред 39: | Ред 40: | ||
Белешка за commit пораките: Добро е пораките да ги започнете со една кратка линија (помалце од 50 карактери) која ќе ги резимира пораките проследена со една празна линија и подетален опис на промените. На пример, алатките кои ги претвараат commit операциите во е-пошта ја користат првата линија како наслов а останатиот дел како тело на пораката. | Белешка за commit пораките: Добро е пораките да ги започнете со една кратка линија (помалце од 50 карактери) која ќе ги резимира пораките проследена со една празна линија и подетален опис на промените. На пример, алатките кои ги претвараат commit операциите во е-пошта ја користат првата линија како наслов а останатиот дел како тело на пораката. | ||
== Git се грижи содржина, не датотеки == | == Git се грижи за содржина, не датотеки == | ||
Многу системи за контрола на ревизии имаат „add“ команда која му кажува на системот да започни да води грижа за таа датотека. „Add“ командата на git прави нешто попросто и помоќно: git add се користи за нови и изменети (веќе згрижени) датотеки, и во двата случаја прави снимка од датотеките, ја додава таа содржина во индексот, спремна за commit. | Многу системи за контрола на ревизии имаат „add“ команда која му кажува на системот да започни да води грижа за таа датотека. „Add“ командата на git прави нешто попросто и помоќно: git add се користи за нови и изменети (веќе згрижени) датотеки, и во двата случаја прави снимка од датотеките, ја додава таа содржина во индексот, спремна за commit. | ||
Ред 76: | Ред 77: | ||
git branch -d experimental | git branch -d experimental | ||
== Користење на git за соработка == | |||
Соработка меѓу развивачите е една од најважните прочини зошто се користат системи како git. Да претпоставиме една честа ситуација - двајца програмери Алиса и Боб (имињата се честа пракса во криптографијата :)), Алиса направиле нов проект во /home/alice/project, и Боб кој се наоѓа на истиот систем е заинтересиран за проектот и сака да придонеси. Боб започнува со | |||
git clone /home/alice/project myrepo | |||
со што добива своја копија (клон) од складиштето на Алиса во директориумот myrepo. Клонот, како што кажува и името, е на исто рамниште со оригиналниот проект, и има целосна копија на историјата на проектот (не се плашете, git користи магии и добри алгоритми, така што копиите не се големи). Боб го подобрува проектот и перманентно ги зачувува промените во своето складиште | |||
git commit -a | |||
Кога е готов, ја информира Алиса да ги повлечи (анг. pull) промените од неговото складиште. Таа го прави тоа со | |||
cd /home/alice/project | |||
git pull /home/bob/myrepo master | |||
тоа ги спојува промените од гранката master на Боб во тековната гранка на Алиса. Доколку Алиса исто така има промени, тие можи да доведат до конфликт која таа треба да го реши. (забелешка: аргументот master можи да биде изоставен бидејќи е предефиниран). | |||
„pull“ командата всушност прави две работи: прво ги зема промените од специфицираната гранка, а потоа ги спојува со тековната. Кога работите во мала група често ќе работите со една иста гранка. Доколку дефинирате remote гранки можете да си ја олесните работата | |||
git remote add bob /home/bob/myrepo | |||
По додавањето, Алиса можи да ја користи git fetch командата која ќе ги земи промените без да направи спојување | |||
git fetch bob | |||
За разлика од долгата форма кога Алиса ги зема (анг. fetch) промените од Боб користејќи remote складиште претходно наместено со git remote, тоа што е земено се чува во специјална гранка, во овој случај bob/master. Па потоа | |||
git log -p master..bob/master | |||
ги покажува сите промени кои Боб ги направил откако ја одделил својата гранка од Алиса. Откако ќе ги разгледа промените, таа ќе сака да ги спој со своето дрво со командата | |||
git merge bob/master | |||
Спојувањето може да биди направено и на следниот начин | |||
git pull . remotes/bob/branch | |||
pull секогаш спојува со тековната гранка без оглед на тоа што е специфирано. Потоа Боб може да ги добие најновите промените во складиштето на Алиса со | |||
git pull | |||
забележете дека тој не треба да ја специфицира патеката до складиштето на Алиса бидејќи кога тој го клонираше своето складиште од тоа на Алиса, git ја зачува локацијата, и тоа се користи кога нема специфирано патека | |||
git config --get remote.origin.url | |||
(целата конфигурација можете да ја видете со git config -l). Git исто така чува чиста копија од каде што гранката е клонирана под името origin/master | |||
git branch -r | |||
Ако Боб одлучи да работи од друго место, тој сѐ уште можи соработува со Алиса користејќи го ssh протоколот, пример ќе клонира со | |||
git clone alice.org:/home/alice/project myrepo | |||
Меѓутоа ssh не е единствениот протокол, git исто така работи со неговиот прокол, rsync, http. За повеќе информации | |||
man git-pull | |||
== Повеќе за историјата на еден проект во git == | |||
Историјата во git е претставена како повеќе меѓусебно поврзани commit-ови. Веќе ја разгледавме командата git log која може да ги листа. Забележете дека првата линија од секој commit го содржи неговото име | |||
git log | |||
commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 | |||
Author: Junio C Hamano <junkio@cox.net> | |||
Date: Tue May 16 17:18:22 2006 -0700 | |||
merge-base: Clarify the comments on post processing. | |||
Можеме да добиеме повеќе детали за тој commit со | |||
git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 | |||
Имињата претставуваат SHA-1 hash и не се баш практични за користење. Можете да користите само дел од името кој е доволно долг за да го идентификувате commit-от | |||
git show c82a22c39c # најчесто само првите карактери се доволни | |||
git show HEAD # најновата ревизија на тековната гранка | |||
git show experimental # најновата ревизија во experimental гранката | |||
Секој commit обично има еден „родител“ commit кој покажува кон претходната состојба на проектот | |||
git show HEAD^ # родителот на HEAD | |||
git show HEAD^^ # родителот на родителот на HEAD | |||
Git исто така има и grep команда која пребарува стрингови низ целиот проект | |||
git grep "hello" | |||
Многу git команди прифаќаат множества од commit-и кои можат да бидат спефицирани на повеќе начини. Еве неколку примери си git log | |||
git log v2.5..v2.6 # commit-и измеѓу v2.5 и v2.6 | |||
git log v2.5.. # commit-и од v2.5 до последниот | |||
git log --since="2 weeks ago" # commit-и во последните 2 недели | |||
git log v2.5.. Makefile # commit-и од v2.5 до последниот кои ја промениле Makefile датотеката | |||
== Следни чекори == | |||
* Официјалната страна на git [http://git.or.cz/] | |||
* Git за секој ден со 20 команди [http://www.kernel.org/pub/software/scm/git/docs/everyday.html] | |||
* Вториот дел од ова упатство (на англиски) кое ги објаснува техничките работи [http://www.kernel.org/pub/software/scm/git/docs/tutorial-2.html] | |||
* Git за CVS корисници [http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html] | |||
* Google Techtalk презентација на Linus Torvals за git (youtube) [http://www.youtube.com/watch?v=4XpnKHJAok8] | |||
[[Категорија:Упатства]] | [[Категорија:Упатства]] |
Последна преработка од 17:39, 29 јануари 2011
Текстот е во главно превод на официјалниот водич кој се наоѓа на [1]
Вовед
Упатството ќе ви објасни како да увезите нов проект во git, да направите промени, и да ги споделите со други.
Доколку сакате да го користите git само за да ја добиете најновата верзија од некој проект, може повеќе да бидете заинтересирани во првите двe поглавја од упатството за корисници на git [2].
Ако сакате да добиете подетална документација за некоја опција на git, напишете
man git-opcija
пример, за „git pull“ напишете
man git-pull
Увезување на нов проект
Доколку имате архива со некој проект, на пример project.tar.gz можете да го контролирате со git на следниот начин
tar xzf project.tar.bz cd project git init
git ќе ви одговори со
Initialized empty Git repository in .git/
Тоа е тоа, нели беше лесно? Сега кажете му на git да зачува снимка од содржината на сите датотеки во тековниот директориум со опцијата add
git add .
Сега снимката е зачувана во во привремена област на премин која git ја нарекува „index“. Промените перменантно можете да ги зачувате со
git commit
Ова ќе ве праша за commit порака (во вашиот едитор), која треба да е кратка и јасна. Честито, ја зачувавте вашата прва ревизија во git.
Правење промени
Променете некои датотеки, потоа додајте ги нивните променети содржини во индексот
git add datoteka1 datoteka2 datoteka3
Сега сте спремни за commit. Можете да видите кои промени сте ги направиле во diff-стил со git diff
git diff --cached
(без --cached, git ќе ви ги покажи промените кои се направени, но не се додадени во индексот). Можите да добиете и кратко резиме со git status. На крај, перманентно зачувајте ги промените со
git commit
Наместо рачно да пишите git add претходно, двете операции можете да ги направите во еден чекор со
git commit -a
меѓутоа, ова нема да ги препознае новите датотеки.
Белешка за commit пораките: Добро е пораките да ги започнете со една кратка линија (помалце од 50 карактери) која ќе ги резимира пораките проследена со една празна линија и подетален опис на промените. На пример, алатките кои ги претвараат commit операциите во е-пошта ја користат првата линија како наслов а останатиот дел како тело на пораката.
Git се грижи за содржина, не датотеки
Многу системи за контрола на ревизии имаат „add“ команда која му кажува на системот да започни да води грижа за таа датотека. „Add“ командата на git прави нешто попросто и помоќно: git add се користи за нови и изменети (веќе згрижени) датотеки, и во двата случаја прави снимка од датотеките, ја додава таа содржина во индексот, спремна за commit.
Гледање на историјата на проектот
Кога и да било, можете да ја разгледата историјата на проектот преку дневникот со
git log
Доколку сакате да видите компленти diff-ови на секој чекор користете
git log -p
Често доста помага краток поглед на промените
git log --stat --summary
Работење со гранки
Едно git складиште (repository) може да содржи повеќе гранки. На пример, за да направите нова гранка со име „experimental“
git branch experimental
Ако сега напишите
git branch
ќе добиете листа на гранките во проектот, пример
experimental * master
experimental гранката е таа што штотуку ја направивте, а master е предефинираната гранка која за вас се прави автоматски при иницијализрањето на проектот. Астерискот (*) ви кажува на која гранка моментално работите, за промена на гранката
git checkout experimental
што ќе ве однеси во experimental гранката. За да направите промени и да се вратите во master гранката
git commit -a git checkout master
Промената во оваа гранка не е видлива бидејќи ја направивте во experimental гранката. Тука направете други промени па
git commit
Сега имате две гранки кои по нивното разделување имаат различни промени. За да ги споите (што многу често ќе сакате да го правите) напишете
git merge experimental
што ја спојува тековната (master) гранка со experimental. Доколку промените имаат конфликти, ќе има маркери на деловите кои се конфликтни
git diff
ќе ви поможи. Откако рачно ќе ги решите конфликтите направете commit со
git commit -a
Доколку сакате графички приказ на промените напишете
gitk
Сега можите да ја избришете experimental гранката со
git branch -d experimental
Користење на git за соработка
Соработка меѓу развивачите е една од најважните прочини зошто се користат системи како git. Да претпоставиме една честа ситуација - двајца програмери Алиса и Боб (имињата се честа пракса во криптографијата :)), Алиса направиле нов проект во /home/alice/project, и Боб кој се наоѓа на истиот систем е заинтересиран за проектот и сака да придонеси. Боб започнува со
git clone /home/alice/project myrepo
со што добива своја копија (клон) од складиштето на Алиса во директориумот myrepo. Клонот, како што кажува и името, е на исто рамниште со оригиналниот проект, и има целосна копија на историјата на проектот (не се плашете, git користи магии и добри алгоритми, така што копиите не се големи). Боб го подобрува проектот и перманентно ги зачувува промените во своето складиште
git commit -a
Кога е готов, ја информира Алиса да ги повлечи (анг. pull) промените од неговото складиште. Таа го прави тоа со
cd /home/alice/project git pull /home/bob/myrepo master
тоа ги спојува промените од гранката master на Боб во тековната гранка на Алиса. Доколку Алиса исто така има промени, тие можи да доведат до конфликт која таа треба да го реши. (забелешка: аргументот master можи да биде изоставен бидејќи е предефиниран).
„pull“ командата всушност прави две работи: прво ги зема промените од специфицираната гранка, а потоа ги спојува со тековната. Кога работите во мала група често ќе работите со една иста гранка. Доколку дефинирате remote гранки можете да си ја олесните работата
git remote add bob /home/bob/myrepo
По додавањето, Алиса можи да ја користи git fetch командата која ќе ги земи промените без да направи спојување
git fetch bob
За разлика од долгата форма кога Алиса ги зема (анг. fetch) промените од Боб користејќи remote складиште претходно наместено со git remote, тоа што е земено се чува во специјална гранка, во овој случај bob/master. Па потоа
git log -p master..bob/master
ги покажува сите промени кои Боб ги направил откако ја одделил својата гранка од Алиса. Откако ќе ги разгледа промените, таа ќе сака да ги спој со своето дрво со командата
git merge bob/master
Спојувањето може да биди направено и на следниот начин
git pull . remotes/bob/branch
pull секогаш спојува со тековната гранка без оглед на тоа што е специфирано. Потоа Боб може да ги добие најновите промените во складиштето на Алиса со
git pull
забележете дека тој не треба да ја специфицира патеката до складиштето на Алиса бидејќи кога тој го клонираше своето складиште од тоа на Алиса, git ја зачува локацијата, и тоа се користи кога нема специфирано патека
git config --get remote.origin.url
(целата конфигурација можете да ја видете со git config -l). Git исто така чува чиста копија од каде што гранката е клонирана под името origin/master
git branch -r
Ако Боб одлучи да работи од друго место, тој сѐ уште можи соработува со Алиса користејќи го ssh протоколот, пример ќе клонира со
git clone alice.org:/home/alice/project myrepo
Меѓутоа ssh не е единствениот протокол, git исто така работи со неговиот прокол, rsync, http. За повеќе информации
man git-pull
Повеќе за историјата на еден проект во git
Историјата во git е претставена како повеќе меѓусебно поврзани commit-ови. Веќе ја разгледавме командата git log која може да ги листа. Забележете дека првата линија од секој commit го содржи неговото име
git log commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 Author: Junio C Hamano <junkio@cox.net> Date: Tue May 16 17:18:22 2006 -0700 merge-base: Clarify the comments on post processing.
Можеме да добиеме повеќе детали за тој commit со
git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Имињата претставуваат SHA-1 hash и не се баш практични за користење. Можете да користите само дел од името кој е доволно долг за да го идентификувате commit-от
git show c82a22c39c # најчесто само првите карактери се доволни git show HEAD # најновата ревизија на тековната гранка git show experimental # најновата ревизија во experimental гранката
Секој commit обично има еден „родител“ commit кој покажува кон претходната состојба на проектот
git show HEAD^ # родителот на HEAD git show HEAD^^ # родителот на родителот на HEAD
Git исто така има и grep команда која пребарува стрингови низ целиот проект
git grep "hello"
Многу git команди прифаќаат множества од commit-и кои можат да бидат спефицирани на повеќе начини. Еве неколку примери си git log
git log v2.5..v2.6 # commit-и измеѓу v2.5 и v2.6 git log v2.5.. # commit-и од v2.5 до последниот git log --since="2 weeks ago" # commit-и во последните 2 недели git log v2.5.. Makefile # commit-и од v2.5 до последниот кои ја промениле Makefile датотеката