Git ვერსიის მართვის სისტემა. SmartGit- ის მაგალითისთვის, მაგალითად, Git ვერსიის მართვის სისტემის საფუძვლები

პროექტზე მუშაობის დროს, მისი მონაწილეები ხშირად ხვდებიან სინქრონიზაციისა და ფაილების ისტორიასთან დაკავშირებულ პრობლემებს, რომელთა ვერსიის მართვის სისტემები (SUMS) დახმარებას უწევს გადაჭრას. სტატიების ამ სერიის მიზანია მკითხველს გაეცნოს SUV- ის მუშაობის პრინციპებს და დეტალურად განიხილოს ერთი მათგანი, კერძოდ Git. რატომ git? ინ ახლახან   ეს სისტემა პოპულარობას იძენს და მისი მნიშვნელობა თავისუფალი პროგრამული უზრუნველყოფისთვის (და განსაკუთრებით GNU / Linux პროექტისთვის) ძნელია გადაჭარბებული.

ჩვენ მუდმივად, ზოგადად, გავაანალიზებთ საკონტროლო სისტემების მახასიათებლებს და ვისაუბრებთ მათ არქიტექტურასა და მოცემული პროგრამის ძირითადი მახასიათებლების შესახებ. გარდა ამისა, ჩვენ განვიხილავთ არსებულ ინტერფეისებს Git– თან მუშაობისთვის.

ავტორი მიზანმიმართულად გამოტოვებს ფუნქციების, გასაღებების და სხვა დახვეწილობების ტერმინოლოგიას, რათა ნათლად, მკაფიოდ და ზოგადად წარმოგიდგინოთ სურათი. ეს სტატია ვარაუდობს, რომ მკითხველი კარგად იცნობს Unix– ის მსგავსი ოპერაციული სისტემებს (OS) და ასევე აქვს ზოგადი ცოდნა ალგორითმების და ზოგადად კომპიუტერული მეცნიერების შესახებ.

შემდეგ მასალებში შევეხებით Git- ის სტრუქტურასა და ფილოსოფიას, ამ სისტემის სპეციფიკას და მასთან პრაქტიკული მუშაობის დახვეწილობას. სტატია Git– ის სხვა SUV– ებთან ურთიერთქმედების შესახებ (როგორიცაა Subversion, CVS, Mercurial და ა.შ.) ციკლს დასრულდება.

2. Git არის ...

Git არის განაწილებული ფაილური ვერსიის მართვის სისტემა. პროგრამის კოდი იწერება ძირითადად C.- ში. პროექტი შეიქმნა ლინუს ტორვალდსის მიერ 2005 წელს, Linux- ის ბირთვის დამუშავების მენეჯმენტისთვის და, ისევე, როგორც GNU / Linux, არის უფასო პროგრამა (პროგრამა), ხოლო მესამე მხარის გამოყენება ექვემდებარება GNU GPL ვერსიას 2. მოკლედ ეს ხელშეკრულება შეიძლება შეფასდეს, როგორც უფასო კოდის პროგრამული უზრუნველყოფა, რომელიც უნდა შემუშავდეს ღიად, ე.ი. ნებისმიერ პროგრამისტს აქვს უფლება გააგრძელოს პროექტის გაუმჯობესება ნებისმიერ ეტაპზე. მისი არსებობის მოკლე დროით ეს სისტემა   დაინერგა მრავალი წამყვანი დეველოპერის მიერ. Git გამოიყენება ისეთ პროექტებში, რომლებიც ცნობილია Linux– ის საზოგადოებისთვის, როგორიცაა Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. ვერსიის კონტროლის სისტემები

Version Control Systems (Version Control Systems) არის პროგრამული უზრუნველყოფა, რომელიც შექმნილია ფაილის (ან ფაილების ჯგუფის) ისტორიასთან მუშაობის ავტომატიზაციისთვის, უზრუნველყოფს ცვლილებების მონიტორინგს, მონაცემთა სინქრონიზაციას და პროექტის უსაფრთხო საცავის ორგანიზებას. მოკლედ რომ ვთქვათ, ვერსიის მართვის სისტემების მთავარი მიზანია ინფორმაციის შეცვლაზე მუშაობის გამარტივება. მოდით განვიხილოთ განვითარების ზოგადი ხედი მაგალითის გამოყენებით.

დავუშვათ, რომ არსებობს გარკვეული პროექტი, რომელსაც თქვენ უვითარებთ, პროგრამისტების რამდენიმე განყოფილება და თქვენ ხართ კოორდინატორი (ან ლიდერი). საკონტროლო სისტემასთან მიმართებაში, იქნება ეს სერვერი (თუ ეს არის ცენტრალიზებული სისტემა) ან ადგილობრივი მანქანა, ნებისმიერი პროექტის შემქმნელი შემოიფარგლება მხოლოდ ფაილური ვერსიების შეცვლის ან / და წაკითხვის უფლებით. ეს საცავი. ნებისმიერ დროს, შეგიძლიათ გადააბრუნოთ მონაცემები თქვენთვის საჭირო ვერსიამდე. თქვენ, როგორც კოორდინატორი, შეგიძლიათ შეზღუდოთ გარკვეული მომხმარებლისათვის წვდომა ფაილის ვერსიის განახლების მიზნით. SUV ასევე უზრუნველყოფს ინტერფეისს ფაილის ვერსიების მონიტორინგისა და მოსაძებნად. მაგალითად, შეგიძლიათ შექმნათ შეკითხვა: "სად და როდის შეიცვალა კოდი?".

სისტემა ითვალისწინებს მონაცემთა უსაფრთხო შენახვას, ე.ი. მასში დაცულ ნებისმიერ ბლოკს აქვს მრავალი კლონი. მაგალითად, თუ ფაილი დაზიანებულია, შეგიძლიათ დროულად შეცვალოთ იგი ასლით. პროექტის მონაცემების მოცულობის შესამცირებლად, ხშირად გამოიყენება დელტა შეკუმშვა - საცავის ტიპი, რომელშიც არა ფაილური ვერსიები ინახება, არამედ იცვლება მხოლოდ თანმიმდევრული გადასინჯვებით.

4. განსხვავებები განაწილებული ვერსიის მართვის სისტემებს შორის

განაწილებული ვერსიის მართვის სისტემები არის SUV, რომელთა მთავარი პარადიგმაა თითოეული პროექტის შემქმნელის მონაცემების ლოკალიზაცია. სხვა სიტყვებით რომ ვთქვათ, თუ ცენტრალიზებულ SUV- ში ყველა მოქმედება, ამა თუ იმ გზით, დამოკიდებულია ცენტრალურ ობიექტზე (სერვერზე), მაშინ განაწილებულ SUV- ში თითოეული დეველოპერი ინახავს საკუთარი ვერსიის ფილიალს მთელი პროექტის განმავლობაში. ასეთი სისტემის ხელსაყრელია ის, რომ თითოეულ დეველოპერს აქვს შესაძლებლობა დამოუკიდებლად იმუშაოს, ზოგჯერ პროექტის სხვა მონაწილეებთან ურთიერთთანამშრომლობის შუალედური გაცვლა. განვიხილოთ ეს თვისება, გააგრძელეთ წინა მაგალითი.

აპარატზე თითოეულ დეველოპერს აქვს საკუთარი ადგილობრივი საცავი - ფაილის ვერსიების შესანახად. პროექტის მონაცემებთან მუშაობა ხორციელდება თქვენს ადგილობრივ საცავზე, და ამისათვის საჭირო არ არის კონტაქტის შენარჩუნება დანარჩენ (თუნდაც მთავარ) განვითარების ფილიალებთან. სხვა საცავებთან დაკავშირება საჭირო იქნება მხოლოდ სხვა ფილიალების ფაილური ვერსიების შეცვლის / წაკითხვისას. ამავე დროს, თითოეული პროექტის მონაწილე ადგენს საკუთარი შენახვის უფლებას წაიკითხონ და წერონ. ამრიგად, განაწილებულ სუას ყველა ფილიალი ერთმანეთის ტოლია და კოორდინატორი ირჩევს მათგან მთავარს. მთავარი ფილიალი განსხვავებულია მხოლოდ იმით, რომ დეველოპერები გონებრივად გაათანაბრებენ მას.

5. Git– ის ძირითადი მახასიათებლები და მახასიათებლები

უნდა ითქვას, რომ სისტემამ, თუ მან არ გააფუჭა სიბრტყე, მაშინ ცოტა გააღიზიანა საზოგადოება SUV სფეროში, თავისი სიახლით და შესთავაზა განვითარების ახალი გზა. Git უზრუნველყოფს მოქნილ და ადვილად გამოსაყენებელ ინსტრუმენტებს პროექტის ისტორიისთვის.

Git- ის მახასიათებელია ის, რომ პროექტის ვერსიებზე მუშაობა შეიძლება არ ჩატარდეს ქრონოლოგიური თანმიმდევრობით. განვითარება შეიძლება განხორციელდეს რამდენიმე პარალელურ ფილიალში, რომელთა დიზაინის დროს ნებისმიერ დროს შეიძლება შერწყმა და გაყოფა.

Git არის საკმაოდ მოქნილი სისტემა და მისი ფარგლები არ შემოიფარგლება მხოლოდ განვითარების მასშტაბით. მაგალითად, ჟურნალისტებმა, ტექნიკური ლიტერატურის ავტორებმა, ადმინისტრატორებმა, უნივერსიტეტის მასწავლებლებმა შეიძლება კარგად გამოიყენონ ეს საკუთარი ტიპის საქმიანობაში. ეს დავალებები მოიცავს ნებისმიერი დოკუმენტაციის, ანგარიშის, საშინაო დავალების ვერსიის კონტროლს.

ჩვენ ხაზს ვუსვამთ მთავარ განსხვავებებს Git- ს და სხვა განაწილებულ და ცენტრალიზებულ SUV- ებს შორის.

Git Architecture

SHA1 (უსაფრთხო ჰაშის ალგორითმი 1) არის კრიპტოგრაფიული ჰასინგის ალგორითმი. Git- ში თქვენი პროექტის თითოეული ფაილი მოიცავს სახელწოდებას და შინაარსს. სახელი პირველი 20 ბაიტია; იგი ვიზუალურად იწერება ორმოცდაათიანი რიცხვების სისტემაში ორმოცი სიმბოლოთ. მოცემული გასაღები   მოპოვებულია ფაილის შინაარსის ჰუსინგის შედეგად. მაგალითად, ორი სახელის შედარებისას, თითქმის ასი პროცენტიანი ალბათობით შეიძლება ითქვას, რომ მათ აქვთ იგივე შინაარსი. ასევე, სხვადასხვა ფილიალში (საცავებში) იდენტური ობიექტების სახელები ერთნაირია, რაც საშუალებას გაძლევთ უშუალოდ მუშაობთ მონაცემებზე. კარგი დანამატი   რაც ზემოთ უკვე ნათქვამია, რომ ჰაში საშუალებას გაძლევთ ზუსტად განსაზღვროთ ფაილების კორუფცია. მაგალითად, შინაარსის ჰშის სახელთან შედარებისას, საკმაოდ ზუსტად შეგვიძლია ვთქვათ, არის მონაცემები კორუმპირებული თუ არა. გარდა ამისა, სახელით ვგულისხმობთ ფაილის სახელს, ხოლო პერსონაჟის სტრიქს SHA1 ჰეშტს ვუწოდებთ.

აღსანიშნავია ეგრეთ წოდებული შეჯახება. "სწორად დაადგინეთ ზიანი" ნიშნავს, რომ არსებობს ასეთი ფაილები, შინაარსით განსხვავებული, რომელთა SHA1 ჰაში იგივეა. ასეთი შეჯახების ალბათობა ძალიან დაბალია და წინასწარი შეფასებით, ეს არის 2 –80 – ე ხარისხში (~ 10 – –25 – ე ხარისხში). ზუსტი დადგენა არ არსებობს, რადგან ამ დროისთვის მსოფლიო საზოგადოებამ ვერ შეძლო ამ კრიპტოგრაფიული სქემის ეფექტურად გაშიფვრა.

Git ობიექტები

Git- ში ფაილურ ვერსიებთან მუშაობა შეიძლება შედარდეს ჩვეულებრივი ფაილური სისტემის ოპერაციებთან. სტრუქტურა შედგება ოთხი ტიპის ობიექტისაგან: Blob, Tree, Commit და References; ზოგი მათგანი, თავის მხრივ, იყოფა სუბიექტებად.

Blob (ორობითი დიდი ობიექტი) - მონაცემთა ტიპი, რომელიც შეიცავს მხოლოდ ფაილის შინაარსს და მის SHA1 ჰეშს. Blob არის მთავარი და ერთადერთი მონაცემთა გადამზიდავი Git ჩარჩოებში. თქვენ შეგიძლიათ პარალელური დახატვა ამ ობიექტსა და ფაილურ სისტემებში ინოდებს შორის, რადგან მათი სტრუქტურა და მიზნები ძალიან ჰგავს.

ხე

  • საკუთარი SHA1 ჰაში;
  • SHA1 ბუშტებისა და / ან ხეების ჰაში;
  • unix სისტემების დაშვების უფლებები;
  • ობიექტის სიმბოლური სახელწოდება (სისტემაში შიდა გამოყენების სახელი).

მის ბირთვს ობიექტი წარმოადგენს დირექტორიის ანალოგს. იგი განსაზღვრავს პროექტის ფაილების იერარქიას.

ვალდებულება   - მონაცემთა ტიპი, რომელიც შეიცავს:

  • საკუთარი SHA1 ჰაში;
  • ბმული ზუსტად ერთ ხეზე;
  • ბმული წინა ვალდებულებასთან (შეიძლება რამდენიმე იყოს)
  • ავტორის სახელი და ვალდებულების შექმნის დრო;
  • შემსრულებლის სახელი (მსჯავრდებული - პირი, ვინც შეიტანა ვალდებულება საცავში, ეს შეიძლება განსხვავდებოდეს ავტორისგან) და ვალდებულების გამოყენების დრო;
  • მონაცემების თვითნებური ნაშთი (ბლოკი შეიძლება გამოყენებულ იქნას ელექტრონულ ხელმოწერაში ან, მაგალითად, ჩადენილი ცვლილებების ასახსნელად).

ეს ობიექტი შექმნილია ფაილების ჯგუფის Snapshot (ვერსიის) შესანახად დროის კონკრეტულ მომენტში, შეგიძლიათ შეადაროთ იგი საკონტროლო წერტილს. კომიტეტის გაერთიანება, განშტოება ან, მაგალითად, ხაზოვანი სტრუქტურის შექმნა, ამით ასახულია პროექტის ვერსიების იერარქია.

ცნობა - მონაცემთა ტიპი, რომელიც შეიცავს ბმულს ოთხივე ობიექტთან (Blob, Tree, Commit and References). მისი მთავარი მიზანია პირდაპირ ან ირიბად მიუთითოს ობიექტზე და იყოს იმ ფაილის სინონიმი, რომელზეც იგი ეხება. ეს ზრდის პროექტის სტრუქტურის გააზრებას. ძალიან არასასიამოვნოა იმ პერსონაჟების უაზრო სიმრავლისთვის სახელის შექმნა, მაგრამ ბმული, განსხვავებით SHA1 ჰეშტისგან, შეიძლება დაასახელოს, როგორც დეველოპერისთვის ეს უფრო მოსახერხებელია.

ბმულებიდან, თავის მხრივ, შეგვიძლია განვასხვავოთ მრავალი ქვესახეობა, რომელსაც აქვს გარკვეული განსხვავებები: ფილიალი, ტეგ. განვიხილოთ ისინი.

ფილიალი (ხელმძღვანელი, ფილიალი) - სიმბოლური ბმული (სიმბოლური რგოლი), რომელიც მიუთითებს ბოლო ამა თუ იმ ფილიალის ქრონოლოგიაში და ინახავს ობიექტის SHA1 ჰეშს. ეს არის ჟურნალის ფაილური სისტემების მონაცემთა ტიპი. ამ ტიპის ობიექტი თავად Git- ში არ არის განსაზღვრული, მაგრამ მემკვიდრეობითია ოპერაციული და ფაილური სისტემებიდან. ფილიალი გამოიყენება როგორც ფაილის სინონიმი, რომელსაც იგი ეხება, ე.ი. Git საშუალებას გაძლევთ უშუალოდ იმუშაოთ. თქვენ თავს უფლებას მისცემთ, არ იფიქროთ იმაზე, მუშაობთ უახლეს ვერსიასთან თუ არა.

ტეგ   - მონაცემთა ტიპი, რომელიც ფილიალებისგან განსხვავებით, უცბად ეხება იგივე ობიექტს, როგორიცაა ბლაგვი, ხე, ჩადება ან ტეგები. ეს, თავის მხრივ, შეიძლება დაიყოს მსუბუქი და მსუბუქი წონის ან ანოტირებულ ტეგად. შუქის ჩანართი, გარდა ბმული იმუნიტეტის გარდა, არ განსხვავდება ჩვეულებრივი ტოტებისაგან, ე.ი. შეიცავს მხოლოდ მასში მითითებული ობიექტის SHA1 ჰეშტს. ანოტირებული წარწერა შედგება ორი ნაწილისაგან:

  • პირველი ნაწილი შეიცავს SHA1 ჰასს;
  • მეორე ნაწილი შედგება:
    • ობიექტის SHA1, რომელსაც ანოტირებული ჩანართი მიუთითებს;
    • მითითებული ობიექტის ტიპი (ბლაგვი, ხე, ღეროვანი ან საკვანძო);
    • ტეგის სიმბოლური სახელი;
    • შეიქმნა ჩანაწერის თარიღი და დრო;
    • ტეგის შემქმნელის სახელი და ელ.ფოსტა;
    • მონაცემების თვითნებური ნაშთი (ამ ბლოკის გამოყენება შესაძლებელია ელექტრონული ხელმოწერისთვის ან ტეგის ასახსნელად).

სხვა სიტყვებით რომ ვთქვათ, Git- ში პროექტი არის ბლაბლების კოლექცია, რომელსაც ხეების ქსელი უკავშირდება. შედეგად იერარქიული სტრუქტურა შეიძლება დამოკიდებულია დროზე, რაც აისახება ვალდებულების ვერსიის ფორმაში და Git- ში მათი სტრუქტურის გასაგებად არსებობს ობიექტები, როგორიცაა ბმულები. ბმულებთან დაკავშირებული ქმედებების გამოკლებით, სისტემის ობიექტებთან თითქმის ყველა მუშაობა მაქსიმალურად ავტომატიზირებულია შიგნიდან. ბმული მექანიზმის საფუძველზე, ჩვენ შემდეგ იდეამდე მივდივართ - ვიმუშაოთ ფაილების ჯგუფებზე. ავტორის თქმით, იდეა მთავარია Git- ის ფილოსოფიაში. მაგალითად, ამგვარი ჩადენისთვის ოპერაციის დაწესებით, იგი რეკურსიულად ასრულებს თავის ნაწილს იმ ხეში, რომელზეც იგი ეხება. ზოგადად მიღებული ხედვის „მოქმედება თითოეულ ფაილზე“ გაფართოებაა, ინოვაცია ამარტივებს პროგრამის შემსრულებლის მხრიდან განხორციელებას და მიდგომას SUV- ს ყოველდღიური დავალებების შესრულებაზე, როგორიცაა ფილიალების შერწყმა / გაყოფა, კვლავ ამარტივებს პროცესს რეკურსიულად. ეს მიდგომა მარტივია გასაგები, სწრაფად მუშაობს და მოქნილია საკუთარი მიზნების რეალიზაციაში. ამ მახასიათებლებისგან ბევრი მიიღწევა Unix- ზე ორიენტირებული სისტემის წყალობით, ე.ი. სტანდარტული მოწყობილობებით მუშაობს, Git ეყრდნობა არსებულებს ოპერაციული სისტემა   გადაწყვეტილებები.

მოდით განვმარტოთ მონაცემთა შენახვის მომენტი. ქრონოლოგიაში სხვადასხვა ვერსიის ფაილების შინაარსი დიდ მეხსიერებას იძენს. მაგალითად, ოცი ვერსიის ოცი ფაილის პროექტში, არქივი იწონის 20-ჯერ მეტს (ალბათ ასამდე მეგაბაიტი) და რა მოხდება, თუ ამ და სხვათა რიცხვი 10-ჯერ მეტია (როგორც ჩანს, არც თუ ისე ბევრი)? ოკუპირებული სივრცის ზომა გაიზრდება 100 ჯერ (ანუ დაახლოებით 1 GB). რეალურ პრობლემებში, ოკუპირებული მეხსიერების ზრდის ტემპი შორს არის ხაზოვანი დამოკიდებულებით დროზე. ამ პრობლემის გადასაჭრელად, რამდენიმე ოპტიმიზაცია არსებობს:

  • თითოეული Git ობიექტი ინახება როგორც ჩვეულებრივი არქივი (tar.gz);
  • თანმიმდევრული დელტა შეკუმშვა გამოიყენება ფაილების მთელი იერარქიისთვის.

მოდით მაგალითი მოვიყვანოთ.

თქვენ გაქვთ თქვენი პროექტის სამწლიანი ისტორია, მასში დაახლოებით ათასი ფაილი და ასი ვერსიაა. თუ რაიმე მომენტში საჭიროა ადრინდელი ვერსიისკენ მიბრუნება, Git– ს მოუწევს მოახდინოს ფაილების მთელი ისტორიის დელტა შეკუმშვის გაუქმება. იმედგაცრუებული, მაგრამ ამ პროცესს შუადღემდე შეუძლია. Git გთავაზობთ ე.წ. საკონტროლო წერტილები, ე.ი. შეინახეთ ყოველკვირეული დაარქივებული ფაილი მრავალი ვერსიის საშუალებით, რომელსაც შეკუმშვის სიღრმე ვუწოდებთ. შემდეგ ჩვენს მაგალითში მთელი ამბავი ვიწრო დელტა-კომპრესების გარკვეულ წინასწარ განსაზღვრულ რაოდენობას, მათი გაუქმებას, მათი ქრონოლოგია შეგიძლიათ გადახედოთ ნებისმიერ ვერსიას. გაითვალისწინეთ, რომ მიზანშეწონილია დელტა კომპრესიის გამოყენება იერარქიასთან უახლოესი ობიექტების გარკვეულ ტიპებზე, ამისათვის, საცავი დალაგებულია შესაბამისად და ტიპის მიხედვით. ამ პუნქტით აღწერილი ოპერაციების ეს სერია ხორციელდება git-repack ფუნქციით (და git-gc, რომელიც შეიცავს მას).

შერწყმა და გაყოფილი ფილიალები

ეს საკითხი ძალზედ შრომატევადი და გაჯერებულია, ამასთან დაკავშირებით მხოლოდ ზოგადი თვალსაზრისით წარმოგიდგენთ შერწყმისა და განცალკევების ცნებებს. მოდით მივმართოთ მაგალითს.

წარმოიდგინეთ პროექტის განვითარების მომენტი, როდესაც მთავარი მიზანი პროგრამის სიჩქარეა. ერთ-ერთი შესაძლო ტაქტიკური გადაწყვეტაა დეველოპერების ორ ჯგუფად დაყოფა, რომელთაგან თითოეული გადაჭრის იმავე პრობლემას. ამ შემთხვევაში, უნდა გაიყოს პროექტის ისტორიის ფილიალი. ეს პროცედურა   მოუწოდა ფილიალი. ფილიალის განშტოების მოქმედება უბრალოდ ქმნის მის ასლს, რომელსაც შემდგომში საკუთარი ისტორია ექნება.

