git pull კონფიგურაცია

June 02, 2024

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

გავარჩიოთ თითოეული ბრძანება:

1. git config pull.rebase false
   • ეს ბრძანება გამორთავს git pull ბრძანების შესრულებისას ავტომატური რიბეისს.
   • დეფოფტად Git-ი გამოიყენებს დართვის(merge) სტრატეგიას, რაც ნიშნავს რომ, დაშორებული რეპოზიტორის ცვლილებები დაერთვება თქვენს ლოკალურ ცვლილებებს და შეიქმნება ახალი - დართვის კომიტი.
2. git config pull.rebase true
   • კონფიგურირების ეს ბრძანება შემდგომში git pull ბრძანების შესრულებას დეფოლტად ჩაურთავს რიბეისის გამოყენებას.
   • დართვის კომიტის შექმნის ნაცვლად, დაშორებული რეპოზიტორის ცვლილება მიიღება ლოკალური ცვლილების ზემოთ. ეს მიდგომა ინახავს კომიტების წრფივ ისტორიას, რაც შესაძლებელია უპრიანიც იყოს რაიმე პროექტში.
3. git config pull.ff only
   • ასეთი კონფიგურაცია გადართავს git pull ბრძანების ქცევას “fast-forward only” სტრატეგიის გამოყენებაზე.
   • ეს ნიშნავს, რომ Git-ი შეასრულებს pull-ს მხოლოდ იმ შემთხვევაში, თუ შესაძლებელია, რომ დაშორებული რეპოზიტორის ცვლილება მიღებული იქნას რიბეისის ან დართვის ახალი კომიტის შექმნის გარეშე. გამორიცხავს ორივე ზემო კონფიგურაციას და თუ ეს შეუძლელებილია, pull ოპერაცია დასრულდება შეცდომით.

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

მაგალითისათვის, თუ თქვენ გინდათ, რომ კომიტების ისტორია დარჩეს წრფივი და გასაგები, იყენებთ pull.rebase true. ხოლო, თუ გინდათ გვერდი აუაროთ შემთხვევით კონფლიქტებს და ყოველთვის იყოთ დარწმუნებული იმაში, რომ pull ოპერაცია ჩაივლის წარმატებით - “fast-forward”, ანუ კონფიგურაცია pull.ff only.

ᲠᲘᲑᲔᲘᲡᲘ (rebase) — ეს არის კომიტების ისტორიის ცვლილებების პროცესი. როცა იყენებთ რიბეისს, დაშორებული რეპოზიტორიდან იღებთ კომიტებს და ზემოდან აწერთ ლოკალური კომიტებს. განვიხილოთ ეს მაგალითზე:

დავუშვათ, თქვენი კომიტების ისტორია გამოიყურება ასე:

A---B---C (ლოკალური კომიტები)
     \
      D---E (დაშორებული კოიტები)

თუ თქვენ შეასრულებთ git pull --rebase, თქვენი კომიტების ისტორია გახდება ასეთი:

D---E---A'---B'---C' (ლოკალური კომიტები რიბეისის შემდეგ)

თქვენი ლოკალური კომიტები A, B და C „გადაეწერერება“ დაშორებული რეპოზიტორის D და E კომიტებს. რიბეისის მერე A, B და C კომიტებს გაუჩნდებათ ახალი ხეშები, რადგან მათ ექმნებათ ახალი ბაზა.

რიბეისის ძირითადი უპირატესობა:

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

რიბეისის ძირითადი ნაკლი:

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