Упатство:Вовед во git: Разлика помеѓу преработките

Од Сподели wiki
Прејди на прегледникот Прејди на пребарувањето
Нема опис на уредувањето
 
с (7 ревизии: initial)
 
(Не се прикажани 6 меѓувремени преработки од еден друг корисник)
Ред 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, да направите промени, и да ги споделите со други.  
Ред 7: Ред 9:
Ако сакате да добиете подетална документација за некоја опција на git, напишете
Ако сакате да добиете подетална документација за некоја опција на git, напишете
  man git-opcija
  man git-opcija
пример, за „git pull“ на папишете
пример, за „git pull“ напишете
  man git-pull
  man git-pull


== Увезување на нов проект ==
== Увезување на нов проект ==
Доколку имате архива со некој проект, на пример project.tar.gz можете да го контролирате со git на следниот начин
Доколку имате архива со некој проект, на пример project.tar.gz можете да го контролирате со git на следниот начин
  tar xzf project.tar.bz
  tar xzf project.tar.bz
Ред 21: Ред 24:
Сега снимката е зачувана во во привремена област на премин која git ја нарекува „index“. Промените перменантно можете да ги зачувате со
Сега снимката е зачувана во во привремена област на премин која git ја нарекува „index“. Промените перменантно можете да ги зачувате со
  git commit
  git commit
Ова ќе ве праша за commit порака (во вашиот едитор), која треба да е кратка и јасна. Ја зачувавте вашата прва ревизија во git
Ова ќе ве праша за 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 датотеката


== Следни чекори ==
* Официјалната страна на 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 датотеката

Следни чекори

  • Официјалната страна на git [3]
  • Git за секој ден со 20 команди [4]
  • Вториот дел од ова упатство (на англиски) кое ги објаснува техничките работи [5]
  • Git за CVS корисници [6]
  • Google Techtalk презентација на Linus Torvals за git (youtube) [7]