მოდით მივიღოთ იგივე დავალების ორი დასრულებული შედეგი, რომელზედაც მუშაობდნენ პროგრამისტების ორი ჯგუფი. როგორ ვიქნებით? ნახეთ ვისი კოდი უფრო სწრაფი და საიმედოა? ეს ძალიან ადვილია, მაგრამ ყოველთვის არ არის საუკეთესო გამოსავალი. კარგი გამოსავალია, კოდისა და ფაილების მცირე გაგებით, მათი დაყოფა დაქვემდებარებაში ან კოდების ბლოკებად. და მხოლოდ ამის შემდეგ შეგვიძლია გამოვყოთ ამ ნაწილების სიძლიერე და სისუსტე. რასაკვირველია, ეს ვარიანტი შესაფერისია მხოლოდ იმ შემთხვევაში, თუ წინასწარ განისაზღვრა, რომ შემდგომში თქვენ შეგიძლიათ ყველა ეს ნაწილაკი ერთად შეაგროვოთ. შემთხვევა, როდესაც თქვენ თავად შეიმუშავებთ კოდს, შეცდომების გაუმჯობესება და დაფიქსირება მოცემულ მაგალითს ექვემდებარება. ეს პროცესი   ორი მთელი რიცხვის გაერთიანება ერთს ეწოდება შერწყმა. ორი ვერსიის შეთავსების პროცესი არის პროექტის მთავარი წერტილი. როგორც ეს შეიძლება, თავიდან აიცილოთ ამ ოპერაციის ავტომატური შესრულება. Git- ის გამორჩეული თვისება არის ყველაზე საიმედო და საკმაოდ სწრაფი გზა   განშტოების პრობლემის გადაჭრა.

სისტემის უპირატესობებში შედის:

  1. უნიქსის ორიენტაცია.
  2. იდეოლოგიური თანმიმდევრულობა (სისტემის გამოყენების წესების დაცვით, მისი შეყვანა ძალზე ძნელია უიმედო სიტუაცია   ან მიიღე ის, რაც არ მოელოდა).
  3. მაღალი ხარისხის (ეს არის სისტემის ერთ – ერთი აშკარა უპირატესობა, რომლის გადახდაა „იდეოლოგიური მდგრადობა“ და „უნიქსიზე ორიენტირებული“).
  4. Git ინტეგრაცია მესამე მხარის კონტროლის სისტემებთან, როგორიცაა Subversion, Mercurial, ...
  5. ფაილების ჯგუფის მენეჯმენტი (სისტემას არ სჭირდება ცალკეულ ფაილში ცვლილებების გათვალისწინება. მას ახსოვს ნებისმიერი ცვლილება მთელს პროექტში. თუ მოულოდნელად გჭირდებათ ცვლილებების თვალყურის დევნება, ის ზუსტად გადმოცემს იმ ნაწილს, რაც ამ ფაილთან არის დაკავშირებული).
  6. შერწყმის ოპერაცია (რთული ამოცანის ყველაზე ავტომატიზებული განხორციელება).

ნაკლოვანებები მოიცავს:

  1. Unix- ის ორიენტაცია (აღსანიშნავია Git- ის სრულყოფილი განხორციელების ნაკლებობა არაიონიქსის სისტემებზე).
  2. Git-gc ბრძანების პერიოდულად შესრულების აუცილებლობა (შეფუთულია ფაილების ჯგუფები და წაშლის ისეთებს, რომლებიც არ უკავშირდება კავშირებს).
  3. Hash შეჯახება (სხვადასხვა შინაარსის ფაილების შესაბამისი SHA1 ჰაში).

6. Git ინტერფეისები

”რამდენი ადამიანი, ამდენი მოსაზრება”. შევეცადოთ ხაზი გავუსვა ინტერფეისის ტიპებს სისტემასთან მუშაობისთვის. გარკვეული მიზნებისათვის, შემდეგი შემდეგი ტიპის პროგრამები უკეთესია საკუთარი გზით.

მათთვის, ვინც არ არის მჭიდროდ ჩართული განვითარებაში, ”კონსერვატორებისთვის” - მათთვის, ვისაც უყვარს ”ღილაკები და ნიშნები” და ვისაც შეგნებულად სურს დაიცვას თავი ფუნქციების დამახსოვრების უზარმაზარი ძალისხმევისგან, კლავიშებისა და მრავალი ქვეტექსტისგან, უფრო შესაფერისია TortoiseGit ან Git Extensions. ინტერფეისები. ისინი საშუალებას გაძლევთ იმოქმედოთ ძირითადად მაუსის საშუალებით და ბევრისთვის იმუშაოთ ჩვეულებრივ Windows ოპერაციულ სისტემაში.





ზუსტად საპირისპირო ტიპის ინტერფეისი. პროგრამისტებისთვის, რომლებსაც მუდმივად სჭირდებათ თანამშრომლობა თანამშრომლებთან, მაკონტროლებელი კოდის ტიპიური ამოცანების გადასაჭრელად, იმ ადამიანებისთვის, რომლებიც იყენებენ Unix- ის მსგავსი სისტემებში მუშაობას ტერმინალის გამოყენებით, აპლიკაციების კონსოლური ხედი საუკეთესოა. ისინი ასევე მარტივი გამოსაყენებელია, ცოტა უფრო სწრაფი და ფუნქციონალური, მაგრამ მათ დრო დასჭირდებათ, რომ გაერკვნენ, თუ როგორ გამოიყენოთ იგი.



შეგვიძლია განვასხვავოთ მესამე ტიპის ინტერფეისი - პირველი ორი ნაზავი. ე.ი. თქვენ გაქვთ კონსოლის პროგრამა, მაგალითად, "მშობლიური" git ჭურვი. თქვენ შეგიძლიათ გამოიყენოთ მრავალი დამატებითი კომუნალური პროგრამა, მაგალითად Gitk ან QGit, ხეების სანახავად, გაამარტივოთ ვერსიის იერარქიის მიმოხილვა, ვერსიებს შორის განსხვავებები და მოძებნოთ საჭირო ობიექტები.



7. დასკვნა

ასე რომ, მკითხველები უკვე ხვდებიან, თუ როგორ მუშაობს თანამედროვე ვერსიის მართვის სისტემები. გარდა ამისა, ჩვენ მიმოვიხილეთ ერთ-ერთი ყველაზე პოპულარული სისტემის არქიტექტურა - Git. შემდეგ სტატიაში, ჩვენ შევეცდებით გაეცნოთ მის ზოგიერთ მახასიათებელს პრაქტიკაში - განვიხილავთ მათ ფუნქციებსა და გასაღებებს. სტატიაში მოცემულია ფაილების ისტორიის შენარჩუნების არაერთი საილუსტრაციო მაგალითი, ასევე განაწილებული სისტემების ფილოსოფია. ავტორი შეეცდება მკითხველს დაანახოს როგორ გამოიყენოს Git სწორად და გადახედოს ამ GMS– ის გამოყენების ზოგიერთ ჩვეულებრივ შეცდომას.

ბევრი მათგანი ასოცირდება განვითარებასთან პროგრამაგაიგონა git. რა არის ეს სამი წერილი? ძალიან მნიშვნელოვანია აღწერილობის, აგრეთვე ფუნქციონირების პრინციპების გაგება, იმისათვის, რომ ეფექტურად გამოიყენოთ ეს ვერსია კონტროლის სისტემა, რომელშიც, სხვა მსგავსი სისტემებისგან განსხვავებით, სრულიად განსხვავებული ცნებები ინფორმაციის შესახებ, მასთან ერთად იმუშავებს, მიუხედავად მსგავსი ინტერფეისი. რა არის გიტი?

აღწერა

Git არის განაწილებული ვერსიის მართვის სისტემა შემუშავებული ფაილებისთვის. იგი 2005 წელს შეიქმნა Linux OS– ის ავტორის მიერ. ეს სისტემა სინქრონიზაციას უწევს საიტთან მუშაობას, ასევე ფაილებში ინახავს და აახლებს ცვლილებებს. ეს არის ძალიან მოსახერხებელი მიდგომა იმ პროექტზე მომუშავე რამდენიმე დეველოპერის შემთხვევაში. დღეს ბევრ ცნობილ პროექტს იყენებენ ზუსტად Git. რას იძლევა გამოყენება? მაგალითად, ოპერაციის შემუშავება android სისტემები   ჩაერთო პროგრამისტების დიდი რაოდენობით. უკიდურესად მოუხერხებელი იქნებოდა, თუ ერთმა მათგანმა ცვლილებები შეიტანა, დანარჩენებმა ამის შესახებ არ იცოდნენ. Git ყველას საშუალებას აძლევს შეინარჩუნონ ყველა ცვლილება და შეცდომების შემთხვევაში, დაბრუნდნენ წინა ვერსიები   ფაილები.

კასტების გამოყენება ვიდრე წერთ


Git- ს და სხვებს შორის მთავარი განსხვავებაა, თუ როგორ გამოიყურება მონაცემები. პროგრამების უმეტესობა ინახავს ინფორმაციას ცვლილებების ჩამონათვალის სახით, რომელსაც ფაილების პატჩები ეწოდება. ასეთი სისტემები ეხება შენახულ მონაცემებს, როგორც ფაილების ერთობლიობას, ასევე ცვლილებების ერთობლიობას, რომელიც მზადდება თითოეული ფაილისთვის, დროის შედარებით. როგორ ინახავს Git მონაცემებს? რა არის ეს სისტემა, რომელიც განასხვავებს მას სხვებისგან? პატჩების ნაცვლად, აქ შენახული მონაცემები განიხილება მცირე ფაილური სისტემის ნუგბარების ნაკრებად. როდესაც მომხმარებელი შეასრულებს პროექტის ახალ ვერსიას, სისტემა უბრალოდ ინახავს ფაილების მდგომარეობის ამსახველ სურათს მიმდინარე მომენტში. ეფექტურობის ასამაღლებლად იმ შემთხვევაში, როდესაც ფაილი არ შეცვლილა, სისტემა არ ინახავს მას, მაგრამ აკავშირებს ბმულზე ადრე შენახულ ინსტანციას, რომელშიც განხორციელდა უახლესი ცვლილებები.

ეს არის ძალიან მნიშვნელოვანი განსხვავება სხვა საკონტროლო სისტემებისგან, რაც თანდაყოლილია Git– ში. რა განსხვავებაა? Git პატარავით იქცევა ფაილური სისტემაფლობენ ძალზე მძლავრ ინსტრუმენტებს, რომლებიც მუშაობს მის თავზე.

ძირითადად ადგილობრივი ოპერაციები


Git– ში ოპერაციების უმეტესობის შესასრულებლად, საჭიროა მხოლოდ ადგილობრივი რესურსები და ფაილები. ეს ნიშნავს, რომ ყველაზე ხშირად არ არის საჭირო ქსელში სხვა კომპიუტერებზე ინფორმაციის მიწოდება. მას შემდეგ, რაც ყველა პროექტის ცვლილება დისკზეა, ოპერაციები ხორციელდება ელვისებური სისწრაფით. მაგალითად, პროექტის ისტორიის სანახავად, მას არ სჭირდება სერვერის ჩამოტვირთვა. ამის შესახებ იკითხება კომპიუტერის ადგილობრივი საცავიდან. თუ თქვენ გჭირდებათ დაინახოთ ცვლილებები ფაილის ვერსიას შორის, რომელიც გაკეთდა ერთი თვის წინ და მიმდინარე, შეგიძლიათ ეს გააკეთოთ ძალიან სწრაფად, სერვერზე გადასვლის გარეშე.

