Αλλαξα το rebase από 'επανατοποθέτηση' σε 'αλλαγή βάσης'

Author: csaragiotis

book/03-git-branching/1-git-branching.asc

@@ -28,5 +28,5 @@ include::sections/rebasing.asc[]
 
 Καλύψαμε τα βασικά της δημιουργίας και συγχώνευσης κλάδων στο Git.
 Πλέον αισθανόμαστε αυτοπεποίθηση να δημιουργούμε κλάδους, να μεταβαίνουμε σε αυτούς και να συγχωνεύουμε τοπικούς κλάδους. 
-Ακόμα μπορούμε να μοιραζόμαστε τους κλάδους μας ωθώντας τους σε έναν κοινόχρηστο διακομιστή, να δουλεύουμε με άλλους σε κοινούς κλάδους και να επανατοποθετούμε τους κλάδους μας προτού τους μοιραστούμε με άλλους. 
+Ακόμα μπορούμε να μοιραζόμαστε τους κλάδους μας ωθώντας τους σε έναν κοινόχρηστο διακομιστή, να δουλεύουμε με άλλους σε κοινούς κλάδους και να αλλάζουμε τη βάση των κλάδων μας προτού τους μοιραστούμε με άλλους. 
 Στη συνέχεια θα εξετάσουμε τι χρειάζεται ώστε να λειτουργήσουμε έναν δικό μας διακομιστή που θα φιλοξενεί ένα αποθετήριο Git.

book/03-git-branching/sections/rebasing.asc

@@ -73,7 +73,7 @@ image::images/git-diff-check.png[Έξοδος μίας `git diff --check`.]
 αντιμετωπίζεται ως το θέμα ενός e-mail και οι υπόλοιπες ως το σώμα του.
 Η κενή γραμμή που χωρίζει την περίληψη από τη λεπτομερή περιγραφή 
 είναι κρίσιμη (εκτός κι αν η λεπτομερής περιγραφή παραλείπεται 
-τελείως)· εργαλεία όπως η επανατοποθέτηση (rebase) μπορεί να  
+τελείως)· εργαλεία όπως η αλλαγή βάσης (rebase) μπορεί να  
 μπερδευτούν όταν τρέχουμε ταυτόχρονα.
 
 Περαιτέρω παράγραφοι έρχονται μετά από κενές γραμμές.
@@ -506,7 +506,7 @@ $ git commit
 
 [ΣΗΜΕΙΩΣΗ]
 ====
-Ίσως θελήσουμε να χρησιμοποιήσουμε την εντολή `rebase -i` για να συναρμόσουμε την εργασία μας σε μία μόνο υποβολή ή να αναδιατάξουμε την εργασία μας στις υποβολές για να κάνουμε διευκολύνουμε τον συντηρητή να ελέγξει το επίθεμά μας --βλ. <<_rewriting_history>> για περισσότερες πληροφορίες σχετικά με τη διαδραστική επανατοποθέτηση.
+Ίσως θελήσουμε να χρησιμοποιήσουμε την εντολή `rebase -i` για να συναρμόσουμε την εργασία μας σε μία μόνο υποβολή ή να αναδιατάξουμε την εργασία μας στις υποβολές για να κάνουμε διευκολύνουμε τον συντηρητή να ελέγξει το επίθεμά μας --βλ. <<_rewriting_history>> για περισσότερες πληροφορίες σχετικά με τη διαδραστική αλλαγή βάσης.
 ====
 
 Όταν ολοκληρωθεί η εργασία στον κλάδο μας και είμαστε έτοιμοι να τον επιστρέψουμε στους διαχειριστές, μεταβαίνουμε στην αρχική σελίδα του έργου και κάνουμε κλικ στο κουμπί ``Fork'', ώστε να δημιουργήσουμε τη δική μας εγγράψιμη διχάλα του έργου.
