32-წუთიანი სამუშაო სესია იმაზე, თუ რას აკეთებს Git სინამდვილეში კულისებში — სნეპშოტების მოდელი და კომიტების გრაფი, სამი არე, ბრენჩინგი და მერჯი, რებეისის კომპრომისები, თანამშრომლობა remote-ებთან და pull request-ებით, თქვენს გუნდზე მორგებული სამუშაო პროცესი და როგორ გააუქმოთ თითქმის ყველაფერი უსაფრთხოდ.
Git-თან დაკავშირებული დაბნეულობის უმეტესობა არასწორი წარმოდგენიდან მოდის. Git არ ინახავს ფაილების ცვლილებების ან დიფების სიას. ის ინახავს თქვენი პროექტის სრული სნეპშოტების სერიას, სადაც თითოეული უკან, იმ სნეპშოტზე მიუთითებს, საიდანაც წარმოიშვა. სწორად წარმოიდგინეთ ეს ერთი სურათი და თითქმის ყველა ბრძანება აღარ მოგეჩვენებათ ჯადოქრობად.
C3 (HEAD) მიუთითებს თავის მშობელ C2-ზე, რომელიც C1-ზე მიუთითებს. ყოველი კომიტი ასევე ინახავს პროექტის ხის სრულ სნეპშოტს.
კომიტი → ხე → ბლობები. უცვლელი ფაილები იმავე ბლობს იყენებენ, ამიტომ სნეპშოტი იაფია.
მაჩვენებელი კომიტზე (ჩვეულებრივ ბრენჩის გავლით), რომელზეც თქვენი შემდეგი კომიტი დაშენდება. „Detached HEAD“ უბრალოდ ნიშნავს, რომ ის პირდაპირ კომიტზე მიუთითებს და არა ბრენჩზე.
ბრენჩი, მაგალითად main, უბრალოდ მოძრავი იარლიყია, რომელიც ერთ კომიტზე მიუთითებს. კომიტის გაკეთება ამ იარლიყს წინ წასწევს — მთელი მექანიზმი ეს არის.
ისტორია არის მიმართული აციკლური გრაფი — კომიტები მშობლის წიბოებით, ციკლების გარეშე. მერჯი კომიტს ორ მშობელს აძლევს; მხოლოდ ასე იტოტება და ისევ ერთდება გრაფი.
კომიტი თქვენს ფაილებს პირდაპირ არ იღებს სნეპშოტად. შუაში განზრახ დგას ერთი ნაბიჯი — სტეიჯინგის არე — რომელიც საშუალებას გაძლევთ ზუსტად აირჩიოთ, რა მოხვდება შემდეგ კომიტში. ამ სამი ადგილის გაგება არის განსხვავება იმას შორის, Git-ს ებრძვით თუ მართავთ.
git add ფაილის მიმდინარე შიგთავსს სტეიჯინგში აკოპირებს; git commit კი ყველაფერს, რაც სტეიჯინგშია, ახალ სნეპშოტად ბეჭდავს. ფაილები, რომლებიც შეასწორეთ, მაგრამ სტეიჯინგში არ გადაიტანეთ, უბრალოდ გარეთ რჩება.add ამზადებს მონახაზს; commit ბეჭდავს მას; restore კი სუფთა ასლს უკან აბრუნებს.
git add -p ფაილის ნაწილებს (ჰანკებს) გადაიტანს სტეიჯინგში, ასე რომ ერთი არეული სამუშაო სესია რამდენიმე მიზანმიმართულ კომიტად იქცევა.git status ყოველთვის აჩვენებს დაყოფას: სტეიჯინგში, შეცვლილი მაგრამ სტეიჯინგის გარეშე, და აღურიცხავი. წაიკითხეთ ის ყოველი კომიტის წინ.კომიტში მხოლოდ სტეიჯინგში გადატანილი ჯგუფი ხვდება. დანარჩენი უცვლელად რჩება თქვენს სამუშაო ხეში.
რადგან ბრენჩი უბრალოდ კომიტზე მაჩვენებელია, მისი შექმნა მყისიერია და არაფერი ღირს. მუშაობთ ბრენჩზე, შემდეგ მერჯავთ უკან, რომ მისი კომიტები ისტორიის სხვა ხაზში გადაიტანოთ. ეს შეერთება ორნაირად შეიძლება მოხდეს.
git switch -c feature ქმნის ახალ იარლიყს თქვენს მიმდინარე კომიტზე და HEAD-ს მასზე გადაიტანს. ახალი კომიტები ამ იარლიყს წინ სწევს, ხოლო main ადგილზე რჩება.თუ main არ დაძრულა, Git უბრალოდ მის იარლიყს ბრენჩის წვერომდე წასწევს. ისტორია წრფივი რჩება.
როცა ორივე ბრენჩს ახალი კომიტები აქვს, Git ქმნის მერჯ-კომიტს M ორი მშობლით, რომ ისინი ერთმანეთს დაუკავშიროს.
კონფლიქტი შეცდომა არ არის — ეს Git-ის თხოვნაა, აირჩიოთ ერთი და იმავე ხაზების ორ ცვლილებას შორის. შეასწორეთ, გადაიტანეთ სტეიჯინგში, დააკომიტეთ.
კონფლიქტი მხოლოდ მაშინ ხდება, როცა ორი ბრენჩი ერთი და იმავე ფაილის ერთსა და იმავე ხაზებს ცვლის. მცირე და ხშირი მერჯები მათ იშვიათსა და პატარას ხდის — სწორედ ეს არის მთელი არგუმენტი 06-ე სექციის სამუშაო პროცესების უკან.
ორივე ერთი ბრენჩის ნამუშევარს მეორეზე გადააქვს. მერჯი აღრიცხავს იმას, რაც სინამდვილეში მოხდა — ორი ხაზი, რომლებიც შეხვდნენ. რებეისი თქვენს კომიტებს ისე გადაწერს, თითქოს უახლესი წვეროდან დაიწყეთ, და სუფთა სწორ ხაზს იძლევა. არცერთი არ არის „სწორი“; ისინი უბრალოდ სხვადასხვა რამეზეა ოპტიმიზებული.
ინახავს ყოველ კომიტს და აღრიცხავს შეერთებას. ისტორია აჩვენებს, რომ ბრენჩი ნამდვილად არსებობდა — უფრო დატვირთული გრაფის ფასად.
A' და B' თქვენი კომიტების ასლებია ახალი ჰეშებით. გრაფი სუფთაა; ორიგინალები კი აღარ არსებობს.
squash მერჯით) main-ში.squash მერჯი ბრენჩის ყველა კომიტს ერთ ახალ კომიტად კუმშავს სამიზნე ბრენჩზე. main-ში თითო ფიჩერზე ერთი მოწესრიგებული ჩანაწერი გრჩებათ, ხოლო ბრენჩის ხმაურიანი შუალედური კომიტები საერთო ისტორიაში საერთოდ არ ხვდება. GitHub-სა და GitLab-ზე სწორედ ამიტომ არის პოპულარული — უბრალოდ გაითვალისწინეთ, რომ ბრენჩის კომიტ-დონის დეტალიზაციას კარგავთ.
Git განაწილებულია, ამიტომ სერვერი განსაკუთრებული არაფერია — ის კიდევ ერთი კლონია, რომელზეც ყველა შეთანხმდა. fetch-ით ჩამოტვირთავთ მის კომიტებს, push-ით ატვირთავთ თქვენსას, ხოლო pull request ის ადგილია, სადაც ადამიანები კოდს ამოწმებენ, სანამ ის საერთო ხაზს შეუერთდება.
origin ჰქვია. თქვენი ლოკალური origin/main read-only სნეპშოტია იმისა, სად იყო სერვერის main ბოლო კავშირის დროს — და არა ცოცხალი ხედი.fetch ჩამოტვირთავს თქვენს სამუშაოს შეუხებლად; pull = fetch + merge; push ატვირთავს თქვენს კომიტებს.
origin/* მაჩვენებლებს, მაგრამ არასოდეს ცვლის თქვენს ბრენჩებს ან ფაილებს — მისი გაშვება ყოველთვის უსაფრთხოა.fetch და შემდეგ merge (ან rebase, თუ --rebase მიუთითეთ). ის ნამდვილად ცვლის თქვენს ბრენჩს, ამიტომ კონფლიქტი შესაძლებელია.main-ს origin/main-თან, რომ Git-მა შეძლოს თქვას „წინ 2, უკან 1“.main-ს მიაღწევს.Git-ის ძრავა ყველგან ერთნაირია; თქვენ ირჩევთ მის გარშემო არსებულ თანამშრომლობის პლატფორმას. თითო ხაზი — დადებითი, უარყოფითი და როდის იმარჯვებს.
აირჩიეთ, როცა გინდათ მაქსიმალური მოცვა, ღია კოდის ხილვადობა ან უმცირესი წინააღმდეგობის გზა ახალი გუნდისთვის.
აირჩიეთ, როცა გინდათ ერთი მომწოდებელი თავიდან ბოლომდე, ან მთელი სტეკის საკუთარ ინფრასტრუქტურაში გაშვება გჭირდებათ.
აირჩიეთ, როცა თქვენი გუნდი უკვე Atlassian-ზეა სტანდარტიზებული და გინდათ მჭიდრო კავშირი ისიუსა და კოდს შორის.
Git არანაირ პროცესს არ გახვევთ. ბრენჩების ვორქფლოუ არის შეთანხმება, რომელსაც თქვენი გუნდი აწესებს: როგორ იწოდება ბრენჩები, რამდენ ხანს ცოცხლობს და როგორ აღწევს სამუშაო პროდაქშენამდე. გულწრფელი სიმართლე: უმეტეს გუნდში მარტივი ვორქფლოუ იმარჯვებს — სირთულე რეალურმა შეზღუდვამ უნდა დაიმსახუროს.
ერგება გუნდებს, რომლებიც უწყვეტად უშვებენ და მყარი CI აქვთ — თანამედროვე ნაგულისხმევი არჩევანი პროდუქტის ინჟინერიაში.
main), მოკლე ფიჩერ-ბრენჩები, განხილვა PR-ით, დეპლოი მერჯზე.main-იდან ხშირად დეპლოიავთ; პარალელურად გამოშვებული ვერსიებისთვის ჩაშენებული ადგილი არ აქვს.ერგება ვებ-აპლიკაციებისა და სერვისების უმეტესობას უწყვეტი დეპლოიმენტით — დაიწყეთ აქედან, თუ საწინააღმდეგო მიზეზი არ გაქვთ.
develop-ის, release-ისა და hotfix-ისთვის — სასარგებლოა, როცა ერთდროულად რამდენიმე გამოშვებულ ვერსიას უვლით.ერგება ვერსიებიან/დესკტოპ/on-prem პროგრამებს დაგეგმილი რელიზებით — იშვიათად სწორი არჩევანი SaaS-ისთვის, რომელიც ყოველდღე უშვებს.
თქვენ მიერ გაკეთებული კომიტები მაშინაც რჩება, როცა მათ „დაკარგავთ“ — reflog ახსოვს, სად იყო HEAD. აღდგენის ოთხი ინსტრუმენტის ცოდნა შემზარავი მომენტების უმეტესობას ორბრძანებიან შესწორებად აქცევს.
HEAD მიუთითებდა, ინახება დაახლოებით 90 დღე. რებეისი ან hard reset გაგიფუჭდათ? git reflog გაჩვენებთ კომიტს, რომელზეც წუთის წინ იყავით, ხოლო git reset --hard HEAD@{1} უკან დაგაბრუნებთ.გადაწერს ლოკალურ ისტორიას — შესანიშნავია გაგზავნამდე, საშიში მის შემდეგ. --soft ცვლილებებს სტეიჯინგში ტოვებს, --hard კი შლის.
ქმნის ახალ კომიტს, რომელიც ძველს აუქმებს. საერთო ბრენჩებზე უსაფრთხოა, რადგან ისტორიას არასოდეს გადაწერს.
git bisect ორობითი ძებნით ეძებს ცნობილ კარგ და ცნობილ ცუდ კომიტს შორის იმას, რომელმაც ყველაფერი გააფუჭა — log(n) ტესტი და არა n.
ხუთი სწრაფი კითხვა კომიტების მოდელზე, სტეიჯინგზე, მერჯსა და რებეისზე, remote-ებსა და აღდგენაზე — მყისიერი უკუკავშირი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში