Git менен баштоо: үйрөнчүктөр үчүн толук жол

Кириш сөздүн ордуна

Саламатсызбы келечектеги улук программалык камсыздоо инженери. Бүгүн биз versionны башкаруу системасы жөнүндө сүйлөшөбүз, тактап айтканда Git (англисче грамматикадан көрүнгөндөй JIT эмес, GIT деп окугула). Ооба, ооба, мен Mercurial, SVN да бар экенин билем... Бирок, чынчыл бололу: алардын убактысы өтүп кеткен, мен аларга баалуу убактыңызды коротпойм. Биздин убакта Гитти билүүнүн маанилүүлүгүн түшүнүшүңүз үчүн, мен муну айтайын: муну билбестен/түшүнбөй туруп, программалоодо эч кандай ишиңиз жок. Бирок сулуулук, тынымсыз иштөө үчүн бардык буйруктарды жана мүмкүнчүлүктөрдү башыңызда сактоонун кажети жок. Сиз болуп жаткан нерселердин баарын түшүнүүгө жардам бере турган бир катар буйруктарды бorшиңиз керек.

Git негиздери

Git биздин code үчүн бөлүштүрүлгөн version башкаруу системасы болуп саналат. Эмне үчүн муктажбыз? Бөлүштүрүлгөн командалар кандайдыр бир ишти башкаруу системасына муктаж. Убакыттын өтүшү менен болгон өзгөрүүлөргө көз салуу керек. Башкача айтканда, этап-этабы менен кайсы файлдар жана кантип өзгөргөнүн көрөбүз. Бул бир тапшырманын алкагында жасалган иштерди талдоодо өзгөчө маанилүү: бул артка кайтууга мүмкүндүк берет. Келгиле, бир жагдайды элестетип көрөлү: жумушчу code бар болчу, анда баары жакшы болчу, бирок биз бир нерсени жакшыртууну чечтик, аны бул жерден оңдоп, ошол жерден чыңдап коелу. Баары жакшы болчу, бирок бул жакшыртуу функциянын жарымын бузуп, иштөөгө мүмкүн болбой калды. Анда эмне болот? Гитасыз адам бир нече саат отуруп, бардыгынын башында кандай болгонун эстеп калууга туура келет. Ошентип, биз жөн гана милдеттенмеге кайтып келебиз жана ушуну менен бүттү. Же бир эле учурда эки иштеп чыгуучу codeду өзгөртсөчы? Гитсиз мындай көрүнөт: алар codeду оригиналдан көчүрүп алып, эмне кылыш керек болсо, ошону кылышты. Убакыт келип, экөө тең өзгөртүүлөрүн негизги папкага кошкусу келет. Анан мындай кырдаалда эмне кылуу керек?.. Бул ишти аткаруунун убактысын эсептегенге да батынбайм. Эгер сиз Gitти колдонсоңуз, мындай көйгөйлөр такыр болбойт.

Git орнотулууда

Gitти компьютериңизге орнотуп алалы. Мен ар кимдин ар кандай OS бар экенин түшүнөм, ошондуктан мен бир нече учурларды сүрөттөөгө аракет кылам.

Windows үчүн орнотуу

Адаттагыдай эле, сиз exe файлын жүктөп алып, аны иштетишиңиз керек. Бул жерде баары жөнөкөй: биринчи Google шилтемесин чыкылдатыңыз , орнотуңуз жана бүттү. Жумуш үчүн биз алар берген bash консолун колдонобуз. Windows менен иштөө үчүн Git Bash'ти иштетишиңиз керек. Бул баштоо менюсунда ушундай көрүнөт: Бул сиз иштей турган консол. Gitти ачуу үчүн ар дайым долбоор менен папкага кирбеш үчүн, папканы оң баскыч менен чыкылдатып, консолду бизге керектүү жол менен ачсаңыз болот:

Linux үчүн орнотуу

