1. Isang detalyadong gabay sa Git para sa mga nagsisimula

Ngayon ay pag-uusapan natin ang tungkol sa isang version control system, ang Git.

Talagang hindi ka maaaring maging isang ganap na programmer nang hindi nalalaman at nauunawaan ang tool na ito. Siyempre, hindi mo kailangang panatilihin ang lahat ng mga utos at feature ng Git sa iyong ulo upang patuloy na magamit. Kailangan mong malaman ang isang hanay ng mga utos na makakatulong sa iyong 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 koponan ay nangangailangan ng ilang uri ng sistema para sa pamamahala ng kanilang trabaho. Ito ay kinakailangan upang subaybayan ang mga pagbabago na nagaganap sa paglipas ng panahon.

Ibig sabihin, kailangan nating makita ang step-by-step kung aling mga file ang nagbago at kung paano. Ito ay lalong mahalaga kapag sinisiyasat mo kung ano ang nagbago sa konteksto ng isang gawain, na ginagawang posible na ibalik ang mga pagbabago.

Isipin natin ang sumusunod na sitwasyon: mayroon kaming gumaganang code, lahat ng nasa loob nito ay mabuti, ngunit pagkatapos ay nagpasya kaming pagbutihin o i-tweak ang isang bagay. Walang malaking bagay, ngunit sinira ng aming "pagpapabuti" ang kalahati ng mga tampok ng programa at naging imposibleng gumana. Kaya ngayon ano? Kung wala ang Git, kailangan mong umupo at mag-isip nang maraming oras, sinusubukang alalahanin kung paano ang lahat ay orihinal. Ngunit sa Git, ibabalik lang namin ang commit — at iyon na.

O paano kung may dalawang developer na gumagawa ng sarili nilang mga pagbabago sa code nang sabay? Kung walang Git, kinokopya nila ang orihinal na mga file ng code at binago ang mga ito nang hiwalay. Darating ang panahon na pareho nilang gustong idagdag ang kanilang mga pagbabago sa pangunahing direktoryo. Ano ang gagawin mo sa kasong ito?

Walang ganoong mga problema kung gagamit ka ng Git.

Pag-install ng Git

I-install natin ang Java sa iyong computer Ang prosesong ito ay bahagyang naiiba para sa iba't ibang mga operating system.

Pag-install sa Windows

Gaya ng dati, kailangan mong mag-download at magpatakbo ng isang exe file. Ang lahat ay simple dito: mag-click sa unang link ng Google , isagawa ang pag-install, at iyon na. Upang gawin ito, gagamitin namin ang bash console na ibinigay ng Windows.

Sa Windows, kailangan mong patakbuhin ang Git Bash. Ganito ang hitsura nito sa Start Menu:

Ngayon ito ay isang command prompt na maaari mong gamitin.

Upang maiwasan ang pagpunta sa folder na may proyekto sa bawat oras upang mag-order upang buksan ang Git doon, maaari mong buksan ang command prompt sa folder ng proyekto gamit ang kanang pindutan ng mouse na may landas na kailangan namin:

Pag-install sa Linux

Karaniwan ang Git ay bahagi ng mga pamamahagi ng Linux at naka-install na, dahil ito ay isang tool na orihinal na isinulat para sa pagbuo ng kernel ng Linux. Ngunit may mga sitwasyon na hindi. Upang suriin, kailangan mong buksan ang isang terminal at isulat ang: git --version. Kung makakakuha ka ng isang maliwanag na sagot, pagkatapos ay walang kailangang i-install.

Buksan ang isang terminal at i-install. Para sa Ubuntu, kailangan mong isulat ang: sudo apt-get install git. At iyon lang: ngayon ay maaari mong gamitin ang Git sa anumang terminal.

Pag-install sa macOS

Dito rin, kailangan mo munang suriin kung naroon na ang Git (tingnan sa itaas, katulad ng sa Linux).

Kung wala ka nito, ang pinakamadaling paraan para makuha ito ay ang pag-download ng pinakabagong bersyon . Kung naka-install ang Xcode, tiyak na awtomatikong mai-install ang Git.

Mga setting ng Git

Ang Git ay may mga setting ng user para sa user na magsusumite ng trabaho. Makatuwiran ito at kinakailangan, dahil kinukuha ng Git ang impormasyong ito para sa field ng May-akda kapag may ginawang commit.

Mag-set up ng username at password para sa lahat ng iyong proyekto sa pamamagitan ng pagpapatakbo ng mga sumusunod na command:

Kung kailangan mong baguhin ang may-akda para sa isang partikular na proyekto (para sa isang personal na proyekto, halimbawa), maaari mong alisin ang "--global". Bibigyan tayo nito ng sumusunod:

Medyo teorya

Upang sumisid sa paksa, dapat naming ipakilala sa iyo ang ilang mga bagong salita at aksyon... Kung hindi, walang pag-uusapan. Siyempre, ito ay jargon na nanggagaling sa amin mula sa English, kaya magdadagdag ako ng mga pagsasalin sa loob ng panaklong.