@@ -556,7 +556,7 @@ Jessica Smith (2):
 Η έξοδος μπορεί να αποσταλεί στον συντηρητή --του λέει από όπου διακλαδώθηκε η δουλειά, συνοψίζει τις υποβολές και λέει από πού να έλξει αυτήν τη δουλειά.
 
 Σε ένα έργο, στο οποίο δεν είμαστε συντηρητές, είναι γενικά ευκολότερο να έχουμε έναν κλάδο όπως ο `master` να παρακολουθεί πάντα τον `origin/master` και να σδουλεύουμε σε θεματικούς κλάδους τους οποίους μπορούμε εύκολα να διαγράψουμε αν απορριφθούν.
-Η διατήρηση ξεχωριστών θεματικών κλάδων για διαφορετικά θέματα διευκολύνει επίσης την επανατοποθέτηση της εργασίας μας, αν η άκρη του κύριου αποθετηρίου έχει μετακινηθεί εν τω μεταξύ και οι υποβολές μας δεν εφαρμόζονται πλέον με καθαρό τρόπο.
+Η διατήρηση ξεχωριστών θεματικών κλάδων για διαφορετικά θέματα διευκολύνει επίσης την αλλαγή βάσης της εργασίας μας, αν η άκρη του κύριου αποθετηρίου έχει μετακινηθεί εν τω μεταξύ και οι υποβολές μας δεν εφαρμόζονται πλέον με καθαρό τρόπο.
 Για παράδειγμα, εάν θέλουμε να δημιουργήσουμε ένα δεύτερο θέμα στο έργο, καλό είναι να μην συνεχίζουμε να εργαζόμαστε στον κλάδο του θέματος το οποίο μόλις ωθήσαμε, αλλά να ξεκινήσουμε από τον κλάδο `master` του αποθετηρίου:
 
 [source,console]
@@ -575,7 +575,7 @@ $ git fetch origin
 image::images/public-small-1.png[Αρχικό ιστορικό υποβολών με τη δουλειά στο `featureB`.]
 
 Ας υποθέσουμε ότι ο συντηρητής του έργου έχει έλξει κάμποσα επιθέματα κώδικα και έχει δοκιμάσει τον πρώτο μας κλάδο, αλλά πλέον δεν συγχωνεύεται παστρικά.
-Σε αυτήν την περίπτωση, μπορούμε να προσπαθήσουμε να επανατοποθετήσουμε αυτόν τον κλάδο στην κορυφή του κλάδου `origin/master`, να επιλύσουμε τις συγκρούσεις για τον διαχειριστή και στη συνέχεια να ωθήσουμε εκ νέου τις αλλαγές μας:
+Σε αυτήν την περίπτωση, μπορούμε να προσπαθήσουμε να αλλάξουμε τη βάση αυτού του κλάδου στην κορυφή του κλάδου `origin/master`, να επιλύσουμε τις συγκρούσεις για τον διαχειριστή και στη συνέχεια να ωθήσουμε εκ νέου τις αλλαγές μας:
 
 [source,console]
 -----
@@ -590,7 +590,7 @@ $ git push -f myfork featureA
 .Ιστορικό υποβολών μετά τη δουλειά στο `featureA`.
 image::images/public-small-2.png[Ιστορικό υποβολών μετά τη δουλειά στο `featureA`.]
 
-Επειδή επανατοποθετήσαμε τον κλάδο, πρέπει να χρησιμοποιήσουμε την επιλογή `-f` στην εντολή `push`, ώστε να  μπορέσουμε να αντικαταστήσουμε τον κλάδο `featureA` στον διακομιστή με μια υποβολή που δεν είναι απόγονος του.
+Επειδή αλλάξαμε τη βάση του κλάδου, πρέπει να χρησιμοποιήσουμε την επιλογή `-f` στην εντολή `push`, ώστε να  μπορέσουμε να αντικαταστήσουμε τον κλάδο `featureA` στον διακομιστή με μια υποβολή που δεν είναι απόγονος του.
 Μια εναλλακτική λύση θα ήταν να ωθήσουμε αυτήν τη νέα δουλειά σε ένα διαφορετικό κλάδο στον διακομίστή (ίσως με όνομα `featureAv2`).
 
 Ας δούμε ένα ακόμα πιθανό σενάριο: ο διαχειριστής έχει εξετάσει την εργασία στον δεύτερό μας κλάδο και του αρέσει η ιδέα, αλλά θα ήθελε να αλλάξουμε μια-δυο λεπτομέρειες στην υλοποίησή της.

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

