Resolved pull confilict.

Author: csaragiotis

TRANSLATION_NOTES.asc

@@ -12,7 +12,6 @@ A
 *attribute* → γνώρισμα +
 *authenticate/authentication* → ταυτοποιώ/ταυτοποίηση +
 
-
 B
 ~
 *Branch (branches)* → Κλάδος (κλάδοι) +
@@ -35,13 +34,14 @@ D
 F
 ~
 *fast-forward* → ταχυπροώθηση + 
-*fork* (n.) → διχάλα (σε αναζήτηση καλύτερης μετάφρασης --καλά θα ήταν το ρήμα και το ουσιαστικό να έχουν την ίδια ρίζα) +
+*fork* (n.) → διχάλα (σε αναζήτηση καλύτερης μετάφρασης). Στο site της Microsoft αναφέρεται ως ``διπλότυπο'' --καλά θα ήταν το ρήμα και το ουσιαστικό να έχουν την ίδια ρίζα) +
 *fork* (v.) → αποσχίζω (σε αναζήτηση καλύτερης μετάφρασης --ίσως αποστασιοποιώ; καλά θα ήταν το ρήμα και το ουσιαστικό να έχουν την ίδια ρίζα)
 
 H
 ~
 *hook* → άγκιστρο + 
 
+
 I
 ~
 *issue* → ζήτημα
@@ -84,7 +84,7 @@ S
 *stable* (for code) → ευσταθής (όχι σταθερός) + 
 *stablility* → ευστάθεια (όχι σταθερότητα) + 
 *Stage* → Καταχωρώ +
-*Staging area* → Περιοχή καταχώρησης
+*Staging area* → Περιοχή καταχώρησης + 
 *Stash* → Εναποθέτω
 
 T

book/04-git-server/sections/hosted.asc

@@ -2,6 +2,6 @@
 
 Εάν δεν θέλουμε να υποστούμε όλες τις εργασίες που εμπλέκονται στην εγκατάσταση του δικού μας διακομιστή Git, έχουμε αρκετές επιλογές για τη φιλοξενία των έργων μας σε έναν εξωτερικό, αποκλειστικό ιστότοπο φιλοξενίας. Αυτή η επιλογή προσφέρει κάποια πλεονεκτήματα: ένας χώρος φιλοξενίας στήνεται γενικά γρήγορα και είναι εύκολο να ξεκινήσουν έργα σε αυτόν, ενώ δεν εμπλέκεται συντήρηση ή παρακολούθηση του διακομιστή. Ακόμα κι αν έχουμε εγκαταστήσει και τρέξει εσωτερικά τον δικό μας διακομιστή, μπορεί να θέλουμε να χρησιμοποιήσουμε έναν δημόσιο ιστότοπο φιλοξενίας για τον ανοιχτό κώδικά μας --είναι γενικά ευκολότερο για την κοινότητα ανοιχτού κώδικα να μας βρει και να μας βοηθήσει.
 
-Πλέον, υπάρχει ένας τεράστιος αριθμός επιλογών φιλοξενίας από τους οποίους μπορούμε να διαλέξουμε, η κάθε μία με διαφορετικά πλεονεκτήματα και μειονεκτήματα. Μπορούμε να βρούμε μια ενημερωμένη λίστα στη σελίδα GitHosting στο κύριο wiki Git στην διεύθυνση https://git.wiki.kernel.org/index.php/GitHosting[].
+Πλέον, υπάρχει ένας τεράστιος αριθμός επιλογών φιλοξενίας από τους οποίους μπορούμε να διαλέξουμε, η κάθε μία με διαφορετικά πλεονεκτήματα και μειονεκτήματα. Μπορούμε να βρούμε μια ενημερωμένη λίστα στη σελίδα GitHosting στο κύριο wiki Git στη διεύθυνση https://git.wiki.kernel.org/index.php/GitHosting[].
 
 Θα καλύψουμε τη χρήση του GitHub στο κεφάλαιο <<_github>>, καθώς είναι ο μεγαλύτερος διακομιστής Git και ούτως ή άλλως ίσως χρειαστεί να αλληλεπιδράσουμε με τα έργα που φιλοξενούνται σε αυτόν, αλλά υπάρχουν και άλλοι δεκάδες διακομιστές Git από τους οποίους μπορούμε επιλέξουμε εφόσον δεν θέλουμε να δημιουργήσουμε τον δικό μας διακομιστή Git.