Адатта, git мурунтан эле орнотулган жана Linux дистрибуцияларына киргизилген, анткени ал башында Linux ядросун иштеп чыгуу үчүн жазылган курал. Бирок ал жок болгон жагдайлар бар. Муну текшерүү үчүн терминалды ачып, теришиңиз керек: git --version. Эгер так жооп болсо, эч нерсе орнотуунун кереги жок. Терминалды ачып, орнотуңуз. Мен Ubuntuдо иштейм, андыктан ал үчүн эмне жазыш керектигин айта алам: sudo apt-get install git. Мына ушундай: эми сиз Gitти каалаган терминалда колдоно аласыз.

MacOS боюнча орнотуу

Бул жерде да, адегенде Gitтин бар-жоктугун текшеришиңиз керек (жогоруда, Linux сыяктуу). Болбосо, эң оңой жолу - акыркы versionсын жүктөп алуу . Эгерде XCode орнотулган болсо, анда Git сөзсүз түрдө автоматтык түрдө орнотулат.

Git орнотуу

Гитте колдонуучу жөндөө бар, андан жумуш аткарылат. Бул акылга сыярлык жана зарыл нерсе, анткени милдеттенме түзүлгөндө, Гит Author талаасы үчүн дал ушул маалыматты алат. Бардык долбоорлор үчүн колдонуучу атын жана паролду орнотуу үчүн, сиз төмөнкү буйруктарды киргизишиңиз керек:

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com

Эгер белгилүү бир долбоордун авторун өзгөртүү зарылчылыгы болсо (мисалы, жеке долбоор үчүн), сиз --global-ды алып салсаңыз болот жана бул иштейт:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

Бир аз теория...

Тема боюнча калуу үчүн билдирүүңүзгө бир нече жаңы сөздөрдү жана аракеттерди кошуу максатка ылайыктуу... Болбосо сүйлөшө турган эч нерсе болбойт. Албетте, бул кээ бир жаргон жана англисче көчүрмө, ошондуктан мен англисче маанилерди кошом. Кандай сөздөр жана иш-аракеттер?

• git репозиторий;
• милдеттендирүү (милдеттенүү);
• бутак;
• бириктирүү;
• чыр-чатактар;
• тартуу;
• түртүү;
• кээ бир файлдарды кантип четке кагуу керек (.gitignore).

Жана башка.

Гиттеги штаттар

Гитада түшүнүү жана эстен чыгарбоо керек болгон бир нече жагдайлар бар:

• коштолбогон;
• өзгөртүлгөн;
• даярдалган (этапталган);
• жасалган.

Ал эмнени билдирет?

Бул биздин codeдогу файлдар жайгашкан мамлекеттер. Башкача айтканда, алардын жашоо жолу, адатта, мындай көрүнөт:

1. Түзүлгөн жана репозиторийге кошулбаган файл көзөмөлдөнбөгөн абалда болот.
2. Биз Git репозиторийине кошулган файлдарга өзгөртүүлөрдү киргизебиз - алар өзгөртүлгөн абалда.
3. Биз өзгөрткөн файлдардын ичинен биз керектүүлөрдү гана (же бардыгын) тандайбыз (мисалы, бизге түзүлгөн класстардын кереги жок) жана бул өзгөртүүлөр менен класстар этаптуу абалга түшөт.
4. Этаптуу абалдан даярдалган файлдардан тапшырма түзүлүп, Гит репозиторийине өтөт. Андан кийин, баскычтуу абал бош. Бирок өзгөртүлгөн дагы бир нерсени камтышы мүмкүн.

Бул ушундай көрүнөт (расмий documentтен алынган сүрөт, андыктан ага ишенсеңиз болот)):

Милдет деген эмне

Коммит versionны башкаруудагы негизги an object болуп саналат. Анда ошол милдеттенмеден берки бардык өзгөрүүлөр камтылган. Милдеттенмелер бири-бири менен жалгыз байланышкан тизме сыяктуу байланышкан. Тактап айтканда: Биринчи милдеттенме бар. Экинчи милдеттенме түзүлгөндө, ал (экинчи) биринчиден кийин келерин билет. Жана ушундай жол менен сиз маалыматты көзөмөлдөй аласыз. Милдеттенме ошондой эле метадайындар деп аталган өзүнүн маалыматына ээ:

• уникалдуу идентификатор, анын жардамы менен сиз аны таба аласыз;
• аны түзгөн автордун аты-жөнү;
• түзүү датасы;
• бул милдеттенме учурунда эмне жасалганын сүрөттөгөн комментарий.

Бул көрүнүш мына мындай:

бутак деген эмне

Фorал - бул милдеттенменин көрсөткүчү. Милдеттенме өзүнөн мурун кайсы милдеттенме келгенин билгендиктен, фorал милдеттенмеге ишарат кылганда, мурункулардын баары ага кайрылышат. Ушуга таянып, биз бир эле милдеттенмени көрсөткөн көптөгөн бутактар ​​болушу мүмкүн деп айта алабыз. Иш бутактарда болот, ошондуктан жаңы милдеттенме түзүлгөндө, фorал өзүнүн көрсөткүчүн жаңы милдеттенмеге жылдырат.

Git менен баштоо

Сиз жергorктүү репозиторий менен же алыскы репозиторий менен гана иштей аласыз. Керектүү буйруктарды иштеп чыгуу үчүн, сиз жергorктүү репозиторийди гана колдоно аласыз. Ал бардык маалыматты .git папкасындагы долбоордо жергorктүү түрдө гана сактайт. Алыскы жөнүндө сөз кыла турган болсок, анда бардык маалымат алыскы serverде сакталат: долбоордун көчүрмөсү гана локалдык түрдө сакталат, ага өзгөртүүлөр (git push) алыскы репозиторийге түртүлүшү мүмкүн. Бул жерде жана андан ары биз консолдо git менен иштөөнү талкуулайбыз. Албетте, сиз кээ бир графикалык чечимдерди колдоно аласыз (мисалы, Intellij IDEAда), бирок адегенде кандай буйруктар болуп жатканын жана алар эмнени билдирерин аныкташыңыз керек.

Жергorктүү репозиторийде Git менен иштөө

Андан кийин, мен сизге макаланы окуп жатканда мен кылган бардык кадамдарды жасоону сунуштайм. Бул сиздин материалды түшүнүүнү жана сактоону жакшыртат. Ошентип, аппетит :) Жергorктүү репозиторийди түзүү үчүн төмөнкүнү жазышыңыз керек:

git init

Бул консол жайгашкан жерде .git папкасын түзөт. .git бул Git репозиторийиндеги бардык маалыматты сактаган папка. Аны жок кылуунун кереги жок ;) Андан кийин файлдар бул долбоорго кошулуп, алардын статусу Көзөмөлсүз болуп калат. Учурдагы жумуш абалы кандай экенин көрүү үчүн жазыңыз:

git status

Биз кожоюн бутактабыз, башкасына өтмөйүнчө баары ошол бойдон кала берет. Ушундай жол менен сиз кайсы файлдар өзгөртүлгөнүн, бирок этаптуу абалга кошула электигин көрө аласыз. Аларды этаптуу абалга кошуу үчүн git add деп жазышыңыз керек. Бул жерде бир нече варианттар болушу мүмкүн, мисалы:

• git add -A - баскычтуу абалдан бардык файлдарды кошуу;
• git кошуу. — бул папкадагы бардык файлдарды жана бардык ички файлдарды кошуңуз. Негизинен мурункуга окшош;
• git add <файлдын аты> - белгилүү бир файлды гана кошот. Бул жерде кандайдыр бир үлгү боюнча кошуу үчүн кадимки сөз айкаштарын колдоно аласыз. Мисалы, git add *.java: бул сизге java кеңейтүүсү менен файлдарды гана кошуу керек дегенди билдирет.

Биринчи эки вариант жөнөкөй экени түшүнүктүү, бирок кошумчалоо менен ал кызыктуураак болот, ошондуктан биз жазабыз:

git add *.txt

Статусту текшерүү үчүн биз билген команданы колдонобуз:

git status

Мындан биз регулярдуу туюнтма туура иштегенин көрүүгө болот жана азыр test_resource.txt баскычтуу абалда. Акыр-аягы, акыркы этап (жергorктүү репозиторий менен, алыскы репозиторий менен дагы бирөө болот;)) - жаңы милдеттенмени тапшырыңыз жана түзүңүз:

git commit -m “all txt files were added to the project”