Anong mga salita at kilos?

• git repository
• mangako
• sangay
• pagsamahin
• mga salungatan
• hilahin
• itulak
• paano balewalain ang ilang file (.gitignore)

At iba pa.

Mga katayuan sa Git

Ang Git ay may ilang mga estatwa na kailangang maunawaan at tandaan:

• hindi sinusubaybayan
• binago
• itinanghal
• nakatuon

Paano mo dapat maunawaan ito?

Ito ang mga status na nalalapat sa mga file na naglalaman ng aming code. Sa madaling salita, ang kanilang ikot ng buhay ay karaniwang ganito:

• Ang isang file na nilikha ngunit hindi pa naidagdag sa imbakan ay may katayuang "hindi nasubaybayan".
• Kapag gumawa kami ng mga pagbabago sa mga file na naidagdag na sa Git repository, ang kanilang status ay "binago".
• Kabilang sa mga file na binago namin, pipiliin namin ang mga kailangan namin (halimbawa, hindi namin kailangan ang mga pinagsama-samang klase), at ang mga klase na ito ay binago sa katayuang "itinatanghal".
• Ang isang commit ay ginawa mula sa mga inihandang file sa naka-stage na estado at napupunta sa Git repository. Pagkatapos nito, walang mga file na may "staged" status. Ngunit maaaring may mga file pa rin na ang status ay "nabago".

Ganito ang hitsura nito:

Ano ang commit?

Ang commit ay ang pangunahing kaganapan pagdating sa kontrol ng bersyon. Naglalaman ito ng lahat ng pagbabagong ginawa mula noong nagsimula ang commit. Ang mga commit ay naka-link nang magkasama tulad ng isang solong naka-link na listahan.

Sa partikular, mayroong unang commit. Kapag nalikha ang pangalawang commit, alam nito (ang pangalawa) kung ano ang darating pagkatapos ng una. At sa ganitong paraan, masusubaybayan ang impormasyon.

Ang isang commit ay mayroon ding sariling impormasyon, tinatawag na metadata:

• ang natatanging identifier ng commit, na maaaring magamit upang mahanap ito
• ang pangalan ng may-akda ng commit, na lumikha nito
• ang petsa kung kailan ginawa ang commit
• isang komento na naglalarawan kung ano ang ginawa sa panahon ng commit

Narito ang hitsura nito:

Ano ang isang sangay?

Ang isang sangay ay isang pointer sa ilang commit. Dahil alam ng isang commit kung aling commit ang nauuna dito, kapag ang isang branch ay tumuturo sa isang commit, lahat ng mga nakaraang commit ay nalalapat din dito.

Alinsunod dito, maaari naming sabihin na maaari kang magkaroon ng maraming sangay hangga't gusto mo na tumuturo sa parehong commit.

Ang trabaho ay nangyayari sa mga sangay, kaya kapag ang isang bagong commit ay ginawa, ang sangay ay naglilipat ng pointer nito sa mas kamakailang commit.

Pagsisimula sa Git

Maaari kang magtrabaho sa isang lokal na imbakan nang nag-iisa pati na rin sa isang malayuan.

Upang maisagawa ang mga kinakailangang utos, maaari mong limitahan ang iyong sarili sa lokal na imbakan. Iniimbak lamang nito ang lahat ng impormasyon ng proyekto nang lokal sa .git na folder.

Kung pinag-uusapan natin ang malayong imbakan, ang lahat ng impormasyon ay naka-imbak sa isang lugar sa malayong server: isang kopya lamang ng proyekto ang naka-imbak nang lokal. Ang mga pagbabagong ginawa sa iyong lokal na kopya ay maaaring itulak (git push) sa malayong imbakan.

Sa aming talakayan dito at sa ibaba, pinag-uusapan natin ang tungkol sa pagtatrabaho sa Git sa console. Siyempre, maaari kang gumamit ng isang uri ng solusyon na nakabatay sa GUI (halimbawa, IntelliJ IDEA), ngunit dapat mo munang malaman kung anong mga utos ang isinasagawa at kung ano ang ibig sabihin ng mga ito.

Nagtatrabaho sa Git sa isang lokal na imbakan

Upang lumikha ng isang lokal na imbakan, kailangan mong isulat:

Gagawa ito ng nakatagong .git na folder sa kasalukuyang direktoryo ng console.

Ang .git na folder ay nag-iimbak ng lahat ng impormasyon tungkol sa Git repository. Wag mong tanggalin ;)

Susunod, idinaragdag ang mga file sa proyekto, at itinalaga ang mga ito sa katayuang "Hindi Nasubaybayan." Upang suriin ang kasalukuyang katayuan ng iyong trabaho, isulat ito:

Nasa master branch kami, at dito kami mananatili hanggang lumipat kami sa ibang branch.

