Pagsisimula sa Git: isang detalyadong gabay para sa mga nagsisimula

Sa halip na isang pagpapakilala

Kumusta sa hinaharap na Senior Software Engineer. Ngayon ay pag-uusapan natin ang tungkol sa version control system, katulad ng Git (basahin bilang GIT, at hindi JIT, na tila mula sa English grammar). Oo, oo, alam ko na mayroon ding Mercurial, SVN... Ngunit maging tapat tayo: ang kanilang oras ay lumipas na, at hindi ko sasayangin ang iyong mahalagang oras sa kanila. Upang maunawaan mo ang kahalagahan ng pag-alam sa Git sa ating panahon, sasabihin ko ito: nang walang kaalaman/pagkaunawa dito, wala kang magagawa sa programming. Ngunit ang kagandahan ay upang gumana nang tuluy-tuloy hindi mo kailangang panatilihin ang lahat ng mga utos at mga posibilidad sa iyong ulo. Kailangan mong malaman ang isang hanay ng mga utos na tutulong sa iyo na maunawaan ang lahat ng nangyayari.

Mga Pangunahing Kaalaman sa Git

Ang Git ay isang distributed version control system para sa aming code. Bakit kailangan natin ito? Ang mga naipamahagi na koponan ay nangangailangan ng ilang uri ng sistema ng pamamahala sa trabaho. Kailangang subaybayan ang mga pagbabagong nagaganap sa paglipas ng panahon. Iyon ay, hakbang-hakbang na nakikita natin kung aling mga file ang nagbago at kung paano. Ito ay lalong mahalaga kapag sinusuri mo kung ano ang ginawa sa loob ng isang gawain: ginagawa nitong posible na bumalik. Isipin natin ang isang sitwasyon: mayroong isang gumaganang code, lahat ay mabuti sa loob nito, ngunit nagpasya kaming pagbutihin ang isang bagay, sabunutan ito dito, sabunutan doon. Maayos ang lahat, ngunit sinira ng pagpapahusay na ito ang kalahati ng pag-andar at naging imposibleng gumana. Kaya, ano ang susunod? Kung wala ang Gita, ang isa ay kailangang umupo nang maraming oras at alalahanin kung paano ang lahat ay orihinal. At kaya bumalik na lang kami sa commit at iyon na. O paano kung mayroong dalawang developer na gumagawa ng kanilang mga pagbabago sa code sa parehong oras? Kung wala ang Git, ganito ang hitsura: kinopya nila ang code mula sa orihinal at ginawa ang kailangan nilang gawin. Dumating ang sandali at parehong gustong idagdag ang kanilang mga pagbabago sa pangunahing folder. At ano ang gagawin sa sitwasyong ito?.. Ni hindi ako nangahas na tantyahin ang oras para gawin ang gawaing ito. Hindi magkakaroon ng ganoong mga problema kung gagamit ka ng Git.

Pag-install ng Git

I-install natin ang Git sa iyong computer. Naiintindihan ko na ang lahat ay may iba't ibang OS, kaya susubukan kong ilarawan para sa ilang mga kaso.

Pag-install para sa Windows

Gaya ng dati, kailangan mong i-download ang exe file at patakbuhin ito. Ang lahat ay simple dito: mag-click sa unang link ng Google , i-install at iyon na. Para sa trabaho gagamitin namin ang bash console na ibinibigay nila. Upang gumana sa Windows, kailangan mong patakbuhin ang Git Bash. Ganito ang hitsura sa start menu: At isa na itong console kung saan maaari kang magtrabaho. Upang hindi pumunta sa folder na may proyekto sa bawat oras na buksan ang git doon, maaari kang mag-right-click sa folder upang buksan ang console gamit ang landas na kailangan namin:

Pag-install para sa Linux