@@ -69,10 +69,10 @@ image::images/integration-manager.png[Ροή εργασίας με διαχει
 Το αποθετήριο του καλόβουλου δικτάτορα χρησιμεύει ως αποθετήριο αναφοράς από το οποίο όλοι οι συνεργάτες πρέπει να έλξουν (αρχεία).
 Η διαδικασία λειτουργεί έτσι (βλ. <<wfdiag_c>>):
 
-1. Οι απλοί προγραμματιστές ασχολούνται με τον θεματικό κλάδο τους και επανατοποθετούν την εργασία τους στον κλάδο `master`. Ο κλάδος `master` είναι αυτός του δικτάτορα.
-2. Οι υπολοχαγοί συγχωνεύουν τους κλάδους των προγραμματιστών ο καθένας στον δικό του στον κλάδο `master`.
-3. Ο δικτάτορας συγχωνεύει τους κλάδους των ``υπολοχαγών'' των υπολοχαγών στον κλάδο `master`του δικτάτορα.
-4. Ο δικτάτορας σπρώχνει τον δικό του κλάδο `master` στο αποθετήριο αναφοράς, έτσι ώστε οι άλλοι προγραμματιστές να μπορέσουν να επανατοποθετηθούν.
+0. Οι απλοί προγραμματιστές ασχολούνται με τον θεματικό κλάδο τους και αλλάζουν τη βάση της εργασίας τους στον κλάδο `master`. Ο κλάδος `master` είναι αυτός του δικτάτορα.
+0. Οι υπολοχαγοί συγχωνεύουν τους κλάδους των προγραμματιστών ο καθένας στον δικό του στον κλάδο `master`.
+0. Ο δικτάτορας συγχωνεύει τους κλάδους των ``υπολοχαγών'' των υπολοχαγών στον κλάδο `master`του δικτάτορα.
+0. Ο δικτάτορας σπρώχνει τον δικό του κλάδο `master` στο αποθετήριο αναφοράς, έτσι ώστε οι άλλοι προγραμματιστές να μπορέσουν να αλλάξουν τη βάση τους σε αυτόν.
 
 [[wfdiag_c]]
 .Ροή εργασίας με καλόβουλο δικτάτορα.

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

@@ -136,7 +136,7 @@ If you would prefer to skip this patch, instead run "git am --skip".
 To restore the original branch and stop patching run "git am --abort".
 -----
 
-Αυτή η εντολή τοποθετεί σημάνσεις σύγκρουσης σε όλα τα αρχεία με τα οποία αντιμετωπίζει προβλήματα, όπως μια σύγκρουση σε συγχώνευσης ή επανατοποθέτηση.
+Αυτή η εντολή τοποθετεί σημάνσεις σύγκρουσης σε όλα τα αρχεία με τα οποία αντιμετωπίζει προβλήματα, όπως μια σύγκρουση συγχώνευσης ή αλλαγής βάσης.
 Μπορούμε να επιλύσουμε αυτό το πρόβλημα λίγο-πολύ με τον ίδιο τρόπο --επεξεργαζόμαστε το αρχείο για να επιλύσουμε τη σύγκρουση, τοποθετούμε το νέο αρχείο στο ενδιάμεσο στάδιο και στη συνέχεια να εκτελούμε την `git am --resolved` για να συνεχίσουμε στο επόμενο επίθεμα:
 
 [source,console]
@@ -356,7 +356,7 @@ image::images/large-merges-2.png[Η συγχώνευση ενσωμάτωσε θ
 Έτσι, όταν κλωνοποιούμε το αποθετήριο Git, έχουμε τέσσερις κλάδους στους οποίους μπορούμε να μεταβούμε  για να αξιολογήσουμε το έργο σε διαφορετικά στάδια ανάπτυξης, ανάλογα με το πόσο αιχμής θέλουμε να είμαστε ή πώς θέλουμε να συνεισφέρουμε· και ο συντηρητής έχει μια δομημένη ροή εργασίας για να τους βοηθήσει να ελέγξουν νέες συνεισφορές.
 
 [[_rebase_cherry_pick]]
-===== Ροές εργασίας επανατοποθέτησης και ανθολόγησης
+===== Ροές εργασίας με αλλαγή βάσης και ανθολόγηση
 
 (((workflows, rebasing and cherry-picking)))
 Άλλοι συντηρητές προτιμούν να επανατοποθετούν ή να ανθολογούν (cherry-pick) τις συνεισφορές στην κορυφή του κύριου κλάδου τους, αντί να τις συγχωνεύουν, για να διατηρήσουν ένα κατά βάση γραμμικό ιστορικό.
@@ -366,9 +366,9 @@ image::images/large-merges-2.png[Η συγχώνευση ενσωμάτωσε θ
 
 (((εντολές git, cherry-pick)))
 Ο άλλος τρόπος για να μετακινήσουμε εργασία που εισάγεται από τον ένα κλάδο στον άλλο είναι η ανθολόγησή (cherry-pick) του.
-Η ανθολόγηση στο Git είναι σαν μια επανατοποθέτηση μίας μόνο υποβολής.
+Η ανθολόγηση στο Git είναι σαν μια αλλαγή βάσης μίας μόνο υποβολής.
 Παίρνει το επίθεμα που εισήχθη σε μια υποβολή και προσπαθεί να το ξαναεφαρμόσει στον κλάδο στον οποίο βρισκόμαστε αυτήν τη στιγμή.
-Η ανθολόγηση είναι χρήσιμη εάν έχουμε αρκετές υποβολές σε έναν θεματικό κλάδο και θέλουμε να ενσωματώσουμε μόνο μία από αυτές ή εάν έχουμε μόνο μία υποβολή σε έναν θεματικό κλάδο και προτιμάμε να την ανθολογήσουμε αντί να την επανατοποθετήσουμε.
+Η ανθολόγηση είναι χρήσιμη εάν έχουμε αρκετές υποβολές σε έναν θεματικό κλάδο και θέλουμε να ενσωματώσουμε μόνο μία από αυτές ή εάν έχουμε μόνο μία υποβολή σε έναν θεματικό κλάδο και προτιμάμε να την ανθολογήσουμε αντί να αλλάξουμε τη βάση της.
 Για παράδειγμα, ας υποθέσουμε ότι έχουμε ένα έργο που μοιάζει με αυτό:
 
 .Παράδειγμα ιστορικού πριν την ανθολόγηση.
@@ -395,7 +395,7 @@ image::images/rebasing-2.png[Ιστορικό μετά την ανθολόγησ
 ===== Rerere
 
 (((εντολές git, rerere)))(((rerere)))
-Εάν κάνουμε πολλές συγχωνεύσεις και επανατοποθετήσεις ή διατηρούμε ένα μακρόβιο θεματικό κλάδο, το Git διαθέτει μια λειτουργία που λέγεται ``rerere'' και η οποία μπορεί να μας βοηθήσει.
+Εάν κάνουμε πολλές συγχωνεύσεις και αλλαγές βάσης ή διατηρούμε ένα μακρόβιο θεματικό κλάδο, το Git διαθέτει μια λειτουργία που λέγεται ``rerere'' και η οποία μπορεί να μας βοηθήσει.
 
 `rerere` σημαίνει ``επαναχρησιμοποίηση καταγεγραμμένης επίλυσης'' (``reuse recorded resolution'') – είναι ένας τρόπος σύντομης αντιμετώπισης της μη-αυτόματης επίλυσης συγκρούσεων.
 Όταν η rerere είναι ενεργοποιημένη, το Git διατηρεί ένα σύνολο προ- και μετα- εικόνων από επιτυχείς συγχωνεύσεις και αν παρατηρήσει ότι υπάρχει μια σύγκρουση που μοιάζει ακριβώς με μία που έχουμε ήδη επιλύσει, θα χρησιμοποιήσει απλώς το επίθεμα από την τελευταία φορά, χωρίς να μας ενοχλήσει.