ადგილობრივი სამუშაო ასევე ნიშნავს იმას, რომ თქვენ შეგიძლიათ ბევრი რამ გააკეთოთ ქსელთან დაკავშირების გარეშე. მაგალითად, დეველოპერს შეუძლია ტრანსპორტირების დროს შეიტანოს ცვლილებები. ბევრ საკონტროლო სისტემაში ეს შეუძლებელია.

მონაცემთა მთლიანობის მონიტორინგი

ნებისმიერი ფაილის შენახვის წინ, მას ენიჭება ინდექსი ჩიტის სახით, რომელიც გამოითვლება უშუალოდ Git- ის მიერ. რა არის ეს მნიშვნელობა, რომელიც გამოითვლება სპეციალური ალგორითმების გამოყენებით და გამოიყენება მონაცემთა შენახვისა და გადაცემის დროს მონაცემების მთლიანობის დასადგენად. გიტის ცოდნის გარეშე აქ არაფრის შეცვლა შეუძლებელია, და ეს სისტემის ფილოსოფიის მნიშვნელოვანი კომპონენტია.

მონაცემებს ყველაზე ხშირად ემატება.


Git- ში შესრულებული თითქმის ყველა მოქმედება ემატება მონაცემთა ბაზას. მათი ამოღება ძალიან რთულია. თქვენ შეგიძლიათ მხოლოდ დაკარგოთ ინფორმაცია, რომელიც ჯერ არ არის შენახული, მაგრამ როდესაც ის ჩადენილია, ზარალი გამორიცხულია. ამ მიზეზის გამო, ბევრს ირჩევს Git, რადგან აქ შეგიძლიათ ექსპერიმენტი განახორციელოთ რისკის გარეშე, რაიმე შეუქცევად გაკეთებაზე.

ფაილის სტატუსი

Git– ს დამწყებთათვის მუშაობა უნდა გვახსოვდეს, რომ ფაილი შეიძლება იყოს სამ შტატში:

  • ჩადენილი, ანუ ფაილი ინახება ადგილობრივ საცავში.
  • ცვლილებები განხორციელდა, როდესაც ცვლილებები განხორციელდა, მაგრამ დაზოგვა ჯერ არ დასრულებულა.
  • მომზადებულია - შეცვლილი ფაილები, რომლებიც აღინიშნება დაზოგვისთვის.

ასე რომ, პროექტებში, რომლებსაც იყენებენ Git, არსებობს სამი განყოფილება სხვადასხვა ფაილის მდგომარეობებისთვის:

  • Git დირექტორია, სადაც მეტამონაცემები ინახება, ასევე ობიექტების მონაცემთა ბაზა. სისტემის ეს ნაწილი ყველაზე მნიშვნელოვანია.
  • სამუშაო დირექტორია, რომელიც წარმოადგენს მონაცემთა ბაზიდან ამოღებული პროექტის ზოგიერთი ვერსიის ასლს.
  • ფაილი, რომელიც შეიცავს ინფორმაციას შემდგომი შენახვის შესახებ.

დააინსტალირეთ Git


პირველი, რაც უნდა გავაკეთოთ, რათა გამოიყენოთ ვერსიის კონტროლის სისტემა, მისი ინსტალაციაა. ამის გაკეთების რამდენიმე გზა არსებობს. მთავარია ორი ვარიანტი:

  • დააინსტალირეთ Git წყაროდან.
  • პაკეტის დაყენება თქვენი პლატფორმისთვის.

დააინსტალირეთ Git წყაროდან

თუ ეს შესაძლებელია, უმჯობესია გამოიყენოთ ეს ვარიანტი, რადგან ყველაზე მეტად ახალი ვერსია. თითოეული განახლება, როგორც წესი, შეიცავს ბევრ სასარგებლო გაუმჯობესებას, რის გამოც თუ წყაროდან ინსტალაცია თქვენთვის არც თუ ისე რთულია, უმჯობესია უპირატესობა მიენიჭოთ მას. დიახ, და Linux- ის განაწილების უმეტესობაში შედის მემკვიდრეობითი პაკეტები.

ინსტალაციისთვის დაგჭირდებათ საჭირო ბიბლიოთეკები: expat, curl, libiconv, opensl, zlib. მათი ინსტალაციის შემდეგ, შეგიძლიათ ჩამოტვირთოთ უახლესი ვერსია   ვერსიის კონტროლის სისტემა, შედგენა და ინსტალაცია.

Windows- ის ინსტალაცია

თუ მომხმარებელს არ აქვს Linux, მაგრამ სურს Git გამოიყენოს, Windows ასევე მხარს უჭერს ამ სისტემას. და მისი ინსტალაცია ძალიან მარტივია. არსებობს msysGit პროექტი, რომლის ინსტალაციის პროცედურა ერთ-ერთი ყველაზე მარტივია. თქვენ უბრალოდ უნდა ჩამოტვირთოთ ინსტალერის ფაილი, რომელიც შეგიძლიათ ნახოთ პროექტის გვერდზე GitHub– ში, შემდეგ კი გაუშვით. ინსტალაციის დასასრულს, კომპიუტერში იქნება ორი ვერსია - გრაფიკული და კონსოლი.

Git საწყისი კონფიგურაცია


მას შემდეგ, რაც კომპიუტერში დაინსტალირდება საკონტროლო სისტემა, თქვენ უნდა შეასრულოთ გარკვეული მოქმედებები მომხმარებლის კონფიგურაციისთვის. ეს კეთდება ერთხელ. განახლებისას, ყველა პარამეტრი შენახულია. მათი შეცვლა შესაძლებელია ნებისმიერ დროს.

Git მოიცავს git კონფიგურაციის კომუნალურ პროგრამას, რომლის საშუალებითაც შეგიძლიათ გააკეთოთ პარამეტრები და გააკონტროლოთ სისტემის მოქმედება, ასევე გარეგნობა. ამ პარამეტრების შენახვა შესაძლებელია სამ ადგილზე:

  • ფაილში, რომელიც შეიცავს მნიშვნელობებს, რომლებიც საერთოა ყველა მომხმარებლისთვის და საცავებისთვის.
  • კონკრეტულ მომხმარებლის პარამეტრებში შემავალი ფაილში.
  • მიმდინარე საცავში მდებარე კონფიგურაციის ფაილში. ასეთი პარამეტრები მხოლოდ მისთვის ძალაშია.

ნიკი

პირველ რიგში, ინსტალაციის შემდეგ, თქვენ უნდა მიუთითოთ მომხმარებლის სახელი, ასევე ელ.ფოსტა. ეს ძალზე მნიშვნელოვანია, რადგან თითოეული ვალდებულება (სახელმწიფო დაცვა) შეიცავს ამ მონაცემებს. ისინი შედიან ყველა ვალდებულებაში და შემდგომში მათი შეცვლა შეუძლებელია.

თუ დააკონკრეტებთ გლობალურ ვარიანტს, ამგვარი პარამეტრების გაკეთება ერთხელ უნდა მოხდეს.

ტექსტის რედაქტორის არჩევა

სახელის მითითების შემდეგ, თქვენ უნდა აირჩიოთ რედაქტორი, რომელიც საჭირო იქნება Git- ში შეტყობინებების აკრეფის დროს. სტანდარტულად გამოიყენებს სტანდარტული ოპერაციული სისტემის რედაქტორი. თუ მომხმარებელს სურს გამოიყენოს სხვა, თქვენ უნდა დაარეგისტრიროთ ეს კონფიგურაციის ფაილის პარამეტრებში ხაზში core.editor.

პარამეტრების გადამოწმება

Git- ის საფუძვლების გასაცნობად, თქვენ უნდა შეძლოთ გამოყენებული პარამეტრების შემოწმება. ამისათვის გამოიყენეთ კონფიგურაციული სია. იგი აჩვენებს ყველა შესაძლო პარამეტრს, რომლის პოვნაც შეუძლია. ზოგიერთი დასახელების სახელი შეიძლება გამოჩნდეს სიაში არაერთხელ. ეს იმიტომ ხდება, რომ Git კითხულობს ერთ კლავიშს სხვადასხვა ფაილებიდან. ამ სიტუაციაში, ბოლო მნიშვნელობა გამოიყენება თითოეული გასაღებისთვის. შესაძლებელია გარკვეული კლავიშების მნიშვნელობების შემოწმება ბრძანებაში "- ჩამონათვალის" - "(კლავიშის") ნაცვლად.

როგორ შევქმნათ საცავი

ამ მიზნის მისაღწევად ორი გზა არსებობს. პირველი არის არსებული კატალოგის ან პროექტის სისტემაში შემოტანა. მეორე არის არსებული საცავის კლონირება სერვერისგან.

ამ დირექტორიაში შექმნა

თუ მომხმარებელი გადაწყვეტს Git– ის გამოყენებას არსებული პროექტის დასაწყებად, მან უნდა წავიდეს დირექტორიაში და დაარეგისტრიროს სისტემა. ამას მოითხოვს git init ბრძანება. იგი ქმნის საქვეუწყებო დაწესებულებას იმ დირექტორიაში, სადაც ყველა იქნება საჭირო ფაილები. ამ ეტაპზე, პროექტის ვერსიის კონტროლი ჯერ კიდევ არ არის დადგენილი. კონტროლის ქვეშ მყოფი ფაილების დასამატებლად, საჭიროა მათ ინდექსირება და პირველი ცვლილების განხორციელება.

საცავი კლონირება

არსებული საცავის ასლის მისაღებად გჭირდებათ git კლონის ბრძანება. მასთან ერთად, Git მიიღებს თითქმის ყველა მონაცემის ასლს სერვერისგან. ეს ეხება თითოეული ფაილის ყველა ვერსიას. ძალიან მოსახერხებელი ფუნქციაა, რადგან სერვერის უკმარისობის შემთხვევაში, პროგრამისტი შეძლებს კლონას გამოიყენოს ნებისმიერ კლიენტზე, დაუბრუნოს სერვერი იმ მდგომარეობაში, რომელიც კლონირების დროს იყო. ეს გამოიყურება აღდგენის წერტილად.

ფაილის წაშლა Git

თქვენ შეგიძლიათ წაშალოთ ნებისმიერი ფაილი სისტემიდან, თუ მას გამორიცხავთ ინდექსისგან, ანუ მონიტორინგის ფაილიდან. ამისათვის თქვენ გჭირდებათ git rm ბრძანება. ის ასევე ამოიღებს ფაილს მომხმარებლის სამუშაო დირექტორია. მაშინ უნდა ჩაიდინო. ამის შემდეგ, ფაილი უბრალოდ ქრება და აღარ იქნება მისი თვალყურის დევნება. თუ ის შეიცვალა და უკვე ინდექსირებულია, მაშინ იძულებითი წაშლა –f– ის პარამეტრით გამოიყენება. ეს მეთოდი ხელს შეუშლის მონაცემების წაშლას, რომლებიც ჯერ არ არის დაწერილი Snapshot- ზე და რომელთა აღდგენა შეუძლებელია სისტემისგან.

შეცვალეთ ცვლილებები

ნებისმიერ დროს, შეიძლება დაგჭირდეთ მოქმედების გაუქმება. თუ მომხმარებელმა ადრეულად შეასრულა დანაშაული, დაივიწყა რამდენიმე ფაილის დამატება, მაშინ შეგიძლიათ ზედმეტი შეავსოთ იგი --amand პარამეტრის გამოყენებით. ეს ბრძანება გამოიყენება ინდექსის ჩასატარებლად. თუ ბოლო შენახვის შემდეგ ცვლილებები არ განხორციელდა, პროექტი იმავე მდგომარეობაში იქნება და რედაქტორი გამოჩნდება კომენტარებისთვის, სადაც მომხმარებელს შეუძლია შეცვალოს ყველაფერი, რაც საჭიროა. უნდა გვახსოვდეს, რომ ყველა გაუქმების ოპერაციის გაუქმება შეუძლებელია. ზოგჯერ შეგიძლიათ მუდმივად წაშალოთ საჭირო მონაცემები. ფრთხილად უნდა იყოს.