Андан кийин, фorалдын тарыхын карап чыгуу үчүн чоң буйрук бар. Аны колдонолу:

git log

Бул жерде сиз биздин биринчи милдеттенмебиз биз өткөрүп берген текст менен пайда болгонун көрө аласыз. Биз өткөрүп жаткан текст бул милдеттенменин жүрүшүндө эмне жасалганын мүмкүн болушунча так аныктоо керек экенин түшүнүү абдан маанилүү. Бул келечекте көп жолу жардам берет. Уктай элек, кызыккан окурман мындай деп айтышы мүмкүн: GitTest.java файлына эмне болду? Эми биз билебиз, бул үчүн колдонуңуз:

git status

Көрүнүп тургандай, ал аңдылбаган абалда калып, канатта күтүүдө. Же балким, биз аны таптакыр долбоорго кошкубуз келбейт? Ушундай да болот. Андан кийин, аны кызыктуураак кылуу үчүн, келгиле, test_resource.txt текст файлыбызды өзгөртүүгө аракет кылалы. Келгиле, ал жерге бир аз текст кошуп, статусун текшерели:

git status

Бул жерде сиз эки мамлекеттин ортосундагы айырманы так көрө аласыз - көзөмөлдөнбөгөн жана өзгөртүлгөн. GitTest.java көзөмөлдөнбөгөн абалда жана test_resource.txt өзгөртүлгөн абалда. Эми өзгөртүлгөн абалда файлдар бар болгондуктан, биз аларга киргизилген өзгөртүүлөрдү карай алабыз. Бул буйрукту колдонуу менен жасалышы мүмкүн:

git diff

Башкача айтканда, бул жерде мен биздин тексттик файлга Hello world! Текст файлына өзгөртүүлөрдү кошуп, төмөнкүлөрдү аткарыңыз:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”

Бардык милдеттенмелерди көрүү үчүн жазыңыз:

git log

Көрүнүп тургандай, буга чейин эки милдеттенме бар. Ушундай эле жол менен биз GitTest.java кошобуз. Азыр комментарийлер жок, жөн гана буйруктар:

git add GitTest.java
git commit -m “added GitTest.java”
git status

.gitignore менен иштөө

Биз репозиторийде баштапкы codeду гана сактагыбыз келгени анык. Дагы бакшка эмне болушу мүмкүн? Кеминде, компиляцияланган класстар жана/же иштеп чыгуу чөйрөлөрүн түзүүчү файлдар. Гит аларды этибарга албашы үчүн атайын файл түзүлүшү керек. Биз муну жасайбыз: .gitignore деп аталган долбоордун тамырында файлды түзөбүз жана бул файлда ар бир сап этибарга алынбаган үлгү болот. Бул мисалда, git ignore төмөнкүдөй болот:

```
*.class
target/
*.iml
.idea/
```

Эми карап көрөлү:

• биринчи сап .class кеңейтүүсү менен бардык файлдарды четке кагуу;
• экинчи сап максаттуу папканы жана анда камтылган нерселердин баарын этибарга алуу;
• үчүнчү сап .iml кеңейтүүсү менен бардык файлдарды этибарга алуу;
• Төртүнчү сап .idea папкасына көңүл бурбоо.

Келгиле, бир мисал менен аракет кылалы. Бул кантип иштээрин көрүү үчүн долбоорго түзүлгөн GitTest.class классын кошуп, долбоордун абалын көрүңүз:

git status

Албетте, биз кокусунан (эгерде git add -A колдонсок) долбоорго компиляцияланган класс кошкубуз келбейт. Бул үчүн, .gitignore файлын түзүп, мурда сүрөттөлгөндөрдүн бардыгын кошуңуз: Эми git ignoreди жаңы милдеттенме менен долбоорго кошолу:

git add .gitignore
git commit -m “added .gitignore file”

Эми чындык учуру: бизде Git репозиторийине кошууну каалаган эмес, көзөмөлдөнбөгөн абалда түзүлгөн GitTest.class классы бар. Бул жерде git ignore иштеши керек:

git status

Баары түшүнүктүү) Git ignore +1)

бутактары менен иштөө жана башкалар