Karaniwang naka-install na ang git at kasama sa mga distribusyon ng Linux, dahil ito ay isang tool na orihinal na isinulat para sa pagbuo ng Linux kernel. Ngunit may mga sitwasyon na wala ito. Upang suriin ito, kailangan mong buksan ang isang terminal at i-type ang: git --version. Kung may malinaw na sagot, hindi na kailangang mag-install ng anuman. Buksan ang isang terminal at i-install. Nagtatrabaho ako sa Ubuntu, para masabi ko sa iyo kung ano ang isusulat para dito: sudo apt-get install git. At iyon lang: maaari mo na ngayong gamitin ang Git sa anumang terminal.

Pag-install sa macOS

Dito rin, kailangan mo munang suriin kung mayroon nang Git (tingnan sa itaas, tulad ng sa Linux). Kung hindi, ang pinakamadaling paraan ay ang pag-download ng pinakabagong bersyon. Kung naka-install ang XCode, tiyak na awtomatikong mai-install ang Git.

Pag-setup ng Git

Ang git ay may setting ng user kung saan isasagawa ang gawain. Ito ay isang makatwiran at kinakailangang bagay, dahil kapag ang isang commit ay ginawa, ang Git ay eksaktong kukuha ng impormasyong ito para sa field ng May-akda. Upang mag-set up ng username at password para sa lahat ng proyekto, kailangan mong ipasok ang mga sumusunod na command:

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

Kung kailangang baguhin ang may-akda para sa isang partikular na proyekto (para sa isang personal na proyekto, halimbawa), maaari mong alisin ang --global, at gagana ito:

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

Isang maliit na teorya...

Upang manatili sa paksa, ipinapayong magdagdag ng ilang mga bagong salita at aksyon sa iyong mensahe... Kung hindi, walang pag-uusapan. Siyempre, ito ay ilang jargon at isang kopya ng Ingles, kaya magdagdag ako ng mga kahulugan sa Ingles. Anong mga salita at kilos?

• git repository;
• mangako (commit);
• sangay;
• pagsamahin;
• mga salungatan;
• hilahin;
• itulak;
• kung paano huwag pansinin ang ilang mga file (.gitignore).

At iba pa.

Estado sa Git

Ang Gita ay may ilang mga estado na kailangang maunawaan at tandaan:

• hindi sinusubaybayan;
• binago;
• inihanda (itinatanghal);
• nakatuon.

Ano ang ibig sabihin nito?

Ito ang mga estado kung saan matatagpuan ang mga file mula sa aming code. Iyon ay, ang kanilang landas sa buhay ay karaniwang ganito:

1. Ang isang file na ginawa at hindi idinagdag sa repository ay nasa hindi nasusubaybayang estado.
2. Gumagawa kami ng mga pagbabago sa mga file na naidagdag na sa Git repository - ang mga ito ay nasa binagong estado.
3. Mula sa mga file na binago namin, pipiliin lang namin ang mga (o lahat) na kailangan namin (halimbawa, hindi namin kailangan ang mga pinagsama-samang klase), at ang mga klase na ito na may mga pagbabago ay nahuhulog sa itinanghal na estado.
4. Ang isang commit ay nilikha mula sa mga inihandang file mula sa itinanghal na estado at napupunta sa Git repository. Pagkatapos nito, walang laman ang itinanghal na estado. Ngunit ang binago ay maaaring naglalaman pa rin ng isang bagay.

Mukhang ganito (larawan mula sa opisyal na dokumento, para mapagkakatiwalaan mo ito)):

Ano ang commit

Ang commit ay ang pangunahing object sa version control. Naglalaman ito ng lahat ng mga pagbabago mula noong commit na iyon. Ang mga commit ay naka-link sa isa't isa tulad ng isang solong naka-link na listahan. Namely: May unang commit. Kapag nalikha ang pangalawang commit, alam nito (ang pangalawa) na darating ito pagkatapos ng una. At sa ganitong paraan masusubaybayan mo ang impormasyon. Ang commit ay mayroon ding sariling impormasyon, tinatawag na metadata:

• isang natatanging commit identifier kung saan mo ito mahahanap;
• ang pangalan ng commit author na lumikha nito;
• gumawa ng petsa ng paglikha;
• isang komento na naglalarawan kung ano ang ginawa sa panahon ng commit na ito.

Ito ang hitsura nito:

Ano ang sangay

Ang branch ay isang pointer sa isang commit. Dahil alam ng isang commit kung aling commit ang nauna rito, kapag ang isang sangay ay tumuturo sa isang commit, lahat ng mga nauna ay tumutukoy din dito. Batay dito, maaari nating sabihin na maaaring mayroong maraming sangay na tumuturo sa parehong commit. Ang trabaho ay nangyayari sa mga branch, kaya kapag ang isang bagong commit ay ginawa, ang branch ay naglilipat ng pointer nito sa mas bagong commit.

Pagsisimula sa Git

Maaari ka lamang magtrabaho sa isang lokal na imbakan, o sa isang malayuan. Upang maisagawa ang mga kinakailangang utos, maaari mo lamang gamitin ang lokal na imbakan. Iniimbak nito ang lahat ng impormasyon nang lokal lamang sa proyekto sa .git na folder. Kung pinag-uusapan natin ang tungkol sa remote, kung gayon ang lahat ng impormasyon ay naka-imbak sa isang lugar sa isang malayong server: isang kopya lamang ng proyekto ang naka-imbak nang lokal, mga pagbabago kung saan maaaring itulak (git push) sa remote na imbakan. Dito at higit pa ay tatalakayin natin ang pagtatrabaho sa git sa console. Siyempre, maaari kang gumamit ng ilang mga graphical na solusyon (halimbawa, sa Intellij IDEA), ngunit kailangan mo munang malaman kung anong mga utos ang nangyayari at kung ano ang ibig sabihin ng mga ito.

Nagtatrabaho sa Git sa isang lokal na imbakan

Susunod, iminumungkahi kong sundin mo ang lahat ng mga hakbang na ginawa ko habang binabasa mo ang artikulo. Mapapabuti nito ang iyong pag-unawa at pagpapanatili ng materyal. So bon appetit :) Upang lumikha ng isang lokal na imbakan, kailangan mong isulat:

git init

Gagawa ito ng .git na folder sa lokasyon kung saan matatagpuan ang console. Ang .git ay isang folder na nag-iimbak ng lahat ng impormasyon tungkol sa Git repository. Hindi na kailangang tanggalin ito ;) Susunod, ang mga file ay idaragdag sa proyektong ito, at ang kanilang katayuan ay magiging Untracked. Upang makita kung ano ang kasalukuyang katayuan sa trabaho, isulat ang:

git status

Kami ay nasa master branch, at hanggang sa lumipat kami sa isa pa, ang lahat ay mananatiling ganoon. Sa ganitong paraan makikita mo kung aling mga file ang nabago ngunit hindi pa naidagdag sa naka-stage na estado. Upang idagdag ang mga ito sa itinanghal na estado, kailangan mong isulat ang git add. Maaaring mayroong ilang mga opsyon dito, halimbawa:

• git add -A - idagdag ang lahat ng mga file mula sa itinanghal na estado;
• git add . — idagdag ang lahat ng mga file mula sa folder na ito at lahat ng mga panloob. Mahalagang kapareho ng nauna;
• git add <filename> - nagdaragdag lamang ng isang partikular na file. Dito maaari kang gumamit ng mga regular na expression upang magdagdag ayon sa ilang pattern. Halimbawa, git add *.java: nangangahulugan ito na kailangan mo lamang magdagdag ng mga file na may extension ng java.

Malinaw na ang unang dalawang pagpipilian ay simple, ngunit sa karagdagan ito ay magiging mas kawili-wili, kaya sumulat kami:

git add *.txt

Upang suriin ang katayuan, ginagamit namin ang utos na alam na namin:

git status

Mula dito makikita natin na gumana nang tama ang regular na expression, at ngayon ay nasa staged na estado ang test_resource.txt. At sa wakas, ang huling yugto (na may isang lokal na imbakan, na may isang malayo ay magkakaroon ng isa pa ;)) - gumawa at lumikha ng isang bagong pangako:

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