შეჯამება


ახლა მომხმარებელს უნდა ჰქონდეს იდეა, თუ რა არის Git, რატომ არის საჭირო ამ ვერსიის კონტროლის სისტემა, როგორ განსხვავდება იგი სხვა მსგავსი პროდუქტებისაგან. ნათელია, რომ სრული შესავლისთვის აუცილებელია Git– ის სამუშაო ვერსიის დაინსტალირება საკუთარი პარამეტრებისთვის. Git- სთვის ნებისმიერი სახელმძღვანელო ან ვიდეო კურსი "dummies" - სთვის, რომელსაც შეუძლია ნაბიჯ-ნაბიჯ უხელმძღვანელოს მომხმარებლის სისტემაში მუშაობის ყველა ეტაპზე, არ დააზარალებს.

ეს თავი Git– ს დაწყებასთან დაკავშირებით. ჯერ მოდით, ვისწავლოთ ვერსიის მართვის სისტემების საფუძვლები, შემდეგ გადავიდეთ იმაზე, თუ როგორ უნდა აწარმოოთ Git თქვენს OS- ზე და ბოლოს დააკონფიგურიროთ ის, რომ მუშაობს. თავის ბოლოს, თქვენ უკვე იცით, რა არის Git და რატომ უნდა გამოიყენოთ იგი, ასევე მიიღებთ სისტემას, რომელიც საბოლოოდ კონფიგურებულია მუშაობისთვის.

ვერსიის კონტროლის შესახებ

რა არის "ვერსიის კონტროლის სისტემა" და რატომ არის ეს მნიშვნელოვანი? ვერსიის კონტროლის სისტემა არის სისტემა, რომელიც წერს ფაილში ცვლილებებს ან ფაილების ნაკრებებს დროთა განმავლობაში და საშუალებას მოგცემთ მოგვიანებით დაუბრუნდეთ კონკრეტულ ვერსიას. პროგრამული უზრუნველყოფის წყაროს კოდი გამოიყენებს მაგალითს ამ წიგნში ფაილური ვერსიების გასაკონტროლებლად, თუმცა რეალურად შეგიძლიათ გამოიყენოთ ვერსიის კონტროლი თითქმის ნებისმიერი ტიპის ფაილისთვის.

თუ თქვენ ხართ გრაფიკული ან ვებ დიზაინერი და გსურთ შეინახოთ გამოსახულების ან განლაგების თითოეული ვერსია (სავარაუდოდ, გინდათ), ვერსიის კონტროლის სისტემა (შემდგომში SLE) მხოლოდ ისაა, რაც გჭირდებათ. ეს საშუალებას გაძლევთ დააბრუნოთ ფაილები იმ მდგომარეობაში, რომელშიც ისინი იმყოფებოდნენ ცვლილებებამდე, დააბრუნეთ პროექტი საწყისი მდგომარეობაიხილეთ ცვლილებები, იხილეთ ვინ შეცვალა ბოლო და რამ შეუქმნა პრობლემა, ვინ დაისახა დავალება და როდის და სხვა. ზოგადად, SLE- ის გამოყენება ასევე ნიშნავს, რომ თუ რამე დაარღვიეთ ან ფაილებს დაკარგავთ, მარტივად შეგიძლიათ გამოსწორება. ყველაფრის გარდა, ამ ყველაფერს ყოველგვარი დამატებითი ძალისხმევის გარეშე მიიღებთ.

ადგილობრივი ვერსიის მართვის სისტემები

ბევრი ადამიანი იყენებს ფაილების კოპირებას ცალკეულ დირექტორიაში, როგორც ვერსიის კონტროლის მეთოდი (შესაძლოა, თუნდაც დირექტორია, რომელზეც დროა ბეჭედი, თუ საკმარისად ჭკვიანნი არიან). ეს მიდგომა ძალიან ხშირია მისი სიმარტივის გამო, მაგრამ ის შეცდომებისკენ წარმოუდგენლად მიდრეკილია. თქვენ მარტივად შეგიძლიათ დაივიწყოთ, რომელ დირექტორია ხართ და შემთხვევით შეცვალეთ არასწორი ფაილი, ან გადაწერეთ თქვენთვის სასურველი არასწორი ფაილები.

ამ პრობლემის გადასაჭრელად, პროგრამისტებმა დიდი ხნის წინ შეიმუშავეს ადგილობრივი მძიმე ვალუტა მარტივი მონაცემთა ბაზით, რომელიც ინახავს ჩანაწერებს ფაილებში ყველა ცვლილების შესახებ, რითაც აკონტროლებენ ცვლილებებს.

სურათი 1. ადგილობრივი ვერსიის კონტროლი.

ერთ-ერთი პოპულარული მყარი ვალუტა იყო RCS სისტემა, რომელიც დღეს ბევრ კომპიუტერში ნაწილდება. პოპულარული Mac OS X- იც კი გთავაზობთ rcs ბრძანებას დეველოპერული ინსტრუმენტების ინსტალაციის შემდეგ. RCS ინახავს დისკების ნაკრებებს (ფაილებს შორის განსხვავებები) სპეციალურ ფორმატში, რომლის გამოყენებით მას შეუძლია ხელახლა შექმნას თითოეული ფაილის მდგომარეობა მოცემულ მომენტში.

ცენტრალიზებული ვერსიის მართვის სისტემები

შემდეგი სერიოზული პრობლემა, რომლის წინაშეც ადამიანები დგანან, სხვა დეველოპერებთან ურთიერთობის აუცილებლობაა. მისი მოგვარების მიზნით, შემუშავდა ვერსიის მართვის ცენტრალიზებული სისტემა (CSCV). სისტემებს, როგორიცაა: CVS, Subversion და Perforce, აქვთ ერთი სერვერი, რომელიც შეიცავს ფაილების ყველა ვერსიას, და არაერთი კლიენტი, რომლებიც იღებენ ფაილებს ამ ცენტრალიზებული საცავიდან. CCSC– ის გამოყენება მრავალი წლის განმავლობაში იყო სტანდარტი.


სურათი 2. ცენტრალიზებული ვერსიის კონტროლი.

ამ მიდგომას ბევრი უპირატესობა აქვს, განსაკუთრებით ადგილობრივ მძიმე ვალუტასთან მიმართებაში. მაგალითად, ყველა შემქმნელმა გარკვეულწილად იცის რას აკეთებს თითოეული მათგანი. ადმინისტრატორებს აქვთ სრული კონტროლი იმაზე, თუ ვინ რა შეუძლია გააკეთოს და CCSV– ების ადმინისტრირება გაცილებით ადვილია, ვიდრე ადგილობრივი კლიენტების ადგილობრივი მონაცემთა ბაზების ფუნქციონირება.

ამის მიუხედავად, ამ მიდგომას სერიოზული უარყოფითი მხარეც აქვს. ყველაზე აშკარა მინუსი არის მარცხის ერთი წერტილი, რომელსაც წარმოადგენს ცენტრალიზებული სერვერი. თუ ეს სერვერი ერთი საათის განმავლობაში ვერ მოხერხდება, ამ დროის განმავლობაში ვერავინ შეძლებს ვერსიის კონტროლის გამოყენებას იმ ცვლილებების შესანახად, რომლებზეც მუშაობს, და ვერავინ შეძლებს ამ ცვლილებების გაზიარებას სხვა დეველოპერებთან. თუ მყარი დისკი, რომელზედაც ინახება ცენტრალური მონაცემთა ბაზა, არის დაზიანებული და არ არის დროული სარეზერვო საშუალებები, თქვენ ყველაფერს დაკარგავთ - პროექტის მთელ ისტორიას, არ ითვლიან საცავის ცალკეულ სურათებს, რომლებიც ინახება დეველოპერების ადგილობრივ აპარატებზე. ადგილობრივი მძიმე ვალუტა იმავე პრობლემას განიცდის - როდესაც პროექტის მთელი ისტორია ერთ ადგილზეა, თქვენ რისკავთ ყველაფერს.

დეცენტრალიზებული ვერსიის მართვის სისტემები

ეს ხდება იმ შემთხვევაში, როდესაც მოქმედებს დეცენტრალიზებული ვერსიის კონტროლის სისტემები (DSCWs). DSCV– ში (მაგალითად, Git, Mercurial, Bazaar ან Darcs), კლიენტები არა მხოლოდ ყველა ფაილის (ვიდეოს მდგომარეობის გარკვეულ მომენტში) ჩამოტვირთვის ნახატი (დროულად კონკრეტულ მომენტში): ამ შემთხვევაში, თუ რომელიმე სერვერი, რომლის მეშვეობითაც დეველოპერებმა მონაცემები გაცვალეს, კვდება, ნებისმიერი კლიენტის საცავი შეიძლება კოპირებული იქნას სხვა სერვერზე, რომ გააგრძელოს მუშაობა. საცავის თითოეული ასლი არის ყველა მონაცემის სრული სარეზერვო საშუალება.

სურათი 3. დეცენტრალიზებული ვერსიის კონტროლი.

უფრო მეტიც, ბევრ DSCW- ს შეუძლია ერთდროულად ურთიერთობა რამდენიმე დისტანციურ საცავთან, ასე რომ თქვენ შეგიძლიათ იმუშაოთ ხალხის სხვადასხვა ჯგუფთან, ერთსა და იმავე დროს სხვადასხვა მიდგომების გამოყენებით. ეს საშუალებას გაძლევთ მიმართოთ განვითარების რამდენიმე მიდგომას, მაგალითად, იერარქიული მოდელები, რაც ცენტრალიზებულ სისტემებში სრულიად შეუძლებელია.

ახლახან დამჭირდა გიტის საფუძვლების სწავლება ჩემს რამდენიმე თანამშრომელს, რომლებიც მხოლოდ პროგრამირებას სწავლობენ და ცდილობენ მუშაობას. დამწყებთათვის სტატიების ინტერნეტში მოსაძებნის შემდეგ, მივხვდი იმ ფაქტს, რომ მათი უმეტესობა იმაშია, თუ როგორ უნდა გამოიყენოთ კონსოლი Git ან მისი აუცილებლობისა და უპირატესობის შესახებ სხვა მსგავსი სისტემების შესახებ. დამწყები, როგორც წესი, არ არის ძალიან ძლიერი ამ ყველაფერ საკითხში. მე მჯერა, რომ მას, დამწყებთათვის, არ სჭირდება ამ ყველაფრის ცოდნა. ყოველივე ამის შემდეგ, თქვენ შეგიძლიათ გამოიყენოთ Git თქვენი პროექტებისთვის და ისწავლეთ ყველა მისი ხიბლი პროგრამირების შესწავლის პარალელურად. მაგრამმე გირჩევთ რომ გამოიყენოთ ეს სტატია, როგორც ფაქტის დამდგენი სტატია და მომავალში შეიტყოთ უფრო მეტი Git- ის შესახებ..

ზოგადად, კატის სტატიის ქვეშ, როგორც გამოყენებაSmartGit და BitBucket   შეგიძლიათ გააუმჯობესოთ თქვენი ცხოვრება, როგორც ახალბედა დეველოპერი.

მ სკარლეტის გეგმა, რას გავაკეთებთ:

  1. საცავის შექმნა Bitbucket- ზე.
  2. საცავის კლონირება (მისი დამატება SmartGit).
  3. ვალდებულებების შექმნა.
  4. ცვლილებების გაუქმება.
  5. ფილიალების შექმნა.
  6. ფილიალების დისტანციური საცავისკენ უბიძგებს (ატვირთეთ ფილიალები დისტანციურ სერვერზე).
  7. ფილიალების შერწყმა.

