diff --git a/Git & GitHub/About-Pull-Requests.md b/Git & GitHub/About-Pull-Requests.md
new file mode 100644
index 0000000..8587422
--- /dev/null
+++ b/Git & GitHub/About-Pull-Requests.md	
@@ -0,0 +1,42 @@
+# Pull Request-ების შესახებ
+### Pull Request-ები არის ერთგვარი საშუალება "შეტყობინების გაგზავნის" სხვა თანაგუნდელისთვის, რომ თქვენ დაფუშეთ თქვენი ბრენჩი GitHub რეპოზიტორიში. მას შემდგომ, რაც გაიხსნება pull request-ი, თქვენ შესაძლებლობა გაქვთ გამართოთ დისკუსია და განიხილოთ პოტენციური ცვლილებები სხვა თანაგუნდელებთან ერთად, მოახდინოთ დამატებითი ცვლილებები საჭიროებისამებრ და შემდგომ მოახდინოთ საბოლოო "ვერსიის" შერწყმა(merge) მთავარ ბრენჩზე. (master/main)
+
+
+pull request-ის ინიციალიზების შემდგომ, თქვენ დაინახავთ გადათვალიერების გვერდს (review page), რომელშიც ასახული იქნება თქვენი, ანუ შესადარებელი ბრენჩი და რეპოზიტორიის საბაზისო ბრენჩი(master/main). ზემოხსენებულ გვერდში თქვენ გაქვთ შესაძლებლობა გადახედოთ ცვლილებებს, რომლებიც თავმოყრილია კომიტებში, დაამატოთ ლეიბლები, ვადები და უფლებამოსილი პირი/ები(assignees). ასევე, მოიხსენიოთ(mention) სხვა თანაგუდნელები, ან კონტრიბუტორები. დამატებითი ინფორმაციისათვის ეწვიეთ: [Pull Request-ის შექმნა](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request)
+
+pull request-ის შექმნის შემდგომ, თქვენ გაქვთ შესაძლებლობა დაფუშოთ კომიტები თქვენი ლოკალური ბრენჩიდან არსებულ pull request-ში. კომიტები გამოჩნდება ქრონოლოგიურად და ცვლილებების ნახვა შესაძლებელია "Files Changed" ტაბში.
+
+სხვა კონტრიბუტორებს შეუძლიათ გადახედონ თქვენ მიერ შეთავაზებულ ცვლილებებს, დაამატონ კომენტარები და კონტრიბუცია შეიტანონ თქვენს pull request-ში.
+
+თქვენ შეგიძლიათ ბრენჩის მიმდინარე deployment სტატუსი და წინარე deployment აქტივობები "Conversation" ტაბში. დამატებითი ინფორმაციისათვის ეწვიეთ: "[Viewing deployment activity for a repository.](https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/viewing-deployment-activity-for-your-repository)"
+
+მას შემდგომ, რაც დარწმუნდებით, რომ თქვენ მიერ შეთავაზებული ცვლილებები დადასტურებულია გეძლევათ შესაძლებლობა, რომ შერწყათ/დამერჯოთ pull request-ი.
+თუ მუშაობთ `shared repository model`-ში, მაშინ თქვენ ქმნით pull request-ს და თავადვე, ან სხვა შერწყამს თქვენს ცვლილებებს თქვენივე ბრენჩიდან იმ საბაზისო ბრენჩში, რომელსაც თქვენ მიუთითებთ pull request-ში. (ძირითად შემთხვევებში ეს არის master/main ბრენჩი.) დამატებითი ინფორმაციისათვის ეწვიეთ: "[Merging a pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request)."
+
+თუ სტატუს ჩექები მოთხოვნილია რეპოზიტორიაში, მაშინ მოთხოვნილმა სტატუს ჩექებმა უნდა გაიაროს წარმატებით იმისათვის, რომ მოხდეს თქვენი ბრენჩის შერწყმა დაცულ ბრენჩზე. დამატებითი ინფორმაციისათვის ეწვიეთ: "[About required status checks](https://docs.github.com/en/free-pro-team@latest/articles/about-required-status-checks)."
+
+თქვენ შეგიძლიათ მიაბათ pull request-ი არსებულ იშუს(Issue), რათა მოხდეს იმ ადამიანების ინფორმირება, რომლებიც ამ საკითხს "კურირებენ". რა იგულისხმება ამაში?
+იგულისხმება ის, რომ მათ შეუძლიათ ნახონ, თუ რა სტადიაზეა საკითხი, ხოლო საკითხთან დაკავშირებული ბრენჩის შერწყმის შემდგომ ხდება ავტომატურად დახურვა ამ საკითხის. დამატებითი ინფორმაციისათვის ეწვიეთ: "[Linking a pull request to an issue](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue)."
+
+```
+Tips: should be added
+```
+
+# შაბლონად შენახვა Pull Request-ების
+
+Pull request-ების შაბლონად შენახვა საჯარო რეპოზიტორიებში
+
+როდესაც ქმნით pull request-ს, შეგიძლიათ, რომ შექმნათ ისეთი pull request-ი, რომელიც უკვე მზად არის განსახილველად, ან შეინახოთ შაბლონად. შაბლონური pull request-ებს ვერ დამერჯავთ. დეტალური ინფორმაციისათვის ეწვიეთ: "[Creating a pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request)" და "[Creating a pull request from a fork](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)."
+
+როდესაც დარწმუნდებით, რომ თქვენი pull request-ი არის სრულყოფილი და მზად არის განსახილველად, მაშინ შეგიძლიათ შაბლონური pull request მონიშნოთ, როგორც განსახილველად მზად მყოფი. ასევე ნებისმიერ დროს შესაძლებელია მიმდინარე pull request-ის შაბლონად შენახვა. დამატებითი ინფორმაციისათვის ეწვიეთ: "[Changing the stage of a pull request.](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request)."
+
+
+# დამატებითი საკითხავი
+
+*[Pull request](https://docs.github.com/en/free-pro-team@latest/articles/github-glossary/#pull-request)
+*[About branches](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-branches)
+*[Commenting on a pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request)
+*[Merging a pull request](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request)
+*[Closing a pull request](https://docs.github.com/en/free-pro-team@latest/articles/closing-a-pull-request)
+*[Deleting unused branches](https://docs.github.com/en/free-pro-team@latest/articles/deleting-unused-branches)
+*[About pull request merges](https://docs.github.com/en/free-pro-team@latest/articles/about-pull-request-merges)
\ No newline at end of file
diff --git a/Git & GitHub/Forking-Projects.md b/Git & GitHub/Forking-Projects.md
new file mode 100644
index 0000000..899dca8
--- /dev/null
+++ b/Git & GitHub/Forking-Projects.md	
@@ -0,0 +1,58 @@
+
+თუ რაღაც გარკვეული პერიოდია გასული, რაც GitHub-ს იყენებ დამოუკიდებლად, ალბათ გაგიჩნდებოდა სურვილი, რომ კონტრიბუცია შეგეტანა ვიღაცის პროექტში, ან გაქვს სურვილი იმის, რომ გამოიყენო სხვისი პროექტი შენი პროექტის საწყის წერტილად. ეს პროცესი ცნობილია, როგორც *forking.*
+
+"fork"-ის შექმნა გულისხმობს სხვისი პროექტის ეგზემპლარის შექმნას. ფორკები შეგვიძლია წარმოვიდგინოთ, როგორც ხიდი ორიგინალ რეპოზიტორიასა და თქვენს პერსონალურ ეგზემპლარს შორის. თქვენ შეგიძლიათ გააგზავნოთ *Pull Request*-ები და შეთავაზოთ ცვლილებები.
+
+მიმდინარე გაკვეთილში გამოვიყენებთ "[Spoon-Knife პროექტს](https://github.com/octocat/Spoon-Knife)", რომელიც არის სატესტო რეპოზიტორია დაჰოსტილი GitHub.com-ზე, რომელიც საშუალებას გაძლევთ გატესტოთ Pull Request-ის workflow.
+
+# და-fork-ეთ რეპოზიტორია
+
+იმისათვის, რომ და-fork-ოთ Spoon-Knife რეპოზიტორია, დააჭირეთ **Fork** ღილაკს რეპოზიტორიის ჰედერში.
+
+<!-- IMG #1 Here -->
+
+მოთავსდით კომფორტულად სავარძელში/სკამში და დაელოდეთ, fork-ის მაგიის შესრულებას :laughing:
+
+# დაკლონეთ თქვენ მიერ გაკეთებული fork
+
+Spoon-Knife რეპოზიტორიის წარმატებული fork-ის შემდგომ, ის მხოლოდ ხელმისაწვდომია/არსებობს GitHub პლატფორმაზე. იმისათვის, რომ შეძლოთ პროექტზე მუშაობა და-fork-ილი პროექტი უნდა დაკლონოთ ლოკალურად თქვენს კომმპიუტერში.
+
+თქვენ მიერ გაკეთებულ fork-ში მარჯვენა კუთხეში დააჭირეთ **Clone or Download**-ს.
+თუ როგორ დაკლონავთ პროექტს დამოკიდებულია თქვენზე. შეგიძლიათ დაკლონოთ [Git ბრძანებათა ხაზის მეშვეობით](https://lab.github.com/), ან [GitHub Desktop](https://lab.github.com/) გამოყენებით.
+
+
+# ცვლილებების შეტანა და დაფუშვა
+
+შეიტანეთ ნებისმიერი სახის ცვლილებები პროექტში თქვენივე საყვარელი ტექსტური ედიტორის გამოყენებით. მაგალითისთვის შეგიძლიათ შეცვალოთ *index.html* და დაამატოთ თქვენი GitHub username.
+
+როდესაც მზად იქნებით ცვლიებების გასაგზავნათ, დააკომიტეთ ისინი.
+
+კომიტით თქვენ Git-ს დაახლოებით ასეთი რაღაც უთხარით:(რომ წარმოვიდგინოთ ადამიანურ ენაზე პროცესი):
+
+> კარგი, მე დავასნეფშოთე ჩემი ცვლილებები.
+
+თქვენ რა თქმა უნდა შეგიძლიათ გააგრძელოთ ცვლილებების შეტანა და დაკომიტება. როდესაც საბოლოოდ დაასრულებთ, დაფუშეთ თქვენი ცვლილებები დისტანციურ ბრენჩზე.
+
+# Pull Request-ის შექმნა
+
+ბოლო ნაბიჯი სწორედ ეს არის. თქვენ მზად ხართ შეთავაზოთ თქვენი ცვლილებები მთავარ პროექტში! (თუ რა თქმა უნდა თვლით, რომ თქვენ მიერ შეტანილი ცვლილებები გამოადგება პროექტის მომხმარებლებს).
+
+Pull request-ის შესაქმნელად გადამისამართით იქ, სადაც თქვენი პროექტი ცხოვრობს. მოცემული გაკვეთილისთვის ეს იქნება დაახლოებით შემდეგი მისამართი:
+
+`https://github.com/<თქვენი_username>/Spoon-Knife`.
+
+გადამისამართებისთანავე თქვენ დაინახავთ ბანერს, რომელიც ინდიკატორია იმის, რომ თქვენ ახლახანს დაფუშეთ ახალი ბრენჩი:
+
+<!-- IMG # 2 -->
+
+**Compare and Pull Request**-ზე დაჭერით თქვენ გადამისამართდებით სადისკუსიო გვერდზე, სადაც უთითებთ სათაურსა და არასავალდებულო აღწერას. მნიშვნელოვანია, რომ pull request-ის შექმნისას რივიუერებს მიაწოდოთ გამოსადეგი ინფორმაცია, თუ რატომ აგზავნით მიმდინარე pull request-ს. მსგავსი პრაქტიკა ამარტივებს პროცესს პროექტის მფლობელისთვის წარმოდგენის შესაქმნელად, თუ რატომ გსურთ შეტანილი ცვლილებების ასახვა.
+
+როდესაც ზემოხსენებულ ნიშნულებს შეავსებთ, დააჭირეთ **Send pull request** და თქვენი ცვლილებები მზად არის განსახილველად.
+
+<!-- IMG #3 -->
+
+Pull Request-ები შეგვიძლია ასევე წარმოვიდგინოთ როგორც სივრცე, სადაც შეგვიძლია გავმართოთ დისკუსია შეთავაზებულ ცვლილებებზე. დიდი ალბათობით Octocat-ი ვერ დამერჯავს თქვენ მიერ შეთავაზებულ ცვლილებებს, მაგრამ სხვა პროექტების შემთხვევაში არ ინერვიულოთ, თუ პროექტის მფლობელი უარყოფს თქვენ მიერ შეთავაზებულ ცვლილებებს, ან მოგთხოვთ დამატებით ინფორმაციას თქვენი ცვლილებებისთვის. არც იმაზე ინერვიულოთ, თუ უბრალოდ მფლობელს არ მოეწონა თქვენი შეთავაზება. ეს სავსებით ნორმალურია. თქვენი ეგზემპლარი სამუდამოდ იარსებებს ინტერნეტში და ვინ იცის, იქნებ ვიღაც სხვამ, ვისაც არასდროს შეხვედრილხართ იპოვოს თქვენი ცვლილებები და გახდეს მისთვის ბევრად ღირებული, ვიდრე ეს პროექტის მფლობელისთვის იყო.
+
+# გილოცავ!
+
+თქვენ წარმატებით და-fork-ეთ და კონტრიბუცია შეიტანეთ რეპოზიტორიაში. ახლა უკვე თამამად შეგიძლიათ სხვა პროექტებშიც შეიტანოთ კონტრიბუცია!
\ No newline at end of file
diff --git a/Git & GitHub/Git-Handbook.md b/Git & GitHub/Git-Handbook.md
new file mode 100644
index 0000000..d925657
--- /dev/null
+++ b/Git & GitHub/Git-Handbook.md	
@@ -0,0 +1,176 @@
+# რა არის ვერსიების სამართავი სისტემა?
+
+ვერსიების სამართავი სისტემა (Version Control System ან VCS შემოკლებით) ამონიტორინგებს ცვლილებებს და ინახავს მის ისტორიას. დეველოპერებს ეძლევათ საშუალება გადაამოწმონ ისტორია შემდეგი მიზნებისთვის:
+
+* რა სახის ცვლილებები იქნა შეტანილი?
+
+* ვინ შეიტანა ზემოხსენებული ცვლილებები?
+
+* როდის მოხდა ცვლილების ასახვა?
+
+* რატომ გახდა ცვლილებები საჭირო?
+
+# რა არის განაწილებული ვერსიების სამართავი სისტემა?
+
+Git არის მაგალითი განაწილებული ვერსიების სამართავი სისტემის. (Distributed Version Control System, ან DVCS შემოკლებით) ძირითადად გამოიყენება open source და კომერციულ software development-ში. DVCS გვაძლევს სრულ წვდომას თითოეულ ფაილზე, ბრენჩსა და პროექტის იტერაციაზე. სხვა პოპულარული ცენტრალიზებული ვერსიების სამართავი სისტემებისაგან განსხვავებით, DVCS-ები (მსგავსად Git-ისა) არ საჭიროებენ მუდმივ კავშირს ცენტრალურ რეპოზიტორიასან. დეველოპერებს შეუძლიათ იმუშაონ ნებისმიერი წერტილიდან და ითანამშრომლონ ასინქრონულად ნებისმიერი დროის ზონიდან.
+
+
+# რატომ Git?
+
+ბოლო [Stack Overflow developer survey](https://insights.stackoverflow.com/survey/2017#technology)-ზე დაყრდნობით 70%-ზე მეტი დეველოპერი იყენებს Git, რაც გულისხმობს იმას, რომ Git არის ყველაზე ფართოდ გამოყენებული VCS მსოფლიოში. Git ფართოდ გამოიყენება როგორც open source, ასევე კომერციულ software development-ში.
+Git-ს აქვს **მნიშვნელოვანი ბენეფიტები** როგორც ინდივიდუალური პირებისთვის, ასევე გუნდებისა და ბიზნესისთვისაც.
+
+* Git მეშვეობით დეველოპერებს საშუალება ეძლევათ ნახონ ცვლილებების მთლიანი ისტორიები, გადაწყვეტილებები და პროგრესი ნებისმიერი პროექტის ერთ სივრცეში.
+
+* დეველოპერებს შეუძლიათ იმუშაონ დროის ნებისმიერი ზონიდან. ისეთი DVCS, როგორიც არის Git გაძლევთ კოლაბორაციის საშუალებას maintaining source code გაგების შეფერხების გარეშე.
+
+* კომპანიები იყენებენ Git-ს რათა მოსპონ საკომუნიკაციო ბარიერები გუნდებს შორის და უზრუნველყონ მათი ფოკუსირება უფრო მეტად.
+
+
+# რა არის სათავსო/საცავი (Repository)?
+
+Repository, ანუ Git პროექტი, როგორც გარსი, ისე არის შემოხვეული პროექტში არსებულ ფაილებსა და ფოლდერებს. ფაილების ისტორიები წარმოჩენილია როგორც snapshot, რომელიც *commit*-ად არის ცნობილი, ხოლო ეს კომიტები არსებობენ როგორც linked-list კავშირი, რომლის დაყოფაც შესაძლებელია სხვადასხვა development გარემოებებად. ე.წ. ბრენჩები.
+
+იქიდან გამომდინარე, რომ Git არის DVCS, რეპოზიტორები არიან დამოუკიდებელი ერტეულები და ნებისმიერი, ვინც ფლობს რეპოზიტორის ეგზემპლარს აქვს წვდომა მთლიან კოდთან და მასთან დაკავშირებულ ისტორიასთან. ბრძანებათა ხაზის ან სხვა ინტერფეისის საშუალებით git რეპოზიტორია ასევე საშუალებას გვაძლევს: დავკლონოთ, შევქმნათ ბრენჩები, დავაკომიტოთ, დავმერჯოთ და სხვ.
+
+რეპოზიტორიებთან მუშაობით პროექტები არის უფრო ორგანიზებული და დაცული. დეველოპერები უფრო თამამად "ფიქსავენ ბაგებს", ან ქმნიან ახალ ცვლილებებს და არ არსებობს შიში იმისა, რომ მათი მთავარი პროდუქტი ჩამოინგრევა.
+
+
+# საბაზისო Git ბრძანებები.
+
+ Git გამოსაყენებლად, დეველოპერები იყენებენ სპეციალურ ბრძანებებს რომ დააკოპირონ, შექმნან, შეცვალონ ან შეაერთონ კოდი. ბრძანებების გაშვება შესაძლებელია პირდაპირ ბრძანებათა ხაზიდან (command line), ან აპლიკაციის გამოყენებით ([GitHub Desktop](https://desktop.github.com/) ან Git Kraken). ქვემოთ არის ჩამოთვლილი ხშირად გამოყენებული ბრძანებები Git გამოსაყენებლად:
+
+* `git init` ინიციალიზებას ახდენს სრულად ახალი Git რეპოზიტორიისა და იწყებს თვალყურის დევნას არსებული დირექტორიისა. Git ამატებს დამალულ ქვე-ფოლდერს არსებულ დირექტორიაში, რომელშიც ინახება შიდა ინფორმაციული მონაცემთა სტრუქტურები, რომლებიც საჭიროა ვერსიების სამართავად.
+
+* `git clone` ქმნის ლოკალურ ეგზემპლარს პროექტისა, რომელიც უკვე არსებობს დისტანციურად. კლონი მოიცავს პროექტის ყველა ფაილს, ისტორიასა და ბრენჩებს.
+
+* `git add` ამატებს ცვლილებას. ვინაიდან Git ამონიტორინგებს დეველოპერის კოდში შეტანილ ცვლილებებს, მნიშვნელოვანია, რომ დავამატოთ ცვლილებები, რათა მოხდეს მათი ასახვა პროექტის ისტორიაში. ზემოხსენებული ბრძანება პასუხისმგებელია დამატებაზე (რომელიც შეგვიძლია მოვიხენიოთ პირველ ეტაპად, რადგანაც სულ 2 ეტაპიანია ეს პროცესი). ნებისმიერი ცვლილება, რომელიც არის დამატებული იქნება პროექტის ისტორიის ნაწილი. 
+
+* `git commit` ასეივებს/ინახავს დამატებულ ცვლილებას/სნეფშოტს პროექტის ისტორიაში და ამით სრულდება ცვლილებების მონიტორინგის პროცესი. მოკლედ რომ ვთქვათ, კომიტ ბრძანება გავს სურათის გადაღებას. ნებისმიერი ცვლილება, რომელიც დამატებულია `git add` ბრძანებით, შენახული/დაკომიტებებული იქნება `git commit` მიერ.
+
+* `git status` გვიჩვენებს ცვლილებების სტატუსს, რომლებიც არიან  `untracked, modified, staged` სტადიებში.
+
+* `git branch` გვიჩვენებს ლოკალურად არსებულ ბრენჩებს.
+
+* `git merge` ძირითადად ეს ბრძანება გამოიყენება მაშინ, როდესაც სურთ ორი განსხვავებული ბრენჩის შეერთება. მაგალითისთვის: დეველოპერი გამოიყენებს ამ ბრძანებას როდესაც მათ სურთ ცვლილებების ასახვა *feature branch*-დან მთავარ *(master/main)* ბრენჩში.
+
+* `git pull` ანახლებს დეველოპმენტის ლოკალურ ხაზს დისტანციური(*remote*) ნაწილიდან გამომდინარე.მაგალითისთვის: X დეველოპერი გამოიყენებს ამ ბრძანებას, თუ Y დეველოპერმა განაახლა დისტანციური(remote) ბრენჩი და X დეველოპერს სურს დისტანციურ ბრენჩზე არსებული ცვლილებების ლოკალურად წამოღება(განახლება).
+
+* `git push` ანახლებს დისტანციურ(remote) ბრენჩს ყველა იმ კომიტით, რაც გვაქვს ლოკალურ ბრენჩში.
+
+თუ გსურთ უფრო დეტალური განმარტებები, ან გსურთ ყველა git ბრძანებების ხილვა, ეწვიეთ: [a full reference guide to Git Commands.](https://git-scm.com/docs)
+
+# აღმოაჩინე უფრო მეტი Git ბრძანებები
+
+უფრო დეტალური განხილვისთვის (თავისი პრაქტიკული მაგალითებით) დაგეხმარებათ შემდეგი რესურსები:
+
+* [Working locally](https://www.youtube.com/watch?v=rBbbOouhI-s&index=2&list=PLg7s6cbtAD17Gw5u8644bgKhgRLiJXdX4)
+* [`git status`](https://www.youtube.com/watch?v=rBbbOouhI-s&index=2&list=PLg7s6cbtAD17Gw5u8644bgKhgRLiJXdX4)
+* [Two-step commits](https://www.youtube.com/watch?v=Vb0Ghkkc2hk&index=4&list=PLg7s6cbtAD17Gw5u8644bgKhgRLiJXdX4)
+* [`git pull` and `git push`](https://www.youtube.com/watch?v=-uQHV9GOA0w&index=5&list=PLg7s6cbtAD17Gw5u8644bgKhgRLiJXdX4)
+
+
+# როგორ გვეხმარება GitHub
+
+GitHub არის Git დასაჰოსტი რეპოზიტორია, რომელიც დეველოპერებს უზრუნველყოფს ხელსაწყოებით უკეთესი კოდის ხარისხისათვის, pull request-ებისათვის, კოდის განხილვისათვის და ასევე გვაწვდის უამრავ უფასო, ან შესყიდვად აპლიკაციებს, რომლებიც ხელმისაწვდომია GitHub Marketplace-ში. 
+
+# როგორ მუშაობს GitHub
+
+GitHub-ი დეველოპმენტის პროცესში ქმნის კოლაბორაციას. შესასრულებელი სამუშაო არის ორგანიზებული რეპოზიტორიებში, სადაც დეველოპერებს ხაზგასმით შეუძლიათ ჩამოაყალიბონ მიმართულებები და მოლოდინები თითოეული გუნდის წევრისათვის. შემდგომ, GitHub flow-ის გამოყენებით, დეველოპერები ქმნიან ბრენჩებს, რათა იმუშაონ განახლებებზე, დააკომიტონ ცვლილებები, გახსნან pull request-ები, რათა მოხდეს შეტანილი ცვლილებების განხილვა და შემდგომ მათი ასახვა.
+
+# GitHub flow
+
+GitHub flow არის მსუბუქი, ბრენჩზე დაფუძნებული workflow, რომელიც დაშენებულია `core git commands`-ზე.
+
+GitHub flow შედგება 6 ნაბიჯისაგან, რომლებიც ერთმანეთის დამოუკიდებლად ქმნიან ბენეფიტებს, როდესაც ხდება მათი იმპლემენტაცია:
+
+1. **შექმენი ბრენჩი:** თემატური ბრენჩები, რომლებიც ძირითად შემთხვევებში იქმნება ბრენჩ `master/main`-დან, გუნდებს აძლევს საშუალებას, რომ შეიტანონ წვლილი პარალელურად ერთმანეთთან კონფლიქტის გარეშე.
+
+2. **დაამატე კომიტები:** კომიტების მეშვეობით იქმნება უკან დაბრუნებადი "წერტილები", რომლებიც ისახება პროექტის ისტორიაში და ხარვეზის დროს ბევრად მარტივი და უსაფრთხოა უსაფრთხო გარემოს აღდგენა.
+
+3. **გახსენი pull request-ები:** pull request-ებით დეველოპმენტის პროცესი ხდება გამჭირვალე, რაც გულისხმობს იმას, რომ ყველას ეძლევა შესაძლებლობა განიხილოს თქვენ მიერ შეტანილი ცვლილებები, გაიმართოს დისკუსია, მოგცენ უკეთესი რჩევები და ამის შემდგომ მოხდეს თქვენი ცვლილებების შერწყმა.
+
+4. **ჩაერთეთ და განიხილეთ კოდი:** ძირითად შემთხვევებში გუნდები მონაწილეობას იღებენ კოდის განხილვაში (ე.წ. code review process) დაკომენტარებით, გატესტვით, ან უბრალოთ თქვენი კოდის განხილვით. code review არის ფუნდამენტი დეველოპმენტ პროცესში.
+
+5. **შერწყმა(Merge):** ღილაკ `merge`-ზე დაჭერით, GitHub ავტომატურად ასრულებს  `git merge` ოპერაციას. GitHub აგრეთვე ინახავს მთლიანი ბრენჩის დეველოპმენტ ისტორიას.
+
+6. **Deploy:** გუნდებს შეუძლიათ ამოირჩიონ საუკეთესო დასარილიზებელი ციკლები, ან დააიმპლემენტირონ `continuous integration tools`, რათა დარწმუნდნენ, რომ კოდი, რომელიც არსებობს deployment ბრენჩზე წარმატებით გაიარა robust worfklow-ი.
+
+
+# გაიგე მეტი GitHub flow-ზე
+
+დამატებითი რესურსებისთვის, შეგიძლიათ ეწვიოთ:
+
+* [Interactive guide](https://guides.github.com/introduction/flow/)
+* [GitHub Flow video](https://www.youtube.com/watch?v=47E-jcuQz5c&index=1&list=PLg7s6cbtAD17Gw5u8644bgKhgRLiJXdX4)
+
+
+# GitHub და ბრძანებათა ხაზი (command line)
+
+მათთვის, ვინც არიან ახლები command line-ში, ვთვლი, რომ ქვემოთ მოყვანილი მაგალითები დაგეხმარებათ უკეთ წარმოიდგინოთ, თუ როგორ გამოიყენოთ Git:
+
+# მაგალითი: შეიტანეთ ცვლილებები არსებულ რეპოზიტორიში
+
+```
+# გადმოწერე/დაკლონე  რეპოზიტორია Github.com-დან  თქვენს კომპიუტერში
+git clone https://github.com/me/repo.git
+
+# გადადით `repo` დირექტორიაში
+cd repo
+
+# შექმენით ახალი ბრენჩი
+git branch my-branch
+
+# გადადით შექმნილ ბრენჩზე (დეველოპმენტის ახხალ ხაზზე)
+git checkout my-branch
+
+# შეიტანეთ ცვლილებები, მაგ:   შეიტანეთ ცვლილებები `file1.md` და `file2.md`-ში
+
+# დაამატეთ  ფაილები
+git add file1.md file2.md
+
+# დააკომიტეთ/დაასეივეთ შეტანილი ცვლილებები. (`-m`) არგუმენტი გამოიყენება კომენტარის დასართავად.
+git commit -m "my snapshot"
+
+# დაფუშეთ ცვლილებები github-ზე
+git push --set-upstream origin my-branch
+```
+
+# მაგალითი: ახალი რეპოზიტორიის შექმნა და ასახვა GitHub-ზე
+
+პირველ რიგში საჭიროა, რომ შექმნათ ახალი რეპოზიტორია. შეგიძლიათ გაეცნოთ ჩვენს [Hello World](../Hello-world.md) გაკვეთილს. **არ** დააინიციალიზიროთ რეპოზიტორია README, .gitignore ან License ფაილებით.
+
+
+```
+# შექმენით ახალი დირექტორია და დააინიციალიზირეთ ის git სპეციფიური ფუნქციებით.
+git init my-repo
+
+# გადაინაცვლეთ `my-repo` დირექტორიაში
+cd my-repo
+
+# შექმენით პირველი ფაილი თქვენს პროექტში
+touch README.md
+
+# git-მა არ იცის შექმნილი ფაილის შესახებ, დაამატეთ ის.
+git add README.md
+
+# დააკომიტეთ/დაასეივეთ დამატებული ფაილი შესაბამისი მესიჯით.
+git commit -m "add README to initial commit"
+
+# მიაწოდეთ სრული მისამართი იმ რეპოზიტორიისა, რომელიც შექმენით github-ზე
+git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
+
+# ასახეთ ცვლილებები github-ზე
+git push --set-upstream origin main
+
+```
+
+
+# დამატებითი რესურსები
+
+* [Beginner projects to explore](https://github.com/showcases/great-for-new-contributors)
+* [GitHub video guides](https://youtube.com/githubguides)
+* [GitHub on-demand training](https://lab.github.com/)
+* [GitHub training guides](https://guides.github.com/)
+* [GitHub training resources](https://lab.github.com/)
+
diff --git a/Git & GitHub/Git-and-GitHub.md b/Git & GitHub/Git-and-GitHub.md
new file mode 100644
index 0000000..d3039f6
--- /dev/null
+++ b/Git & GitHub/Git-and-GitHub.md	
@@ -0,0 +1,81 @@
+---
+description: >-
+  სათარგმნი მასალა:
+  https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/GitHub
+---
+
+# Git
+
+
+ყველა დეველოპერი ძირითადად იყენებს რაღაც სახის ვერსიების სამართავ სისტემას `(Version Control System)`. ხელსაწყო, რომელიც დეველოპერს კოლაბორაციის საშუალებას აძლევს სხვა დეველოპერებთან. რაშიც იგულისხმება ის, რომ მათ შეუძლიათ იმუშაონ საერთო პროექტზე და აირიდონ ისეთი საშიშროებები, როგორებიცაა:
+
+* თავზე გადაწერა ერთმანეთის ნამუშევრის
+* ხარვეზის დაფიქისრების შემთხვევაში, გვაძლევს საშუალებას, რომ ცვლილებები დავაბრუნოთ წინა გამართულ ვერსიებში.
+
+ყველაზე პოპულარული ვერსიების სამართავი სისტემა (ყოველ შემთვევაში ვებ დეველოპერებისთვის) არის **Git**, **GiHub**-თან ერთად. **GitHub** არის საიტი, რომელიც საშუალებას იძლევა დავჰოსტოთ სათავსოები`(Repositories)` და გვაწვდის ხელსაწყოებს მათთან უკეთესად სამუშაოდ.
+
+---
+
+# მიმოხილვა
+
+ვერსიების სამართავი სისტემები **სასიცოცხლოდ მნიშვნელოვანია** დეველოპმენტისთვის.
+
+* იშვიათობაა დამოუკიდებლად პროექტზე მუშაობა, ამიტომ როცა იწყებ სხვა დეველოპერებთან ერთად მუშაობას, მაშინ ჩნდება შესრულებული სამუშაოს ერთმანეთთან კონფლიქტის რისკი. — ეს ხდება მაშინ, როდესაც ორივე დეველოპერი ერთსა და იმავე დროს ცდილობს განაახლოს ერთი და იგივე კოდის ნაწილი. ასეთ დროს საჭიროა, რომ არსებობდეს რაღაც სახის მექანიზმი, რომელიც დაგვეხმარება მსგავსი სიტუაციების სამართავად და მოახდენს შესრულებული სამუშაოს დაკარგვის პრევენციას.
+
+* დამოუკიდებლად, ან სხვებთან ერთად პროექტზე მუშაობისას  ვერსიების სამართავი სისტემა გვაძლევს საშუალებას დავაბრუნოთ კოდი სასურველ ნაწილში მაშინაც კი, თუ კომპიუტერი მწყობრიდან გამოვა.
+
+* ხშირია შემთხვევები, როდესაც პრობლემის აღმოჩენა ხდება მოგვიანებით, ამიტომაც შესაძლებელია კოდის წინა სასურველ ვერსიაზე დაბრუნება.
+
+* ძირითადად, სხვადასხვა გუნდის წევრები ქმნიან ცალკეულ ვერსიებს კოდის (ეწოდება *Branch* Git-ში), სადაც მუშაობენ ახალ Feature-ზე და შემდგომ ხდება შეტანილი ცვლილების შერწყმა(merge) კონტროლირებადი მეთოდით (GitHub-ში გამოიყენება *pull request*) *master* ბრენჩთან.
+
+
+
+ვერსიების სამართავი სისტემები გვაწვდიან ყველა საჭირო ხელსაწყოს, ზემოხსენებული საჭიროებებისათვის. [Git](https://git-scm.com/) არის მაგალითი ვერსიების სამართავი სისტემის, ხოლო [GitHub](https://github.com) არის ვებ საიტი + ინფრასტრუქტურა, რომელიც უზრუნველყოფს Git სერვერსა და უამრავ სასარგებლო ხელსაწყოს Git სათავსოებთან(`Repositories`) სამუშაოდ, როგორც ინდივიდუალური პირებისთვის, ასევე გუნდებისთვისაც.
+
+> Git არის განაწილებული ვერსიების სამართავი სისტემა, იგულისხმება, რომ სათავსოს სრული ეგზემპლარი  არსებობს ლოკალურად შენს კომპიუტერში (ყველა სხვას აქვთ თავიანთი ეგზემპლარები). ნებისმიერი სახის შეტანილი ცვლილება ასახული იქნება მხოლოდ შენს ეგზემპლარში. შეტანილი ცვლილებები შემდგომ და-push-ული არის სერვერზე, სადაც ადმინისტრატორი წყვეტს შეირწყმება თუ არა ასახული ცვლილებები master ეგზემპლართან.
+
+---
+
+# წინაპირობა
+
+Git და GitHub გამოსაყენებლად საჭიროა:
+
+* დესკტოპ კომპიუტერი, სადაც დაინსტალირებულია Git (ნახეთ: [Git ჩამოსატვირთი გვერდი](https://git-scm.com/downloads))
+
+* ხელსაწყო Git გამოსაყენებლად. იმის გათვალისწინებით, თუ როგორ სტილში გიყვარს მუშაობა, შეგიძლია გამოიყენო : [Git გრაფიკული კლიენტი](https://git-scm.com/downloads/guis/) (რეკომენდირებულია გამოიყენოთ: GitHub Desktop, SourceTree ან Git Kraken), ან შესაძლოა ტერმინალ ფანჯარის გამოყენებაც საწყის დონეზე საბაზისო git ბრძანებების შესასწავლად.
+
+* [GitHub ანგარიში](https://github.com/join) თუ უკვე არ გაქვთ, გამოიყენეთ მითითებული ლინკი დასარეგისტრირებლად.
+
+გასათვალისწინებელია, რომ წინაპირობის დასაკმაყოფილებლად აუცილებელი არ არის გარკვეული იყოთ ვებ დეველოპმენტში, Git/GitHub ან სხვა ნებისმიერ ვერსიების სამართავ სისტემაში, მაგრამ რეკომენდირებულია, რომ იცით რაღაც დონეზე კოდინგი და გაქვთ ნებისმიერი სახის კოდი, რომელსაც განათავსებთ სათავსოებში.
+
+ასევე რეკომენდირებულია, რომ გაქვთ ტერმინალის საბაზისო ცოდნა. მაგალითისთვის: იცით როგორ გადახვიდეთ დირექტორიებში, შექმნათ ფაილები და როგორ შეცვალოთ სისტემური `PATH`
+
+>GitHub არ არის ერთადერთი პლატფორმა, Git-თან სამუშაოდ. არსებობს ასევე სხვა ალტერნატივებიც, როგორიცაა [Gitlab](https://gitlab.com), რომელიც შეგიძლიათ, რომ ცადოთ. ასევე შესაძლებელია საკუთარი Git სერვერის აწევა/გამოყენებაც Github/Gitlab მაგივრად, მაგრამ მიმდინარე კურსში ჩვენ ვიმუშავებთ GitHub-ზე.
+
+---
+
+# გზამკვლევები
+
+
+[Hello World](https://LinkHere.LinkHere)
+
+ზემოხსენებული გაკვეთილი იდეალურია დამწყებებისთვის - პრაქტიკული მაგალითებით მუშაობა GitHub-თან. ისწავლით Git საბაზისოებს. როგორ შევქმნათ სათავსო, ბრენჩები, კომიტები, გავხსნათ და შევრწყათ pull request-ები.
+
+[Git Handbook](https://LinkHere.LinkHere)
+
+ამ გაკვეთილში გაეცნობით ვერსიების სამართავ სისტემებს უფრო სიღრმისეულად. განხილულია ასევე თუ რა არის სათავსო, როგორ მუშაობს GitHub მოდელი, Git ბრძანებები თავისი მაგალითებით და სხვ.
+
+[Forking Projects](https://LinkHere.LinkHere)
+
+თუ დაინტერესებული ხართ კონტრიბუციით და გსურთ სხვის კოდში წვლილის შეტანა, მაშინ პროექტების Forking-ი მნიშვნელოვანია. ამ გაკვეთილში დეტალურად არის ახსნილი თუ როგორ.
+
+
+[Pull Requests შესახებ](https://LinkHere.LinkHere)
+
+გზამკვლევი თუ როგორ ვმართოთ pull request-ები. 
+
+[Mastering Issues](https://LinkHere.LinkHere)
+
+Issue-ები შეგვიძლია წარმოვიდგინოთ, როგორც ფორუმი ჩვენი GitHub პროექტისთვის, სადაც სხვა დეველოპერებს(ან უბრალოდ დაინტერესებულ პირებს) შესაძლებლობა აქვთ დასვან შეკითხვები, დააფიქსირონ ხარვეზები, ან მოახდინოთ "ხმის მიწვდენა" თქვენი პროდუქტის მომხმარებლებზე (მაგალითისთვის: X ხარვეზი, რომელიც დააფიქსირა მომხმარებელმა არის აღმოფხვრილი). ამ გაკვეთილში გაეცნობით საბაზისოებს, რაც უნდა იცოდეთ Issue-თან მიმართებაში.
+
+> მნიშვნელოვანია იცოდეთ, რომ გაცილებით ბევრი რაღაცის გაკეთება არის შესაძლებელი Git და GitHub-ით, მაგრამ ზემოხსენებული გზამკვლევებით წარმოდგენილია ის მინიმალური სასწავლო მასალა, რაც საჭიროა Git-ის ეფექტურად გამოსაყენებლად. რაც უფრო ღრმად დაეუფლებით Git-ს მიხვდებით, რომ მარტივია შეცდომის დაშვება, როდესაც დაიწყებთ უფრო კომპლექსური ბრძანებების გამოყენებას, მაგრამ არ ინერვიულოთ!  ზოგჯერ თვით პროფესიონალ დეველოპერებსაც კი დამაბნევლად ეჩვენებათ Git და ამიტომაც კონსულტაციისთვის ხშირად მიმართავენ ისეთ ხერხებს, როგორებიცაა: გადაწყვეტის ინტერნეტში მოძიება, ან Git-თვის განკუთვნილ ვებ-გვერდებს. მაგ: [Flight rules for Git](https://github.com/k88hudson/git-flight-rules) და [Dangit, git!](https://dangitgit.com/)
\ No newline at end of file
diff --git a/Git & GitHub/Hello-World.md b/Git & GitHub/Hello-World.md
new file mode 100644
index 0000000..2e054f5
--- /dev/null
+++ b/Git & GitHub/Hello-World.md	
@@ -0,0 +1,172 @@
+**თქვენ ისწავლით, თუ როგორ:**
+* შექმნათ და გამოიყენოთ სათავსო/საცავი (Repository)
+* შექმნათ და მართოთ ახალი ბრენჩი (Branch)
+* შეიტანოთ ცვლილებები ფაილში და დაფუშოთ GitHub-ზე როგორც კომიტი
+* გახსნათ და შერწყათ(merge) pull request
+
+# **რა არის GitHub?**
+
+GitHub არის კოდის დასაჰოსტი პლატფორმა, რომელიც საშუალებას გაძლევთ სხვებთან ერთად იმუშაოთ საერთო პროექტზე ნებისმიერი ადგილიდან.
+
+ამ გზამკვლევში ისწავლით GitHub-ის ძირითად ნაწილს, როგორებიცაა: სათავსო/საცავები(repositories), branches, commits, pull requests. თქვენ შექმნით თქვენს Hello World სათავსოს და ისწავლით GitHub pull request-ის მუშაობის პროცესს(workflow).
+
+# **კოდის წერა არ არის სავალდებულო**
+
+ამ გზამკვლევის წარმატებით შესასრულებლად, საჭიროა [GitHub.com ანგარიში](https://github.com) და ინტერნეტთან წვდომა. არ არის საჭირო იცოდეთ, თუ როგორ დაწეროთ კოდი
+
+> რჩევა: გახსენით მიმდინარე გზამკვლევი სხვა ბრაუზერის ფანჯარაში (ან ტაბში)
+
+
+# ნაბიჯი 1. შექმენით Repository
+
+**Repository** ძირითადად გამოიყენება ერთი პროექტის დასაორგანიზებლად.
+რეპოსიტორები შესაძლოა შეიცავდნენ: ფოლდერებს, ფაილებს, სურათებს, ვიდეოებს,
+ელექტრონულ ცხრილებს(SpreadSheet) - ძირითადად ყველაფერს, რაც თქვენს პროექტს
+სჭირდება. ჩვენი რეკომენდაციაა, რომ თან დაურთოთ ***README,*** ან სხვა ნებისმიერი
+ფაილი, რომელიც მომხმარებელს ინფორმაციას მიაწვდის თქვენი პროექტის შესახებ.
+GitHub ამარტივებს ზემოხსენებული ფაილის შექმნას რეპოზიტორიის შექმნისტანავე.
+***GitHub ასევე გვთავაზობს სხვა common option-საც. მაგალითისთვის: ლიცენზიის ფაილი***
+
+თქვენი `hello-world` სათავსო/საცავი შესაძლოა იყოს ის ადგილი, სადაც შეგეძლებათ 
+შეინახოთ თქვენი იდეები, რესურსები, ან სხვებს გაუზიაროთ საკითხები.
+
+
+# იმისათვის, რომ შექმნათ ახალი სათავსო/საცავი(Repository)
+
+1. მარჯვენა ზედა კუთხეში, თქვენი ავატარის გვერდით, დააჭირეთ `+` და შემდგომ
+აირჩიეთ **New Repository**
+2. დაარქვით თქვენს სათავსოს `hello-world`
+3. დაწერეთ მოკლე აღწერა
+4. აირჩიეთ **Initialize this repository with a README**
+
+<!-- Image #1 here -->
+
+დააჭირეთ **Create Repository**
+
+
+# ნაბიჯი 2. შექმენით Branch
+
+**Branching** არის გზა ემუშაოთ სათავსოს სხვადასხვა ვერსიებს ერთდროულად.
+
+default-ად თქვენს საცავს აქვს ერთი branch `master/main`, რომელიც იგულისხმება,
+ როგორც განსაზღვრული branch. ჩვენ ვიყენებთ ბრენჩებს საექსპერიმენტოდ და შეგვაქვს
+ ცვლილებები მანამ, სანამ მათ დავაკომიტებდეთ `master/main`-ზე
+
+ როდესაც თქვენ ქმნით ახალ branch-ს `master/main`-დან, თქვენ ქმნით მის ეგზემპლარს, რაშიც
+ იგულისხმება ის, რომ თქვენ ქმნით იმ დროისთვის დამახასიათებელი ვერსიის ეგზემპლარს.
+ თუ სხვა პირმა შეიტანა ცვლილებები `master/main` ბრენჩში მანამ, სანამ თქვენ მუშაობდით
+ თქვენს ბრენჩზე, მაშინ შეგიძლიათ ჩამოქაჩოთ(pull) შეტანილი განახლებები.
+
+
+დიაგრამაზე ასახულია:
+* `master/main` ბრენჩი
+* ახალი ბრენჩი `feature` (რადგანაც ჩვენ ვასრულებთ "feature" სამუშაოს ამ ბრენჩში)
+* გზა, რომელსაც გადის ბრენჩი `feature` მანამ, სანამ იგი შეირწყმება(merged) `master/main`-თან.
+
+<!-- IMG #2 Here-->
+
+ოდესმე შეგინახავთ სხვადასხვა ვერსიები კონკრეტული ფაილის? რაღაც ამდაგვარი:
+
+* `story.txt`
+* `story-george-edit.txt`
+* `story-george-edit-final.txt`
+
+ბრენჩები ზუსტად მსგავს მიზნებს ემსახურებიან GitHub რეპოზიტორიებში.
+
+მაგალითისთვის: GitHub დეველოპერები, writer-ები და დიზაინერები იყენებენ ბრენჩებს, რათა
+შეინახონ `bug fixes`, და `feature work`-ები `master/main` (production) ბრენჩის განცალკევებულად.
+როდესაც კონკრეტული ცვლილება არის მზად, ისინი შერწყამენ(merge) თავიანთ ბრენჩს `master/main`-ში.
+
+# იმისათვის, რომ შექმნათ ახალი ბრენჩი
+
+1. გადადით თქვენს ახალ რეპოზიტორიში `hello-world`
+2. დააჭირეთ ჩამოსაშლელს(drop-down) ფაილების ლისტის თავზე, სადაც წერია: **branch: master/main.**
+3. ბრენჩის ტექსტბოქსში მიუთითეთ ბრენჩის სახელი `readme-edits`
+4. აირჩიეთ ლურჯი ღილაკი **Create Branch** ან დააჭირეთ *Enter*
+
+
+<!-- IMG #3 HERE -->
+
+ახლა თქვენ გაქვთ ორი ბრენჩი: `master/main` და `readme-edits`. ისინი ზუსტად ერთნაირად გამოიყურებიან,
+მაგრამ არა დიდი ხნით! ახლა ჩვენ დავამატებთ ცვლილებებს ახალ ბრენჩში.
+
+
+# ნაბიჯი 3. ცვლილებების შეტანა და დაკომიტება
+
+ბრავო! ახლა, შენ იმყოფები ბრენჩ `readme-edits`-ის code view ფანჯარაში. (ჩვენი ბრენჩი არის ეგზემპლარი `master/main` ბრენჩის.)
+დროა შევიტანოთ ცვლილებები.
+
+GitHub-ზე შესანახ ცვლილებებს ეწოდებათ *კომიტები(commits)* თითოეულ კომიტს აქვს შესაბამისი *კომიტ მესიჯი*, რომელიც არის
+აღწერა თუ რატომ მოხდა კონკრეტული ცვლილება. კომიტ მესიჯები ინახავენ თქვენი ცვლილებების ისტორიას, რაც უმარტივებს
+სხვა დეველოპერებს გაიგონ, თუ რა გააკეთეთ და რატომ.
+
+# შეიტანეთ ცვლილებები და დააკომიტეთ
+
+1. დააჭირეთ `README.md` ფაილს.
+2. დააჭირეთ ფანქრის სიმბოლოს ფაილის ზედა მარჯვენა კუთხეში ცვლილების შესატანად.
+3. ედიტორში დაწერეთ ნებისმიერი რამ. (მაგალითად მოყევით თქვენს შესახებ).
+4. დაწერეთ კომიტ მესიჯი, რომელიც აღწერს თქვენს ცვლილებებს.
+5. დააჭირეთ **Commit Changes** ღილაკს.
+
+<!-- IMG #4 HERE -->
+
+შეტანილი ცვლილებები აისახება მხოლოდ README ფაილისთვის `readme-edits` ბრენჩში.
+გამოდის, რომ ზემოხსენებული ბრენჩი შეიცავს ისეთ კონტენტს, რომელიც განსხვავდება ჩვენი `master/main`-გან
+
+
+# ნაბიჯი 4. გახსენით Pull Request
+
+ვინაიდან თქვენ უკვე გაქვთ ისეთი ბრენჩი, რომელიც განსხვავებულია `master/main`-გან
+შეგიძლიათ შექმნათ *pull request*.
+
+როდესაც თქვენ ხსნით *pull request*-ს, თქვენ თავაზობთ თქვენს ცვლილებებს და ითხოვთ, რომ
+განხილულ იქნას თქვენი ცვლილებები ვიღაცის მიერ და შეირწყას(merge) მათ ბრენჩში.
+Pull Request-ებში შესაძლებელია *diffs*, ანუ განსხვავებების(differences) ნახვა ორივე ბრენჩიდან.
+ცვლილებები, დამატებები და ამოკლებები ნაჩვენებია მწვანე და წითელ ფერებში.
+
+მას შემდეგ, რაც დააკომიტებთ გაქვთ შესაძლებლობა, რომ გახსნათ pull request და გამართოთ
+დისკუსია იმ შემთხვევაშიც კი, თუ თქვენი კოდი არ არის დამთავრებული.
+
+
+თქვენს pull request მესიჯში შეგიძლიათ GitHub [@mention system](https://docs.github.com/en/free-pro-team@latest/github/writing-on-github/about-writing-and-formatting-on-github#text-formatting-toolbar)
+დახმარებით მოიხსენიოთ სხვა მომხმარებლები feedback-თვის. არ აქვს მნიშვნელობა ისინი თქვენს ქვედა სართულზე იმყოფებიან, თუ კილომეტრების დაშორებით.
+
+თქვენ ასევე გაქვთ შესაძლებლობა, რომ გახსნათ pull request-ი თქვენს რეპოზიტორიში და შერწყათ(merge) თავადვე. ეს ხერხი არის საუკეთესო GitHub დინების შესასწავლად მანამ, სანამ გადახვალთ უფრო დიდი ზომის პროექტებზე სამუშაოდ.
+
+# გახსენით ახალი Pull Request README-ში შეტანილი ცვლილებებისთვის.
+
+
+ნაბიჯი  | სურათი
+------------ | -------------
+დააჭირე X Pull Request ტაბს და Pull request გვერდიდან დააჭირეთ მწვანე **New pull request** ღილაკს.| სურათი #1
+**Example Comparisons**-ში აირჩიეთ ბრენჩი, რომელიც შექმენით `readme-edits`, რათა შეადაროთ `master/main` (ორიგინალს) | სურათი #2
+შეადარეთ თქვენი ცვლილებები, რათა დარწმუნდეთ, თუ რა ცვლილებებს ასახავთ. | სურათი #3
+როდესაც დარწმუნდებით, რომ ასახული ცვლილებები თქვენთვის მისაღებია, დააჭირეთ **Create Pull Request** ღილაკს | სურათი #4
+მიუთითეთ სათაური და დაწერეთ მოკლე აღწერა თქვენი ცვლილებების | სურათი #5
+
+როდესაც დაასრულებთ მოკლე აღწერას, დააჭირეთ **Create pull request!**
+
+> შეგიძლიათ გამოიყენოთ [emoji](https://help.github.com/articles/basic-writing-and-formatting-syntax/#using-emoji) & [images/gif Drag & Drop](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/file-attachments-on-issues-and-pull-requests) ფუნქციონალები კომენტარებსა და თქვენს Pull Request-ებში.
+
+
+# ნაბიჯი 5. დამერჯეთ თქვენი Pull Request
+
+ამ საბოლოო ნაბიჯში დადგა დრო, რომ დავმერჯოთ `readme-edits` ბრენჩი `master/main` ბრენჩში.
+
+1. დააჭირეთ მწვანე **Merge pull request** ღილაკს, რათა დამერჯოთ ცვლილებები `master/main`-ში.
+2. დააჭირეთ **Confirm merge**
+3. წაშალეთ ბრენჩი, რადგანაც მასში არსებული ცვლილებები უკვე შერწყმულია. (წაშლა შეგიძლიათ **Delete branch** ღილაკით.)
+
+
+# დროა აღვნიშნოთ!
+
+ამ გზამკვლევის დასრულებით, თქვენ ისწავლეთ თუ როგორ შექმნათ პროექტი და pull request GitHub-ზე!
+
+ეს კი მოკლე აღწერა იმის, თუ რა ისწავლეთ:
+* შექმენით open source repository
+* შექმენით ახალი ბრენჩი
+* შეიტანეთ ცვლილება ფაილში და დააკომიტეთ ცვლილებები GitHub-ზე
+* გახსენით და დამერჯეთ Pull Request
+
+თუ გსურთ უფრო სიღრმისეულად შეისწავლოთ Pull Requests, მაშინ გირჩევთ გადახედოთ:
+[GitHub flow Guide](https://guides.github.com/introduction/flow/), [GitHub Explore](https://github.com/explore)
diff --git a/Git & GitHub/Mastering-Issues.md b/Git & GitHub/Mastering-Issues.md
new file mode 100644
index 0000000..e0850b5
--- /dev/null
+++ b/Git & GitHub/Mastering-Issues.md	
@@ -0,0 +1,150 @@
+იშუები არის საუკეთესო გზა თასქების, გაუმჯობესებების, ბაგების აღსარიცხად. იშუ შეგვიძლია წარმოვიდგინოთ, როგორც მეილი, იმ განსხვავებით, რომ ის შესაძლებელია გაზიარდეს და განხილულ იქნეს გუნდის სხვა წევრების მიერაც. უმეტეს software პროექტებს აქვთ რაღაც ტიპის bug tracker თავიან პროექტებში. GitHub-ის შემთხვევაში, მას **Issues** ეწოდება და გამოყოფილია, როგორც ცალკე სექცია რეპოზიტორიში.
+
+<!-- IMG #1 here -->
+
+მაგალითისთვის, შეგვიძლია გადავხედოთ [Bootstrap-ის Issues სექციას](https://github.com/twbs/bootstrap/issues):
+
+<!-- IMG #2 here -->
+
+ტიპობრივი issue GitHub-ზე დაახლოებით გამოიყურება ასე: 
+
+<!-- IMG #3 here -->
+
+* **სათაური** და **აღწერის** მეშვეობით ნათელია, თუ რას ეხება კონკრეტული issue.
+
+* ფერადი **ლეიბლები** გვეხმარებიან კატეგორიებად დაყოფასა და issue-ების ფილტრაციაში.
+
+* **მაილსთოუნი**-ს ქცევა შეგვიძლია, წარმოვიდგინოთ როგორც კონტეინერი issue-ებისთვის. მაილსთოუნი გამოგადგებათ მაშინ, როდესაც გსურთ, რომ ასოციაციით დააკავშიროთ issue-ები კონკრეტულ feature-ებთან, ან პროექტის ფაზებთან. (მაგ: Weekly Sprint 9/5-9/16, ან Shipping 1.0).
+
+* ერთი **assignee** პასუხისმგებელია issue-ში არსებული საკითხის შესრულებაზე.
+
+* **კომენტარები** აძლევს სხვებს(რომელთაც აქვთ წვდომა რეპოზიტორიაზე) feedback-ის საშუალებას.
+
+
+# Milestones, Labels, Assignees
+
+როდესაც თავს მოიყრის ბევრი issue, შესაძლოა გაგირთულდეთ ისეთი issue-ების პოვნა, რომელსაც თვლით, რომ პრიორიტეტულია. **Milestones, labels, assignees** გეხმარებათ issue-ების ფილტრაციასა და მათ კატეგორიებად დაყოფაში.
+
+შეგიძლიათ დაამატოთ/შეცვალოთ milestone, assignee, და label-ები. განთავსებულია მარჯვენა sidebar-ში.
+
+<!-- IMG #4 here -->
+
+თუ თქვენ ვერ ხედავთ ზემოხსენებულ ღილაკებს, ნაგულისხმევია, რომ თქვენ არ გაქვთ issue-ზე ცვლილების შეტანის უფლება. თქვენ შეგიძლიათ მოითხოვოთ რეპოზიტორიის მფლობელისგან, რომ დაგამატოთ როგორც კოლაბორატორი, რათა გქონდეთ წვდომა ღილაკებთან.
+
+
+# Milestones
+
+როგორც უკვე ვახსენეთ, მაილსთოუნები არის ჯგუფები იშუებისა, რომლებიც შეესაბამებიან რაღაც პროექტს, ან დროის ინტერვალს. ქვემოთ მოყვანილია მაგალითები, თუ როგორ გამოიყენება ზემოხსენებული ფუნქცია:
+
+* **Beta Launch** - ფაილის ბაგები, რომლებიც გამოსასწორებელია მანამ, სანამ ჩაეშვება თქვენი პროექტის ბეტა ვერსია. არის ერთ-ერთი საუკეთესო გზა იმაში დასარწმუნებლად, რომ თქვენ არ ტოვებთ არაფერს.
+
+* **October Sprint** - issue-ები, რომლებზეც ისურვებდით, რომ იმუშაოთ ოქტომბერში. გამოიყენება მაშინ, როდესაც ბევრი საკითხია შესასრულებელი და ხდება მათი დახარისხება.
+
+* **Redesign** - issue-ები, რომლებიც დაკავშირებულია redesign-თან.
+
+
+
+# Labels
+
+ლეიბლები არის საუკეთესო გზა სხვადასხვა ტიპის იშუების დასაორგანიზებლად. თქვენ შეგიძლიათ გქონდეთ უსაზღვრო ლეიბლები და ასევე გაფილტროთ ერთი, ან რამდენიმე ლეიბლით.
+
+# Assignees
+
+ყოველ issue-ს შეუძლია ჰყავდეს თავისი assignee. - კონკრეტული პირი, რომელიც პასუხისმგებელია საკითხის ბოლომდე მიყვანაზე.
+
+# Notifications და @mentions
+
+`@`-ის გამოყენებით, შესაძლებლობა გაქვთ შეატყობინოთ სხვა GitHub მომხმარებლებსა და გუნდებს.(შესაძლებელია ასევე სხვა იშუს მოხსენიებაც.)
+ზემოხსენებული ქმედების ფონზე შეგვიძლია ჩავრთოთ "საჭირო ხალხი" დაკავშირებული საკითხის ეფექტურად გადასაწყვეტად. ასევე შესაძლებელია გამოიყენოთ [GitHub Flavored Markdown](https://help.github.com/articles/writing-on-github#name-and-team-mentions-autocomplete).
+
+<!-- IMG #5 here -->
+
+
+# Notifications
+
+[ნოტიფიკაციები](https://github.com/notifications) არის GitHub მიერ შემოთავაზებული გზა, რომელიც უზრუნველყობს საკითხების **up to date** სტადიაში ქონას. ზემოხსენებული ფუნქცია შეგიძლიათ გამოიყენოთ იმ შემთხვევაში, თუ გაინტერესებთ არის თუ არა ახალი იშუები რეპოზიტორიებში, ან სჭირდება თუ არა ვინმეს თქვენგან პასუხი, რათა მოხდეს საკითხის სხვა ეტაპზე გადაყვანა.
+
+არსებობს ორი გზა ნოტიფიკაციის მისაღებად: იმეილის, ან ვებ გვერდის მეშვეობით.კონფიგურაცია შესაძლებელია თქვენს [პარამეტრებში](https://github.com/settings/notifications). თუ ფიქრობთ, რომ მოგიწევთ ბევრი ნოტიფიკაციის მიღება, მაშინ გირჩევთ, რომ მიიღოთ ვებ და იმეილ ნოტიფიკაციები ერთდროულად. ერთი **Participating** და მეორე **Watching**-თვის.
+
+<!-- IMG #6 here-->
+
+სურათზე ნაჩვენები პარამეტრებს თუ გამოიყენებთ, მაშინ თქვენ მიიღებთ იმეილს, როდესაც ვინმე მოგიხსენიებთ საკითხზე.
+
+წვდომა თქვენს ნოტიფიკაციებზე გაქვთ [https://github.com/notifications](ნოტიფიკაციები)-დან. გამოიყენება მაშინ, როდესაც გინდათ დაასკანეროთ ბევრი ნოტიფიკაცია ერთდროულად და გსურთ, რომ მოუნიშნოთ "წაკითხული" ან "და-mute-ოთ".
+სცადეთ გამოიყენოთ კლავიატურის შორთქათები, რათა აასწრაფოთ თქვენი workflow. 
+ვებ გვერდზე <kbd>?</kbd> დაჭერით თქვენ ნახავთ რომელი შორთქათებია ხელმისაწვდომი.
+
+<!-- IMG #7 here -->
+
+და-mute-ული საკითხები აღარ გამოჩნდება როგორც წაუკითხავი მანამ, სანამ კიდევ ერთხელ არ იქნებით @ნახსენები. იდეალური სტრატეგიაა იმ იშუებისთვის, რომლებშიც ნაკლებად ხართ დაინტერესებული(ან შესაძლოა იყოს ისეთი ქვესისტემა, რომელშიც ნაკლებად ხართ გარკვეული). თუ იშუს მონიშნავთ როგორც წაკითხულს, მაშინ იშუ წაკითხული დარჩება მანამ, სანამ სხვა არ დააკომენტარებს.
+
+GitHub ასინქრონირებს წაკითხულ/წაუკითხავ სტატუსებს იმეილ ნოტიფიკაციებისთვისაც - თუ თქვენ წაიკითხავთ ნოტიფიკაციას იმეილ კლიენტში, მაშინ ვებ ინტერფეისში აღნიშნული იქნება როგორც წაკითხული.
+
+
+# @mentions
+
+@mentions არის გზა, რითაც შეგვიძლია სხვა GitHub მომხმარებლები მოვიხსენიოთ იშუებში. არ აქვს მნიშვნელობა ეს იქნება იშუს აღწერა თუ კომენტარი. @მომხმარებლის_username საშუალებით მომხმარებელს ეგზავნება ნოტიფიკაცია. (თუ გქონიათ შეხება Twitter-თან, მაშინ ზუსტად მსგავსი პრინციპია აქაც).
+
+ზემოხსენებული ფუნქცია გამოსადეგია მაშინ, როდესაც კონკრეტულად იცით, თუ რომელი მომხმარებლები მოიხსენიოთ, მაგრამ არის შემთხვევები, როდესაც გუნდებს შორის მუშაობთ და ზუსტად არ იცით ვის შეუძლია თქვენი დახმარება. @mention-ები მუშაობენ გუნდებისთვისაც. პირობითად, თუ თქვენ შექმნით გუნდს `browser-bugs` @acmeinc ორგანიზაციაში, მაშინ შეგეძლებათ დაამენშენოთ მთლიანი გუნდი:
+
+> /cc @acmeinc/browser-bugs
+
+ამ ბრძანების საშუალებით ნოტიფიკაცია გაეგზავნება `browser-bugs`-ის გუნდის წევრებს.
+
+
+
+# References
+
+ხშირია შემთხვევები, როდესაც ერთი იშუ დაკავშირებულია მეორესთან. ასეთ დროს შესაძლებელია დააკავშიროთ ერთი იშუ მეორესთან <kbd>#</kbd>+Issue ნომერი.
+
+> @georgetsouvaltzis, მემგონი ამ საკითხზე მსგავსი იშუ უკვე არსებობს: #42
+
+როდესაც მოიხსენიებთ იშუს #42(პირობითად), #42 იშუში შეიქმნება შეტყობინება, რომელიც გამოიყურება დაახლოებით ასე:
+
+<!-- IMG #8 here-->
+
+
+იშუს მოხსენიება სხვა რეპოზიტორიაში? შესაძლებელია! უბრალოდ წინ თან დაურთეთ რეპოზიტორიის სახელი. მაგალითი: `georgetsouvaltzis/example-project#42
+
+
+# Search
+
+ყველა გვერდის თავში, არსებობს ძებნის ბოქსი, რომლის საშუალებითაც იშუებში შესაძლოა მოიძიოთ სასურველი შედეგი.
+
+ძებნაში შესაძლებელია: 
+
+* keyword (საკვანძო სიტყვა). მაგალითად: ყველა იშუ, რომელშიც მოხსენიებულია სიტყვა sidebar
+
+* state (სტადია). მაგალითად: ყველა იშუ, რომელშიც მოხსენიებულია სიტყვა sidebar და არის დახურული
+
+* assignee, მაგალითად: ყველა იშუ, რომელშიც მოხსენიებულია სიტყვა sidebar და დაესაინებული იყო @georgetsouvaltzis-ზე.
+
+
+# Overview & Reports
+
+იშუების სექციის გარეთ, არსებობს ორი გვერდი, რომელიც გეხმარებათ შეაჯამოთ თუ რა ხდება თქვენს რეპოზიტორიში/ყველა რეპოზიტორიში არსებულ იშუებში.
+
+
+### იშუების Dashboard
+
+თუ გსურთ უფრო ფართოდ და თვალნათლივ დაინახოთ პროექტებში არსებული იშუები, მაშინ [Issues Dashboard](https://github.com/issues) ზედგამოჭრილი ხელსაწყოა. დეშბორდი ზუსტად იმავე პრინციპით მუშაობს, როგორიც იშუ სექციაშია, მაგრამ განსხვავდება იმით, რომ კრებს იშუებს სხვაგვარად:
+
+* ყველა იშუები რეპოზიტორიებში, რომლებსაც შენ ფლობ და ეწევი კოლაბორაციას.
+* იშუები, რომლებიც მობმულია თქვენზე
+* იშუები, რომლებიც შექმნილია თქვენ მიერ.
+
+
+
+# იშუების სხვა გამოყენებები
+
+[Bug tracker for your open source projects](https://github.com/nodejs/node-v0.x-archive/issues)
+
+
+# დასასრული
+
+ახლა უკვე თამამად შეგიძლიათ მიულოცოთ თქვენს თავს - ვიცი და მესმის, რომ საკმაოდ ბევრი იყო წასაკითხად :), მაგრამ იშუების მენეჯმენტი არის ერთ-ერთი მნიშვნელოვანი ხელსაწყო ნებისმიერ დეველოპმენტ გარემოში!
+
+
+
+
+
diff --git a/git.md b/git.md
deleted file mode 100644
index 5182edc..0000000
--- a/git.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-description: >-
-  სათარგმნი მასალა:
-  https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/GitHub
----
-
-# Git
-