Susunod, mayroong isang mahusay na utos upang tingnan ang kasaysayan ng commit ng isang sangay. Gamitin natin ito:

git log

Dito mo na makikita na ang aming unang commit ay lumabas kasama ng text na aming inilipat. Napakahalagang maunawaan na ang tekstong ipapasa natin ay dapat tukuyin nang tumpak hangga't maaari kung ano ang ginawa sa panahon ng commit na ito. Makakatulong ito ng maraming beses sa hinaharap. Maaaring sabihin ng matanong na mambabasa na hindi pa natutulog: ano ang nangyari sa GitTest.java file? Ngayon malalaman natin, gamitin para dito:

git status

Tulad ng nakikita natin, nananatili ito sa hindi nasubaybayan na estado at naghihintay sa mga pakpak. O baka ayaw nating idagdag ito sa proyekto? Nangyayari minsan. Susunod, upang gawin itong mas kawili-wili, subukan nating baguhin ang aming text file na test_resource.txt. Magdagdag tayo ng ilang teksto doon at suriin ang katayuan:

git status

Dito mo malinaw na makikita ang pagkakaiba sa pagitan ng dalawang estado - hindi sinusubaybayan at binago. Ang GitTest.java ay nasa untracked state at ang test_resource.txt ay nasa modified state. Ngayon na mayroon nang mga file sa binagong estado, maaari nating tingnan ang mga pagbabagong ginawa sa kanila. Magagawa ito gamit ang command:

git diff

Ibig sabihin, kitang-kita mo dito na nagdagdag ako ng hello world! sa aming text file. Magdagdag ng mga pagbabago sa text file at mag-commit:

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

Upang tingnan ang lahat ng commit, isulat ang:

git log

Tulad ng nakikita mo, mayroon nang dalawang commit. Sa parehong paraan, idinaragdag namin ang GitTest.java. Ngayon walang mga komento, utos lamang:

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

Nagtatrabaho sa .gitignore

Malinaw na gusto lang naming iimbak ang source code at wala nang iba pa sa repositoryo. Ano pa kaya ito? Sa pinakamababa, pinagsama-samang mga klase at/o mga file na lumilikha ng mga kapaligiran sa pag-unlad. Upang hindi sila pansinin ng Git, mayroong isang espesyal na file na kailangang gawin. Ginagawa namin ito: lumikha kami ng isang file sa ugat ng proyekto na tinatawag na .gitignore, at sa file na ito, ang bawat linya ay magiging isang pattern na balewalain. Sa halimbawang ito, ang git ignore ay magiging ganito:

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

Tingnan natin ngayon:

• ang unang linya ay huwag pansinin ang lahat ng mga file na may extension na .class;
• ang pangalawang linya ay huwag pansinin ang target na folder at lahat ng nilalaman nito;
• ang ikatlong linya ay huwag pansinin ang lahat ng mga file na may extension na .iml;
• Ang ikaapat na linya ay huwag pansinin ang .idea folder.

Subukan natin ito sa isang halimbawa. Upang makita kung paano ito gumagana, idagdag natin ang pinagsama-samang klase ng GitTest.class sa proyekto at tingnan ang katayuan ng proyekto:

git status

Malinaw, hindi namin nais na aksidenteng (kung gumagamit kami ng git add -A) magdagdag ng isang pinagsama-samang klase sa proyekto. Upang gawin ito, gumawa ng .gitignore file at idagdag ang lahat ng inilarawan kanina: Ngayon, idagdag natin ang git ignore sa proyekto na may bagong commit:

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

At ngayon ang sandali ng katotohanan: mayroon kaming pinagsama-samang klase ng GitTest.class sa isang hindi sinusubaybayang estado, na hindi namin gustong idagdag sa Git repository. Dito dapat gumana ang git ignore:

git status

Malinaw ang lahat) Git huwag pansinin ang +1)

Nagtatrabaho sa mga sangay at iba pa

