7 საუკეთესო პრაქტიკა (Best practices) GIT-ზე უკეთესი კოდის ხარისხისთვის

 

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

 

1)     Atomic Commit 

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

·       თქვენ შეგიძლიათ დაა-commit-ოთ 1000 ცვლილება როგორც ერთი commit.

·       თქვენ შეგიძლიათ დაა-commit-ოთ ყველა dll ფაილი ან თუნდაც ბიბლიოთეკები

·       თქვენ შეგიძლიათ დაა-commit-ოთ ცვლილებები, რომლებიც შეიცავს შეცდომას.

მაგრამ არის თუ არა ეს კარგი ? რა თქმა უნდა, არა.

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

 

2)     სიცხადე იმაში თუ რა უნდა/არ უნდა დავა-commit-ოთ

ბევრი დეველოპერი აკეთებს კოდში ცვლილებებს, შემდეგ აკეთებს commit-ს და შემდეგ push-ს. ჩვენ შეიძლება შევხვდეთ ბევრ repository-ის, სადაც და-commit-ებული იქნება dll, pdf და სხვა არასასურველი ფაილები. როდესაც ვაკეთებთ commit-ს, საკუთარ თავს უნდა დავუსვათ ორი შეკითხვა:

·       საჭიროა თუ არა ყველა ფაილის დაკომიტება და საჭიროა თუ არა ისინი ვერსიის კონტროლის სისტემაში ?

·       არის თუ არა კონკრეტული ფაილები source code-ის ნაწილი ?

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

 

3)     Git-ის ბრძანებების ცოდნა

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

 

4)     გაქვთ თუ არა Git Workflow ?

თუ მუშაობ გუნდში და იყენებთ Git-ს, მაშინ არის არსებითი რომ მთელი დეველოპმენტ გუნდი იყენებს ერთსა და იმავე Workflow-ს. ქვემოთ მოყვანილია სამი ძირითადი უპირატესობა workflow-ს გამოყენებისას:

·       დეველოპმენტ პროცესი იქნება უფრო ორგანიზებული

·       კარგი Git Workflow არის საწინდარი branch-ების ყოველთვის მოწესრიგებულ მდგომარეობაში ყოფნის, ანუ ყოველთვის გვექნება clean branch-ები.

·       ეს უფრო კომფორტულს გახდის ჩვენს ცხოვრებას და გააუმჯობესებს კოდის ხარისხს.

 

5)     გატესტე და-push-ვამდე

სანამ ჩვენ ჩვენს ცვლილებებს დავა-commit-ებთ და დავ-push-ავთ, აუცილებელია რომ ისინი გავტესტოთ. თუ დავა-commit-ებთ შეცდომიან კოდს ლოკალურ repository-ზე ეს დაგბლოკავთ თქვენ, მაგრამ თუ თქვენ და-push-ავთ შეცდომიან კოდს, მაშინ თქვენ დაბლოკავთ მთლიან გუნდს.

·       ეს მიდგომარე დაგვეხმარებათ თქვენ და თქვენს გუნდს რომ დაწეროთ უფრო მეტი unit test-ები და გაუშვათ ისინი ყოველი commit-ის წინ.

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

 

6)     დაიცავით master branch

Default branch git-ზე არის master. შესაბამისად, კოდი ამ branch-ზე უნდა იყოს სტაბილური და გამოიყენებოდეს მხოლოდ production-თვის. ჩვენ უნდა დავიცვათ master branch სხვადასხვა მიმართულებით.ქვემოთ მოცემულია  რეკომენდაციები ამის განსახორციელებლად:

·       master branch არ უნდა იქნას წაშლილი არც შემთხვევით და არც განზრახ.

·       master branch-ზე commit-ის ისტორია არ უნდა იყოს შეცვლილი და გადაწერილი

·       პირდაპირი commit master branch-ზე არ უნდა იყოს შესაძლებელი code review-ს გარეშე

 

7)     Branch მენეჯმენტი

Git გვთავაზობს მძლავს branching მოდელს. ჩვენ უნდა გვქონდეს ჩვენი კოდი master-ისგან განსხვავებულ branch-ზე შემდეგ შემთხვევებში:

·       თუ ჩვენ ვაპირებთ ახალი ფუნქციონალის იმპლემენტაციას - უნდა გავაკეთოთ ახალ branch-ზე.

·       თუ ვაპირებთ არსებული bug-ის fix-ს - უნდა გავაკეთოთ ახალ branch-ზე.

·       თუ გვინდა refactoring - უნდა გავაკეთოთ ახალ branch-ზე.

როცა უკვე მოვრჩებით ჩვენს ცვლილებებს ჩვენს branch-ზე, შემდეგ უნდა გავაკეთოთ Pull Request (Merge Request) და მხოლოდ code review-ს გავლის შემდეგ უნდა მოვახდინოთ მისი სინქრონიზება master-ზე.