Ipinapakita nito kung aling mga file ang nagbago ngunit hindi pa naidagdag sa katayuang "itinatanghal." Upang idagdag ang mga ito sa "staged" na katayuan, kailangan mong isulat ang "git add". Mayroon kaming ilang mga pagpipilian dito, halimbawa:

• git add -A - idagdag ang lahat ng mga file sa "itinanghal" na katayuan
• git add . — idagdag ang lahat ng mga file mula sa folder na ito at lahat ng mga subfolder. Mahalagang kapareho ng nauna;
• git add <file name> — nagdaragdag ng isang partikular na file. Dito maaari kang gumamit ng mga regular na expression upang magdagdag ng mga file ayon sa ilang pattern. Halimbawa, git add *.java: Nangangahulugan ito na gusto mo lang magdagdag ng mga file na may extension ng java.

Ang unang dalawang pagpipilian ay malinaw na simple. Ang mga bagay ay nagiging mas kawili-wili sa pinakabagong karagdagan, kaya't sumulat tayo:

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

Dito makikita mo na gumana nang tama ang regular na expression: ang test_resource.txt ay mayroon na ngayong "staged" status.

At sa wakas, ang huling yugto para sa pagtatrabaho sa isang lokal na imbakan (mayroong isa pa kapag nagtatrabaho sa malayong imbakan ;)) — paglikha ng isang bagong commit:

Ang susunod ay isang mahusay na utos para sa pagtingin sa kasaysayan ng commit sa isang sangay. Gamitin natin ito:

Dito makikita mo na ginawa namin ang aming unang commit at kasama dito ang text na ibinigay namin sa command line. Napakahalagang maunawaan na ang tekstong ito ay dapat na ipaliwanag nang tumpak hangga't maaari kung ano ang ginawa sa panahon ng commit na ito. Makakatulong ito sa atin ng maraming beses sa hinaharap.

Ang isang matanong na mambabasa na hindi pa natutulog ay maaaring nagtataka kung ano ang nangyari sa GitTest.java file. Alamin natin ngayon din. Upang gawin ito, ginagamit namin ang:

Tulad ng makikita mo, ito ay "untracked" pa rin at naghihintay sa mga pakpak. Ngunit paano kung hindi namin nais na idagdag ito sa proyekto sa lahat? Minsan nangyayari yan.

Upang gawing mas kawili-wili ang mga bagay, subukan natin ngayon na baguhin ang aming test_resource.txt file. Magdagdag tayo ng ilang teksto doon at suriin ang katayuan:

Dito mo malinaw na makikita ang pagkakaiba sa pagitan ng mga "untracked" at "modified" status.

Ang GitTest.java ay "untracked", habang ang test_resource.txt ay "modified".

Ngayon na mayroon kaming mga file sa binagong estado, maaari naming suriin ang mga pagbabagong ginawa sa kanila. Magagawa ito gamit ang sumusunod na command:

Ibig sabihin, malinaw mong makikita dito kung ano ang idinagdag ko sa aming text file: hello world!

Idagdag natin ang ating mga pagbabago sa text file at gumawa ng commit:

Upang tingnan ang lahat ng commit, isulat ang:

Tulad ng nakikita mo, mayroon na tayong dalawang pangako.

Magdaragdag kami ng GitTest.java sa parehong paraan. Walang komento dito, utos lang:

Nagtatrabaho sa .gitignore

Maliwanag, gusto lang naming panatilihing nag-iisa ang source code, at wala nang iba pa, sa repositoryo. Kaya ano pa ang maaaring mayroon? Sa pinakamababa, pinagsama-samang mga klase at/o mga file na nabuo ng mga kapaligiran sa pag-unlad.

Upang sabihin sa Git na huwag pansinin ang mga ito, kailangan nating lumikha ng isang espesyal na file. Gawin ito: gumawa ng file na tinatawag na .gitignore sa ugat ng proyekto. Ang bawat linya sa file na ito ay kumakatawan sa isang pattern na huwag pansinin.

Sa halimbawang ito, magiging ganito ang hitsura ng .gitignore file:

Tignan natin:

• 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 nating gumamit ng isang halimbawa. Upang makita kung paano ito gumagana, idagdag natin ang pinagsama-samang GitTest.class sa proyekto at suriin ang katayuan ng proyekto:

Maliwanag, hindi namin nais na kahit papaano ay hindi sinasadyang idagdag ang pinagsama-samang klase sa proyekto (gamit ang git add -A). Upang gawin ito, lumikha ng .gitignore na file at idagdag ang lahat ng inilarawan kanina:

Ngayon, gumamit tayo ng commit upang idagdag ang .gitignore file sa proyekto:

At ngayon ang sandali ng katotohanan: mayroon kaming isang pinagsama-samang klase na GitTest.class na "hindi sinusubaybayan", na hindi namin gustong idagdag sa Git repository.