book/05-distributed-git/sections/contributing.asc

@@ -625,7 +625,7 @@ image::images/public-small-3.png[Ιστορικό υποβολών μετά τη
 ==== Δημόσιο έργο μέσω e-mail
 
 (((contributing, public large project)))
-Πολλά έργα έχουν θεσπίσει διαδικασίες για την αποδοχή των μπαλωμάτων --θα πρέπει να ελέγξουμε τους συγκεκριμένους κανόνες του έργου, επειδή θα διαφέρουν.
+Πολλά έργα έχουν θεσπίσει διαδικασίες για την αποδοχή των επιδιορθώσεων --θα πρέπει να ελέγξουμε τους συγκεκριμένους κανόνες του έργου, επειδή θα διαφέρουν.
 Δεδομένου ότι υπάρχουν πολλά παλαιότερα, μεγαλύτερα έργα που αποδέχονται επιδιορθώσεις μέσω μιας λίστας ηλεκτρονικής αλληλογραφίας προγραμματιστών, θα εξετάσουμε ένα τέτοιο παράδειγμα.
 
 Η ροή εργασίας είναι παρόμοια με την προηγούμενη περίπτωση --δημιουργούμε θεματικούς κλάδους έναν για κάθε σειρά επιδιόρθωσης λογισμικού στην οποία εργαζόμαστε.
@@ -712,7 +712,7 @@ index 76f47bc..f9815f1 100644
 -----
 
 Αν ο διακομιστής IMAP δεν χρησιμοποιεί SSL, οι δύο τελευταίες γραμμές πιθανώς δεν είναι απαραίτητες και η τιμή `host` θα είναι `imap://` αντί για 'imaps://`.
-Όταν έχει ρυθμιστεί το αρχείο `~/.gitconfig`, μπορούμε να χρησιμοποιήσουμε την `git imap-send` για να τοποθετήσουμε τη σειρά μπαλωμάτων στον φάκελο ``Πρόχειρα'' (``Drafts'') του καθορισμένου διακομιστή IMAP:
+Όταν έχει ρυθμιστεί το αρχείο `~/.gitconfig`, μπορούμε να χρησιμοποιήσουμε την `git imap-send` για να τοποθετήσουμε τη σειρά επιδιορθώσεων στον φάκελο ``Πρόχειρα'' (``Drafts'') του καθορισμένου διακομιστή IMAP:
 
 [source,console]
 -----

book/06-github/sections/3-maintaining.asc

@@ -21,7 +21,7 @@ image::images/new-repo.png[Η αναπτυσσόμενη λίστα ``New reposi
 image::images/newrepoform.png[Η φόρμα ``New repository''.]
 
 Το μόνο που έχουμε να κάνουμε εδώ είναι να δώσουμε ένα όνομα έργου. τα υπόλοιπα πεδία είναι εντελώς προαιρετικά.
-Προς το παρόν, απλώς κάνουμε κλικ στο κουμπί ``Create Repository'' και αμέσως έχουμε ένα νέο αποθετήριο στο GitHub, το οποίο ονομάζεται `<user>/<project_name>`.
+Προς το παρόν, απλά κάνουμε κλικ στο κουμπί ``Create Repository'' και αμέσως έχουμε ένα νέο αποθετήριο στο GitHub, το οποίο ονομάζεται `<user>/<project_name>`.
 
 Εφόσον δεν έχουμε ακόμα κανένα κώδικα, το GitHub θα μας δείξει οδηγίες για τον τρόπο δημιουργίας ενός ολοκαίνουργιου αποθετηρίου Git ή τη σύνδεση ενός υπάρχοντος έργου Git.
 Δεν θα εντρυφήσουμε εδώ· τα σχετικά υπάρχουν στο κεφάλαιο <<_git_basics_chapter>>.
@@ -58,9 +58,7 @@ image::images/collaborators.png[Το πλαίσιο με τους συνεργά
 
 ==== Διαχείριση αιτημάτων έλξης
 
-Now that you have a project with some code in it and maybe even a few collaborators who also have push access, let's go over what to do when you get a αίτημα έλξης yourself.
-
-Τώρα που έχουμε ένα έργο με κώδικα και ενδεχομένως μερικούς συνεργάτες που έχουν επίσης πρόσβαση ώθησης, ας δούμε τι πρέπει να κάνουμε όταν έχουμε ένα αίτημα έλξης.
+Τώρα που έχουμε ένα έργο με κώδικα και ενδεχομένως μερικούς συνεργάτες που έχουν πρόσβαση ώθησης, ας δούμε τι πρέπει να κάνουμε όταν έχουμε ένα αίτημα έλξης.
 
 Τα αιτήματα έλξης μπορεί είτε να προέρχεται από έναν κλάδο σε μία διχάλα του αποθετηρίου μας είτε μπορεί να προέρχεται από άλλον κλάδο στο ίδιο αποθετήριο.
 Η μόνη διαφορά είναι ότι αυτοί που βρίσκονται σε μία διχάλα είναι συχνά από χρήστες στων οποίων τους κλάδους δεν μπορούμε να ωθήσουμε όπως και αυτοί δεν μπορούν να ωθήσουν προς τους δικούς μας, ενώ με τα εσωτερικά αιτήματα έλξης γενικά και τα δύο μέρη έχουν πρόσβαση στον κλάδο.
@@ -121,8 +119,8 @@ image::images/maint-02-merge.png[Κουμπί ``Merge'']
 [[_pr_refs]]
 ===== Refs αιτημάτων έλξης
 
-Εάν έχουμε να κάνουμε με *πολλά* αιτήματα έλξης και δεν θέλουμε να προσθέσουμε πολλά απομακρυσμένα αποπετήρια ή να κάνουμε μία έλξη κάθε φορά, υπάρχει ένα ωραίο κόλπο το οποίο το GitHub μας επιτρέπει να κάνουμε.
-Αυτό είναι ένα λίγο προηγμένο τέχνασμα και θα δούμε τις λεπτομέρειές του σε μεγαλύτερο βάθος στην ενότητα <<_refspec>>, αλλά μπορεί να είναι αρκετά χρήσιμο.
+Εάν έχουμε να κάνουμε με *πολλά* αιτήματα έλξης και δεν θέλουμε να προσθέσουμε πολλά απομακρυσμένα αποθετήρια ή να κάνουμε μία έλξη κάθε φορά, υπάρχει ένα ωραίο κόλπο που μας επιτρέπει να κάνουμε το GitHub.
+είναι ένα λίγο προηγμένο τέχνασμα και θα δούμε τις λεπτομέρειές του σε μεγαλύτερο βάθος στην ενότητα <<_refspec>>, αλλά μπορεί να είναι αρκετά χρήσιμο.
 
 Το GitHub διαφημίζει τους κλάδους αιτημάτων έλξης ενός αποθετηρίου ως ένα είδος ψευδο-κλάδων στον διακομιστή.
 Από προεπιλογή δεν τους παίρνουμε όταν κλωνοποιούμε, αλλά είναι εκεί με κάποιον ασαφή και ομιχλώδη τρόπο και μπορούμε να έχουμε αρκετά εύκολα πρόσβαση σε αυτά.
@@ -151,8 +149,8 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a	refs/pull/4/head
 Αυτές είναι ουσιαστικά κλάδοι, αλλά επειδή δεν βρίσκονται κάτω από `refs/heads/`, δεν τις παίρνουμε όταν κλωνοποιούμε ή ανακτούμε από το διακομιστή --η διαδικασία της ανάκτησης τους αγνοεί κανονικά.
 
 Υπάρχουν δύο αναφορές ανά αίτημα έλξης --αυτή που τελειώνει σε σημεία `/head` δείχνει στην ίδια ακριβώς υποβολή με την τελευταία υποβολή στον κλάδο του αιτήματος έλξης.
-Έτσι, αν κάποιος υποβάλει ένα αίτημα έλξης στο αποθετήριό μας και ο κλάδος του ονομάζεται `bug-fix` και δείχνει στην υποβολή `a5a775`, τότε στο αποθετήριό *μας* δεν θα έχουμε κλάδο `bug fix ' (αφού αυτός βρίσκεται στην διχάλα του), αλλά θα έχουμε `pull/<pr#>/head` που δείχνει στην `a5a775`.
-Αυτό σημαίνει ότι μπορούμε πολύ εύκολα να έλξουμε κάθε κλάδο αιτήματος έλκυσης χωρίς να χρειαστεί να προσθέσουμε μια δέσμη τηλεχειριστηρίων.
+Έτσι, αν κάποιος υποβάλει ένα αίτημα έλξης στο αποθετήριό μας και ο κλάδος του ονομάζεται `bug-fix` και δείχνει στην υποβολή `a5a775`, τότε στο *δικό μας* αποθετήριο δεν θα έχουμε κλάδο `bug-fix ' (αφού αυτός βρίσκεται στη διχάλα του), αλλά θα έχουμε `pull/<pr#>/head` που δείχνει στην `a5a775`.
+Αυτό σημαίνει ότι μπορούμε πολύ εύκολα να έλξουμε κάθε κλάδο αιτήματος έλξης χωρίς να χρειαστεί να προσθέσουμε κάμποσα απομακρυσμένα αποθετήρια.
 
 Τώρα, μπορούμε να ανακτήσουμε απευθείας την αναφορά.
 
@@ -164,8 +162,8 @@ From https://github.com/libgit2/libgit2
 ----
 
 Αυτό λέει στο Git, ``συνδέσου στο απομακρυσμένο αποθετήριο `origin` και κατέβασε το ref με όνομα `refs/pull/958/head`''.
-Το Git υπακούει και κατεβάζει ό,τι χρειάζόμαστε για να κατασκευάσουμε αυτό το ref και βάζει έναν δείκτη στην υποβολή που θέλουμε κάτω από το `.git / FETCH_HEAD`.
-Μπορούμε να την συγχωνεύσουμε με την `git merge FETCH_HEAD` σε έναν κλάδο στον οποίο θέλουμε να το δοκιμάσουμε, αλλά αυτό το μήνυμα συγχώνευσης φαίνεται λίγο παράξενο.
+Το Git υπακούει και κατεβάζει ό,τι χρειαζόμαστε για να κατασκευάσουμε αυτό το ref και βάζει έναν δείκτη στην υποβολή που θέλουμε στο αρχείο `.git/FETCH_HEAD`.
+Μπορούμε να την συγχωνεύσουμε με την εντολή `git merge FETCH_HEAD` σε έναν κλάδο στον οποίο θέλουμε να το δοκιμάσουμε, αλλά αυτό το μήνυμα συγχώνευσης φαίνεται λίγο παράξενο.
 Επίσης, εάν εξετάζουμε *πολλά* αιτήματα έλξης, κάτι τέτοιο γίνεται κουραστικό.
 
 Υπάρχει επίσης ένας τρόπος για να ανακτήσουμε _όλα_ τα αιτήματα έλξης και να τα κρατάμε ενημερωμένα κάθε φορά που συνδεόμαστε στο απομακρυσμένο αποθετήριο.
@@ -240,7 +238,7 @@ image::images/maint-04-target.png[Χειροκίνητη αλλαγή της δ
 
 Σε οποιοδήποτε σχόλιο αν αρχίσουμε να πληκτρολογούμε έναν χαρακτήρα `@` θα αρχίσει να συμπληρώνεται αυτόματα με τα ονόματα και τα ονόματα χρήστη των ατόμων που συνεργάζονται ή συνεισφέρουν στο έργο.
 
-.Πληκτρολογούμε @ για να μνημονεύσουμε κάποιον.
+.Πληκτρολογούμε `@` για να μνημονεύσουμε κάποιον.
 image::images/maint-05-mentions.png[Μνείες]
 
 Μπορούμε επίσης να μνημονεύσουμε έναν χρήστη που δεν βρίσκεται σε αυτό το αναπτυσσόμενο μενού, αλλά συχνά ο αυτόματος συμπυκνωτής το κάνει πιο γρήγορα.
@@ -277,7 +275,7 @@ image::images/maint-08-notifications-page.png[Κέντρο ειδοποιήσε
 
 Εάν κάνουμε κλικ σ' αυτό, θα δούμε μια λίστα με όλα τα στοιχεία για τα οποία έχουμε ειδοποιηθεί, ομαδοποιημένα κατά έργο.
 Μπορούμε να φιλτράρουμε τις ειδοποιήσεις ενός συγκεκριμένου έργου κάνοντας κλικ στο όνομά του στην αριστερή πλευρική μπάρα.
-Μπορούμε επίσης να επιβεβαιώσουμε την λήψη της ειδοποίησης κάνοντας κλικ στο εικονίδιο tick δίπλα σε οποιαδήποτε ειδοποίηση ή να επιβεβαιώσουμε την λήψη _όλων_ των ειδοποιήσεων σε ένα έργο κάνοντας κλικ στο εικονίδιο tick στο πάνω μέρος της ομάδας.
+Μπορούμε επίσης να επιβεβαιώσουμε τη λήψη της ειδοποίησης κάνοντας κλικ στο εικονίδιο tick δίπλα σε οποιαδήποτε ειδοποίηση ή να επιβεβαιώσουμε την λήψη _όλων_ των ειδοποιήσεων σε ένα έργο κάνοντας κλικ στο εικονίδιο tick στο πάνω μέρος της ομάδας.
 Υπάρχει επίσης ένα κουμπί σίγασης δίπλα σε κάθε σημάδι επιλογής στο οποίο μπορούμε να κάνουμε κλικ για να μην λαμβάνουμε άλλες ειδοποιήσεις σχετικά με το συγκεκριμένο στοιχείο.
 
 Όλα αυτά τα εργαλεία είναι πολύ χρήσιμα για τον χειρισμό μεγάλου αριθμού ειδοποιήσεων.

book/08-customizing-git/1-customizing-git.asc

@@ -1,7 +1,7 @@
 [[_customizing_git]]
 == Εξατομίκευση του Git
 
-Μέχρι στιγμής, έχουμε καλύψει τα βασικά σχετικά με τον τρόπο λειτουργίας του Git και τον τρόπο χρήσης του και έχουμε εισαγάγει διάφορα εργαλεία που παρέχει το Git για να μας βοηθήσει να το χρησιμοποιήσουε εύκολα και αποτελεσματικά.
+Μέχρι στιγμής, έχουμε καλύψει τα βασικά σχετικά με τον τρόπο λειτουργίας του Git και τον τρόπο χρήσης του και έχουμε εισάγει διάφορα εργαλεία που παρέχει το Git για να μας βοηθήσει να το χρησιμοποιήσουμε εύκολα και αποτελεσματικά.
 Σε αυτό το κεφάλαιο, θα δούμε πώς μπορούμε να κάνουμε το Git να λειτουργεί με πιο εξατομικευμένο τρόπο, εισάγοντας αρκετές σημαντικές ρυθμίσεις διαμόρφωσης και το σύστημα άγκιστρων.
 Με αυτά τα εργαλεία, είναι εύκολο να κάνουμε το Git να λειτουργεί ακριβώς όπως εμείς, η εταιρεία μας ή η ομάδα μας το θέλουμε να λειτουργεί.