რა არის Git?
მოკლედ რომ ვთქვათ — Git არის ვერსიების კონტროლის სისტემა, რომელიც საშუალებას გაძლევს აკონტროლო შენი ან გუნდის მიერ შექმნილი კოდი, დააკვირდე ცვლილებებს, აღადგინო წინა ვერსიები და კომფორტულად იმუშაო გუნდთან ერთად.
ტექნიკურად, Git არის ღია კოდის (open-source) დისტრიბუციული ვერსიების კონტროლის სისტემა (DVCS — Distributed Version Control System), რომლის მიზანია სისწრაფე, მონაცემთა მთლიანობა და განაწილებული (არასწორხაზოვანი) სამუშაო ნაკადების მხარდაჭერა.
რატომ ღირს Git-ის გამოყენება?
- Git საშუალებას გაძლევს თითოეული ცვლილება ჩაიწეროს ისტორიის სახით და საჭიროების შემთხვევაში დაბრუნდე წინა ვერსიაზე.
- გუნდური მუშაობისთვის ის განსაკუთრებით მოსახერხებელია — შეგიძლია იმუშაო ოფლაინ და შემდეგ დაასინქრონო ცვლილებები.
- Git-ის branch-ები და მოქნილი ისტორია საშუალებას გაძლევს შექმნა დამოუკიდებელი ფუნქციონალები უსაფრთხოდ.
ლოკალური და დისტანციური (Remote) რეპოზიტორიები
- ლოკალური რეპოზიტორი — შენს კომპიუტერზე არსებული Git რეპოზიტორი, სადაც მუშაობ კოდზე, აკეთებ კომმიტებს და მართავ ბრენჩებს.
- დისტანციური რეპოზიტორი — სერვერზე განთავსებული ასლი (მაგალითად GitHub ან GitLab), რომელიც გამოიყენება გუნდური მუშაობისა და რეზერვული შენახვისთვის.
Git – საფუძვლები
რა არის ლოკალური და დისტანციური რეპოზიტორიები?
- ლოკალური — შენს კომპიუტერზე არსებული რეპოზიტორი.
- დისტანციური — სერვერზე განთავსებული რეპოზიტორი გუნდური მუშაობისთვის.
როგორ შევქმნა ლოკალური რეპოზიტორი?
git init
📌 ბრძანება უნდა გაუშვა პროექტის ფოლდერში. შექმნის ფარულ ფაილს .git.
როგორ შევქმნა დისტანციური რეპოზიტორი?
GitHub/GitLab-ზე → New Repository → მიუთითე სახელი → Create ამის შემდეგ მიიღებ მისამართს, მაგალითად:
https://github.com/user/repo.git
როგორ დავამატო დისტანციური რეპოზიტორი?
git remote add origin https://github.com/user/repo.git
როგორ შევცვალო დისტანციური რეპოზიტორის მისამართი?
git remote set-url origin NEW_URL
როგორ წავშალო დისტანციური რეპოზიტორი?
git remote remove origin
როგორ გადმოვწერო კოდი დისტანციური რეპოზიტორიიდან?
git clone https://github.com/user/repo.git
შექმნის ახალ საქაღალდეს და მთლიანად გადმოგიტანს პროექტს.
როგორ დავფიქსირო ცვლილებები (commit)?
git add . # ამზადებს ფაილებს კომმიტისთვის
git commit -m "კომმიტის აღწერა" # ინახავს ცვლილებებს ისტორიის სახით
როგორ გავაგზავნო ცვლილებები დისტანციურ რეპოზიტორიაში?
git push origin main
📌 თუ იყენებ სხვა ბრენჩს — ჩაანაცვლე main შესაბამისით (მაგ. master, dev).
როგორ შევქმნა ახალი ბრენჩი?
git checkout -b feature-branch
📌 -b ქმნის და ერთდროულად გადაგიყვანს ახალ ბრენჩზე.
როგორ გადავიდე სხვა ბრენჩზე?
git checkout branch-name
ან, Git 2.23+ ვერსიიდან:
git switch branch-name
რა არის .gitignore?
.gitignore — ფაილი, სადაც ჩამოწერილია ფაილები და საქაღალდეები, რომლებსაც Git არ უნდა აკონტროლებდეს. მაგალითი:
__pycache__/
.env
*.log
როგორ ვნახო კომმიტების ისტორია?
git log
📌 გამოსასვლელად დააჭირე q. კომპაქტური ვერსია:
git log --oneline
რა განსხვავებაა git reset და git revert შორის?
-
git reset — აბრუნებს კომმიტებს უკან და გადაადგილებს ბრენჩის მაჩვენებელს (შესაძლებელია მონაცემთა დაკარგვა).
-
git revert — ქმნის ახალ კომმიტს, რომელიც აუქმებს არჩეული კომმიტის ცვლილებებს (უსაფრთხოდ ინახავს ისტორიას).
📌 reset გამოიყენება ლოკალურად, revert — გუნდური მუშაობისას.
რა განსხვავებაა Git და GitHub (ან GitLab, Bitbucket) შორის?
-
Git — ვერსიების კონტროლის ინსტრუმენტია (CLI).
-
GitHub / GitLab / Bitbucket — პლატფორმები დისტანციური რეპოზიტორიებისთვის, Pull Request-ებისა და CI/CD პროცესებისთვის.
როგორ მოვახდინო ახალი ბრენჩების ჩამოტვირთვა დისტანციური რეპოდან, შერწყმის გარეშე?
git fetch
📌 მხოლოდ განაახლებს დისტანციური ბრენჩების სიას და კომმიტებს, არაფერს აერთიანებს.
git reset–ის რეჟიმები:
git reset --soft HEAD~1 # ცვლილებები რჩება staging-ში
git reset --mixed HEAD~1 # რჩება სამუშაო ფოლდერში, მაგრამ არა staging-ში
git reset --hard HEAD~1 # მთლიანად წაშლის ცვლილებებს (ფრთხილად!)
რა არის commit-ების “squash”?
Squash — რამდენიმე კომმიტის გაერთიანება ერთში. გამოიყენება ისტორიის გასაწმენდად merge-ის წინ.
git rebase -i HEAD~N
როგორ გადავიტანო კომმიტები ერთი ბრენჩიდან მეორეში?
Cherry-pick:
git checkout target-branch
git cherry-pick <commit-hash>
Rebase:
git rebase source-branch
რა განსხვავებაა git merge და git rebase შორის?
-
merge — აერთიანებს ბრენჩებს, ქმნის merge-კომმიტს და ინახავს ისტორიულ სტრუქტურას.
-
rebase — გადაწერს ისტორიას, ქმნის ხაზოვან commit-ების რიგს.
📌 merge მარტივი და უსაფრთხო მეთოდია. 📌 rebase ქმნის სუფთა ისტორიას, მაგრამ მოითხოვს სიფრთხილეს გუნდურ მუშაობაში.
რა არის .gitattributes?
.gitattributes — ფაილი, რომელიც მართავს Git-ის ქცევას კონკრეტული ფაილების მიმართ.
მაგალითები:
*.sh text eol=lf
*.md diff=markdown
როგორ ვნახო განსხვავება ორ ბრენჩს შორის კონკრეტული ფაილისთვის?
git diff branch1 branch2 -- path/to/file
მაგალითი:
git diff main feature-xyz -- src/app.py
რა არის interactive rebase და როგორ განსხვავდება ჩვეულებრივი rebase-ისგან?
ჩვეულებრივ git rebase-ს უბრალოდ გადააქვს კომმიტები ახალ ბაზაზე.
git rebase -i საშუალებას გაძლევს:
-
შეცვალო კომმიტების რიგი
-
გააერთიანო (squash)
-
წაშალო (drop)
-
შეแกინო (edit) შეტყობინებები
📌 გამოიყენე merge-მდე ან pull request-ის მომზადებისას ისტორიის გასაწმენდად.
როდის გამოვიყენო git cherry-pick?
git cherry-pick <commit>
📌 გამოიყენება, როცა:
-
გჭირდება ერთი კონკრეტული ფიქსი ან ფუნქციონალი სხვა ბრენჩიდან;
-
გინდა გადმოიტანო მხოლოდ ერთი commit პროდაქშენში (backport);
-
გინდა კონკრეტული ცვლილების კოპირება სხვა ფიჩში.
რა პრობლემა ჩნდება, თუ გუნდის ნაწილი მუშაობს Linux/Mac-ზე, ნაწილი კი Windows-ზე?
რობლემა: განსხვავებული სტრიქონის დასრულება (EOL) — LF (Unix) vs CRLF (Windows).
შედეგი:
-
არასაჭირო diff-ები
-
merge კონფლიქტები
-
ცრუ ცვლილებები
🔧 გადაწყვეტა:
დაამატე .gitattributes-ში:
* text=auto
ან დააყენე LF როგორც სტანდარტული დასრულება .editorconfig ან IDE-ს კონფიგურაციაში.
რომელი ბრენჩინგის სტრატეგიები არსებობს?
| სტრატეგია | აღწერა |
|---|---|
| Git Flow | მკაფიო სტრუქტურა: master, develop, feature, release, hotfix. კარგია დიდი პროექტებისთვის. |
| GitHub Flow | მარტივი: main + feature ბრენჩები. სწრაფი და მარტივი პროცესი. |
| GitLab Flow | აერთიანებს GitHub Flow-ს CI/CD-თან და გარემოებთან (staging, production). |
| Trunk-based | ყველა მუშაობს ერთ ბრენჩზე (main) და აკეთებს მცირე, ხშირ ცვლილებებს. შესაფერისია DevOps გარემოსთვის. |
როგორ ავირჩიო ბრენჩინგის სტრატეგია?
დამოკიდებულია:
-
გუნდის ზომაზე
-
რელიზების სიხშირეზე
-
DevOps პროცესების არსებობაზე
-
პროდუქციის სტაბილურობაზე
მაგალითები:
-
მცირე პროექტი ან სტარტაპი → GitHub Flow — მარტივი და სწრაფი.
-
კორპორაციული პროექტი QA პროცესით → Git Flow ან GitLab Flow.
-
მაღალი ეფექტურობის DevOps გარემო → Trunk-based development.