Ngayon ay dapat nating makita ang mga epekto ng .gitignore file:

Perpekto! .gitignore +1 :)

Nagtatrabaho sa mga sangay

Naturally, ang pagtatrabaho sa isang sangay lamang ay hindi maginhawa para sa mga nag-iisa na developer, at ito ay imposible kapag mayroong higit sa isang tao sa isang koponan. Ito ang dahilan kung bakit mayroon kaming mga sangay.

Ang isang branch ay isang movable pointer lamang para mag-commit.

Sa bahaging ito, tutuklasin 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 pang iba.

Upang makita ang isang listahan ng lahat ng mga sangay sa repositoryo at maunawaan kung alin ka, kailangan mong isulat:

Makikita mo na isa lang ang master branch namin. Ang asterisk sa harap nito ay nagpapahiwatig na tayo ay nasa loob nito. Sa pamamagitan ng paraan, maaari mo ring gamitin ang "git status" na utos upang malaman kung saang sangay tayo naroroon.

Pagkatapos ay mayroong ilang mga opsyon para sa paglikha ng mga sangay (maaaring marami pa — ito ang mga ginagamit ko):

• lumikha ng bagong sangay batay sa kung saan tayo nasa (99% ng mga kaso)
• lumikha ng isang sangay batay sa isang partikular na pangako (1% ng mga kaso)

Gumawa tayo ng branch batay sa isang partikular na commit

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

Na-highlight namin ang commit sa komentong "nagdagdag ng hello world..." Ang natatanging identifier nito ay 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Gusto naming gumawa ng "development" na sangay na magsisimula sa commit na ito. Upang gawin ito, sumulat kami:

Ang isang sangay ay nilikha na ang unang dalawang commit lamang mula sa master branch. Para i-verify ito, siguraduhin muna naming lumipat sa ibang branch at tingnan ang bilang ng mga commit doon:

And as expected, dalawa ang commit namin. Siyanga pala, narito ang 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 na may "untracked" status.

Ngayon ay maaari nating suriin muli ang ating mga sangay sa pamamagitan ng pagsulat nito:

Makikita mo na mayroong dalawang sangay: "master" at "development". Kasalukuyan kaming nasa development.

Gumawa tayo ng isang sangay batay sa kasalukuyang isa

Ang pangalawang paraan upang lumikha ng isang sangay ay ang paglikha nito mula sa isa pa. Nais naming lumikha ng isang sangay batay sa master branch. Una, kailangan nating lumipat dito, at ang susunod na hakbang ay lumikha ng bago. Tignan natin:

• git checkout master - lumipat sa master branch
• git status — i-verify na nasa master branch talaga kami

Dito makikita mo na lumipat kami sa master branch, ang .gitignore file ay may bisa, at ang compiled class ay hindi na naka-highlight bilang "untracked".

Ngayon lumikha kami ng bagong sangay batay sa master branch:

Kung hindi ka sigurado kung ang sangay na ito ay kapareho ng "master", madali mong masuri sa pamamagitan ng pagsasagawa ng "git log" at pagtingin sa lahat ng mga commit. Dapat silang apat.

Pag-ayos ng gulo

Bago natin tuklasin kung ano ang isang salungatan, kailangan nating pag-usapan ang tungkol sa pagsasama ng isang sangay sa isa pa.

Inilalarawan ng larawang ito ang proseso ng pagsasama ng isang sangay sa isa pa:

Dito, mayroon kaming pangunahing sangay. Sa ilang mga punto, ang isang pangalawang sangay ay nilikha mula sa pangunahing sangay at pagkatapos ay binago. Kapag tapos na ang gawain, kailangan nating pagsamahin ang isang sangay sa isa pa.

Sa aming halimbawa, ginawa namin ang feature/update-txt-files branch. Gaya ng ipinahiwatig ng pangalan ng sangay, nag-a-update kami ng text.

Ngayon ay kailangan nating gumawa ng bagong commit para sa gawaing ito:

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":

Bilang resulta, kasama na ngayon ng master branch ang commit na idinagdag sa feature/update-txt-files.

Idinagdag ang functionality na ito, para ma-delete mo ang isang feature branch. Upang gawin ito, sumulat kami:

Palubhain natin ang sitwasyon: ngayon sabihin natin na kailangan mong baguhin muli ang txt file. Ngunit ngayon ang file na ito ay babaguhin din sa master branch. Sa madaling salita, magbabago ito nang magkatulad. Hindi malalaman ng Git kung ano ang gagawin kapag gusto naming pagsamahin ang aming bagong code sa master branch.

Gagawa kami ng bagong branch batay sa master, gagawa ng mga pagbabago sa text_resource.txt, at gagawa ng commit para sa gawaing ito:

... gumawa kami ng mga pagbabago sa file

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

… na-update namin ang test_resource.txt