Siyempre, ang pagtatrabaho sa isang sangay ay hindi maginhawa para sa isa at imposible kapag mayroong higit sa isang tao sa koponan. May sangay para dito. Tulad ng sinabi ko dati, ang isang sangay ay isang gumagalaw na pointer para mag-commit. Sa bahaging ito, titingnan natin ang pagtatrabaho sa iba't ibang sangay: kung paano pagsamahin ang mga pagbabago mula sa isang sangay patungo sa isa pa, kung anong mga salungatan ang maaaring lumitaw, at marami pa. Upang makita ang isang listahan ng lahat ng mga sangay sa repositoryo at maunawaan kung alin ka, kailangan mong isulat:

git branch -a

Maaari mong makita na mayroon lamang kaming isang master branch, at ang asterisk sa harap nito ay nagsasabi na kami ay nasa ito. Sa pamamagitan ng paraan, upang malaman kung saang branch tayo naroroon, maaari rin nating gamitin ang pagsusuri sa status (git status). Susunod, mayroong maraming mga pagpipilian para sa paglikha ng mga sangay (marahil marami pa, ginagamit ko ang mga ito):

• lumikha ng isang bagong sangay batay sa kung saan kami ay nasa (99% ng mga kaso);
• lumikha ng isang sangay batay sa isang tiyak na pangako (1%).

Gumawa ng branch batay sa isang partikular na commit

Aasa kami sa natatanging commit identifier. Upang mahanap ito, sumulat kami:

git log

Na-highlight ko ang commit sa komentong "nagdagdag ng hello world...". Mayroon itong natatanging identifier - "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". Gusto kong gumawa ng development branch simula sa commit na ito. Para dito, isusulat ko:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Ang isang sangay ay nilikha na naglalaman lamang ng unang dalawang commit mula sa master branch. Para subukan ito, sisiguraduhin muna naming lumipat kami sa ibang branch at titingnan ang bilang ng mga commit dito:

git status
git log

At totoo: dalawa pala ang commit namin. Siyanga pala, isang kawili-wiling punto: wala pang .gitignore na file sa sangay na ito, kaya ang aming pinagsama-samang file (GitTest.class) ay naka-highlight na ngayon sa hindi sinusubaybayang estado. Ngayon ay maaari nating baguhin muli ang ating mga sangay sa pamamagitan ng pagsulat:

git branch -a

Makikita na mayroong dalawang sangay - master at development - at ngayon tayo ay nasa pag-unlad.

Lumikha ng isang sangay batay sa kasalukuyang isa

Ang pangalawang paraan upang lumikha ng isang sangay ay ang magtayo sa isa pa. Gusto kong gumawa ng branch batay sa master branch, kaya kailangan ko munang lumipat dito, at ang susunod na hakbang ay gumawa ng bago. Tingnan natin:

• git checkout master - lumipat sa master branch;
• git status - suriin kung ito ay nasa master.

Dito makikita mo na lumipat na kami sa master branch, gumagana na rito ang git ignore, at ang pinagsama-samang klase ay hindi na lilitaw bilang untracked. Ngayon lumikha kami ng bagong sangay batay sa master branch:

git checkout -b feature/update-txt-files

Kung mayroon kang anumang mga pagdududa na ang sangay na ito ay hindi magiging katulad ng master, maaari mong madaling suriin ito sa pamamagitan ng pagsulat ng git log at pagtingin sa lahat ng mga commit. Dapat silang apat.

Lutasin ang mga salungatan