წავიდეთ. საცავის შექმნა ძალიან მარტივი ამოცანაა. ამისათვის BitBucket გამოვიყენებთ, ასე რომ თქვენ გჭირდებათ ანგარიში. რეგისტრაციის შემდეგ დააჭირეთ ღილაკს "შექმნა" და შეავსეთ საჭირო ველები. დაასახელეთ საცავი SmartGit– ის გამოყენებით. აიღეთ ბმული ჩვენს საცავთან.

ახლა გაუშვით SmartGit, შეარჩიეთ "პროექტი" - "კლონი" (ან Ctrl + Alt + O) და შეავსეთ საჭირო ველები:

სისტემა ითხოვს თქვენს მომხმარებლის სახელი და პაროლს Bitbucket- დან:


შემდეგ ფანჯარაში, შესაძლებელია კლონირების ორი ვარიანტი: „ჩართეთ ქვემოდულები“ \u200b\u200bდა „მოიყვანეთ ყველა თავი და წარწერა“. Git საშუალებას აძლევს ცალკეული განაცხადის მოდულების შენახვას სხვადასხვა საცავებში. თუ შეამოწმებთ "ჩართეთ ქვემოდულები" პარამეტრს, SmartGit ავტომატურად დატვირთავს ყველა მოდულს. თუ შემოწმებულია "ყველა უფროსისა და წარწერის" ვარიანტი, მაშინ SmartGit პროექტის საქაღალდის შექმნის შემდეგ ჩამოტვირთავთ ყველა ფილიალს და თეგს ამ საცავისთვის:

შემდეგი ფანჯარა არის პროექტის სახელწოდება SmartGit:

თუ თქვენ დააკონტროლეთ ცარიელი საცავი (როგორც ამ სტატიაში), ნახავთ შემდეგ ფანჯარას:

წინ წადი. მოდით შევქმნათ ვალდებულება. რა არის ვალდებულება? ეს ცვლილებებს ახდენს. თითოეულ დანაშაულს "ახსოვს" რა შეიცვალეთ და ნებისმიერ დროს შეგიძლიათ აღადგინოთ ფაილების წინა მდგომარეობა. გირჩევთ, ყოველი მნიშვნელოვანი ცვლილების შემდეგ შეასრულოთ ვალდებულება, მაგალითად, შეცდომის დაფიქსირება ფუნქციაში. ვალდებულების შესაქმნელად, თქვენ უნდა შეცვალოთ რაიმე პროექტი. დაამატეთ რამდენიმე ფაილი პროექტის საქაღალდეში:

ახლა ნახავთ ჩვენს პროექტში განხორციელებულ ცვლილებებს SmartGit– ში:

შეარჩიეთ ორივე ფაილი და დააჭირეთ "სცენა" და შემდეგ "ჩადება". რატომ დააჭირეთ სცენა? ეტაპი ღილაკს დაამატეთ არჩეული ფაილები მიმდინარე ინდექსში. თუ გსურთ შექმნათ ჩადება ორი ფაილისთვის, მაგრამ შეიცვალა, სავარაუდოდ, როგორც 5, უბრალოდ შეარჩიეთ ეს ორი ფაილი, დააჭირეთ ღილაკს "ეტაპი", რომელიც დაამატებთ მათ ინდექსს, ხოლო "ჩადენის" შემდეგ. ამრიგად, მხოლოდ შერჩეული ორი ფაილი იქნება ჩადენილი.

ამის შემდეგ გამოჩნდება ფანჯარა, სადაც დაგჭირდებათ კომენტარის ჩაწერა ვალდებულებასთან დაკავშირებით. ჩვეულებრივ, ისინი წერენ იმას, რაც შეიცვალა, დაამატა, წაიშალა და ა.შ.:

შემდეგ დააჭირეთ ღილაკს ”ვალდებულება”. Commit & Push ღილაკს იგივე აკეთებს, მაგრამ ასევე უბიძგებს (ატვირთავს) დისტანციურ საცავში შესატან ცვლილებებს (ჩვენს შემთხვევაში, Bitbucket). ეს ჯერ არ გააკეთოთ. ჩვენ კიდევ უფრო წინ წავალთ. ქვემოთ, ფილიალების ჩამონათვალში, ჩნდება ადგილობრივი ფილიალი   "ოსტატი". ეს არის განაცხადის კოდი მთავარი ფილიალი. რა ფილიალებია, ცოტა მოგვიანებით გეტყვი. ახლა მოდით რამე გავაკეთოთ ჩვენი პროექტით, შემდეგ კი უკან დავიხიოთ ცვლილებები. მე წაშლის readme.txt ფაილს, დავაფიქსირებ index.php ფაილს და დავამატებ ახალ confic.cfg ფაილს:

ახლა შეცვალეთ ცვლილება ჩადენის შემდეგ. მოდით წავიდეთ ლოგში:

ჩვენ შევარჩევთ იმ ვალდებულებას, რომლის გადაღებაც გვინდა და დააჭირეთ "გადატვირთვა":

შემდეგ ფანჯარაში გვთავაზობენ აირჩიონ რომელი ”გადატვირთვის” გაკეთება გვინდა:

აგიხსნით. შეგახსენებთ, რომ ჩადენის შექმნისას, პირველ რიგში, ფაილებს დაამატებთ ინდექსში (ეტაპი). ეს საშუალებას გაძლევთ ჩაწეროთ მხოლოდ ინდექსური ფაილები. რბილი გადატვირთვა მხოლოდ აღდგება. ინდექსი და ფიზიკური ფაილების ცვლილებები რჩება. შერეული გადატვირთვა მუშაობს ისევე, როგორც პროგრამული უზრუნველყოფა, მაგრამ ის ასევე წაშლის ფაილების ინდექსს. მყარი გადატვირთვის წაშლა ფაილებში ჩადენილი ცვლილებები, ინდექსი და ფიზიკური ცვლილებები. გამოიყენეთ ფრთხილად მყარი გადატვირთვაეს უნებურად არ ამოიღებდა ჭარბი.

მე ძალიან მძიმე გადატვირთვა გავაკეთე სიცხადისთვის:

როგორც ხედავთ, ფაილებში ყველა ცვლილება გაქრა, უფრო სწორად, ყველაფერი დაუბრუნდა პირველ ვალდებულებას.

ახლა ცოტა რამ ფილიალების შექმნის შესახებ. რატომ არის ისინი საერთოდ საჭირო? ფილიალი საშუალებას გაძლევთ შეინახოთ კოდის არსებული მდგომარეობა და ექსპერიმენტი. მაგალითად, თქვენ წერთ ახალ მოდულს. ლოგიკურია ამის გაკეთება ცალკეულ ფილიალში. ავტორიტეტი ურეკავს და ამბობს, რომ პროექტში არის ხარვეზი და სასწრაფოდ უნდა გამოსწორდეს, მაგრამ თქვენი მოდული არ დაემატა. როგორ შევსება გატეხილი ფაილები? უბრალოდ გადახვიდეთ სამუშაო ფილიალში მოდულის გარეშე, შეასწორეთ შეცდომა და ატვირთეთ ფაილები სერვერზე. და როდესაც "საფრთხე" დასრულდა - გააგრძელეთ მოდულაზე მუშაობა. და ეს ფილიალების სარგებლიანობის მრავალი მაგალითია.

შევეცადოთ შევქმნათ საკუთარი ფილიალი. ჩვენ უკვე გვაქვს ერთი, ეს არის სამაგისტრო. ის იქმნება ავტომატურად (თუ არ არსებობს), როდესაც თქვენ პირველი ჩადენის გაკეთება. შექმენით სხვა ფილიალი და დაასახელეთ "new_future1". დააჭირეთ F7 ან დააჭირეთ ქვემოთ მოცემულ ღილაკს "ფილიალები" ჩანართზე "ადგილობრივი ფილიალები" და ჩამოსაშლელ სიაში აირჩიეთ "ფილიალის დამატება":

დააჭირეთ ღილაკს "ფილიალის დამატება და შეცვლა" დაუყოვნებლივ გადასვლის შექმნილ ფილიალში. ახლა თქვენ შეგიძლიათ შექმნათ ახალი ვალდებულებები, შეცვალოთ ფაილები და არ ინერვიულოთ. ვინაიდან თქვენ ყოველთვის გყავთ სამაგისტრო ფილიალი, რომლის დაბრუნებასაც შეძლებთ. ფილიალის შეცვლისას, Git ცვლის ადგილობრივ ფაილებს ამ ფილიალში. ანუ, თუ შექმნით ახალი ფილიალი   შეცვალეთ რაღაც index.php ფაილში და შემდეგ გადადით მასტერ ფილიალზე, შემდეგ კი თქვენ მიერ განხორციელებული ყველა ცვლილება წაიშლება. თუ თქვენ გადახვედით შექმნილ ფილიალს, ცვლილებები დაბრუნდება.

ჯერჯერობით, ადგილობრივად ვმუშაობდით. შევეცადოთ ატვირთოთ ჩვენი ნამუშევრების სერვერები. მოდით შევქმნათ რამდენიმე ვალდებულება new_future1 ფილიალში. იმ შემთხვევაში, თუ საცავი ცარიელია და ის ცარიელია, რადგან ეს ჩვენ რამდენიმე ხნის წინ შევქმენით და სერვერზე არაფერი ატვირთავთ, Bitbucket დაავალებს მთავარ ფილიალს, რომელიც გადმოწერილი იქნა პირველ მთავარზე. ამიტომ, გადახვიდეთ "სამაგისტრო" ფილიალზე და დააჭირეთ ღილაკს "Push":

შემდეგი, SmartGit სთხოვს თუ არა კონფიგურაციას ფილიალის თვალყურის დევნა (კოპირების მიკვლევა). თვალყურის დევნება საშუალებას გაძლევთ ავტომატურად განაახლოთ შესაბამისი ფილიალები, როდესაც ჩამოტვირთოთ ან გადმოწერეთ კოდის განახლებები. ასე რომ, თავისუფლად დააჭირეთ ღილაკს "კონფიგურაცია":

ახლა გადადით სხვა ფილიალში და იგივე გააკეთეთ. მოდით წავიდეთ Bitbucket- ში და ვნახოთ რა შეიცვალა "ვალდებულებების" განყოფილებაში:

როგორც ხედავთ, ყველაფერი მიიღო დისტანციურ სერვერზე.

ახლა მარილი ტოტები. რატომ არის ეს საჭირო? იგივე მაგალითი მიიღეთ მოდულთან ერთად. ადრე თუ გვიან, თქვენ დაამატებთ მას და მოგიწევთ მოდულის კოდი დაამატოთ მთავარ განაცხადის კოდი. უბრალოდ გაერთიანდება ტოტები. ამისათვის გადახვიდეთ იმ ფილიალში, რომელშიც გსურთ კოდის შერწყმა. ჩვენს შემთხვევაში, ეს ოსტატია. ამის შემდეგ, დააჭირეთ ღილაკს მარჯვენა ფილიალზე, საიდანაც გსურთ შეიტანოთ კოდი და აირჩიეთ "შერწყმა":

ახლა კი რჩება სამაგისტრო ფილიალის ცვლილებების შეტანა სერვერზე. შეავსეთ ცვლილება სერვერზე ისე, როგორც ადრე გავაკეთეთ და მიიღეთ:

ეს ყველაფერი ერთხელ. სურათების გამო, სტატია შესანიშნავი გამოვიდა. დასვით თქვენი პასუხები. დაწერე კითხვები.

VCS საფუძვლები

შესავალი