At ngayon ang pinakakawili-wiling punto: kailangan nating pagsamahin ang mga pagbabago mula sa feature/add-header na sangay patungo sa master. Nasa master branch kami, kaya kailangan lang naming isulat:

Ngunit ang resulta ay magiging salungatan sa test_resource.txt file:

Dito makikita natin na hindi makapagpasya ang Git sa sarili nitong paraan kung paano pagsamahin ang code na ito. Sinasabi nito sa amin na kailangan muna nating lutasin ang hindi pagkakasundo, at pagkatapos lamang gawin ang pangako.

OK. Binuksan namin ang file na may salungatan sa isang text editor at nakita namin:

Upang maunawaan kung ano ang ginawa ni Git dito, kailangan nating tandaan kung aling mga pagbabago ang ginawa natin at kung saan, at pagkatapos ay ihambing:

1. Ang mga pagbabago na nasa linyang ito sa master branch ay matatagpuan sa pagitan ng "<<<<<<<< HEAD" at "=======".
2. Ang mga pagbabagong nasa feature/add-header branch ay makikita sa pagitan ng "=======" at ">>>>>>> feature/add-header".

Ito ay kung paano sinasabi sa amin ng Git na hindi nito maisip kung paano isasagawa ang pagsasanib sa lokasyong ito sa file. Hinati nito ang seksyong ito sa dalawang bahagi mula sa iba't ibang sangay at iniimbitahan kaming lutasin ang pagsasanib sa aming sarili.

Sapat na. Matapang akong nagpasya na alisin ang lahat, na iniiwan lamang ang salitang "header":

Tingnan natin ang katayuan ng mga pagbabago. Ang paglalarawan ay bahagyang naiiba. Sa halip na isang "binagong" status, mayroon kaming "unmerged". Kaya't maaari bang nabanggit natin ang ikalimang katayuan? Sa tingin ko ay hindi ito kailangan. Tingnan natin:

Maaari nating kumbinsihin ang ating sarili na ito ay isang espesyal, hindi pangkaraniwang kaso. Ituloy natin:

Maaari mong mapansin na ang paglalarawan ay nagmumungkahi ng pagsulat lamang ng "git commit". Subukan nating isulat iyon:

At ganoon din, ginawa namin ito — nalutas namin ang salungatan sa console.

Siyempre, maaari itong gawin nang mas madali sa pinagsamang mga kapaligiran sa pag-unlad. Halimbawa, sa IntelliJ IDEA, ang lahat ay naka-set up nang maayos upang maisagawa mo ang lahat ng kinakailangang aksyon sa loob mismo nito. Ngunit ang mga IDE ay gumagawa ng maraming bagay "sa ilalim ng talukbong", at madalas ay hindi natin naiintindihan kung ano ang eksaktong nangyayari doon. At kapag walang pag-unawa, maaaring lumitaw ang mga problema.

Nagtatrabaho sa mga malalayong imbakan

Ang huling hakbang ay upang malaman ang ilang higit pang mga utos na kinakailangan upang gumana sa malayong repositoryo.

Tulad ng sinabi ko, ang isang malayong imbakan ay isang lugar kung saan nakaimbak ang imbakan at kung saan maaari mong i-clone ito.

Anong uri ng mga malalayong imbakan ang naroroon? Mga halimbawa:

• Ang GitHub ay ang pinakamalaking storage platform para sa mga repositoryo at collaborative development.
• Ang GitLab ay isang web-based na tool para sa DevOps lifecycle na may open source. Ito ay isang Git-based system para sa pamamahala ng mga code repository na may sarili nitong wiki, bug tracking system, CI/CD pipeline, at iba pang function.
• Ang BitBucket ay isang web service para sa pagho-host ng proyekto at collaborative development batay sa Mercurial at Git version control system. Sa isang pagkakataon nagkaroon ito ng malaking kalamangan sa GitHub dahil nag-aalok ito ng mga libreng pribadong repositoryo. Noong nakaraang taon, ipinakilala din ng GitHub ang kakayahang ito sa lahat nang libre.
• At iba pa…

Kapag nagtatrabaho sa isang malayuang imbakan, ang unang bagay na dapat gawin ay i-clone ang proyekto sa iyong lokal na imbakan.

Para dito, na-export namin ang proyektong ginawa namin nang lokal Ngayon ay ma-clone ito ng lahat para sa kanilang sarili sa pamamagitan ng pagsulat:

Mayroon na ngayong kumpletong lokal na kopya ng proyekto. Upang matiyak na ang lokal na kopya ng proyekto ay ang pinakabago, kailangan mong hilahin ang proyekto sa pamamagitan ng pagsulat:

Sa aming kaso, walang nagbago sa malayong repositoryo sa kasalukuyan, kaya ang tugon ay: Napapanahon na.

Ngunit kung gumawa kami ng anumang mga pagbabago sa remote na imbakan, ang lokal ay ina-update pagkatapos naming hilahin ang mga ito.