Албетте, бир тармакта иштөө бирөө үчүн ыңгайсыз жана командада бир нече адам болгондо мүмкүн эмес. Бул үчүн фorал бар. Мен мурда айткандай, бутак - бул жөн гана милдеттенмелер үчүн кыймылдуу көрсөткүч. Бул бөлүктө биз ар кандай тармактарда иштөөнү карайбыз: бир бутактан экинчисине өзгөртүүнү кантип бириктирүү керек, кандай чыр-чатактар ​​келип чыгышы мүмкүн жана башкалар. Репозиторийдеги бардык фorалдардын тизмесин көрүү жана кайсынысында экениңизди түшүнүү үчүн төмөнкүнү жазышыңыз керек:

git branch -a

Көрүп турасыз, бизде бир гана башкы бутак бар, анын алдындагы жылдызча биз анын үстүндө экенибизди айтып турат. Айтмакчы, кайсы фorалда экенибизди билүү үчүн статусту текшерүүнү (git status) колдонсок болот. Андан кийин, бутактарды түзүү үчүн бир нече варианттар бар (балким дагы бар, мен буларды колдоном):

• биз иштеп жаткан фorалдын негизинде жаңы фorал түзүү (99% учурлар);
• белгилүү бир милдеттенменин негизинде фorалды түзүү (1%).

Белгилүү бир милдеттенменин негизинде фorал түзүңүз

Биз уникалдуу милдеттенме идентификаторуна таянабыз. Аны табуу үчүн, биз жазабыз:

git log

Мен "салам дүйнө кошулду..." деген комментарий менен милдеттенмени баса белгиледим. Анын уникалдуу идентификатору бар - “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Мен ушул милдеттенмеден баштап өнүгүү тармагын түзгүм келет. Бул үчүн мен жазам:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Мастер бутактан биринчи эки гана тапшырманы камтыган бутак түзүлөт. Муну текшерүү үчүн, биз адегенде башка фorалга өткөнүбүздү текшерип, андагы милдеттенмелердин санын карайбыз:

git status
git log

Бул чындык: бизде эки милдет бар экени белгилүү болду. Айтмакчы, кызыктуу жагдай: бул тармакта азырынча .gitignore файлы жок, андыктан биздин компиляцияланган файлыбыз (GitTest.class) азыр көзөмөлдөнбөгөн абалда баса белгиленет. Эми биз фorалдарыбызды кайра карап чыгабыз:

git branch -a

Көрүнүп тургандай, эки бутак бар - кожоюн жана өнүктүрүү - азыр биз өнүгүү жолундабыз.

Учурдагы фorалдын негизинде фorал түзүңүз

Бутакты түзүүнүн экинчи жолу - башканы куруу. Мен башкы бутактын негизинде фorал түзгүм келет, андыктан биринчи ага өтүшүм керек, кийинки кадам жаңысын түзүү. Кел карайбыз:

• git checkout master - башкы фorалга өтүү;
• git статусу - анын мастерде экендигин текшериңиз.

Бул жерде сиз биз мастер бутагына өткөнүбүздү көрө аласыз, git ignore бул жерде мурунтан эле иштеп жатат жана компиляцияланган класс мындан ары көзөмөлдөнбөгөн катары көрүнбөйт. Эми биз мастер бутагынын негизинде жаңы фorалды түзөбүз:

git checkout -b feature/update-txt-files

Эгерде сизде бул бутак мастердикине окшош эмес деп күмөн санасаңыз, анда git log жазып, бардык милдеттенмелерди карап, муну оңой текшере аласыз. Алардын төртөө болушу керек.

Конфликттерди чечүү

Конфликт эмне экенин түшүнүүдөн мурун, биз бир бутакты экинчи бутакка бириктирүү (бириктирүү) жөнүндө сөз кылышыбыз керек. Бул сүрөттө бир бутак экинчи бутакка кошулган процессти көрсөтө алат: Башкача айтканда, негизги бутак бар. Кайсы бир убакта андан экинчи даражадагысы түзүлөт, анда өзгөрүүлөр болот. Иш бүткөндөн кийин, бир бутакты башкасына бириктирүү керек. Мен ар кандай өзгөчөлүктөргө токтолбойм: Мен бул макаланын алкагында гана түшүнүүнү билдиргим келет жана зарыл болсо, майда-чүйдөсүнө чейин өзүңөр билесиңер. Ошентип, биздин мисалда, биз өзгөчөлүк/update-txt-файлдардын бутагын түздүк. Фorалдын атында жазылгандай, текстти жаңыртабыз. Эми бул маселе боюнча жаңы милдеттенме түзүшүңүз керек:

git add *.txt 
git commit -m “updated txt files”
git log

Эми, эгерде биз өзгөчөлүктү/update-txt-files бутагын мастерге бириктиргибиз келсе, анда биз мастерге барып, git merge feature/update-txt-files деп жазышыбыз керек:

git checkout master
git merge feature/update-txt-files
git log

Натыйжада, эми башкы фorалда функция/update-txt-файлдарына кошулган милдеттенме бар. Бул функция кошулган, ошондуктан сиз функция бутагын жок кыла аласыз. Бул үчүн биз жазабыз:

git branch -D feature/update-txt-files

Азырынча бул түшүнүктүү, туурабы? Кырдаалды татаалдаштырып көрөлү: азыр txt файлын кайра өзгөртүү керек деп айталы. Бирок азыр бул файл устада да өзгөртүлөт. Башкача айтканда, ал параллелдүү өзгөрөт жана Git жаңы codeду мастер бутагына бириктиргибиз келген кырдаалда эмне кылуу керектигин түшүнө алbyte. Go! Биз мастердин негизинде жаңы фorал түзөбүз, text_resource.txt файлына өзгөртүүлөрдү киргизебиз жана бул маселе боюнча милдеттенме түзөбүз:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

Мастер бутагына барып, бул текст файлын функция бутагы менен бир сапта жаңыртыңыз:

git checkout master
… обновor test_resource.txt

git add test_resource.txt
git commit -m “added master header to txt”

Эми эң кызыктуу учур: өзгөчөлүк/кошумча баш бутагынан мастерге өзгөртүүлөрдү бириктиришиңиз керек. Биз башкы фorалдабыз, андыктан биз эмне кылышыбыз керек экенин жазуу:

git merge feature/add-header

Бирок биз test_resource.txt файлында конфликт менен жыйынтыкка ээ болобуз: Жана бул жерден Git бул codeду кантип бириктирүүнү өз алдынча чече албаганын жана биз адегенде чыр-чатакты чечип, андан кийин гана милдеттенме алышыбыз керек экенин көрөбүз. Макул, конфликти камтыган файлды тексттик редактордо ачып көрөлү: Гит бул жерде эмне кылганын түшүнүү үчүн, биз кайда жазганыбызды эстеп, салыштыруу керек:

1. “<<<<<<< HEAD” жана “=======” ортосундагы негизги бутагы бул сапта болгон башкы өзгөртүүлөр.
2. "=======" жана ">>>>>>> өзгөчөлүк/кошуу-башчысы" ортосунда өзгөчөлүк/кошуу-башкы бөлүмүндө болгон өзгөрүүлөр бар.

Ошентип, Гит бул учурда бул файлды кантип бириктирүү керектигин түшүнө албаганын көрсөтүп, бул бөлүмдү ар кандай бутактардан эки бөлүккө бөлүп, өзүбүз чечүүнү сунуштады. Макул, күчтүү эрк менен мен баарын алып салууну чечтим, бир гана сөздүн башын калтырам: Өзгөртүүлөрдүн абалын карап көрөлү, сүрөттөмө бир аз башкача болот. Өзгөртүлгөн абал болбойт, бирок Unmerged. Ошентип, биз аман-эсен бешинчи абалды кошо алабыз ... Бирок, бул керексиз деп ойлойм, карап көрөлү:

git status

Бул башка, адаттан тыш окуя экенине ынандык. уланталы:

git add *.txt

Сүрөттөмөдө сиз алар git commit жазууну гана сунуштаарын байкайсыз. Биз угуп, жазабыз:

git commit