სანამ რაიმე კონკრეტულ ვერსიაზე კონტროლის სისტემაზე საუბრობთ, უნდა გესმოდეთ რა არის, რა არის ისინი და რატომ გამოჩნდნენ საერთოდ. ეს ლექცია განკუთვნილია ვერსიის კონტროლისა და მართვის სისტემების თავდაპირველი გაცნობისთვის, პირველ რიგში კი გეტყვით ვერსიის კონტროლის ინსტრუმენტების წარმოშობის შესახებ, გეტყვით, რომელი ვერსიის მართვის სისტემები პოპულარულია ახლა და რა არის მათ შორის ძირითადი განსხვავებები.

ვერსიის კონტროლის შესახებ

რა არის ვერსიის კონტროლი და რატომ გჭირდებათ ეს?

ალბათ ღირს დაწყებული ვერსიის კონტროლის სისტემის (SLE) განსაზღვრებით - ეს არის სისტემა, რომელიც აღრიცხავს ცვლილებებს ერთ ან მეტ ფაილში, ასე რომ მომავალში შესაძლებელი გახდება ამ ფაილების გარკვეული ძველი ვერსიების დაბრუნება.

ბოლო დროს, ფაილები საბოლოო შედეგია მრავალი პროფესიისთვის (მაგალითად, წერა, კვლევა და, რა თქმა უნდა, პროგრამული უზრუნველყოფის შემუშავება). ამ ფაილების შემუშავებასა და შენარჩუნებას დიდი დრო და ძალისხმევა სჭირდება და არავის არ სურს დახარჯოს კიდევ უფრო მეტი დრო და ძალისხმევა ნებისმიერი ცვლილების შედეგად დაკარგული მონაცემების აღდგენაზე.

წარმოიდგინეთ, რომ პროგრამისტი ამუშავებს პროექტს, რომელიც შედგება ერთი პატარა ფაილისგან (სხვათა შორის, მაგალითი საკმაოდ რეალურია, არა სინთეზური, რომელიც რეალურ ცხოვრებაში ხვდება). პროექტის პირველი ვერსიის გამოქვეყნების შემდეგ, მას რთული არჩევანის წინაშე დგება: აუცილებელია პირველი ვერსიის მომხმარებლების მიერ დაფიქსირებული პრობლემების დაფიქსირება და, ამავდროულად, წამისათვის რაიმე ახალი შეიმუშაოს. მაშინაც კი, თუ თქვენ უბრალოდ უნდა აღმოიფხვრას პრობლემები, რომელიც წარმოიქმნება, სავარაუდოა, რომ ნებისმიერი ცვლილების შემდეგ პროექტი შეწყვეტს მუშაობას, და თქვენ უნდა დაადგინოთ რა შეიცვალა ისე, რომ უფრო ადვილია პრობლემის ლოკალიზაცია. ასევე მიზანშეწონილია, რომ დაიცვან გარკვეული სახის ჟურნალი ცვლილებებისა და შესწორებების შედეგად, რათა არ მოხდეს იგივე სამუშაო რამდენჯერმე.

უმარტივეს შემთხვევაში, ზემოთ ჩამოთვლილი პრობლემის გადაჭრა შესაძლებელია ფაილების რამდენიმე ასლის შენახვის გზით, მაგალითად, ერთი პროექტის პირველ ვერსიაში შეცდომების გამოსწორებისთვის, ხოლო მეორე ახალი ცვლილებებისთვის. იმის გამო, რომ ცვლილებები, როგორც წესი, ფაილის ზომასთან შედარებით არ არის ძალიან დიდი, თქვენ შეგიძლიათ შეინახოთ მხოლოდ შეცვლილი ხაზები, ხოლო სასარგებლო პროგრამის გამოყენებით შეინახოთ და მოგვიანებით მათი შერწყმა გამოიყენოთ პატჩის კომუნალური გამოყენებით. რა მოხდება, თუ პროექტი რამდენიმე ათასი ფაილისგან შედგება და მასზე ასამდე ადამიანი მუშაობს? თუ ამ შემთხვევაში იყენებთ მეთოდს ფაილების ცალკეული ასლების შესანახად (ან თუნდაც მხოლოდ ცვლილებები), მაშინ პროექტი ძალიან სწრაფად ჩერდება. შემდეგ ლექციებში, მაგალითად, მე გამოვიყენებ პროგრამების წყაროების კოდებს, მაგრამ სინამდვილეში, თითქმის ნებისმიერი ტიპის ფაილები შეიძლება განთავსდეს ვერსიის კონტროლის ქვეშ.

თუ თქვენ გრაფიკული ან ვებ დიზაინერი ხართ და გსურთ შეინახოთ გამოსახულების ან განლაგების თითოეული ვერსია - და ალბათ ეს გსურთ - მაშინ ვერსიის მართვის სისტემის გამოყენება ძალიან გონივრული გადაწყვეტილება იქნება. SLE შესაძლებელს გახდის ინდივიდუალური ფაილების დაბრუნებას წინა მდგომარეობაში, დააბრუნოს მთელი პროექტი თავის წინა მდგომარეობაში, დაათვალიეროს ცვლილებები, რომლებიც მოხდეს დროთა განმავლობაში, დაადგინეთ, თუ ვინ შეიტანეს ცვლილებები მოდულში, რომელიც მოულოდნელად შეჩერდა, ვინ დაუშვა შეცდომა, როდის და ა.შ. ზოგადად, თუ SLE– ს გამოყენებით, ყველაფერს ანგრევთ ან ფაილებს კარგავთ, ყველაფერი ადვილად აღდგება. გარდა ამისა, ოვერჰედის ყველაფერი, რაც მიიღებთ, ძალიან მცირე იქნება.

ადგილობრივი ვერსიის მართვის სისტემები

როგორც უკვე აღვნიშნეთ, ადგილობრივი SUV- ს ერთ-ერთი მაგალითი უკიდურესად მარტივია: ბევრს ურჩევნია გააკონტროლოს ვერსიები, უბრალოდ ფაილების სხვა დირექტორიაში კოპირებით (კოპირებით) ეს მიდგომა ძალზე ხშირია, რადგან ის მარტივია, მაგრამ ის ხშირად ვერ ხერხდება. ძალიან ადვილია დაივიწყოთ, რომ თქვენ არასწორი დირექტორია და შემთხვევით შეცვალეთ არასწორი ფაილი, ან დააკოპირეთ ფაილები არასწორ ადგილზე და წაშალეთ საჭირო ფაილები. ამ პრობლემის გადასაჭრელად, პროგრამისტებმა დიდი ხანია შეიმუშავეს ადგილობრივი მყარი ვალუტა მარტივი მონაცემთა ბაზით, რომელიც ინახავს ყველა ცვლილებას საჭირო ფაილებში.

ამ ტიპის ერთ-ერთი ყველაზე პოპულარული მყარი ვალუტაა RCS (Revision Control System), რომელიც ჯერ კიდევ ბევრ კომპიუტერზეა დამონტაჟებული. თანამედროვე Mac OS X- ზეც კი, rcs დამონტაჟებულია დეველოპერული ინსტრუმენტებით. RCS შემუშავდა 1980-იანი წლების დასაწყისში ვალტერ F. ტიჩის მიერ. სისტემა საშუალებას გაძლევთ შეინახოთ მხოლოდ ერთი ფაილის ვერსიები, ასე რომ თქვენ უნდა მართოთ მრავალი ფაილი ხელით. სისტემის კონტროლის ქვეშ მყოფი თითოეული ფაილისთვის, ვერსიის ინფორმაცია ინახება სპეციალურ ფაილში იმ ორიგინალის ფაილის სახელით, რომელსაც ბოლოში ემატება სიმბოლოები ", v". მაგალითად, file.txt– სთვის, ვერსიები ინახება ფაილში.txt, v. ეს პროგრამა დაფუძნებულია პაჩების ნაკრებებთან მუშაობის დაწყებას წყვილ ვერსიებს შორის (პატჩი არის ფაილი, რომელიც აღწერს სხვაობას ფაილებს შორის). ეს საშუალებას გაძლევთ ხელახლა შექმნათ ნებისმიერი ფაილი ნებისმიერ დროს, თანმიმდევრულად იყენებთ პატჩებს. სისტემა იყენებს Diff სასარგებლო პროგრამას ვერსიების შესანახად. მიუხედავად იმისა, რომ RCS აკმაყოფილებს ვერსიის კონტროლის სისტემის მინიმალურ მოთხოვნებს, მას აქვს შემდეგი ძირითადი უარყოფითი მხარეები, რაც ასევე სტიმული იყო შემდეგი სისტემის შექმნის სტიმულირებისთვის:

  • იმუშავეთ მხოლოდ ერთ ფაილთან, თითოეული ფაილი უნდა იყოს კონტროლირება ცალკე;
  • სისტემასთან რამდენიმე მომხმარებლის ერთდროული მუშაობისთვის არასასურველი მექანიზმი, საცავი უბრალოდ დაბლოკილია მანამ, სანამ მომხმარებელი ბლოკავს მას განბლოკვას;
  • არავინ არ გაათავისუფლებს სარეზერვო ასპარეზს, თქვენ რისკავთ ყველაფერს.

ცენტრალიზებული ვერსიის მართვის სისტემები

შემდეგი მთავარი პრობლემა სხვა კომპიუტერებზე დეველოპერებთან თანამშრომლობის საჭიროება იყო. მისი გადასაჭრელად, შეიქმნა ცენტრალიზებული ვერსიის მართვის სისტემები (CSCV). ასეთ სისტემებში, მაგალითად CVS, Subversion და Perforce, არის ცენტრალური სერვერი, რომელზეც ყველა ფაილი ინახება ვერსიის კონტროლის ქვეშ, და არაერთი კლიენტი, რომლებიც მისგან იღებენ ფაილების ასლებს. მრავალი წლის განმავლობაში ეს სტანდარტი იყო ვერსიის მართვის სისტემებისთვის.

ამ მიდგომას ბევრი უპირატესობა აქვს, განსაკუთრებით ადგილობრივ მძიმე ვალუტასთან მიმართებაში. მაგალითად, ყველამ იცის, ვინ და რა არის პროექტში ჩართული. ადმინისტრატორებს აქვთ მკაფიო კონტროლი იმაზე, თუ ვინ და რა შეუძლია გააკეთოს და, რა თქმა უნდა, CSCV ადმინისტრირება ბევრად უფრო ადვილია, ვიდრე თითოეულ კლიენტზე მდებარე ადგილობრივი მონაცემთა ბაზა. ამასთან, ამ მიდგომით, არსებობს რამდენიმე სერიოზული ნაკლი. ყველაზე აშკარაა, რომ ცენტრალიზებული სერვერი არის დაუცველობა მთელ სისტემაში. თუ სერვერი ერთ საათში ითიშება, მაშინ ერთი საათის განმავლობაში დეველოპერები ვერ ურთიერთობენ და ვერავინ შეძლებს დაზოგვას ახალი ვერსია   მათი მუშაობა. თუ ცენტრალური მონაცემთა ბაზის მქონე დისკი დაზიანებულია და არა სარეზერვო, თქვენ დაკარგავთ აბსოლუტურად ყველაფერს - პროექტის მთელ ისტორიას, გარდა ალბათ რამდენიმე სამუშაო ვერსიის გარდა, რომელიც შენახული იყო მომხმარებლების სამუშაო აპარატებზე.

CVS