At sa wakas, ang huling utos ay itulak ang data sa malayong imbakan. Kapag gumawa kami ng isang bagay sa lokal at nais na ipadala ito sa malayong imbakan, kailangan muna naming lumikha ng bagong commit nang lokal. Upang ipakita ito, magdagdag tayo ng iba pa sa ating text file:

Ngayon isang bagay na medyo karaniwan para sa amin - lumikha kami ng isang pangako para sa gawaing ito:

Ang utos upang itulak ito sa malayong imbakan ay:

Yun lang muna!

2. Paano magtrabaho kasama ang Git sa IntelliJ IDEA

Sa bahaging ito, matututunan mo kung paano magtrabaho sa Git sa IntelliJ IDEA.

Mga kinakailangang input:

1. Basahin, sundan, at unawain ang naunang bahagi. Makakatulong ito na matiyak na ang lahat ay naka-set up at handa na.
2. I-install ang IntelliJ IDEA. Dapat maayos ang lahat dito :)
3. Maglaan ng isang oras upang makamit ang kumpletong karunungan.

Gawin natin ang demo project na ginamit ko para sa artikulo tungkol sa Git.

I-clone ang proyekto nang lokal

Mayroong dalawang mga pagpipilian dito:

1. Kung mayroon ka nang isang GitHub account at nais mong itulak ang isang bagay sa ibang pagkakataon, mas mainam na i-fork ang proyekto at i-clone ang iyong sariling kopya. Maaari mong basahin ang tungkol sa kung paano lumikha ng isang tinidor sa isa pang artikulo sa ilalim ng pamagat Isang halimbawa ng daloy ng trabaho sa pag-fork .
2. I-clone ang repositoryo at gawin ang lahat nang lokal nang walang kakayahang itulak ang buong bagay sa server.

Upang mai-clone ang isang proyekto mula sa GitHub, kailangan mong kopyahin ang link ng proyekto at ipasa ito sa IntelliJ IDEA:

1. Kopyahin ang address ng proyekto:

2. Buksan ang IntelliJ IDEA at piliin ang "Kumuha mula sa Kontrol ng Bersyon":

3. Kopyahin at i-paste ang address ng proyekto:

4. Ipo-prompt kang lumikha ng proyekto ng IntelliJ IDEA. Tanggapin ang alok:

5. Dahil walang build system, pipiliin namin ang "Gumawa ng proyekto mula sa mga kasalukuyang pinagmumulan":

6. Susunod na makikita mo ang magandang screen na ito:

Ngayon na naisip namin ang pag-clone, maaari mong tingnan ang paligid.

Unang sulyap sa IntelliJ IDEA bilang isang Git UI

Tingnang mabuti ang na-clone na proyekto: maaari ka nang makakuha ng maraming impormasyon tungkol sa version control system.

Una, mayroon kaming Control pane ng Bersyon sa ibabang kaliwang sulok. Dito mahahanap mo ang lahat ng lokal na pagbabago at makakuha ng listahan ng mga commit (katulad ng "git log").

Lumipat tayo sa isang talakayan ng Log. Mayroong tiyak na visualization na tumutulong sa amin na maunawaan nang eksakto kung paano natuloy ang pag-unlad. Halimbawa, makikita mo na may ginawang bagong branch na may idinagdag na header sa txt commit, na pagkatapos ay pinagsama sa master branch. Kung nag-click ka sa isang commit, makikita mo sa kanang sulok ang lahat ng impormasyon tungkol sa commit: lahat ng mga pagbabago at metadata nito.

Bukod dito, makikita mo ang mga aktwal na pagbabago. Nakikita rin natin na naresolba ang isang salungatan doon. Inilalahad din ito ng IDEA nang napakahusay.

Kung nag-double click ka sa file na binago sa panahon ng commit na ito, makikita natin kung paano nalutas ang salungatan:

Tandaan namin na sa kaliwa at kanan mayroon kaming dalawang bersyon ng parehong file na kailangang pagsamahin sa isa. At sa gitna, mayroon kaming huling pinagsamang resulta.

Kapag ang isang proyekto ay maraming branch, commit, at user, kailangan mong maghanap nang hiwalay ayon sa branch, user, at petsa:

Bago magsimula, kapaki-pakinabang din na ipaliwanag kung paano maunawaan kung saang sangay tayo naroroon.

Sa kanang sulok sa ibaba, mayroong isang button na may label na "Git: master". Anuman ang sumusunod sa "Git:" ay ang kasalukuyang sangay. Kung iki-click mo ang pindutan, maaari kang gumawa ng maraming kapaki-pakinabang na bagay: lumipat sa isa pang sangay, lumikha ng bago, palitan ang pangalan ng isang umiiral na, at iba pa.

Nagtatrabaho sa isang imbakan

Mga kapaki-pakinabang na hotkey

Para sa trabaho sa hinaharap, kailangan mong tandaan ang ilang napaka-kapaki-pakinabang na mga hotkey:

1. CTRL+T — Kunin ang pinakabagong mga pagbabago mula sa malayuang imbakan (git pull).
2. CTRL+K — Gumawa ng commit / tingnan ang lahat ng kasalukuyang pagbabago. Kabilang dito ang parehong hindi sinusubaybayan at binagong mga file (git commit).
3. CTRL+SHIFT+K — Ito ang utos para sa pagtulak ng mga pagbabago sa remote repository. Ang lahat ng mga commit na nilikha nang lokal at wala pa sa remote na imbakan ay itulak (git push).
4. ALT+CTRL+Z — Nagbabago ang rollback sa isang partikular na file sa estado ng huling commit na ginawa sa lokal na repositoryo. Kung pipiliin mo ang buong proyekto sa kaliwang sulok sa itaas, maaari mong ibalik ang mga pagbabago sa lahat ng file.

Ano ang gusto natin?

Upang magawa ang trabaho, kailangan nating makabisado ang isang pangunahing senaryo na ginagamit sa lahat ng dako.

Ang layunin ay upang ipatupad ang bagong pag-andar sa isang hiwalay na sangay at pagkatapos ay itulak ito sa isang malayong imbakan (pagkatapos ay kailangan mo ring lumikha ng isang kahilingan sa paghila sa pangunahing sangay, ngunit iyon ay lampas sa saklaw ng araling ito).

Ano ang kinakailangan upang gawin ito?

1. Kunin ang lahat ng kasalukuyang pagbabago sa pangunahing sangay (halimbawa, "master").

2. Mula sa pangunahing sangay na ito, lumikha ng isang hiwalay na sangay para sa iyong trabaho.

3. Ipatupad ang bagong functionality.

4. Pumunta sa pangunahing sangay at tingnan kung may mga bagong pagbabago habang kami ay nagtatrabaho. Kung hindi, kung gayon ang lahat ay maayos. Ngunit kung may mga pagbabago, gagawin namin ang sumusunod: pumunta sa nagtatrabaho na sangay at i-rebase ang mga pagbabago mula sa pangunahing sangay patungo sa atin. Kung maayos ang lahat, mahusay. Ngunit lubos na posible na magkaroon ng mga salungatan. Habang nangyayari ito, maaari lamang silang malutas nang maaga, nang hindi nag-aaksaya ng oras sa malayong imbakan.

   Nagtataka ka ba kung bakit kailangan mong gawin ito? Mabuting asal ito at pinipigilan ang mga salungatan na mangyari pagkatapos na itulak ang iyong sangay sa lokal na imbakan (mayroong, siyempre, isang posibilidad na magaganap pa rin ang mga salungatan, ngunit ito ay nagiging mas maliit ).

5. Itulak ang iyong mga pagbabago sa malayong repositoryo.

Paano makakuha ng mga pagbabago mula sa malayong server?

Nagdagdag kami ng paglalarawan sa README na may bagong commit at gusto naming makuha ang mga pagbabagong ito. Kung ang mga pagbabago ay ginawa pareho sa lokal na repositoryo at sa malayong isa, pagkatapos ay iniimbitahan kaming pumili sa pagitan ng isang merge at isang rebase. Pinipili nating pagsamahin.

Ipasok ang CTRL+T :

Makikita mo na ngayon kung paano nagbago ang README, ibig sabihin, ang mga pagbabago mula sa remote na imbakan ay nakuha, at sa kanang sulok sa ibaba makikita mo ang lahat ng mga detalye ng mga pagbabago na nagmula sa server.

Gumawa ng bagong sangay batay sa master

Simple lang ang lahat dito.

Pumunta sa kanang sulok sa ibaba at i-click ang Git: master . Piliin ang + Bagong Sangay .

Iwanan ang checkbox ng Checkout branch na napili at ilagay ang pangalan ng bagong branch. Sa aming kaso: ito ay magiging readme-improver .

Git: ang master ay magbabago sa Git: readme-improver .

Gayahin natin ang parallel work

Para lumitaw ang mga salungatan, kailangang may gumawa sa kanila.

Ie-edit namin ang README na may bagong commit sa pamamagitan ng browser, kaya ginagaya ang parallel work. Para bang may gumawa ng mga pagbabago sa parehong file habang ginagawa namin ito. Magiging conflict ang resulta. Aalisin namin ang salitang "fully" mula sa linya 10.

Ipatupad ang aming functionality

Ang aming gawain ay baguhin ang README at magdagdag ng paglalarawan sa bagong artikulo. Iyon ay, ang gawain sa Git ay dumadaan sa IntelliJ IDEA. Idagdag ito:

Tapos na ang mga pagbabago. Ngayon ay maaari na tayong gumawa ng commit. Pindutin ang CTRL+K , na nagbibigay sa amin ng:

Bago gumawa ng commit, kailangan nating tingnang mabuti kung ano ang inaalok ng window na ito.