Bago natin maunawaan kung ano ang isang salungatan, kailangan nating pag-usapan ang tungkol sa pagsasanib (pagsasama) ng isang sangay sa isa pa. Maaaring ipakita ng larawang ito ang proseso kapag ang isang sangay ay pinagsama sa isa pa: Ibig sabihin, mayroong isang pangunahing sangay. Sa ilang mga punto, ang pangalawang isa ay nilikha mula dito, kung saan nangyayari ang mga pagbabago. Kapag tapos na ang trabaho, kailangan mong pagsamahin ang isang sangay sa isa pa. Hindi ko ilalarawan ang iba't ibang mga tampok: Nais kong ihatid lamang ang pag-unawa sa loob ng balangkas ng artikulong ito, at malalaman mo mismo ang mga detalye kung kinakailangan. Kaya, sa aming halimbawa, ginawa namin ang feature/update-txt-files branch. Tulad ng nakasulat sa pangalan ng sangay, ia-update namin ang teksto. Ngayon ay kailangan mong gumawa ng bagong commit para sa bagay na ito:

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

Ngayon, kung gusto nating pagsamahin ang feature/update-txt-files branch sa master, kailangan nating pumunta sa master at isulat ang git merge feature/update-txt-files:

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

Bilang resulta, ngayon ang master branch ay mayroon ding commit na idinagdag sa feature/update-txt-files. Idinagdag ang functionality na ito para ma-delete mo ang feature branch. Upang gawin ito sumulat kami:

git branch -D feature/update-txt-files

Sa ngayon ay malinaw, tama ba? Pasimplehin natin ang sitwasyon: ngayon sabihin natin na kailangan nating baguhin muli ang txt file. Ngunit ngayon ang file na ito ay babaguhin din sa wizard. Iyon ay, magbabago ito nang magkatulad, at hindi mauunawaan ng Git kung ano ang kailangang gawin sa isang sitwasyon kung kailan gusto nating pagsamahin ang bagong code sa master branch. Go! Gumagawa kami ng bagong sangay batay sa master, gumawa ng mga pagbabago sa text_resource.txt at gumawa ng commit para sa bagay na ito:

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

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

Pumunta sa master branch at i-update din ang text file na ito sa parehong linya ng feature branch:

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

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

At ngayon ang pinakakawili-wiling sandali: kailangan mong pagsamahin ang mga pagbabago mula sa feature/add-header na sangay patungo sa master. Kami ay nasa master branch, kaya ang kailangan lang naming gawin ay magsulat:

git merge feature/add-header

Ngunit makakakuha tayo ng resulta na may salungatan sa test_resource.txt file: At dito makikita natin na ang Git ay hindi nakapag-iisa na makapagpasya kung paano pagsamahin ang code na ito at sinasabi na kailangan muna nating lutasin ang salungatan, at pagkatapos ay gumawa ng commit. Ok, buksan natin ang file na naglalaman ng conflict sa isang text editor at tingnan ang: Upang maunawaan kung ano ang ginawa ni git dito, kailangan mong tandaan kung ano ang isinulat namin kung saan at ihambing:

1. sa pagitan ng "<<<<<<<< HEAD" at "=======" ay ang mga pangunahing pagbabago na nasa linyang ito sa master branch.
2. sa pagitan ng “=======” at “>>>>>>> feature/add-header” ay may mga pagbabago sa feature/add-header branch.

Kaya, ipinakita ni Git na sa puntong ito ay hindi niya maisip kung paano pagsamahin ang file na ito, hinati ang seksyong ito sa dalawang bahagi mula sa iba't ibang sangay at iminungkahi na magpasya kami para sa aming sarili. Okay, with a strong will I decide to remove everything, leave only the word header: Let's look at the status of the changes, the description will be slightly different. Walang mababagong estado, ngunit Hindi Pinagsama. Kaya maaari tayong ligtas na magdagdag ng ikalimang estado... Ngunit sa tingin ko ito ay hindi kailangan, tingnan natin:

git status

Kami ay kumbinsido na ito ay isang kakaiba, hindi pangkaraniwang kaso. Ituloy natin:

git add *.txt

Sa paglalarawan mapapansin mo na iminumungkahi lamang nila ang pagsulat ng git commit. Nakikinig kami at nagsusulat:

git commit

