Mga sistema ng kontrol sa bersyon

"Hi, Amigo!"

"Hi!"

"Ngayon sasabihin ko sa iyo ang tungkol sa mga version control system."

"Tulad ng malamang na alam mo na, ang mga programa ay madalas na napakalaki at tumatagal ng napakatagal na oras upang magsulat. Minsan dose-dosenang mga tao ang maaaring gumugol ng mga taon sa pagsulat ng isang programa."

"Ang mga proyektong may milyun-milyong linya ng code ay isang katotohanan."

"Whoa."

"Napakakomplikado ng lahat. Madalas na nakikialam ang mga tao sa isa't isa, at madalas na binabago ang parehong code, at iba pa at iba pa."

"Upang ayusin ang gulo na ito, nagsimulang gumamit ang mga programmer ng mga version control system para sa kanilang code."

" Ang version control system ay isang program na binubuo ng isang client at server.

"Ang programa ay nag-iimbak ng data (ang code na isinulat ng mga programmer) sa isang server, at ang mga programmer ay nagdaragdag o nagbabago nito gamit ang mga kliyente."

"Ang pangunahing pagkakaiba sa pagitan ng isang version control system at mga program na ginagawang posible na magtrabaho nang magkakasama sa mga dokumento ay ang pag-iimbak nito ng lahat ng nakaraang bersyon ng lahat ng mga dokumento (mga file ng code)."

"Maaari mo ba akong bigyan ng higit pang mga detalye. Paano gumagana ang lahat ng ito?"

"Isipin na ikaw ay isang programmer at gusto mong gumawa ng maliliit na pagbabago sa source code ng isang program na nakaimbak sa isang repositoryo sa server."

"Narito ang kailangan mong gawin:"

"1) Mag-log in sa server."

"2) Kopyahin ang pinakabagong bersyon ng lahat ng mga file sa iyong computer gamit ang Checkout command."

"3) Gumawa ng mga pagbabago sa mga kinakailangang file."

"4) Patakbuhin ang programa nang lokal upang matiyak na ito ay nag-compile at tumatakbo."

"5) Ipadala ang iyong 'mga pagbabago' sa server gamit ang Commit command."

"Sa pangkalahatan ay may katuturan iyon."

"Ngunit mayroon pa. Isipin na dumating ka sa trabaho sa umaga, ngunit ito ay oras na ng tanghalian sa India. Kaya ang iyong mga kasamahan sa India ay gumawa na ng mga pagbabago at ginawa ang kanilang mga pagbabago sa iyong repositoryo sa server."

"Kailangan mong gamitin ang pinakabagong bersyon ng code. Kaya gawin mo ang Update command."

"Paano iyon naiiba sa Checkout ?"

" Ang Checkout ay idinisenyo upang kopyahin ang lahat ng mga file ng repositoryo, ngunit ina-update lamang ng Update ang mga file na na-update sa server mula noong huli kang nagpatakbo ng isang Checkout / Update command."

"Ito ay tinatayang kung paano ito gumagana:"

Checkout :

"Ngayon, sabihin nating binago namin ang file B at gusto naming i-upload ito sa server. Para magawa ito, kailangan naming gamitin ang command na Commit ."

"At narito kung paano gumagana ang Update command:"

"How interesting! May iba pa bang utos?"

"Oo, medyo marami. Pero iba-iba sila depende sa kung anong version control program ang pipiliin mo. So, I'm trying to explain the general principles."

"Mayroon ding operasyon na tinatawag na merging—ang pagsasama-sama ng dalawang dokumento. Ipagpalagay na dalawang programmer ay binago ang parehong file sa parehong oras. Pagkatapos ay hindi papayagan ng program sa server na gawin ang parehong mga pagbabago. Kung sino ang unang gumawa ay makakapagdagdag ng kanyang o ang kanyang mga pagbabago."

"So ano ang ginagawa ng ibang tao?"

"Iimbitahan siya na magsagawa ng isang Update operation upang makuha ang pinakabagong mga pagbabago mula sa server. Siya nga pala, ito — paggawa ng Update bago gumawa - ay mabuting kasanayan."

"Pagkatapos, sa panahon ng pagpapatakbo ng Update, susubukan ng client program na pagsamahin ang mga lokal na pagbabago sa mga pagbabagong natanggap mula sa server."

"Kung binago ng mga programmer ang iba't ibang bahagi ng file, malamang na matagumpay na maipagsama ng programmer ang bersyon ng control.  Kung ang mga pagbabago ay nasa parehong lugar, mag-uulat ang program ng version control ng pagsasanib ng pagsasanib at ipo-prompt ang user na manu-mano. pagsamahin ang mga pagbabago."

"Halimbawa, madalas itong nangyayari kapag ang parehong programmer ay nagdagdag ng isang bagay sa dulo ng isang file."

"I see. Overall, parang reasonable naman."

"At may isa pa: mga sanga."

"Isipin na ang dalawang programmer mula sa isang koponan ay may tungkuling muling isulat ang parehong module. O mas mabuti pa — muling isulat ito mula sa simula. Hanggang sa makumpleto ang module na ito, ang program ay hindi gagana, at maaaring hindi man lang mag-compile."

"So ano ang dapat nilang gawin?"

"Sumusulong sila sa pamamagitan ng pagdaragdag ng mga sangay sa repositoryo. Sa madaling salita, ang ibig sabihin nito ay nahahati ang repositoryo sa dalawang bahagi. Hindi sa pamamagitan ng mga file o direktoryo, ngunit ayon sa mga bersyon."

"Isipin na ang koryente ay hindi kailanman natuklasan at ang mga robot ay hindi kailanman naimbento. Kung gayon ang tatlong digmaan sa pagpapalaya ay hindi kailanman mangyayari, at ang lahat ng kasaysayan ng tao ay sumunod sa isang ganap na naiibang landas. "

"Ang landas na ito ay isang alternatibong sangay ng kasaysayan."

"O maaari mo lamang subukang ilarawan ang isang sangay bilang isang kopya lamang ng imbakan. Sa madaling salita, sa isang punto, gumawa kami ng isang clone ng imbakan sa server, upang, bilang karagdagan sa pangunahing imbakan ( madalas na tinatawag na trunk ), may isa pa tayong branch ."

"Well, mukhang mas naiintindihan iyon.

"Bakit hindi mo na lang sabihin na kinopya namin ang repository?"

"Hindi ito simpleng pagkopya."

"Ang mga sanga na ito ay hindi lamang maaaring ihiwalay mula sa puno ng kahoy, ngunit pinagsama din dito."

"Sa madaling salita, ang ilang trabaho ay maaaring gawin sa isang sangay, at pagkatapos ay kapag natapos na ito maaari mong idagdag ang sangay ng imbakan sa puno ng imbakan?"

"Oo."

"At ano ang mangyayari sa mga file?"

"Isasama ang mga file."

"Well, that sounds cool. Sana ganoon din ka-cool sa action."

"And then some. Okay, let's take a break."

"May isang grupo ng mga kapaki-pakinabang na impormasyon  dito "