Sa seksyong Commit Message , nagsusulat kami ng text na nauugnay sa commit. Pagkatapos, para magawa ito, kailangan nating i-click ang Commit .

Isinulat namin na ang README ay nagbago at lumikha ng commit. May lalabas na alerto sa ibabang kaliwang sulok na may pangalan ng commit:

Suriin kung ang pangunahing sangay ay nagbago

Natapos namin ang aming gawain. Gumagana siya. Nagsulat kami ng mga pagsubok. Maayos ang lahat. Ngunit bago itulak sa server, kailangan pa rin nating suriin kung mayroong anumang mga pagbabago sa pangunahing sangay sa ngayon. Paano nangyari iyon? Medyo madali: may nakatanggap ng gawain pagkatapos mo, at may nakatapos nito nang mas mabilis kaysa sa natapos mo ang iyong gawain.

Kaya kailangan nating pumunta sa master branch. Upang gawin ito, kailangan nating gawin ang ipinapakita sa kanang sulok sa ibaba sa screenshot sa ibaba:

Sa master branch, pindutin ang CTRL+T para makuha ang mga pinakabagong pagbabago nito mula sa remote server. Sa pagtingin sa kung ano ang mga pagbabago, madali mong makita kung ano ang nangyari:

Ang salitang "fully" ay inalis. Marahil ay nagpasya ang isang tao mula sa marketing na hindi ito dapat isulat ng ganoon at binigyan ang mga developer ng isang gawain upang i-update ito.

Mayroon na kaming lokal na kopya ng pinakabagong bersyon ng master branch. Bumalik sa readme-improver .

Ngayon ay kailangan nating i-rebase ang mga pagbabago mula sa master branch patungo sa atin. Ginagawa namin ito:

Kung ginawa mo ang lahat ng tama at sumunod sa akin, ang resulta ay dapat magpakita ng isang salungatan sa README file:

Dito ay marami rin tayong mga impormasyon na dapat maunawaan at ibabad. Ipinapakita dito ang isang listahan ng mga file (sa aming kaso, isang file) na may mga salungatan. Maaari tayong pumili sa tatlong opsyon:

1. tanggapin ang sa iyo — tanggapin lamang ang mga pagbabago mula sa readme-improver.
2. tanggapin ang sa kanila - tanggapin lamang ang mga pagbabago mula sa master.
3. pagsamahin — piliin ang iyong sarili kung ano ang gusto mong panatilihin at kung ano ang itatapon.

Hindi malinaw kung ano ang nagbago. Kung may mga pagbabago ay ang master branch, kailangan sila doon, kaya hindi natin basta-basta tanggapin ang ating mga pagbabago. Alinsunod dito, pipiliin namin ang pagsamahin :

Dito makikita natin na mayroong tatlong bahagi:

1. Ito ang mga pagbabago mula sa readme-improver.
2. Ang pinagsamang resulta. Sa ngayon, ito ang umiiral bago ang mga pagbabago.
3. Ang mga pagbabago mula sa master branch.

Kailangan nating gumawa ng pinagsama-samang resulta na magbibigay-kasiyahan sa lahat. Nire-review kung ano ang binago BAGO ang aming mga pagbabago, napagtanto namin na inalis lang nila ang salitang "fully". Okay walang problema! Nangangahulugan iyon na aalisin din namin ito sa pinagsamang resulta at pagkatapos ay idagdag ang aming mga pagbabago. Kapag naitama na namin ang pinagsamang resulta, maaari naming i-click ang Ilapat .

Pagkatapos ay may lalabas na notification, na nagsasabi sa amin na matagumpay ang rebase:

Ayan! Nalutas namin ang aming unang salungatan sa pamamagitan ng IntelliJ IDEA.

Itulak ang mga pagbabago sa malayong server

Ang susunod na hakbang ay itulak ang mga pagbabago sa remote server at gumawa ng pull request. Upang gawin ito, pindutin lamang ang CTRL+SHIFT+K . Pagkatapos makuha namin:

Sa kaliwa, magkakaroon ng listahan ng mga commit na hindi pa nai-push sa remote na imbakan. Sa kanan ay makikita ang lahat ng mga file na nagbago. At ayun na nga! Pindutin ang Push at mararanasan mo ang kaligayahan :)

Kung matagumpay ang push, makakakita ka ng notification na tulad nito sa kanang sulok sa ibaba:

Bonus: paggawa ng pull request

Pumunta tayo sa isang repositoryo ng GitHub at nakita natin na alam na ng GitHub kung ano ang gusto natin:

I-click ang Ihambing at hilahin ang kahilingan . Pagkatapos ay i-click ang Lumikha ng pull request . Dahil naresolba namin ang mga salungatan nang maaga, ngayon kapag gumagawa ng kahilingan sa paghila, maaari na namin itong i-merge kaagad:

Yun lang muna!