CVS (Concurrent Versions System) კვლავ ყველაზე ფართოდ გამოიყენება სისტემა, მაგრამ ის სწრაფად კარგავს პოპულარობას ხარვეზების გამო, რომელზეც ქვემოთ ვისაუბრებ. დიკ გრუნმა CVS შეიმუშავა 1980-იანი წლების შუა პერიოდში. ინდივიდუალური ფაილების შესანახად, CVS (ისევე როგორც RCS) იყენებს ფაილებს RCS ფორმატში, მაგრამ საშუალებას გაძლევთ მართოთ ფაილების ჯგუფები, რომლებიც მდებარეობს დირექტორიაში. CVS ასევე იყენებს კლიენტ-სერვერის არქიტექტურას, რომელშიც ყველა ვერსიის ინფორმაცია ინახება სერვერზე. კლიენტ-სერვერის არქიტექტურის გამოყენებით საშუალებას გაძლევთ CVS გამოიყენოთ გეოგრაფიულად განაწილებული მომხმარებელი გუნდებიც კი, სადაც თითოეულ მომხმარებელს აქვს საკუთარი სამუშაო დირექტორია პროექტის ასლის საშუალებით. როგორც სახელი გულისხმობს, მომხმარებლებს შეუძლიათ სისტემის გაზიარება.

იგივე ფაილის შეცვლისას შესაძლო კონფლიქტები წყდება იმით, რომ სისტემა საშუალებას გაძლევთ შეიტანოთ ცვლილებები მხოლოდ ფაილის უახლეს ვერსიაში. ამიტომ, ყოველთვის არის რეკომენდებული ფაილების სამუშაო ასლის განახლება შესაძლო კონფლიქტური ცვლილებების შემთხვევაში, თქვენი ცვლილებების ატვირთვის წინ. განახლებისას, სისტემა ავტომატურად ახდენს სამუშაო ასლის ცვლილებებს ცვლილებებში და მხოლოდ ფაილის ერთ-ერთ ადგილას კონფლიქტური ცვლილებების შემთხვევაში მოითხოვს კონფლიქტის ადგილმდებარეობის სახელმძღვანელო კორექტირებას.

CVS ასევე საშუალებას გაძლევთ იხელმძღვანელოთ პროექტის განვითარების რამდენიმე ხაზი განვითარების ფილიალების გამოყენებით. ამრიგად, როგორც ზემოთ აღვნიშნეთ, შეცდომების გამოსწორება შეგიძლიათ პროექტის პირველ ვერსიაში და ერთდროულად განავითაროთ ახალი ფუნქციონირება.

გამოყენებული იქნა CVS ბევრი   პროექტები, მაგრამ რა თქმა უნდა, ეს არ ყოფილა ხარვეზების გარეშე, რამაც მოგვიანებით განაპირობა შემდეგი სისტემის განხილვა. განვიხილოთ ძირითადი უარყოფითი მხარეები:

  • ვინაიდან ვერსიები ინახება RCS ფაილებში, შეუძლებელია დირექტორია ვერსიების შენახვა. სტანდარტული გზა   ამ დაბრკოლების ირგვლივ არის ფაილის შენახვა (მაგალითად, README.txt) დირექტორიაში;
  • ფაილების გადატანა ან გადარქმევა არ ექვემდებარება ვერსიის კონტროლს. ამის გაკეთების სტანდარტული გზაა ჯერ ფაილის კოპირება, ძველი წაშლა cvs remove ბრძანების გამოყენებით, შემდეგ კი მისი ახალი სახელით დაამატეთ cvs add ბრძანება;
დამორჩილება

დივერსია (SVN) განვითარდა 2000 წელს CollabNet– ის ინიციატივით. SVN თავდაპირველად შეიქმნა, როგორც "საუკეთესო CVS" და დეველოპერების მთავარი ამოცანა იყო მსგავსი ინტერფეისის შენარჩუნებისას CVS- ის დიზაინში შეცდომების გამოსწორება. SVN, როგორც CVS, იყენებს კლიენტ-სერვერის არქიტექტურას. ყველაზე მნიშვნელოვანი ცვლილებები CVS– სთან შედარებით:

  • ატომური ცვლილებები (ჩადენა). თუ ვალდებულების დამუშავება შეწყდა, ცვლილებები არ განხორციელდება.
  • ფაილების გადარქმევა, კოპირება და გადაადგილება ზოგავს ცვლილებების მთელ ისტორიას.
  • დირექტორიები, სიმბოლური ბმულები და მეტა მონაცემები ექვემდებარება ვერსიის კონტროლს.
  • ორობითი ფაილებისთვის ეფექტური ცვლილების საცავი.

განაწილებული ვერსიის მართვის სისტემები

ამ სიტუაციაში, განაწილებული ვერსიის მართვის სისტემები (RSKV) ამოქმედდება. ისეთ სისტემებზე, როგორიცაა Git, Mercurial, Bazaar ან Darcs, კლიენტები არა მხოლოდ ჩამოტვირთებენ ფაილების უახლეს ვერსიებს, არამედ მთლიანად დააკოპირებენ მთლიან საცავში. ამიტომ, იმ შემთხვევაში, როდესაც სერვერზე, რომლის მეშვეობითაც მუშაობა აპირებდა კვდება, ნებისმიერი კლიენტის საცავი შეიძლება გადაწერილი იქნას სერვერზე, მონაცემთა ბაზის აღდგენის მიზნით. ყოველ ჯერზე, როდესაც კლიენტი შეარჩევს ფაილების უახლეს ვერსიას, იგი ქმნის ყველა მონაცემის სრულ ასლს თავისთვის.

გარდა ამისა, ამ სისტემების უმეტესობაში შეგიძლიათ იმუშაოთ რამდენიმე დისტანციურ საცავთან, ასე რომ თქვენ შეგიძლიათ ერთდროულად განსხვავებულად იმუშაოთ ადამიანების სხვადასხვა ჯგუფთან ერთსა და იმავე პროექტის ფარგლებში. ასე რომ, ერთ პროექტში შესაძლებელია რამდენიმე ტიპის სამუშაო პროცესის ერთდროულად ჩატარება, რაც შეუძლებელია ცენტრალიზებულ სისტემებში.

რატომ გვჭირდება განაწილებული სისტემები?

როგორც სახელი გულისხმობს, განაწილებული სისტემების ერთ-ერთი მთავარი იდეა არის ვერსიების მკაფიოდ განსაზღვრული ცენტრალური საცავის არარსებობა - საცავი. განაწილებული სისტემების შემთხვევაში, ვერსიების სერია შეიძლება ნაწილობრივ ან ნაწილობრივ გადანაწილდეს სხვადასხვა საცავებს შორის, მათ შორის დისტანციურებს შორის. ასეთი მოდელი იდეალურად ჯდება განაწილებული გუნდების მუშაობასთან, მაგალითად, მსოფლიოში განაწილებული განვითარების ჯგუფი, რომელიც ერთ პროექტზე მუშაობს წყაროს კოდი. ასეთი გუნდის დეველოპერს შეუძლია ჩამოტვირთოთ ყველა ვერსიის ინფორმაცია და შემდეგ მხოლოდ იმუშაოს ადგილობრივ აპარატზე. მუშაობის ერთ – ერთი ეტაპის შედეგის მიღწევისთანავე, ცვლილებები შეიძლება აიტვირთოთ ერთ ცენტრალურ საცავში ან გამოქვეყნდეს დეველოპერის ვებსაიტზე ან საფოსტო გზავნილის სიაში სანახავად. პროექტის სხვა მონაწილეებს, თავის მხრივ, შეეძლება განაახლონ ვერსიის საცავის ასლი ახალი ცვლილებებით, ან შეეცადონ გამოქვეყნებული ცვლილებები ცალკეულ, ტესტის განვითარების ფილიალში. სამწუხაროდ, კარგი საპროექტო ორგანიზაციის გარეშე, ერთი ცენტრალური საცავის არარსებობა შეიძლება იყოს განაწილებული სისტემების მინუსი. თუ ცენტრალიზებული სისტემების შემთხვევაში ყოველთვის არის ერთი საერთო საცავი, საიდანაც შეგიძლიათ მიიღოთ პროექტის უახლესი ვერსია, მაშინ განაწილებული სისტემების შემთხვევაში, თქვენ ორგანიზაციულად უნდა გადაწყვიტოთ, რომელია ფილიალი მთავარი. რატომ შეიძლება საინტერესო იყოს განაწილებული ვერსიის კონტროლის სისტემა მისთვის, ვინც უკვე იყენებს ცენტრალიზებულ სისტემას - მაგალითად Subversion? ნებისმიერი სამუშაო გულისხმობს გადაწყვეტილების მიღებას და უმეტეს შემთხვევაში აუცილებელია სხვადასხვა ვარიანტების მოსინჯვა: ვერსიის კონტროლის სისტემებთან მუშაობისას, განვითარების ფილიალებს იყენებენ სხვადასხვა ვარიანტების მოსაზრებისთვის და დიდ ცვლილებებზე მუშაობას. მიუხედავად იმისა, რომ ეს არის საკმაოდ ბუნებრივი კონცეფცია, მისი გამოყენება Subversion– ში ადვილი არ არის. უფრო მეტიც, ყველაფერი უფრო რთული ხდება იმ შემთხვევაში, როდესაც მრავალჯერადი ზედიზედ მიერთება ხდება ერთი ფილიალიდან მეორეზე - ამ შემთხვევაში, აუცილებელია ზუსტი მითითება თითოეული ცვლილების საწყის და საბოლოო ვერსიებზე, რათა თავიდან აიცილოთ კონფლიქტები და შეცდომები. განაწილებული ვერსიის მართვის სისტემებისთვის, განვითარების ფილიალები ერთ-ერთი ფუნდამენტური კონცეფციაა - უმეტეს შემთხვევაში, ვერსიის მაღაზიის თითოეული ასლი განვითარების ფილიალია. ამრიგად, განაწილებული სისტემების შემთხვევაში ერთი ფილიალიდან მეორეზე ცვლილებების შეთავსების მექანიზმი ერთ – ერთი მთავარია, რაც მომხმარებლებს სისტემის გამოყენების დროს ნაკლებ ძალისხმევას აძლევს.

პოპულარული განაწილებული SUV მოკლე აღწერა

  • Git არის განაწილებული ვერსიის კონტროლის სისტემა, რომელიც შემუშავებულია ლინუს ტორვალდის მიერ. თავდაპირველად, Git გამიზნულად იყო გამოყენებული ლინუქსის ბირთვის განვითარების პროცესში, მაგრამ მოგვიანებით იგი გამოყენებულ იქნა ბევრ სხვა პროექტში - მაგალითად, X.org და Ruby on Rails, Drupal. ამჟამად Git არის ყველაზე სწრაფი განაწილებული სისტემა ყველაზე კომპაქტური გადასინჯვის მაღაზიის გამოყენებით. ამავე დროს, მომხმარებლების გადართვისთვის, მაგალითად, Subversion– დან, Git ინტერფეისი შეიძლება რთული ჩანდეს;
  • Mercurial არის დისტრიბუტიული სისტემა, რომელიც წერია პითონში, სადაც რამდენიმე გაფართოებაა C. Mercurial– ის გამოყენებით მიღებული პროექტებიდან, შეგიძლიათ დაასახელოთ ისეთი როგორიცაა Mozilla და MoinMoin.
  • Bazaar არის განვითარების სისტემა, რომელსაც მხარს უჭერს Canonical, რომელიც ცნობილია Ubuntu– ს განაწილებით და საიტზე https://launchpad.net/. სისტემა ძირითადად დაწერილია პითონში და გამოიყენება ისეთი პროექტებით, როგორიცაა, მაგალითად, MySQL.
  • კოდევი - პითონის დაფუძნებული განაწილებული სისტემა ინოვაციური შერწყმის ცვლილების ალგორითმის გამოყენებით. სისტემა გამოიყენება, მაგალითად, ორიგინალური BitTorrent კლიენტის შემუშავებისას.
  • Darcs არის განაწილებული ვერსიის კონტროლის სისტემა, რომელიც წერია ჰასკელში, რომელიც გამოიყენება, მაგალითად, Buildbot პროექტის მიერ.
  • მონოტონი - C ++ -ში დაწერილი სისტემა და SQLite- ის გამოყენებით, როგორც შესწორებების საცავი.