Ушунун баары: биз муну ушундай кылдык - консольдогу чыр-чатакты чечтик. Албетте, иштеп чыгуу чөйрөлөрүндө муну бир аз жеңorрээк кылсаңыз болот, мисалы, Intellij IDEAда баары ушунчалык жакшы орнотулган, андагы бардык керектүү аракеттерди аткара аласыз. Бирок өнүгүү чөйрөсү капчыктын астында көп нерселерди жасайт жана биз көбүнчө ал жерде эмне болгонун түшүнбөйбүз. Ал эми түшүнүү жок болгондо, көйгөйлөр жаралышы мүмкүн.

Алыскы репозиторийлер менен иштөө

Акыркы кадам - ​​алыскы репозиторий менен иштөө үчүн зарыл болгон дагы бир нече буйруктарды түшүнүү. Мен буга чейин айткандай, алыскы репозиторий - бул репозиторий сакталган жана аны клондоочу жер. Алыскы репозиторийлердин кандай түрлөрү бар? Мисалдар көп:

• GitHub репозиторийлер жана биргелешкен өнүктүрүү үчүн эң чоң репозиторий. Мен буга чейин мурунку макалаларда сүрөттөгөн. Менин Github аккаунтума
  жазылыңыз . Мен ал жакта иштеп жүргөндө окуп жүргөн багыттарым боюнча көп эмгектеримди көргөзмөгө коём.

• GitLab бул ачык булактуу веб- негизделген DevOps өмүр циклинин инструменти , Git үчүн өзүнүн викиси, көйгөйлөрдү көзөмөлдөө системасы , CI/CD түтүктөрү жана башка өзгөчөлүктөрү менен code репозиторийлерин башкаруу тутумун камсыз кылат . Майкрософт GitHub сатып алганы тууралуу кабардан кийин, кээ бир иштеп чыгуучулар GitLabдагы иштерин кайталашты.
  

• BitBucket – бул Mercurial жана Git versionсын башкаруу системасынын негизинде хостинг долбоорлору жана аларды биргелешип иштеп чыгуу үчүн веб-сервис. Бир убакта анын GitHubга караганда чоң артыкчылыгы бар болчу, анткени анын акысыз жеке репозиторийлери болгон. Өткөн жылы GitHub да бул функцияны бардыгына бекер жеткorктүү кылган.

• Жана башка…

Алыскы репозиторий менен иштөөдө эң биринчи нерсе - бул долбоорду жергorктүү проектиге клондоо. Бул үчүн мен жергorктүү деңгээлде жасаган долбоорду экспорттодум, эми аны ар ким өзү үчүн клондой алат:

git clone https://github.com/romankh3/git-demo

Азыр жер-жерлерде долбоордун толук көчүрмөсү бар. Долбоордун акыркы көчүрмөсү жергorктүү жерде экенине ынануу үчүн, алар айткандай, маалыматтарды жазуу менен ташташыңыз керек:

git pull

Биздин учурда, азыр алыстан эч нерсе өзгөргөн жок, андыктан жооп: Буга чейин эле актуалдуу. Бирок мен алыскы репозиторийге кандайдыр бир өзгөртүүлөрдү киргизсем, биз аларды тарткандан кийин жергorктүү жаңыртылып калат. Акыр-аягы, акыркы буйрук алыскы репозиторийге маалыматтарды түртүп жатат. Биз локалдык түрдө бир нерсе жасап, аны алыскы репозиторийге өткөргүбүз келгенде, адегенде жергorктүү жаңы милдеттенме түзүшүбүз керек. Бул үчүн, келгиле, текст файлыбызга дагы бир нерсени кошолу: Эми бул биз үчүн кадимки нерсе - биз бул маселе боюнча милдеттенме түзөбүз:

git add test_resource.txt
git commit -m “prepated txt for pushing”

Эми муну алыскы репозиторийге түртүү буйругу:

git push

Менин сага айткым келгени ушул эле. Конул бурганын учун рахмат. Менин GitHub аккаунтума жазылыңыз , анда мен окуган жана жумушта колдонгон ар кандай сонун мисал долбоорлорун жарыялайм.

пайдалуу шилтемелер

• Гит боюнча расмий document орус тorнде . Мен аны маалымдама катары сунуштайм.
• Git