At iyon lang: ganito ang ginawa namin - naresolba namin ang conflict sa console. Siyempre, sa mga kapaligiran ng pag-unlad, maaari mong gawin ito nang mas madali, halimbawa, sa Intellij IDEA, ang lahat ay naka-set up nang maayos upang maisagawa mo ang lahat ng kinakailangang aksyon dito. Ngunit ang kapaligiran ng pag-unlad ay gumagawa ng maraming bagay sa ilalim ng hood, at madalas ay hindi natin naiintindihan kung ano ang eksaktong nangyari doon. At kapag walang pag-unawa, pagkatapos ay maaaring lumitaw ang mga problema.

Nagtatrabaho sa mga malalayong imbakan

Ang huling hakbang ay upang maunawaan ang ilang higit pang mga utos na kinakailangan upang gumana sa isang malayuang imbakan. Tulad ng nasabi ko na, ang isang malayong imbakan ay isang lugar kung saan ang imbakan ay nakaimbak at mula sa kung saan maaari mong i-clone ito. Anong mga uri ng malalayong imbakan ang naroon? Mayroong maraming mga halimbawa:

• Ang GitHub ay ang pinakamalaking repositoryo para sa mga repositoryo at collaborative development. Inilarawan ko na ito sa mga nakaraang artikulo.
  Mag-subscribe sa aking Github account . Madalas kong i-exhibit ang aking trabaho doon sa mga lugar na pinag-aaralan ko sa aking trabaho.

• Ang GitLab ay isang open source na web- based na DevOps lifecycle tool na nagbibigay ng code repository management system para sa Git na may sarili nitong wiki, issue tracking system , CI/CD pipeline at iba pang feature. Matapos ang balita na binili ng Microsoft ang GitHub, nadoble ng ilang developer ang kanilang trabaho sa GitLab.
  

• Ang BitBucket ay isang web service para sa pagho-host ng mga proyekto at ang kanilang pinagsamang pag-unlad, batay sa Mercurial at Git version control system. Sa isang pagkakataon nagkaroon ito ng malaking kalamangan sa GitHub dahil mayroon itong mga libreng pribadong repositoryo. Noong nakaraang taon, ginawa rin ng GitHub na available ang feature na ito sa lahat nang libre.

• At iba pa…

Ang unang bagay na kailangan mong gawin kapag nagtatrabaho sa isang malayuang imbakan ay ang pag-clone ng proyekto sa iyong lokal. Para sa kasong ito, na-export ko ang proyekto na ginawa namin nang lokal, at ngayon ay ma-clone ito ng lahat para sa kanilang sarili sa pamamagitan ng pagsulat:

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

Ngayon ay mayroong isang kumpletong kopya ng proyekto sa lokal. Upang matiyak na ang pinakabagong kopya ng proyekto ay matatagpuan sa lokal, kailangan mong, tulad ng sinasabi nila, itapon ang data sa pamamagitan ng pagsulat:

git pull

Sa aming kaso, walang nagbago sa malayo ngayon, kaya ang sagot ay: Napapanahon na. Ngunit kung gumawa ako ng ilang mga pagbabago sa malayong imbakan, ang lokal ay maa-update pagkatapos naming hilahin ang mga ito. At sa wakas, ang huling utos ay itulak ang data sa malayong imbakan. Kapag nakagawa kami ng isang bagay nang lokal at gusto naming ilipat ito sa isang malayong imbakan, kailangan muna naming gumawa ng bagong commit nang lokal. Upang gawin ito, magdagdag tayo ng iba pa sa aming text file: Ngayon ito ay isang pangkaraniwang bagay para sa amin - gumawa kami ng isang pangako para sa bagay na ito:

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

At ngayon ang utos na itulak ito sa malayong imbakan:

git push

Yun lang ang gusto kong sabihin sayo. Salamat sa iyong atensyon. Mag-subscribe sa aking GitHub account , kung saan nag-post ako ng iba't ibang magagandang halimbawang proyekto mula sa kung ano ang aking pinag-aaralan at ginagamit sa trabaho.

kapaki-pakinabang na mga link

• Ang opisyal na dokumento sa Git ay nasa Russian . Inirerekomenda ko ito bilang gabay sa sanggunian.
• Git