GitHub-ის გამოყენება

July 16, 2024

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

GitHub აუდენტიფიკაცია

უსაფრთხოების ზომების გათვალისწინებით 2021 წლის შემდეგ GitHub-მა შეზღუდა მომხმარებლის სახელით და პაროლით აუდენტიფიკაცია რეპოზიტორების განახლების დროს.

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

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

მიზანი

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

მეორე პროტოკოლი, რომლითაც GitHub-თან შესაძლებელია მუშაობა, არის https-ი, მაგრამ ამ დროს git-ის ბრძანება მოითხოვს მომხმარებლის სახელს და პაროლს. როგორც ზემოთ ავღნიშნე, პაროლის გამოყენება ასეთ პროცედურებში უკვე აკრძალულია, ამის მაგივრად გამოიყენება პერონალური დაშვების ტოკენი. ამ პროცედურას VS Code აგვარებს ვიზუალურ რეჟიმში, GitHub-ზე აუდენტიფიქაციის შემდეგ ქმნის API ტოკენს და შემდეგ გვაკავშირებს საჭირო რეპოზიტორრისთან, ხოლო ყველა შემდგომ git პროცედურებს წაუძღვება ამ ტოკენის გამოყენებით. ეს ყველაფერი გასაგებია, თუმცა ჩემი სწავლებები ამგვარ ვინდოუსურ მეთოდებს არ განიხილავს, ამიტომ მე მოვიყვან კლასიკურ მაგალითს ლინუქსის ცხოვრებიდან.

ChatGPT გვეტყვის, რომ პაროლის მაგივრად უნდა შევიყვანოთ ტოკენი, აი ტოკენის მაგალითი: ghp_xrAsuLgZCxjOC5Mr9EfBhqa4D917Uw*a0PeN, ხელით შეყვანის პერსპექტივა მგონი ძალიან მოსაწყენია, ამიტომ ამ პირველ მეთოდს გვერდს ავუვლით.

თუმცა გარკვეული ნაბიჯები მაინც გასავლელი გვაქვს და ჯერი ისინი განვიხილოთ

GitHub-ის პერსონალური ტოკენი (Personal Access Token, PAT)

შექმენით პერსონალური ტოკენი:

• გადადით GitHub-ის პარამეტრებში: https://github.com/settings/tokens
• შექმენით ახალი ტოკენი საჭირო უფლებებით. მაგალითად, ფუშისთვის დაგჭირდებათ repo უფლება.

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

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

git push https://avto:your-personal-access-token@github.com/avto/myrepo.git

ეს URL შეიცავს ტოკენ, ასევე შესაძლებელია შევინახოთ როგორც origin remote-ი, შემდეგი git push ბრძანებები არ მოითხოვს ტოკენის ხელახლა შეყვანას.

:

1. remote URL დაყენება ტოკენით:

   git remote set-url origin https://avto:your-personal-access-token@github.com/avto/myrepo.git
   

2. push-ის გაკეთება:

   git push origin main
   

ამის შემდეგ, ნებისმიერ დროს შეგიძლიათ გამოიყენოთ მხოლოდ git push და ტოკენი ავტომატურად იქნება ჩართულიი:

git push

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

უფრო უსაფრთხო მეთოდები:

1. Git Credential Manager-ის გამოყენება

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

2. .netrc ფაილის გამოყენება

ეს მეთოდი ყველაზე მისაღები გამოდგა ჩემთვის, შევქმნით ფაილს და ჩავწერთ:

machine github.com
login your-github-username
password your-personal-access-token

შევცვლით პერმიშენს

chmod 600 ~/.netrc

3. Git-ის credential მეხსიერების გამოყენება (Linux)

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

Git-ს შეუძლია შეინახოს თქვენი credentials მეხსიერებაში გარკვეული დროის განმავლობაში (ეს ყველაზე უსაფრთხოა მოკლე დროში):

git config --global credential.helper cache
# ან კონკრეტული დროით (მაგალითად 1 საათით)
git config --global credential.helper 'cache --timeout=3600'

ამ მეთოდების გამოყენებით თქვენ შეძლებთ უსაფრთხოდ და მარტივად მართოთ თქვენი GitHub-ზე push-ები. (და არა მარტო)

ახლა მოვიყვან კიდევ ერთ კონკრეტულ მაგალითს და ამით დავასრულებ მიზანს, რომელსაც მიეძღვნა პოსტი (თუ კიდევ გახსოვთ რა იყო):

როგორ მოვიქცე, როცა რეპოზიტორი დაქლონილი მაქვს ssh-ით და მოვედი სკოლაში, სადაც https-ის გარდა პერსპექტივა არ მაქვს.

ყველაფერი გამომადგება, ის რაც ზემოთ დავწერე, ძირითადად კი ~/.netrc ფაილი თავისი შინაგანი განწყობილებით.

ორივე ssh და https გამოყენებისათვის უნდა დავამატოთ კიდევ ერთი remote მისამართი. ადვილი მისახვედრია, რომ ეს იქნება https-ი.

აქ არის ნაბიჯები, რომლებიც უნდა გაიაროთ:

1. დაამატეთ https პროტოკოლი, როგორც მეორე remote:

   გადადით თქვენს რეპოზიტორში:

   cd path/to/your/repository
   

   დაამატეთ https პროტოკოლი, როგორც ახალი remote (მაგალითად, https-origin):

   git remote add https-origin https://github.com/<username>/<repository>..git
   

2. .netrc ფაილის კონფიგურაცია:

   იხილე ზომოთთ

3. შეამოწმეთ არსებული remote-ები:

   დარწმუნდით, რომ ორივე remote მისამართი სწორად დადგა:

   git remote -v
   

   შედეგი უნდა იყოს მსგავსი:

   origin  git@github.com:avtotrainer/portfolio.git (fetch)
   origin  git@github.com:avtotrainer/portfolio.git (push)
   https-origin https://github.com/avtotrainer/portfolio.git (fetch)
   https-origin https://github.com/avtotrainer/portfolio.git (push)
   

4. pushის შესრულება:

   • SSH პროთტოკოლით:

     git push origin main
     

   • HTTPS პროტოკოლით (როდესაც თქვენი ორგანიზაციის ქსელში იმყოფებით):

     git push https-origin main
     

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

git push ბძანება, ასე მოკლედ შეასრულებს იმ პროტოკოლს, რომლითაც თავდაპირველად
 არის ქლონირებული, ხოლო თუ გვინდა მეორე პროტოკოლით დაფუშვა, მაშინ უნდა გამოვი
ყენოთ ახალი რემოუთის სახელი. აქ https-origin არ არის რაიმე კონსტანტა, ის
უბრალოდ სახელია, რომელიც შეიძლება იყოს მაგალითად troponi-იც ან saba, ეს სახელი
მიახლოებულია თემასთან და მიტომ, შესაძლებელიია უფრო მოკლედაც, მაგალითად https

მაშინ ფუშის ბრძანება მეორე პროტოკოლით მიიღებს საეს git push https main