diff --git a/.github/workflows/PR.yml b/.github/workflows/PR.yml new file mode 100644 index 000000000..39cd11936 --- /dev/null +++ b/.github/workflows/PR.yml @@ -0,0 +1,43 @@ +# This is a basic workflow to help you get started with Actions + +name: PR + +# Controls when the action will run. +on: + # Triggers the workflow on push or pull request events but only for the master branch + pull_request: + branches: [ master ] + + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: + +# A workflow run is made up of one or more jobs that can run sequentially or in parallel +jobs: + # This workflow contains a single job called "build" + build: + # The type of runner that the job will run on + runs-on: ubuntu-latest + + # Steps represent a sequence of tasks that will be executed as part of the job + steps: + # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it + - uses: actions/checkout@v2 + - name: Set up Ruby + # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby, + # change this to (see https://github.com/ruby/setup-ruby#versioning): + # uses: ruby/setup-ruby@v1 + uses: ruby/setup-ruby@v1 + with: + ruby-version: 2.6 + + # Runs a single command using the runners shell + - name: before install + run: | + wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh + sh bootstrap.sh + bundle install + - name: build book + env: + GITHUB_VERSION: "v0.0.0" + run: | + bundle exec rake book:build_action diff --git a/.github/workflows/release-on-merge.yml b/.github/workflows/release-on-merge.yml new file mode 100644 index 000000000..3c877b87b --- /dev/null +++ b/.github/workflows/release-on-merge.yml @@ -0,0 +1,42 @@ +name: Release on push to main + +on: + push: + branches: [ main, master ] + +jobs: + release: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + with: + fetch-depth: 0 + - name: get bootstrap file + run: wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh + - name: run bootstrap + run: sh bootstrap.sh + - name: Compute tag name + id: compute-tag + run: | + echo Computing next tag number + LASTPATCH=$(git describe --tags | cut -d- -f1 | cut -d. -f3) + PATCH=$(($LASTPATCH+1)) + echo "::set-output name=tagname::2.1.${PATCH}" + echo "::set-output name=branch::${GITHUB_REF#refs/heads/}" + + - name: Set up Ruby + uses: ruby/setup-ruby@v1 + with: + ruby-version: 2.7 + bundler-cache: true # runs 'bundle install' and caches installed gems automatically + + - name: Build release assets + run: bundle exec rake book:build_action + + - name: Create release + uses: ncipollo/release-action@v1 + with: + token: ${{ secrets.GITHUB_TOKEN }} + tag: ${{ steps.compute-tag.outputs.tagname }} + commit: ${{ steps.compute-tag.outputs.branch }} + artifacts: './progit.epub,./progit.mobi,./progit.pdf,./progit.html' diff --git a/.gitignore b/.gitignore index 94edaae9a..aa9b3a0a0 100644 --- a/.gitignore +++ b/.gitignore @@ -2,10 +2,12 @@ output .DS_Store # build artifacts +Gemfile.lock progit.html progit.pdf progit.pdfmarks progit.epub +progit.fb2.zip progit-kf8.epub progit.mobi -/images/ +contributors.txt \ No newline at end of file diff --git a/.mailmap b/.mailmap new file mode 100644 index 000000000..d64acd787 --- /dev/null +++ b/.mailmap @@ -0,0 +1,2 @@ +Jean-Noël Avila +Scott Chacon \ No newline at end of file diff --git a/.tgitconfig b/.tgitconfig new file mode 100644 index 000000000..a1a520376 --- /dev/null +++ b/.tgitconfig @@ -0,0 +1,6 @@ +[bugtraq] + url = https://github.com/progit/progit2/issues/%BUGID% + logregex = "(?:[Cc]lose[sd]?|[Ff]ix(?:e[sd])?|[Rr]esolve[sd]?):?\\s+(?:[Ii]ssues?\\s+#?|#)\\d+(?:(?:,|\\s+and)\\s+(?:[Ii]ssues?\\s+#?|#)\\d+)*\n(\\d+)" + +[tgit] + icon = Pro.ico diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000000000..cd6f15ad8 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,34 @@ +language: ruby +sudo: false +git: + depth: false +cache: bundler +before_install: + - wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh + - sh bootstrap.sh +script: bundle exec rake book:build +after_success: bundle exec rake book:tag +deploy: + provider: releases + file_glob: true + file: + - progit*.epub + - progit*.mobi + - progit*.pdf + skip_cleanup: true + on: + tags: true + api-key: $GITHUB_API_TOKEN +branches: + only: + - master + - /^2\.1(\.\d+)+$/ + +addons: + apt: + packages: + - epubcheck +notifications: + email: + on_success: never + on_failure: always diff --git a/A-git-in-other-environments.asc b/A-git-in-other-environments.asc new file mode 100644 index 000000000..0a1e9c87f --- /dev/null +++ b/A-git-in-other-environments.asc @@ -0,0 +1,28 @@ +[[A-git-in-other-environments]] +[appendix] +== Το Git σε άλλα περιβάλλοντα + +Αν διαβάσουμε όλο το βιβλίο, θα έχουμε μάθει πολλά για τον τρόπο χρήσης του Git στη γραμμή εντολών. +Μπορούμε να εργαστούμε με τοπικά αρχεία, να συνδέσουμε το αποθετήριό μας με άλλους μέσω ενός δικτύου και να εργαστούμε αποτελεσματικά με άλλους. +Αλλά η ιστορία δεν τελειώνει εκεί. Το Git χρησιμοποιείται συνήθως ως μέρος ενός μεγαλύτερου οικοσυστήματος και το τερματικό δεν είναι πάντα ο καλύτερος τρόπος για να εργαστούμε μαζί του. +Τώρα θα ρίξουμε μια ματιά σε μερικά από τα άλλα είδη περιβάλλοντος όπου το Git μπορεί να είναι χρήσιμο και πώς άλλες εφαρμογές (συμπεριλαμβανομένων και των δικών μας) λειτουργούν μαζί με το Git. + +include::book/A-git-in-other-environments/sections/guis.asc[] + +include::book/A-git-in-other-environments/sections/visualstudio.asc[] + +include::book/A-git-in-other-environments/sections/visualstudiocode.asc[] + +include::book/A-git-in-other-environments/sections/jetbrainsides.asc[] + +include::book/A-git-in-other-environments/sections/sublimetext.asc[] + +include::book/A-git-in-other-environments/sections/bash.asc[] + +include::book/A-git-in-other-environments/sections/zsh.asc[] + +include::book/A-git-in-other-environments/sections/powershell.asc[] + +=== Ανακεφαλαίωση + +Έχουμε μάθει πώς να αξιοποιούμε τη δύναμη του Git χρησιμοποιώντας εργαλεία καθημερινής χρήσης και επίσης πώς να αποκτούμε πρόσβαση στα αποθετήρια Git χρησιμοποιώντας δικά μας προγράμματα. diff --git a/B-embedding-git-in-your-applications.asc b/B-embedding-git-in-your-applications.asc new file mode 100644 index 000000000..c40c17112 --- /dev/null +++ b/B-embedding-git-in-your-applications.asc @@ -0,0 +1,19 @@ +[[B-embedding-git-in-your-applications]] +[appendix] +== Ενσωμάτωση του Git στις εφαρμογές μας + +Εάν η εφαρμογή μας απευθύνεται σε προγραμματιστές, οι πιθανότητες ότι θα επωφεληθούν από την ενοποίηση με τον έλεγχο εκδόσεων του πηγαίου κώδικα είναι πολλές. +Ακόμη και οι εφαρμογές που δεν αφορούν προγραμματιστές, όπως επεξεργασία εγγράφων, θα μπορούσαν ενδεχομένως να επωφεληθούν από τις λειτουργίες ελέγχου εκδόσεων και το μοντέλο του Git λειτουργεί πολύ καλά για πολλά διαφορετικά σενάρια. + +Εάν χρειάζεται να ενσωματώσουμε το Git με την εφαρμογή μας, έχουμε ουσιαστικά δύο επιλογές: α) εκκίνηση κελύφους και να καλέσουμε το `git` πρόγραμμα γραμμή-εντολής, ή να ενσωματώσουμε μια Git βιβλιοθήκη μέσα σστην εφαρμογή μας. +Εδώ θα καλύψουμε την ενσωμάτωση γραμμή-εντολής και μερικές από τις πιο γνωστές ενσωματώσιμες βιβλιοθήκες του Git. + +include::book/B-embedding-git/sections/command-line.asc[] + +include::book/B-embedding-git/sections/libgit2.asc[] + +include::book/B-embedding-git/sections/jgit.asc[] + +include::book/B-embedding-git/sections/go-git.asc[] + +include::book/B-embedding-git/sections/dulwich.asc[] diff --git a/C-git-commands.asc b/C-git-commands.asc new file mode 100644 index 000000000..f5d6ce218 --- /dev/null +++ b/C-git-commands.asc @@ -0,0 +1,581 @@ +[[C-git-commands]] +[appendix] +== Εντολές Git + +Σε όλο το βιβλίο έχουμε εισάγει δεκάδες εντολές Git και προσπαθήσαμε σκληρά να τις εισάγουμε μέσα σε ένα αφηγηματικό πλαίσιο, προσθέτοντας περισσότερες εντολές στην ιστορία αργά. +Ωστόσο, αυτό μας αφήνει με παραδείγματα χρήσης των εντολών κάπως διάσπαρτα σε όλο το βιβλίο. + +Σε αυτό το παράρτημα, θα διαπεράσουμε όλες τις εντολές Git που εξετάσαμε σε όλο το βιβλίο, χονδρικά ομαδοποιημένες με βάση τη χρήση τους. +Θα μιλήσουμε για το τι κάνει γενικά κάθε εντολή και στη συνέχεια να επισημάνουμε πού στο βιβλίο θα βρούμε τις χρήσεις τους. + +[TIP] +==== +Μπορείτε να συτνομεύσετε τις μεγάλες επιλογές. +Για παράδειγμα, μπορείτε να πληκτρολογήσετε `git commit --a`, το οποίο είναι σαν να πληκτρολογήσατε `git commit --amend`. +Αυτό λειτουργεί μόνο όταν τα γράμματα μετά `--` είναι μοναδικά για την κάθε επιλογή. +Να χρησιμοποείται ολόκληρη την επιλογή όταν γράφετε scripts. +==== + +=== Ρύθμιση και διαμόρφωση + +Υπάρχουν δύο εντολές που χρησιμοποιούνται αρκετά, από τις πρώτες επικλήσεις του Git σε κοινές καθημερινές μικροαλλαγές και αναφορές, οι εντολές `config` και `help`. + +==== git config + +Το Git έχει έναν προεπιλεγμένο τρόπο να κάνει εκατοντάδες πράγματα. +Για πολλά από αυτά τα πράγματα, μπορούμε να ενημερώσουμε το Git να τα κάνει με διαφορετικό προεπιλεγμένο τρόπο ή να ορίσουμε τις προτιμήσεις μας. +Αυτό περιλαμβάνει τα πάντα, από το να πούμε στο Git τι είναι το όνομά μας σε συγκεκριμένες προτιμήσεις χρώματος τερματικού ή ποιον επεξεργαστή κειμένου χρησιμοποιούμε. +Υπάρχουν πολλά αρχεία από τα οποία θα διαβάσει και στα οποία θα γράψει αυτή η εντολή, γι' αυτό μπορούμε να ορίσουμε τιμές σε καθολικό επίπεδο ή για συγκεκριμένα αποθετήρια. + +Η εντολή `git config` έχει χρησιμοποιηθεί σχεδόν σε κάθε κεφάλαιο του βιβλίου. + +Στην ενότητα <> τη χρησιμοποιούμε για να καθορίσουμε το όνομα, τη διεύθυνση e-mail και την προτίμηση μας για τον επεξεργαστή κειμένου προτού καν ξεκινήσουμε να χρησιμοποιούμε το Git. + +Στην ενότητα <> βλέπουμε πώς μπορούμε να τη χρησιμοποιήσουμε για να δημιουργήσουμε συντομογραφίες εντολών που επεκτείνονται σε μεγάλες ακολουθίες επιλογών, ώστε να μην χρειάζεται να τις πληκτρολογούμε κάθε φορά. + +Στην ενότητα <> τη χρησιμοποιούμε για να κάνουμε `--rebase` την προεπιλογή όταν τρέχουμε την `git pull`. + +Στην ενότητα <> τη χρησιμοποιούμε για να ρυθμίσουμε ένα προεπιλεγμένο κατάστημα για τους κωδικούς μας HTTP. + +Στην ενότητα <> βλέπουμε πώς να εγκαθιστούμε φίλτρα μουτζουρώματος και καθαρίσματος σε περιεχόμενο που εισέρχεται και εξέρχεται από το Git. + +Τέλος, το σύνολο της ενότητας <> είναι αφιερωμένο στην εντολή. + +[[r_ch_core_editor]] +==== git config core.editor commands + +Μαζί με τις εντολές διαμόρφωσης στο <>, πολλοί επεξεργαστές κειμένου μπορούν να δηλωθούν ως εξής: + +.Εξαντλητική λίστα με τις `core.editor` εντολές διαμόρφωσης +[cols="1,2",options="header"] +|============================== +|Editor | Configuration command +|Atom |`git config --global core.editor "atom --wait"` +|BBEdit (macOS, with command line tools) |`git config --global core.editor "bbedit -w"` +|Emacs |`git config --global core.editor emacs` +|Gedit (Linux) |`git config --global core.editor "gedit --wait --new-window"` +|Gvim (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Vim\vim72\gvim.exe' --nofork '%*'"` (Also see note below) +|Helix |`git config --global core.editor "hx"` +|Kate (Linux) |`git config --global core.editor "kate --block"` +|nano |`git config --global core.editor "nano -w"` +|Notepad (Windows 64-bit) |`git config core.editor notepad` +|Notepad++ (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Notepad+\+\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` (Also see note below) +|Scratch (Linux)|`git config --global core.editor "scratch-text-editor"` +|Sublime Text (macOS) |`git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl --new-window --wait"` +|Sublime Text (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\Sublime Text 3\sublime_text.exe' -w"` (Also see note below) +|TextEdit (macOS)|`git config --global core.editor "open --wait-apps --new -e"` +|Textmate |`git config --global core.editor "mate -w"` +|Textpad (Windows 64-bit) |`git config --global core.editor "'C:\Program Files\TextPad 5\TextPad.exe' -m"` (Also see note below) +|UltraEdit (Windows 64-bit) | `git config --global core.editor Uedit32` +|Vim |`git config --global core.editor "vim --nofork"` +|Visual Studio Code |`git config --global core.editor "code --wait"` +|VSCodium (Free/Libre Open Source Software Binaries of VSCode) | `git config --global core.editor "codium --wait"` +|WordPad |`git config --global core.editor "'C:\Program Files\Windows NT\Accessories\wordpad.exe'"` +|Xi | `git config --global core.editor "xi --wait"` +|============================== + +[NOTE] +==== +Αν έχετε έναν 32-bit επεξεργαστή κειμένου σε Windows 64-bit σύστημα, το πρόγραμμα θα εγκατασταθεί στο `C:\Program Files (x86)\` αντί για `C:\Program Files\` όπως είναι στον πίνακα παραπάνω. +==== + +==== git help + +Η εντολή `git help` χρησιμοποιείται για να μας δείξει όλη την τεκμηρίωση που περιέχεται στο Git για οποιαδήποτε εντολή. +Ενώ δίνουμε μια γενική επισκόπηση των περισσότερων από τις πιο δημοφιλείς εντολών σε αυτό το παράρτημα, για μια πλήρη λίστα όλων των πιθανών επιλογών και σημαιών για κάθε εντολή, μπορούμε πάντα να εκτελέσουμε το `git help `. + +Βλέπουμε την εντολή `git help` στην ενότητα <> και πώς να τη χρησιμοποιήσουμε για να βρούμε περισσότερες πληροφορίες για την `git shell` στην ενότητα <>. + +=== Λήψη και δημιουργία έργων + +Υπάρχουν δύο τρόποι για να αποκτήσουμε ένα αποθετήριο Git. +Ο ένας είναι να το αντιγράψουμε από ένα υπάρχον αποθετήριο στο δίκτυο ή αλλού και ο άλλος να δημιουργήσουμε ένα νέο σε έναν υπάρχοντα κατάλογο. + +==== git init + +Για να πάρουμε έναν κατάλογο και να τον μετατρέψουμε σε ένα νέο αποθετήριο Git, ώστε να μπορούμε να ξεκινήσουμε έλεγχο εκδόσεων, μπορούμε απλά να εκτελέσουμε την `git init`. + +Αυτό αναφέρεται για πρώτη φορά στην ενότητα <>, όπου παρουσιάζεται η δημιουργία ενός ολοκαίνουργιου αποθετηρίου στο οποίο θα δουλεύουμε στη συνέχεια. + +Μιλάμε εν συντομία για το πώς μπορούμε να αλλάξουμε τον προεπιλεγμένο κλάδο από τον "`master`" στην ενότητα <>. + +Χρησιμοποιούμε αυτήν την εντολή για να δημιουργήσουμε ένα άδειο κενό αποθετήριο για έναν διακομιστή στην ενότητα <>. + +Τέλος, βλέπουμε κάποιες λεπτομέρειες του τι πραγματικά κάνει στο παρασκήνιο αυτή η εντολή σκηνές στην ενότητα <>. + +==== git clone + +Η εντολή `git clone` είναι στην πραγματικότητα ένα περιτύλιγμα που περιέχει πολλές άλλες εντολές. +Δημιουργεί ένα νέο κατάλογο, πηγαίνει σε αυτόν και τρέχει την `git init` για να τον κάνει ένα κενό αποθετήριο Git, προσθέτει ένα απομακρυσμένο αποθετήριο (`git remote add`) στη διεύθυνση URL που του διαβιβάζουμε (εξ ορισμού ονομάζεται `origin`), τρέχει ένα `git fetch` από το απομακρυσμένο αποθετήριο και στη συνέχεια ελέγχει την πιο πρόσφατη υποβολή στον κατάλογο εργασίας μας με την `git checkout`. + +Η εντολή `git clone` χρησιμοποιείται σε δεκάδες μέρη σε όλο το βιβλίο, αλλά θα αναφέρουμε μόνον κάποια ενδιαφέροντα από αυτά. + +Εισάγεται και εξηγείται στην ενότητα <>, στην οποία βλέπουμε μερικά παραδείγματα. + +Στην ενότητα <> εξετάζουμε τη χρήση της επιλογής `--bare` για να δημιουργήσουμε ένα αντίγραφο ενός αποθετηρίου Git χωρίς κατάλογο εργασίας. + +Στην ενότητα <> τη χρησιμοποιούμε για να αποσυσκευάσουμε ένα συσκευασμένο αποθετήριο Git. + +Τέλος, στην ενότητα <> μαθαίνουμε την επιλογή `--recurse-submodules` για να κάνουμε την κλωνοποίηση ενός αποθετηρίου με υπομονάδες λίγο πιο απλή. + +Αν και χρησιμοποιείται σε πολλά άλλα μέρη μέσω του βιβλίου, αυτά είναι τα σημεία που είναι κατά κάποιον τρόπο μοναδικά ή στα οποία χρησιμοποιείται με τρόπους που είναι λίγο διαφορετικοί. + +=== Βασική λήψη στιγμιοτύπων + +Για τη βασική ροή εργασίας της προσθήκης περιεχομένου στο στάδιο καταχώρισης και της υποβολής του στο ιστορικό μας, υπάρχουν μόνο μερικές βασικές εντολές. + +==== git add + +Η εντολή `git add` προσθέτει περιεχόμενο από τον κατάλογο εργασίας στο στάδιο καταχώρισης (ή "`ευρετήριο`") για την επόμενη υποβολή. +Όταν εκτελείται η εντολή `git commit`, εκ προεπιλογής εξετάζει μόνον το στάδιο καταχώρισης, συνεπώς η `git add` χρησιμοποιείται για να δημιουργήσουμε ακριβώς όπως θέλουμε το επόμενο υποβληθέν στιγμιότυπό μας. + +Αυτή η εντολή είναι μια εξαιρετικά σημαντική εντολή στο Git και αναφέρεται ή χρησιμοποιείται δεκάδες φορές σε αυτό το βιβλίο. +Θα καλύψουμε γρήγορα ορισμένες από τις μοναδικές χρήσεις που αναφέρονται. + +Αρχικά εισάγουμε και εξηγούμε λεπτομερώς την `git add` στην ενότητα <>. + +Αναφέρουμε πώς να τη χρησιμοποιήσουμε για την επίλυση συγκρούσεων συγχώνευσης στην ενότητα <>. + +Βλέπουμε πώς να τη χρησιμοποιούμε για να προσθέσουμε στο στάδιο καταχώρισης διαδραστικά αρχεία ή συγκεκριμένα τμήματα τροποποιημένων αρχείων στην ενότητα <>. + +Τέλος, την προσομοιώνουμε σε ένα χαμηλό επίπεδο στην ενότητα <>, ώστε να πάρουμε μια ιδέα για το τι κάνει στο παρασκήνιο. + +==== git status + +Η εντολή `git status` μάς δείχνει τις διαφορετικές καταστάσεις αρχείων στον κατάλογο εργασίας και το στάδιο καταχώρισης μας. +Ποια αρχεία είναι τροποποιημένα αλλά δεν έχουν προστεθεί στο στάδιο καταχώρισης και ποια έχουν προστεθεί αλλά δεν έχουν ακόμη υποβληθεί. +Στην κανονική της μορφή, θα μας δείξει επίσης κάποιες βασικές υποδείξεις σχετικά με τον τρόπο μετακίνησης αρχείων μεταξύ αυτών των σταδίων. + +Αρχικά καλύπτουμε την `status` στην ενότητα <>, τόσο σε βασικές όσο και σε απλοποιημένες μορφές. +Αν και τη χρησιμοποιούμε σε όλο το βιβλίο, σχεδόν όλα όσα μπορούμε να κάνουμε με την εντολή `git status` καλύπτονται αυτήν την ενότητα. + +==== git diff + +Η εντολή `git diff` χρησιμοποιείται όταν θέλουμε να δούμε διαφορές μεταξύ οποιωνδήποτε δύο δένδρων. +Αυτή θα μπορούσε να είναι η διαφορά μεταξύ του περιβάλλοντος εργασίας μας και του ενδιάμεσου σταδίου (σκέτη `git diff`), μεταξύ του ενδιάμεσου σταδίου και της τελευταίας μας υποβολής (`git diff --staged`) ή μεταξύ δύο υποβολών (`git diff master branchB`). + +Αρχικά εξετάζουμε τις βασικές χρήσεις της `git diff` στην ενότητα <>, όπου παρουσιάζεται πώς βλέπουμε ποιες αλλαγές έχουν προστεθεί στο στάδιο καταχώρισης και ποιες όχι. + +Τη χρησιμοποιούμε για να αναζητήσουμε πιθανά σφάλματα λευκών διαστημάτων πριν υποβάλλουμε με την επιλογή `--check` στην ενότητα <>. + +Βλέπουμε πώς να ελέγξουμε πιο αποτελεσματικά τις διαφορές μεταξύ κλάδων με τη σύνταξη `git diff A...B` στην ενότητα <>. + +Τη χρησιμοποιούμε για να φιλτράρουμε τις διαφορές λευκών διαστημάτων με την επιλογή `-b` και πώς να συγκρίνουμε τα διαφορετικά στάδια των συγκρουόμενων αρχείων με τις `--theirs`, `--ours` και `--base` στην ενότητα <>. + +Τέλος, τη χρησιμοποιούμε για να συγκρίνουμε αποτελεσματικά τις αλλαγές των υπομονάδων με την επιλογή `--submodule` στην ενότητα <>. + +==== git difftool + +Η εντολή `git difftool` απλά εκκινεί ένα εξωτερικό εργαλείο για να μας δείξει τη διαφορά (diff) ανάμεσα σε δύο δέντρα στην περίπτωση που θέλουμε να χρησιμοποιήσουμε κάποια άλλη εφαρμογή από την ενσωματωμένη εντολή `git diff`. + +Την αναφέρουμε μόνο εν συντομία αυτό στην ενότητα <>. + +==== git commit + +Η εντολή git commit λαμβάνει όλα τα περιεχόμενα του αρχείου που έχουν προστεθεί στο στάδιο καταχώρισης με την `git add`, καταγράφει ένα νέο μόνιμο στιγμιότυπο στη βάση δεδομένων και μετά μετακινεί τον δείκτη κλάδου στον τρέχοντα κλάδο σε αυτό. + +Τα βασικά της υποβολής καλύπτονται στην ενότητα <>. +Εκεί παρουσιάζεται επίσης πώς χρησιμοποιούμε τη σημαία `-a` για να παραλείψουμε το βήμα `git add` στις καθημερινές ροές εργασίας και πώς να χρησιμοποιήσουμε τη σημαία `-m` για να περάσουμε ένα μήνυμα υποβολής στη γραμμή εντολών αντί για την εκκίνηση ενός επεξεργαστή κειμένου. + +Στην ενότητα <> καλύπτεται η τροποποίηση της πιο πρόσφατης υποβολής με την την επιλογή `--amend` για να επαναλάβουμε την πιο πρόσφατη υποβολή. + +Στην ενότητα <>, βλέπουμε με περισσότερες λεπτομέρειες τι κάνει `git commit` και γιατί το κάνει με αυτόν τον τρόπο. + +Εξετάζουμε πώς υπογράφουμε κρυπτογραφικά υποβολές με τη σημαία `-S` στην ενότητα <>. + +Τέλος, ρίχνουμε μια ματιά στο τι κάνει η εντολή `git commit` στο παρασκήνιο και πώς εφαρμόζεται πραγματικά στην ενότητα <>. + +==== git reset + +Η εντολή `git reset` χρησιμοποιείται κυρίως για να ακυρώσει κάτι, όπως μπορούμε να δούμε και από την ίδια τη λέξη. +Μετακινεί τον δείκτη `HEAD` τριγύρω και προαιρετικά αλλάζει τον `index` ή το στάδιο καταχώρισης και μπορεί επίσης προαιρετικά να αλλάξει τον κατάλογο εργασίας μας αν χρησιμοποιήσουμε την επιλογή `--hard`. +Η τελευταία επιλογή καθιστά δυνατή την απώλεια της δουλειάς μας με αυτήν την εντολή, εφόσον χρησιμοποιηθεί εσφαλμένα, οπότε καλά θα είναι να την καταλάβουμε σε βάθος πριν τη χρησιμοποιήσουμε. + +Ουσιαστικά η απλούστερη χρήση της `git reset` καλύπτεται στην ενότητα <>, όπου τη χρησιμοποιούμε για να αφαιρέσουμε από το στάδιο καταχώρισης ένα αρχείο στο οποίο είχαμε τρέξει την `git add`. + +Στη συνέχεια την καλύπτουμε αρκετά λεπτομερώς στην ενότητα <>, η οποία είναι εξ ολοκλήρου αφιερωμένη σε αυτήν την εντολή. + +Χρησιμοποιούμε την `git reset --hard` για να ματαιώσουμε μια συγχώνευση στην ενότητα <>, όπου χρησιμοποιούμε επίσης την `git merge --abort`, η οποία είναι λιγάκι σαν ένα περιτύλιγμα της εντολής `git reset`. + +==== git rm + +Η εντολή `git rm` χρησιμοποιείται για την αφαίρεση αρχείων από το στάδιο καταχώρισης και τον κατάλογο εργασίας. +Είναι παρόμοια με το `git add` στο ότι προετοιμάζει την κατάργηση ενός αρχείου για την επόμενη υποβολή. + +Η εντολή `git rm` καλύπτεται με κάποια λεπτομέρεια στην ενότητα <>, συμπεριλαμβανομένων των θεμάτων της αναδρομικής αφαίρεσης αρχείων και της αφαίρεσης αρχείων μόνο από το στάδιο καταχώρισης αλλά τη διατήρησή τους στον κατάλογο εργασίας με την επιλογή `--cached`. + +Η μόνη άλλη διαφορετική χρήση του `git rm` στο βιβλίο είναι στην ενότητα <> όπου εν συντομία χρησιμοποιείται και εξηγείται η `--ignore-unmatch` κατά την εκτέλεση της `git filter-branch`, η οποία ουσιαστικά δεν τερματίζει με σφάλμα όταν το το αρχείο που προσπαθούμε να καταργήσουμε δεν υπάρχει. +Αυτό μπορεί να είναι χρήσιμο όταν η εντολή χρησιμοποιείται σε script. + +==== git mv + +Η εντολή `git mv` είναι μια εντολή ευκολίας για να μετακινήσουμε ένα αρχείο και στη συνέχεια εκτελέσουμε την `git add` στο νέο αρχείο και `git rm` στο παλιό αρχείο. + +Την αναφέρουμε μόνο εν συντομία στην ενότητα <>. + +==== git clean + +Η εντολή `git clean` χρησιμοποιείται για τη διαγραφή ανεπιθύμητων αρχείων από τον κατάλογο εργασίας μας. +Αυτό θα μπορούσε να περιλαμβάνει την αφαίρεση παραπροϊόντων μεταγλώττισης ή αρχείων σύγκρουσης συγχώνευσης. + +Καλύπτουμε πολλές από τις επιλογές και τα σενάρια στα οποία μπορούμε να χρησιμοποιήσουμε την εντολή clean στην ενότητα <>. + +=== Διακλάδωση και συγχώνευση + +Υπάρχουν μόνο μερικές εντολές που υλοποιούν το μεγαλύτερο μέρος της λειτουργικότητας διακλάδωσης και συγχώνευσης στο Git. + +==== git branch + +Η εντολή 'git branch' είναι στην πραγματικότητα ένα εργαλείο διαχείρισης κλάδων. +Μπορεί να απαριθμήσει τους κλάδους που έχουμε, να δημιουργήσει έναν νέο κλάδο, να διαγράψει κλάδους και να μετονομάσει κλάδους. + +Το μεγαλύτερο μέρος του κεφαλαίου <> είναι αφιερωμένο στην εντολή `branch` και χρησιμοποιείται σε όλο το κεφάλαιο. +Αρχικά παρουσιάζεται στην ενότητα <> και τα περισσότερα από τα χαρακτηριστικά της (εισαγωγή και διαγραφή) αναλύονται στην ενότητα <>. + +Στην ενότητα <> χρησιμοποιούμε την επιλογή `git branch -u` για να δημιουργήσουμε έναν παρακολουθούμενο κλάδο. + +Τέλος, στην ενότητα <> βλέπουμε μερικά από τα πράγματα που κάνει στο παρασκήνιο. + +==== git checkout + +Η εντολή 'git checkout' χρησιμοποιείται για να μεταβούμε από έναν κλάδο σε άλλο και να ενημερώοσουμε το περιεχόμενο στον κατάλογο εργασίας μας. + +Αρχικά συναντάμε την εντολή στην ενότητα <> μαζί με την εντολή `git branch`. + +Βλέπουμε πώς να το χρησιμοποιήσουμε για να αρχίσουμε να παρακολουθούμε κλάδους με τη σημαία `--track` στην ενότητα <>. + +Τη χρησιμοποιούμε για την επανεισαγωγή των συγκρούσεων αρχείων με την `--conflict=diff3` στην ενότητα <>. + +Βλέπουμε λεπτομερώς τη σχέση της με την `git reset` στην ενότητα <>. + +Τέλος, βλέπουμε κάποιες λεπτομέρειες υλοποίησής της στην ενότητα <>. + +==== git merge + +Το εργαλείο `git merge` χρησιμοποιείται για τη συγχώνευση ενός ή περισσοτέρων κλάδων στον κλάδο στον οποίο έχουμε κάνει checkout. +Στη συνέχεια ωθεί τον τρέχοντα κλάδο στο αποτέλεσμα της συγχώνευσης. + +Η εντολή git merge εισάγεται για πρώτη φορά στην ενότητα <>. +Παρότι χρησιμοποιείται σε διάφορα σημεία του βιβλίου, υπάρχουν πολύ λίγες παραλλαγές της εντολής `merge` -- βασικά η `git merge ` με το όνομα του μόνου κλάδου που θέλουμε να συγχωνεύσουμε. + +Καλύψαμε πώς κάνουμε μία συναρμοσμένη (squashed) συγχώνευση (στην οποία το Git συγχωνεύει το έργο, αλλά προσποιείται ότι πρόκειται για μια νέα υποβολή χωρίς να καταγράφει το ιστορικό του κλάδου που συγχωνεύουμε) στο τέλος της ενότητας <>. + +Πολλές πληροφορίες για τη διαδικασία και εντολή συγχώνευσης συμπερλιλαμβανομένης της εντολής `-Xignore-space-change` και της σημαίας `--abort`, όσον αφορά στη ματαίωση μίας προβληματικής συγχώνευσης, υπάρχουν στην ενότητα <>. + +Μάθαμε πώς να επαληθεύουμε τις υπογραφές πριν τη συγχώνευση αν το έργο μας χρησιμοποιεί την υπογραφή GPG στην ενότητα <>. + +Τέλος, μάθαμε για τη συγχώνευση υποδέντρων στην ενότητα <>. + +==== git mergetool + +Η εντολή `git mergetool` απλά εκκινεί έναν εξωτερικό βοηθό συγχώνευσης σε περίπτωση που έχουμε προβλήματα με κάποια συγχώνευση στο Git. + +Την αναφέρουμε στα γρήγορα στην ενότητα <> και βλέπουμε λεπτομερώς πώς να υλοποιήσουμε το δικό μας εξωτερικό εργαλείο συγχώνευσης στην ενότητα <>. + +==== git log + +Η εντολή `git log` χρησιμοποιείται για να δείξει το προσπελάσιμο εγγεγραμμένο ιστορικό ενός έργου από το πιο πρόσφατο στιγμιότυπο υποβολής και πίσω. +Εκ προεπιλογής εμφανίζεται μόνο το ιστορικό του κλάδου στον οποίο βρισκόμαστε, αλλά είναι δυνατό να δοθούν διαφορετικές ή ακόμα και πολλαπλές κεφαλές ή κλάδοι που μπορούμε να διασχίσουμε. +Συχνά χρησιμοποιείται επίσης για την εμφάνιση διαφορών μεταξύ δύο ή περισσοτέρων κλάδων σε επίπεδο υποβολής. + +Αυτή η εντολή χρησιμοποιείται σχεδόν σε κάθε κεφάλαιο του βιβλίου για να επιδείξει την ιστορία ενός έργου. + +Εισάγουμε την εντολή και την καλύπτουμε σε κάποιο βάθος στην ενότητα <>. +Εξετάζουμε τις επιλογές `-p` και `-stat` για να πάρουμε μια ιδέα για το τι εισήχθη σε κάθε υποβολή και τις επιλογές `--pretty` και `--oneline` για να δούμε την ιστορία πιο συνοπτικά, μαζί με μερικές απλές ημερομηνίες και επιλογές φιλτραρίσματος συγγραφέων. + +Στην ενότητα <> τη χρησιμοποιούμε με την επιλογή `--decorate` για να απεικονίσουμε εύκολα τη θέση των δεικτών του κλάδου μας· επίσης χρησιμοποιούμε την επιλογή `--graph` για να δούμε με τι μοιάζουν αποκλίνουσες ιστορίες. + +Στις ενότητες <> και <> καλύπτουμε τη σύνταξη `branchA..branchB` της εντολής `git log` για να δούμε ποιες υποβολές είναι μοναδικές σε έναν κλάδο σε σχέση με έναν άλλο κλάδο. +Στην ενότητα <> βλέπουμε ακριβώς αυτό σε αρκετά μεγάλη έκταση. + +Στις ενότητες <> και <> καλύπτουμε τη χρήση της μορφής `branchA...branchB` και τη σύνταξη `--left-right` για να δούμε τι υπάρχει σε έναν κλάδο ή τον άλλο αλλά όχι και στους δύο. +Στην ενότητα <> εξετάζουμε επίσης πώς χρησιμοποιούμε την επιλογή `--merge` για να βοηθήσουμε στην αποσφαλμάτωση συγκρούσεων συγχώνευσης καθώς και την επιλογή `--cc` για να εξετάσουμε τις συγκρούσεις συγχώνευσης υποβολών στο ιστορικό μας. + +Στην ενότητα <> χρησιμοποιούμε την επιλογή `-g` για να δούμε το reflog του Git μέσα από αυτό το εργαλείο αντί να κάνουμε διέλευση κλάδων. + +Στην ενότητα <> εξετάζουμε τις επιλογές `-S` και `-L` για να κάνουμε αρκετά εξεζητημένες αναζητήσεις για κάτι που συνέβη στο παρελθόν στον κώδικα, όπως για παράδειγμα το ιστορικό μιας συνάρτησης. + +Στην ενότητα <> βλέπουμε πώς χρησιμοποιούμε την `--show-signature` για να προσθέσουμε μια συμβολοσειρά επικύρωσης σε κάθε υποβολή στην έξοδο της `git log` ανάλογα με το αν είναι έγκυρα υπογεγραμμένη ή όχι. + +==== git stash + +Η εντολή `git stash` χρησιμοποιείται για την προσωρινή αποθήκευση εργασιών που δεν έχουν υποβληθεί, προκειμένου να καθαριστεί ο κατάλογος εργασίας μας χωρίς να χρειάζεται να εκτελέσουμε εργασίες που δεν έχουν ολοκληρωθεί σε κάποιον κλάδο. + +Καλύπτεται εξ ολοκλήρου στην ενότητα <>. + +==== git tag + +Η εντολή `git tag` χρησιμοποιείται για να προσαρτήσει έναν μόνιμο σελιδοδείκτη σε ένα συγκεκριμένο σημείο στο ιστορικό του κώδικα. +Γενικά αυτό χρησιμοποιείται για πράγματα όπως εκδόσεις κυκλοφορίας λογισμικού (release). + +Αυτή η εντολή εισάγεται και καλύπτεται λεπτομερώς στην ενότητα <> και τη χρησιμοποιούμε στην πράξη στην ενότητα <>. + +Καλύπτουμε επίσης τον τρόπο δημιουργίας μιας ετικέτας που έχει υπογραφεί με GPG με τη σημαία `-s` και την επαλήθευση ετικετών με τη σημαία `-v` στην ενότητα <>. + +=== Κοινή χρήση και ενημέρωση έργων + +Δεν υπάρχουν πολλές εντολές στο Git που έχουν πρόσβαση στο δίκτυο, σχεδόν όλες οι εντολές λειτουργούν στην τοπική βάση δεδομένων. +Όταν είμαστε έτοιμοι να μοιραστούμε τη δουλειά μας ή να έλξουμε αλλαγές από αλλού, υπάρχει μια χούφτα εντολών που ασχολούνται με τα απομακρυσμένα αποθετήρια. + +==== git fetch + +Η εντολή `git fetch` επικοινωνεί με ένα απομακρυσμένο αποθετήριο και ανακτά όλες τις πληροφορίες που βρίσκονται σε εκείνο το αποθετήριο που δεν βρίσκονται στο τρέχον αποθετήριο και τις αποθηκεύει στην τοπική βάση δεδομένων μας. + +Αρχικά εξετάζουμε αυτήν την εντολή στην ενότητα <> και συνεχίζουμε να δούμε παραδείγματα χρήσης της στην ενότητα <>. + +Τη χρησιμοποιούμε επίσης σε πολλά παραδείγματα στην ενότητα <>. + +Τη χρησιμοποιούμε για να ανακτήσουμε μια συγκεκριμένη αναφορά που βρίσκεται έξω από τον προεπιλεγμένο χώρο στην ενότητα <> και βλέπουμε πώς να ανακτήσουμε από ένα δεμάτι στην ενότητα <>. + +Δημιουργήσαμε πολύ εξατομικευμένες αναφορές για να κάνουμε την `git fetch` να έχει λίγο διαφορετική λειτουργία από την προεπιλεγμένη στην ενότητα <>. + +==== git pull + +Η εντολή `git pull` είναι βασικά ένας συνδυασμός των εντολών `git fetch` και `git merge`, στον οποίο το Git θα ανακτήσει από το απομακρυσμένο σημείο που καθορίζουμε και στη συνέχεια θα προσπαθήσει αμέσως να το συγχωνεύσει στον κλάδο στον οποίο βρισκόμαστε. + +Την εισάγουμε γρήγορα στην ενότητα <> και δείχνουμε πώς θα δούμε τι θα συγχωνευθεί αν την τρέξουμε στην ενότητα <>. + +Βλέπουμε επίσης πώς να τη χρησιμοποιήσουμε για να βοηθήσουμε στην επανατοποθέτηση σε επανατοποθετημένους κλάδους στην ενότητα <>. + +Δείχνουμε πώς να τη χρησιμοποιήσουμε με μια διεύθυνση URL για να έλξουμε αλλαγές με τη μία στην ενότητα <>. + +Τέλος, αναφέρουμε πολύ γρήγορα ότι μπορούμε να χρησιμοποιήσουμε την επιλογή `-verify-signatures` για να επαληθεύσουμε ότι οι υποβολές που έχουμε έλξει έχουν υπογραφεί με GPG στην ενότητα <>. + +==== git push + +Η εντολή `git push` χρησιμοποιείται για να επικοινωνήσουμε με ένα άλλο αποθετήριο, να υπολογίσουμε τι έχει η τοπική βάση δεδομένων μας που δεν το έχει το απομακρυσμένο αποθετήριο και στη συνέχεια ωθεί τη διαφορά στο άλλο αποθετήριο. +Απαιτεί πρόσβαση εγγραφής στο άλλο αποθετήριο, συνεπώς εμπλέκει κάποιου είδους ταυτοποίηση. + +Αρχικά εξετάζουμε την εντολή `git push` στην ενότητα <>. +Εδώ καλύπτουμε τα βασικά στοιχεία της ώθησης ενός κλάδου σε ένα απομακρυσμένο αποθετήριο. +Στην ενότητα <> προχωρούμε λίγο πιο βαθιά στην ώθηση συγκεκριμένων κλάδων και στην ενότητα <> βλέπουμε πώς μπορούμε να ρυθμίσουμε παρακολουθούμενος κλάδους ώστε να ωθούμε σε αυτούς αυτόματα. +Στην ενότητα <> χρησιμοποιούμε τη σημαία `--delete` για να διαγράψουμε έναν κλάδο στον διακομιστή με την `git push`. + +Σε όλη την ενότητα <> βλέπουμε αρκετά παραδείγματα χρήσης της `git push` για να μοιραζόμαστε την εργασία σε κλάδους σε πολλά αποθετήρια. + +Βλέπουμε πώς να τη χρησιμοποιούμε για να μοιραζόμαστε τις ετικέτες που έχουμε φτιάξει με την επιλογή `--tags` στην ενότητα <>. + +Στην ενότητα <> χρησιμοποιούμε την επιλογή `--recurse-submodules` για να ελέγξουμε ότι όλα τα submodules μας έχουν δημοσιευθεί πριν ωθήσουμε το superproject, κάτι που μπορεί να είναι πραγματικά χρήσιμο όταν χρησιμοποιούμε submodules. + +Στην ενότητα <> μιλάμε εν συντομία για το άγκιστρο `pre-push`, το οποίο είναι ένα script που μπορούμε να ρυθμίσουμε να τρέχει πριν ολοκληρωθεί η ώθηση για να επιβεβαιωθεί ότι επιτρέπεται να ωθηθεί. + +Τέλος, στην ενότητα <> εξετάζουμε την ώθηση με πλήρη refspec αντί για τις γενικές συντομεύσεις που χρησιμοποιούνται κανονικά. +Αυτό μπορεί να μας βοηθήσει να είμαστε πολύ συγκεκριμένοι σχετικά με το έργο που θέλουμε να μοιραστούμε. + +==== git remote + +Η εντολή `git remote` είναι ένα εργαλείο διαχείρισης των απομακρυσμένων αποθετηρίων μας. +Μας επιτρέπει να αποθηκεύουμε μεγάλες διευθύνσεις URL ως σύντομα ψευδόνυμα, όπως "`origin`", ώστε να μην χρειάζεται να τις πληκτρολογούμε συνεχώς. +Μπορούμε να έχουμε αρκετές τέτοιες και η εντολή `git remote` χρησιμοποιείται για την προσθήκη, αλλαγή και διαγραφή τους. + +Αυτή η εντολή καλύπτεται λεπτομερώς στην ενότητα <>, συμπεριλαμβανομένης της καταχώρισης, προσθήκης, αφαίρεσης και της μετονομασίας των απομακρυσμένων αποθετηρίων. + +Χρησιμοποιείται σχεδόν σε κάθε επόμενο κεφάλαιο του βιβλίου, αλλά πάντα στο τυπικό σχήμα `git remote add `. + +==== git archive + +Η εντολή `git archive` χρησιμοποιείται για τη δημιουργία ενός αρχείου αρχειοθήκης ενός συγκεκριμένου στιγμιότυπου του έργου. + +Χρησιμοποιούμε το `git archive` για να δημιουργήσουμε ένα tarball ενός έργου για κοινή χρήση στην ενότητα <>. + +==== git submodule + +Η εντολή `git submodule` χρησιμοποιείται για τη διαχείριση εξωτερικών αποθετηρίων μέσα σε ένα κανονικό αποθετήριο. +Αυτό θα μπορούσε να γίνεται π.χ. για βιβλιοθήκες ή άλλους τύπους κοινών πόρων. +Η εντολή `submodule` έχει πολλές υπό-εντολές (`add`, `update`, `sync`, κ.λπ.) για τη διαχείριση αυτών των πόρων. + +Αυτή η εντολή αναφέρεται και καλύπτεται εξ ολοκλήρου στην ενότητα <>. + +=== Επιθεώρηση και σύγκριση + +==== git show + +Η εντολή `git show` μπορεί να εμφανίσει ένα αντικείμενο Git με έναν απλό και ανθρωπανάγνωστο τρόπο. +Κανονικά θα τη χρησιμοποιούσαμε για να εμφανίσουμε πληροφορίες σχετικές με μια ετικέτα ή μια υποβολή. + +Αρχικά τη χρησιμοποιούμε για την εμφάνιση επισημειωμένων πληροφοριών ετικετών στην ενότητα <>. + +Αργότερα το χρησιμοποιούμε αρκετά στην ενότητα <> για να δείξουμε τις υποβολές τις οποίες επιλύουν οι διάφορες επιλογές αναθεωρήσεών μας. + +Ένα από τα πιο ενδιαφέροντα πράγματα που κάνουμε με την `git show` είναι να εξάγουμε συγκεκριμένα περιεχόμενα αρχείου σε διάφορα στάδια κατά τη διάρκεια μιας σύγκρουσης συγχώνευσης (ενότητα <>). + +==== git shortlog + +Η εντολή `git shortlog` χρησιμοποιείται για να συνοψίσει την έξοδο της `git log`. +Πολλές από τις επιλογές που παίρνει είναι ίδιες με αυτές που παίρνει η εντολή `git log`, αλλά αντί να αναγράφει όλες τις υποβολές, παρουσιάζει μια σύνοψη των υποβολών, ομαδοποιημένων ανά συντάκτη. + +Η χρήση της για τη δημιουργία ενός ωραιότατου μητρώου αλλαγών (changelog) περιγράφεται στην ενότητα <>. + +==== git describe + +Η εντολή `git describe` χρησιμοποιείται για να πάρει ο,τιδήποτε επιλύεται σε μια υποβολή και παράγει μια συμβολοσειρά που είναι σχετικά ανθρωπανάγνωστη και δεν θα αλλάζει. +Είναι ένας τρόπος για να αποκτήσουμε μια περιγραφή κάποιας υποβολής που είναι τόσο μονοσήμαντη όσο ο αριθμός SHA-1 μίας υποβολής αλλά πιο κατανοητή. + +Χρησιμοποιούμε την `git describe` στις ενότητες <> και <> για να πάρουμε μια συμβολοσειρά με την οποία ονομάζουμε μία δημοσιευμένη έκδοση στη συνέχεια. + +=== Αποσφαλμάτωση + +Το Git έχει μερικές εντολές που χρησιμοποιούνται για την αποσφαλμάτωση προβλημάτων στον κώδικά μας. +Αυτό κυμαίνεται ανάμεσα στο να ανακαλύψουμε πού εισήχθη κάτι μέχρι στο ποιος το εισήγαγε. + +==== git bisect + +Το εργαλείο `git bisect` είναι ένα απίστευτα χρήσιμο εργαλείο εντοπισμού σφαλμάτων που χρησιμοποιείται για να εντοπίσει ποια συγκεκριμένη υποβολή ήταν η πρώτη που εισήγαγε ένα σφάλμα ή πρόβλημα κάνοντας μια αυτόματη δυαδική αναζήτηση. + +Καλύπτεται πλήρως στην ενότητα <> που είναι και η μόνη ενότητα στην οποία αναφέρεται. + +==== git blame + +Η εντολή `git blame` επισημειώνει τις γραμμές κάθε αρχείου με την τελευταία υποβολή στην οποία εισήχθη αλλαγή σε αυτήν τη γραμμή του αρχείου και ποιο πρόσωπο που συνέταξε αυτή την υποβολή. +Αυτό είναι χρήσιμο για να βρούμε το άτομο και να του ζητήσουμε περισσότερες πληροφορίες σχετικά με ένα συγκεκριμένο τμήμα του κώδικά μας. + +Καλύπτεται στην ενότητα <> και αναφέρεται μόνο σε αυτήν την ενότητα. + +==== git grep + +Η εντολή `git grep` μπορεί να μας βοηθήσει να βρούμε οποιαδήποτε συμβολοσειρά ή κανονική έκφραση (regular expression) σε οποιοδήποτε από τα αρχεία του πηγαίου κώδικα μας, ακόμα και παλαιότερες εκδόσεις του έργου μας. + +Καλύπτεται στην ενότητα <> και αναφέρεται μόνο σε αυτήν την ενότητα. + +=== Επιθέματα + +Ορισμένες εντολές στο Git επικεντρώνονται στην έννοια της αντιληψης των υποβολών ως εισαγόμενων αλλαγών σαν μία σειρά από υποβολές να είναι μία σειρά από επιθέματα. +Αυτές οι εντολές μας βοηθούν να διαχειριστούμε τους κλάδους μας με αυτόν τον τρόπο. + +==== git cherry-pick + +Η εντολή `git cherry-pick` χρησιμοποιείται για να πάρει την αλλαγή που εισήχθη σε μια μοναδική υποβολή και να προσπαθήσει να την επαναλάβει ως νέα υποβολή για τον κλάδο στο οποίο βρισκόμαστε. +Αυτό μπορεί να είναι χρήσιμο όταν θέλουμε να πάρουμε μόνο μία ή δύο υποβολές από έναν κλάδο αντί να συγχωνεύσουμε τον κλάδο, κάτι που θα επιτελέσει όλες τις αλλαγές. + +Η ανθολόγηση περιγράφεται και παρουσιάζεται στην ενότητα <>. + +==== git rebase + +Η εντολή `git rebase` είναι βασικά μια αυτοματοποιημένη ανθολόγηση (`cherry-pick`). +Προσδιορίζει μια σειρά υποβολών και στη συνέχεια τις ανθολογεί μία μία σειρά με την ίδια σειρά κάπου αλλού. + +Η αλλαγή βάσης καλύπτεται λεπτομερώς στην ενότητα <>, συμπεριλαμβανομένων συνεργατικών ζητημάτων που σχετίζονται με την αλλαγή βάσης κλάδων που είναι ήδη δημόσιοι. + +Τη χρησιμοποιούμε πρακτικά σε ένα παράδειγμα διαίρεσης του ιστορικού μας σε δύο χωριστά αποθετήρια στην ενότητα <> στο οποίο χρησιμοποιούμε επίσης τη σημαία `--onto`. + +Στην ενότητα <> αντιμετωπίζουμε μια σύγκρουση συγχώνευσης κατά τη διαδικασία αλλαγής βάσης. + +Επίσης, τη χρησιμοποιούμε στην ενότητα <> σε μια διαδραστική λειτουργία script με την επιλογή `-i`. + +==== git revert + +Η εντολή `git revert` είναι ουσιαστικά η αντίστροφη της `git cherry-pick`. +Δημιουργεί μια νέα υποβολή που εφαρμόζει το ακριβώς αντίθετο από την αλλαγής που εισήχθη στην υποβολή που στοχεύουμε, ουσιαστικά αναιρόντας ή επαναφέροντάς την. + +Τη χρησιμοποιούμε στην ενότητα <> για να αναιρέσουμε μια υποβολή συγχώνευσης. + +=== Ηλεκτρονικό ταχυδρομείο + +Πολλά έργα Git, συμπεριλαμβανομένου του ίδιου του Git, διατηρούνται εξ ολοκλήρου σε λίστες ηλεκτρονικής αλληλογραφίας. +Το Git διαθέτει πολλά ενσωματωμένα εργαλεία που συμβάλλουν στη διευκόλυνση αυτής της διαδικασίας, από τη δημιουργία επιθεμάτων που μπορούμε να στείλουμε εύκολα με e-mail στην εφαρμογή αυτών των επιθεμάτων από e-mail. + +==== git apply + +Η εντολή `git apply` εφαρμόζει ένα επίθεμα που δημιουργήθηκε με την εντολή `git diff` ή ακόμα και την diff της GNU. +Είναι παρόμοια με αυτό που κάνει η εντολή `patch` με κάποιες μικρές αλλαγές. + +Η χρήση της καθώς και οι περιστάσεις στις οποίες μπορούμε να το κάνουμε παρουσιάζονται στην ενότητα <>. + +==== git am + +Η εντολή `git am` χρησιμοποιείται για την εφαρμογή επιθεμάτων από τα εισερχόμενα e-mail, και πιο συγκεκριμένα το οποίο είναι μορφοποιημένο σαν mbox. +Αυτό είναι χρήσιμο για τη λήψη ενημερωμένων εκδόσεων μέσω e-mail και την εύκολη εφαρμογή τους στο έργο μας. + +Καλύψαμε τη χρήση και τη ροή εργασίας γύρω από την `git am` στην ενότητα <>, συμπεριλαμβανομένων των επιλογών `--resolved`, `-i` και `-3`. + +Υπάρχει επίσης ένας αριθμός αγκίστρων που μπορούμε να χρησιμοποιούμε για να βοηθήσουμε στη ροή εργασίας γύρω από την `git am`, που καλύπτονται στην ενότητα <>. + +Επίσης, τη χρησιμοποιούμε για να εφαρμόσουμε αλλαγές σε αιτήματα έλξης στο GitHub, μορφοποιημένες σαν επιθέματα στην ενότητα <>. + +==== git format-patch + +Η εντολή `git format-patch` χρησιμοποιείται για τη δημιουργία μιας σειράς επιθεμάτων σε μορφή mbox, που μπορούμε να αποστείλουμε σε μια λίστα αλληλογραφίας, εφόσον είναι κατάλληλα μορφοποιημένη. + +Βλέπουμε ένα παράδειγμα συμβολής σε ένα έργο χρησιμοποιώντας το εργαλείο `git format-patch` στην ενότητα <>. + +==== git imap-send + +Η εντολή git imap-send μεταφορτώνει ένα γραμματοκιβώτιο που δημιουργείται με την `git format-patch` σε ένα φάκελο προχείρων IMAP. + +Ένα παράδειγμα συμβολής σε ένα έργο με αποστολή επιθεμάτων με το εργαλείο `git imap-send` παρουσιάζεται στην ενότητα <>. + +==== git send-email + +Η εντολή `git send-email` χρησιμοποιείται για την αποστολή patches που δημιουργούνται με το `git format-patch` μέσω email. + +Ένα παράδειγμα συμβολής σε ένα έργο με αποστολή επιθεμάτων με το εργαλείο `git send-email` παρουσιάζεται στην ενότητα <>. + +==== git request-pull + +Η εντολή `git request-pull` χρησιμοποιείται απλά για να δημιουργήσουμε ένα σώμα κειμένου e-mail σε κάποιον. +Αν έχουμε έναν κλάδο σε δημόσιο διακομιστή και θέλουμε να ενημερώσουμε κάποιον πώς να ενσωματώσει αυτές τις αλλαγές χωρίς να του στείλουμε τα επιθέματα με e-mail, μπορούμε να εκτελέσουμε αυτήν την εντολή και να στείλουμε την έξοδο στο άτομο που θέλουμε να έλξει τις αλλαγές. + +Ο τρόπος χρήσης της `git request-pull` για τη δημιουργία ενός μηνύματος έλξης παρουσιάζεται στην ενότητα <>. + +=== Εξωτερικά Συστήματα + +Το Git συνοδεύεται από μερικές εντολές για ενσωμάτωση με άλλα συστήματα ελέγχου έκδοσεων. + +==== git svn + +Η εντολή `git svn` χρησιμοποιείται για να επικοινωνήσουμε με το σύστημα ελέγχου έκδοσεων Subversion ως πελάτες. +Αυτό σημαίνει ότι μπορούμε να χρησιμοποιήσουμε το Git για να κάνουμε ανακτήσουμε από και να υποβάλλουμε σε διακομιστή Subversion. + +Αυτή η εντολή καλύπτεται σε βάθος στην ενότητα <>. + +==== git fast import + +Για άλλα συστήματα ελέγχου εκδόσεων ή για εισαγωγή από σχεδόν οποιαδήποτε μορφή, μπορούμε να χρησιμοποιήσουμε τη λειτουργία `git fast import` για να απεικονίσουμε γρήγορα την άλλη μορφή σε κάτι που το Git μπορεί εύκολα να καταγράψει. + +Αυτή η εντολή καλύπτεται σε βάθος στην ενότητα <>. + +=== Διοίκηση + +Εάν διαχειριζόμαστε ένα αποθετήριο Git ή χρειάζεται να διορθώσουμε κάποια πράγματα σε μεγάλη έκταση, το Git μάς παρέχει μια σειρά διοικητικών εντολών για να μας βοηθήσει. + +==== git gc + +Η εντολή `git gc` τρέχει μια "`συλλογή σκουπιδιών`" ("`garbage collection`") στο αποθετήριό μας, αφαιρώντας τα μη σημαντικά αρχεία από την βάση δεδομένων και πακετάρει τα εναπομείναντα αρχεία σε μια πιο αποτελεσματική μορφή. + +Αυτή η εντολή εκτελείται κανονικά στο παρασκήνιο για εμάς, αν και μπορούμε να την εκτελέσουμε χειροκίνητα εάν το επιθυμούμε. +Μερικά παραδείγματα αυτού παρουσιάζονται στην ενότητα <>. + +==== git fsck + +Η εντολή `git fsck` χρησιμοποιείται για να ελέγξει την εσωτερική βάση δεδομένων για προβλήματα ή ανακολουθίες. + +Τη χρησιμοποιούμε μόνο μία φορά στην ενότητα <> για να αναζητήσουμε εκκρεμεί αντικείμενα (dangling objects). + +==== git reflog + +Η εντολή `git reflog` περνάει μέσα από ένα μητρώο στο οποίο καταγράφονται οι θέσεις των κεφαλών των κλάδων μας, ώστε να βρει υποβολές που ενδεχομένως έχουμε χάσει εξαιτίας επανεγγραφής του ιστορικού. + +Καλύπτουμε αυτήν την εντολή κυρίως στην ενότητα <>, όπου δείχνουμε την κανονική χρήση και πώς χρησιμοποιήσουμε το `git log -g` για να δούμε τις ίδιες πληροφορίες με αυτές που δίνει η έξοδος της `git log`. + +Επίσης βλέπουμε ένα πρακτικό παράδειγμα ανάκτησης ενός τέτοιου χαμένου κλάδου στην ενότητα <>. + +==== git filter-branch + +Η εντολή `git filter-branch` χρησιμοποιείται για να ξαναγράψει πολλές υποβολές σύμφωνα με ορισμένα μοτίβα, όπως η αφαίρεση ενός αρχείου από παντού ή το φιλτράρισμα ολόκληρου του αποθετηρίου σε έναν μόνο υποκατάλογο για την εξαγωγή του έργου. + +Στην ενότητα <> εξηγούμε την εντολή και εξερευνούμε διάφορες επιλογές όπως `--commit-filter`, `--subdirectory-filter` και `--tree-filter`. + +Στην ενότητα <> τη χρησιμοποιούμε για να διορθώσουμε εισαγόμενα εξωτερικά αποθετήρια. + +=== Εντολές διοχέτευσης + +Υπάρχουν επίσης αρκετές εντολές διοχέτευσης χαμηλότερου επιπέδου που συναντήσαμε στο βιβλίο. + +Η πρώτη είναι η `ls-remote` στην ενότητα <> την οποίο χρησιμοποιούμε για να δούμε τις ανεπεξέργαστες αναφορές στον διακομιστή. + +Χρησιμοποιούμε την `ls-files` στις ενότητες <>, <> και <> για να ρίξουμε μια πιο ακατέργαστη ματιά σε αυτό που είναι το στάδιο καταχώρισης. + +Επίσης, αναφέρουμε την `rev-parse` στην ενότητα <> για να πάρουμε σχεδόν οποιαδήποτε συμβολοσειρά και να τη μετατρέψουμε σε αντικείμενο SHA-1. + +Ωστόσο, οι περισσότερες από τις εντολές διοχέτευσης χαμηλού επιπέδου που καλύπτουμε είναι στο κεφάλαιο <>, και αυτές είναι λίγο πολύ αυτό το επίκεντρο αυτού του κεφαλαίου. +Η χρήση τους σε όλο το υπόλοιπο βιβλίο έχει αποφευχθεί σε μεγάλο βαθμό. diff --git a/CITATION.cff b/CITATION.cff new file mode 100644 index 000000000..b311dcddc --- /dev/null +++ b/CITATION.cff @@ -0,0 +1,29 @@ +# This CITATION.cff file was generated with cffinit. +# Visit https://bit.ly/cffinit to generate yours today! + +cff-version: 1.2.0 +title: Pro Git +message: >- + If you use this software, please cite it using the + metadata from this file. +type: software +authors: + - given-names: Scott + family-names: Chacon + email: schacon@gmail.com + - given-names: Ben + family-names: Straub + email: ben@straub.cc +identifiers: + - type: url + value: 'https://git-scm.com/book/en/v2' + description: Pro Git website +repository-code: 'https://github.com/progit/progit2' +url: 'https://git-scm.com/book/en/v2' +keywords: + - git + - book + - asciidoc + - pro-git +license: CC-BY-NC-SA-3.0 +version: '2' diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c2fb19e83..ba00b375c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,37 +1,44 @@ # Contributing to Pro Git (2nd Edition) +## Licensing your work to us -## Licensing - -By opening a pull request to this repository, you agree to provide your work under the [project license](LICENSE.asc). +When you open a pull request, you agree to provide your work under the [project license](LICENSE.asc). Also, you agree to grant such license of your work as is required for the purposes of future print editions to @ben and @schacon. Should your changes appear in a printed edition, you'll be included in the [contributors list](book/contributors.asc). +## Signaling an Issue + +Search for similar issues, before creating a new issue. + +Also, if this issue has been spotted on the git-scm.com site, cross-check that the issue is present in the pdf version. +The issue may have already been corrected in the source files, but not yet deployed to the git-scm.com site. + ## Small Corrections -Errata and basic clarifications will be accepted if we agree that they improve the content. You can also open an issue so we can figure out how or if it needs to be addressed. +Errata and basic clarifications will be accepted if we agree that they improve the content. +You can also open an issue so that we can discuss how or if the issue needs to be addressed. -If you've never done this before, the [flow guide](https://guides.github.com/introduction/flow/) might be useful. +If you've never done this before, the [flow guide](https://docs.github.com/en/get-started/quickstart/github-flow) might be useful. ## Large Rewrites -Open an issue for discussion before you start. These changes tend to be very subjective, often only clarifying things for some small percentage of people and it's rarely worth the time to accept them. Professional copy editors have already reviewed this content multiple times so while you may have somewhat better taste and grammar than we do it's unlikely that your prose is going to be *so* much better that it's worth changing vast swaths of text. +Open an issue for discussion before you start. +A large rewrite tends to be very subjective, often only clarifying things for a small amount of readers. +Professional copy editors have already reviewed this content multiple times. +It's unlikely that your prose is going to be *so* much better that it's worth changing large portions of text. ## Figures -The images in this book were generated using [Sketch 3](http://bohemiancoding.com/sketch/), with the [included sketchbook file](diagram-source/progit.sketch). +The images in this book are generated using [Sketch 3](https://www.sketch.com/), with the [included sketchbook file](diagram-source/progit.sketch). -To add a figure: - -1. Add a page to the sketchbook. Try to use the included symbols wherever possible. -1. Add a "slice" to your page. Give it a name that matches the destination PNG filename, relative from the root of the source directory. -1. Make sure your slice is set to export at "800w". +To create a figure: +1. Add a page to the sketchbook. +Use the included symbols wherever possible. +2. Add a "slice" to your page. +Name the slice so that it matches the destination PNG filename, relative from the root of the source directory. +3. Set your slice to export at "800w". ## Translations -Translations to other languages are highly encouraged but handled a little differently than the first edition. We now keep each translation in a separate repository and automatically build the output files through Atlas. This was something that was really difficult in the last edition. - -Since each translation is a different repository, we can also have different maintainers for each project. The Pro Git team simply pulls them in and builds them for the translation teams. To get automatic builds, translations repositories will have to be under the [`progit` organization on GitHub](https://github.com/progit). - -You can find out information on all the current translations and information on how to start your own at http://progit.org/translations. +If you want to contribute to translating Pro Git into your language, take a look at [TRANSLATING.md](TRANSLATING.md). diff --git a/Gemfile b/Gemfile index d7bd91223..80e387b71 100644 --- a/Gemfile +++ b/Gemfile @@ -1,16 +1,18 @@ source 'https://rubygems.org' -gem 'rake' -gem 'asciidoctor', '1.5.0' +gem 'rake', '13.2.1' +gem 'asciidoctor', '2.0.23' -gem 'json' -gem 'awesome_print' +gem 'json', '2.11.3' +gem 'awesome_print', '1.9.2' -gem 'asciidoctor-epub3', '1.0.0.alpha.2' -gem 'asciidoctor-pdf', '1.5.0.alpha.5' +gem 'asciidoctor-fb2', '0.8.0' +gem 'asciidoctor-epub3', '2.1.3' +gem 'asciidoctor-pdf', '2.3.19' -gem 'coderay' -gem 'pygments.rb' -gem 'thread_safe' -gem 'epubcheck' -gem 'kindlegen' +gem 'coderay', '1.1.3' +gem 'pygments.rb', '3.0.0' +gem 'thread_safe', '0.3.6' +gem 'epubcheck-ruby', '5.2.1.0' +gem 'html-proofer', '5.0.10' +gem 'kindlegen', '3.1.1' diff --git a/Gemfile.lock b/Gemfile.lock deleted file mode 100644 index 72029ced7..000000000 --- a/Gemfile.lock +++ /dev/null @@ -1,74 +0,0 @@ -GEM - remote: https://rubygems.org/ - specs: - Ascii85 (1.0.2) - afm (0.2.2) - asciidoctor (1.5.0) - asciidoctor-epub3 (1.0.0.alpha.2) - asciidoctor (>= 1.5.0, < 1.6.0) - gepub (~> 0.6.9.2) - thread_safe (~> 0.3.4) - asciidoctor-pdf (1.5.0.alpha.5) - asciidoctor (~> 1.5.0) - prawn (= 1.2.1) - prawn-svg (= 0.16.0) - prawn-table (= 0.1.1) - prawn-templates (= 0.0.3) - treetop (= 1.5.3) - awesome_print (1.2.0) - coderay (1.1.0) - epubcheck (3.0.1) - gepub (0.6.9.2) - nokogiri (~> 1.6.1) - rubyzip (>= 1.1.1) - hashery (2.1.1) - json (1.8.1) - kindlegen (2.9.4) - mini_portile (0.6.0) - nokogiri (1.6.3.1) - mini_portile (= 0.6.0) - pdf-core (0.2.5) - pdf-reader (1.3.3) - Ascii85 (~> 1.0.0) - afm (~> 0.2.0) - hashery (~> 2.0) - ruby-rc4 - ttfunk - polyglot (0.3.5) - posix-spawn (0.3.9) - prawn (1.2.1) - pdf-core (~> 0.2.5) - ttfunk (~> 1.2.0) - prawn-svg (0.16.0) - prawn (>= 0.8.4) - prawn-table (0.1.1) - prawn-templates (0.0.3) - pdf-reader (~> 1.3) - prawn (>= 0.15.0) - pygments.rb (0.6.0) - posix-spawn (~> 0.3.6) - yajl-ruby (~> 1.1.0) - rake (10.3.2) - ruby-rc4 (0.1.5) - rubyzip (1.1.6) - thread_safe (0.3.4) - treetop (1.5.3) - polyglot (~> 0.3) - ttfunk (1.2.2) - yajl-ruby (1.1.0) - -PLATFORMS - ruby - -DEPENDENCIES - asciidoctor (= 1.5.0) - asciidoctor-epub3 (= 1.0.0.alpha.2) - asciidoctor-pdf (= 1.5.0.alpha.5) - awesome_print - coderay - epubcheck - json - kindlegen - pygments.rb - rake - thread_safe diff --git a/LICENSE.asc b/LICENSE.asc index 81f2824e2..6d40900c3 100644 --- a/LICENSE.asc +++ b/LICENSE.asc @@ -1 +1,2 @@ -This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. +Αυτό το έργο διατίθεται με άδεια χρήσης σύμφωνα με την Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. +Για να δείτε αντίγραφο της άδειας χρήσης, επισκεφθείτε https://creativecommons.org/licenses/by-nc-sa/3.0 ή στείλτε γράμμα στην διεύθυνση Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. \ No newline at end of file diff --git a/Pro.ico b/Pro.ico new file mode 100644 index 000000000..992dcc6da Binary files /dev/null and b/Pro.ico differ diff --git a/README.asc b/README.asc index f9ddb6577..cc6bc21cb 100644 --- a/README.asc +++ b/README.asc @@ -1,29 +1,21 @@ -= Pro Git, Second Edition += Pro Git, Second Edition - Ελληνική μετάφραση -Welcome to the second edition of the Pro Git book. +Καλώς ήρθατε στην δεύτερη έκδοση του βιβλίου Pro Git. -You can find this book online at: http://git-scm.com/book +Μπορείτε να το βρείτε στην σελίδα: http://git-scm.com/book. -Like the first edition, the second edition of Pro Git is open source under a Creative Commons license. +Όπως και η πρώτη έκδοση, έτσι και η δεύτερη έκδοση του Pro Git είναι ανοιχτού κώδικα κάτω από το Creative Commons license. -A couple of things have changed since open sourcing the first edition. -For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book. -We've also moved to using O'Reilly's https://atlas.oreilly.com[Atlas platform] for generating continuous builds of the book so all major formats are always available in every language. +Μερικά πράγματα έχουν αλλάξει από την πρώτη έκδοση ανοιχτού κώδικα. +Το πρώτο, μεταφέραμε από το Markdown στο εκπλητική AsciiDoc μορφή για το κείμενο του βιβλίου· εδώ https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/[AsciiDoc σύντομη αναφορά]. -We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository. -See link:CONTRIBUTING.md[the Contributing document] for more information. +Επίσης μεταφέραμε τις μεταφράσεις σε διαφορετικά αποθετήρια αντί σε υποκαταλόγους τους Αγγλικού αποθετηρίου. +Βλ. link:TRANSLATING.md[μεταφραστικό εγχειρίδιο] για περισσότερες πληροφορίες. -== How To Generate the Book +== Πως να δημιουργήσετε το βιβλίο -There are two ways to generate e-book content from this source code. - -The easiest way is simply to let us do it. -A robot is standing by to look for new work on the main branch and automatically build it for everyone. - -You can find the current builds on http://git-scm.com/book[] and more information about the builds available at https://progit.org[]. - -The other way to generate e-book files is to do so manually with Asciidoctor. -If you run the following you _may_ actually get HTML, Epub, Mobi and PDF output files: +Για να παράξετε το ηλεκτρονικό-βιβλίο χειροκίνητα χρησιμοποιώντας τον Asciidoctor. +Αν τρέξετε τις παρακάτω εντολές _μπορείτε_ να παράξετε το βιβλίο σε μορφή HTML, Epub, Mobi, και PDF. ---- $ bundle install @@ -35,11 +27,43 @@ Converting to EPub... Converting to Mobi (kf8)... -- Mobi output at progit.mobi Converting to PDF... - -- PDF output at progit.pdf + -- PDF output at progit.pdf +---- + +Μπορείτε να παράξετε μόνο μια μορφή από τις υποστηρίζομενες (HTML, EPUB, mobi, or PDF). +Χρησιμοποιείστε μια από τις ακόλουθες εντολές: + +Για να παράξετε το HTML βιβλίο: + +---- +$ bundle exec rake book:build_html +---- + +Για να παράξετε το EPUB βιβλίο: + ---- +$ bundle exec rake book:build_epub +---- + +Για να παράξετε το mobi βιβλίο: + +---- +$ bundle exec rake book:build_mobi +---- + +Για να παράξετε το PDF βιβλίο: + +---- +$ bundle exec rake book:build_pdf +---- + +== Ενημέρωση για κάποιο Θέμα (Issue) + +Προτού ενημερώσετε για κάποιο θέμα (issue), ελέγξτε ότι δεν είναι ήδη κάποιο παρόμοιο στο σύστημα εντοπισμού σφαλμάτων (bug tracking system). -This uses the `asciidoctor`, `asciidoctor-pdf` and `asciidoctor-epub` projects. +Επίσης, αν αυτό το θέμα (issue) έχει ήδη βρεθεί στη git-scm.com ιστοσελίδα, ελέγξτε ότι υπάρχει ακόμα στο αποθετήριο. +Το θέμα (issue) μπορεί να έχει διορθωθεί, αλλά οι αλλαγές να μην έχουν εφαρμοστεί ακόμα. -== Contributing +== Συνεισφορά -If you'd like to help out by making a change or contributing a translation, take a look at the link:CONTRIBUTING.md[contributor's guide]. +Αν θέλετε να βοηθήσετε κάνοντας κάποια αλλαγή, δείτε τον οδηγό link:CONTRIBUTING.md[οδηγός συνεισφορών]. \ No newline at end of file diff --git a/Rakefile b/Rakefile index 602386729..4f7c3dac9 100644 --- a/Rakefile +++ b/Rakefile @@ -1,30 +1,138 @@ namespace :book do - desc 'prepare build' - task :prebuild do - Dir.mkdir 'images' unless Dir.exists? 'images' - Dir.glob("book/*/images/*").each do |image| - FileUtils.copy(image, "images/" + File.basename(image)) + + # Variables referenced for build + version_string = `git describe --tags --abbrev=0`.chomp + if version_string.empty? + version_string = '0' + else + versions = version_string.split('.') + version_string = versions[0] + '.' + versions[1] + '.' + versions[2].to_i.next.to_s + end + date_string = Time.now.strftime('%Y-%m-%d') + params = "--attribute revnumber='#{version_string}' --attribute revdate='#{date_string}'" + header_hash = `git rev-parse --short HEAD`.strip + + # Check contributors list + # This checks commit hash stored in the header of list against current HEAD + def check_contrib + if File.exist?('book/contributors.txt') + current_head_hash = `git rev-parse --short HEAD`.strip + header = `head -n 1 book/contributors.txt`.strip + # Match regex, then coerce resulting array to string by join + header_hash = header.scan(/[a-f0-9]{7,}/).join + + if header_hash == current_head_hash + puts "Hash on header of contributors list (#{header_hash}) matches the current HEAD (#{current_head_hash})" + else + puts "Hash on header of contributors list (#{header_hash}) does not match the current HEAD (#{current_head_hash}), refreshing" + sh "rm book/contributors.txt" + # Reenable and invoke task again + Rake::Task['book/contributors.txt'].reenable + Rake::Task['book/contributors.txt'].invoke + end end end desc 'build basic book formats' - task :build => :prebuild do - puts "Converting to HTML..." - `bundle exec asciidoctor progit.asc` - puts " -- HTML output at progit.html" + task :build => [:build_html, :build_epub, :build_fb2, :build_mobi, :build_pdf] do + begin + # Run check + Rake::Task['book:check'].invoke + + # Rescue to ignore checking errors + rescue => e + puts e.message + puts 'Error when checking books (ignored)' + end + end + + desc 'build basic book formats (for ci)' + task :ci => [:build_html, :build_epub, :build_fb2, :build_mobi, :build_pdf] do + # Run check, but don't ignore any errors + Rake::Task['book:check'].invoke + end + + desc 'generate contributors list' + file 'book/contributors.txt' do + puts 'Generating contributors list' + sh "echo 'Contributors as of #{header_hash}:\n' > book/contributors.txt" + sh "git shortlog -s HEAD | grep -v -E '(Straub|Chacon|dependabot)' | cut -f 2- | sort | column -c 120 >> book/contributors.txt" + end + + desc 'build HTML format' + task :build_html => 'book/contributors.txt' do + check_contrib() + + puts 'Converting to HTML...' + sh "bundle exec asciidoctor #{params} -a data-uri progit.asc" + puts ' -- HTML output at progit.html' + + end + + desc 'build Epub format' + task :build_epub => 'book/contributors.txt' do + check_contrib() + + puts 'Converting to EPub...' + sh "bundle exec asciidoctor-epub3 #{params} progit.asc" + puts ' -- Epub output at progit.epub' - puts "Converting to EPub..." - `bundle exec asciidoctor-epub3 progit.asc` - puts " -- Epub output at progit.epub" + end + + desc 'build FB2 format' + task :build_fb2 => 'book/contributors.txt' do + check_contrib() + + puts 'Converting to FB2...' + sh "bundle exec asciidoctor-fb2 #{params} progit.asc" + puts ' -- FB2 output at progit.fb2.zip' + + end - puts "Converting to Mobi (kf8)..." - `bundle exec asciidoctor-epub3 -a ebook-format=kf8 progit.asc` - puts " -- Mobi output at progit.mobi" + desc 'build Mobi format' + task :build_mobi => 'book/contributors.txt' do + check_contrib() - puts "Converting to PDF... (this one takes a while)" - `bundle exec asciidoctor-pdf progit.asc 2>/dev/null` - puts " -- PDF output at progit.pdf" + puts "Converting to Mobi (kf8)..." + sh "bundle exec asciidoctor-epub3 #{params} -a ebook-format=kf8 progit.asc" + puts " -- Mobi output at progit.mobi" end + + desc 'build PDF format' + task :build_pdf => 'book/contributors.txt' do + check_contrib() + + puts 'Converting to PDF... (this one takes a while)' + sh "bundle exec asciidoctor-pdf #{params} progit.asc 2>/dev/null" + puts ' -- PDF output at progit.pdf' + end + + desc 'Check generated books' + task :check => [:build_html, :build_epub] do + puts 'Checking generated books' + + sh "htmlproofer progit.html" + sh "epubcheck progit.epub" + end + + desc 'Clean all generated files' + task :clean do + begin + puts 'Removing generated files' + + FileList['book/contributors.txt', 'progit.html', 'progit-kf8.epub', 'progit.epub', 'progit.fb2.zip', 'progit.mobi', 'progit.pdf'].each do |file| + rm file + + # Rescue if file not found + rescue Errno::ENOENT => e + begin + puts e.message + puts 'Error removing files (ignored)' + end + end + end + end + end task :default => "book:build" diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..f1ed9cb69 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,5 @@ +## Reporting a security issue + +If you find any security issue or vulnerability, please email [ben@straub.cc](mailto:ben@straub.cc) with your report. + +Do not open a issue on the `progit/progit2` repository or discuss the vulnerability in public. diff --git a/TRANSLATING.md b/TRANSLATING.md new file mode 100644 index 000000000..b2d1cc9db --- /dev/null +++ b/TRANSLATING.md @@ -0,0 +1,97 @@ +# Μετάφραση Pro Git (2η Έκδοση) + +Οι μεταφράσεις χειρίζονται με αποκεντρωτικό τρόπο. Κάθε ομάδα μετάφρασης συντηρεί το δικό της έργο. Κάθε μετάφραση είναι στο δικός της αποθετήριο, η ομάδα Pro Git απλώς έλκει τις αλλαγές και τις χτίζει μέσα στη https://git-scm.com ιστοσελίδα μόλις είναι έτοιμες. + +## Γενικός οδηγός για την μετάφραση του Pro Git + +Το Pro git βιβλίο είναι για τεχνικό εργαλείο, για αυτό η μετάφρασή του είναι δύσκολη σε σύγκριση με μια μη-τεχνική μετάφραση. + +Τα επόμενα είναι οδηγίες για να σας βοηθήσουν στην πορεία: +* Προτού ξεκινήσετε, διαβάστε όλο το βιβλίο Pro Git στα Αγγλικά, ώστε να είστε ενήμεροι για το περιεχόμενο, και οικίοι με το στυλ που χρησιμοποιείται. +* Βεβαιωθείτε ότι έχετε καλή εργασιακή γνώση του Git, ώστε να μπορείτε να εξηγήσετε τους τεχνικούς όρους. +* Ακολουθείστε ένα κοινό στυλ και μορφοποίηση για την μετάφραση. +* Βεβαιωθείτε ότι διαβάσετε και καταλάβατε τα βασικά της [Asciidoc μορφοποίησης](https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/). Αν δεν ακολουθήσετε την σύνταξη του asciidoc μπορεί να οδηγήσεισε προβλήματα με το χτίσιμο/μεταγλώτισση των pdf, epub και html αρχείων που χρειάζονται για το βιβλίο. + +## Μετάφραση του βιβλίου σε άλλη γλώσσα + +### Βοήθεια με ένα ήδη υπάρχων έργο + +* Ελέγξτε για ήδη υπάρχων έργο στο ακόλουθο πίνακα +* Πηγαίνετε στην σελίδα του έργου στο GitHub. +* Ανοίξτε ένα θέμα (issue), introduce για ρωτήστε που μπορείτε να βοηθήσετε. + +| Language | GitHub page | +| :------------- | :------------- | +| العربية | [progit2-ar/progit2](https://github.com/progit2-ar/progit2) | +| Беларуская | [progit/progit2-be](https://github.com/progit/progit2-be) | +| български език | [progit/progit2-bg](https://github.com/progit/progit2-bg) | +| Čeština | [progit-cs/progit2-cs](https://github.com/progit-cs/progit2-cs) | +| English | [progit/progit2](https://github.com/progit/progit2) | +| Español | [progit/progit2-es](https://github.com/progit/progit2-es) | +| فارسی | [progit2-fa/progit2](https://github.com/progit2-fa/progit2) | +| Français | [progit/progit2-fr](https://github.com/progit/progit2-fr) | +| Deutsch | [progit/progit2-de](https://github.com/progit/progit2-de) | +| Ελληνικά | [progit2-gr/progit2](https://github.com/progit2-gr/progit2) | +| Indonesian | [progit/progit2-id](https://github.com/progit/progit2-id) | +| Italiano | [progit/progit2-it](https://github.com/progit/progit2-it) | +| 日本語 | [progit/progit2-ja](https://github.com/progit/progit2-ja) | +| 한국어 | [progit/progit2-ko](https://github.com/progit/progit2-ko) | +| Македонски | [progit2-mk/progit2](https://github.com/progit2-mk/progit2) | +| Bahasa Melayu| [progit2-ms/progit2](https://github.com/progit2-ms/progit2) | +| Nederlands | [progit/progit2-nl](https://github.com/progit/progit2-nl) | +| Polski | [progit2-pl/progit2-pl](https://github.com/progit2-pl/progit2-pl) | +| Português (Brasil) | [progit/progit2-pt-br](https://github.com/progit/progit2-pt-br) | +| Русский | [progit/progit2-ru](https://github.com/progit/progit2-ru) | +| Slovenščina | [progit/progit2-sl](https://github.com/progit/progit2-sl) | +| Српски | [progit/progit2-sr](https://github.com/progit/progit2-sr) | +| Svenska | [progit2-sv/progit2](https://github.com/progit2-sv/progit2) | +| Tagalog | [progit2-tl/progit2](https://github.com/progit2-tl/progit2) | +| Türkçe | [progit/progit2-tr](https://github.com/progit/progit2-tr) | +| Українська| [progit/progit2-uk](https://github.com/progit/progit2-uk) | +| Ўзбекча | [progit/progit2-uz](https://github.com/progit/progit2-uz) | +| 简体中文 | [progit/progit2-zh](https://github.com/progit/progit2-zh) | +| 正體中文 | [progit/progit2-zh-tw](https://github.com/progit/progit2-zh-tw) | + +### Έναρξη νέας μετάφρασης + +Αν δεν υπάρχει κάποιο έργο για την γλώσσας σας, μπορείτε να ξεκίνησετε την δικιά σας μετάφραση. + +Ορίστε την δουλειά σας στην δεύτερη έκδοση του βιβλίου, διαθέσιμη [εδώ](https://github.com/progit/progit2). Επίσης κάντε: + 1. Επιλέξτε το σωστό [ISO 639 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) για την γλώσσα σας. + 1. Δημιουργήστε ένα [GitHub organization](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch), for example: `progit2-[your code]` στο GitHub. + 1. Δημιουργήστε ένα έργο `progit2`. + 1. Αντιγράψτε τη δομή του progit/progit2 (παρών έργο) μέσα στο δικό σας έργο και ξεκινήστε την μετάφραση. + + ### Ενημέρωση Updating the status of your translation + + Στο https://git-scm.com, οι μεταφράσεις μοιράζονται σε τρεις κατηγορίες. Μόλις φτάσετε σε κάποιο από αυτά τα επίπεδα/κατηγορίες, επικοινωνήστε με τους συντηρητές του https://git-scm.com/ ώστε να έλξουν (pull) τις αλλαγές. + + | Κατηγορία | Ολοκλήρωση | +| :------------- | :------------- | +| Έναρξη μετάφρασης | Μετάφραση εισαγωγής, όχι κάτι άλλο. | +| Μερικώς μεταφράσεις διαθέσιμες | έχουν μεταφραστεί μέχρι την ενότητα 6 | +| Πλήρης μετάφραση διαθέσιμη | το βιβλίο είναι (σχεδόν) ολόκληρο μεταφρασμένο. | + +## Continuous integration με GitHub Actions + +Το GitHub Actions είναι μία [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) υπηρεσία που ενσωματώνεται με το GitHub. GitHub Actions χρησιμοποιούνται για βεβαιώσουν ότι τα αιτήματα-ελκυσμού (pull requests) δεν σπάνε το χτίσιμο ή την μεταγλώτισση. GitHub Actions μπορούν επίσης να δώσουν μεταγλωτισμένες εκδόσεις του βιβλίου. + +Οι ρυθμίσεις για τα GitHub Actions εμπεριέχονται στο `.github/workflows` φάκελο, και αν φέρετε το `main` κλάδο από το αρχικό αποθετήριο θα τα πάρατε και αυτά. +Ωστόσο, αν δημιουργήσατε το αποθετήριο μετάφρασης _αποκόπτωντας_ (_forking_) το αρχικό αποθετήριο, υπάρχει ένα επιπλέον βήμα που πρέπει να κάνετε (αν δεν αποκόψατε (fork), μπορείτε να παραλείψετε αυτό το κομμάτι). +Το GitHub υποθέτει ότι οι αποκόψεις (forks) θα χρησιμοποιηθούν για να συμβάλουν στο αποθετήριο από το οποίο αποκόπηκαν, οπότε θα πρέπει να επισκεφθείτε την ετικέτα "Actions" στο αποκομένο σας αποθετήριο, και να πατήσετε το κουμπί "I understand my workflows" για να επιτρέψετε στα actions να τρέξουν. + +## Ορίζοντας μια αλυσίδα έκδοσης για τα e-books + +Αυτή είναι μια τεχνική δουλειά. Παρακαλούμε ενημερώστε τον @jnavila για να ξεκινήσετε τις epub εκδόσεις. + +## Πέραν του Pro Git + +Η μετάφραση του βιβλίου είναι το πρώτο βήμα. Μόλις το ολοκληρώσετε, μπορείτε να μεταφράσετε το εγχειρίδιο χρήστη του Git. + +Αυτή η δουλειά απαιτεί πιο τεχνική γνωσή του εργαλείου από ότι του βιβλίου. Ελπίζοντας, έχοντας μεταφράσει όλο το περιεχόμενο του βιβλίου, μπορείτε να καταλάβετε τους όρους που χρησιμοποιούνται στην εφαρμογή. Αν νιώθετε τεχνικά έτοιμοι για αυτή τη δουλειά, το αποθετήριο είναι [εδώ](https://github.com/git-l10n/git-po) και πρέπει να ακολουθήσετε τον [οδηγό](https://github.com/git-l10n/git-po/blob/master/po/README.md). + +Προσέξτε όμως ότι: + + * θα πρέπει να χρησιμοποιήσετε συγκεκριμένα εργαλεία για την διαχείριση των po αρχείων (για την επεξεργασία τους [poedit](https://poedit.net/)) και την συγχώνευση τους. Μπορεί να χρειαστεί να μεταγλωτίσσετε το git για να ελέγξετε την δουλειά σας. + * βασική γνώση απαιτείται για το πως δουλεύουν τα μεταφραστικά εργαλεία, που είναι πολύ διαφορετικά από την μετάφραση βιβλίων. + * η βάση του Git έργου χρησιμοποιεί πιο αυστηρές [διαδικασίες](https://github.com/git-l10n/git-po/blob/master/Documentation/SubmittingPatches) για να αποδεχθεί συνεισφορές, βεβαιωθείτε ότι τις ακολουθείτε. \ No newline at end of file diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index aab7e6029..5ad69fdcf 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -1,11 +1,121 @@ -== Translation Notes +== Σημειώσεις σχετικά με τη μετάφραση του βιβλίου -After forking this repository to translate the work, this file is where the notes for coordinating the translation work would go. -Things like standardizing on words and expressions so that the work is consistent or notes on how the contributing process is to be handled. +Το αρχείο αυτό περιλαμβάνει κάποιες λέξεις οι οποίες είναι αρκετά κοινές στο βιβλίο και την μετάφρασή τους (ώστε να υπάρχει μια συνοχή μεταξύ των κεφαλαίων). -As a translation maintainer, also feel free to modify or completely rewrite the README file to contain instructions specific to your translation. +=== Πηγές +* https://el.wikipedia.org/wiki/Git_(λογισμικό)[Σελίδα του Git στην βικιπαίδεια:] Τις περισσότερες μεταφράσεις τις έχω πάρει (papantonis) από την ελληνική αλλά είναι πάντα ανοιχτές για συζήτηση. +* http://www.wordreference.com/engr/[Wordreference: ] Επίσης, μεταξύ των διαφόρων προγραμμάτων μετάφρασης λέξεων που υπάρχουν, χρησιμοποιώ (papantonis) κυρίως το καθώς έχω παρατηρήσει ότι περιέχει πιο περιεκτικές και ακριβείς μεταφράσεις, ειδικά για λέξεις από τον χώρο της πληροφορικής. +* https://glosbe.com/en/el/[Glosbe:] Online λεξικό για πάρα πολλές γλώσσες, έχει και πολλά παραδείγματα (που από όσο έχω καταλάβει είναι αυτόματα τραβηγμένα από επίσημα έγγραφα π.χ. της ΕΕ, υποτίτλους, βιβλία κ.α.) (saragiotis) +* https://www.microsoft.com/en-us/language/[Microsoft language portal] (saragiotis) -=== Translation Status +=== Όροι -As the work is translated, please update the `status.json` file to indicate the rough percentage complete each file is. -This will be shown on various pages to let people know how much work is left to be done. +A +~ +*add* → προσθέτω + +*archive* → αρχειοθετώ (ρ.), αρχειοθήκη *(ουσ.) + +*attribute* → γνώρισμα + +*authenticate/authentication* → ταυτοποιώ/ταυτοποίηση + + +B +~ +*branch (branches)* → κλάδος (κλάδοι) + +*bundle* → δεματιάζω (ρ.), δεμάτι (ουσ.) + + + +C +~ +*centralised Version Control System* → συγκεντρωτικό Σύστημα Ελέγχου Εκδόσεων + +*check out* → Ενημερώνω + +*commit* → Υποβάλλω + +*configuration* → διαμόρφωση + +*customization* (n.) → εξατομίκευση + +*customization* (v.) → εξατομικεύω + +D +~ +*debug* → αποσφαλμάτωση (ουσ.), αποσφαλματώνω (ρ.) + +*directory* → κατάλογος + +*distributed Version Control Systems* → κατανεμημένα Συστήματα Ελέγχου Εκδόσεων + +F +~ +*fast-forward* → ταχυπροώθηση + +*fork* (n.) → διχάλα (σε αναζήτηση καλύτερης μετάφρασης). Στο site της Microsoft αναφέρεται ως ``διπλότυπο'' --καλά θα ήταν το ρήμα και το ουσιαστικό να έχουν την ίδια ρίζα) + +*fork* (v.) → αποσχίζω (σε αναζήτηση καλύτερης μετάφρασης --ίσως αποστασιοποιώ; καλά θα ήταν το ρήμα και το ουσιαστικό να έχουν την ίδια ρίζα) + +H +~ +*handle* → δείκτης χειρισμού + +*hook* → άγκιστρο + + + +I +~ +*issue* → ζήτημα + +K +~ +*kernel* → πυρήνας + +M +~ +*master branch* → κύριος κλάδος + +*merge* → συγχωνεύω + +*metadata* → μεταδεδομένα + +Ν +~ +*namespace* → ονοματοχώρος + + + +P +~ +*patch (n)* → επιδιόρθωση λογισμικού + +*patch (v)* → επιδιορθώνω + +*project* → έργο + +*pull* → τραβώ + +*push* → ωθώ + +R +~ +*repository* → αποθετήριο + +S +~ +*script* → script + +*server* → διακομιστής + +*snapshot* → στιγμιότυπο + +*snippet* → απόσπασμα κώδικα + +*software* → Λογισμικό + +*source code* → πηγαίος κώδικας + +*squash* → συναρμόζω (ρ.), συναρμογή (ουσ.) + +*stable* (for code) → ευσταθής (όχι σταθερός) + +*stablility* → ευστάθεια (όχι σταθερότητα) + +*stage* → καταχωρώ + +*staging area* → στάδιο καταχώρησης + +*stash* → φύλαξη (ουσ.), φυλάω (ρ.) (προηγούμενη εναλλακτική: εναπόθεση) + +T +~ +*token* → διακριτικό + +*topic branch* → θεματικός κλάδος + +*track* → εντοπίζω + + +U +~ +*upload* → μεταφορτώνω + + +V +~ +*version control system* → Σύστημα Ελέγχου Εκδόσεων + +W +~ +*whitespace* → λευκοί χαρακτήρες + +*wrapper* → θύλακας (αναζητείται καλύτερη μετάφραση) + + + +=== Πρόοδος της μετάφρασης + +Αν έχετε μεταφράσει ένα κομμάτι κειμένου, φροντίστε να ανανεώσετε το αρχείο 'status.json' ώστε να μπορούμε να παρακολουθούμε ποιο ποσοστό του κάθε κεφαλαίου έχει μεταφραστεί. Με αυτό τον τρόπο θα μπορούν να δουν όλοι ποια κεφάλαια χρειάζονται περισσότερη δουλειά για να μεταφραστούν 100%. diff --git a/book/01-introduction/1-introduction.asc b/book/01-introduction/1-introduction.asc deleted file mode 100644 index 0809ab839..000000000 --- a/book/01-introduction/1-introduction.asc +++ /dev/null @@ -1,26 +0,0 @@ -[[_getting_started]] -== Getting Started - -This chapter will be about getting started with Git. -We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with. -At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so. - -include::sections/about-version-control.asc[] - -include::sections/history.asc[] - -include::sections/basics.asc[] - -include::sections/command-line.asc[] - -include::sections/installing.asc[] - -include::sections/first-time-setup.asc[] - -include::sections/help.asc[] - -=== Summary - -You should have a basic understanding of what Git is and how it's different from the centralized version control system you may have previously been using. -You should also now have a working version of Git on your system that's set up with your personal identity. -It's now time to learn some Git basics. diff --git a/book/01-introduction/images/areas.png b/book/01-introduction/images/areas.png deleted file mode 100644 index 209bc197f..000000000 Binary files a/book/01-introduction/images/areas.png and /dev/null differ diff --git a/book/01-introduction/images/centralized.png b/book/01-introduction/images/centralized.png deleted file mode 100644 index e8d103ab8..000000000 Binary files a/book/01-introduction/images/centralized.png and /dev/null differ diff --git a/book/01-introduction/images/deltas.png b/book/01-introduction/images/deltas.png deleted file mode 100644 index b914131e2..000000000 Binary files a/book/01-introduction/images/deltas.png and /dev/null differ diff --git a/book/01-introduction/images/distributed.png b/book/01-introduction/images/distributed.png deleted file mode 100644 index 572552cd1..000000000 Binary files a/book/01-introduction/images/distributed.png and /dev/null differ diff --git a/book/01-introduction/images/git-osx-installer.png b/book/01-introduction/images/git-osx-installer.png deleted file mode 100644 index 7490d6935..000000000 Binary files a/book/01-introduction/images/git-osx-installer.png and /dev/null differ diff --git a/book/01-introduction/images/local.png b/book/01-introduction/images/local.png deleted file mode 100644 index abb473d06..000000000 Binary files a/book/01-introduction/images/local.png and /dev/null differ diff --git a/book/01-introduction/images/snapshots.png b/book/01-introduction/images/snapshots.png deleted file mode 100644 index 82eb324ff..000000000 Binary files a/book/01-introduction/images/snapshots.png and /dev/null differ diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index a29ed2f56..5ceb61784 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,62 +1,61 @@ -=== About Version Control +=== Σχετικά με τον έλεγχο εκδόσεων -(((version control))) -What is "version control", and why should you care? -Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. -For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. +(((έλεγχος εκδόσεων))) +Τι είναι ο "`έλεγχος εκδόσεων`" και γιατί πρέπει να μας απασχολεί; +Ο έλεγχος εκδόσεων είναι ένα σύστημα το οποίο καταγράφει αλλαγές σε ένα αρχείο ή σε ένα σύνολο αρχείων έτσι ώστε να μπορούμε να ανακαλέσουμε συγκεκριμένες εκδόσεις τους αργότερα. +Στα παραδείγματα του βιβλίου, τα αρχεία που θα χρησιμοποιήσουμε για έλεγχο εκδόσεων θα είναι αρχεία πηγαίου κώδικα λογισμικού αν και στην πραγματικότητα, θα μπορούσαμε να χρησιμοποιήσουμε αρχεία οποιουδήποτε τύπου. -If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. -It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. -Using a VCS also generally means that if you screw things up or lose files, you can easily recover. -In addition, you get all this for very little overhead. +Αν είμαστε γραφίστες ή σχεδιαστές ιστοσελίδων και θέλουμε να κρατήσουμε κάθε έκδοση κάποιας εικόνας ή κάποιας σελιδοποίησης (κάτι το οποίο είναι εξαιρετικά πιθανό) τότε ένα Σύστημα Ελέγχου Εκδόσεων (Version Control System, VCS) είναι μια πολύ σοφή επιλογή. +Ένα τέτοιο σύστημα μας επιτρέπει να επαναφέρουμε συγκεκριμένα αρχεία, ακόμα και ολόκληρο έργο (project) σε προγενέστερη κατάσταση, να συγκρίνουμε αλλαγές που έχουν γίνει με την πάροδο του χρόνου, να δούμε ποιος τροποποίησε τελευταίος κάτι που ενδεχομένως δημιουργεί κάποιο πρόβλημα, ποιος δημιούργησε κάποιο πρόβλημα και άλλα πολλά. +Η χρήση ενός συστήματος ελέγχου εκδόσεων σημαίνει επίσης ότι αν τα κάνουμε θάλασσα ή χάσουμε αρχεία, είναι εύκολο να τα ανακτήσουμε. +Επιπλέον, όλες αυτές οι δυνατότητες προσφέρονται με πολύ μικρή επιβάρυνση. -==== Local Version Control Systems +==== Τοπικά συστήματα ελέγχου εκδόσεων -(((version control,local))) -Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). -This approach is very common because it is so simple, but it is also incredibly error prone. -It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to. +(((έλεγχος εκδόσεων, τοπικός))) +Η προτιμώμενη από πολλούς μέθοδος για έλεγχο εκδόσεων είναι να αντιγράφουν τα αρχεία σε ένα άλλο φάκελο (πιθανότατα ένα χρονολογημένο κατάλογο αν είναι έξυπνοι). +Αυτή η προσέγγιση είναι πολύ κοινή επειδή είναι τόσο απλή, συγχρόνως όμως είναι και πολύ επιρρεπής σε σφάλματα. +Είναι εύκολο να ξεχάσουμε σε ποιον φάκελο βρίσκομαστε και να επεξεργαστουμε λάθος αρχείο ή να διαγράψουμε λάθος αρχεία. -To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control. +Για να αντιμετωπίσουν αυτό το πρόβλημα οι προγραμματιστές ανέπτυξαν από παλιά τοπικά VCS που είχαν απλή βάση δεδομένων που κρατούσε όλες τις αλλαγές των αρχείων κάτω από έλεγχο εκδόσεων. -.Local version control. -image::images/local.png[Local version control diagram] +.Διάγραμμα τοπικού ελέγχου εκδόσεων +image::images/local.png[Διάγραμμα τοπικού ελέγχου εκδόσεων] -One of the more popular VCS tools was a system called RCS, which is still distributed with many computers today. -Even the popular Mac OS X operating system includes the `rcs` command when you install the Developer Tools. -RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches. +Ένα από τα πιο δημοφιλή VCS ήταν το σύστημα RCS το οποίο διανέμεται ακόμα σε πολλούς υπολογιστές. +Το https://www.gnu.org/software/rcs/[RCS^] δουλεύει χρησιμοποιώντας συλλογές από επιθέματα (patches) (που είναι οι διαφορές μεταξύ αρχείων) σε μια συγκεκριμένη μορφή στον δίσκο. Έπειτα, μπορεί να ξαναδημιουργήσει κάθε αρχείο όπως ήταν σε οποιοδήποτε χρονικό σημείο εφαρμόζοντας όλα τα επιθέματα. -==== Centralized Version Control Systems +==== Συγκεντρωτικά συστήματα ελέγχου εκδόσεων -(((version control,centralized))) -The next major issue that people encounter is that they need to collaborate with developers on other systems. -To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. -These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce))) -For many years, this has been the standard for version control. +(((έλεγχος εκδόσεων, συγκεντρωτικός))) +Το επόμενο σημαντικό πρόβλημα που αντιμετώπισαν οι προγραμματιστές ήταν η ανάγκη για συνεργασία με προγραμματιστές άλλων συστημάτων. +Για την αντιμετώπιση του συγκεκριμένου προβλήματος, αναπτύχθηκαν τα συγκεντρωτικά συστήματα ελέγχου εκδόσεων (Centralized Version Control Systems, CVCSs). +Τα συστήματα αυτά (όπως το CVS, το Subversion και το Perforce) έχουν έναν διακομιστή (server), ο οποίος περιέχει όλα τα αρχεία και κάποιους πελάτες (clients) οι οποίοι ενημερώνουν (check out) τα αρχεία τους από αυτή την κεντρική τοποθεσία. (((CVS)))(((Subversion)))(((Perforce))) +Για πολλά χρόνια, αυτό ήταν και το καθιερωμένο πρότυπο για τα συστήματα ελέγχου εκδόσεων. -.Centralized version control. -image::images/centralized.png[Centralized version control diagram] +.Συγκεντρωτικός έλεγχος εκδόσεων +image::images/centralized.png[Συγκεντρωτικός έλεγχος εκδόσεων] -This setup offers many advantages, especially over local VCSs. -For example, everyone knows to a certain degree what everyone else on the project is doing. -Administrators have fine-grained control over who can do what; and it's far easier to administer a CVCS than it is to deal with local databases on every client. +Αυτή η μέθοδος προσφέρει πολλά πλεονεκτήματα, ειδικά σε σχέση με τα τοπικά VCSs. +Για παράδειγμα, ο καθένας γνωρίζει σε κάποιο βαθμό με τι ασχολούνται όλοι οι υπόλοιποι σε ένα έργο. +Οι διαχειριστές ελέγχουν σε μεγάλο βαθμό τι επιτρέπεται να κάνει ο καθένας και επιπλέον η διαχείριση ενός συγκεντρωτικού συστήματος ελέγχου εκδόσεων είναι πολύ ευκολότερη από τη διαχείριση τοπικών βάσεων δεδομένων σε κάθε πελάτη. -However, this setup also has some serious downsides. -The most obvious is the single point of failure that the centralized server represents. -If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they're working on. -If the hard disk the central database is on becomes corrupted, and proper backups haven't been kept, you lose absolutely everything – the entire history of the project except whatever single snapshots people happen to have on their local machines. -Local VCS systems suffer from this same problem – whenever you have the entire history of the project in a single place, you risk losing everything. +Η συγκεκριμένη μέθοδος έχει όμως και σημαντικά μειονεκτήματα. +Το πιο προφανές είναι το γεγονός ότι μια βλάβη στον κεντρικό διακομιστή προκαλεί την αποτυχία όλου του συστήματος. +Αν ο διακομιστής πέσει για μία ώρα, τότε κατά τη διάρκεια αυτής της ώρας κανείς δεν μπορεί να συνεργαστεί με το VCS ή να αποθηκεύσει αλλαγές σε αυτό. +Αν για παράδειγμα ο σκληρός δίσκος στον οποίο βρίσκεται η κεντρική βάση δεδομένων καταστραφεί και δεν έχουν κρατηθεί τα απαραίτητα αντίγραφα ασφαλείας τότε χάνονται τα πάντα -- ολόκληρο το ιστορικό του έργου χάνεται εκτός από στιγμιότυπα (snapshots) του έργου που μπορεί να έχουν κρατήσει στους υπολογιστές τους κάποιοι προγραμματιστές. +Τα τοπικά VCS πάσχουν από το ίδιο πρόβλημα -- όταν το ιστορικό ενός έργου βρίσκεται σε ένα και μοναδικό μέρος τότε υπάρχει ο κίνδυνος να χαθούν τα πάντα. -==== Distributed Version Control Systems +==== Κατανεμημένα συστήματα ελέγχου εκδόσεων -(((version control,distributed))) -This is where Distributed Version Control Systems (DVCSs) step in. -In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files: they fully mirror the repository. -Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. -Every clone is really a full backup of all the data. +(((έλεγχος εκδόσεων, κατανεμημένος))) +Στο σημείο αυτό έρχονται τα κατανεμημένα (Distributed) DVCS. +Σε ένα κατανεμημένο σύστημα (όπως το Git, το Mercurial ή το Darcs) οι πελάτες δεν ανακτούν μόνο το τελευταίο στιγμιότυπο των αρχείων τους, αλλά ολόκληρο το αποθετήριο (repository), συμπεριλαμβανομένης και ολόκληρου του ιστορικού. +Συνεπώς, στην περίπτωση που ο διακομιστής πεθάνει, τα τοπικά αποθετήρια που έχουν οι πελάτες μπορούν να χρησιμοποιηθούν ώστε να επαναφέρουν τα δεδομένα του. +Κάθε κλώνος είναι ένα πλήρες αντίγραφο ασφαλείας όλων των δεδομένων. -.Distributed version control. -image::images/distributed.png[Distributed version control diagram] +.Διάγραμμα κατανεμημένος έλεγχος εκδόσεων +image::images/distributed.png[.Διάγραμμα κατανεμημένος έλεγχος εκδόσεων] -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. -This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models. +Επιπλέον, πολλά από αυτά τα συστήματα μπορούν να συνεργάζονται με πολλά απομακρυσμένα αποθετήρια, έτσι ώστε να μπορούμε να συνεργαστούμε με πολλές ομάδες και με διαφορετικούς τρόπους ταυτόχρονα στο ίδιο έργο. +Αυτό μας επιτρέπει να δημιουργούμε διάφορους τύπους ροής εργασιών (workflows) όπως ιεραρχικά μοντέλα, που είναι αδύνατο να δημιουργήσουμε σε συγκεντρωτικά συστήματα. diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc deleted file mode 100644 index ee48b38e0..000000000 --- a/book/01-introduction/sections/basics.asc +++ /dev/null @@ -1,108 +0,0 @@ -=== Git Basics - -So, what is Git in a nutshell? -This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. -As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. -Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar, and understanding those differences will help prevent you from becoming confused while using it.(((Subversion)))(((Perforce))) - -==== Snapshots, Not Differences - -The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. -Conceptually, most other systems store information as a list of file-based changes. -These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time. - -.Storing data as changes to a base version of each file. -image::images/deltas.png[Storing data as changes to a base version of each file.] - -Git doesn't think of or store its data this way. -Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem. -Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. -To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored. -Git thinks about its data more like a *stream of snapshots*. - -.Storing data as snapshots of the project over time. -image::images/snapshots.png[Git stores data as snapshots of the project over time.] - -This is an important distinction between Git and nearly all other VCSs. -It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. -This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. -We'll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in <<_git_branching>>. - -==== Nearly Every Operation Is Local - -Most operations in Git only need local files and resources to operate – generally no information is needed from another computer on your network. -If you're used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. -Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. - -For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you – it simply reads it directly from your local database. -This means you see the project history almost instantly. -If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. - -This also means that there is very little you can't do if you're offline or off VPN. -If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. -If you go home and can't get your VPN client working properly, you can still work. -In many other systems, doing so is either impossible or painful. -In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline). -This may not seem like a huge deal, but you may be surprised what a big difference it can make. - -==== Git Has Integrity - -Everything in Git is check-summed before it is stored and is then referred to by that checksum. -This means it's impossible to change the contents of any file or directory without Git knowing about it. -This functionality is built into Git at the lowest levels and is integral to its philosophy. -You can't lose information in transit or get file corruption without Git being able to detect it. - -The mechanism that Git uses for this checksumming is called a SHA-1 hash.(((SHA-1))) -This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. -A SHA-1 hash looks something like this: - -[source] ----- -24b9da6552252987aa493b52f8696cd6d3b00373 ----- - -You will see these hash values all over the place in Git because it uses them so much. -In fact, Git stores everything in its database not by file name but by the hash value of its contents. - -==== Git Generally Only Adds Data - -When you do actions in Git, nearly all of them only add data to the Git database. -It is hard to get the system to do anything that is not undoable or to make it erase data in any way. -As in any VCS, you can lose or mess up changes you haven't committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. - -This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. -For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_undoing>>. - -==== The Three States - -Now, pay attention. -This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. -Git has three main states that your files can reside in: committed, modified, and staged. -Committed means that the data is safely stored in your local database. -Modified means that you have changed the file but have not committed it to your database yet. -Staged means that you have marked a modified file in its current version to go into your next commit snapshot. - -This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. - -.Working directory, staging area, and Git directory. -image::images/areas.png["Working directory, staging area, and Git directory."] - -The Git directory is where Git stores the metadata and object database for your project. -This is the most important part of Git, and it is what is copied when you clone a repository from another computer. - -The working directory is a single checkout of one version of the project. -These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. - -The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. -It's sometimes referred to as the ``index'', but it's also common to refer to it as the staging area. - -The basic Git workflow goes something like this: - -1. You modify files in your working directory. -2. You stage the files, adding snapshots of them to your staging area. -3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. - -If a particular version of a file is in the Git directory, it's considered committed. -If it has been modified and was added to the staging area, it is staged. -And if it was changed since it was checked out but has not been staged, it is modified. -In <<_git_basics_chapter>>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 71888c23c..9a131353f 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,11 +1,11 @@ -=== The Command Line +=== Η γραμμή εντολών -There are a lot of different ways to use Git. -There are the original command line tools, and there are many graphical user interfaces of varying capabilities. -For this book, we will be using Git on the command line. -For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity. -If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true. -Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available. +Υπάρχουν πολλοί διαφορετικοί τρόποι με τους οποίους μπορούμε να χρησιμοποιήσουμε το Git. +Υπάρχουν τα εργαλεία γραμμής εντολών αλλά και διάφορα γραφικά εργαλεία με ποικίλες δυνατότητες. +Στο βιβλίο αυτό θα χρησιμοποιήσουμε το Git μέσα από την γραμμή εντολών. +Καταρχάς, η γραμμή εντολών είναι το μόνο εργαλείο στο οποίο μπορεί κανείς να τρέξει _όλες_ τις εντολές του Git -- για λόγους απλότητας τα περισσότερα από τα γραφικά εργαλεία υλοποιούν μόνο ένα υποσύνολο των λειτουργιών του Git. +Αν γνωρίζετε πώς να χρησιμοποιείτε το Git από την γραμμή εντολών, τότε θα μπορέσετε να καταλάβετε και πώς να χρησιμοποιήσετε τα γραφικά εργαλεία, ενώ το αντίστροφο δεν ισχύει πάντα. +Επίσης, ενώ η επιλογή ενός γραφικού προγράμματος είναι θέμα προσωπικού γούστου, _όλοι_ οι χρήστες έχουν τα εργαλεία γραμμής εντολών εγκατεστημένα και διαθέσιμα. -So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows. -If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book. +Συνεπώς θεωρείται ότι γνωρίζετε πώς να ανοίξετε την εφαρμογή Terminal στο Mac ή τη γραμμή εντολών (Command Prompt) ή το Powershell στα Windows. +Αν δεν γνωρίζετε για τι μιλάμε, ίσως χρειαστεί να αναβάλετε για λίγο την εκμάθηση του Git και να ψάξετε τα παραπάνω ώστε να μπορέσετε να παρακολουθήσετε τα υπόλοιπα παραδείγματα και τις περιγραφές του βιβλίου. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 25034077d..67115a2bc 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,28 +1,40 @@ -[[_first_time]] -=== First-Time Git Setup +[[r_first_time]] +=== Ρύθμιση του Git για πρώτη φορά -Now that you have Git on your system, you'll want to do a few things to customize your Git environment. -You should have to do these things only once on any given computer; they'll stick around between upgrades. -You can also change them at any time by running through the commands again. +Έχοντας πλέον εγκατεστημένο το Git στον υπολογιστή μας, θα χρειαστεί να κάνουμε μερικές ρυθμίσεις ώστε να εξατομικεύσουμε το περιβάλλον του Git. +Τις ρυθμίσεις αυτές θα χρειαστεί να τις κάνουμε μόνο μία φορά σε κάθε υπολογιστή· θα μείνουν ως έχουν μετά από αναβαθμίσεις. +Μπορούμε επίσης να αλλάξουμε τις ρυθμίσεις αυτές απλά και μόνο διατρέχοντας τις εντολές ξανά. -Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.(((git commands, config))) -These variables can be stored in three different places: +Το Git περιέχει ένα εργαλείο που ονομάζεται `git config` (((εντολές git, config))) το οποίο μας επιτρέπει να δούμε και να θέσουμε τιμές στις λεγόμενες μεταβλητές διαμόρφωσης (configuration variables), που ελέγχουν όλες τις πτυχές εμφάνισης και λειτουργίας του Git. +Οι μεταβλητές αυτές αποθηκεύονται σε τρία διαφορετικά μέρη: -1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. - If you pass the option `--system` to `git config`, it reads and writes from this file specifically. -2. `~/.gitconfig` or `~/.config/git/config` file: Specific to your user. - You can make Git read and write to this file specifically by passing the `--global` option. -3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. +1. Στο αρχείο `[path]/etc/gitconfig`: περιέχει τιμές για όλους τους χρήστες του συστήματος και όλα τα αποθετήριά τους. + Αν χρησιμοποιήσουμε την επιλογή `--system` στην εντολή `git config`, τότε η εντολή διαβάζει και γράφει από αυτό το αρχείο. + Επειδή αυτό είναι ένα αρχείο ρύθμισης του συστήματος, πρέπει να έχουμε προνόμια διαχειριστή ή superuser για να το τροποποιήσουμε. +2. Στο αρχείο `~/.gitconfig` ή `~/.config/git/config`: περιέχει τιμές συγκεκριμένες για εμάς, τον χρήστη. + Για να κάνουμε το Git να γράφει και να διαβάζει από αυτό το αρχείο θα πρέπει να χρησιμοποιήσουμε την επιλογή `--global`, και αυτό επηρεάζει όλα τα αποθετήρια με τα οποία εργαζόμαστε στο σύστημά μας. +3. Στο αρχείο `config` στον κατάλογο του Git (το αρχείο αυτό ονομάζεται `.git/config`) του αποθετηρίου το οποίο χρησιμοποιούμε ανά πάσα στιγμή: περιέχει τιμές ειδικά για το συγκεριμένο αποθετήριο. + Μπορούμε να επιβάλουμε στο Git να διαβάζει και να γράφει σε αυτό το αρχείο με την επιλογή `-- local`, που είναι και η προεπιλογή. + Προφανώς, θα πρέπει να βρίσκομαστε μέσα σε κάποιο αποθετήριο Git για να λειτουργήσει σωστά αυτή η εντολή. -Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +Καθένα από τα παραπάνω επίπεδα υπερσκελίζει τις τιμές του προηγούμενου επιπέδου, οπότε οι τιμές του αρχείου `.git/config` υπερσκελίζουν εκείνες του αρχείου `[path]/etc/gitconfig`. -On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). -It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +Σε υπολογιστές Windows, το Git θα αναζητήσει το αρχείο `.gitconfig` στον κατάλογο `$HOME` (συνήθως στην τοποθεσία `C:\Users\$USER`). +Επίσης, θα αναζητήσει το αρχείο `[path]/etc/gitconfig`, η τοποθεσία του οποίου ορίζεται σε σχέση με το MSys root, που αντιστοιχεί στην τοποθεσία στην οποία αποφασίσαμε να εγκαταστήσουμε το Git στα Windows μας, όταν το εγκαθιστούσαμε. +Αν χρησιμοποιούμε την έκδοση 2.x ή μεταγενέστερη του Git για Windows, υπάρχει επίσης ένα αρχείο ρυθμίσεων του συστήματος στον κατάλογο `C:\Documents and Settings\All Users\Application Data\Git\config` στα Windows XP και στον `C:\ProgramData\Git\config` στα Windows Vista ή μεταγενέστερα. +Αυτό το αρχείο ρυθμίσεων μορεί να αλλαχθεί μόνον με την εντολή `git config -f <αρχείο>` όταν εκτελείται από έναν διαχειριστή. -==== Your Identity +Μπορούμε να δούμε όλες τις ρυθμίσεις και από που έρχονται χρησιμοποιώντας: -The first thing you should do when you install Git is to set your user name and e-mail address. -This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: +[source,console] +---- +$ git config --list --show-origin +---- + +==== Η ταυτότητά μας + +Το πρώτο πράγμα που θα πρέπει να κάνουμε αφού εγκαταστήσουμε το Git είναι να ορίσουμε το όνομα χρήστη και τη διεύθυνση e-mail μας. +Το παραπάνω είναι πολύ σημαντικό καθώς κάθε υποβολή (commit) που κάνουμε στο Git θα περιέχει τις πληροφορίες αυτές: [source,console] ---- @@ -30,32 +42,63 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. -If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you're in that project. +Όπως και οι προηγούμενες ρυθμίσεις, έτσι και αυτή χρειάζεται να γίνει μόνο μία φορά αν χρησιμοποιήσουμε την επιλογή `--global`, διότι τότε το Git θα χρησιμοποιεί πάντα αυτές τις πληροφορίες για οτιδήποτε κάνουμε σε αυτό το σύστημα. +Αν θέλουμε να τροποποιήσουμε τις παραπάνω πληροφορίες για συγκεκριμένα έργα τότε μπορούμε να τρέξουμε τις ίδιες εντολές, μέσα από τον κατάλογο του έργου, χωρίς την επιλογή `--global`. + +Πολλά από τα γραφικά εργαλεία θα μας βοηθήσουν σε αυτή τη διαδικασία όταν τα χρησιμοποιήσουμε για πρώτη φορά. -Many of the GUI tools will help you do this when you first run them. +[[r_editor]] +==== Ο επεξεργαστής κειμένου -==== Your Editor +Τώρα που έχουμε ορίσει την ταυτότητά μας, μπορούμε να καθορίσουμε τον επεξεργαστή κειμένου που θα χρησιμοποιούμε όταν το Git μας ζητάει να επεξεργαστούμε κάποιο κείμενο. +Αν δεν τον ρυθμίσουμε, το Git θα χρησιμοποιήσει τον προεπιλεγμένο επεξεργαστή κειμένου του συστήματός μας. -Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. -If not configured, Git uses your system's default editor, which is generally Vim. -If you want to use a different text editor, such as Emacs, you can do the following: +Αν θέλουμε να χρησιμοποιήσουμε έναν διαφορετικό επεξεργαστή κειμένου, όπως τον Emacs, μπορούμε να εκτελέσουμε την εντολή: [source,console] ---- $ git config --global core.editor emacs ---- +Στα Windows, αν θέλουμε να χρησιμοποιήσουμε διαφορετικό επεξεργαστή κειμένου, πρέπει να ορίσουμε ολόκληρο το path στο εκτελέσιμο αρχείο. +Αυτό μπορεί να είναι διαφορετικό ανάλογα πως είναι πακεταρισμένος ο επεξεργαστής κειμένου. + +Στην περίπτωση του Notepad++, ένας δημοφιλείς επεξεργαστής κειμένου, πιθανόν να θέλουμε να χρησιμοποιήσουμε την 32-bit έκδοση, αφού την χρονική περίοδο που γράφεται το βιβλίο η 64-bit έκδοση δεν υποστηρίζει όλα τα πρόσθετα εργαλεία. +Αν είμαστε σε 32-bit Windows σύστημα, ή έχουμε 64-bit επεξεργαστή κειμένου σε 64-bit σύστημα, θα εκτελέσουμε το παρακάτω: + +[source,console] +---- +$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" +---- + +[NOTE] +==== +Ο Vim και ο Emacs είναι δημοφιλείς επεξεργαστές κειμένου που χρησιμοποιούνται συχνά από προγραμματιστές σε λειτουργικά συστήματα που βασίζονται στο Unix, όπως το Linux και το Mac. +Αν χρησιμοποιείτε κάποιον άλλο επεξεργαστή κειμένου, ή κάποια έκδοση 32-bit, μπορείτε να βρείτε οδηγίες για το πώς να εγκαταστήσετε τον αγαπημένο σας επεξεργαστή με το Git στο <>. +==== + [WARNING] ==== -Vim and Emacs are popular text editors often used by developers on Unix based systems like Linux and Mac. -If you are not familiar with either of these editors or are on a Windows system, you may need to search for instructions for how to set up your favorite editor with Git. -If you don't set an editor like this and you don't know what Vim or Emacs are, you will likely get into a really confusing state when they are launched. +Αν δεν ρυθμίσουμε τον επεξεργαστή κειμένου που χρησιμοποιούμε με αυτό τον τρόπο, θα μπερδευτούμε πολύ όταν το Git προσπαθήσει να τον εκκινήσει. +Για παράδειγμα στα Windows, μπορεί μια λειτουργία του Git να τερματιστεί πρόωρα κατά τη διάρκεια της επεξεργασίας. ==== -==== Checking Your Settings +[[r_new_default_branch]] +==== Το προεπιλεγμένο όνομα κλάδου μας -If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: +Το Git εξ ορισμού δημιουργεί έναν κλάδο (branch) με το όνομα _master_, όταν δημιουργούμε ένα καινούριο αποθετήριο με την εντολή `git init`. +Από την έκδοση 2.28 και μετά του Git, μπορούμε να ορίσουμε διαφορετικό όνομα για τον αρχικό κλάδο. + +Για να ορίσουμε ως προεπιλεγμένο όνομα κλάδου το _main_, εκτελούμε: + +[source,console] +---- +$ git config --global init.defaultBranch main +---- + +==== Έλεγχος των ρυθμίσεών μας + +Αν θέλουμε να ελέγξουμε τις ρυθμίσεις μας, μπορούμε να εκτελέσουμε την εντολή `git config --list` για να παραθέσουμε όλες τις ρυθμίσεις του Git: [source,console] ---- @@ -69,13 +112,25 @@ color.diff=auto ... ---- -You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). -In this case, Git uses the last value for each unique key it sees. +Επειδή το Git διαβάζει τις ρυθμίσεις του από διαφορετικά αρχεία (`[path]/etc/gitconfig` και `~/.gitconfig` για παράδειγμα), μπορεί να δούμε κάποιες από αυτές περισσότερες από μια φορά. +Στην περίπτωση αυτή, το Git θα χρησιμοποιήσει την τελευταία τιμή για κάθε ξεχωριστή ρύθμιση. -You can also check what Git thinks a specific key's value is by typing `git config `:(((git commands, config))) +Μπορούμε επίσης να δούμε την τιμή μιας συγκεκριμένης ρύθμισης πληκτρολογώντας `git config `:(((εντολές git, config))) [source,console] ---- $ git config user.name John Doe ---- + +[NOTE] +==== +Επειδή το Git ενδεχομένως μπορεί να διαβάσει την τιμή της ίδιας μεταβλητής ρύθμισης από περισσότερα από ένα αρχεία, είναι δυνατό να δείτε κάποια αναπάντεχη τιμή για κάποια από αυτές τις μεταβλητές χωρίς να γνωρίζετε γιατί. +Σε τέτοιες περιπτώσεις, μπορείτε να ρωτήσετε το Git ποια είναι η προέλευση (_origin_) αυτής της τιμής και θα μας πει ποιο αρχείο ρύθμισης όρισε την τιμή αυτής της παραμέτρου: + +[source,console] +---- +$ git config --show-origin rerere.autoUpdate +file:/home/johndoe/.gitconfig false +---- +==== diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 119a8aff0..d8602e8f1 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -1,7 +1,7 @@ -[[_git_help]] -=== Getting Help +[[r_git_help]] +=== Χρησιμοποιώντας τη βοήθεια -If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: +Αν ποτέ χρειαστoύμε βοήθεια για το Git ενώ το χρησιμοποιούμε, μπορούμε να δούμε τη βοήθεια των σελίδων του εγχειριδίου (manpages) για οποιαδήποτε εντολή του Git με τρεις διαφορετικούς τρόπους: [source,console] ---- @@ -10,13 +10,41 @@ $ git --help $ man git- ---- -For example, you can get the manpage help for the config command by running(((git commands, help))) +Για παράδειγμα, μπορούμε να δούμε τη βοήθεια της σελίδα του εγχειριδίου για την εντολή `git config` εκτελώντας(((εντολές git, help))) [source,console] ---- $ git help config ---- -These commands are nice because you can access them anywhere, even offline. -If the manpages and this book aren't enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). -These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC))) +Οι εντολές αυτές είναι πολύ χρήσιμες καθώς μπορούμε τις χρησιμοποιήσουμε ακόμα και αν είμαστε εκτός δικτύου. +Αν οι σελίδες του εγχειριδίου και αυτό το βιβλίο δεν είναι αρκετά και χρειαζόμαστε πιο άμεση βοήθεια, μπορούμε να δοκιμάσουμε τα κανάλια `#git`, `#github` ή `#gitlab` στον διακομιστή (((IRC))) Libera Chat IRC που βρίσκετα στο https://libera.chat/[^]. +Στα κανάλια αυτά θα βρούμε εκατοντάδες επαΐοντες του Git και συχνά είναι πολύ πρόθυμοι να βοηθήσουν. + +Επιπλέον, αν δεν χρειαζόμαστε την εκτεταμένη βοήθεια του manpage αλλά ένα γρήγορο φρεσκάρισμα των διαθέσιμων επιλογών για μία εντολή του Git, μπορούμε να ρωτήσουμε την πιο συνοπτική "`βοήθεια`" με τις επιλογές `-h` , όπως για παράδειγμα: + +[source,console] +---- +$ git add -h +usage: git add [] [--] ... + + -n, --dry-run dry run + -v, --verbose be verbose + + -i, --interactive interactive picking + -p, --patch select hunks interactively + -e, --edit edit current diff and apply + -f, --force allow adding otherwise ignored files + -u, --update update tracked files + --renormalize renormalize EOL of tracked files (implies -u) + -N, --intent-to-add record only the fact that the path will be added later + -A, --all add changes from all tracked and untracked files + --ignore-removal ignore paths removed in the working tree (same as --no-all) + --refresh don't add, only refresh the index + --ignore-errors just skip files which cannot be added because of errors + --ignore-missing check if - even missing - files are ignored in dry run + --sparse allow updating entries outside of the sparse-checkout cone + --chmod (+|-)x override the executable bit of the listed files + --pathspec-from-file read pathspec from file + --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character +---- diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index df3ebe449..f347aa949 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,20 +1,20 @@ -=== A Short History of Git +=== Σύντομο ιστορικό του Git -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. +Όπως συμβαίνει με πολλά όμορφα πράγματα στη ζωή, έτσι και το Git ξεκίνησε με δυναμικές αντιπαραθέσεις και δημιουργικές καταστροφές. -The Linux kernel is an open source software project of fairly large scope.(((Linux))) -For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. -In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.(((BitKeeper))) +Ο πυρήνας (kernel) του Linux είναι ένα έργο λογισμικού ανοιχτού κώδικα με πολύ ευρύ πεδίο(((Linux))). +Κατά την πρώτη περίοδο συντήρησης του πυρήνα του Linux (1991-2002), οι αλλαγές στο λογισμικό διανέμονταν ως επιθέματα (patches) και αρχειοθετημένα (archived) αρχεία. +Το 2002 ο πυρήνας του Linux άρχισε να χρησιμοποιεί ένα ιδιωτικό κατανεμημένο VCS, το (((BitKeeper))) BitKeeper. -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool's free-of-charge status was revoked. -This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.(((Linus Torvalds))) -Some of the goals of the new system were as follows: +Το 2005, η σχέση ανάμεσα στην κοινότητας που ανέπτυσσε τον πυρήνα του Linux και της εταιρείας που ανέπτυσσε το BitKeeper κατέρρευσε και η δωρεάν χρήση του εργαλείου ανακλήθηκε. +Αυτό προέτρεψε την κοινότητα ανάπτυξης του Linux (και ιδιαίτερα τον Linus (((Linus Torvalds))) Torvalds, τον δημιουργό του) να αναπτύξουν το δικό τους εργαλείο βασιζόμενοι στην εμπειρία που απέκτησαν κατά το διάστημα που χρησιμοποιούσαν το BitKeeper. +Κάποιοι από τους στόχους του νέου συστήματος ήταν οι εξής: -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed -* Able to handle large projects like the Linux kernel efficiently (speed and data size) +* Ταχύτητα +* Απλή σχεδίαση +* Καλή υποστήριξη για έργα με μη γραμμική ανάπτυξη (με χιλιάδες παράλληλους κλάδους) +* Πλήρως κατανεμημένο +* Ικανό να διαχειριστεί μεγάλα έργα όπως τον πυρήνα του Linux αποτελεσματικά (κυρίως όσον αφορά στην ταχύτητα και τον όγκο των δεδομένων) -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. -It's incredibly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<_git_branching>>). +Από τη γέννησή του το 2005 και έπειτα, το Git έχει εξελιχθεί και ωριμάσει κατά τέτοιο τρόπο, ώστε αφενός να είναι εύχρηστο αφετέρου να διατηρεί αυτά τα αρχικά χαρακτηριστικά. +Είναι αξιοθαύμαστα γρήγορο, είναι πολύ αποτελεσματικό σε μεγάλα έργα και επιπλέον διαθέτει ένα απίστευτο σύστημα διαχείρισης κλάδων για μη-γραμμική ανάπτυξη (βλ. <>). diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index ce3eeaf1a..59b0810f4 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -1,99 +1,137 @@ -=== Installing Git +=== Εγκατάσταση του Git -Before you start using Git, you have to make it available on your computer. -Even if it's already installed, it's probably a good idea to update to the latest version. -You can either install it as a package or via another installer, or download the source code and compile it yourself. +Πριν ξεκινήσουμε να χρησιμοποιούμε το Git, θα πρέπει να το εγκαταστήσουμε στον υπολογιστή μας. +Ακόμα και αν είναι ήδη εγκατεστημένο, καλό είναι να το ανανεώσουμε στην τελευταία του έκδοση. +Μπορούμε να το εγκαταστήσουμε είτε ως ξεχωριστό πακέτο, είτε μέσω ενός άλλου προγράμματος εγκατάστασης πακέτων, είτε να κατεβάσουμε τον πηγαίο κώδικα και να τον μεταγλωττίσουμε σε εκτελέσιμα αρχεία. [NOTE] ==== -This book was written using Git version *2.0.0*. -Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. -Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine. +Το βιβλίο αυτό γράφτηκε χρησιμοποιώντας την έκδοση *2* του Git. +Δεδομένου ότι το Git έχει πολύ καλή συμβατότητα προς-τα-πίσω (προς παλιότερες εκδόσεις του), οποιαδήποτε νεότερη έκδοση θα πρέπει να λειτουργεί σωστά. +Αν και οι περισσότερες από τις εντολές που χρησιμοποιούνται στο βιβλίο αυτό θα πρέπει να λειτουργούν και σε πολύ παλιότερες εκδόσεις του Git, μερικές από αυτές μπορεί να έχουν ελαφρώς διαφορετική λειτουργία. ==== -==== Installing on Linux +==== Εγκατάσταση στο Linux -(((Linux, installing))) -If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. -If you're on Fedora for example, you can use yum: +(((Linux, εγκατάσταση))) +Αν θέλουμε να εγκαταστήσουμε το Git σε Linux, μπορούμε να το κάνουμε μέσω του βασικού εργαλείου διαχείρισης πακέτων το οποίο περιλαμβάνεται στη διανομή του Linux που χρησιμοποιούμε. +Αν για παράδειγμα χρησιμοποιούμε το Fedora (ή κάποια παραπλήσια διανομή με RPM), μπορούμε να χρησιμοποιήσουμε το `dnf`: [source,console] - $ sudo yum install git +---- +$ sudo dnf install git-all +---- -If you're on a Debian-based distribution like Ubuntu, try apt-get: +Αν χρησιμοποιούμε κάποια διανομή Debian όπως το Ubuntu, εκτελούμε την εντολή `apt`: [source,console] - $ sudo apt-get install git +---- +$ sudo apt install git-all +---- -For more options, there are instructions for installing on several different Unix flavors on the Git website, at http://git-scm.com/download/linux[]. +Για περισσότερες επιλογές, μπορούμε να βρούμε οδηγίες για την εγκατάστασή του Git σε διάφορες διανομές του Linux στην ιστοσελίδα https://git-scm.com/download/linux[^]. -==== Installing on Mac +==== Εγκατάσταση σε Mac -(((Mac, installing))) -There are several ways to install Git on a Mac. -The easiest is probably to install the Xcode Command Line Tools.(((Xcode))) -On Mavericks (10.9) or above you can do this simply by trying to run 'git' from the Terminal the very first time. -If you don't have it installed already, it will prompt you to install it. +(((Mac, εγκατάσταση))) +Υπάρχουν διάφοροι τρόποι για να εγκαταστήσουμε το Git σε έναν υπολογιστή Mac. +Ο ευκολότερος είναι να εγκαταστήσουμε τα Xcode (((Xcode))) Command Line Tools. +Από την έκδοση Mac Os X Maverics (10.9) και έπειτα, μπορούμε να τα εγκαταστήσουμε απλά τρέχοντας την εντολή `git` από το τερματικό (Terminal) την πρώτη φορά. -If you want a more up to date version, you can also install it via a binary installer. -An OSX Git installer is maintained and available for download at the Git website, at http://git-scm.com/download/mac[]. +[source,console] +---- +$ git --version +---- + +Αν δεν το έχουμε ήδη εγκατεστημένο, θα μας προτρέψει να το εγκαταστήσουμε. -.Git OS X Installer. -image::images/git-osx-installer.png[Git OS X installer.] +Αν θέλουμε μια πιο ενημερωμένη έκδοση, μπορούμε επίσης να εγκαταστήσουμε το Git μέσω ενός installer. +Ένας installer του Git για macOS είναι διαθέσιμος για λήψη στην ιστοσελίδα του Git, https://git-scm.com/download/mac[^]. -You can also install it as part of the GitHub for Mac install. -Their GUI Git tool has an option to install command line tools as well. -You can download that tool from the GitHub for Mac website, at http://mac.github.com[]. +.Πρόγραμμα εγκατάσης του Git για το OS X +image::images/git-osx-installer.png[Πρόγραμμα εγκατάσης του Git για το OS X] -==== Installing on Windows +==== Εγκατάσταση σε Windows -There are also a few ways to install Git on Windows.(((Windows, installing))) -The most official build is available for download on the Git website. -Just go to http://git-scm.com/download/win[] and the download will start automatically. -Note that this is a project called Git for Windows (also called msysGit), which is separate from Git itself; for more information on it, go to http://msysgit.github.io/[]. +Υπάρχουν επίσης αρκετοί τρόποι για να εγκαταστήσουμε το Git σε Windows.(((Windows, εγκατάσταση))) +Η πιο επίσημη έκδοση είναι διαθέσιμη για λήψη από την ιστοσελίδα του Git. +Απλά πηγαίνουμε στο https://git-scm.com/download/win[^] και η λήψη θα ξεκινήσει αυτόματα. +Σημειώνουμε ότι το πρόγραμμα αυτό ονομάζεται Git για Windows, που είναι διαφορετικό πρόγραμμα από το ίδιο το Git· για περισσότερες πληροφορίες σχετικά, πηγαίνουμε στην ιστοσελίδα https://gitforwindows.org[^]. -Another easy way to get Git installed is by installing GitHub for Windows. -The installer includes a command line version of Git as well as the GUI. -It also works well with Powershell, and sets up solid credential caching and sane CRLF settings.(((Powershell)))(((CRLF)))(((credential caching))) -We'll learn more about those things a little later, but suffice it to say they're things you want. -You can download this from the GitHub for Windows website, at http://windows.github.com[]. +Για αυτόματη εγκατάσταση μπορούμε να χρησιμοποιήσουμε το https://community.chocolatey.org/packages/git[πακέτο Git Chocolatey^]. +Σημειώνουμε ότι το πακέτο Chocolatey συντηρείται από την κοινότητα. +==== Εγκατάσταση από τον πηγαίο κώδικα -==== Installing from Source +Κάποιοι βρίσκουν πιο χρήσιμο να εγκαταστήσουν το Git από τον πηγαίο του κώδικα, επειδή με αυτό τον τρόπο θα έχουν την πιο πρόσφατη έκδοση. +Οι εφαρμογές εγκατάστασης που αναφέραμε προηγουμένως τείνουν να υστερούν ελαφρώς χρονικά, αλλά καθώς το Git έχει ωριμάσει τα τελευταία χρόνια, δεν θα δούμε κάποια εντυπωσιακή διαφορά. -Some people may instead find it useful to install Git from source, because you'll get the most recent version. -The binary installers tend to be a bit behind, though as Git has matured in recent years, this has made less of a difference. +Αν πραγματικά θέλουμε να εγκαταστήσουμε το Git από τον πηγαίο του κώδικα, θα πρέπει να έχουμε τις παρακάτω βιβλιοθήκες από τις οποίες εξαρτάται το Git: autotools, curl, zlib, openssl, expat και libiconv. +Για παράδειγμα, αν έχουμε ένα λειτουργικό σύστημα το οποίο χρησιμοποιεί το `dnf` (όπως το Fedora) ή το `apt-get` (όπως τα συστήματα Debian), μπορούμε να χρησιμοποιήσουμε μία από τις παρακάτω εντολές για να εγκαταστήσουμε τα ελάχιστα προαπαιτούμενα για να μεταγλωτίσσουμε και να εγκαταστήσουμε το Git: + +[source,console] +---- +$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \ + openssl-devel perl-devel zlib-devel +$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ + gettext libz-dev libssl-dev +---- -If you do want to install Git from source, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. -For example, if you're on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: +Για να έχουμε τη δυνατότητα να προσθέσουμε την τεκμηρίωση (documentation) σε διάφορες μορφές (doc, html, info), θα χρειαστούμε επίσης τα παρακάτω: [source,console] - $ sudo yum install curl-devel expat-devel gettext-devel \ - openssl-devel zlib-devel - $ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ - libz-dev libssl-dev +---- +$ sudo dnf install asciidoc xmlto docbook2X +$ sudo apt-get install asciidoc xmlto docbook2x +---- + +[NOTE] +==== +Χρήστες του RHEL και των παραγώγων του, όπως το CentOS και το Scientific Linux θα χρειαστεί https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages[να ενεργοποιήσουν το αποθετήριο EPEL^] για να κατέβει το πακέτο `docbook2X`. +==== -In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required: +Αν χρησιμοποιούμε κάποια διανομή Debian (Debian/Ubuntu/παράγωγα του Ubuntu), τότε χρειαζόμαστε ακόμα το πακέτο `install-info`: [source,console] - $ sudo yum install asciidoc xmlto docbook2x - $ sudo apt-get install asciidoc xmlto docbook2x +---- +$ sudo apt-get install install-info +---- + +Αν χρησιμοποιούμε κάποια διανομή RPM (Fedora/RHEL/παράγωγα του RHEL), θα χρειαστούμε ακόμα το πακέτο getopt (που είναι ήδη εγκατεστημένο στις διανομές Debian): + +[source,console] +---- +$ sudo dnf install getopt +---- + +Επιπλέον, αν χρησιμοποιούμε Fedora/RHEL/παράγωγα του RHEL, θα πρέπει να κάνουμε το εξής: + +[source,console] +---- +$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi +---- + +εξαιτίας διαφορών στο όνομα του binary. -When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. -You can get it via the Kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub web site, at https://github.com/git/git/releases[]. -It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. +Εφόσον έχουμε εγκαταστήσει όλα τα απαραίτητα προαπαιτούμενα, μπορούμε να προχωρήσουμε και να κατεβάσουμε την τελευταία έκδοσης του Git από διάφορα μέρη. +Μπορούμε να την αποκτήσουμε από την ιστοσελίδα του kernel.org, https://www.kernel.org/pub/software/scm/git[^], ή την αντίστοιχη ιστοσελίδα του Github, https://github.com/git/git/tags[^]. +Γενικά, είναι πιο εύκολο να βρούμε την τελευταία έκδοση στην ιστοσελίδα του Github, αλλά στο kernel.org θα βρούμε επίσης ψηφιακές υπογραφές της έκδοσης (release signatures) για να επαληθεύσουμε τη λήψη μας. -Then, compile and install: +Μπορούμε πλέον να μεταγλωττίσουμε και να εγκαταστήσουμε: [source,console] - $ tar -zxf git-2.0.0.tar.gz - $ cd git-2.0.0 - $ make configure - $ ./configure --prefix=/usr - $ make all doc info - $ sudo make install install-doc install-html install-info +---- +$ tar -zxf git-2.8.0.tar.gz +$ cd git-2.8.0 +$ make configure +$ ./configure --prefix=/usr +$ make all doc info +$ sudo make install install-doc install-html install-info +---- -After this is done, you can also get Git via Git itself for updates: +Αφού ολοκληρωθεί η παραπάνω διαδικασία, μπορούμε επίσης να πάρουμε το Git μέσω του ίδιου του Git, ώστε να παίρνουμε τις ενημερωμένες εκδόσεις: [source,console] - $ git clone git://git.kernel.org/pub/scm/git/git.git +---- +$ git clone https://git.kernel.org/pub/scm/git/git.git +---- diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc new file mode 100644 index 000000000..28a8f55c0 --- /dev/null +++ b/book/01-introduction/sections/what-is-git.asc @@ -0,0 +1,109 @@ +[[r_what_is_git_section]] +=== Τι είναι το Git; + +Τι είναι, λοιπόν, το Git με λίγα λόγια; +Η συγκεκριμένη ενότητα είναι σημαντική επειδή αν καταλάβουμε τι είναι το Git και πώς δουλεύει, θα είναι πιο εύκολο να το χρησιμοποιήσουμε αποτελεσματικά. +Καθώς μαθαίνουμε το Git, ας προσπαθήσουμε να αδειάσουμε το μυαλό μας από γνώσεις που μπορεί να έχουμε για άλλα συστήματα ελέγχου έκδοσεων, όπως το Subversion (((Subversion))) και το (((Perforce))) Perforce -- με αυτό τον τρόπο θα αποφύγουμε την όποια σύγχυση όταν χρησιμοποιούμε το εργαλείο. +Αν και η διεπαφή χρήστη του Git είναι παρόμοια με αυτές των άλλων VCS, το Git αποθηκεύει και αντιμετωπίζει τα δεδομένα με πολύ διαφορετικό τρόπο και η κατανόηση των διαφορών θα μας βοηθήσει να μην μπερδευόμαστε όταν το χρησιμοποιούμε. + +==== Στιγμιότυπα, όχι διαφορές + +Η σημαντικότερη διαφορά ανάμεσα στο Git και τα άλλα VCS συστήματα βρίσκεται στον τρόπο με τον οποίο το Git αντιλαμβάνεται τα δεδομένα. +Εννοιολογικά, τα περισσότερα συστήματα αποθηκεύουν τις πληροφορίες ως μια λίστα από αλλαγές σε αρχεία. +Αυτά τα συστήματα (CVS, Subversion, Perforce, και άλλα) αντιμετωπίζουν τις πληροφορίες που αποθηκεύουν ως ένα σύνολο αρχείων και αλλαγών που έχουν γίνει στα αρχεία με την πάροδο του χρόνου (αυτός ο τρόπος ονομάζεται συνήθως έλεγχος εκδόσεων _βασισμένος στις διαφορές_ (delta-based)). + +.Αποθήκευση των δεδομένων ως διαφορών σε σχέση με μία βασική έκδοση κάθε αρχείου +image::images/deltas.png[Αποθήκευση των δεδομένων ως διαφορών σε σχέση με μία βασική έκδοση κάθε αρχείου] + +Το Git δεν αντιλαμβάνεται ούτε αποθηκεύει δεδομένα με αυτό τον τρόπο. +Αντίθετα, το Git αντιλαμβάνεται τα δεδομένα ως μια σειρά στιγμιοτύπων ενός μικροσκοπικού συστήματος αρχείων (file system). +Κάθε φορά που υποβάλουμε (commit) ή αποθηκεύουμε την κατάσταση του έργου μας, το Git παίρνει μια φωτογραφία της εικόνας των αρχείων μας εκείνη τη στιγμή και αποθηκεύει έναν δείκτη (reference) σε αυτό το στιγμιότυπο. +Για να είναι πιο αποδοτικό, το Git δεν ξαναποθηκεύει ένα αρχείο, εφόσον αυτό δεν έχει τροποποιηθεί, απλώς αποθηκεύει έναν σύνδεσμο προς το προηγούμενο όμοιο αρχείο το οποίο έχει ήδη αποθηκευτεί. +Το Git λοιπόν αντιλαμβάνεται τα δεδομένα περισσότερο σαν μία *ροή από στιγμιότυπα*. + +.Αποθήκευση δεδομένων ως στιγμιοτύπων του έργου με την πάροδο του χρόνου. +image::images/snapshots.png[Αποθήκευση δεδομένων ως στιγμιοτύπων του έργου με την πάροδο του χρόνου.] + +Αυτή είναι μια πολύ σημαντική διαφορά μεταξύ του Git και σχεδόν όλων των υπόλοιπων συστημάτων ελέγχου εκδόσεων. +Αναγκάζει το Git να αναθεωρήσει σχεδόν όλες τις πτυχές του ελέγχου εκδόσεων, που αντέγραψαν τα υπόλοιπα συστήματα από την προηγούμενη γενιά. +Αυτό κάνει το Git να φαντάζει σαν ένα μίνι σύστημα αρχείων με πολλά εργαλεία φτιαγμένα πάνω σε αυτό παρά σαν ένα απλό VCS. +Θα διερευνήσουμε κάποια από τα οφέλη που κερδίζουμε όταν χρησιμοποιούμε τα δεδομένα με αυτό τον τρόπο όταν καλύψουμε τις διακλαδώσεις (branches) του Git <>. + +==== Σχεδόν όλες οι λειτουργίες εκτελούνται τοπικά + +Οι περισσότερες λειτουργίες στο Git χρειάζονται μόνο τοπικά αρχεία και πόρους για να εκτελεστούν -- γενικά, δεν χρειάζεται να μεταφερθεί καμία πληροφορία από κάποιον άλλο υπολογιστή του δικτύου μας. +Αν είστε συνηθισμένοι σε ένα συγκεντρωτικό VCS, όπου οι περισσότερες λειτουργίες καθυστερούν εξαιτίας του χρόνου απόκρισης του δικτύου, τότε αυτή η πτυχή του Git θα μας κάνει να νομίζουμε ότι οι θεοί της ταχύτητας ευλόγησαν το Git με υπερκόσμιες δυνάμεις. +Οι περισσότερες λειτουργίες στο Git φαίνονται σχεδόν στιγμιαίες, κυρίως λόγω του ότι το πλήρες ιστορικό του έργου βρίσκεται στον τοπικό μας δίσκο. + +Για παράδειγμα, για να δούμε στο ιστορικό του έργου μας, το Git δεν χρειάζεται να λάβει το ιστορικό από τον διακομιστή και να το εμφανίσει στον χρήστη -- χρειάζεται απλά να το διαβάσει από την τοπική μας βάση δεδομένων. +Αυτό σημαίνει ότι μπορούμε να δούμε το ιστορικό του έργου μας σχεδόν στιγμιαία. +Αν θέλουμε να δούμε τις αλλαγές που εισήχθησαν ανάμεσα στην τρέχουσα έκδοση ενός αρχείου και στην έκδοσή του πριν από ένα μήνα, το Git θα εντοπίσει το αρχείο όπως ήταν πριν από ένα μήνα και θα κάνει έναν τοπικό υπολογισμό των διαφορών, αντί να ζητήσει από τον διακομιστή να το κάνει ή να τραβήξει την παλιά έκδοση του αρχείου και να υπολογίσει τις διαφορές τοπικά. + +Αυτό επιπλέον σημαίνει ότι είναι πολύ λίγες οι λειτουργίες που δεν μπορούμε να κάνουμε όταν είμαστε εκτός δικτύου ή δεν είμαστε συνδεδεμένοι στο VPN. +Αν βρισκόμαστε σε ένα αεροπλάνο ή στο τρένο και θέλουμε να εργαστούμε, μπορούμε να υποβάλουμε τις αλλαγές μας χωρίς πρόβλημα (στο _τοπικό_ μας αντίγραφο) και να τις μεταφορτώσουμε όταν ξανασυνδεθούμε στο δίκτυο. +Αν βρισκόμαστε στο σπίτι μας και το VPN client μας δεν δουλεύει καλά και δεν μπορούμε να συνδεθούμε, μπορούμε ακόμα να εργαστούμε. +Σε πολλά άλλα συστήματα, αυτό είναι είτε αδύνατο είτε επίπονο. +Για παράδειγμα, στο Perforce δεν μπορούμε να κάνουμε πολλά πράγματα αν δεν είμαστε συνδεδεμένοι με τον διακομιστή· στο Subversion και το CVS μπορούμε να επεξεργαστούμε αρχεία, αλλά δεν είναι δυνατό υποβάλουμε τις αλλαγές στη βάση δεδομένων μας (διότι δεν είμαστε συνδεδεμένοι με αυτή). +Τα παραπάνω μπορεί να μην φαίνονται πολύ σημαντικά, αλλά θα εκπλαγούμε με το πόσο μεγάλη διαφορά μπορεί να κάνουν. + +==== To Git έχει ακεραιότητα + +Οτιδήποτε υπάρχει στο Git περνά από έλεγχο αθροίσματος (checksum) πριν αποθηκευτεί και έπειτα μπορούμε να αναφερόμαστε σε αυτό το άθροισμα ελέγχου. +Αυτό σημαίνει ότι είναι αδύνατο κάποιος να αλλάξει το περιεχόμενο ενός αρχείου ή ενός καταλόγου χωρίς το Git να το γνωρίζει. +Η λειτουργικότητα αυτή είναι ενσωματωμένη στο Git στα χαμηλότερα επίπεδα και είναι αναπόσπαστη από τη φιλοσοφία του. +Είναι αδύνατο να χαθεί πληροφορία κατά τη μεταφορά της ή να παραφθαρεί κάποιο αρχείο χωρίς το Git να το ανιχνεύσει. + +Ο μηχανισμός που χρησιμοποιεί το Git για τον αθροιστικό έλεγχο ονομάζεται κατακερματισμός SHA-1.(((SHA-1))) +Το SHA-1 είναι μια συμβολοσειρά 40 δεκαεξαδικών ψηφίων (0-9 και a-f) και υπολογίζεται με βάση τα περιεχόμενα μιας δομής αρχείου ή φακέλου στο Git. +Μια συμβολοσειρά με κατακερματισμό SHA-1 έχει αυτή τη μορφή: + +[source] +---- +24b9da6552252987aa493b52f8696cd6d3b00373 +---- + +Θα βλέπουμε αυτές τις κατακερματισμένες τιμές παντού στο Git γιατί τις χρησιμοποιεί πολύ. +Μάλιστα, το Git αποθηκεύει τα πάντα στη βάση δεδομένων του με βάση την κατακερματισμένη τιμή των περιεχομένων ενός αρχείου και όχι με βάση το όνομα του αρχείου. + +==== Το Git γενικά μόνο προσθέτει δεδομένα + +Όταν κάνουμε κάτι στο Git, σχεδόν πάντα προσθέτονται δεδομενα στη βάση δεδομένων του Git. +Είναι σχεδόν αδύνατο να αναγκάσουμε το σύστημα να κάνει κάτι που δεν αναιρείται ή να διαγράψει δεδομένα. +Όπως σε κάθε σύστημα διαχείρισης ελέγχου εκδόσεων (VCS) είναι δυνατό να χάσουμε ή να μπουρδουκλώσουμε αλλαγές που δεν έχουν υποβληθεί ακόμα, αλλά από τη στιγμή που υποβάλουμε ένα στιγμιότυπο στο Git είναι πολύ δύσκολο να χαθεί, ειδικά αν ωθήσουμε (push) την τοπική μας βάση δεδομένων τακτικά σε κάποιο άλλο αποθετήριο. + +Αυτό καθιστά τη χρήση του Git ευχάριστη διότι γνωρίζουμε ότι μπορούμε να πειραματιστούμε χωρίς να φοβόμαστε ότι θα τα κάνουμε μαντάρα. +Μια πιο διεξοδική ματιά στο πώς αποθηκεύει τα δεδομένα του το Git και πώς μπορούμε να ανακτήσουμε δεδομένα που φαίνονται χαμένα, υπάρχει στην ενότητα <>. + +==== Οι τρεις καταστάσεις + +Και τώρα προσοχή -- το παρακάτω είναι το βασικό πράγμα που πρέπει να θυμόμαστε για το Git, αν θέλουμε η υπόλοιπη διαδικασία μάθησής του να κυλήσει ομαλά. +Τα αρχεία στο Git μπορούν να βρίσκονται σε τρεις κύριες καταστάσεις: _τροποποιημένο_ (_modified_), _επισημασμένο_ (_staged_) και _υποβεβλημένο_ (_committed_). + +* Τροποποιημένο (modified) σημαίνει ότι το αρχείο έχει αλλάξει, αλλά δεν έχει ακόμα δεσμευτεί στη βάση δεδομένων. +* Επισημασμένο (staged) σημαίνει ότι ένα τροποποιημένο αρχείο της τρέχουσας έκδοσης όταν έχει επισημανθεί για βρίσκεται στο επόμενο υποβεβλημένο στιγμιότυπο. +* Υποβεβλημένο (commited) είναι ένα αρχείο όταν τα δεδομένα του είναι αποθηκευμένα με ασφάλεια στην τοπική βάση δεδομένων. + +Αυτό μας φέρνει στις τρεις βασικές περιοχές ενός έργου στο Git: το δέντρο εργασίας, τον προθάλαμο και τον κατάλογο του Git. + +.Κατάλογος εργασίας, προθάλαμος και κατάλογος του Git +image::images/areas.png["Δέντρο εργασίας, προθάλαμος και κατάλογος του Git"] + +Το δέντρο εργασίας είναι το στιγμιότυπο μίας έκδοσης του έργου. +Τα αρχεία ανασύρονται (pulled) από τη συμπιεσμένη βάση δεδομένων του καταλόγου του Git και τοποθετούνται στον τοπικό δίσκο ώστε να τα χρησιμοποιήσουμε ή να τα τροποποιήσoυμε. + +Ο προθάλαμος είναι ένα αρχείο το οποίο γενικά περιλαμβάνεται στον κατάλογο μας του Git, στο οποίο είναι αποθηκευμένες πληροφορίες σχετικά με το τι θα υποβληθεί στην επόμενη υποβολή (commit). +Το τεχνικό όνομα του προθαλάμου στην ορολογία του Git είναι "`index`" (ευρετήριο), αλλά το όνομα "`staging area`" (προθάλαμος) είναι επίσης σύνηθες. + +Ο κατάλογος του Git είναι το μέρος όπου το Git αποθηκεύει τα μεταδεδομένα (metadata) και τη βάση δεδομένων των αντικειμένων του έργου. +Αυτό είναι το πιο σημαντικό τμήμα του Git και είναι αυτό που αντιγράφεται όταν δημιουργούμε έναν _κλώνο_ ενός αποθετηρίου από έναν άλλο υπολογιστή. + +Η βασική ροή εργασίας του Git είναι κάτι σαν το εξής: + +1. Τροποποιούμε κάποια αρχεία στον δεντρο εργασίας μας. +2. Επιλέγουμε ποιες αλλαγές θέλουμε να υποβληθούν στην επόμενη υποβολή, τοποθετώντας _μόνο_ αυτές τις αλλαγές στον προθάλαμο. +3. Πραγματοποιούμε μια υποβολή, η οποία παίρνει τα αρχεία όπως είναι στον προθάλαμο και αποθηκεύει αυτό το στιγμιότυπο μόνιμα στον κατάλογο του Git. + +Αν μια συγκεκριμένη έκδοση ενός αρχείου βρίσκεται στον κατάλογο του Git, θεωρείται _υποβεβλημένο_ (committed). +Αν έχει τροποποιηθεί και έχει προστεθεί στον προθάλαμο, ονομάζεται _επισημασμένο_ (staged). +Τέλος, αν έχει τροποποιηθεί από τότε που ανακλήθηκε αλλά δεν έχει επισημανθεί, τότε λέμε ότι είναι _τροποποιημένο_. +Στο κεφάλαιο <>, θα μάθουμε περισσότερα για αυτές τις καταστάσεις και για το πώς μπορούμε να τις εκμεταλευτούμε ή να παρακάμψουμε εντελώς τον προθάλαμο. diff --git a/book/02-git-basics/1-git-basics.asc b/book/02-git-basics/1-git-basics.asc deleted file mode 100644 index 14d3d34b0..000000000 --- a/book/02-git-basics/1-git-basics.asc +++ /dev/null @@ -1,26 +0,0 @@ -[[_git_basics_chapter]] -== Git Basics - -If you can read only one chapter to get going with Git, this is it. -This chapter covers every basic command you need to do the vast majority of the things you'll eventually spend your time doing with Git. -By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. -We'll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. - -include::sections/getting-a-repository.asc[] - -include::sections/recording-changes.asc[] - -include::sections/viewing-history.asc[] - -include::sections/undoing.asc[] - -include::sections/remotes.asc[] - -include::sections/tagging.asc[] - -include::sections/aliases.asc[] - -=== Summary - -At this point, you can do all the basic local Git operations – creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. -Next, we'll cover Git's killer feature: its branching model. diff --git a/book/02-git-basics/images/lifecycle.png b/book/02-git-basics/images/lifecycle.png deleted file mode 100644 index 1ef9e6848..000000000 Binary files a/book/02-git-basics/images/lifecycle.png and /dev/null differ diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index fd442420b..c42bef342 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -1,13 +1,13 @@ -[[_git_aliases]] -=== Git Aliases +[[r_git_aliases]] +=== Συντομεύεσεις στο Git (((aliases))) -Before we finish this chapter on basic Git, there's just one little tip that can make your Git experience simpler, easier, and more familiar: aliases. -We won't refer to them or assume you've used them later in the book, but you should probably know how to use them. +Πριν προχωρήσουμε στο επόμενο κεφάλαιο, θέλουμε να εισάγουμε μια λειτουργικότητα που μπορεί να διευκολύνει και απλουστεύσει την εμπειρία μας με το Git: τα ψευδώνυμα. +Δεν θα τα χρησιμοποιήσουμε πουθενά αλλού σε αυτό το βιβλίο, αλλά αν σκοπεύουμε να χρησιμοποιούμε το Git τακτικά, τα ψευδώνυμα είναι κάτι που πρέπει να γνωρίζουμε. -Git doesn't automatically infer your command if you type it in partially. -If you don't want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`.(((git commands, config))) -Here are a couple of examples you may want to set up: +Το Git δεν μπορεί να μαντέψει μια εντολή αν τη γράψουμε μόνο μερικώς. +Αν δεν θέλουμε να πληκτρολογούμε όλα τα γράμματα των εντολών του Git, μπορούμε εύκολα να ορίσουμε ένα ψευδώνυμο για κάθε εντολή με την εντολή `git config`.(((εντολές git, config))) +Μερικά παραδείγματα για το πώς μπορούμε να ορίσουμε μερικά ψευδώνυμα: [source,console] ---- @@ -17,34 +17,34 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -This means that, for example, instead of typing `git commit`, you just need to type `git ci`. -As you go on using Git, you'll probably use other commands frequently as well; don't hesitate to create new aliases. +Αυτό σημαίνει ότι μπορούμε, για παράδειγμα, να πληκτρολογήσουμε `git ci` αντί για `git commit`. +Καθώς χρησιμοποιούμε το Git, θα δούμε ότι υπάρχουν και άλλες εντολές που χρησιμοποιούμε συχνά -- μην διστάσουμε να δημιουργήσουμε νέα ψευδώνυμα. -This technique can also be very useful in creating commands that you think should exist. -For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: +Η τεχνική αυτή μπορεί να φανεί χρήσιμη για να δημιουργήσουμε εντολές που πιστεύουμε ότι θα έπρεπε να υπήρχαν. +Για παράδειγμα, αν θέλουμε να κάνουμε πιο εύχρηστη τη διαδικασία αφαίρεσης ενός αρχείου από τον προθάλαμο, μπορούμε να δημιουργήσουμε ένα ψευδώνυμο: [source,console] ---- $ git config --global alias.unstage 'reset HEAD --' ---- -This makes the following two commands equivalent: +Αυτό καθιστά τις δύο παρακάτω εντολές ισοδύναμες: [source,console] ---- $ git unstage fileA -$ git reset HEAD fileA +$ git reset HEAD -- fileA ---- -This seems a bit clearer. -It's also common to add a `last` command, like this: +Η εντολή που εκτελούμε φαίνεται πλέον πιο καθαρά. +Το ψευδώνυμο `last` είναι επίσης πολύ συνηθισμένο: [source,console] ---- $ git config --global alias.last 'log -1 HEAD' ---- -This way, you can see the last commit easily: +Με αυτό τον τρόπο μπορούμε να δούμε πιο εύκολα την τελευταία υποβολή: [source,console] ---- @@ -53,16 +53,16 @@ commit 66938dae3329c7aebe598c2246a8e6af90d04646 Author: Josh Goebel Date: Tue Aug 26 19:48:51 2008 +0800 - test for current head + Test for current head Signed-off-by: Scott Chacon ---- -As you can tell, Git simply replaces the new command with whatever you alias it for. -However, maybe you want to run an external command, rather than a Git subcommand. -In that case, you start the command with a `!` character. -This is useful if you write your own tools that work with a Git repository. -We can demonstrate by aliasing `git visual` to run `gitk`: +Όπως μπορούμε να δούμε, το Git μπορεί να αντικαταστήσει μια εντολή με οποιοδήποτε ψευδώνυμο ορίσουμε. +Μπορεί όμως αντί για μια εντολή του Git, να θέλουμε να εκτελέσουμε μια εξωτερική εντολή. +Στην περίπτωση αυτή, θα πρέπει να ξεκινήσουμε την εντολή με τον χαρακτήρα `!`. +Αυτό θα μας φανεί χρήσιμο αν γράφουμε δικά μας εργαλεία που δουλεύουν με αποθετήρια Git. +Για παράδειγμα, μπορούμε να χρησιμοποιήσουμε το ψευδώνυμο `git visual` για να εκτελέσουμε την εντολή `gitk`: [source,console] ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 91bf18d8c..d33185253 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,64 +1,87 @@ -[[_getting_a_repo]] -=== Getting a Git Repository +[[r_getting_a_repo]] +=== Απόκτηση αποθετηρίου Git -You can get a Git project using two main approaches. -The first takes an existing project or directory and imports it into Git. -The second clones an existing Git repository from another server. +Μπορούμε να δημιουργήσουμε ένα έργο στο Git χρησιμοποιώντας δύο βασικές προσεγγίσεις. -==== Initializing a Repository in an Existing Directory +1. Να πάρουμε ένα έργο που έχουμε σε κάποιο υπάρχοντα κατάλογο που δεν βρίσκεται υπό έλεγχο εκδόσεων και να τον μετατρέψουμε σε ένα αποθετήριο Git +2. Να _κλωνοποιήσουμε_ (clone) ένα υπάρχον αποθετήριο Git από κάπου αλλού. -If you're starting to track an existing project in Git, you need to go to the project's directory and type +Σε κάθε περίπτωση, θα αποκτήσουμε ένα αποθετήριο Git τοπικά στον υπολογιστή μας. + +==== Αρχικοποίηση αποθετηρίου σε έναν υπάρχοντα κατάλογο + +Αν έχουμε ένα έργο σε έναν κατάλογο που δεν βρίσκεται υπό έλεγχο εκδόσεων και θέλουμε να ξεκινήσουμε να τον ελέγχουμε με το Git, πρώτα πρέπει να πάμε σε αυτό τον κατάλογο. +Αυτό γίνεται με διαφορετικό τρόπο ανάλογα με το σύστημά μας. + +Σε Linux +[source,console] +---- +$ cd /home/user/my_project +---- +Σε macOS: +[source,console] +---- +$ cd /Users/user/my_project +---- +Σε Windows: +[source,console] +---- +$ cd C:/Users/user/my_project +---- + +και πληκτρολογούμε: [source,console] ---- $ git init ---- -This creates a new subdirectory named `.git` that contains all of your necessary repository files – a Git repository skeleton. -At this point, nothing in your project is tracked yet. -(See <<_git_internals>> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) +Η εντολή αυτή δημιουργεί έναν νέο υποκατάλογο με το όνομα `.git` ο οποίος περιέχει όλα τα απαραίτητα αρχεία για το αποθετήριο -- ένα σκελετό για το αποθετήριό μας. +Στο σημείο αυτό, τίποτα δεν παρακολουθείται ακόμα από το έργο μας. +Βλ. <> για περισσότερες πληροφορίες σχετικά με το τι ακριβώς αρχεία περιέχονται στον κατάλογο `.git`, που μόλις δημιουργήσαμε.(((εντολές git, init))) -If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. -You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`: +Αν θέλουμε να ξεκινήσουμε τον έλεγχο έκδοσης στα υπάρχοντα αρχεία (εν εντιθέσει με ένα κενό κατάλογο), θα πρέπει να ξεκινήσουμε την παρακολούθηση αυτών των αρχείων και να κάνουμε την πρώτη υποβολή (commit). +Για να το πετύχουμε αυτό θα χρειαστούμε μερικές εντολές `git add` οι οποίες προσδιορίζουν τα αρχεία που θέλουμε να παρακολουθούμε και μια εντολή `git commit`: [source,console] ---- $ git add *.c $ git add LICENSE -$ git commit -m 'initial project version' +$ git commit -m 'Initial project version' ---- -We'll go over what these commands do in just a minute. -At this point, you have a Git repository with tracked files and an initial commit. +Θα εξετάσουμε σε λίγο τι κάνουν οι παραπάνω εντολές. +Στο σημείο αυτό, έχουμε ένα αποθετήριο Git με κάποια παρακολουθούμενα αρχεία και μια αρχική υποβολή. -[[_git_cloning]] -==== Cloning an Existing Repository +[[r_git_cloning]] +==== Κλωνοποίηση υπάρχοντος αποθετηρίου -If you want to get a copy of an existing Git repository – for example, a project you'd like to contribute to – the command you need is `git clone`. -If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". -This is an important distinction – instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. -Every version of every file for the history of the project is pulled down by default when you run `git clone`. -In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there – see <<_git_on_the_server>> for more details). +Αν θέλουμε να αποκτήσουμε ένα αντίγραφο ενός υπάρχοντος αποθετηρίου Git -- για παράδειγμα, ένα έργο στο οποίο θα θέλουμε να συνεισφέρουμε -- η εντολή που χρειαζόμαστε είναι `git clone`. +Αν είμαστε εξεικοιωμένοι με άλλα συστήματα ελέγχου έκδοσης όπως το Subversion, θα παρατηρήσουμε ότι η εντολή είναι "clone" και όχι "checkout". +Αυτή είναι μια σημαντική διάκριση -- το Git δεν παίρνει απλά ένα αντίγραφο της τρέχουσας κατάστασης του αποθετηρίου, αλλά ένα πλήρες αντίγραφο σχεδόν όλων των δεδομένων που βρίσκονται στον διακομιστή. +Με την εντολή `git clone` όλες οι εκδόσεις κάθε αρχείου του έργου αποθηκεύονται τοπικά. +Μάλιστα, αν ο δίσκος του διακομιστή μας αλλοιωθεί, μπορούμε να χρησιμοποιήσουμε οποιονδήποτε από τους κλώνους του ώστε να θέσουμε τον διακομιστή στην κατάσταση που ήταν όταν κλωνοποιήθηκε (μπορεί να χαθεί κάποιο άγκιστρο (hook) από την μεριά του διακομιστή, αλλά τα δεδομένα με έκδοση θα είναι εκεί -- βλ. <> για περισσότερες πληροφορίες). -You clone a repository with `git clone [url]`.(((git commands, clone))) -For example, if you want to clone the Git linkable library called libgit2, you can do so like this: +Για να κλωνοποιήσουμε ένα αποθετήριο, εκτελούμε την εντολή `git clone `.(((εντολές git, clone))) +Για παράδειγμα, αν θέλουμε να κλωνοποιήσουμε τη βιβλιοθήκη libgit2 του Git, θα πρέπει να εκτελέσουμε: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -That creates a directory named ``libgit2'', initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. -If you go into the new `libgit2` directory, you'll see the project files in there, ready to be worked on or used. -If you want to clone the repository into a directory named something other than ``libgit2'', you can specify that as the next command-line option: +Η εντολή αυτή δημιουργεί έναν κατάλογο με το όνομα "`libgit2`", αρχικοποιεί έναν κατάλογο `.git` μέσα σε αυτό, κατεβάζει όλα τα δεδομένα αυτού του αποθετηρίου καθώς και ένα αντίγραφο από την τελευταία έκδοση. +Αν περιηγηθούμε στον καινούριο κατάλογο `libgit2`, θα δούμε τα αρχεία του έργου μέσα σε αυτό, έτοιμα προς χρήση ή επεξεργασία. + +Αν θέλουμε να κλωνοποιήσουμε το αποθετήριο σε έναν κατάλογο με διαφορετικό όνομα, μπορούμε να το ορίσουμε με την παρακάτω εναλλακτική της εντολής: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 mylibgit ---- -That command does the same thing as the previous one, but the target directory is called `mylibgit`. +Η εντολή αυτή έχει το ίδιο αποτέλεσμα με την προηγούμενη, με τη διαφορά ότι ο κατάλογος που θα δημιουργηθεί θα ονομάζεται `mylibgit`. -Git has a number of different transfer protocols you can use. -The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. -<<_git_on_the_server>> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +Το Git συνεργάζεται με διάφορα πρωτόκολλα μεταφοράς που μπορούμε να χρησιμοποιήσουμε. +Το προηγούμενο παράδειγμα χρησιμοποεί το πρωτόκολλο `https://`, ενδέχεται επίσης να δούμε το `git://` ή το `user@server:path/to/repo.git` το οποίο χρησιμοποιεί το πρωτόκολλο μεταφοράς SSH. +Το κεφάλαιο <> παρουσιάζει όλες τις διαθέσιμες εναλλακτικές που με τις οποίες μπορεί ένας διακομιστής να μας δώσει πρόσβαση σε ένα αποθετήριο Git, καθώς και τα πλεονεκτήματα και μειονεκτήματα της κάθε εναλλακτικής. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index d4bf2ec37..ad0bfaf15 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,46 +1,59 @@ -=== Recording Changes to the Repository +=== Καταγραφή αλλαγών στο αποθετήριο -You have a bona fide Git repository and a checkout or working copy of the files for that project. -You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +Σε αυτό το σημείο, θα πρέπει να έχουμε ένα αξιόπιστο αποθετήριο Git στο τοπικό μηχάνημά μας και μια ενημερωμένη έκδοση των αρχείων του έργου μπροστά μας. +Συνήθως, η διαδικασία που ακολουθεί είναι να κάνουμε μερικές αλλαγές στο έργο και να υποβάλλουμε στιγμιότυπα (snapshots) αυτών των αλλαγών στο αποθετήριό μας όποτε το έργο φτάνει σε μια κατάσταση που θέλουμε να καταγράψουμε. -Remember that each file in your working directory can be in one of two states: tracked or untracked. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything. +Θυμόμαστε ότι κάθε αρχείο στον κατάλογο που εργαζόμαστε μπορεί να βρίσκεται σε δύο καταστάσεις: _παρακολουθούμενο_ (tracked) ή _μη-παρακολουθούμενο_. +Τα παρακολουθούμενα αρχεία είναι αυτά που βρίσκονταν στο τελευταίο στιγμιότυπο καθώς και αρχεία που μόλις έχουν τοποθετηθεί στο στάδιο καταχώρησης· μπορεί να είναι μη τροποποιημένα, τροποποιημένα ή στο στάδιο καταχώρησης (staged). +Εν συντομία, τα παρακολουθούμενα αρχεία είναι τα αρχεία που το Git γνωρίζει για αυτά. -As you edit files, Git sees them as modified, because you've changed them since your last commit. -You stage these modified files and then commit all your staged changes, and the cycle repeats. +Τα μη-παρακολουθούμενα αρχεία είναι όλα τα υπόλοιπα -- τα αρχεία στον κατάλογο εργασίας που δεν βρίσκονταν στο τελευταίο στιγμιότυπο, και δεν βρίσκονται ούτε στο στάδιο καταχώρησης. +Όταν κλωνοποιούμε για πρώτη φορά ένα αποθετήριο, όλα τα αρχεία θα είναι παρακολουθούμενα και ατροποποίητα επειδή το Git μόλις τα έχει ενημερώσει (check out) και δεν τα έχουμε επεξεργαστεί ακόμα. -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] +Καθώς επεξεργαζόμαστε τα αρχεία, το Git θα τα αναγνωρίζει ως τροποποιημένα, αφού θα έχουν αλλάξει από την τελευταία μας υποβολή (commit). +Όσο εργαζόμαστε, τοποθετούμε επιλεκτικά κάποια τροποποιημένα αρχεία στο στάδιο καταχώρησης, στη συνέχεια υποβάλλουμε όλες τις αλλαγές των αρχείων και επαναλαμβάνουμε τη διαδικασία ξανά και ξανά. -[[_checking_status]] -==== Checking the Status of Your Files +.Ο κύκλος ζωής της κατάστασης των αρχείων μας +image::images/lifecycle.png[Ο κύκλος ζωής της κατάστασης των αρχείων μας] -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +[[r_checking_status]] +==== Έλεγχος της κατάστασης των αρχείων μας + +Το βασικό εργαλείο που χρησιμοποιoύμε για να προσδιορίσουμε την τρέχουσα κατάσταση των αρχείων είναι η εντολή `git status`.(((εντολές git, status))) +Αν την εκτελέσουμε αμέσως μόλις έχουμε κλωνοποιήσει ένα αποθετήριο, θα δούμε ένα μήνυμα παρόμοιο με το παρακάτω: [source,console] ---- $ git status On branch master -nothing to commit, working directory clean +Your branch is up-to-date with 'origin/master'. +nothing to commit, working tree clean ---- -This means you have a clean working directory – in other words, there are no tracked and modified files. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<<_git_branching>> will go over branches and references in detail. +Αυτό σημαίνει ότι έχουμε ένα καθαρό κατάλογο εργασίας· με άλλα λόγια, κανένα από τα παρακολουθούμενα αρχεία μας δεν έχουν τροποποιηθεί. +Επίσης το Git δεν βλέπει κανένα μη-παρακολουθούμενο αρχείο, αλλιώς θα τα παρέθετε στο παραπάνω μήνυμα. +Τέλος, η εντολή αυτή μας ενημερώνει σε ποιον κλάδο βρίσκομαστε καθώς και ότι δεν έχει αποκλίσει από τον αντίστοιχο κλάδο που βρίσκεται στον διακομιστή. +Προς το παρόν ο κλάδος αυτός είναι ο `master`, που είναι και ο προεπιλεγμένος· δεν θα μας απασχολήσει εδώ. +Η ενότητα <> θα εξετάσει πιο αναλυτικά τους κλάδους και τις αναφορές. -Let's say you add a new file to your project, a simple README file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: +[NOTE] +==== +Το GitHub άλλαξε το προεπιλεγμένο όνομα κλάδου από `master` σε `main` στα μέσα του 2020, κάτι που μιμήθηκαν και άλλοι διακομιστές Git. +Συνεπώς, ενδεχομένως θα δείτε ότι το προεπιλεμγένο όνομα κλάδου σε κάποια πιο καινούρια αποθετήρια είναι `main` και όχι `master`. +Επιπλέον, το προεπιλεγμένο όνομα βρόχου μπορεί να τροποποιηθεί (όπως είδαμε στην ενότητα <>), συνεπώς ίσως δέιτε κάποιο άλλο όνομα για τον προεπιλεγμένο κλάδο. + +Πάντως, το ίδιο το Git χρησιμοποιεί το όνομα `master` ως προεπιλεγμένο, συνεπώς αυτό θα χρησιμοποιήσουμε κι εμείς σε αυτό το βιβλίο. +==== + +Ας υποθέσουμε ότι έχουμε προσθέσει ένα νέο αρχείο στο έργο μας, ένα απλό αρχείο `README`. +Αν το αρχείο αυτό δεν προϋπήρχε και εκτελέσουμε την εντολή `git status`, θα δούμε το μη-παρακολουθούμενο αρχείο μας ως εξής: [source,console] ---- $ echo 'My Project' > README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add ..." to include in what will be committed) @@ -49,49 +62,51 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -You can see that your new README file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including README, so let's start tracking the file. +Βλέπουμε ότι το αρχείο `README` είναι μη-παρακολουθούμενο διότι βρίσκεται κάτω από τον τίτλο "`Untracked files`" στο πάνω μέρος του αποτελέσματος της εντολής. +Μη-παρακολουθούμενο ουσιαστικά σημαίνει ότι το Git βλέπει ένα αρχείο το οποίο δεν υπήρχε στο προηγούμενο στιγμιότυπο (υποβολή, commit) και που δεν έχει τοποθετηθεί ακόμα στο στάδιο καταχώρησης· το Git δεν θα συμπεριλάβει το αρχείο αυτό στα επόμενα στιγμιότυπα που θα υποβάλλουμε, αν δεν το ζητήσουμε ρητά. +Αυτό γίνεται ώστε να μην συμπεριλάβουμε κατά λάθος στο έργο μας αρχεία τα οποία δεν θέλουμε να συμπεριλάβουμε, για παράδειγμα εκτελέσιμα αρχεία. +Σε αυτή την περίπτωση, θέλουμε να συμπεριλάβουμε το αρχείο `README` στο έργο μας, οπότε ας ξεκινήσουμε να παρακολουθούμε το αρχείο. -[[_tracking_files]] -==== Tracking New Files +[[r_tracking_files]] +==== Παρακολούθηση νέων αρχείων -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the README file, you can run this: +Για να αρχίσουμε να παρακολουθούμε ένα καινούριο αρχείο, χρησιμοποιoύμε την εντολή `git add`.(((εντολές git, add))) +Για να αρχίσουμε να παρακολουθούμε το αρχείο `READΜE`, εκτελούμε: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your README file is now tracked and staged to be committed: +Αν τώρα εκτελέσουμε την εντολή `git status` για να δούμε την τρέχουσα κατάσταση, θα δούμε ότι το αρχείο `README` πλέον παρακολουθείται και έχει τοποθετηθεί στο στάδιο καταχώρησης ώστε να είναι έτοιμο να υποβληθεί: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: - (use "git reset HEAD ..." to unstage) + (use "git restore --staged ..." to unstage) new file: README ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add (files)` – that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +Καταλαβαίνουμε ότι το αρχείο αυτό πλέον έχει τοποθετηθεί στο στάδιο καταχώρησης διότι βρίσκεται κάτω από τον τίτλο "`Changes to be committed`". +Αν σε αυτό το σημείο υποβάλλουμε τα αρχεία μας, η έκδοση του αρχείου `README` που θα αποθηκευτεί στο στιγμιότυπο θα είναι αυτή που υπήρχε όταν εκτελέσαμε την εντολή `git add`. +Ίσως θυμόμαστε ότι όταν εκτελέσαμε την εντολή `git init` ακολουθούμενη από `git add ` -- αυτό το κάναμε για να αρχίσουμε να παρακολουθούμε τα αρχεία του καταλόγου.(((εντολές git, init)))(((εντολές git, add))) +Η εντολή `git add` μπορεί να ακολουθείται είτε από ένα αρχείο είτε από έναν κατάλογο· αν ακολουθείται από κατάλογο τότε η εντολή θα καταχωρήσει όλα τα αρχεία του συγκεκριμένου καταλόγου. -==== Staging Modified Files +==== Καταχώριση τροποποιημένων αρχείων στο στάδιο καταχώρησης -Let's change a file that was already tracked. -If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this: +Ας αλλάξουμε ένα αρχείο που βρίσκεται ήδη υπό παρακολούθηση. +Αν αλλάξουμε το ήδη παρακολουθούμενο αρχείο "`CONTRIBUTING.md`" και εκτελέσουμε την εντολή `git status` ξανά, θα δούμε κάτι σαν το εξής: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -105,17 +120,18 @@ Changes not staged for commit: ---- -The ``CONTRIBUTING.md'' file appears under a section named ``Changed but not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. -`git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. -It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again: +Το αρχείο "`CONTRIBUTING.md`" βρίσκεται κάτω από την κατηγορία "`Changes not staged for commit`" -- που σημαίνει ότι ένα αρχείο υπό παρακολούθηση έχει τροποποιηθεί στον κατάλογο εργασίας, αλλά δεν έχει τοποθετηθεί ακόμα στο στάδιο καταχώρησης. +Για να το τοποθετήσουμε στο στάδιο καταχώρησης θα πρέπει να εκτελέσουμε την εντολή `git add`. +Η εντολή `git add` έχει πολλές λειτουργίες· τη χρησιμοποιoύμε για να ξεκινήσουμε την παρακολούθηση καινούργιων αρχείων, για να τοποθετήσουμε αρχεία στο στάδιο καταχώρησης αλλά και για άλλες λειτουργίες όπως το να επισημάνουμε αρχεία που προέρχονται από συγκρούσεις συγχώνευσης (merge conflicts) ως επιλυμένα. +Μπορούμε να σκεφτούμε την εντολή ως "`πρόσθεσε αυτό το περιεχόμενο στην επόμενη υποβολή`" αντί για "`πρόσθεσε αυτό το αρχείο στο έργο`".(((εντολές git, add))) +Ας εκτελέσουμε την εντολή `git add`, ώστε να καταχωρήσουμε το αρχείο "`CONTRIBUTING.md`" και έπειτα ας τρέξουμε την εντολή `git status` ξανά: [source,console] ---- $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -124,16 +140,17 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +Και τα δύο αρχεία πλέον βρίσκονται στο στάδιο καταχώρησης και θα συμπεριληφθούν στην επόμενη υποβολή μας. +Ας υποθέσουμε τώρα ότι θυμηθήκαμε άλλη μία μικρή αλλαγή που θέλουμε να κάνουμε στο αρχείο `CONTRIBUTING.md` πριν το υποβάλλουμε. +Το ανοίγουμε ξανά, κάνουμε την αλλαγή που θέλουμε και είμαστε έτοιμοι για την υποβολή. +Παρόλα αυτά ας εκτελέσουμε `git status` για άλλη μια φορά: [source,console] ---- $ vim CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -148,18 +165,19 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +Τι στην ευχή συμβαίνει; +Το αρχείο `CONTRIBUTING.md` εμφανίζεται και ως αρχείο τοποθετημένο στο στάδιο καταχώρησης, _αλλά και_ ως αρχείο που δεν έχει τοποθετηθεί στο στάδιο καταχώρησης. +Πώς είναι αυτό δυνατόν; +Αυτό που συμβαίνει είναι ότι το Git τοποθετεί στο στάδιο καταχώρησης ένα αρχείο ακριβώς όπως είναι τη στιγμή που εκτελούμε την εντολή `git add`. +Αν υποβάλλουμε το στιγμιότυπο τώρα, η έκδοση του αρχείου `CONTRIBUTING.md` που θα συμπεριληφθεί στην υποβολή είναι αυτή που υπήρχε όταν εκτελέσαμε την εντολή `git add` (και όχι η τωρινή έκδοση του αρχείου). +Γενικά, αν τροποποιήσουμε ένα αρχείο αφότου έχουμε εκτελέσει την εντολή `git add`, θα πρέπει να εκτελέσουμε `git add` ξανά, αν θέλουμε να τοποθετήσουμε την τελευταία εκδοχή του αρχείου στο στάδιο καταχώρησης: [source,console] ---- $ git add CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -167,11 +185,11 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== Σύντομο Status -While the `git status` output is pretty comprehensive, it's also quite wordy. -Git also has a short status flag so you can see your changes in a more compact way. -If you run `git status -s` or `git status --short` you get a far more simplified output from the command. +Αν και το αποτέλεσμα της εντολής `git status` είναι αρκετά περιεκτικό, οι πληροφορίες αυτές είναι λίγο φλύαρες. +Το Git διαθέτει μια σημαία για πιο συνοπτική περιγραφή της κατάστασης των αλλαγών. +Αν εκτελέσουμε `git status -s` ή `git status --short` θα έχουμε ένα πιο απλοποιημένο αποτέλεσμα. [source,console] ---- @@ -183,18 +201,18 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. -There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified. -So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. -The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +Τα καινούργια αρχεία που δεν παρακολουθούνται ακόμα ακολουθούνται με ένα `??`, τα καινούρια αρχεία που έχουν καταχωρηθεί με `A`, τα τροποποιημένα αρχεία με `M` κ.ο.κ. +Υπάρχουν δύο στήλες στην έξοδο· η αριστερή στήλη περιγράφει την κατάσταση του σταδίου καταχώρησης και η δεξιά στήλη την κατάσταση του δένδρου εργασίας. +Έτσι, για παράδειγμα, στην προήγουμενη έξοδο το αρχείο `README` έχει τροποποιηθεί στον κατάλογο εργασίας, αλλά δεν έχει ακόμα τοποθετηθεί στο στάδιο καταχώρησης, ενώ το αρχείο `lib/simplegit.rb` είναι και τροποποιημένο και έχει τοποθετηθεί στο στάδιο καταχώρησης. +Το αρχείο `Rakefile` έχει τροποποιηθεί, τοποθετηθεί στο στάδιο καταχώρησης και στη συνέχεια τροποποιήθηκε ξανά, που σημαίνει ότι υπάρχουν κάποιες αλλαγές που έχουν τοποθετηθεί στο στάδιο καταχώρησης και άλλες που δεν έχουν τοποθετηθεί στο στάδιο καταχώρησης. -[[_ignoring]] -==== Ignoring Files +[[r_ignoring]] +==== Αγνόηση αρχεία -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +Συμβαίνει συχνά, να υπάρχει μια κατηγορία αρχείων που δεν θέλουμε να προσθέτει αυτόματα το Git, ούτε καν να φαίνονται ως μη-παρακολουθούμενα. +Αυτά είναι συνήθως αρχεία που δημιουργούνται αυτόματα όπως αρχεία .log ή αρχεία που δημιουργούνται κατά τη μεταγλώττιση. +Σε αυτές τις περιπτώσεις μπορούμε να δημιουργήσουμε ένα αρχείο με όνομα `.gitignore`, στο οποίο να καταγράψουμε τα μοτίβα των ονομάτων αυτών των αρχείων.(((αγνόηση αρχείων))) +Να ένα παράδειγμα αρχείου `.gitignore`: [source,console] ---- @@ -203,70 +221,81 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code. -The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +Η πρώτη γραμμή λέει στο Git να αγνοεί όλα τα αρχεία που τελειώνουν σε "`.o`" ή "`.a`" -- αρχεία που είναι συνήθως αποτέλεσμα της μεταγλώττισης τους κώδικά μας. +Η δεύτερη γραμμή λέει στο Git να αγνοεί όλα τα αρχεία που τελειώνουν με τον χαρακτήρα (`~`), το οποίο χρησιμοποιείται από πολλούς επεξεργαστές κειμένου, όπως τον Emacs, για να δηλώσει τα προσωρινά αρχεία. +Μπορούμε επίσης να συμπεριλάβουμε καταλόγους που περιλαμβάνουν αρχεία καταγραφής· προσωρινούς καταλόγους· αυτόματες δημιουργίες τεκμηρίωσεων· κ.ο.κ. +Γενικά είναι καλή ιδέα να ρυθμίσουμε το αρχείο `.gitignore` νωρίς ώστε να μην υποβάλλουμε κατά λάθος αρχεία που δεν θέλουμε να βρίσκονται στο αποθετήριό μας. -The rules for the patterns you can put in the `.gitignore` file are as follows: +Οι κανόνες για τα μοτίβα που μπορούμε να δηλώσουμε στο αρχείο `.gitignore` είναι οι εξής: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work. -* You can start patterns with a forward slash (`/`) to avoid recursivity. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* Οι κενές γραμμές ή οι γραμμές που ξεκινούν με `#` αγνοούνται. +* Μπορούμε να χρησιμοποιήσουμε τα κλασικά μοτίβα για ονόματα αρχείων (glob patterns) που εφαρμόζονται αναδρομικά. +* Μπορούμε να ξεκινήσουμε τα μοτίβα μας με slash (`/`) ώστε να αποφύγουμε την αναδρομικότητα +* Μπορούμε να τελειώσουμε τα μοτίβα μας με slash (`/`) ώστε να ορίσουμε έναν κατάλογο. +* Μπορούμε να αντιστρέψουμε ένα μοτίβο χρησιμοποιώντας ένα θαυμαστικό (`!`) στην αρχή του. -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +Τα μοτίβα αυτά μοιάζουν με απλοποιημένες κανονικές εκφράσεις (regular expressions) που χρησιμοποιούν τα κέλυφοι (shells). +Ένας αστερίσκος (`\*`) αντιστοιχεί σε μηδέν ή περισσότερους χαρακτήρες· το `[abc]` αντιστοιχεί σε οποιονδήποτε χαρακτήρα βρίσκεται μέσα στις αγκύλες (σε αυτή την περίπτωση `a`, `b` και `c`)· το σύμβολο του αγγλικού ερωτηματικού (`?`) αντιστοιχεί σε έναν και μόνο χαρακτήρα· και οι αγκύλες που περιέχουν χαρακτήρες που διαχωρίζονται με παύλα (`[0-9]`) αντιστοιχίζονται σε όλους τους χαρακτήρες που υπάρχουν μεταξύ τους (σε αυτή την περίπτωση, όλους τους αριθμούς από το 0 μέχρι το 9). +Μπορούμε επίσης να χρησιμοποιήσουμε δύο αστερίσκους για να αντιστοιχίσουμε εμφωλευμένους καταλόγους· η έκφραση `a/**/z` αντιστοιχεί στους καταλόγους `a/z`, `a/b/z`, `a/b/c/z` κ.ο.κ. -Here is another example .gitignore file: +Ορίστε άλλο ένα παράδειγμα ενός αρχείου `.gitignore`: [source] ---- -# no .a files +# αγνόησε όλα τα αρχεία .a *.a -# but do track lib.a, even though you're ignoring .a files above +# αλλά να παρακολουθείς το lib.a, παρά το ότι αγνοείς τα αρχεία .a !lib.a -# only ignore the TODO file in the current directory, not subdir/TODO +# αγνόησε μόνο το αρχείο TODO στον τρέχοντα κατάλογο, όχι το subdir/TODO /TODO -# ignore all files in the build/ directory +# αγνόησε όλα τα αρχεία σε οποιονδήποτε κατάλογο με όνομα build build/ -# ignore doc/notes.txt, but not doc/server/arch.txt +# αγνόησε το doc/notes.txt, αλλά όχι το doc/server/arch.txt doc/*.txt -# ignore all .pdf files in the doc/ directory +# αγνόησε όλα τα αρχεία .pdf στον φάκελο doc/ και όλους τους υποφακέλους του doc/**/*.pdf ---- [TIP] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +Αν θέλετε κάποια παραδείγματα για να ξεκινήσετε, το GitHub διατηρεί μια λίστα με παραδείγματαα αρχείων `.gitignore` για πολλές γλώσσες προγραμματισμού στη διεύθυνση https://github.com/github/gitignore[^]. ==== -[[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +[NOTE] +==== +Στην απλούστερη περίπτωση, ένα αποθετήριο έχει μόνο ένα αρχείο `.gitignore` στον κατάλογο root, το οποίο εφαρμόζεται αναδρομικά σε όλο το αποθετήριο. +Όμως είναι δυνατό να έχετε επιπρόσθετα αρχεία `.gitignore` σε υποφακέλους. +Οι κανόνες σε αυτά τα εμφωλευμένα αρχεία `.gitignore` εφαρμόζονται μόνο σε αρχεία του φακέλου στον οποίο βρίσκονται. +Το αποθετήριο με τον πηγαίο κώδικα του πυρήνα του Linux έχει 206 αρχεία `.gitignore`. + +Περισσότερες λεπτομέρειες σχετικά με πολλαπλά αρχεία `.gitignore` είναι πέρα από τους σκοπούς αυτού του βιβλίου· βλ. `man gitignore` για περισσότερες λεπτομέρειες. +==== -If the `git status` command is too vague for you – you want to know exactly what you changed, not just which files were changed – you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed – the patch, as it were. +[[r_git_diff_staged]] +==== Προβολή των καταχωρημένων και μη-καταχωρημένων αλλαγών -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +Αν η εντολή `git status` είναι πολύ αόριστη για μας και θέλουμε να δούμε ακριβώς τι έχουμε αλλάξει (και όχι μόνο ποια αρχεία έχουν αλλάξει), μπορούμε να χρησιμοποιήσουμε την εντολή `git diff`.(((εντολές git, diff))) +Θα καλύψουμε την εντολή αυτή πιο αναλυτικά αργότερα, αλλά το πιθανότερο είναι ότι θα τη χρησιμοποιoύμε πιο συχνά για να απαντήσουμε σε αυτές τις δύο ερωτήσεις: Τι έχουμε αλλάξει και δεν έχουμε ακόμα τοποθετήσει στο στάδιο καταχώρησης; +Και τι έχουμε τοποθετήσει στο στάδιο καταχώρησης και είναι έτοιμο να υποβληθεί; +Ενώ η εντολή `git status` απαντά σε αυτές τις ερωτήσεις πολύ γενικά, απαριθμώντας τα ονόματα των αρχείων, η εντολή `git diff` θα μας δείξει ακριβώς ποιες γραμμές προστέθηκαν ή αφαιρέθηκαν -- με άλλα λόγια το επίθεμα (patch) όπως ήταν. + +Έστω λοιπόν ότι έχουμε επεξεργαστεί και τοποθετήσει στο στάδιο καταχώρησης το αρχείο `README` ξανά και μετά επεξεργαζόμαστε το αρχείο `CONTRIBUTING.md` χωρίς να το τοποθετήσουμε στο στάδιο καταχώρησης. +Αν τώρα εκτελέσουμε την εντολή `git status`, θα δούμε κάτι τέτοιο: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) - new file: README + modified: README Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -275,7 +304,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -To see what you've changed but not yet staged, type `git diff` with no other arguments: +Για να δούμε τι έχουμε αλλάξει, αλλά δεν έχουμε ακόμα τοποθετήσει στο στάδιο καταχώρησης, πληκτρολογούμε `git diff` χωρίς άλλα ορίσματα: [source,console] ---- @@ -296,11 +325,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +Η εντολή αυτή συγκρίνει τον κατάλογο εργασίας μας με ό,τι υπάρχει στο στάδιο καταχώρησης. +Μας λέει τις αλλαγές που έχουμε κάνει, αλλά δεν έχουμε ακόμα τοποθετήσει στο στάδιο καταχώρησης. -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +Αν θέλουμε να δούμε τι έχουμε τοποθετήσει στο στάδιο καταχώρησης, που θα είναι και μέρος της επόμενης υποβολής, μπορούμε να χρησιμοποιήσουμε την εντολή `git diff --staged`. +Η εντολή αυτή συγκρίνει τις αλλαγές που βρίσκονται στο στάδιο καταχώρησης με την τελευταία υποβολή: [source,console] ---- @@ -314,11 +343,11 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit – only changes that are still unstaged. -This can be confusing, because if you've staged all of your changes, `git diff` will give you no output. +Είναι σημαντικό να θυμόμαστε ότι η εντολή `git diff` από μόνη της δεν μας εμφανίζει όλες τις αλλαγές που έγιναν σε σχέση με την τελευταία υποβολή, αλλά μόνο τις αλλαγές που δεν έχουν ακόμα τοποθετηθεί στο στάδιο καταχώρησης. +Αν έχουμε τοποθετήσει όλες τις αλλαγές μας στο στάδιο καταχώρησης, η εντολή `git diff` δεν θα επιστρέψει τίποτα. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. -If our environment looks like this: +Ας δούμε άλλο ένα παράδειγμα, έστω ότι έχουμε τοποθετήσει το αρχείο `CONTRIBUTING.md` στο στάδιο καταχώρησης και έπειτα το έχουμε τροποποιήσει, μπορούμε να χρησιμοποιήσουμε την εντολή `git diff` για να δούμε ποιες ακριβώς αλλαγές του αρχείου έχουν τοποθετηθεί στο στάδιο καταχώρησης και ποιες όχι. +Αν το περιβάλλον εργασίας μας είναι κάπως έτσι: [source,console] ---- @@ -326,6 +355,7 @@ $ git add CONTRIBUTING.md $ echo '# test line' >> CONTRIBUTING.md $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) @@ -338,7 +368,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged +Τότε μπορούμε να χρησιμοποιήσουμε την εντολή `git diff` για να δούμε τι δεν έχει τοποθετηθεί ακόμα στο στάδιο καταχώρησης [source,console] ---- @@ -354,7 +384,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (--staged and --cached are synonyms): +καθώς και την εντολή `git diff --cached` για να δούμε τι έχουμε τοποθετήσει στο στάδιο καταχώρησης μέχρι στιγμής (τα `--staged` και `--cached` είναι συνώνυμα): [source,console] ---- @@ -376,32 +406,36 @@ index 8ebb991..643e24f 100644 ---- [NOTE] -.Git Diff in an External Tool +.Χρήση της `git diff` από Εξωτερικό εργαλείο ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. -There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. -If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like Araxis, emerge, vimdiff and more. -Run `git difftool --tool-help` to see what is available on your system. +Θα συνεχίσουμε να χρησιμοποιούμε την εντολή `git diff` με διάφορους τρόπους στο βιβλίο. +Αν όμως θέλουμε να βλέπουμε τις διαφορές μεταξύ των αρχείων με κάποιο γραφικό εργαλείο (και όχι μέσα από τη γραμμή εντολών), υπάρχει και άλλος τρόπος. +Αν εκτελέσετε την εντολή `git difftool` αντί για `git diff` μπορείτε να δείτε τις διαφορές των αρχείων με προγράμματα όπως τα emerge, vimdiff και άλλα (συμπεριλαμβανομένων και εμπορικών λογισμικών). +Εκτελείτε την εντολή `git difftool --tool-help` για να δείτε ποια προγράμματα είναι διαθέσιμα στο σύστημά σας. ==== -[[_committing_changes]] -==== Committing Your Changes +[[r_committing_changes]] +==== Υποβολή των αλλαγών -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged – any files you have created or modified that you haven't run `git add` on since you edited them – won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) +Τώρα που ο προθάλαμός μας περιέχει τις αλλαγές που θέλουμε, είμαστε έτοιμοι να τις υποβάλλουμε (commit). +Θυμόμαστε ότι όλα τα μη καταχωρημένα αρχεία, δηλαδή όσα αρχεία έχουμε δημιουργήσει ή τροποποιήσει και για τα οποία δεν εκτελέσαμε την εντολή `git add`, δεν θα συμπεριληφθούν σε αυτή την υποβολή. +Θα παραμείνουν ως τροποποιημένα αρχεία στον δίσκο μας. +Σε αυτή την περίπτωση, έστω ότι την τελευταία φορά που εκτελέσαμε την εντολή `git status`, είδαμε ότι τα πάντα είχαν τοποθετηθεί στο στάδιο καταχώρησης και συνεπώς είμαστε έτοιμοι να υποβάλλουμε τις αλλαγές μας.(((εντολές git, status))) +Ο απλούστερος τρόπος για να υποβάλλουμε αλλαγές είναι να πληκτρολογήσουμε `git commit`:(((εντολές git, commit))) [source,console] ---- $ git commit ---- -Doing so launches your editor of choice. -(This is set by your shell's `$EDITOR` environment variable – usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <<_getting_started>>).(((editor, changing default)))(((git commands, config))) +Όταν το κάνουμε, θα ξεκινήσει ο προεπιλεγμένος επεξεργαστής κειμένου μας. -The editor displays the following text (this example is a Vim screen): +[NOTE] +==== +Αυτός είναι καθορισμένος από τη μεταβλητή περιβάλλοντος (environment variable) της γραμμής εντολών, `$EDITOR` -- συνήθως vim ή emacs, αλλά μπορείτε να χρησιμοποιήσετε την εντολή `git config --global core.editor` ώστε να χρησιμοποιήσετε τον επεξεργαστή κειμένου της αρεσκείας σας, όπως είδαμε στο <>.(((επεξεργαστής κειμένου, αλλαγή προεπιλεγμένου)))(((εντολές git, config))) +==== + +Ο επεξεργαστής κειμένου μας θα εμφανίσει το παρακάτω κείμενο (αυτό το παράδειγμα είναι οθόνη του Vim): [source] ---- @@ -409,6 +443,8 @@ The editor displays the following text (this example is a Vim screen): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master +# Your branch is up-to-date with 'origin/master'. +# # Changes to be committed: # new file: README # modified: CONTRIBUTING.md @@ -419,40 +455,46 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +Βλέπουμε ότι το προεπιλεγμένο μήνυμα υποβολής περιέχει το τελευταίο αποτέλεσμα της εντολής `git status` μέσα σε σχόλια και μια κενή γραμμή στην αρχή. +Μπορούμε να αφαιρέσουμε τα σχόλια αυτά και να γράψουμε το δικό μας μήνυμα υποβολής ή να τα αφήσουμρ ως έχουν ώστε να μας βοηθήσουν αργότερα να θυμηθούμε ποια αρχεία υποβάλλουμε. -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +[NOTE] +==== +Για να έχετε μια ακόμα πιο ρητή υπενθύμιση των αλλαγών που έχετε κάνει, μπορείτε να χρησιμοποιήσετε την επιλογή `-v` στην εντολή `git commit`. +Με τον τρόπο αυτό, θα εισάγετε τις αλλαγές σας στον επεξεργαστή κειμένου ώστε να δείτε ακριβώς ποιες αλλαγές θα υποβάλλετε. +==== + +Αφού κλείσουμε τον επεξεργαστή κειμένου, το Git θα δημιουργήσει την υποβολή μας με το παραπάνω μήνυμα (τα σχόλια θα αφαιρεθούν). + +Εναλλακτικά, μπορούμε να γράψουμε το μήνυμα υποβολής μας μαζί με την εντολή `commit`, μετά τη σημαία `-m` ως εξής: [source,console] ---- -$ git commit -m "Story 182: Fix benchmarks for speed" -[master 463dc4f] Story 182: Fix benchmarks for speed +$ git commit -m "Story 182: fix benchmarks for speed" +[master 463dc4f] Story 182: fix benchmarks for speed 2 files changed, 2 insertions(+) create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +Μόλις κάναμε την πρώτη μας υποβολή! +Βλέπουμε ότι η υποβολή αυτή μας έχει δώσει κάποιες πληροφορίες: τον κλάδο στον οποίο υποβάλλαμε τις αλλαγές μας (`master`), το άθροισμα ελέγχου SHA-1 (SHA-1 checksum) της υποβολής (`463dc4f`), πόσα αρχεία τροποποιήθηκαν, καθώς και στατιστικά για το πόσες γραμμές προστέθηκαν και αφαιρέθηκαν σε αυτή την υποβολή. -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +Θυμόμαστε ότι η υποβολή αλλαγών καταγράφει το στιγμιότυπο το οποίο είχαμε εκείνη τη στιγμή στο στάδιο καταχώρησης. +Οτιδήποτε δεν είχαμε τοποθετήσει στο στάδιο καταχώρησης, παραμένει εκεί τροποποιημένο και μπορούμε να το υποβάλλουμε αργότερα με άλλο ένα commit. +Κάθε φορά που πραγματοποιούμε μια υποβολή, καταγράφουμε ένα στιγμιότυπο του έργου μας, στο οποίο μπορούμε να επανέλθουμε αργότερα ή να το συγκρίνουμε με κάποιο παλιότερο στιγμιότυπο του έργου μας. -==== Skipping the Staging Area +==== Παραλείποντας το στάδιο καταχώρησης -(((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +(((στάδιο καταχώρησης, παράκαμψη))) +Παρόλο που το στάδιο καταχώρησης είναι πολύ χρήσιμο για να κόβουμε και να ράβουμε τις υποβολές μας όπως ακριβώς θέλουμε, ενίοτε είναι πιο περίπλοκος από όσο χρειάζεται να είναι στην εργασία μας. +Αν θέλουμε να παραλείψουμε το στάδιο καταχώρηςη, το Git παρέχει μια απλή συντόμευση. +Αν προσθέσουμε την επιλογή `-a` στην εντολή `git commit` αναγκάζουμε το Git να τοποθετεί αυτόματα όλα τα αρχεία υπό παρακολούθηση πριν κάνει το commit, επιτρέποντάς μας έτσι να παραλείψουμε την εντολή `git add`: [source,console] ---- $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) @@ -460,21 +502,23 @@ Changes not staged for commit: modified: CONTRIBUTING.md no changes added to commit (use "git add" and/or "git commit -a") -$ git commit -a -m 'added new benchmarks' -[master 83e38c7] added new benchmarks +$ git commit -a -m 'Add new benchmarks' +[master 83e38c7] Add new benchmarks 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit. +Παρατηρούμε ότι στην περίπτωση αυτή, δεν έχουμε εκτελέσει την εντολή `git add` για το αρχείο `CONTRIBUTING.md` πριν υποβάλουμε το στιγμιότυπό μας. +Αυτό γίνεται επειδή η σημαία `-a` περιλαμβάνει όλα τα αρχεία που έχουν τροποποιηθεί. +Αυτό είναι βολικό, αλλά χρειάζεται προσοχή· μερικές φορές αυτή η σημαία μπορεί να συμπεριλάβει αλλαγές που δεν θέλουμε να υποβάλουμε. -[[_removing_files]] -==== Removing Files +[[r_removing_files]] +==== Διαγραφή αρχείων -(((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. +(((αρχεία, διαγραφή))) +Για να διαγράψουμε ένα αρχείο από το Git, θα πρέπει να το διαγράψουμε από τη λίστα των παρακολουθούμενων αρχείων (ή πιο σωστά, να το διαγράψουμε από το στάδιο καταχώρησης) και έπειτα να το υποβάλλουμε +Αυτό γίνεται με την εντολή `git rm`, η οποία επίσης θα διαγράψει το αρχείο από τον κατάλογο εργασίας μας, ώστε να μην εμφανίζεται ως μη-παρακολουθούμενο αρχείο. -If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output: +Αν απλά διαγράψουμε το αρχείο από τον κατάλογο εργασίας μας, θα εμφανίζεται κάτω από την κατηγορία "`Changed but not updated`" (_unstaged_, που ουσιαστικά σημαίνει ότι δεν έχει τοποθετηθεί στο στάδιο καταχώρησης) του αποτελέσματος της εντολής `git status`: [source,console] ---- @@ -491,7 +535,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +Αν στη συνέχεια εκτελέσουμε την εντολή `git rm`, τοποθετηθεί στο στάδιο καταχώρησης την διαγραφή του αρχείου: [source,console] ---- @@ -499,77 +543,79 @@ $ git rm PROJECTS.md rm 'PROJECTS.md' $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file and added it to the index already, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +Την επόμενη φορά που θα κάνουμε commit, το αρχείο θα έχει διαγραφεί και δεν θα βρίσκεται υπό παρακολούθηση. +Αν είχαμε τροποποιήσει το αρχείο ή το είχαμε ήδη τοποθετήσει στο στάδιο καταχώρησης, θα πρέπει να εξαναγκάσουμε τη διαγραφή του με την επιλογή `-f`. +Πρόκειται για μια λειτουργικότητα ασφαλείας του Git, προκειμένου να αποτρέψει αφαίρεση δεδομένων από σφάλμα που δεν έχουν ακόμα καταγραφεί σε κάποιο στιγμιότυπο και δεν μπορούν να ανακτηθούν από το Git. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +Κάτι άλλο που μπορεί να θέλουμε να κάνουμε, είναι να κρατήσουμε το αρχείο στον κατάλογο εργασίας μας, αλλά να το αφαιρέσουμε από το στάδιο καταχώρησης. +Με άλλα λόγια, ίσως θέλουμε να κρατήσουμε το αρχείο στον σκληρό μας δίσκο, αλλά να μην βρίσκεται πλέον υπό παρακολούθηση από το Git. +Αυτό είναι ιδιαίτερα χρήσιμο αν είχαμε ξεχάσει να προσθέσουμε κάτι στο αρχείο `.gitignore` και το τοποθετήσαμε στο στάδιο καταχώρησης κατά λάθος, όπως για παράδειγμα μεγάλα αρχεία `.log` ή αρχεία `.a` που προέκυψαν από μεταγλώττιση. +Για να το κάνουμε αυτό, χρησιμοποιoύμε την επιλογή `--cached`: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as +Μπορούμε να χρησιμοποιήσουμε την παραπάνω εντολή με αρχεία, καταλόγους και μοτίβα glob αρχείων. +Αυτό σημαίνει ότι μπορούμε να εκτελέσουμε εντολές όπως: [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +Παρατηρήστε το backslash (`\`) μπροστά από τον αστερίσκο, `*`. +Είναι απαραίτητο, επειδή το Git χρησιμοποιεί κι αυτό ανάπτυξη των ονομάτων των αρχείων (file name expansion), επιπρόσθετα με την ανάπτυξη των ονομάτων των αρχείων του κελύφους. +Η παραπάνω εντολή αφαιρεί όλα τα αρχεία που έχουν την κατάληξη `.log` στον κατάλογο `log/`. +Επίσης, θα μπορούσαμε να κάνουμε κάτι τέτοιο: [source,console] ---- $ git rm \*~ ---- -This command removes all files that end with `~`. +Η εντολή αυτή αφαιρεί όλα τα αρχεία που τελειώνουν με τον χαρακτήρα `~`. -[[_git_mv]] -==== Moving Files +[[r_git_mv]] +==== Μετακίνηση αρχείων -(((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact – we'll deal with detecting file movement a bit later. +(((αρχεία, μετακίνηση))) +Σε αντίθεση με άλλα συστήματα ελέγχου έκδοσης, το Git δεν παρακολουθεί τις μετακινήσεις αρχείων από μόνο του. +Αν μετονομάσουμε ένα αρχείο στο Git, δεν αποθηκεύεται καμιά μεταπληροφορία που να ενημερώνει το Git ότι μετονομάσαμε το αρχείο. +Παρόλα αυτά, το Git είναι αρκετά έξυπνο ώστε να καταλάβει κάτι τέτοιο -- θα ασχοληθούμε λίγο αργότερα με την ανίχνευση μετακίνησης αρχείων. -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like +Κατ' αυτή την έννοια, το γεγονός ότι το Git έχει εντολή `mv` μπορεί να δημιουργήσει σύγχυση. +Αν θέλουμε να μετονομάσουμε ένα αρχείο στο Git, μπορούμε να το κάνουμε κάπως έτσι: [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +το οποίο θα λειτουργήσει τέλεια. +Στην πραγματικότητα, αν εκτελέσουμε κάτι τέτοιο και έπειτα κοιτάξουμε το status του αποθετηρίου, θα δούμε ότι το Git το θεωρεί μετονομασμένο αρχείο: [source,console] ---- $ git mv README.md README $ git status On branch master +Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) renamed: README.md -> README ---- -However, this is equivalent to running something like this: +Παρόλα αυτά, είναι ισοδύναμο με το να εκτελέσουμε το εξής: [source,console] ---- @@ -578,6 +624,6 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `mv` is one command instead of three – it's a convenience function. -More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Το Git καταλαβαίνει ότι ουσιαστικά πρόκειται για μετονομασία, οπότε δεν έχει σημασία αν μετονομάσουμε ένα αρχείο με αυτό τον τρόπο ή με την εντολή `mv`. +Η μόνη πραγματική διαφορά είναι ότι η εντολή `mv` είναι μία εντολή αντί για τρεις -- άρα πιο βολική. +Και το πιο σημαντικό, μπορούμε να χρησιμοποιήσουμε όποιο εργαλείο θέλουμε για να μετονομάσουμε ένα αρχείο και να λύσουμε το πρόβλημα της προσθήκης/διαγραφής, `add`/`rm`, του αρχείου αργότερα, πριν την υποβολή. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index f9a027ef3..bbeeaf2e4 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,18 +1,26 @@ -[[_remote_repos]] -=== Working with Remotes - -To be able to collaborate on any Git project, you need to know how to manage your remote repositories. -Remote repositories are versions of your project that are hosted on the Internet or network somewhere. -You can have several of them, each of which generally is either read-only or read/write for you. -Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. -Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. -In this section, we'll cover some of these remote-management skills. - -==== Showing Your Remotes - -To see which remote servers you have configured, you can run the `git remote` command.(((git commands, remote))) -It lists the shortnames of each remote handle you've specified. -If you've cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from: +[[r_remote_repos]] +=== Δουλεύοντας με απομακρυσμένα αποθετήρια + +Για να μπορούμε να συνεργαζόμαστε σε έργα του Git, θα πρέπει να γνωρίζουμε πώς να διαχειριζόμαστε τα απομακρυσμένα αποθετήριά μας. +Τα απομακρυσμένα αποθετήρια (remote repositories) είναι εκδόσεις του έργου μας που βρίσκονται στο Διαδίκτυο ή σε κάποιο δίκτυο. +Μπορούμε να δημιουργήσουμε όσα θέλουμε και καθένα από αυτά είναι προσβάσιμα από μας είτε ως για ανάγνωση-μόνο είτε για ανάγνωση/εγγραφή. +Η συνεργασία με άλλους συμπεριλαμβάνει τη διαχείριση αυτών των απομακρυσμένων αποθετηρίων, ώθηση και ελκυσμό δεδομένων προς και από αυτά όποτε χρειάζεται να κοινοποιήσουμε τη δουλειά μας ή να ενημερωθούμε για τη δουλειά άλλων. +Η διαχείριση τέτοιων αποθετηρίων χρειάζεται ικανότητες όπως: πρόσθεση καινούριων απομακρυσμένων αποθετηρίων, διαγραφή αποθετηρίων που δεν έχουν πια κάποια χρησιμότητα, διαχείριση απομακρυσμένων κλάδων και ορισμό τους ως υπο-παρακολούθηση ή τερματισμό της παρακολούθησής τους και άλλα. +Σε αυτή την ενότητα, θα ασχοληθούμε με κάποιες από αυτές τις δεξιότητες. + +[NOTE] +.Τα απομακρυσμένα αποθετήρια μπορεί να βρίσκονται στον υπολογιστή μας. +==== +Είναι απολύτως δυνατό να εργάζεστε με ένα "`απομακρυσμένο`" αποθετήριο, που βρίσκεται στον ίδιο υπολογιστή στον οποίο βρίσκεστε και εσείς. +Η λέξη "`απομακρυσμένο`" δεν υπονοεί απαραίτητα ότι το αποθετήριο βρίσκεται κάπου αλλού στο δίκτυο ή στο Διαδίκτυο, αλλά μόνο ότι βρίσκεται κάπου αλλού. +Όταν εργάζεστε με ένα τέτοιο απομακρυσμένο αποθετήριο περιλαμβάνει επίσης τις συνήθεις λειτουργίες ώθησης (push), ελκυσμού (pull) και ανάκτησης (fetch), όπως με κάθε άλλο απομακρυσμένο αποθετήριο. +==== + +==== Εμφάνιση των απομακρυσμένων αποθετηρίων μας + +Για να δούμε τους απομακρυσμένους διακομιστές που έχουμε παραμετροποιήσει, εκτελούμε την εντολή `git remote`.(((εντολές git, remote))) +Η εντολή αυτή θα μας επιστρέψει μια λίστα με τα ονόματα των απομακρυσμένων που έχουμε ορίσει. +Αν έχουμε κλωνοποιήσει το αποθετήριό μας, θα πρέπει να βλέπουμε τουλάχιστον το `origin` -- που είναι το προεπιλεγμένο όνομα που δίνει το Git στον διακομιστή από τον οποίο μόλις κλωνοποιήσαμε: [source,console] ---- @@ -28,7 +36,7 @@ $ git remote origin ---- -You can also specify `-v`, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote: +Η επιλογή `-v`, η οποία θα μας δείξει τα σύντομα ονόματα των απομακρυσμένων αποθετηρίων μας, μαζί με τις διευθύνσεις URL που είναι συσχετισμένες με αυτά: [source,console] ---- @@ -37,8 +45,8 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -If you have more than one remote, the command lists them all. -For example, a repository with multiple remotes for working with several collaborators might look something like this. +Αν έχουμε περισσότερα από ένα απομακρυσμένα αποθετήρια, η εντολή αυτή θα τα παραθέσει όλα. +Για παράδειγμα, ένα αποθετήριο με πολλά απομακρυσμένα αποθετήρια, ώστε να συνεργάζονται πολλά άτομα, θα φαίνεται κάπως έτσι: [source,console] ---- @@ -56,15 +64,16 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -This means we can pull contributions from any of these users pretty easily. -We may additionally have permission to push to one or more of these, though we can't tell that here. +Αυτό σημαίνει ότι μπορούμε να τραβήξουμε τη συνεισφορά καθενός από αυτούς τους χρήστες πολύ εύκολα. +Επιπλέον ενδεχομένως μπορούμε να ωθήσουμε αλλαγές σε κάποιο ή κάποια από αυτά τα απομακρυσμένα αποθετήρια, αν και αυτό δεν το γνωρίζουμε ακόμα. -Notice that these remotes use a variety of protocols; we'll cover more about this in <<_git_on_the_server>>. +Παρατηρούμε ότι τα απομακρυσμένα αποθετήρια χρησιμοποιούν πολλά πρωτόκολλα· θα καλύψουμε αναλυτικά τα πρωτόκολλα αυτά στο <>. -==== Adding Remote Repositories +==== Προσθήκη απομακρυσμένων αποθετηρίων -We've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add [shortname] [url]`: +Έχουμε ήδη αναφέρει και έχουμε επιδείξει πώς η εντολή `git clone` _έμμεσα_ προσθέτει το απομακρυσμένο αποθετήριο `origin` στο αποθετήριό μας. +Ας δούμε πως μπορούμε να προσθέσουμε ένα νέο απομακρυσμένο αποθετήριο _άμεσα_.(((εντολές git, remote))) +Για να προσθέσουμε ένα νέο απομακρυσμένο αποθτεήριο Git με ένα σύντομο όνομα, το οποίο μπορούμε να θυμάστε εύκολα, εκτελούμε την εντολή `git remote add `: [source,console] ---- @@ -78,8 +87,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +Τώρα πλέον μπορούμε να χρησιμοποιούμε στη γραμμή εντολών τη συμβολοσειρά `pb` αντί για ολόκληρη τη διεύθυνση του αποθετηρίου. +Για παράδειγμα, αν θέλουμε να ανακτήσουμε (fetch) όλες τις πληροφορίες που έχει ο Paul στο αποθετήριό του, μπορούμε να εκτελέσουμε την εντολή `git fetch pb`: [source,console] ---- @@ -93,53 +102,65 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Paul's master branch is now accessible locally as `pb/master` – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <<_git_branching>>.) +Ο κλάδος `master` του Paul είναι πλέον προσβάσιμος τοπικά σε μας ως `pb/master` -- μπορούμε να τον συγχωνεύσουμε σε κάποιον δικό μας κλάδο, ή να φτιάξουμε (check out) έναν τοπικό κλάδο σε αυτό το σημείο, αν θέλουμε να το επιθεωρήσουμε. +Θα δούμε περισσότερα για τους κλάδους και πώς τους χρησιμοποιούμε στην ενότητα <>. -[[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes +[[r_fetching_and_pulling]] +==== Ανάκτηση δεδομένων από απομακρυσμένα αποθετήρια -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +Όπως μόλις είδαμε, για να πάρουμε δεδομένα από απομακρυσμένα έργα, μπορούμε να εκτελέσουμε:(((εντολές git, fetch))) [source,console] ---- -$ git fetch [remote-name] +$ git fetch ---- -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +Η εντολή αυτή θα πάει στο απομακρυσμένο έργο και θα τραβήξει όλα τα δεδομένα από αυτό το απομακρυσμένο έργο που δεν έχουμε ακόμα. +Αφού γίνει αυτό, θα έχουμε πρόσβαση σε όλους τους κλάδους αυτού του απομακρυσμένου έργου, τους οποίους και μπορούμε να συγχωνεύσουμε ή να τους επιθεωρήσουμε περαιτέρω. + +Όταν κλωνοποιήσουμε ένα αποθετήριο, το αποθετήριο αυτό αποθηκεύεται με το όνομα "`origin`". +Συνεπώς, η εντολή `git fetch origin` ανακτά όλες τις νέες αλλαγές που έχουν γίνει από τότε που κλωνοποιήσαμε το αποθετήριο ή από τότε που ανακτήσαμε δεδομένα από αυτό για τελευταία φορά. +Είναι σημαντικό να τονίσουμε ότι η εντολή `git fetch` απλά τραβά δεδομένα στο τοπικό μας αποθετήριο· δεν συγχωνεύει τα δεδομένα αυτά με διάφορες αλλαγές που μπορεί να έχουμε κάνει εμείς τοπικά. +Θα πρέπει να κάνουμε τη συγχώνευση χειροκίνητα όταν είστε έτοιμοι. -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. +Αν ο κλάδος που παρακολουθεί έναν απομακρυσμένα κλάδο (περισσότερες λεπτομέρειες για αυτό στην επόμενη ενότητα και την ενότητα <>), μπορούμε να χρησιμοποιήσουμε την εντολή `git pull` για να γίνει αυτόματη ανάκτηση και συγχώνευση του απομακρυσμένου κλάδου στο τρέχοντα δικό μας.(((εντολές git, pull))) +Αυτή η ροή εργασιών ενδεχομένως μας φαίνεται πιο εύκολη· επιπλέον, η εντολή `git clone` θέτει αυτόματα τον τοπικό μας κλάδο `master` να παρακολουθεί τον απομακρυσμένο κλάδου `master` (ή όπως ονομάζεται ο προεπιλεγμένος κλάδος) στον διακομιστή από τον οποίο κλωνοποιήσαμε. +Η εκτέλεση της εντολής `git pull`, γενικά ανακτά τα δεδομένα από τον διακομιστή, τον οποίο είχαμε αρχικά κλωνοποιήσει και προσπαθεί να συγχωνεύσει αυτά τα δεδομάνα στον κώδικα πάνω στον οποίο εργαζόμαστε. -If you have a branch set up to track a remote branch (see the next section and <<_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +[NOTE] +==== +Από την έκδοση 2.27 του Git και μετά, η εντολή `git pull` σας προειδοποιεί αν η μεταβλητή `pull.rebase` δεν έχει καθοριστεί. +Το Git θα συνεχίσει να σας δίνει προειδοποιήσεις μέχρι να καθορίσετε αυτή τη μεταβλητή. -[[_pushing_remotes]] -==== Pushing to Your Remotes +Αν θέλετε την προεπιλεγμένη συμπεριφορά του Git (fast-forward αν είναι δυνατό, αλλιώς δημιούργησε μία υποβολή συγχώνευσης (merge commit)): +`git config --global pull.rebase "false"` -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push [remote-name] [branch-name]`.(((git commands, push))) -If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +Αν θέλετε να κάνετε rebase όταν έλκουμε: +`git config --global pull.rebase "true"` +==== + +[[r_pushing_remotes]] +==== Ώθηση δεδομένων σε απομακρυσμένα αποθετήρια + +Όταν έχουμε φέρει κάποιο έργο μας σε σημείο που θέλουμε να το κοινοποιήσουμε, θα πρέπει να το ωθήσουμε. +Η εντολή είναι απλή: `git push `.(((εντολές git, push))) +Για παράδειγμα, αν θέλουμε να ωθήσουμε τον τοπικό μας κλάδο `master` στον απομακρυσμένο διακομιστή `origin` (επαναλαμβάνουμε ότι η κλωνοποίηση παραμετροποιεί αυτόματα αυτά τα ονόματα), τότε μπορούμε να εκτελέσουμε αυτή την εντολή έτσι ώστε να ωθήσουμε τις υποβολές (commits) που έχουμε κάνει στον διακομιστή: [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push. -See <<_git_branching>> for more detailed information on how to push to remote servers. +Η εντολή αυτή θα εκτελεστεί επιτυχώς μόνο αν έχουμε κλωνοποιήσει από έναν διακομιστή στον οποίο έχουμε δικαίωμα εγγραφής και αν κανείς άλλος δεν έχει ωθήσει δεδομένα στο μεσοδιάστημα. +Αν εμείς και κάποιος άλλος έχουμε κλωνοποιήσει το έργο ενώ αυτό βρίσκεται στην ίδια κατάσταση και αυτός ωθήσει δεδομένα στον διακομιστή και μετά ωθήσουμε εμείς δεδομένα στον διακομιστή, η δική μας εντολή για ώθηση δεδομένων θα απορριφθεί. +Αυτό που θα πρέπει να κάνουμε είναι να ανακτήσουμε τις αλλαγές του άλλου και να τις ενσωματώσουμε στις δικές μας, ώστε να μας επιτραπεί να ωθήσουμε. +Στην ενότητα <> θα δούμε περισσότερες πληροφορίες σχετικά με την ώθηση δεδομένων σε απομακρυσμένους διακομιστές. -[[_inspecting_remote]] -==== Inspecting a Remote +[[r_inspecting_remote]] +==== Επιθεώρηση απομακρυσμένου αποθετηρίου -If you want to see more information about a particular remote, you can use the `git remote show [remote-name]` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +Αν θέλουμε να δούμε περισσότερες πληροφορίες σχετικά με ένα απομακρυσμένο αποθετήριο, μπορούμε να χρησιμοποιήσουμε την εντολή `git remote show `.(((εντολές git, remote))) +Αν εκτελέσουμε αυτή την εντολή με κάποιο σύντομο όνομα, όπως το `origin`, θα δούμε κάτι σαν: [source,console] ---- @@ -157,12 +178,12 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the master branch and you run `git pull`, it will automatically merge in the master branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. +Παρατίθεται το URL του απομακρυσμένου αποθετηρίου καθώς και οι κλάδοι τους οποίους παρακολουθούμε. +Επίσης μας ενημερώνει ότι αν βρισκόμαστε στον κλάδο `master` και εκτελέσουμε `git pull`, ο κλάδος `master` του απομακρυσμένου αποθετηρίου θα συγχωνευτεί αυτόματα στον τοπικό κλάδο `master` αφότου ανακτηθεί. +Επίσης παραθέτει τις απομακρυσμένες αναφορές που έχει κατεβάσει. -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +Το παραπάνω είναι ένα απλό παράδειγμα που ενδεχομένως θα συναντήσουμε. +Όταν αρχίσουμε να χρησιμοποιούμε πιο εκτεταμένα το Git, μπορεί να δούμε πολύ περισσότερες πληροφορίες όταν εκτελούμε την εντολή `git remote show`. [source,console] ---- @@ -188,13 +209,13 @@ $ git remote show origin master pushes to master (up to date) ---- -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`. +Αυτή η εντολή μας δείχνει σε αυτή την περίπτωση σε ποιον κλάδο ωθούμε δεδομένα όταν βρισκόμαστε σε συγκεκριμένους κλάδους και εκτελούμε την εντολή `git push`. +Επίσης μας δείχνει ποιους απομακρυσμένους κλάδους του διακομιστή δεν έχουμε ακόμα, ποιους απομακρυσμένους κλάδους έχουμε αλλά έχουν αφαιρεθεί από τον διακομιστή, καθώς και τους κλάδους που θα συγχωνευτούν αυτόματα στους τοπικούς κλάδους που τους παρακολουθούν αν εκτελέσουμε την εντολή `git pull`. -==== Removing and Renaming Remotes +==== Μετονομασία και διαγραφή απομακρυσμένων αποθετηρίων -If you want to rename a reference you can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +Αν θέλουμε να μετονομάσουμε το σύντομο όνομα ενός απομακρυσμένου αποθετηρίου, εκτελούμε την εντολή `git remote rename`.(((εντολές git, remote))) +Για παράδειγμα, αν θέλουμε να μετονομάσουμε το `pb` σε `paul`, μπορούμε να χρησιμοποιήσουμε την `git remote rename`: [source,console] ---- @@ -204,14 +225,16 @@ origin paul ---- -It's worth mentioning that this changes your remote branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. +Αξίζει να σημειωθεί ότι η εντολή αυτή αλλάζει επίσης τα ονόματα των απομακρυσμένων κλάδων που παρακολουθούμε. +Στον κλάδο στον οποίο αναφερόμασταν ως `pb/master` πλέον θα αναφερόμαστε ως `paul/master`. -If you want to remove a remote for some reason – you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore – you can use `git remote rm`: +Αν θελήσουμε να διαγράψουμε για κάποιο λόγο ένα απομακρυσμένο αποθετήριο· έχουμε μετακίνησει τον διακομιστή σε άλλη διεύθυνση ή δεν χρησιμοποιούμε καθόλου το συγκεκριμένο αποθετήριο, ή απλά κάποιος συνεργάτης έχει εγκαταλείψει -- μπορούμε να χρησιμοποιήσουμε είτε την εντολή `git remote remove` ή την `git remote rm`: [source,console] ---- -$ git remote rm paul +$ git remote remove paul $ git remote origin ---- + +Μόλις σβήσουμε την αναφορά σε κάποιο απομακρυσμένο αποθετήριο με αυτό το τρόπο, όλοι οι απομακρυσμένοι κλάδοι και όλες οι ρυθμίσεις που είναι σχετικές με αυτό το απομακρυσμένο αποθετήριο, θα σβηστούν επίσης. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 00cf3847e..7e8f0bf20 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -1,32 +1,32 @@ -[[_git_tagging]] -=== Tagging +[[r_git_tagging]] +=== Ετικέτες -(((tags))) -Like most VCSs, Git has the ability to tag specific points in history as being important. -Typically people use this functionality to mark release points (v1.0, and so on). -In this section, you'll learn how to list the available tags, how to create new tags, and what the different types of tags are. +(((ετικέτες)))(((tags))) +Το Git, όπως και τα περισσότερα VCS, δίνει τη δυνατότητα να βάζουμε ετικέτες (tags) σε συγκεκριμένα σημεία του ιστορικού ενός έργου. +Η λειτουργικότητα αυτή χρησιμοποείται συνήθως για σημειωθούν συγκεκριμένες εκδόσεις (π.χ. έκδοση `1.0`, `2.0` κ.ο.κ.). +Σε αυτή την ενότητα θα μάθουμε πώς να βλέπουμε ποιες ετικέτες έχει ένα έργο, πώς να δημιουργούμε ετικέτες και ποια είδη ετικετών υπάρχουν. -==== Listing Your Tags +==== Παράθεση ετικετών -Listing the available tags in Git is straightforward. -Just type `git tag`:(((git commands, tag))) +Για να δούμε τις ετικέτες ενός έργου, η εντολή στο Git είναι αρκετά απλή. +Απλά πληκτρολογούμε `git tag` (και προαιρετικά `-l` ή `--list`):(((εντολές git, tag))) [source,console] ---- $ git tag -v0.1 -v1.3 +v1.0 +v2.0 ---- -This command lists the tags in alphabetical order; the order in which they appear has no real importance. +Η εντολή παραθέτει τις ετικέτες σε αλφαβητική σειρά, αν και η σειρά αυτή δεν έχει κάποια ιδιαίτερη σημασία. -You can also search for tags with a particular pattern. -The Git source repo, for instance, contains more than 500 tags. -If you're only interested in looking at the 1.8.5 series, you can run this: +Μπορούμε επίσης να αναζητήσουμε ετικέτες που ακολουθούν κάποιο μοτίβο. +Για παράδειγμα, το αποθετήριο με τον πηγαίο κώδικα του Git περιέχει περισσότερες από 500 ετικέτες. +Αν μας ενδιφέρει να δούμε μόνο αυτές που έχουν σχέση με την έκδοση 1.8.5, τότε μπορούμε να εκτελέσουμε: [source,console] ---- -$ git tag -l 'v1.8.5*' +$ git tag -l "v1.8.5*" v1.8.5 v1.8.5-rc0 v1.8.5-rc1 @@ -39,36 +39,44 @@ v1.8.5.4 v1.8.5.5 ---- -==== Creating Tags +[NOTE] +.Παράθεση ετικετών με χαρακτήρες υποκατάστασης απαιτεί την επιλογή `-l` ή `--list` +==== +Αν θέλετε μόνο την πλήρη λίστα των ετικετών, τότε αν εκτελέσετε την εντολή `git tag` υποθέτει ότι θέλετε μια λίστα και την εμφανίζει· η χρήση του `-l` ή του `--list` σε αυτή την περίπτωση είναι προαιρετική. + +Αν όμως δώσετε και ένα μοτίβο με χαρακτήρες υποκατάσταση (wildcards), τότε η χρήση ενός από τα `-l` ή `--list` είναι υποχρεωτική. +==== -Git uses two main types of tags: lightweight and annotated. +==== Δημιουργία ετικετών -A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit. +Το Git χρησιμοποιεί δύο κατηγορίες ετικετών, τις _απλές_ (_lightweight_) και τις ετικέτες με _επισημείωση_ (_annotated_). -Annotated tags, however, are stored as full objects in the Git database. -They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). -It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too. +Μια απλή ετικέτα μοιάζει πολύ με έναν κλάδο που δεν αλλάζει· είναι απλά ένας δείκτης σε μια συγκεκριμένη υποβολή. -[[_annotated_tags]] -==== Annotated Tags +Οι ετικέτες με επισημειώσεις από την άλλη, αποθηκεύονται στη βάση δεδομένων του Git ως πλήρη αντικείμενα. +Για καθεμία επισημειωμένη ετικέτα: υπολογίζεται το άθροισμα ελέγχου (checksum) της· περιέχει το όνομα, και τη διεύθυνση e-mail αυτού που βάζει την ετικέτα και την ημερομηνία· έχει ένα μήνυμα· μπορεί να υπογραφεί και να επαληθευθεί με τον GNU Privacy Guard (GPG). +Γενικά συνιστάται να δημιουργούμε ετικέτες με επισημειώσεις (annotations) έτσι ώστε να έχουμε όλες αυτές τις πληροφορίες, αλλά αν για κάποιο λόγο θέλουμε μία προσωρινή ετικέτα ή μια ετικέτα χωρίς περαιτέρω πληροφορίες, μπορούμε να χρησιμοποιήσουμε τις απλές ετικέτες. -(((tags, annotated))) -Creating an annotated tag in Git is simple. -The easiest way is to specify `-a` when you run the `tag` command:(((git commands, tag))) +[[r_annotated_tags]] +==== Επισημασμένες ετικέτες + +(((ετικέτες, επισημασμένες)))(((tags, annotated))) +Η δημιουργία επισημασμένων ετικετών είναι απλή. +Ο ευκολότερος τρόπος είναι να χρησιμοποιήσουμε την επιλογή `-a` όταν εκτελούμε την εντολή `tag`:(((εντολές git, tag))) [source,console] ---- -$ git tag -a v1.4 -m 'my version 1.4' +$ git tag -a v1.4 -m "my version 1.4" $ git tag v0.1 v1.3 v1.4 ---- -The `-m` specifies a tagging message, which is stored with the tag. -If you don't specify a message for an annotated tag, Git launches your editor so you can type it in. +Η επιλογή `-m` σημαίνει ότι ακολουθεί το μήνυμα της ετικέτας, το οποίο και αποθηκεύεται μαζί με αυτή. +Αν δεν προσδιορίσουμε μήνυμα σε μια καινούρια επισημειωμένη ετικέτα, τότε το Git θα εκκινήσει τον επεξεργαστή κειμένου μας, ώστε να γράψουμε το μήνυμα εκεί. -You can see the tag data along with the commit that was tagged by using the `git show` command: +Χρησιμοποιώντας την εντολή `git show` μπορούμε να δούμε τις πληροφορίες που περιέχει μια ετικέτα: [source,console] ---- @@ -83,17 +91,17 @@ commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 - changed the version number + Change version number ---- -That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. +Η εντολή αυτή μας δείχνει πληροφορίες για τον χρήστη που έφτιαξε την ετικέτα, την ημερομηνία που τοποθετήθηκε η ετικέτα στην υποβολή (commit) και το μήνυμά της. -==== Lightweight Tags +==== Απλές ετικέτες -(((tags, lightweight))) -Another way to tag commits is with a lightweight tag. -This is basically the commit checksum stored in a file – no other information is kept. -To create a lightweight tag, don't supply the `-a`, `-s`, or `-m` option: +(((ετικέτες, απλές)))(((tags, lightweight))) +Ένας άλλος τρόπος για να βάζουμε ετικέτες στις υποβολές είναι οι απλές (lightweight) ετικέτες. +Μία τέτοια ετικέτα δεν είναι τίποτα άλλο από το άθροισμα ελέγχου της υποβολής μας, που αποθηκεύεται σε ένα αρχείο· δεν διατηρείται καμία άλλη πληροφορία. +Για να δημιουργήσουμε μια απλή ετικέτα, δεν θα πρέπει να χρησιμοποιήσουμε τις επιλογές `-a`, `-s` ή `-m`: [source,console] ---- @@ -106,8 +114,8 @@ v1.4-lw v1.5 ---- -This time, if you run `git show` on the tag, you don't see the extra tag information.(((git commands, show))) -The command just shows the commit: +Αν τώρα εκτελέσουμε `git show` για τη συγκεκριμένη ετικέτα, δεν θα δούμε τις επιπλέον πληροφορίες που έχουν οι επισημασμένες ετικέτες.(((εντολές git, show))) +Θα δούμε μόνο την υποβολή: [source,console] ---- @@ -116,39 +124,39 @@ commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 - changed the version number + Change version number ---- -==== Tagging Later +==== Προσάρτηση ετικέτας εκ των υστέρων -You can also tag commits after you've moved past them. -Suppose your commit history looks like this: +Μπορούμε επίσης να προσαρτήσουμε ετικέτες σε παλαιότερες υποβολές. +Ας υποθέσουμε ότι το ιστορικό υποβολών μας είναι κάπως έτσι: [source,console] ---- $ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' -a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support -0d52aaab4479697da7686c15f77a3d64d9165190 one more thing +a6b4c97498bd301d84096da251c98a07c7723e65 Create write support +0d52aaab4479697da7686c15f77a3d64d9165190 One more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' -0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function -4682c3261057305bdd616e23b64b0857d832627b added a todo file -166ae0c4d3f420721acbb115cc33848dfcc2121a started write support -9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile -964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo -8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme +0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc Add commit function +4682c3261057305bdd616e23b64b0857d832627b Add todo file +166ae0c4d3f420721acbb115cc33848dfcc2121a Create write support +9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile +964f16d36dfccde844893cac5b347e7b3d44abbc Commit the todo +8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme ---- -Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit. -You can add it after the fact. -To tag that commit, you specify the commit checksum (or part of it) at the end of the command: +Ας υποθέσουμε τώρα ότι ξεχάσαμε να βάλουμε ετικέτα στο έργο μας στην έκδοση v1.2 που ήταν η υποβολή με το μήνυμα "`updated rakefile`". +Μπορούμε να προσαρτήσουμε την ετικέτα αργότερα. +Για να το κάνουμε αυτό, θα πρέπει να προσδιορίσουμε το άθροισμα ελέγχου της υποβολής μας (ή ένα μέρος του) (commit checksum) στο τέλος της εντολής: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -You can see that you've tagged the commit:(((git commands, tag))) +Μπορούμε να δούμε ότι έχουμε προσθέσει την ετικέτα στην υποβολή:(((εντολές git, tag))) [source,console] ---- @@ -170,16 +178,16 @@ commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon Date: Sun Apr 27 20:43:35 2008 -0700 - updated rakefile + Update rakefile ... ---- -[[_sharing_tags]] -==== Sharing Tags +[[r_sharing_tags]] +==== Κοινοποίηση ετικετών -By default, the `git push` command doesn't transfer tags to remote servers.(((git commands, push))) -You will have to explicitly push tags to a shared server after you have created them. -This process is just like sharing remote branches – you can run `git push origin [tagname]`. +Εξ ορισμού, η εντολή `git push` δεν μεταφέρει ετικέτες στους απομακρυσμένους διακομιστές.(((εντολές git, push))) +Θα πρέπει να ορίσουμε ρητά ότι θέλουμε να ωθήσουμε τις ετικέτες στον διακομιστή, αφού προηγουμένως τις έχουμε δημιουργήσει. +Η διαδικασία είναι παρόμοια με την κοινοποίηση απομακρυσμένων κλάδων -- εκτελούμε την εντολή `git push origin `. [source,console] ---- @@ -193,8 +201,8 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -If you have a lot of tags that you want to push up at once, you can also use the `--tags` option to the `git push` command. -This will transfer all of your tags to the remote server that are not already there. +Αν έχουμε πολλές ετικέτες που θέλουμε να ωθήσουμε με τη μία, μπορούμε επίσης να χρησιμοποιήσουμε την επιλογή `--tags` στην εντολή `git push`. +Με τον τρόπο αυτό θα μεταφέρουμε στον διακομιστή όλες τις ετικέτες που δεν είναι ήδη εκεί. [source,console] ---- @@ -207,12 +215,80 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Now, when someone else clones or pulls from your repository, they will get all your tags as well. +Πλέον, όταν κάποιος κλωνοποιήσει ή ελκύσει (pulls) δεδομένα από το αποθετήριό μας, θα λάβει μαζί και όλες τις ετικέτες μας. + +[NOTE] +.Η εντολή `git push` ωθεί και τα δύο είδη ετικετών +==== +Η εντολή `git push --tags` θα ωθήσει τόσο τις απλές όσο και τις επισημασμένες ετικέτες. +Προς το παρόν δεν υπάρχει κάποιος τρόπος να ωθήσετε μόνο τις απλές ετικέτες, αλλά αν εκτελέσετε `git push --follow-tags` μόνο οι επισημασμένες ετικέτες θα ωθηθούν στον απομακρυσμένο διακομιστή. +==== + +==== Διαγραφή ετικετών + +Για να διαγράψουμε μια ετικέτα στο τοπικό μας αποθετήριο, μπορούμε να εκτελέσουμε `git tag -d `. +Για παράδειγμα, μπορούμε να διαγράψουμε την απλή ετικέτα που δημιουργήσαμε παραπάνω ως εξής: + +[source,console] +---- +$ git tag -d v1.4-lw +Deleted tag 'v1.4-lw' (was e7d5add) +---- + +Σημειώνουμε ότι η εντολή αυτή δεν διαγράφει την ετικέτα από τους απομακρυσμένους διακομιστές. +Υπάρχουν δύο παραλλαγές για τη διαγραφή ετικετών από έναν απομακρυσμένο διακομιστή. + +Η πρώτη είναι η εντολή `git push :refs/tags/`: + +[source,console] +---- +$ git push origin :refs/tags/v1.4-lw +To /git@github.com:schacon/simplegit.git + - [deleted] v1.4-lw +---- + +Αυτό ερμηνεύεται ως εξής: η ετικέτα της οποίας το ονομα είναι ο χαρακτήρας null πριν από το `:` ωθείται στο απομακρυσμένο όνομα ετικέτας και ουσιαστικά το διαγράφει. -==== Checking out Tags +Η δεύτερη (και πιο διαισθητική) είναι να διαγράψουμε την ετικέτα ως εξής: + +[source,console] +---- +$ git push origin --delete +---- + +==== Ενημέρωση (check out) ετικετών + +Για να δούμε τις εκδόσεις των αρχείων μας στα οποία δείχνει μία ετικέτα, μπορούμε να εκτελέσουμε `git checkout` για αυτή την ετικέτα, αλλά αυτό θέτει το αποθετήριό μας σε κατάσταση "`detached HEAD`", κάτι που έχει κάποιες παρενέργειες: + +[source,console] +---- +$ git checkout v2.0.0 +Note: switching to 'v2.0.0'. + +You are in 'detached HEAD' state. You can look around, make experimental +changes and commit them, and you can discard any commits you make in this +state without impacting any branches by performing another checkout. + +If you want to create a new branch to retain commits you create, you may +do so (now or later) by using -c with the switch command. Example: + + git switch -c + +Or undo this operation with: + + git switch - + +Turn off this advice by setting config variable advice.detachedHead to false + +HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final + +$ git checkout v2.0-beta-0.1 +Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final +HEAD is now at df3f601... Add atlas.json and cover image +---- -You can't really check out a tag in Git, since they can't be moved around. -If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag with `git checkout -b [branchname] [tagname]`: +Στην κατάσταση "`detached HEAD`", αν κάνουμε αλλαγές και δημιουργήσουμε μια υποβολή (commit), η ετικέτα θα παραμείνει η ίδια, αλλά η νέα υποβολή δεν θα ανήκει σε κανέναν κλάδο και δεν θα είναι προσβάσιμη με κανέναν τρόπο εκτός κι αν χρησιμοποιήσουμε το ακριβές hash της υποβολής. +Επιπλέον, αν χρειάζεται να κάνουμε αλλαγές -- ας πούμε ότι διορθώνουμε κάποιο σφάλμα κάποιας παλιότερης έκδοσης, για παράδειγμα -- καλό θα είναι να δημιουργήσουμε έναν κλάδο: [source,console] ---- @@ -220,4 +296,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Of course if you do this and do a commit, your `version2` branch will be slightly different than your `v2.0.0` tag since it will move forward with your new changes, so do be careful. +Αν βέβαια εκτελέσουμε την παραπάνω εντολή και πραγματοποιήσουμε μια υποβολή, ο κλάδος `version2` θα είναι λίγο διαφορετικός από την ετικέτα `v2.0.0` διότι θα έχει προχωρήσει με τις νέες αλλαγές· συνεπώς προσοχή. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index faa306b57..bb0bbfdfd 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,44 +1,59 @@ -[[_undoing]] -=== Undoing Things +[[r_undoing]] +=== Αναιρέσεις (undoing) -At any stage, you may want to undo something. -Here, we'll review a few basic tools for undoing changes that you've made. -Be careful, because you can't always undo some of these undos. -This is one of the few areas in Git where you may lose some work if you do it wrong. +Οποιαδήποτε στιγμή, μπορεί να θελήσουμε να αναιρέσουμε κάτι. +Σε αυτό το κεφάλαιο, θα δούμε μερικά βασικά εργαλεία με τα οποία μπορούμε να αναιρέσουμε αλλαγές που έχουμε ήδη κάνει. +Θα πρέπει να είμαστε προσεκτικοί γιατί δεν θα μπορούμε πάντα να αναιρέσουμε κάποιες από αυτές τις αναιρέσεις. +Αυτή είναι μία από τις λίγες περιπτώσεις στο Git όπου μπορεί να χάσουμε μέρος της δουλειάς μας αν κάνουμε τις αναιρέσεις λανθασμένα. -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. -If you want to try that commit again, you can run commit with the `--amend` option: +Μια συχνή αναίρεση που χρησιμοποιείται είναι η περίπτωση κατά την οποία υποβάλλουμε κάτι πολύ νωρίς και ενδεχομένως ξεχάσουμε να προσθέσουμε κάποια αρχεία ή κάνουμε κάποιο σφάλμα στο μήνυμα υποβολής. +Αν θέλουμε να ξανακάνουμε τη συγκεκριμένη υποβολή, να προσθέσουμε τις αλλαγές που ξεχάσαμε, να τις βάλουμε στο στάδιο καταχώρησης και να τις ξαναϋποβάλλουμε, θα πρέπει να χρησιμοποιήσουμε την επιλογή `--amend`: [source,console] ---- $ git commit --amend ---- -This command takes your staging area and uses it for the commit. -If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message. +Η εντολή αυτή παίρνει το στάδιο καταχώρησης και το χρησιμοποιεί για την υποβολή. +Αν δεν έχουμε κάνει περαιτέρω αλλαγές από την τελευταία μας υποβολή (για παράδειγμα, αν εκτελέσουμε αυτή την εντολή αμέσως μετά από μια υποβολή), τότε το στιγμιότυπο του αποθετηρίου θα είναι ακριβώς το ίδιο και το μόνο που θα αλλάξαμε είναι το μήνυμα υποβολής. -The same commit-message editor fires up, but it already contains the message of your previous commit. -You can edit the message the same as always, but it overwrites your previous commit. +Όταν εκτελέσουμε την εντολή, θα εκκινήσει ο επεξεργαστής κειμένου, που θα περιέχει το μήνυμα της προηγούμενης υποβολής μας. +Μπορούμε να επεξεργαστούμε το μήνυμα ως συνήθως, αλλά θα αντικαταστήσει την τελευταία μας υποβολή. -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +Για παράδειγμα, αν κάνουμε μια υποβολή και μετά διαπιστώσουμε ότι ξεχάσαμε να καταχωρήσουμε τις αλλαγές ενός αρχείου που θέλουμε να συμπεριλάβουμε στην υποβολή αυτή, τότε μπορούμε να: [source,console] ---- -$ git commit -m 'initial commit' +$ git commit -m 'Initial commit' $ git add forgotten_file $ git commit --amend ---- -You end up with a single commit – the second commit replaces the results of the first. +Καταλήγουμε με μια και μοναδική υποβολή· η δεύτερη υποβολή αντικαθιστά τα αποτελέσματα της πρώτης. -[[_unstaging]] -==== Unstaging a Staged File +[NOTE] +==== +Είναι σημαντικό να καταλάβετε ότι όταν τροποποιούμε (amend) την τελευταία σας υποβολή, στην πραγματικότητα δεν την _τροποποιείτε_ αλλά την _αντικαθιστείτε_ με μια εντελώς νέα, βελτιωμένη υποβολή που διώχνει την παλιά υποβολή και βάζει την νέα υποβολή στη θέση της. +Ουσιαστικά, είναι σαν η προηγούμενη υποβολή να μη συνέβη ποτέ και δεν θα εμφανίζεται στο ιστορικό του αποθετηρίου. + +Η αξία της τροποποίησης των υποβολών είναι ότι κάνετε ελάσονες βελτιώσεις στην τελευταία σας υποβολή, χωρίς να μπουκώνετε το ιστορικό του αποθετηρίου σας με μηνύματα υποβολής της μορφής "`Ωχ, ξέχασα να προσθέσω ένα αρχείο`" ή "`Να πάρει, διόρθωσα ένα τυπογραφικό στην προηγούμενη υποβολή`". +==== + +[NOTE] +==== +Να τροποποιείτε (amend) υποβολές που υπάρχουν μόνο τοπικα και δεν τις έχετε ωθήσει πουθενά. +Η τροποποίηση υποβολών που έχουν ήδη ωθηθεί και η ώθησή του κλάδου θα δημουργήσει προβλήματα στους συνεργάτες σας. +Περισσότερες λεπτομέρειες για το τι συμβαίνει όταν κάνετε κάτι τέτοιο, και πώς να το διορθώσετε όταν είμαστε αυτός που την πατάει υπάρχουν στο <>. +==== -The next two sections demonstrate how to wrangle your staging area and working directory changes. -The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. -For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. -How can you unstage one of the two? -The `git status` command reminds you: +[[r_unstaging]] +==== Αφαίρεση αρχείου από το στάδιο καταχώρησης (staging) + +Στις επόμενες δύο ενότητες θα δούμε πώς μπορούμε να διαχειριστούμε τις αλλαγές που έχουν γίνει στο στάδιο κατάχωρησης και στον κατάλογο εργασίας. +Το καλό είναι ότι η εντολή που χρησιμοποιούμε για να προσδιορίσουμε την κατάσταση αυτών των δύο περιοχών, μας υπενθυμίζει και πώς να αναιρέσουμε τις αλλαγές σε αυτές τις περιοχές. +Για παράδειγμα, έστω ότι έχουμε κάνει αλλαγές σε δύο αρχεία και θέλουμε να τα υποβάλλουμε ως ξεχωριστές αλλαγές, αλλά τα υποβάλαμε κατά λάθος και τα δύο με την εντολή `git add *`. +Πώς μπορούμε να αναιρέσουμε την καταχώριση του ενός από τα δύο; +Η εντολή `git status` μας υπενθυμίζει: [source,console] ---- @@ -52,8 +67,8 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -Right below the ``Changes to be committed'' text, it says use `git reset HEAD ...` to unstage. -So, let's use that advice to unstage the `CONTRIBUTING.md` file: +Ακριβώς κάτω από το "`Changes to be committed`", μας λέει να εκτελέσουμε `git reset HEAD ...` ώστε να αφαιρέσουμε την αλλαγή από το στάδιο καταχώρησης. +Ας χρησιμοποιήσουμε λοιπόν αυτή τη συμβουλή για το αρχείο `CONTRIBUTING.md`: [source,console] ---- @@ -74,24 +89,24 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -The command is a bit strange, but it works. -The `CONTRIBUTING.md` file is modified but once again unstaged. +Η εντολή φαίνεται λίγο περίεργη, αλλά κάνει τη δουλειά. +Το αρχείο `CONTRIBUTING.md` είναι τροποποιημένο, αλλά δεν βρίσκεται στο στάδιο καταχώρησης. [NOTE] ===== -While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. -Calling `git reset` without an option is not dangerous - it only touches your staging area. +Πράγματι, η εντολή `git reset` μπορεί να είναι επικίνδυνη, ιδιαίτερα αν την καλέσετε με τη σημαία `--hard`. +Όμως στο συγκεκριμένο σενάριο, το αρχείο στον κατάλογο εργασίας σας δεν τροποποιείται, οπότε είναι σχετικά ασφαλές. ===== -For now this magic invocation is all you need to know about the `git reset` command. -We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_reset>>. +Προς το παρόν, το μόνο που χρειάζεται να γνωρίζουμε για την εντολή `git reset` είναι η παραπάνω χρήση της. +Θα μπούμε σε περισσότερες λεπτομέρειες για το τι κάνει η εντολή `reset` και πώς να γίνουμε καλύτεροι, ώστε να κάνουμε πραγματικά ενδιαφέροντα πράγματα στην ενότητα <>. -==== Unmodifying a Modified File +==== Αναίρεση τροποποίησης ενός αρχείου -What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file? -How can you easily unmodify it – revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? -Luckily, `git status` tells you how to do that, too. -In the last example output, the unstaged area looks like this: +Τι μπορούμε να κάνουμε όμως αν διαπιστώσουμε ότι δεν θέλουμε να κρατήσουμε τις αλλαγές που κάναμε στο αρχείο `CONTRIBUTING.md`; +Πώς μπορούμε να το ξετροποποιήσουμε εύκολα -- να το φέρουμε στη μορφή που είχε στην τελευταία του υποβολή (ή όπως ήταν όταν το κλωνοποιήσαμε ή όπως το φέραμε στον κατάλογο εργασίας μας); +Ευτυχώς, η εντολή `git status` μας λέει πώς να το κάνουμε. +Στο αποτέλεσμα του προηγούμενου παραδείγματος, η περιοχή με τα μη καταχωρημένα αρχεία είναι κάπως έτσι: [source,console] ---- @@ -102,8 +117,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -It tells you pretty explicitly how to discard the changes you've made. -Let's do what it says: +Η εντολή μας πληροφορεί ρητά πώς να απορρίψουμε τις αλλαγές που έχουμε κάνει. +Ας κάνουμε ό,τι λέει: [source,console] ---- @@ -117,17 +132,104 @@ Changes to be committed: ---- -You can see that the changes have been reverted. +Μπορούμε να δούμε ότι οι αλλαγές έχουν επανέρθει στην προηγούμενη μορφή. [IMPORTANT] ===== -It's important to understand that `git checkout -- [file]` is a dangerous command. -Any changes you made to that file are gone – you just copied another file over it. -Don't ever use this command unless you absolutely know that you don't want the file. +Είναι σημαντικό να καταλάβουμε ότι η εντολή `git checkout \-- ` είναι αρκετά επικίνδυνη. +Όλες οι αλλαγές που έχουμε κάνει τοπικά σε αυτό το αρχείο έχουν πλέον χαθεί -- το Git αντικατέστησε αυτό το αρχείο με την τελευταία έκδοσή του από το στάδιο καταχώρησης ή την υποβεβλημένη έκδοση. +Να μην χρησιμοποιούμε αυτή την εντολή παρά μόνο αν είμαστε απολύτως σίγουροι ότι δεν θέλουμε να κρατήσουμε αυτές τις μη αποθηκευμένες τοπικές αλλαγές. ===== -If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<_git_branching>>; these are generally better ways to go. +Αν θέλουμε να κρατήσουμε τις αλλαγές που κάνουμε στο αρχείο, αλλά παρόλα αυτά χρειάζεται να το κάνουμε στην άκρη, θα πρέπει να εξετάσουμε τη φύλαξη των αλλαγών (stashing) και τη διακλάδωση (branching) στο κεφάλαιο <>, αυτοί συνήθως είναι καλύτεροι τρόποι. + +Θυμόμαστε, ότι έχει υποβληθεί (committed) στο Git μπορεί σχεδόν πάντα να ανακτηθεί. +Μπορούμε να ανακτήσουμε ακόμα και υποβολές σε κλάδους που έχουν διαγραφεί ή υποβολές που επανεγγράφηκαν, με την εντολή `git commit --amend` (βλ. <> σχετικά με την ανάκτηση δεδομένων). +Ωστόσο, αν κάτι δεν είναι υποβεβλημένο και το χάσουμε, είναι πολύ πιθανό να μην μπορέσουμε να το ανακτήσουμε. + +[[r_undoing_git_restore]] +==== Αναίρεση αλλαγών με το git restore + +Στην έκδοση 2.23.0 του Git εισήχθη νεά εντολή: `git restore`. +Βασικά είναι μια εναλλακτική της εντολής `git reset` που μόλις συζητήσαμε. +Από την Git έκδοση 2.23.0 και μετά, το Git χρησιμοποιεί την `git restore` αντί της `git reset` για πολλές λειτουργίες αναίρεσης. + +Ας ξαναδούμε τα βήματά μας, και να αναιρέσουμε αλλαγές με την `git restore` αντί της `git reset`. + +===== Αφαίρεση αρχείου από το στάδιο καταχώρησης με χρήση της git restore + +Στις επόμενες δύο ενότητες θα δούμε πώς μπορούμε να διαχειριστούμε τις αλλαγές που έχουν γίνει στο στάδιο καταχώρησης και στον κατάλογο εργασίας. +Το καλό είναι ότι η εντολή που χρησιμοποιούμε για να προσδιορίσουμε την κατάσταση αυτών των δύο περιοχών, μας υπενθυμίζει και πώς να αναιρέσουμε τις αλλαγές σε αυτές τις περιοχές. +Για παράδειγμα, έστω ότι έχουμε κάνει αλλαγές σε δύο αρχεία και θέλουμε να τα υποβάλλουμε ως ξεχωριστές αλλαγές, αλλά τα υποβάλλαμε κατά λάθος και τα δύο με την εντολή `git add *`. +Πώς μπορούμε να αναιρέσουμε την καταχώριση του ενός από τα δύο; +Η εντολή `git status` μας υπενθυμίζει: + +[source,console] +---- +$ git add * +$ git status +On branch master +Changes to be committed: + (use "git restore --staged ..." to unstage) + modified: CONTRIBUTING.md + renamed: README.md -> README + +---- + +Ακριβώς κάτω από το "`Changes to be committed`", μας λέει να εκτελέσουμε `git restore --staged ...` ώστε να αφαιρέσουμε την αλλαγή από το στάδιο καταχώρησης. +Ας χρησιμοποιήσουμε λοιπόν αυτή τη συμβουλή αυτή για το αρχείο `CONTRIBUTING.md`: + +[source,console] +---- +$ git restore --staged CONTRIBUTING.md +$ git status +On branch master +Changes to be committed: + (use "git restore --staged ..." to unstage) + renamed: README.md -> README + +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: CONTRIBUTING.md + +---- + +Το αρχείο `CONTRIBUTING.md` είναι τροποποιημένο, αλλά δεν βρίσκεται στο στάδιο καταχώρησης. + +===== Αναίρεση τροποποίησης ενός αρχείου με την χρήση της git restore -Remember, anything that is __committed__ in Git can almost always be recovered. -Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<_data_recovery>> for data recovery). -However, anything you lose that was never committed is likely never to be seen again. +Τι μπορούμε να κάνουμε όμως αν διαπιστώσουμε ότι δεν θέλουμε να κρατήσουμε τις αλλαγές που κάναμε στο αρχείο `CONTRIBUTING.md`; +Πώς μπορούμε να το ξετροποποιήσουμε εύκολα -- να το φέρουμε στη μορφή που είχε στην τελευταία του υποβολή (ή όπως ήταν όταν το κλωνοποιήσαμε ή όπως το φέραμε στον κατάλογο εργασίας μας); +Ευτυχώς, η εντολή `git status` μας λέει πώς να το κάνουμε. +Στο αποτέλεσμα του προηγούμενου παραδείγματος, η περιοχή με τα μη καταχωρημένα αρχεία είναι κάπως έτσι: + +[source,console] +---- +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: CONTRIBUTING.md + +---- + +Η εντολή μας πληροφορεί ρητά πώς να απορρίψουμε τις αλλαγές που έχουμε κάνει. +Ας κάνουμε ό,τι λέει: + +[source,console] +---- +$ git restore CONTRIBUTING.md +$ git status +On branch master +Changes to be committed: + (use "git restore --staged ..." to unstage) + renamed: README.md -> README + +---- + +[IMPORTANT] +===== +Είναι σημαντικό να καταλάβουμε ότι η εντολή `git restore -- ` είναι αρκετά επικίνδυνη. +Όλες οι αλλαγές που έχουμε κάνει τοπικά σε αυτό το αρχείο έχουν πλέον χαθεί -- το Git αντικατέστησε αυτό το αρχείο με την τελευταία έκδοσή του από το στάδιο καταχώρησης ή την υποβεβλημένη έκδοση. +Να μην χρησιμοποιούμε αυτή την εντολή παρά μόνο αν είμαστε απολύτως σίγουροι ότι δεν θέλουμε να κρατήσουμε αυτές τις μη αποθηκευμένες τοπικές αλλαγές. +===== diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index ff9f9b4a1..d9620adb2 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ -[[_viewing_history]] -=== Viewing the Commit History +[[r_viewing_history]] +=== Χρησιμοποιώντας το ιστορικό υποβολών -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. +Αφού έχουμε δημιουργήσει αρκετές υποβολές, ή έχουμε κλωνοποιήσει ένα αποθετήριο με υπάρχον ιστορικό υποβολών, κάποια στιγμή θα θελήσουμε να κοιτάξουμε στο παρελθόν για να δούμε τι έχει γίνει. +Το πιο βασικό και ισχυρό εργαλείο για να το κάνουμε αυτό είναι η εντολη `git log`. -These examples use a very simple project called ``simplegit''. -To get the project, run +Τα παρακάτω παραδείγματα χρησιμοποιούν ένα πολύ απλό έργο που ονομάζεται "`simplegit`". +Για να αποκτήσουμε το έργο, εκτελούμε: [source,console] ---- -git clone https://github.com/schacon/simplegit-progit +$ git clone https://github.com/schacon/simplegit-progit ---- -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +Αν εκτελέσουμε την εντολή `git log` σε αυτό το έργο, θα πάρουμε κάτι σαν το εξής:(((εντολές git, log))) [source,console] ---- @@ -21,29 +21,29 @@ commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 - changed the version number + Change version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 - removed unnecessary test + Remove unnecessary test commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31:28 2008 -0700 - first commit + Initial commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order – that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and e-mail, the date written, and the commit message. +Εξ ορισμού, η εντολή `git log` παραθέτει όλες τις υποβολές που έχουν γίνει στο αποθετήριο σε αντίστροφη χρονολογική σειρά, οι πιο πρόσφατες υποβολές εμφανίζονται πρώτες. +Όπως μπορούμε να δούμε, η εντολή καταγράφει κάθε υποβολή μαζί με το άθροισμα ελέγχου SHA-1, το όνομα και το e-mail του δημιουργού της, την ημερομηνία εγραφής, καθώς και το μήνυμα της υποβολής. -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. +Υπάρχει μια πληθώρα επιλογών για τη συγκεκριμένη εντολή ώστε να βρούμε ακριβώς αυτό που ψάχνουμε. +Θα δείξουμε κάποιες από τις πιο δημοφιλείς. -One of the more helpful options is `-p`, which shows the difference introduced in each commit. -You can also use `-2`, which limits the output to only the last two entries: +Μια από τις πιο χρήσιμες επιλογές είναι η `-p` ή `patch`, η οποία δείχνει τη διαφορά που εισήχθη σε κάθε υποβολή. +Μπορούμε επίσης να περιορίσουμε το πλήθος των υποβολών, για παράδειγμα χρησιμοποιούμε την `-2`, για να δούμε μόνο τις δύο τελευταίες υποβολές: [source,console] ---- @@ -52,7 +52,7 @@ commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 - changed the version number + Change version number diff --git a/Rakefile b/Rakefile index a874b73..8f94139 100644 @@ -72,7 +72,7 @@ commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 - removed unnecessary test + Remove unnecessary test diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c6340 100644 @@ -87,13 +87,12 @@ index a0a60ae..47c6340 100644 - git = SimpleGit.new - puts git.show -end -\ No newline at end of file ---- -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +Η επιλογή αυτή εμφανίζει τις ίδιες πληροφορίες, αλλά κάθε υποβολή ακολουθείται και από τις διαφορές (diff) που εισήγαγε. +Αυτό είναι πολύ χρήσιμο στην περίπτωση που θέλουμε να εξετάσουμε κάποιον κώδικα ή για να δούμε στα γρήγορα τι έγινε σε μια ακολουθία υποβολών που εισήγαγε κάποιος συνεργάτης μας. +Μπορούμε επίσης να χρησιμοποιήσουμε επιλογές ανακεφαλαίωσης με την `git log`. +Για παράδειμα, αν θέλουμε να δούμε κάποια συντομευμένα στατιστικά για την κάθε υποβολή, μπορούμε να χρησιμοποιήσουμε την επιλογή `--stat`: [source,console] ---- @@ -102,7 +101,7 @@ commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 - changed the version number + Change version number Rakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) @@ -111,7 +110,7 @@ commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 - removed unnecessary test + Remove unnecessary test lib/simplegit.rb | 5 ----- 1 file changed, 5 deletions(-) @@ -120,7 +119,7 @@ commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31:28 2008 -0700 - first commit + Initial commit README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ @@ -128,156 +127,166 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. +Όπως μπορούμε να δούμε, η επιλογή `--stat` εκτυπώνει κάτω από κάθε υποβολή, μια λίστα με τα τροποποιημένα αρχεία, πόσα αρχεία άλλαξαν, καθώς και πόσες γραμμές προστέθηκαν ή αφαιρέθηκαν σε αυτά τα αρχεία. +Επίσης, εκτυπώνει και μια περίληψη αυτών των πληροφοριών στο τέλος. -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +Μια ακόμα χρήσιμη επιλογή είναι η `--pretty`. +Η επιλογή αυτή αλλάζει τη μορφή της εξόδου της εντολής. +Υπάρχουν μερικές προϋπάρχουσες τιμές που μπορούμε να χρησιμοποιήσουμε. +Η τιμή `oneline` εκτυπώνει κάθε υποβολή σε μία γραμμή, κάτι το οποίο μπορεί να μας φανεί χρήσιμο αν βλέπουμε πολλές υποβολές. +Επιπλέον, οι τιμές `short`, `full` και `fuller` εμφανίζουν την ίδια έξοδο σε παρόμοια μορφή αλλά με λιγότερες ή περισσότερες πληροφορίες αντίστοιχα: [source,console] ---- $ git log --pretty=oneline -ca82a6dff817ec66f44342007202690a93763949 changed the version number -085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test -a11bef06a3f659402fe7563abf99ad00de2209e6 first commit +ca82a6dff817ec66f44342007202690a93763949 Change version number +085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Remove unnecessary test +a11bef06a3f659402fe7563abf99ad00de2209e6 Initial commit ---- -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing – because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +Η πιο ενδιαφέρουσα επιλογή είναι η `format`, η οποία μας επιτρέπει να προσδιορίσουμε εμείς τη μορφή που θα έχει η έξοδός. +Αυτό είναι εξαιρετικά χρήσιμο σε περιπτώσεις που θέλουμε η έξοδος να μπορεί να είναι αναγνώσιμη από κάποιο αυτοματοποιημένο σύστημα -- επειδή έχουμε προσδιορίσει τη μορφή της εξόδου ρητά, γνωρίζουμε ότι αυτή δεν θα αλλάξει με ενημερώσεις του Git:(((log, μορφοποίηση))) [source,console] ---- $ git log --pretty=format:"%h - %an, %ar : %s" -ca82a6d - Scott Chacon, 6 years ago : changed the version number -085bb3b - Scott Chacon, 6 years ago : removed unnecessary test -a11bef0 - Scott Chacon, 6 years ago : first commit +ca82a6d - Scott Chacon, 6 years ago : Change version number +085bb3b - Scott Chacon, 6 years ago : Remove unnecessary test +a11bef0 - Scott Chacon, 6 years ago : Initial commit ---- -<> lists some of the more useful options that format takes. +Ο πίνακας <> παραθέτει μερικές από τις πιο χρήσιμες επιλογές μορφοποίησης. [[pretty_format]] -.Useful options for `git log --pretty=format` +.Χρήσιμες επιλογές για την `git log --pretty=format` [cols="1,4",options="header"] |================================ -| Option | Description of Output -| `%H` | Commit hash -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author e-mail -| `%ad` | Author date (format respects the --date=option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject +| Επιλογή | Περιγραφή εξόδου +| `%H` | Αριθμός SHA-1 υποβολής +| `%h` | Συντμημένος αριθμός SHA-1 υποβολής +| `%T` | Αριθμός SHA-1 δέντρου +| `%t` | Συντμημένος αριθμός SHA-1 δέντρου +| `%P` | Αριθμοί SHA-1 γονέων +| `%p` | Συντμημένοι αριθμός SHA-1 γονέων +| `%an` | Όνομα συγγραφέα +| `%ae` | E-mail συγγραφέα +| `%ad` | Ημερομηνία συγγραφέα (σε μορφή που ορίζεται από την επιλογή `--date=`) +| `%ar` | Ημερομηνία συγγραφέα, σχετική +| `%cn` | Όνομα υποβάλλοντος +| `%ce` | E-mail υποβάλλοντος +| `%cd` | Ημερομηνία υποβολής +| `%cr` | Ημερομηνία υποβολής, σχετική +| `%s` | Θέμα |================================ -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit – you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <<_distributed_git>>. +Ίσως αναρωτιέστε ποια είναι η διαφορά μεταξύ του _author_ (δημιουργού, συγγραφέα) και του _committer_ (αυτού που έκανε την υποβολή). +Ο δημιουργός είναι το πρόσωπο που έγραψε αρχικά τη δουλειά, ενώ o _committer_ είναι αυτός που την υπέβαλε τελευταίος. +Συνεπώς, αν στείλουμε ένα επίθεμα για ένα έργο και κάποιος άλλος το υποβάλλει, θα πρέπει και οι δύο να πιστωθούμε τη δουλειά: εμείς ως δημιουργός και ο άλλος ως αυτός που την υπέβαλλε. +Θα αναλύσουμε αυτή τη διαφορά αυτή σε λίγο, στην ενότητα <>. -The oneline and format options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: +Οι επιλογές `oneline` και `format` είναι ιδιαίτερα χρήσιμες σε συνδυασμό με μια άλλη επιλογή της εντολής `log`, την `--graph`. +Η επιλογή αυτή προσθέτει ένα μικρό γράφημα με χαρακτήρες ASCII που δείχνει το ιστορικό των κλάδων και των συγχωνεύσεων: [source,console] ---- $ git log --pretty=format:"%h %s" --graph -* 2d3acf9 ignore errors from SIGCHLD on trap -* 5e3ee11 Merge branch 'master' of git://github.com/dustin/grit +* 2d3acf9 Ignore errors from SIGCHLD on trap +* 5e3ee11 Merge branch 'master' of https://github.com/dustin/grit.git |\ -| * 420eac9 Added a method for getting the current branch. -* | 30e367c timeout code and tests -* | 5a09431 add timeout protection to grit -* | e1193f8 support for heads with slashes in them +| * 420eac9 Add method for getting the current branch +* | 30e367c Timeout code and tests +* | 5a09431 Add timeout protection to grit +* | e1193f8 Support for heads with slashes in them |/ -* d6016bc require time for xmlschema +* d6016bc Require time for xmlschema * 11d191e Merge branch 'defunkt' into local ---- -This type of output will become more interesting as we go through branching and merging in the next chapter. +Αυτή η μορφή της εξόδου θα γίνει πιο ενδιαφέρουσα αργότερα όταν καλύψουμε τους κλάδους και τις συγχωνεύσεις στο επόμενο κεφάλαιο. -Those are only some simple output-formatting options to `git log` – there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +Αυτές είναι μερικές απλές επιλογές με τις οποίες μπορούμε να μορφοποιήσουμε την έξοδο της εντολής `git log` -- υπάρχουν πολλές άλλες. +Ο πίνακας <> καταγράφει όλες τις επιλογές που καλύψαμε μέχρι στιγμής, καθώς και κάποιες άλλες επιλογές μορφοποίησης που μπορεί να μας φανούν χρήσιμες μαζί με μια περιγραφή του τρόπου με τον οποίο αλλάζουν το αποτέλεμσμα της εντολής `log`. [[log_options]] -.Common options to `git log` +.Συνήθεις επιλογές για την `git log` [cols="1,4",options="header"] |================================ -| Option | Description -| `-p` | Show the patch introduced with each commit. -| `--stat` | Show statistics for files modified in each commit. -| `--shortstat` | Display only the changed/insertions/deletions line from the --stat command. -| `--name-only` | Show the list of files modified after the commit information. -| `--name-status` | Show the list of files affected with added/modified/deleted information as well. -| `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40. -| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. -| `--graph` | Display an ASCII graph of the branch and merge history beside the log output. -| `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). +| Επιλογή | Περιγραφή +| `-p` | Δείξε το επίθεμα (patch) που εισήχθηκε σε κάθε υποβολή. +| `--stat` | Δείξε στατιστικά σχετικά με τα αρχεία που τροποποιήθηκαν σε κάθε υποβολή. +| `--shortstat` | Δείξε μόνον την τελευταία γραμμή από την επιλογή `--stat`, που δείχνει μόνο τον συνολικό αριθμό αρχείων που τροποποιήθηκαν και αριθμό γραμμών που προστέθηκαν και αφαιρέθηκαν. +| `--name-only` | Δείξε τη λίστα των αρχείων που τροποποιήθηκαν (μετά τις πληροφορίες για την υποβολή). +| `--name-status` | Δείξε επιπλέον τη λίστα των αρχείων που επηρεάστηκαν με προσθήκη/τροποποίηση/διαγραφή πληροφοριών. +| `--abbrev-commit` | Δείξε μόνο τους πρώτους χαρακτήρες από τους 40 του αθροίσματος ελέγχου SHA-1. +| `--relative-date` | Δείξε τη σχετική ημερομηνία σε σχετική μορφή (π.χ. "`2 weeks ago`") αντί για την πλήρη. +| `--graph` | Δείξε ένα γράφημα ASCII του κλάδου και του ιστορικού συγχώνευσης δίπλα στην έξοδο του μητρώου. +| `--pretty` | Δείξε τις υποβολές σε εναλλακτική μορφή· οι επιλογές είναι: `oneline`, `short`, `full`, `fuller` και `format` (στην οποία ορίζουμε τη δική μας μορφή). +| `--oneline` | Συντόμευση για `--pretty=oneline --abbrev-commit` χρήση και των δύο μαζί. |================================ -==== Limiting Log Output +==== Περιορίζοντας την έξοδο της `log` -In addition to output-formatting options, `git log` takes a number of useful limiting options – that is, options that let you show only a subset of commits. -You've seen one such option already – the `-2` option, which show only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +Εκτός από τις επιλογές μορφοποίησης, η εντολή `git log` έχει και πολλές επιλογές που περιορίζουν την έξοδό της -- δηλαδή, επιλογές που μας δείχνουν μόνο ένα υποσύνολο των συνολικών υποβολών. +Έχουμε ήδη δει μια τέτοια επιλογή, την `-2`, η οποία εμφανίζει μόνο τις δύο τελευταίες υποβολές. +Μάλιστα, μπορούμε να χρησιμοποιήσουμε `-`, όπου `n` είναι ένας ακέραιος που αντιστοιχεί στις τελευταίες `n` υποβολές. +Στην πραγματικότητα, βέβαια, είναι σχετικά απίθανο να χρησιμοποιούμε αυτή την επιλογή συχνά, καθώς το Git εκ προεπιλογής παροχετεύει την έξοδο σε έναν σελιδοποιητή οπότε βλέπουμε μόνο μια σελίδα με τα στοιχεία του μητρώου κάθε φορά. -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: +Ωστόσο, θα μας φανούν πολύ χρήσιμες οι επιλογές που περιορίζουν τον αριθμό των αποτελεσμάτων με χρονικά κριτήρια. +Για παράδειγμα, η εντολή αυτή θα μας δώσει μια λίστα με τις υποβολές που έγιναν τις τελευταίες δύο εβδομάδες: [source,console] ---- $ git log --since=2.weeks ---- -This command works with lots of formats – you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +Η εντολή αυτή χρησιμοποιείται με πολλές διαφορετικές μορφές -- μπορούμε να προσδιορίσουμε μια συγκεκριμένη μέρα, `"2008-01-15"`, ή μια σχετική μέρα όπως `"2 years 1 day 3 minutes ago"`. -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. -(Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +Μπορούμε επίσης να φιλτράρουμε τη λίστα με τις υποβολές με βάση κάποια κριτήρια. +Η επιλογή `--author` μας επιτρέπει να φιλτράρουμε με βάση έναν συγκεκριμένο δημιουργό και η επιλογή `--grep` μας επιτρέπει να ψάξουμε για λέξεις-κλειδιά στα μηνύματα των υποβολών. -Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string. -For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +[NOTE] +==== +Μπορείτε να χρησιμοποιήσετε περισσότερες από μία φορές τα κριτήρια αναζήτησης `--author` και `--grep`, κάτι που θα περιορίσει την έξοδο της εντολής `log` σε υποβολές που συμφωνούν με _οποιοδήποτε_ από τα μοτίβα για τον `--author` και _οποιοδήποτε_ από τα μοτίβα του `--grep`· πάντως αν προσθέσετε επιπλέον την επιλογή `--all-match`, θα περιορίσετε την έξοδο σε αυτές τις υποβολές που συμφωνούν με _όλα_ τα μοτίβα του `--grep`. +==== + +Ένα ακόμα πολύ χρήσιμο φίλτρο είναι η επιλογή `-S` (κατά το κοινώς λεγόμενο η "`αξίνα`" ("`pickaxe`") του Git) η οποία παίρνει μια συμβολοσειρά και μας δείχνει μόνο τις υποβολές που εισήγαγαν κάποια αλλαγή στον κώδικα, η οποία προσέθεσε ή αφαίρεσε αυτή τη συμβολοσειρά. +Για παράδειγμα, αν θέλουμε να βρούμε την τελευταία υποβολή που προσέθεσε ή αφαίρεσε μια αναφορά σε μια συγκεκριμένη συνάρτηση, θα γράφαμε: [source,console] ---- -$ git log -Sfunction_name +$ git log -S function_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +Η τελευταία πραγματικά χρήσιμη επιλογή που μπορούμε να περάσουμε στην `git log` ως φίλτρο, είναι η διαδρομή του καταλόγου (path). +Αν προσδιορίσουμε έναν κατάλογο ή ένα όνομα αρχείου, μπορούμε να περιορίσουμε την έξοδο της εντολής `log` ώστε να μας εμφανίσει μόνο τις υποβολές που επέφεραν αλλαγές σε αυτά τα αρχεία. +Συνήθως αυτή είναι η τελευταία επιλογή και γενικά ακολουθεί μια διπλή παύλα (`--`) ώστε να ξεχωρίζουμε τις διαδρομές των αρχείων από τις επιλογές. + +[source,console] +---- +$ git log -- path/to/file +---- -In <> we'll list these and a few other common options for your reference. +Στον πίνακα <> καταγράφουμε κάποιες από αυτές τις επιλογές αυτές για εύκολη αναφορά. [[limit_options]] -.Options to limit the output of `git log` +.Επιλογές που περιορίζουν την έξοδο της `git log` [cols="2,4",options="header"] |================================ -| Option | Description -| `-(n)` | Show only the last n commits -| `--since`, `--after` | Limit the commits to those made after the specified date. -| `--until`, `--before` | Limit the commits to those made before the specified date. -| `--author` | Only show commits in which the author entry matches the specified string. -| `--committer` | Only show commits in which the committer entry matches the specified string. -| `--grep` | Only show commits with a commit message containing the string -| `-S` | Only show commits adding or removing code matching the string +| Επιλογή | Περιγραφή +| `-(n)` | Δείξε μόνον τις τελευταίες n υποβολές. +| `--since`, `--after` | Περιόρισε τις υποβολές σε αυτές που έγιναν μετά από συγκεκριμένη ημερομηνία. +| `--until`, `--before` | Περιόρισε τις υποβολές σε αυτές που έγιναν πριν από συγκεκριμένη ημερομηνία. +| `--author` | Δείξε μόνο τις υποβολές στις οποίες το πεδίο author συμφωνεί με συγκεκριμένη συμβολοσειρά. +| `--committer` | Δείξε μόνο τις υποβολές στις οποίες το πεδίο committer συμφωνεί με συγκεκριμένη συμβολοσειρά. +| `--grep` | Δείξε μόνο τις υποβολές στις οποίες το μήνυμα υποβολής περιέχει συγκεκριμένη συμβολοσειρά. +| `-S` | Δείξε μόνο τις υποβολές στις οποίες προστέθηκε ή αφαιρέθηκε κώδικας που ταιριάζει με συγκεκριμένη συμβολοσειρά. |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:(((log filtering))) +Για παράδειγμα, αν θέλουμε να δούμε ποιες υποβολές τροποποίησαν αρχεία τεστ στο ιστορικό του πηγαίου κώδικα του Git από τον Junio Hamano και δεν είναι υποβολές συγχώνευσης κατά τον Οκτώβριο του 2008, μπορούμε να εκτελέσουμε κάτι τέτοιο:(((log, φιλτράρισμα))) [source,console] ---- -$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ +$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attributes are in use acd3b9e - Enhance hold_lock_file_for_{update,append}() API @@ -287,4 +296,11 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Από τις περίπου 40.000 υποβολές στο ιστορικό του πηγαίου κώδικα του Git, η εντολή αυτή θα μας δείξει μόνο έξι που ταιριάζουν με τα παραπάνω κριτήρια. + +[TIP] +.Αποτροπή της εμφάνισης των υποβολών συγχώνευσης +==== +Ανάλογα με τη ροή εργασίας που χρησιμοποιοείτε στο αποθετήριό σας, ενδέχεται ένα σημαντικό ποσοστό των υποβολών στο ιστορικό να είναι απλά υποβολές συγχώνευσης, οι οποίες γενικά δεν εμπεριέχουν πολλές πληροφορίες. +Για να αποτρέψετε την εμφάνιση των υποβολών συγχώνευσης, απλά προσθέτετε στη `log` την επιλογή `--no-merges`. +==== diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc deleted file mode 100644 index 77fb9e603..000000000 --- a/book/03-git-branching/1-git-branching.asc +++ /dev/null @@ -1,32 +0,0 @@ -[[_git_branching]] -== Git Branching - -(((branches))) -Nearly every VCS has some form of branching support. -Branching means you diverge from the main line of development and continue to do work without messing with that main line. -In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. - -Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community. -Why is it so special? -The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. -Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. -Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. - -include::sections/nutshell.asc[] - -include::sections/basic-branching-and-merging.asc[] - -include::sections/branch-management.asc[] - -include::sections/workflows.asc[] - -include::sections/remote-branches.asc[] - -include::sections/rebasing.asc[] - -=== Summary - -We've covered basic branching and merging in Git. -You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. -You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. -Next, we'll cover what you'll need to run your own Git repository-hosting server. diff --git a/book/03-git-branching/images/advance-master.png b/book/03-git-branching/images/advance-master.png deleted file mode 100644 index b789fedaf..000000000 Binary files a/book/03-git-branching/images/advance-master.png and /dev/null differ diff --git a/book/03-git-branching/images/advance-testing.png b/book/03-git-branching/images/advance-testing.png deleted file mode 100644 index 35d058119..000000000 Binary files a/book/03-git-branching/images/advance-testing.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-1.png b/book/03-git-branching/images/basic-branching-1.png deleted file mode 100644 index b49b9f4c3..000000000 Binary files a/book/03-git-branching/images/basic-branching-1.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-2.png b/book/03-git-branching/images/basic-branching-2.png deleted file mode 100644 index 329c9f529..000000000 Binary files a/book/03-git-branching/images/basic-branching-2.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-3.png b/book/03-git-branching/images/basic-branching-3.png deleted file mode 100644 index 688addacf..000000000 Binary files a/book/03-git-branching/images/basic-branching-3.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-4.png b/book/03-git-branching/images/basic-branching-4.png deleted file mode 100644 index c1f1f477a..000000000 Binary files a/book/03-git-branching/images/basic-branching-4.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-5.png b/book/03-git-branching/images/basic-branching-5.png deleted file mode 100644 index 1d4c06423..000000000 Binary files a/book/03-git-branching/images/basic-branching-5.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-branching-6.png b/book/03-git-branching/images/basic-branching-6.png deleted file mode 100644 index b93918b51..000000000 Binary files a/book/03-git-branching/images/basic-branching-6.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-merging-1.png b/book/03-git-branching/images/basic-merging-1.png deleted file mode 100644 index 08b923f37..000000000 Binary files a/book/03-git-branching/images/basic-merging-1.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-merging-2.png b/book/03-git-branching/images/basic-merging-2.png deleted file mode 100644 index b1c58b235..000000000 Binary files a/book/03-git-branching/images/basic-merging-2.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-rebase-1.png b/book/03-git-branching/images/basic-rebase-1.png deleted file mode 100644 index bc804f6af..000000000 Binary files a/book/03-git-branching/images/basic-rebase-1.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-rebase-2.png b/book/03-git-branching/images/basic-rebase-2.png deleted file mode 100644 index c75bf386c..000000000 Binary files a/book/03-git-branching/images/basic-rebase-2.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-rebase-3.png b/book/03-git-branching/images/basic-rebase-3.png deleted file mode 100644 index a18e34f91..000000000 Binary files a/book/03-git-branching/images/basic-rebase-3.png and /dev/null differ diff --git a/book/03-git-branching/images/basic-rebase-4.png b/book/03-git-branching/images/basic-rebase-4.png deleted file mode 100644 index 277b92572..000000000 Binary files a/book/03-git-branching/images/basic-rebase-4.png and /dev/null differ diff --git a/book/03-git-branching/images/branch-and-history.png b/book/03-git-branching/images/branch-and-history.png deleted file mode 100644 index ba2734e01..000000000 Binary files a/book/03-git-branching/images/branch-and-history.png and /dev/null differ diff --git a/book/03-git-branching/images/checkout-master.png b/book/03-git-branching/images/checkout-master.png deleted file mode 100644 index db052e6a4..000000000 Binary files a/book/03-git-branching/images/checkout-master.png and /dev/null differ diff --git a/book/03-git-branching/images/commit-and-tree.png b/book/03-git-branching/images/commit-and-tree.png deleted file mode 100644 index 65289ae8d..000000000 Binary files a/book/03-git-branching/images/commit-and-tree.png and /dev/null differ diff --git a/book/03-git-branching/images/commits-and-parents.png b/book/03-git-branching/images/commits-and-parents.png deleted file mode 100644 index e0c9bbea9..000000000 Binary files a/book/03-git-branching/images/commits-and-parents.png and /dev/null differ diff --git a/book/03-git-branching/images/head-to-master.png b/book/03-git-branching/images/head-to-master.png deleted file mode 100644 index 5086d0fb0..000000000 Binary files a/book/03-git-branching/images/head-to-master.png and /dev/null differ diff --git a/book/03-git-branching/images/head-to-testing.png b/book/03-git-branching/images/head-to-testing.png deleted file mode 100644 index 5422a8eda..000000000 Binary files a/book/03-git-branching/images/head-to-testing.png and /dev/null differ diff --git a/book/03-git-branching/images/interesting-rebase-1.png b/book/03-git-branching/images/interesting-rebase-1.png deleted file mode 100644 index 410287e6a..000000000 Binary files a/book/03-git-branching/images/interesting-rebase-1.png and /dev/null differ diff --git a/book/03-git-branching/images/interesting-rebase-2.png b/book/03-git-branching/images/interesting-rebase-2.png deleted file mode 100644 index ac2740809..000000000 Binary files a/book/03-git-branching/images/interesting-rebase-2.png and /dev/null differ diff --git a/book/03-git-branching/images/interesting-rebase-3.png b/book/03-git-branching/images/interesting-rebase-3.png deleted file mode 100644 index 91f46473f..000000000 Binary files a/book/03-git-branching/images/interesting-rebase-3.png and /dev/null differ diff --git a/book/03-git-branching/images/interesting-rebase-4.png b/book/03-git-branching/images/interesting-rebase-4.png deleted file mode 100644 index 89af34f5f..000000000 Binary files a/book/03-git-branching/images/interesting-rebase-4.png and /dev/null differ diff --git a/book/03-git-branching/images/interesting-rebase-5.png b/book/03-git-branching/images/interesting-rebase-5.png deleted file mode 100644 index 0bc02243e..000000000 Binary files a/book/03-git-branching/images/interesting-rebase-5.png and /dev/null differ diff --git a/book/03-git-branching/images/lr-branches-1.png b/book/03-git-branching/images/lr-branches-1.png deleted file mode 100644 index 3d26562ff..000000000 Binary files a/book/03-git-branching/images/lr-branches-1.png and /dev/null differ diff --git a/book/03-git-branching/images/lr-branches-2.png b/book/03-git-branching/images/lr-branches-2.png deleted file mode 100644 index acfb23dbd..000000000 Binary files a/book/03-git-branching/images/lr-branches-2.png and /dev/null differ diff --git a/book/03-git-branching/images/perils-of-rebasing-1.png b/book/03-git-branching/images/perils-of-rebasing-1.png deleted file mode 100644 index ce92ce97f..000000000 Binary files a/book/03-git-branching/images/perils-of-rebasing-1.png and /dev/null differ diff --git a/book/03-git-branching/images/perils-of-rebasing-2.png b/book/03-git-branching/images/perils-of-rebasing-2.png deleted file mode 100644 index e9b643fa3..000000000 Binary files a/book/03-git-branching/images/perils-of-rebasing-2.png and /dev/null differ diff --git a/book/03-git-branching/images/perils-of-rebasing-3.png b/book/03-git-branching/images/perils-of-rebasing-3.png deleted file mode 100644 index e049cbcd9..000000000 Binary files a/book/03-git-branching/images/perils-of-rebasing-3.png and /dev/null differ diff --git a/book/03-git-branching/images/perils-of-rebasing-4.png b/book/03-git-branching/images/perils-of-rebasing-4.png deleted file mode 100644 index 669fc8125..000000000 Binary files a/book/03-git-branching/images/perils-of-rebasing-4.png and /dev/null differ diff --git a/book/03-git-branching/images/perils-of-rebasing-5.png b/book/03-git-branching/images/perils-of-rebasing-5.png deleted file mode 100644 index 9ba974803..000000000 Binary files a/book/03-git-branching/images/perils-of-rebasing-5.png and /dev/null differ diff --git a/book/03-git-branching/images/remote-branches-1.png b/book/03-git-branching/images/remote-branches-1.png deleted file mode 100644 index 394234f05..000000000 Binary files a/book/03-git-branching/images/remote-branches-1.png and /dev/null differ diff --git a/book/03-git-branching/images/remote-branches-2.png b/book/03-git-branching/images/remote-branches-2.png deleted file mode 100644 index cd9e9d27e..000000000 Binary files a/book/03-git-branching/images/remote-branches-2.png and /dev/null differ diff --git a/book/03-git-branching/images/remote-branches-3.png b/book/03-git-branching/images/remote-branches-3.png deleted file mode 100644 index f2a2d1632..000000000 Binary files a/book/03-git-branching/images/remote-branches-3.png and /dev/null differ diff --git a/book/03-git-branching/images/remote-branches-4.png b/book/03-git-branching/images/remote-branches-4.png deleted file mode 100644 index 9047854e3..000000000 Binary files a/book/03-git-branching/images/remote-branches-4.png and /dev/null differ diff --git a/book/03-git-branching/images/remote-branches-5.png b/book/03-git-branching/images/remote-branches-5.png deleted file mode 100644 index 78b10d287..000000000 Binary files a/book/03-git-branching/images/remote-branches-5.png and /dev/null differ diff --git a/book/03-git-branching/images/topic-branches-1.png b/book/03-git-branching/images/topic-branches-1.png deleted file mode 100644 index 5463092b4..000000000 Binary files a/book/03-git-branching/images/topic-branches-1.png and /dev/null differ diff --git a/book/03-git-branching/images/topic-branches-2.png b/book/03-git-branching/images/topic-branches-2.png deleted file mode 100644 index 320e4e883..000000000 Binary files a/book/03-git-branching/images/topic-branches-2.png and /dev/null differ diff --git a/book/03-git-branching/images/two-branches.png b/book/03-git-branching/images/two-branches.png deleted file mode 100644 index 01b385c3f..000000000 Binary files a/book/03-git-branching/images/two-branches.png and /dev/null differ diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 7a8b8e093..ccaca50d7 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,31 +1,31 @@ -=== Basic Branching and Merging +=== Βασικές έννοιες διακλαδώσεων και συγχωνεύσεων -Let's go through a simple example of branching and merging with a workflow that you might use in the real world. -You'll follow these steps: +Ας δούμε ένα απλό παράδειγμα διακλάδωσης και συγχώνευσης με μία ροή εργασίας που είναι πιθανό να χρησιμοποιήσουμε στον πραγματικό κόσμο. +Θα ακολουθήσουμε τα παρακάτω βήματα: -. Do work on a web site. -. Create a branch for a new story you're working on. -. Do some work in that branch. +. Θα κάνουμε αλλαγές σε μία ιστοσελίδα. +. Θα δημιουργήσουμε έναν κλάδο για μία νέα ιστορία χρήστη (user story) την οποία δουλεύουμε. +. θα κάνουμε αλλαγές σε αυτό τον κλάδο. -At this stage, you'll receive a call that another issue is critical and you need a hotfix. -You'll do the following: +Σε αυτό το σημείο θα δεχτούμε ένα τηλεφώνημα ότι υπάρχει ένα άλλο κρίσιμο πρόβλημα και πρέπει να αναπτύξουμε μία άμεση λύση. +Θα κάνουμε τα παρακάτω: -. Switch to your production branch. -. Create a branch to add the hotfix. -. After it's tested, merge the hotfix branch, and push to production. -. Switch back to your original story and continue working. +. Θα μεταβούμε στον κλάδο παραγωγής. +. Θα δημιουργήσουμε έναν κλάδο στον οποίο θα προσθέσουμε την επείγουσα λυση (hotfix). +. Αφού ο κώδικάς μας δοκιμαστεί, θα συγχωνεύσουμε τον κλάδο με το hotfix και θα τον ωθήσουμε στην παραγωγή. +. Θα επιστρέψουμε στην αρχική ιστορία χρήστη και θα συνεχίσουμε να την δουλεύουμε. -[[_basic_branching]] -==== Basic Branching +[[r_basic_branching]] +==== Διακλαδώσεις -- τα βασικά -(((branches, basic workflow))) -First, let's say you're working on your project and have a couple of commits already. +(((κλάδοι, βασική ροή εργασίας))) +Αρχικά ας υποθέσουμε ότι δουλεύουμε σε ένα έργο και έχουμε κάνει ήδη μερικές υποβολές στον κλάδο `master`. -.A simple commit history -image::images/basic-branching-1.png[A simple commit history.] +.Ένα απλό ιστορικό υποβολών +image::images/basic-branching-1.png[Ένα απλό ιστορικό υποβολών] -You've decided that you're going to work on issue #53 in whatever issue-tracking system your company uses. -To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: +Αποφασίζουμε ότι θα δουλέψουμε στο πρόβλημα #53 του συστήματος παρακολούθησης προβλημάτων που χρησιμοποιεί η εταιρεία μας. +Για να δημιουργήσουμε έναν κλάδο και να μεταβούμε σε αυτό συγχρόνως, μπορούμε να τρέξουμε την εντολή `git checkout` με τη σημαία `-b`: [source,console] ---- @@ -33,7 +33,7 @@ $ git checkout -b iss53 Switched to a new branch "iss53" ---- -This is shorthand for: +Η παραπάνω εντολή είναι συντομογραφία για το εξής: [source,console] ---- @@ -41,29 +41,29 @@ $ git branch iss53 $ git checkout iss53 ---- -.Creating a new branch pointer -image::images/basic-branching-2.png[Creating a new branch pointer.] +.Δημιουργία νέου δείκτη σε κλάδο +image::images/basic-branching-2.png[Δημιουργία νέου δείκτη σε κλάδο] -You work on your web site and do some commits. -Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): +Επεξεργαζόμαστε την ιστοσελίδα μας και κάνουμε μερικές υποβολές. +Με τις υποβολές ο κλάδος `iss53` προχωρά, διότι τον έχουμε κάνει checkout (δηλαδή ο `HEAD` δείχνει σε αυτό τον κλάδο): [source,console] ---- $ vim index.html -$ git commit -a -m 'added a new footer [issue 53]' +$ git commit -a -m 'Create new footer [issue 53]' ---- -.The iss53 branch has moved forward with your work -image::images/basic-branching-3.png[The iss53 branch has moved forward with your work.] +.Ο κλάδος `iss53` προχώρησε εξαιτίας των αλλαγών μας. +image::images/basic-branching-3.png[Ο κλάδος `iss53` προχώρησε εξαιτίας των αλλαγών μας.] -Now you get the call that there is an issue with the web site, and you need to fix it immediately. -With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. -All you have to do is switch back to your `master` branch. +Τώρα λαμβάνουμε το τηλεφώνημα ότι υπάρχει ένα άλλο επείγον πρόβλημα στην ιστοσελίδα και πρέπει να το αντιμετωπίσουμε αμέσως. +Στο Git, δεν είναι απαραίτητο να δουλέψουμε σε αυτό το πρόβλημα παράλληλα με τις αλλαγές που έχουμε ήδη κάνει στον κλάδο `iss53`, ούτε να καταβάλλουμε πολλή δουλειά ώστε να αναιρέσουμε τις αλλαγές που έχουμε ήδη κάνει και να δουλέψουμε στο επείγον πρόβλημα και να εφαρμόσουμε τη λύση μας σε ό,τι βρίσκεται εκείνη τη στιγμή στη γραμμή της παραγωγής. +Το μόνο που έχουμε να κάνουμε είναι να επιστρέψουμε στον κλάδο `master`. -However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches. -It's best to have a clean working state when you switch branches. -There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <<_git_stashing>>. -For now, let's assume you've committed all your changes, so you can switch back to your master branch: +Ωστόσο πριν το κάνουμε αυτό, σημειώστε ότι αν υπάρχουν στον κατάλογο εργασίας μας ή στον προθάλαμο αλλάγες που δεν έχουν υποβληθεί και έρχονται σε σύγκρουση με τον κλάδο στον οποίο θέλουμε να μεταβούμε, το Git δεν θα μας αφήσει να αλλάξουμε κλάδο. +Το καλύτερο είναι να έχουμε μία καθαρή κατασταση εργασίας όταν μεταβαίνουμε από έναν κλάδο σε άλλο. +Υπάρχουν τρόποι να παρακάμψουμε αυτή τη συμπεριφορά (με τις εντολές `git stash` και `git commit --amend`) που θα καλύψουμε στη συνέχεια, στην ενότητα <>. +Προς το παρόν, ας υποθέσουμε ότι έχουμε υποβάλλει όλες τις αλλαγές μας, ώστε να μπορέσουμε να επιστρέψουμε στον κλάδο `master`: [source,console] ---- @@ -71,28 +71,28 @@ $ git checkout master Switched to branch 'master' ---- -At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. -This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. -It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. +Σε αυτό το σημείο, ο κατάλογος εργασίας του έργου μας βρίσκεται ακριβώς στην κατάσταση στην οποία βρισκόταν πριν ξεκινήσουμε να δουλεύουμε για το πρόβλημα #53 και μπορούμε να συγκεντρωθούμε στο hotfix. +Αυτό είναι ένα σημαντικό σημείο που αξίζει να θυμόμαστε: όταν μεταβαίνουμε από έναν κλάδο σε έναν άλλο, το Git επαναφέρει τον κατάλογο εργασίας στην κατάσταση που είχε την τελευταία φορά που είχαμε κάνει κάποια υποβολή (commit) σε αυτό τον κλάδο. +Προσθέτει, διαγράφει και τροποποιεί αρχεία αυτόματα ώστε να βεβαιωθεί ότι το αντίγραφο εργασίας μας είναι ίδιο με την κατάσταση του κλάδου αμέσως μετά την τελευταία υποβολή σε αυτό τον κλάδο. -Next, you have a hotfix to make. -Let's create a hotfix branch on which to work until it's completed: +Στη συνέχεια, πρέπει να δουλέψουμε για το hotfix. +Ας φτιάξουμε έναν κλάδο `hotfix` στον οποίο θα εργαστούμε: [source,console] ---- $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html -$ git commit -a -m 'fixed the broken email address' -[hotfix 1fb7853] fixed the broken email address +$ git commit -a -m 'Fix broken email address' +[hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+) ---- -.Hotfix branch based on `master` -image::images/basic-branching-4.png[Hotfix branch based on `master`.] +.Κλάδος hotfix που βασίζεται στον κλάδο `master` +image::images/basic-branching-4.png[Κλάδος `hotfix` που βασίζεται στον κλάδο `master`] -You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. -You do this with the `git merge` command:(((git commands, merge))) +Τώρα μπορούμε να κάνουμε τα τεστ μας, να βεβαιωθούμε ότι ο κώδικάς μας κάνει αυτό που θέλουμε, να τον συγχωνεύσουμε με τον κλάδο `master` και να τον προωθήσουμε στην παραγωγή. +Το τελευταίο το κάνουμε με την εντολή `git merge`:(((εντολές git, merge))) [source,console] ---- @@ -104,18 +104,18 @@ Fast-forward 1 file changed, 2 insertions(+) ---- -You'll notice the phrase ``fast-forward'' in that merge. -Because the commit pointed to by the branch you merged in was directly upstream of the commit you're on, Git simply moves the pointer forward. -To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward.'' +Σε αυτή τη συγχώνευση υπάρχει η έκφραση "`fast-forward`". +Επειδή η υποβολή `C4` στον οποίο έδειχνε ο κλάδος `hotfix` τον οποίο συγχωνεύσαμε ήταν ακριβώς μπροστά από την υποβολή `C2` στην οποία είμαστε, το Git απλά μετακίνησε τον δείκτη προς τα εμπρός. +Με άλλα λόγια όταν προσπαθούμε να συγχωνεύσουμε μία υποβολή με μία άλλη υποβολή στην οποία μπορούμε να φτάσουμε ακολουθώντας το ιστορικό της πρώτης, το Git απλοποιεί τη διαδικασία μετακινώντας τον δείκτη σε εκείνο το σημείο, διότι δεν υπάρχει άλλη αποκλίνουσα εργασία που θα πρέπει να συγχωνευτεί -- αυτό ονομάζεται "`ταχυπροώθηση`" ("`fast-forward`"). -Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. +Η αλλαγή μας τώρα υπάρχει στο στιγμιότυπο της υποβολής στην οποία δείχνει ο κλάδος `master` και μπορούμε να δημοσιεύσουμε τη διόρθωσή μας. -.`master` is fast-forwarded to `hotfix` -image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.] +.Ο κλάδος `master` ταχυπροωθήθηκε στον κλάδο `hotfix`. +image::images/basic-branching-5.png[Ο κλάδος `master` ταχυπροωθήθηκε στον κλάδο `hotfix`.] -After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted. -However, first you'll delete the `hotfix` branch, because you no longer need it – the `master` branch points at the same place. -You can delete it with the `-d` option to `git branch`: +Αφού ο σημαντικότατος διορθωτικός μας κώδικας έχει δημοσιευτεί, είμαστε έτοιμοι να επανέλθουμε στην εργασία την οποία κάναμε πριν μας διακόψει το τηλεφώνημα. +Προτού όμως συνεχίσουμε, θα διαγράψουμε τον κλάδο `hotfix`, διότι δεν τον χρειαζόμαστε πλέον -- ο κλάδος `master` δείχνει ακριβώς στην ίδια θέση. +Μπορούμε να τον διαγράψουμε με την επιλογή `-d` στην εντολή `git branch`: [source,console] ---- @@ -123,31 +123,31 @@ $ git branch -d hotfix Deleted branch hotfix (3a0874c). ---- -Now you can switch back to your work-in-progress branch on issue #53 and continue working on it. +Τώρα μπορούμε να επιστρέψουμε στον κλάδο εργασίας του προβλήματος #53 και να συνεχίσουμε να δουλεύουμε σ' αυτό. [source,console] ---- $ git checkout iss53 Switched to branch "iss53" $ vim index.html -$ git commit -a -m 'finished the new footer [issue 53]' -[iss53 ad82d7a] finished the new footer [issue 53] +$ git commit -a -m 'Finish the new footer [issue 53]' +[iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+) ---- -.Work continues on `iss53` -image::images/basic-branching-6.png[Work continues on `iss53`.] +.Η εργασία συνεχίζει στον κλάδο `iss53` +image::images/basic-branching-6.png[Η εργασία συνεχίζει στον κλάδο `iss53`] -It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. -If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. +Σε αυτό το σημείο αξίζει να σημειωθεί ότι οι αλλαγές που κάναμε στον κλάδο `hotfix` δεν περιέχονται στα αρχεία του κλάδου `iss53`. +Αν θέλουμε να τα ενσωματώσουμε, μπορούμε να συγχωνεύσουμε τον κλάδο `master` στον κλάδο `iss53` τρέχοντας την εντολή `git merge master` ή μπορούμε να αναβάλουμε την ενσωμάτωση αυτών των αλλαγών μέχρι να αποφασίσουμε να ξαναβάλουμε τον κλάδο `iss53` μέσα στον κλάδο `master` αργότερα. -[[_basic_merging]] -==== Basic Merging +[[r_basic_merging]] +==== Συγχωνεύσεις -- τα βασικά -(((branches, merging)))(((merging))) -Suppose you've decided that your issue #53 work is complete and ready to be merged into your `master` branch. -In order to do that, you'll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. -All you have to do is check out the branch you wish to merge into and then run the `git merge` command: +(((κλάδοι, συγχώνευση)))(((συγχώνευση)))(((branches, merging)))(((merging))) +Ας υποθέσουμε τώρα ότι έχουμε αποφασίσει ότι η εργασία μας για το πρόβλημα #53 έχει ολοκληρωθεί και είναι έτοιμη να συγχωνευτεί στον κλάδο `master`. +Για να το κάνουμε αυτό, αρκεί να συγχωνεύσουμε τον κλάδο `iss53` στον κλάδο `master`, λίγο-πολύ με τον ίδιο τρόπο που συγχωνεύσαμε τον κλάδο `hotfix` προηγουμένως. +Το μόνο που έχουμε να κάνουμε είναι να μεταβούμε στον κλάδο στον οποίο θέλουμε να ενσωματώσουμε τον άλλο κλάδο και να τρέξουμε την εντολή `git merge`: [source,console] ---- @@ -159,38 +159,35 @@ index.html | 1 + 1 file changed, 1 insertion(+) ---- -This looks a bit different than the `hotfix` merge you did earlier. -In this case, your development history has diverged from some older point. -Because the commit on the branch you're on isn't a direct ancestor of the branch you're merging in, Git has to do some work. -In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. +Το μήνυμα στην οθόνη διαφέρει λίγο από εκείνο που πήραμε όταν συγχωνεύσαμε τον κλάδο `hotfix` προηγουμένως. +Σε αυτή την περίπτωση, το ιστορικό των αλλαγών απέκλινε σε κάποιο παλιότερο σημείο. +Επειδή η υποβολή στον κλάδο στον οποίο βρίσκεστε δεν είναι άμεσος πρόγονος του κλάδου τον οποίο ενσωματώνουμε, το Git πρέπει να κάνει λίγη δουλίτσα. +Σε αυτή την περίπτωση, το Git κάνει μία απλή _τριμερή_ συγχώνευση, χρησιμοποιώντας τα στιγμιότυπα στο τέλος του κάθε κλάδου και τον κοινό πρόγονο των δύο. -.Three snapshots used in a typical merge -image::images/basic-merging-1.png[Three snapshots used in a typical merge.] +.Τρία στιγμιότυπα που χρησιμοποιούνται σε μία τυπική συγχώνευση +image::images/basic-merging-1.png[Τρία στιγμιότυπα που χρησιμοποιούνται σε μία τυπική συγχώνευση] -Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. -This is referred to as a merge commit, and is special in that it has more than one parent. +Αντί, λοιπόν, το Git να μετακινήσει τον δείκτη του κλάδου προς τα εμπρός, δημιουργεί ένα νέο στιγμιότυπο που προκύπτει από αυτή την τριμερή συγχώνευση και αυτομάτως δημιουργεί μία νέα υποβολή που δείχνει σε αυτό το στιγμιότυπο. +Αυτό ονομάζεται _υποβολή συγχώνευσης_ (merge commit) και έχει την ιδιαιτερότητα ότι έχει περισσότερους από έναν γονείς. -.A merge commit -image::images/basic-merging-2.png[A merge commit.] +.Μία υποβολή συγχώνευσης +image::images/basic-merging-2.png[Μία υποβολή συγχώνευσης] -It's worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than older tools like CVS or Subversion (before version 1.5), where the developer doing the merge had to figure out the best merge base for themselves. -This makes merging a heck of a lot easier in Git than in these other systems. - -Now that your work is merged in, you have no further need for the `iss53` branch. -You can close the ticket in your ticket-tracking system, and delete the branch: +Τώρα που η εργασία μας έχει συγχωνευτεί, δεν χρειαζόμαστε πλέον τον κλάδο `iss53`. +Μπορούμε να κλείσουμε το ζήτημα στο σύστημα παρακολούθησης προβλημάτων μας και να διαγράψουμε τον κλάδο: [source,console] ---- $ git branch -d iss53 ---- -[[_basic_merge_conflicts]] -==== Basic Merge Conflicts +[[r_basic_merge_conflicts]] +==== Συγκρούσεις συγχωνεύσεων -- τα βασικά -(((merging, conflicts))) -Occasionally, this process doesn't go smoothly. -If you changed the same part of the same file differently in the two branches you're merging together, Git won't be able to merge them cleanly. -If your fix for issue #53 modified the same part of a file as the `hotfix`, you'll get a merge conflict that looks something like this: +(((συγχώνευση, συγκρούσεις)))(((merging, conflicts))) +Ενίοτε, η διαδικασία συγχώνευσης δεν εξελίσσεται τόσο ομαλά. +Αν έχουμε τροποποιήσει το ίδιο σημείο του ίδιου αρχείου με διαφορετικό τρόπο στους δύο κλάδους που συγχωνεύουμε, το Git δεν θα μπορέσει να τους συγχωνεύσει παστρικά. +Αν η λύση μας για το πρόβλημα #53 και η λύση μας για το επείγον πρόβλημα τροποποίησαν το ίδιο τμήμα ενός αρχείου, θα πάρουμε ένα μήνυμα _σύγκρουσης συγχώνευσης_ περίπου σαν το παρακάτω: [source,console] ---- @@ -200,9 +197,9 @@ CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. ---- -Git hasn't automatically created a new merge commit. -It has paused the process while you resolve the conflict. -If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: +Το Git δεν μπόρεσε να δημιουργήσει αυτόματα μία νέα υποβολή συγχώνευσης. +Διέκοψε τη διαδικασία, ώστε να επιλύσουμε τη σύγκρουση. +Αν θέλουμε να δούμε ποια αρχεία δεν έχουν συγχωνευτεί σε οποιοδήπτε σημείο μετά από μία σύγκρουση συγχώνευσης, τρέχουμε την εντολή `git status`: [source,console] ---- @@ -219,9 +216,9 @@ Unmerged paths: no changes added to commit (use "git add" and/or "git commit -a") ---- -Anything that has merge conflicts and hasn't been resolved is listed as unmerged. -Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. -Your file contains a section that looks something like this: +Οτιδήποτε εμπλέκεται σε σύγκρουση συγχώνευσης και δεν έχει επιλυθεί καταγράφεται ως unmerged. +Το Git προσθέτει τυποποιημένους σημειωτές "`επίλυσης σύγκρουσης`" στα αρχεία που εμπλέκονται σε συγκρούσεις, ώστε να τα ανοίξουμε και να επιλύσουμε αυτές τις διαφορές. +Το αρχείο μας θα περιέχει ένα τμήμα που θα φαίνεται κάπως έτσι: [source,html] ---- @@ -234,9 +231,9 @@ Your file contains a section that looks something like this: >>>>>>> iss53:index.html ---- -This means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. -In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. -For instance, you might resolve this conflict by replacing the entire block with this: +Αυτό σημαίνει πως η έκδοση στο `HEAD` (δηλαδή το `master` κλάδο, γιατί σε αυτόν ήμασταν όταν τρέξαμε στην εντολή συγχώνευσης) είναι το πάνω μέρος του μπλόκ (οτιδήποτε πάνω από `=======`), ενώ η έκδοση του κλάδου `iss53` είναι ότι φαίνεται στο κάτω μέρος του μπλόκ. +Προκειμένου να επιλύσουμε τη σύγκρουση, πρέπει είτε να επιλέξουμε τη μία ή την άλλη έκδοση είτε να συγχωνεύσουμε τα περιεχόμενα οι ίδιοι. +Για παράδειγμα, μπορεί να θέλουμε να επιλύσουμε αυτή τη σύγκρουση αντικαθιστώντας ολόκληρο το τμήμα με το παρακάτω: [source,html] ---- @@ -245,11 +242,11 @@ please contact us at email.support@github.com ---- -This resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. -After you've resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. -Staging the file marks it as resolved in Git. +Αυτή η επίλυση της σύγκρουσης περιέχει λίγο από κάθε τμήμα και οι γραμμές που περιέχουν τα `<<<<<<<`, `=======` και `>>>>>>>` έχουν αφαιρεθεί εντελώς. +Αφού έχουμε επιλύσει όλα τα τμήματα σε κάθε αρχείο που εμπλέκεται σε σύγκρουση, τρέχουμε `git add` σε καθένα από αυτά τα αρχεία, ώστε να επισημανθεί ως επιλυμένο. +Αν το αρχείο περάσει στο στάδιο καταχώρησης, αυτό σημαίνει ότι έχει επιλυθεί. -If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:(((git commands, mergetool))) +Αν θέλουμε να χρησιμοποιήσουμε κάποιο γραφικό εργαλείο για να επιλύσουμε αυτές τις συγκρούσεις, τρέχουμε `git mergetool` για να εκκινήσουμε ένα κατάλληλο γραφικό εργαλείο συγχώνευσης που μας καθοδηγεί κατά την επίλυση των συγκρούσεων:(((εντολές git, mergetool))) [source,console] ---- @@ -268,17 +265,17 @@ Normal merge conflict for 'index.html': Hit return to start merge resolution tool (opendiff): ---- -If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on a Mac), you can see all the supported tools listed at the top after ``one of the following tools.'' -Just type the name of the tool you'd rather use. +Αν θέλουμε να χρησιμοποιήσουμε κάποιο εργαλείο συγχώνευσης διαφορετικό από το προεπιλεγμένο (το Git επέλεξε το `opendiff` σε αυτή την περίπτωση, διότι εκτελέσαμε την εντολή σε Mac), μπορούμε να δούμε όλα τα εργαλεία που υποστηρίζονται στο πάνω μέρος μετά από το "`one of the following tools.`" +Απλά γράφουμε το όνομα του εργαλείου που προτιμάμε. [NOTE] ==== -If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <<_advanced_merging>>. +Αν χρειάζεστε πιο προχωρημένα εργαλεία για να επιλύσετε περίπλοκες συγκρούσεις συγχωνεύσεων, θα μιλήσουμε σχετικά στην ενότητα <>. ==== -After you exit the merge tool, Git asks you if the merge was successful. -If you tell the script that it was, it stages the file to mark it as resolved for you. -You can run `git status` again to verify that all conflicts have been resolved: +Αφού βγούμε από το εργαλείο συγχώνευσης, το Git μας ρωτάει αν η συγχώνευση ήταν επιτυχής. +Αν του πούμε ότι ήταν, ωθεί το αρχείο στον προθάλαμο ώστε να επισημανθεί ως επιλυμένο. +Μπορούμε να τρέξουμε την εντολή `git status` ξανά για να επιβεβαιωθούμε ότι όλες οι συγκρούσεις έχουν επιλυθεί: [source,console] ---- @@ -292,8 +289,8 @@ Changes to be committed: modified: index.html ---- -If you're happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. -The commit message by default looks something like this: +Αν είμαστε ευχαριστημένοι με το αποτέλεσμα και επιβεβαιωθούμε ότι όλα τα αρχεία που εμπλέκονται σε συγκρούσεις έχουν τοποθετηθεί στο στάδιο καταχώρησης, μπορούμε να πληκτρολογήσουμε `git commit` για να οριστικοποιήσουμε την υποβολή συγχώνευσης. +Το μήνυμα υποβολής είναι εξ ορισμού κάπως έτσι: [source,console] ---- @@ -318,4 +315,4 @@ Conflicts: # ---- -You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future – why you did what you did, if it's not obvious. +Εφόσον θεωρούμε ότι θα είναι χρήσιμο σε όσους δουν αυτή τη συγχώνευση στο μέλλον, μπορούμε να τροποποιήσουμε αυτό το μήνυμα με λεπτομέρειες σχετικά με το πώς επιλύσαμε τη συγχώνευση και να εξηγήσουμε γιατί κάναμε ό,τι κάναμε, εφόσον δεν είναι προφανές. diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index a8776bb25..10e826e6b 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -1,11 +1,11 @@ -[[_branch_management]] -=== Branch Management +[[r_branch_management]] +=== Διαχείριση κλάδων -(((branches, managing))) -Now that you've created, merged, and deleted some branches, let's look at some branch-management tools that will come in handy when you begin using branches all the time. +(((κλάδοι, διαχείριση))) +Τώρα που έχουμε δημιουργήσει, συγχωνεύσει και διαγράψει μερικούς κλάδους, ας δούμε μερικά εργαλεία διαχείρισης κλάδων που θα μας είναι χρήσιμα όταν αρχίσουμε να χρησιμοποιούμε κλάδους συχνότερα. -The `git branch` command does more than just create and delete branches.(((git commands, branch))) -If you run it with no arguments, you get a simple listing of your current branches: +Η εντολή `git branch` εκτός από το να δημιουργεί και να διαγράφει κλάδους κάνει και κάποια άλλα πράγματα.(((εντολές git, branch))) +Αν την τρέξουμε χωρίς ορίσματα, τότε παίρνουμε μία λίστα όλων των κλάδων: [source,console] ---- @@ -15,20 +15,20 @@ $ git branch testing ---- -Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out (i.e., the branch that `HEAD` points to). -This means that if you commit at this point, the `master` branch will be moved forward with your new work. -To see the last commit on each branch, you can run `git branch -v`: +Ο χαρακτήρας `*` πριν από τον κλάδο `master` επισημαίνει ότι ο κλάδος αυτός είναι ο τρέχων κλάδος (δηλαδή ο κλάδος στον οποίο δείχνει ο δείκτης `HEAD`). +Αυτό σημαίνει ότι αν κάνουμε μία υποβολή σε αυτό το σημείο, ο κλάδος `master` θα προχωρήσει ώστε να συμπεριλάβει τη δουλειά μας. +Για να δούμε την τελευταία υποβολή του κάθε κλάδου μπορούμε να τρέξουμε την εντολή `git branch -v`: [source,console] ---- $ git branch -v - iss53 93b412c fix javascript issue + iss53 93b412c Fix javascript issue * master 7a98805 Merge branch 'iss53' - testing 782fd34 add scott to the author list in the readmes + testing 782fd34 Add scott to the author list in the readme ---- -The useful `--merged` and `--no-merged` options can filter this list to branches that you have or have not yet merged into the branch you're currently on. -To see which branches are already merged into the branch you're on, you can run `git branch --merged`: +Οι επιλογές `--merged` και `--no-merged` φιλτράρουν τη λίστα των κλάδων και δείχνουν μόνον όσους κλάδους έχουν συγχωνευτεί και αντίστοιχα δεν έχουν ακόμα συγχωνευτεί στον τρέχοντα κλάδο. +Για να δούμε ποιοι κλάδοι έχουν ήδη συγχωνευτεί στον τρέχοντα κλάδο, τρέχουμε την εντολή `git branch --merged`: [source,console] ---- @@ -37,10 +37,10 @@ $ git branch --merged * master ---- -Because you already merged in `iss53` earlier, you see it in your list. -Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you've already incorporated their work into another branch, so you're not going to lose anything. +Επειδή είχαμε ήδη συγχωνεύσει τον κλάδο `iss53` προηγουμένως, φαίνεται στη λίστα μας. +Γενικά είναι ασφαλές να διαγράψουμε τους κλάδους αυτής της λίστας που δεν έχουν το `*` χρησιμοποιώντας την εντολή `git branch -d`· έχουμε ήδη ενσωματώσει τις αλλαγές τους σε κάποιον άλλο κλάδο, συνεπώς δεν πρόκειται να χάσουμε τίποτα. -To see all the branches that contain work you haven't yet merged in, you can run `git branch --no-merged`: +Για να δούμε όλους τους κλάδους που περιέχουν εργασία που δεν έχουμε συγχωνεύσει σε κάποιον άλλο κλάδο ακόμα, μπορούμε να εκτελέσουμε την εντολή `git branch --no-merged`: [source,console] ---- @@ -48,8 +48,8 @@ $ git branch --no-merged testing ---- -This shows your other branch. -Because it contains work that isn't merged in yet, trying to delete it with `git branch -d` will fail: +Αυτή δείχνει τον άλλο μας κλάδο. +Επειδή αυτός ο κλάδος περιέχει εργασία που δεν έχει ακόμα συγχωνευτεί σε κάποιον άλλο κλάδο, αν αποπειραθούμε να τον διαγράψουμε με την εντολή `git branch -d` θα αποτύχει: [source,console] ---- @@ -58,4 +58,127 @@ error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. ---- -If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out. +Αν πραγματικά θέλουμε να διαγράψουμε έναν τέτοιο κλάδο και να χάσουμε τη δουλειά που περιέχει, μπορούμε να επιβάλουμε τη διαγραφή με την επιλογή `-D`, όπως υποδεικνύει και το παραπάνω μήνυμα. + +[TIP] +==== +Εφόσον δεν δώσετε το όνομα μίας υποβολής ή ενός κλάδου οι επιλογές `--merged` και `--no-merged` θα σας δείξουν τι έχει ή δεν έχει συγχωνευτεί, αντίστοιχα, στον _τρέχοντα_ κλάδο σας. + +Μπορείτε επίσης να δώσετε μία επιπρόσθετη παράμετρο για να ρωτήσετε την κατάσταση συγχώνευσης σε σχέση με κάποιον άλλο κλάδο χωρίς να έχετε μεταβεί σε αυτό τον κλάδο προηγουμένως, όπως για παράδειγμα, τι δεν έχει συγχωνευτεί στον κλάδο `master` ακόμα; + +[source,console] +---- +$ git checkout testing +$ git branch --no-merged master + topicA + featureB +---- +==== + +==== Μετονομασία κλάδου + +[CAUTION] +==== +Μην μετονομάζουμε κλάδους που χρησιμοποιούνται ακόμα από άλλους συνεργάτες. +Μην μετονομάζουμε κλάδους όπως τους master/main/mainline χωρίς να έχουμε διαβάσει την ενότητα <>. +==== + +Ας υποθέσουμε ότι έχουμε έναν κλάδο με το όνομα `bad-branch-name` και θέλουμε να το αλλάξουμε σε `corrected-branch-name`, διατηρώντας όλο το ιστορικό. +Επίσης θέλουμε να αλλάξουμε το όνομα του κλάδου στον απομακρυσμένο (GitHub, GitLab, ή άλλο) διακομιστή. +Πώς μπορούμε να το κάνουμε; + +Μετονομάζουμε τον κλάδο τοπικά με την εντολή `git branch --move`: + +[source, console] +---- +$ git branch --move bad-branch-name corrected-branch-name +---- + +Η εντολή αυτή αντικαθιστά το `bad-branch-name` με το `corrected-branch-name`, αλλά αυτή η αλλαγή προς το παρόν έχει γίνει μόνο τοπικά. +Για να δουν και οι άλλοι τον διορθωμένο κλάδο, πρέπει να τον ωθήσουμε: + +[source,console] +---- +$ git push --set-upstream origin corrected-branch-name +---- + +Ας δούμε τώρα που βρισκόμαστε: + +[source, console] +---- +$ git branch --all +* corrected-branch-name + main + remotes/origin/bad-branch-name + remotes/origin/corrected-branch-name + remotes/origin/main +---- + +Παρατηρήρουμε ότι βρίσκομαστε στον κλάδο `corrected-branch-name` και ότι επιπλέον είναι διαθέσιμος και στον απομακρυσμένο διακομιστή. +Όμως και ο κλάδος με το προηγούμενο λάθος όνομα υπάρχει ακόμα στον απομακρυσμένο διακομιστή, αλλά μπορούμε να τον διαγράψουμε εκτελώντας την ακόλουθη εντολη: + +[source,console] +---- +$ git push origin --delete bad-branch-name +---- + +Τώρα το παλιό όνομα κλάδου έχει αντικαταστεθί πλήρως από το διορθωμένο όνομα. + +[[r_changing_master]] +===== Αλλαγή του ονόματος του κύριου κλάδου + +[WARNING] +==== +Η μετονομασία των κλάδων όπως οι master/main/mainline/default θα διακόψει την αφομοίωση, τις υπηρεσίες, τα βοηθητικά προγράμματα και τα script μεγαλώττισης που χρησιμοποιεί το αποθετήριό μας. +Πριν το κάνουμε, οπωσδήποτε ενημερώνουμε τους συνεργάτες μας. +Επίσης, κάνουμε μια ενδελεχή αναζήτηση στο αποθετήριό μας και ενημερώνουμε αναφορές στο παλιό όνομα του κύριου κλάδου μας στον κώδικα και τα script μας. +==== + +Μπορούμε να μετονομάσουμε τον τοπικό μας κλάδο `master` σε `main` με την εξής εντολή: + +[source,console] +---- +$ git branch --move master main +---- + +Πλέον δεν υπάρχει τοπικός κλάδος `master`, διότι έχει μετονομαστεί σε `main`. + +Για να δουν και οι άλλοι τον κλάδο `main`, πρέπει να τον ωθήσουμε στον απομακρυσμένο διακομιστή. +Αυτό γίνεται με την εξής εντολή. + +[source,console] +---- +$ git push --set-upstream origin main +---- + +Έχουμε καταλήξει στην ακόλουθη κατάσταση: + +[source,console] +---- +$ git branch --all +* main + remotes/origin/HEAD -> origin/master + remotes/origin/main + remotes/origin/master +---- + +Ο τοπικός μας κλάδος `master` έχει εξαφανιστεί, αφού αντικαταστάθηκε από τον κλάδο `main`. +Ο κλάδος `main` υπάρχει στον απομακρυσμένο διακομιστή. +Όμως και ο κλάδος `master` υπάρχει ακόμα στον απομακρυσμένο διακομιστή. +Κάποιοι συνεργάτες μας θα συνεχίσουν να χρησιμοποιούν τον κλάδο `master` ως τον κύριο κλάδο τους, μέχρι να κάνουμε μερικές ακόμα αλλαγές. + +Πρέπει να κάνουμε μερικά ακόμα πράγματα ώστε να ολοκληρώσουμε τη μετάβαση: + +* Όσα έργα εξαρτώνται από αυτό, θα πρέπει να ενημερώσουν τον κώδικά τους ή/και την παραμετροποίησή τους. +* Ενημερώνουμε όποια αρχεία παραμετροποίησης test-runner έχουμε. +* Προσαρμόζουμε τα script build και release. +* Ενημερώνουμε ρυθμίσεις στον διακομιστή του αποθετηρίου μας όσον αφορά στον προεπιλεγμένο κλάδο, τους κανόνες συγχώνευσης και ό,τι άλλο χρησιμοποιεί ονόματα κλάδων. +* Ενημερώνουμε αναφορές στον παλιό όνομα στην τεκμηρίωση. +* Κλείνουμε ή συγχωνεεύουμε όσα αιτήματα ελκυσμού έχουν ως στόχο τον παλιό κλάδο. + +Αφού έχουμε κάνει όλα αυτά και είμαστε σίγουροι ότι ο κλάδος `main` αποδίδει όπως απέδιδε και ο κλάδος `master`, μπορούμε να διαγράψουμε τον κλάδο `master`: + +[source, console] +---- +$ git push origin --delete master +---- diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 3f24b3a06..d309633d9 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -1,182 +1,210 @@ -[[_git_branches_overview]] -=== Branches in a Nutshell +[[r_git_branches_overview]] +=== Οι κλάδοι με λίγα λόγια -To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. +Για να κατανοήσουμε πραγματικά τον τρόπο με τον οποίο το Git υλοποιεί τις διακλαδώσεις, πρέπει πρώτα να εξετάσουμε τον τρόπο με τον οποίο το Git αποθηκεύει τα δεδομένα. -As you may remember from <<_getting_started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots. +Όπως ίσως θυμόμαστε από την ενότητα <>, το Git δεν αποθηκεύει τα δεδομένα ως μία ακολουθία αλλαγών ή διαφορών αλλά ως μία ακολουθία _στιγμιότυπων_ (snapshots). -When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. -This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. +Όταν κάνουμε μία υποβολή (commit), το Git αποθηκεύει ένα αντικείμενο υποβολής που περιέχει έναν δείκτη προς το στιγμιότυπο του περιεχομένου που έχει υποβληθεί. +Αυτό το αντικείμενο περιέχει επίσης το όνομα και e-mail του συγγραφέα, το μήνυμα που έχουμε πληκτρολογήσει καθώς και δείκτες προς την υποβολή ή τις υποβολές που προηγήθηκαν ακριβώς πριν από αυτή την υποβολή (δηλαδή, τον γονέα ή τους γονείς της): όταν ένα αρχείο υποβάλλεται για πρώτη φορά, τότε δεν έχει κανέναν γονέα· μία συνηθισμένη υποβολή έχει έναν γονέα, ενώ μία υποβολή που προέκυψε από τη συγχώνευση δύο ή περισσότερων κλάδων έχει περισσότερους από έναν γονέα. -To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit. -Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: +Για να το οπτικοποιήσουμε λίγο, ας υποθέσουμε ότι έχουμε έναν κατάλογο που περιέχει τρία αρχεία, τα οποία έχουμε προσθέσει στο στάδιο καταχώρησης και στη συνέχεια υποβάλλουμε (commit). +Κατά την προσθήκη των αρχείων στο στάδιο καταχώρησης υπολογίζονται τα αθροίσματα ελέγχου (checksums) των αρχείων (με τον αλγόριθμο SHA-1, που αναφέρθηκε στην ενότητα <>), αποθηκεύονται οι συγκεκριμένες εκδόσεις των αρχείων στο αποθετήριο Git (το Git ονομάζει αυτές τις εκδόσεις _blobs_) και προσθέτει τα αθροίσματα ελέγχου στο στάδιο καταχώρησης. [source,console] ---- $ git add README test.rb LICENSE -$ git commit -m 'initial commit of my project' +$ git commit -m 'Initial commit' ---- -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. -Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit))) +Όταν κάνουμε την υποβολή, τρέχοντας την εντολή `git commit`, το Git υπολογίζει ένα άθροισμα ελέγχου για καθέναν υποκατάλογο (στη συγκεκριμένη περίπτωση μόνο για τον βασικό κατάλογο του έργου) και τους αποθηκεύει ως αντικείμενα δομής δένδρου στο αποθετήριο Git. +Στη συνέχεια το Git δημιουργεί ένα αντικείμενο υποβολής που περιέχει τα μεταδεδομένα και έναν δείκτη στη βάση του δένδρου του έργου, ώστε να μπορεί να επαναδημιουργήσει το στιγμιότυπο, όταν χρειαστεί.(((εντολές git, commit))) -Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. +Πλέον το αποθετήριό μας περιέχει πέντε αντικείμενα: τρία blob για τα περιεχόμενα των αρχείων (ένα blob για κάθε αρχείο), μία δομή δένδρου που καταγράφει τα περιεχόμενα του καταλόγου και προσδιορίζει ποιο αρχείο αντιστοιχίζεται σε ποιο blob και ένα αντικείμενο commit που περιέχει τον δείκτη στον βασικό κατάλογο και όλα τα μεταδεδομένα της υποβολής. -.A commit and its tree -image::images/commit-and-tree.png[A commit and its tree.] +.Μια υποβολή και το δένδρο της +image::images/commit-and-tree.png[Μια υποβολή και το δένδρο της] -If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. +Αν κάνουμε μερικές αλλαγές και τις υποβάλλουμε, η επόμενη υποβολή αποθηκεύει έναν δείκτη στην ακριβώς προηγούμενη υποβολή. -.Commits and their parents -image::images/commits-and-parents.png[Commits and their parents.] +.Υποβολές (commits) και οι γονείς τους. +image::images/commits-and-parents.png[Υποβολές (commits) και οι γονείς τους.] -A branch in Git is simply a lightweight movable pointer to one of these commits. -The default branch name in Git is `master`. -As you start making commits, you're given a master branch that points to the last commit you made. -Every time you commit, it moves forward automatically. +Οι κλάδοι του Git είναι απλά μετακινήσιμοι δείκτες σε υποβολές. +Το προεπιλεγμένο όνομα κλάδου στο Git είναι `master` (κύριος κλάδος). +Όταν ξεκινάμε να κάνουμε υποβολές, μας δίνεται ένας κλάδος `master` που δείχνει στην τελευταία υποβολή που κάναμε. +Κάθε φορά που υποβάλλουμε, ο κλάδος `master` προχωρά αυτόματα. [NOTE] ==== -The ``master'' branch in Git is not a special branch.(((master))) -It is exactly like any other branch. -The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it. +Ο κλάδος "`master`" στο Git δεν είναι κάποιος ειδικός κλάδος.(((master))) +Είναι ακριβώς το ίδιο με οποιονδήποτε άλλο κλάδο. +Ο μόνος λόγος για τον οποίο σχεδόν κάθε αποθετήριο έχει έναν κλάδο `master` είναι επειδή η εντολή `git init` τον ονομάζει έτσι και οι περισσότεροι χρήστες του Git δεν ασχολούνται με το να τον αλλάξουν. ==== -.A branch and its commit history -image::images/branch-and-history.png[A branch and its commit history.] +.Ένας κλάδος και το ιστορικό υποβολών του +image::images/branch-and-history.png[Ένας κλάδος και το ιστορικό υποβολών του] -[[_create_new_branch]] -==== Creating a New Branch +[[r_create_new_branch]] +==== Δημιουργία νέου κλάδου -(((branches, creating))) -What happens if you create a new branch? -Well, doing so creates a new pointer for you to move around. -Let's say you create a new branch called testing. -You do this with the `git branch` command:(((git commands, branch))) +(((κλάδοι, δημιουργία))) +Τι γίνεται όταν δημιουργούμε έναν νέο κλάδο; +Αυτό που συμβαίνει είναι ότι δημιουργείται ένα νέος δείκτης τον οποίο μπορούμε να μετακινούμε από δω κι από κει. +Ας πούμε ότι δημιουργούμε έναν νέο κλάδο που ονομάζεται `testing`. +Αυτό γίνεται με την εντολή `git branch`:(((εντολές git, branch))) [source,console] ---- $ git branch testing ---- -This creates a new pointer at the same commit you're currently on. +Αυτή η εντολή δημιουργεί έναν νέο δείκτη στην υποβολή στην οποία βρισκόμαστε αυτή τη στιγμή. -.Two branches pointing into the same series of commits -image::images/two-branches.png[Two branches pointing into the same series of commits.] +.Δύο κλάδοι που δείχνουν στην ίδια ακολουθία υποβολών +image::images/two-branches.png[Δύο κλάδοι που δείχνουν στην ίδια ακολουθία υποβολών] -How does Git know what branch you're currently on? -It keeps a special pointer called `HEAD`. -Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. -In Git, this is a pointer to the local branch you're currently on. -In this case, you're still on master. -The `git branch` command only _created_ a new branch – it didn't switch to that branch. +Πώς όμως γνωρίζει το Git σε ποιον κλάδο βρισκόμαστε τώρα; +Το γνωρίζει επειδή διατηρεί έναν ειδικό δείκτη που ονομάζεται `HEAD`. +Σημειώνουμε ότι αυτός ο δείκτης `HEAD` είναι πολύ διαφορετικός από την έννοια του `HEAD` με την οποία είμαστε ενδεχομένως εξοικειωμένοι σε άλλα VCS, όπως το Subversion ή το CVS. +Στο Git αυτός είναι ένας δείκτης στον τοπικό κλάδο στον οποίο στον οποίο βρισκόμαστε αυτή τη στιγμή. +Στη συγκεκριμένη περίπτωση, βρισκόμαστε ακόμα στον κλάδο `master`. +Η εντολή `git branch` απλά _δημιούργησε_ έναν νέο κλάδο -- δεν μετέβη σε αυτό τον κλάδο. -.HEAD pointing to a branch -image::images/head-to-master.png[HEAD pointing to a branch.] +.Ο δείκτης HEAD δείχνει σε έναν κλάδο +image::images/head-to-master.png[Ο δείκτης HEAD δείχνει σε έναν κλάδο] -You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. -This option is called `--decorate`. +Αυτό μπορούμε να το διαπιστώσουμε εύκολα τρέχοντας την εντολή `git log` που παραθέτει πού δείχνουν οι δείκτες των κλάδων. +Η επιλογή ονομάζεται`--decorate`, [source,console] ---- $ git log --oneline --decorate -f30ab (HEAD, master, testing) add feature #32 - ability to add new -34ac2 fixed bug #1328 - stack overflow under certain conditions -98ca9 initial commit of my project +f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface +34ac2 Fix bug #1328 - stack overflow under certain conditions +98ca9 Initial commit ---- -You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit. +Βλέπουμε τους κλάδους "`master`" και "`testing`" που βρίσκονται δίπλα στην υποβολή `f30ab`. -[[_switching_branches]] -==== Switching Branches +[[r_switching_branches]] +==== Μετάβαση σε άλλο κλάδο -(((branches, switching))) -To switch to an existing branch, you run the `git checkout` command.(((git commands, checkout))) -Let's switch to the new testing branch: +(((κλάδοι, μετάβαση))) +Για να μεταβούμε σε έναν ήδη υπάρχοντα κλάδο, τρέχουμε την εντολή `git checkout`.(((εντολές git, checkout))) +Ας μεταβούμε στον νέο κλάδο `testing`: [source,console] ---- $ git checkout testing ---- -This moves `HEAD` to point to the `testing` branch. +Η εντολή αυτή μετατοπίζει τον δείκτη `HEAD` ώστε να δείχνει στον κλάδο `testing`. -.HEAD points to the current branch -image::images/head-to-testing.png[HEAD points to the current branch.] +.Ο `HEAD` δείχνει στον τρέχοντα κλάδο. +image::images/head-to-testing.png[Ο `HEAD` δείχνει στον τρέχοντα κλάδο.] -What is the significance of that? -Well, let's do another commit: +Ποια είναι η σημασία αυτού του πράγματος; +Ας κάνουμε ακόμα μία υποβολή: [source,console] ---- $ vim test.rb -$ git commit -a -m 'made a change' +$ git commit -a -m 'Make a change' ---- -.The HEAD branch moves forward when a commit is made -image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.] +.Ο κλάδος `HEAD` μετακινείται ότι γίνεται μία υποβολή +image::images/advance-testing.png[Ο κλάδος `HEAD` μετακινείται ότι γίνεται μία υποβολή] -This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran `git checkout` to switch branches. -Let's switch back to the master branch: +Αυτό είναι ενδιαφέρον, διότι τώρα ο νέος μας κλάδος `testing` έχει προχωρήσει, αλλά ο κλάδος `master` ακόμα δείχνει στην υποβολή που βρισκόμασταν όταν είχαμε τρέξει την εντολή `git checkout` για να αλλάξουμε κλάδο. +Ας επιστρέψουμε στον κλάδο `master`: [source,console] ---- $ git checkout master ---- -.HEAD moves when you checkout -image::images/checkout-master.png[HEAD moves when you checkout.] - -That command did two things. -It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. -This also means the changes you make from this point forward will diverge from an older version of the project. -It essentially rewinds the work you've done in your testing branch so you can go in a different direction. - [NOTE] -.Switching branches changes files in your working directory +.Η εντολή `git log` δεν δείχνει _όλους_ τους κλάδους _πάντα_ ==== -It's important to note that when you switch branches in Git, files in your working directory will change. -If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. -If Git cannot do it cleanly, it will not let you switch at all. +Αν εκτελούσατε `git log` τώρα, θα αναρωτιόσασταν πού πήγε ο κλάδος "testing" που μόλις δημιουργήσατε, αφού δεν θα εμφανιζόταν στην έξοδο της εντολής. + +Ο κλάδος δεν έχει εξαφανιστεί· το Git δεν γνωρίζει ότι ενδιαφέροσαστε για αυτόν τον κλάδο και προσπαθεί να σας δείξει μόνο αυτό για το οποίο νομίζει ότι σας ενδιαφέρει. +Με άλλα λόγια, εξ ορισμού, η `git log` θα σας δείξει το ιστορικό υποβολών του κλάδου τον οποίο έχουμε κάνει checked out. + +Για να δείτε όλο το ιστορικό υποβολών για τον κλάδο που θέλουμε, πρέπει να το πούμε ρητά: `git log testing`. +Για να δείτε το ιστορικό όλων των κλάδων, προσθέστε και το `--all` στην εντολή `git log`. ==== -Let's make a few changes and commit again: +.Ο δείκτης `HEAD` μετακινείται όταν εκτελούμε checkout +image::images/checkout-master.png[Ο δείκτης `HEAD` μετακινείται όταν εκτελούμε checkout] + +Αυτή η εντολή έκανε δύο πράγματα: +Μετατόπισε τον δείκτη `HEAD` ώστε να ξαναδείχνει στον κλάδο `master` και επανέφερε τα αρχεία στον τρέχοντα κατάλογο στο στιγμιότυπο που δείχνει ο κλάδος `master'. +Αυτό σημαίνει επίσης ότι όποιες αλλαγές κάνουμε από αυτό το σημείο και μετά θα αποκλίνουν από μια παλιότερη έκδοση του έργου. +Ουσιαστικά αναιρεί όποιες αλλαγές έχουμε κάνει στον κλάδο `testing` ώστε να μπορέσουμε να κινηθούμε σε μία διαφορετική κατεύθυνση. + +[NOTE] +.Η μετάβαση από έναν κλάδο σε άλλον αλλάζει τα αρχεία στον κατάλογο εργασίας +=== +Είναι σημαντικό να τονιστεί ότι όταν μετακινείστε από έναν κλάδο σε άλλο στο Git, τα αρχεία στον τρέχοντα κατάλογο αλλάζουν. +Αν μεταβείτε σε κάποιον παλιότερο κλάδο, ο τρέχων κατάλογος θα επαναφερθεί στην κατάσταση στην οποία βρισκόταν την τελευταία φορά που είχατε κάνει κάποια υποβολή σε αυτό τον κλάδο. +Αν το Git δεν μπορεί να το κάνει χωρίς προβλήματα, δεν θα σας επιτρέψει να μεταβείτε σε αυτό τον κλάδο. +=== + +Ας κάνουμε μερικές ακόμα αλλαγές και να τις υποβάλλουμε: [source,console] ---- $ vim test.rb -$ git commit -a -m 'made other changes' +$ git commit -a -m 'Make other changes' ---- -Now your project history has diverged (see <>). -You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. -Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you're ready. -And you did all that with simple `branch`, `checkout`, and `commit` commands. +Τώρα το ιστορικό του έργου έχει αποκλίνει (βλ. <>). +Δημιουργήσαμε έναν κλάδο, μεταβήκαμε σε αυτόν, κάναμε κάποιες αλλαγές και μετά επιστρέψαμε στον κύριο κλάδο μας και κάναμε κάποιες άλλες αλλαγές. +Οι αλλαγές αυτές είναι απομονωμένες σε διαφορετικούς κλάδους: μπορούμε να μεταπηδούμε από τον έναν κλάδο στον άλλο και να τους συγχωνεύσουμε όταν είμαστε έτοιμοι. +Και όλα αυτά τα καταφέρνουμε με απλές εντολές `branch`, `checkout` και `commit`. -[[divergent_history]] -.Divergent history -image::images/advance-master.png[Divergent history.] +[[rdivergent_history]] +.Αποκλίνον ιστορικό +image::images/advance-master.png[Αποκλίνον ιστορικό] -You can also see this easily with the `git log` command. -If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. +Αυτό μπορούμε επίσης να το δούμε εύκολα με την εντολή `git log`. +Αν εκτελέσουμε την εντολή `git log --oneline --decorate --graph --all` θα εκτυπωθεί το ιστορικό των υποβολών στο οποίο θα φαίνεται πού βρίσκονται οι δείκτες των κλάδων μας και με ποιον τρόπο έχει αποκλίνει το ιστορικό. [source,console] ---- $ git log --oneline --decorate --graph --all -* c2b9e (HEAD, master) made other changes -| * 87ab2 (testing) made a change +* c2b9e (HEAD, master) Make other changes +| * 87ab2 (testing) Make a change |/ -* f30ab add feature #32 - ability to add new formats to the -* 34ac2 fixed bug #1328 - stack overflow under certain conditions -* 98ca9 initial commit of my project +* f30ab Add feature #32 - ability to add new formats to the central interface +* 34ac2 Fix bug #1328 - stack overflow under certain conditions +* 98ca9 Initial commit of my project ---- -Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. -Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). +Επειδή ένας κλάδος στο Git είναι στην πραγματικότητα ένα αρχείο που περιέχει τους 40 χαρακτήρες του αθροίσματος ελέγχου SHA-1 της υποβολής στην οποία δείχνει, η δημιουργία και καταστροφή κλάδων είναι μία φθηνή διαδικασία. +Η δημιουργία ενός κλάδου είναι τόσο γρήγορη και απλή όσο το να γράφονται 41 byte σε ένα αρχείο (40 αλφαριθμητικοί χαρακτήρες και ένας χαρακτήρας αλλαγής γραμμής). + +Αυτή είναι μία σημαντική διαφορά σε σχέση με τον τρόπο με τον οποίο τα περισσότερα παλιότερα VCS δημιουργούν κλάδους, που περιλαμβάνει την αντιγραφή όλων των αρχείων του έργου σε έναν άλλο κατάλογο. +Αυτό μπορεί να διαρκέσει αρκετά δευτερόλεπτα ή ακόμα και λεπτά, ανάλογα με το μέγεθος του έργου, ενώ στο Git η διαδικασία είναι σχεδόν στιγμιαία. +Επιπλέον, επειδή σε κάθε υποβολή καταγράφονται οι γονείς της, η εύρεση μίας κατάλληλης βάσης για συγχώνευση γίνεται αυτόματα και γενικά πολύ εύκολα. +Αυτά τα χαρακτηριστικά ενθαρρύνουν τους προγραμματιστές να δημιουργούν και να χρησιμοποιούν κλάδους συχνά. -This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project's files into a second directory. -This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. -Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. -These features help encourage developers to create and use branches often. +Ας δούμε γιατί πρέπει να το κάνουμε αυτό. -Let's see why you should do so. +[NOTE] +.Δημιουργία κλάδου και μετάβαση σε αυτόν με τη μία +==== +Είναι σύνηθες όταν δημιουργείτε έναν κλάδο να θέλετε να μεταβείτε σε αυτόν άμεσα -- αυτό μπορεί να γίνει με την εκτέλεση μίας μόνο εντολής, της `git checkout -b `. +==== + +[NOTE] +==== +Από την έκδοση 2.23 του Git και μετά, μπορείτε να χρησιμοποιήσετε την `git switch` αντί για `git checkout` ώστε: + +- Να μεταβείτε σε έναν προϋπάρχοντα κλάδο: `git switch testing-branch`. +- Να δημιουργήσετε έναν νέο κλάδο και να μεταβείτε σε αυτόν: `git switch -c new-branch`. + Η σημαία `-c` σημαίνει create, μπορείτε επίσης να χρησιμοποιήσετε την πλήρη σημαία: `--create`. +- Να επιστρέψετε στον αμέσως προηγούμενο κλάδο που είχατε κάνει checkout: `git switch -`. +==== diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index dc9308ac6..8e7e6dce3 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -1,28 +1,29 @@ -[[_rebasing]] -=== Rebasing +[[r_rebasing]] +=== Αλλαγή βάσης (rebasing) -(((rebasing))) -In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. -In this section you'll learn what rebasing is, how to do it, why it's a pretty amazing tool, and in what cases you won't want to use it. +(((επανατοποθέτηση)))(((αλλαγή βάσης)))(((rebasing))) +Στο Git, υπάρχουν δύο βασικοί τρόποι ενσωμάτωσης αλλαγών από έναν κλάδο σε έναν άλλο: με την εντολή `merge` και την εντολή `rebase` (αλλαγή βάσης). +Σε αυτή την ενότητα θα μάθουμε τι είναι η αλλαγή βάσης, πώς την κάνουμε, γιατί θεωρείται εκπληκτικό εργαλείο και σε ποιες περιπτώσεις δεν πρέπει να τη χρησιμοποιούμε. -==== The Basic Rebase +==== Η βασική μορφή αλλαγής βάσης -If you go back to an earlier example from <<_basic_merging>>, you can see that you diverged your work and made commits on two different branches. +Εάν επιστρέψουμε σε ένα παλαιότερο παράδειγμα από την ενότητα <>, θα δούμε ότι η δουλειά μας είχε αποκλίνει και είχαμε κάνει υποβολές σε δύο διαφορετικούς κλάδους. -.Simple divergent history -image::images/basic-rebase-1.png[Simple divergent history.] +.Απλό αποκλίνον ιστορικό +image::images/basic-rebase-1.png[Απλό αποκλίνον ιστορικό] -The easiest way to integrate the branches, as we've already covered, is the `merge` command. -It performs a three-way merge between the two latest branch snapshots (`C3` and `C4`) and the most recent common ancestor of the two (`C2`), creating a new snapshot (and commit). +Ο ευκολότερος τρόπος ενσωμάτωσης των κλάδων, όπως έχουμε ήδη δει, είναι η εντολή `merge` (συγχώνευση). +Επιτελεί μια τριμερή συγχώνευση μεταξύ των δύο τελευταίων στιγμιότυπων διακλάδωσης (`C3` και`C4`) και του πιο πρόσφατου κοινού προγόνου τους (`C2`), δημιουργώντας ένα νέο στιγμιότυπο (και μία νέα υποβολή). -.Merging to integrate diverged work history -image::images/basic-rebase-2.png[Merging to integrate diverged work history.] +[[r_rebasing-merging-example]] +.Συγχώνευση και ενσωμάτωση αποκλίνοντος ιστορικού εργασίας +image::images/basic-rebase-2.png[Συγχώνευση και ενσωμάτωση αποκλίνοντος ιστορικού εργασίας] -However, there is another way: you can take the patch of the change that was introduced in `C4` and reapply it on top of `C3`. -In Git, this is called _rebasing_. -With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.(((git commands, rebase))) +Ωστόσο, υπάρχει κι ένας άλλος τρόπος: μπορούμε να πάρουμε μόνον το επίθεμα (patch) με τις τροποποιήσεις που εισήχθησαν με την υποβολή `C4` και να το εφαρμόσουμε ξανά στο στιγμιότυπο `C3`. +Στο Git, αυτό ονομάζεται _αλλαγή βάσης_ ή _επανατοποθέτηση_ (rebasing). +Με την εντολή `rebase` παίρνουμε όλες τις αλλαγές που υποβλήθηκαν σε ένα κλάδο και να τις επαναλαμβάνουμε σε έναν άλλο.(((εντολές git, rebase))) -In this example, you'd run the following: +Για αυτό το παράδειγμα, πρώτα θα κάνουμε checkout τον κλάδο `experiment` και στη συνέχεια θα τον επανατοποθετούσαμε στον κλάδο `master` (δηλαδή, θα αλλάζαμε τη βάση του από την υποβολή `C2` στην υποβολή που δείχνει ο κλάδος `master`) ως εξής: [source,console] ---- @@ -32,12 +33,12 @@ First, rewinding head to replay your work on top of it... Applying: added staged command ---- -It works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. +Η διαδικασία που ακολουθείται με την εντολή `rebase` είναι η εξής: μεταβαίνει στον κοινό πρόγονο των δύο κλάδων (εκείνου στον οποίο βρισκόμαστε και εκείνου ο οποίος θα γίνει η νέα βάση), παίρνει τις διαφορές (diff) που εισάγονται από κάθε υποβολή του κλάδου στον οποίο βρισκόμαστε, αποθηκεύει αυτές τις διαφορές σε προσωρινά αρχεία, μετατοπίζει τον τρέχοντα κλάδο στην ίδια υποβολή στην οποία βρίσκεται και ο κλάδος ο οποίος θα γίνει η νέα βάση και, τέλος, εφαρμόζει τις αλλαγές τη μία μετά την άλλη διαδοχικά. -.Rebasing the change introduced in `C4` onto `C3` -image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.] +.Αλλαγή της βάσης των τροποποιήσεων της `C4` από τη `C2` στη `C3` +image::images/basic-rebase-3.png[Αλλαγή της βάσης των τροποποιήσεων της `C4` από τη `C2` στη `C3`] -At this point, you can go back to the master branch and do a fast-forward merge. +Σε αυτό το σημείο, μπορούμε να επιστρέψουμε στον κλάδο `master` και να κάνουμε μία συγχώνευση με ταχυπροώθηση. [source,console] ---- @@ -45,47 +46,47 @@ $ git checkout master $ git merge experiment ---- -.Fast-forwarding the master branch -image::images/basic-rebase-4.png[Fast-forwarding the master branch.] +.Ταχυπροώθηση του κλάδου `master` +image::images/basic-rebase-4.png[Ταχυπροώθηση του κλάδου `master`] -Now, the snapshot pointed to by `C4'` is exactly the same as the one that was pointed to by `C5` in the merge example. -There is no difference in the end product of the integration, but rebasing makes for a cleaner history. -If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. +Πλέον το στιγμιότυπο στο οποίο δείχνει η υποβολή `C4'` είναι ακριβώς ίδιο με αυτό στο οποίο δείχνει η `C5` στο παλιότερο <>. +Το τελικό προϊόν της ενσωμάτωσης των αλλαγών είναι ακριβώς το ίδιο, αλλά η αλλαγή της βάσης κρατά το ιστορικό πιο καθαρό. +Αν εξετάσουμε το log ενός επανατοποθετημένου (σε νέα βάση) κλάδου, φαίνεται σαν το ιστορικό να είναι γραμμικό, δηλαδή σαν όλη η εργασία να συνέβη ακολουθιακά παρά το ότι αρχικά γινόταν παράλληλα. -Often, you'll do this to make sure your commits apply cleanly on a remote branch – perhaps in a project to which you're trying to contribute but that you don't maintain. -In this case, you'd do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. -That way, the maintainer doesn't have to do any integration work – just a fast-forward or a clean apply. +Συχνά θα κάνουμε κάτι τέτοιο για να βεβαιωθούμε ότι οι υποβολές μας εφαρμόζονται χωρίς συγκρούσεις σε έναν απομακρυσμένο κλάδο -- ενδεχομένως σε ένα έργο στο οποίο συμβάλλουμε, αλλά δεν το διαχειριζόμαστε. +Σε μία τέτοια περίπτωση, θα κάνουμε τη δουλειά μας σε έναν κλάδο και στη συνέχεια θα αλλάζαμε τη βάση (επανατοποθετούσαμε) της εργασίας μας στον κλάδο `origin/master` όταν ήμασταν έτοιμοι να υποβάλλουμε τα επιθέματά μας στο κύριο έργο. +Με αυτό τον τρόπο, ο διαχειριστής του έργου δεν χρειάζεται να κάνει καμία εργασία ενσωμάτωσης -- απλά μια ταχυπροώθηση ή μια καθαρή εφαρμογή. -Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it's only the history that is different. -Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. +Σημειώνουμε ότι το στιγμιότυπο στο οποίο δείχνει η υποβολή στην οποία καταλήγουμε, είναι το ίδιο είτε πρόκειται για την τελευταία από τις επανατοποθετημένες υποβολές μετά από αλλαγή βάσης είτε για την τελική υποβολή συγχώνευσης μετά από μία συγχώνευση -- το μόνο που είναι διαφορετικό είναι το ιστορικό. +Η αλλαγή βάσης εφαρμόζει τις τροποποιήσεις μίας γραμμής εργασίας σε μία άλλη με τη σειρά που έγιναν, ενώ η συγχώνευση παίρνει τα τελικά στιγμιότυπα και τα συγχωνεύει. -==== More Interesting Rebases +==== Μερικές ενδιαφέρουσες αλλαγές βάσης -You can also have your rebase replay on something other than the rebase target branch. -Take a history like <>, for example. -You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. -Then, you branched off that to make the client-side changes (`client`) and committed a few times. -Finally, you went back to your server branch and did a few more commits. +Μπορούμε επίσης να επανατοποθετήσουμε έναν κλάδο πάνω σε κάποιον κλάδο διαφορετικό από αυτόν στον οποίο βασιζόταν αρχικά. +Για παράδειγμα, ας πάρουμε ένα ιστορικό όπως αυτό στο <>. +Έχουμε δημιουργήσει έναν θεματικό κλάδο (`server`) για να προσθέσουμε κάποια λειτουργικότητα από την πλευρά του διακομιστή στο έργο μας και πραγματοποιήσαμε μια υποβολή. +Στη συνέχεια, δημιουργήσαμε μία ακόμα διακλάδωση για να κάνουμε τις αλλαγές από την πλευρά του πελάτη (`client`) και κάνουμε επίσης μερικές υποβολές. +Τέλος, επιστρέψαμε στον κλάδο `server` και κάνουμε μερικές ακόμη υποβολές. -[[rbdiag_e]] -.A history with a topic branch off another topic branch -image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch.] +[[rrbdiag_e]] +.Ιστορικό με έναν θεματικό κλάδο που βασίζεται σε έναν άλλο θεματικό κλάδο +image::images/interesting-rebase-1.png[Ιστορικό με έναν θεματικό κλάδο που βασίζεται σε έναν άλλο θεματικό κλάδο] -Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it's tested further. -You can take the changes on client that aren't on server (`C8` and `C9`) and replay them on your master branch by using the `--onto` option of `git rebase`: +Ας υποθέσουμε ότι αποφασίζουμε να συγχωνεύσουμε τις αλλαγές από την πλευρά του πελάτη στην κεντρική γραμμή που θα δημοσιευτεί, αλλά θέλουμε να αναβάλλουμε τις αλλαγές από την πλευρά του διακομιστή μέχρι να εξεταστούν περαιτέρω. +Μπορούμε να πάρουμε τις αλλαγές από τον κλάδο `client` που δεν βρίσκονται στον κλάδο `server` (`C8` και`C9`) και να τις αναπαράγουμε στον κύριο κλάδο μας χρησιμοποιώντας την επιλογή `--onto` της `git rebase`: [source,console] ---- $ git rebase --onto master server client ---- -This basically says, ``Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.'' -It's a bit complex, but the result is pretty cool. +Αυτή η εντολή ουσιαστικά λέει, "`Πήγαινε στον κλάδο `client`, εντόπισε τα επιθέματα από τότε που απέκλινε από τον κλάδο `server` και εφάρμοσέ τα στον κλάδο `client` σαν ο κλάδος `client` να ήταν κλάδος που απέκλινε από τον κλάδο `master``". +Είναι λίγο περίπλοκο, αλλά το αποτέλεσμα είναι μια ομορφιά. -.Rebasing a topic branch off another topic branch -image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch.] +.Αλλαγή βάσης ενός θεματικού κλάδου που βασίζεται σε έναν άλλο θεματικό κλάδο +image::images/interesting-rebase-2.png[Αλλαγή βάσης ενός θεματικού κλάδου που βασίζεται σε έναν άλλο θεματικό κλάδο] -Now you can fast-forward your master branch (see <>): +Τώρα μπορούμε να ταχυπροωθήσουμε τον κλάδο `master` (βλ. <>): [source,console] ---- @@ -93,25 +94,25 @@ $ git checkout master $ git merge client ---- -[[rbdiag_g]] -.Fast-forwarding your master branch to include the client branch changes -image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.] +[[rrbdiag_g]] +.Ταχυπροώθηση του κλάδου `master` ώστε να συμπεριλάβει τις αλλαγές του κλάδου `client` +image::images/interesting-rebase-3.png[Ταχυπροώθηση του κλάδου `master` ώστε να συμπεριλάβει τις αλλαγές του κλάδου `client`] -Let's say you decide to pull in your server branch as well. -You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` – which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`): +Ας πούμε ότι τώρα αποφασίζουμε να ενσωματώσουμε και τις αλλάγες του κλάδου `server`. +Μπορούμε να αλλάξουμε τη βάση του κλάδου `server` (στον κλάδο `master`), χωρίς να έχουμε προηγουμένως μεταβεί σε αυτόν, εκτελώντας την εντολή `git rebase ` -- η οποία μας μεταφέρει στον θεματικό κλάδο (σε αυτή την περίπτωση, τον `server`) και εφαρμόζει τις αλλαγές του στη νέα βάση (`master`) συγχρόνως: [source,console] ---- $ git rebase master server ---- -This replays your `server` work on top of your `master` work, as shown in <>. +Το αποτέλεσμα της παραπάνω εντολής φαίνεται στην <>. -[[rbdiag_h]] -.Rebasing your server branch on top of your master branch -image::images/interesting-rebase-4.png[Rebasing your server branch on top of your master branch.] +[[rrbdiag_h]] +.Αλλαγή της βάσης του κλάδου `server` στον κλάδο `master` +image::images/interesting-rebase-4.png[Αλλαγή της βάσης του κλάδου `server` στον κλάδο `master`] -Then, you can fast-forward the base branch (`master`): +Στη συνέχεια μπορούμε να ταχυπροωθήσουμε τον κλάδο-βάση (`master`): [source,console] ---- @@ -119,7 +120,7 @@ $ git checkout master $ git merge server ---- -You can remove the `client` and `server` branches because all the work is integrated and you don't need them anymore, leaving your history for this entire process looking like <>: +Μπορούμε να αφαιρέσουμε τους κλάδους `client` και `server` επειδή όλη δουλειά μας έχει ενσωματωθεί και δεν τους χρειάζόμαστε πια, κάνοντας το ιστορικό μας, μετά από όλη αυτή τη διαδικασία, να μοιάζει με το <>: [source,console] ---- @@ -127,110 +128,113 @@ $ git branch -d client $ git branch -d server ---- -[[rbdiag_i]] -.Final commit history -image::images/interesting-rebase-5.png[Final commit history.] +[[rrbdiag_i]] +.Τελικό ιστορικό υποβολών +image::images/interesting-rebase-5.png[Τελικό ιστορικό υποβολών] -[[_rebase_peril]] -==== The Perils of Rebasing +[[r_rebase_peril]] +==== Οι κίνδυνοι της αλλαγής βάσης -(((rebasing, perils of))) -Ahh, but the bliss of rebasing isn't without its drawbacks, which can be summed up in a single line: +(((αλλαγή βάσης, κίνδυνοι))) +Όμως η ευδαιμονία που μας προσφέρει η αλλαγή βάσης έχει κάποιο αντίτιμο, το οποίο μπορεί να συνοψιστεί σε μία γραμμή: -**Do not rebase commits that exist outside your repository.** +*Δεν αλλάζουμε τη βάση υποβολών που υπάρχουν εκτός του αποθετηρίου μας και κάποια άτομα έχουν δουλέψει πάνω σε αυτά.* -If you follow that guideline, you'll be fine. -If you don't, people will hate you, and you'll be scorned by friends and family. +Αν ακολουθήσουμε αυτή τη συμβουλή, θα είστε μια χαρά. +Αν δεν το κάνουμε, θα γίνουμε μισητοί σε όλη την οικουμένη και θα μας περιφρονήσουν φίλοι και συγγενείς. -When you rebase stuff, you're abandoning existing commits and creating new ones that are similar but different. -If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours. +Όταν αλλάζουμε τη βάση ενός κλάδου, εγκαταλείπουμε τις υπάρχουσες υποβολές και δημιουργούμε νέες που είναι παρόμοιες μεν, διαφορετικές δε. +Εάν ωθήσουμε υποβολές κάπου και άλλοι τις τραβήξουν και βασίσουν τη δουλειά τους σε αυτές και στη συνέχεια ξαναγράψουμε αυτές τις υποβολές με την `git rebase` και τις ωθήσουμε ξανά, οι συνεργάτες μας θα πρέπει να ξανασυγχωνεύσουν τη δουλειά τους και τα πράγματα θα μπλέξουν όταν προσπαθήσουμε να έλξουμε τη δουλειά τους στη δική μας. -Let's look at an example of how rebasing work that you've made public can cause problems. -Suppose you clone from a central server and then do some work off that. -Your commit history looks like this: +Ας δούμε ένα παράδειγμα με το οποίο η αλλαγή της βάσης κάποιας εργασίας που έχουμε ήδη κοινοποιήσει σε άλλους μπορεί να προκαλέσει προβλήματα. +Ας υποθέσουμε ότι κλωνοποιούμε από έναν κεντρικό διακομιστή και στη συνέχεια κάνουμε κάποιες αλλαγές. +Το ιστορικό της υποβολής μας μοιάζει με αυτό: -.Clone a repository, and base some work on it -image::images/perils-of-rebasing-1.png["Clone a repository, and base some work on it."] +.Κλωνοποίηση αποθετηρίου και επεξεργασία του +image::images/perils-of-rebasing-1.png["Κλωνοποίηση αποθετηρίου και επεξεργασία του"] -Now, someone else does more work that includes a merge, and pushes that work to the central server. -You fetch it and merge the new remote branch into your work, making your history look something like this: +Τώρα, κάποιος άλλος κάνει και άλλη δουλειά που περιλαμβάνει συγχώνευση και ωθεί τη δουλειά του στον κεντρικό διακομιστή. +Την ανακτούμε και συγχωνεύουμε τον νέο απομακρυσμένο κλάδο στη δουλειά μας, κάνοντας το ιστορικό μας να μοιάζει με αυτό: -.Fetch more commits, and merge them into your work -image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work."] +.Ανάκτηση περισσότερων υποβολών και συγχώνευσή τους στην εργασία μας +image::images/perils-of-rebasing-2.png[Ανάκτηση περισσότερων υποβολών και συγχώνευσή τους στην εργασία μας] -Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. -You then fetch from that server, bringing down the new commits. +Στη συνέχεια, αυτός που ώθησε τη συγχωνευμένη δουλειά αποφασίζει να επιστρέψει και να αλλάξει τη βάση της εργασίας του· κάνει `git push --force` για να επανεγγράψει το ιστορικό στον διακομιστή. +Στη συνέχεια, ανακτούμε από τον διακομιστή και φέρνουμε τις νέες υποβολές. -[[_pre_merge_rebase_work]] -.Someone pushes rebased commits, abandoning commits you've based your work on -image::images/perils-of-rebasing-3.png["Someone pushes rebased commits, abandoning commits you've based your work on."] +[[r_pre_merge_rebase_work]] +.Κάποιος ωθεί επανατοποθετημένες υποβολές, εγκαταλείποντας τις υποβολές στις οποίες έχουμε βασίσει τη δουλειά μας +image::images/perils-of-rebasing-3.png["Κάποιος ωθεί επανατοποθετημένες υποβολές, εγκαταλείποντας τις υποβολές στις οποίες έχουμε βασίσει τη δουλειά μας"] -Now you're both in a pickle. -If you do a `git pull`, you'll create a merge commit which includes both lines of history, and your repository will look like this: +Τώρα έχουμε μπλέξει άσχημα. +Εάν κάνουμε `git pull`, θα δημιουργήσουμε μια υποβολή συγχώνευσης που συμπεριλαμβάνει και τις δύο γραμμές του ιστορικού και το αποθετήριό μας θα μοιάζει με αυτό: -[[_merge_rebase_work]] -.You merge in the same work again into a new merge commit -image::images/perils-of-rebasing-4.png[You merge in the same work again into a new merge commit.] +[[r_merge_rebase_work]] +.Συγχώνευση της ίδιας εργασίας σε μία νέα υποβολή συγχώνευσης +image::images/perils-of-rebasing-4.png[Συγχώνευση της ίδιας εργασίας σε μία νέα υποβολή συγχώνευσης] -If you run a `git log` when your history looks like this, you'll see two commits that have the same author, date, and message, which will be confusing. -Furthermore, if you push this history back up to the server, you'll reintroduce all those rebased commits to the central server, which can further confuse people. -It's pretty safe to assume that the other developer doesn't want `C4` and `C6` to be in the history; that's why they rebased in the first place. +Αν το ιστορικό μας μοιάζει με το παραπάνω και τρέξουμε `git log`, θα δούμε δύο υποβολές που έχουν τον ίδιο συγγραφέα, ημερομηνία και μήνυμα, κάτι που μπορεί να προκαλέσει σύγχυση. +Επιπλέον, αν ωθήσουμε αυτό το ιστορικό πίσω στον διακομιστή, θα επαναφέρουμε όλες εκείνες τις επανατοποθετημένες υποβολές στον κεντρικό εξυπηρετητή, κάτι που θα μπερδέψει ακόμα περισσότερο τους υπόλοιπους. +Είναι αρκετά σίγουρο ότι ο άλλος προγραμματιστής δεν θέλει οι `C4` και `C6` να βρίσκονται στο ιστορικό· άλλωστε αυτός είναι ο λόγος για τον οποίο έκανε την αλλαγή της βάσης. -[[_rebase_rebase]] -==== Rebase When You Rebase +[[r_rebase_rebase]] +==== Επανατοποθέτηση σε επανατοποθετημένες υποβολές -If you *do* find yourself in a situation like this, Git has some further magic that might help you out. -If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten. +Αν παρόλα αυτά, *όντως* βρεθούμε σε μια τέτοια κατάσταση, το Git διαθέτει κάποια μαγικά κόλπα που θα μπορούν να μας βοηθήσουν. +Εάν κάποιος από την ομάδα μας ωθεί εξαναγκαστικά αλλαγές που επανεγγράφουν εργασία στην οποία βασίσαμε τη δική μας δουλειά, το πρόβλημά μας ανάγεται στο να εντοπίσουμε τι είναι δικό μας και τι έχει ξαναγραφτεί από αυτό. -It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. -This is called a ``patch-id''. +Το Git εκτός από το άθροισμα ελέγχου SHA-1 υπολογίζει επίσης ένα άθροισμα ελέγχου που βασίζεται ακριβώς στο επίθεμα που εισήχθη με την υποβολή. +Αυτό ονομάζεται "`patch-id`" (ταυτότητα επιθέματος). -If you pull down work that was rewritten and rebase it on top of the new commits from your partner, Git can often successfully figure out what is uniquely yours and apply them back on top of the new branch. +Αν τραβήξουμε εργασία που ξαναγράφτηκε και αλλάξουμε τη βάση του δικού μας κλάδου ώστε αυτός να βασίζεται πάνω στις νέες υποβολές του συνεργάτη μας, το Git μπορεί συχνά να καταλάβει ποιες αλλαγές είναι μόνο δικές μας και να τις εφαρμόσει ξανά στον νέο κλάδο. -For instance, in the previous scenario, if instead of doing a merge when we're at <<_pre_merge_rebase_work>> we run `git rebase teamone/master`, Git will: +Για παράδειγμα, αν στο προηγούμενο σενάριο, όταν βρισκόμαστε στο <> αντί να κάνουμε συγχώνευση, τρέξουμε `git rebase teamone/master`, το Git: -* Determine what work is unique to our branch (C2, C3, C4, C6, C7) -* Determine which are not merge commits (C2, C3, C4) -* Determine which have not been rewritten into the target branch (just C2 and C3, since C4 is the same patch as C4') -* Apply those commits to the top of `teamone/master` +* Θα προσδιορίσει ποια δουλειά βρίσκεται μόνον στον κλάδο μας (`C2`, `C3`, `C4`, `C6`, `C7`) +* Θα προσδιορίσει ποιες υποβολές δεν είναι υποβολές συγχώνευσης (`C2`, `C3`, `C4`) +* Θα προσδιορίσει ποιες υποβολές δεν έχουν ξαναγραφτεί στον κλάδο στόχο (μόνο οι `C2` και `C3`, δεδομένου ότι η `C4` είναι το ίδιο επίθεμα με την `C4'`) +* Θα εφαρμόσει αυτές τις υποβολές στον κλάδο `teamone/master`. -So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>. +Έτσι, αντί για το αποτέλεσμα που βλέπουμε στην <>, θα καταλήγαμε σε κάτι που μοιάζει πιο πολύ με την <>. -[[_rebase_rebase_work]] -.Rebase on top of force-pushed rebase work. -image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.] +[[r_rebase_rebase_work]] +.Επανατοποθέτηση πάνω σε εξαναγκασμένα επανατοποθετημένη εργασία +image::images/perils-of-rebasing-5.png[Επανατοποθέτηση πάνω σε εξαναγκασμένα επανατοποθετημένη εργασία] -This only works if C4 and C4' that your partner made are almost exactly the same patch. -Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there). +Αυτό θα έχει το επιθυμητό αποτέλεσμα μόνον εάν οι `C4` και `C4'` που έφτιαξε ο συνεργάτης μας είναι σχεδόν ακριβώς το ίδιο επίθεμα. +Διαφορετικά, η `git rebase` δεν θα είναι σε θέση να καταλάβει ότι πρόκειται για ουσιαστικά την ίδια υποβολή και θα προσθέσει ένα ακόμη επίθεμα παρόμοιο με το `C4` (το οποίο πιθανότατα θα αποτύχει να εφαρμοστεί χωρίς συγκρούσεις, αφού οι αλλαγές θα έχουν, τουλάχιστον εν μέρει, εφαρμοστεί ήδη). -You can also simplify this by running a `git pull --rebase` instead of a normal `git pull`. -Or you could do it manually with a `git fetch` followed by a `git rebase teamone/master` in this case. +Μπορούμε επίσης να απλοποιήσουμε τη διαδικασία τρέχοντας μία `git pull --rebase` αντί για κανονικό `git pull`. +Ή θα μπορούσαμε να το κάνουμε χειροκίνητα με μία `git fetch` ακολουθούμενο από μία `git rebase teamone/master` στη συγκεκριμένη περίπτωση. -If you are using `git pull` and want to make `--rebase` the default, you can set the `pull.rebase` config value with something like `git config --global pull.rebase true`. +Εάν χρησιμοποιούμε την `git pull` και θέλουμε να κάνουμε `--rebase` την προεπιλογή, μπορούμε να ορίσουμε την τιμή της παραμέτρου `pull.rebase` με κάτι σαν `git config --global pull.rebase true`. -If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you'll be fine. -If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates. +Αν αλλάζουμε τη βάση υποβολών που δεν έχουν φύγει ποτέ από τον υπολογιστή μας, δεν θα έχουμε προβλήματα. +Εάν αλλάζουμε τη βάση υποβολών που έχουν ήδη ωθηθεί, αλλά κανένας άλλος δεν έχει εργαστεί στις δικές μας υποβολές, επίσης δεν θα έχουμε πρόβλημα. +Εάν αλλάζουμε τη βάση υποβολών που έχουν ήδη ωθηθεί δημοσίως και κάποιοι άλλοι έχουν βασίσει μέρος της εργασίας τους σε αυτές τις υποβολές, τότε μπορεί να αντιμετωπίσουμε προβλήματα που θα προκαλέσουν στους συνεργάτες μας αγανάκτηση και περιφρόνηση προς το πρόσωπό μας. -If you or a partner does find it necessary at some point, make sure everyone knows to run `git pull --rebase` to try to make the pain after it happens a little bit simpler. +Αν αυτό θεωρηθεί απαραίτητο σε κάποιο σημείο, θα πρέπει να βεβαιωθούμε ότι όλοι έχουν ενημερωθεί να εκτελέσουν την `git pull --rebase` ώστε να καταπραΰνουμε λίγο τον πόνο που θα ακολουθήσει. -==== Rebase vs. Merge +==== Σύγκριση αλλαγής βάσης και συγχώνευσης -(((rebasing, vs. merging)))(((merging, vs. rebasing))) -Now that you've seen rebasing and merging in action, you may be wondering which one is better. -Before we can answer this, let's step back a bit and talk about what history means. +(((αλλαγή βάσης, σύγκριση με συγχώνευση)))(((συγχώνευση, σύγκριση με αλλαγή βάσης)))(((επανατοποθέτηση, σύγκριση με συγχώνευση)))(((συγχώνευση, σύγκριση με επανατοποθέτηση)))(((rebasing, vs. merging)))(((merging, vs. rebasing))) +Τώρα που έχουμε δει την αλλαγή βάσης και τη συγχώνευση σε δράση, ίσως να αναρωτηθούμε ποια διαδικασία είναι καλύτερη. +Πριν απαντήσουμε σε αυτό το ερώτημα, ας θυμηθούμε τι ακριβώς είναι το ιστορικό. -One point of view on this is that your repository's commit history is a *record of what actually happened.* -It's a historical document, valuable in its own right, and shouldn't be tampered with. -From this angle, changing the commit history is almost blasphemous; you're _lying_ about what actually transpired. -So what if there was a messy series of merge commits? -That's how it happened, and the repository should preserve that for posterity. +Μια θεώρηση του πράγματος είναι ότι το ιστορικό των υποβολών του αποθετηρίου μας είναι *καταγραφή όσων πραγματικά συνέβησαν*. +Είναι ένα ιστορικό έγγραφο, πολύτιμο από μόνο του και δεν πρέπει να παραβιάζεται. +Από αυτή τη σκοπιά, η αλλαγή του ιστορικού των υποβολών αποτελεί σχεδόν βλασφημία· λέμε _ψέματα_ για το τι συνέβη πραγματικά. +Τι γίνεται, λοιπόν, αν υπάρχει μια μπουρδουκλωμένη σειρά υποβολών συγχώνευσης; +Αυτός είναι ο τρόπος με τον οποίο συνέβησαν και το αποθετήριο πρέπει να τη διατηρήσει για πάντα. -The opposing point of view is that the commit history is the *story of how your project was made.* -You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing. -This is the camp that uses tools like rebase and filter-branch to tell the story in the way that's best for future readers. +Η αντίθετη άποψη είναι ότι το ιστορικό της υποβολής είναι η *ένα αφήγημα του πώς έγινε το έργο μας*. +Δεν θα δημοσιεύαμε το προσχέδιο ενός βιβλίου, οπότε γιατί να δείξουμε όλη την τσαπατσούλικη δουλειά; +Όταν εργάζομαστε σε ένα έργο, ίσως χρειαστούμε μια καταγραφή όλων λανθασμένων βημάτων και των αδιεξόδων, αλλά όταν φτάνει η ώρα να δείξουμε τη δουλειά μας στον υπόλοιπο κόσμο, ίσως θέλουμε να πούμε μια πιο συνεκτική ιστορία του πώς πήγαμε από το Α στο Β. +Όσοι βρίσκονται σε αυτό το στρατόπεδο χρησιμοποιούν εργαλεία όπως `rebase` και `filter-branch` για να ξαναγράψουν τις υποβολές τους πριν αυτές συγχωνευτούν στον κύριο κλάδο. +Χρησιμοποιούν εργαλεία όπως `rebase` και `filter-branch` για να αφηγηθούν την ιστορία με τρόπο που είναι ο καλύτερος για τους μελλοντικούς αναγνώστες. -Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple. -Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different. -Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation. +Τώρα, στο ερώτημα τι είναι καλύτερο, η συγχώνευση ή αλλαγή βάσης; Ας ελπίσουμε ότι βλέπετε ότι η απάντηση δεν είναι τόσο απλή. +Το Git είναι ένα ισχυρό εργαλείο και μας επιτρέπει να κάνουμε πολλά πράγματα στο ιστορικό ή με το ιστορικό, αλλά κάθε ομάδα και κάθε έργο είναι διαφορετικά. +Εφόσον γνωρίζουμε πώς λειτουργούν και οι δύο αυτές διαδικασίες, μπορούμε να αποφασίσουμε ποια είναι η καλύτερη σε κάθε περίσταση. -In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere. +Μπορούμε να συνδυάσουμε και τα δύο: να επανατοποθετούμε τοπικές αλλαγές που δεν έχουμε κοινοποιήσει σε άλλους, προκειμένου να καθαρίσουμε το ιστορικό μας, αλλά ποτέ να μην επανατοποθετούμε τίποτα που έχουμε ήδη ωθήσει κάπου. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index a1f5cc494..e4993e77c 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -1,71 +1,71 @@ -[[_remote_branches]] -=== Remote Branches +[[r_remote_branches]] +=== Απομακρυσμένοι κλάδοι -(((branches, remote)))(((references, remote))) -Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. -You can get a full list of remote references explicitly with `git ls-remote (remote)`, or `git remote show (remote)` for remote branches as well as more information. -Nevertheless, a more common way is to take advantage of remote-tracking branches. +(((κλάδοι, απομακρυσμένοι)))(((αναφορές, απομακρυσμένες))) +Οι απομακρυσμένες αναφορές είναι αναφορές (δείκτες) που βρίσκονται στα απομακρυσμένα αποθετήριά μας και συμπεριλαμβάνουν κλάδους, ετικέτες και ούτω καθεξής. +Μπορούμε να πάρουμε μία πλήρη λίστα των απομακρυσμένων αναφορών με την εντολή `git ls-remote ` ή `git remote show ` για απομακρυσμένους κλάδους καθώς και άλλες πληροφορίες. +Παρόλα αυτά, ένας πιο συνηθισμένος τρόπος είναι να εκμεταλλευτούμε τους κλάδους απομακρυσμένης παρακολούθησης (remote-tracking branches). -Remote-tracking branches are references to the state of remote branches. -They're local references that you can't move; they're moved automatically for you whenever you do any network communication. -Remote-tracking branches act as bookmarks to remind you where the branches in your remote repositories were the last time you connected to them. +Οι κλάδοι απομακρυσμένης παρακολούθησης είναι αναφορές στην κατάσταση απομακρυσμένων κλάδων. +Είναι τοπικές αναφορές τις οποίες δεν μπορούμε να μετακινήσουμε· μετακινούνται αυτόματα όποτε υπάρχει κάποια δικτυακή επικοινωνία, ώστε να διασφαλίζεται η ακριβής αναπαράσταση της κατάστασης του απομακρυσμένου αποθετηρίου. +Μπορούμε να τους σκέφτομαστε ως σελιδοδείκτες που μας θυμίζουν πού βρίσκονταν οι κλάδοι στα απομακρυσμένα αποθετήριά μας την τελευταία φορά που είχαμε συνδεθεί σε αυτά. -They take the form `(remote)/(branch)`. -For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. -If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`. +Έχουν τη μορφή `<απομακρυσμένο-αποθετήριο>/<κλάδος>` (`/`). +Για παράδειγμα, αν θέλουμε να δούμε σε ποια κατάσταση ήταν ο κλάδος `master` στο απομακρυσμένο αποθετήριό μας `origin` την τελευταία φορά που επικοινωνήσαμε μαζί του, θα πρέπει να μεταβούμε στον κλάδο `origin/master`. +Αν δουλεύαμε σε ένα θέμα με κάποιον συνεργάτη και αυτός είχε ωθήσει έναν κλάδο `iss53`, ενδεχομένως να είχαμε κι εμείς έναν δικό μας τοπικό κλάδο `iss53`, αλλά ο κλάδος στον διακομιστή θα αναπαρίστατο με τον κλάδο απομακρυσμένης παρακολούθησης `origin/iss53`. -This may be a bit confusing, so let's look at an example. -Let's say you have a Git server on your network at `git.ourcompany.com`. -If you clone from this, Git's `clone` command automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally. -Git also gives you your own local `master` branch starting at the same place as origin's `master` branch, so you have something to work from. +Ίσως όλα αυτά φαίνονται συγκεχυμένα, οπότε ας τα ξεμπερδέψουμε με ένα παράδειγμα. +Ας υποθέσουμε ότι έχουμε έναν διακομιστή Git στο δίκτυό μας στη διεύθυνση `git.ourcompany.com`. +Αν τον κλωνοποιήσουμε, η εντολή `clone` του Git θα τον ονομάσει `origin`, θα τραβήξει όλα τα δεδομένα και θα δημιουργήσει έναν δείκτη που δείχνει εκεί όπου βρίσκεται ο κλάδος του `master` και θα τον ονομάσει τοπικά `origin/master`. +Το Git επίσης θα δημιουργήσει έναν τοπικό κλάδο `master` για εμάς, ώστε να έχουμε έναν κλάδο στον οποίο μπορούμε να δουλέψουμε. Αυτός ο κλάδος ξεκινά από το ίδιο σημείο από όπου ξεκινά και ο κλάδος `master` του αποθετηρίου `origin`. [NOTE] -.``origin'' is not special ==== -Just like the branch name ``master'' does not have any special meaning in Git, neither does ``origin''. -While ``master'' is the default name for a starting branch when you run `git init` which is the only reason it's widely used, ``origin'' is the default name for a remote when you run `git clone`. -If you run `git clone -o booyah` instead, then you will have `booyah/master` as your default remote branch.(((origin))) +.Το αποθετήριο "`origin`" δεν είναι κάτι ιδιαίτερο +Ακριβώς όπως το όνομα κλάδου "`master`" δεν έχει κάποια ιδιαίτερη σημασία στο Git, το ίδιο συμβαίνει και με το όνομα κλάδου "`origin`". +Ενώ "`master`" είναι το προεπιλεγμένο όνομα για τον αρχικό κλάδο όταν τρέχετε την εντολή `git init` (που είναι και ο μόνος λόγος για τον οποίο χρησιμοποιείται τόσο ευρέως), "`origin`" είναι το προεπιλεγμένο όνομα για ένα απομακρυσμένο αποθετήριο όταν τρέχετε `git clone`. +Αν τρέξετε `git clone -o booyah` τότε θα έχετε ως προεπιλεγμένο απομακρυσμένο κλάδο τον `booyah/master`.(((origin))) ==== -.Server and local repositories after cloning -image::images/remote-branches-1.png[Server and local repositories after cloning.] +.Τοπικά και απομακρυσμένα αποθετήρια μετά την κλωνοποίηση +image::images/remote-branches-1.png[Τοπικά και απομακρυσμένα αποθετήρια μετά την κλωνοποίηση] -If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its `master` branch, then your histories move forward differently. -Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn't move. +Αν κάνουμε λίγη δουλίτσα στον τοπικό μας κλάδο `master` και στο μεταξύ κάποιος άλλος ωθήσει στο `git.ourcompany.com` και ενημερώσει τον κλάδο `master`, τότε τα δύο ιστορικά θα προχωρήσουν διαφορετικά. +Επιπλέον, για όσο χρονικό διάστημε δεν είμαστε συνδεδεμένοι με τον διακομιστή `origin`, ο δείκτης μας `origin/master` δεν μετακινείται. -.Local and remote work can diverge -image::images/remote-branches-2.png[Local and remote work can diverge.] +.Η τοπική και απομακρυσμένη δουλειά μπορεί να αποκλίνουν +image::images/remote-branches-2.png[Η τοπική και απομακρυσμένη δουλειά μπορεί να αποκλίνουν] -To synchronize your work, you run a `git fetch origin` command. -This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position. +Για να συγχρονίσουμε τη δουλειά μας με κάποιο απομακρυσμένο αποθετήριο, τρέχουμε την εντολή `git fetch ` (στην περίπτωσή μας `git fetch `). +Αυτή η εντολή αναζητά ποιος διακομιστής είναι ο "`origin`" (στη συγκεκριμένη περίπτωση είναι ο `git.ourcompany.com`), ανακτά (fetch) από αυτόν ό,τι δεδομένα δεν έχουμε ακόμα και ενημερώνει την τοπική βάση δεδομένων μας, μετακινώντας τον δείκτη `origin/master` στη νέα του πιο ενημερωμένη θέση. -.`git fetch` updates your remote references -image::images/remote-branches-3.png[`git fetch` updates your remote references.] +.Η εντολή `git fetch` ενημερώνει τους κλάδους απομακρυσμένης παρακολούθησης +image::images/remote-branches-3.png[Η εντολή `git fetch` ενημερώνει τους κλάδους απομακρυσμένης παρακολούθησης] -To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let's assume you have another internal Git server that is used only for development by one of your sprint teams. -This server is at `git.team1.ourcompany.com`. -You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <<_git_basics_chapter>>. -Name this remote `teamone`, which will be your shortname for that whole URL. +Για να δείξουμε τι συμβαίνει όταν έχουμε πολλούς απομακρυσμένους διακομιστές και με τι μοιάζουν οι απομακρυσμένοι κλάδοι των απομακρυσμένων έργων, ας υποθέσουμε ότι έχουμε ένα άλλο εσωτερικό διακομιστή Git που χρησιμοποιείται μόνον για ανάπτυξη κώδικα από μία συγκεκριμένη ομάδα. +Αυτός ο διακομιστής βρίσκεται στη διεύθυνση `git.team1.ourcompany.com`. +Μπορούμε να τον προσθέσουμε στο έργο στο οποίο δουλεύουμε ως μία νέα απομακρυσμένη αναφορά εκτελώντας την εντολή `git remote add` όπως εξηγήσαμε στο κεφάλαιο <>. +Ονομάστε αυτό τον απομακρυσμένο διακομιστή `teamone`, που θα είναι και το σύντομο όνομα του παραπάνω URL. -.Adding another server as a remote -image::images/remote-branches-4.png[Adding another server as a remote.] +.Προσθήκη ενός επιπλέον απομακρυσμένου διακομιστή +image::images/remote-branches-4.png[Προσθήκη ενός επιπλέον απομακρυσμένου διακομιστή] -Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don't have yet. -Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote-tracking branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch. +Τώρα μπορούμε να τρέξουμε την εντολή `git fetch teamone` για να ανακτήσουμε οτιδήποτε ο απομακρυσμένος διακομιστής `teamone` έχει που δεν το έχουμε ακόμα εμείς. +Επειδή ο διακομιστής έχει ένα υποσύνολο από τα δεδομένα που έχει ο διακομιστής `origin` αυτή τη στιγμή, το Git δεν ανακτά δεδομένα, αλλά τοποθετεί έναν κλάδο απομακρυσμένης παρακολούθησης με όνομα `teamone/master` να δείχνει στην υποβολή που έχει ο `teamone` στον δικό του κλάδο `master`. -.Remote tracking branch for `teamone/master` -image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.] +.Κλάδος απομακρυσμένης παρακολούθησης για τον κλάδο `teamone/master` +image::images/remote-branches-5.png[Κλάδος απομακρυσμένης παρακολούθησης για τον κλάδο `teamone/master`] -[[_pushing_branches]] -==== Pushing +[[r_pushing_branches]] +==== Ωθήσεις -(((pushing))) -When you want to share a branch with the world, you need to push it up to a remote that you have write access to. -Your local branches aren't automatically synchronized to the remotes you write to – you have to explicitly push the branches you want to share. -That way, you can use private branches for work you don't want to share, and push up only the topic branches you want to collaborate on. +(((ώθηση)))(((pushing))) +Όταν θέλουμε να μοιραστούμε έναν κλάδο με τον υπόλοιπο κόσμο, πρέπει να τον ωθήσουμε σε έναν απομακρυσμένο διακομιστή στον οποίο έχουμε δικαίωμα εγγραφής (write access). +Οι τοπικοί μας κλάδοι δεν συγχρονίζονται αυτόματα με τους απομακρυσμένους διακομιστές στους οποίους έχουμε δικαίωμα να αποθηκεύσουμε -- πρέπει να ωθήσουμε χειροκίνητα τους κλάδους που θέλουμε να κοινοποιήσουμε σε άλλους. +Με αυτό τον τρόπο, μπορούμε να χρησιμοποιήσουμε ιδιωτικούς κλάδους για δουλειά που δεν θέλουμε να μοιραστούμε με άλλους και να ωθούμε μόνον τους θεματικούς κλάδους στους οποίους θέλουμε να συνεργαστούμε. -If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. -Run `git push (remote) (branch)`:(((git commands, push))) +Αν έχουμε έναν κλάδο με όνομα `serverfix` στον οποίο θέλουμε να δουλέψουμε με άλλους, μπορούμε να τον ωθήσουμε με τον ίδιο τρόπο που ωθήσαμε τον πρώτο μας κλάδο. +Εκτελούμε την εντολή `git push `:(((εντολές git, push))) [source,console] ---- @@ -79,26 +79,26 @@ To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix ---- -This is a bit of a shortcut. -Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my serverfix local branch and push it to update the remote's serverfix branch.'' -We'll go over the `refs/heads/` part in detail in <<_git_internals>>, but you can generally leave it off. -You can also do `git push origin serverfix:serverfix`, which does the same thing – it says, ``Take my serverfix and make it the remote's serverfix.'' -You can use this format to push a local branch into a remote branch that is named differently. -If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project. +Στην πραγματικότητα αυτή η εντολή είναι μία συντόμευση. +Το Git αναπτύσσει αυτόματα το όνομα κλάδου `serverfix` σε `refs/heads/serverfix:refs/heads/serverfix`, που σημαίνει "`Πάρε τον τοπικό μου κλάδο `serverfix` και ώθησέ τον ώστε να ενημερωθεί ο αντίστοιχος κλάδος `serverfix` του απομακρυσμένου διακομιστή`". +Θα δούμε πιο λεπτομερώς το κομμάτι `refs/heads/` στην ενότητα <>· προς το παρόν μπορούμε να το αγνοήσουμε. +Επίσης μπορούμε να τρέξουμε την εντολή `git push origin serverfix:serverfix`, που κάνει ακριβώς το ίδιο πράγμα -- λέει, "`Πάρε το δικό μου `serverfix` και κάνε τον, το `serverfix` του απομακρυσμένου διακομιστή`". +Χρησιμοποιήσουμε αυτή την εντολή για να ωθήσουμε έναν τοπικό κλάδο σε έναν απομακρυσμένο που έχει διαφορετικό όνομα. +Αν δεν θέλουμε να ονομάζεται `serverfix` στο απομακρυσμένο αποθετήριο, τότε μπορούμε να τρέξουμε την εντολή `git push origin serverfix:awesomebranch` ώστε να ωθήσουμε τον τοπικό μας κλάδο `serverfix` στον κλάδο με όνομα `awesomebranch` στο απομακρυσμένο αποθετήριο. [NOTE] -.Don't type your password every time +.Δεν χρειάζεται να γράφετε τον κωδικό πρόσβασής σας κάθε φορά. ==== -If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. -By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push. +Αν θέλετε να ωθήσετε κάτι σε ένα URL με HTTPS, ο διακομιστής Git θα σας ζητήσει το όνομα χρήστη και τον κωδικό σας για ταυτοποίηση. +Η προεπιλεγμένη ρύθμιση είναι να σας ζητήσει αυτή την πληροφορία στο τερματικό, ώστε ο διακομιστής να αποφανθεί αν έχετε το δικαίωμα να ωθήσετε αλλαγές. -If you don't want to type it every single time you push, you can set up a ``credential cache''. -The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`. +Αν δεν θέλετε να πληκτρολογείτε τον κωδικό πρόσβασής σας κάθε φορά που ωθείτε κάτι, μπορείτε να ορίσετε μία "`προσωρινή μνήμη διαπιστευτηρίων`" ("`credential cache`"). +Ο πιο απλός τρόπος είναι να παραμένουν στη μνήμη για μερικά λεπτά, κάτι που μπορεί να οριστεί εύκολα με την εντολή `git config --global credential.helper cache`. -For more information on the various credential caching options available, see <<_credential_caching>>. +Περισσότερες πληροφορίες σχετικά με τις διάφορες επιλογές προσωρινής αποθήκευσης διαπιστευτηρίων βλ. <>. ==== -The next time one of your collaborators fetches from the server, they will get a reference to where the server's version of `serverfix` is under the remote branch `origin/serverfix`: +Την επόμενη φορά που κάποιος από τους συνεργάτες μας ανακτήσει δεδομένα από τον διακομιστή, θα πάρει μία αναφορά που θα δείχνει εκεί όπου βρίσκεται ο κλάδος `serverfix` του διακομιστή, δηλαδή κάτω από τον απομακρυσμένο κλάδο `origin/serverfix`: [source,console] ---- @@ -111,11 +111,11 @@ From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ---- -It's important to note that when you do a fetch that brings down new remote-tracking branches, you don't automatically have local, editable copies of them. -In other words, in this case, you don't have a new `serverfix` branch – you only have an `origin/serverfix` pointer that you can't modify. +Είναι σημαντικό να σημειώσουμε πως όταν εκτελούμε μία εντολή `git fetch`, που φέρνει νέους κλάδους απομακρυσμένης παρακολούθησης στον υπολογιστή μας, δεν έχουμε αυτόματα τοπικά επεξεργάσιμα αρχεία. +Με άλλα λόγια, σε αυτή την περίπτωση, δεν έχουμε έναν νέο κλάδο `serverfix` -- έχουμε μόνον έναν δείκτη στον `origin/serverfix` που δεν μπορούμε να τροποποιήσουμε. -To merge this work into your current working branch, you can run `git merge origin/serverfix`. -If you want your own `serverfix` branch that you can work on, you can base it off your remote-tracking branch: +Για να συγχωνεύσουμε αυτή τη δουλειά στον τρέχοντα κλάδο εργασίας μας, μπορούμε να τρέξουμε την εντολή `git merge origin/serverfix`. +Αν θέλουμε τον δικό μας κλάδο `serverfix` στον οποίο μπορούμε να εργαστούμε, μπορούμε να τον βασίσουμε στον κλάδο απομακρυσμένης παρακολούθησης: [source,console] ---- @@ -124,20 +124,20 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -This gives you a local branch that you can work on that starts where `origin/serverfix` is. +Η παραπάνω εντολή μας δίνει έναν τοπικό κλάδο στον οποίο μπορούμε να δουλέψουμε και ξεκινά από το σημείο που βρίσκεται ο κλάδος `origin/serverfix`. -[[_tracking_branches]] -==== Tracking Branches +[[r_tracking_branches]] +==== Παρακολούθηση κλάδων -(((branches, tracking)))(((branches, upstream))) -Checking out a local branch from a remote-tracking branch automatically creates what is called a ``tracking branch'' (or sometimes an ``upstream branch''). -Tracking branches are local branches that have a direct relationship to a remote branch. -If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and branch to merge into. +(((κλάδοι, παρακολούθηση)))(((κλάδοι, upstream))) +Όταν κάνουμε checkout έναν τοπικό κλάδο από έναν κλάδο απομακρυσμένης παρακολούθησης, αυτόματα δημιουργείται ένας "`κλάδος παρακολούθησης`" (και ο κλάδος που παρακολουθείται ονομάζεται "`κλάδος upstream`"). +Οι κλάδοι παρακολούθησης είναι τοπικοί κλάδοι που σχετίζονται άμεσα με κάποιο απομακρυσμένο κλάδο. +Αν είμαστε σε έναν κλάδο παρακολούθησης και πληκτρολογήσουμε `git pull`, το Git αυτόματα γνωρίζει από ποιον διακομιστή να ανακτήσει και σε ποιον κλάδο να συγχωνεύσει. -When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. -However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don't track the `master` branch. -The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. -This is a common enough operation that git provides the `--track` shorthand: +Όταν κλωνοποιούμε ένα αποθετήριο, αυτό δημιουργεί αυτόματα έναν κλάδο `master` που παρακολουθεί τον κλάδο `origin/master`. +Όμως μπορούμε να ορίσουμε και άλλους κλάδους παρακολούθησης, αν θέλουμε -- κλάδους που παρακολουθούν κλάδους σε άλλα απομακρυσμένα αποθετήρια ή δεν παρακολουθούν τον κλάδο `master`. +Η πιο απλή περίπτωση είναι αυτή που μόλις είδαμε, η εντολή `git checkout -b /`. +Αυτή η περίπτωση είναι τόσο συνηθισμένη που το Git μας παρέχει την επιλογή `--track`: [source,console] ---- @@ -146,7 +146,17 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: +Μάλιστα, είναι τόσο συνηθισμένη που υπάρχει συντόμευση για την παραπάνω επιλογή. +Αν το όνομα του κλάδου στον οποίο προσπαθούμε να μεταβούμε (α) δεν υπάρχει και (β) έχει το ίδιο όνομα με μόνο έναν απομακρυσμένο, το Git θα δημιουργήσει αυτόματα έναν κλάδο παρακολούθησης. + +[source,console] +---- +$ git checkout serverfix +Branch serverfix set up to track remote branch serverfix from origin. +Switched to a new branch 'serverfix' +---- + +Για να ορίσουμε έναν τοπικό κλάδο με διαφορετικό όνομα από αυτό του απομακρυσμένου κλάδου, μπορούμε εύκολα να χρησιμοποιήσουμε την πρώτη εκδοχή με διαφορετικό όνομα τοπικού κλάδου: [source,console] ---- @@ -155,9 +165,9 @@ Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ---- -Now, your local branch `sf` will automatically pull from `origin/serverfix`. +Τώρα ο τοπικός μας κλάδος `sf` θα τραβά αυτόματα από τον κλάδο `origin/serverfix`. -If you already have a local branch and want to set it to a remote branch you just pulled down, or want to change the upstream branch you're tracking, you can use the `-u` or `--set-upstream-to` option to `git branch` to explicitly set it at any time. +Αν έχουμε ήδη έναν τοπικό κλάδο και θέλουμε να τον συνδέσουμε με έναν απομακρυσμένο κλάδο που μόλις τραβήξαμε ή θέλουμε να αλλάξουμε τον κλάδο upstream που παρακολουθούμε, μπορούμε να χρησιμοποιήσουμε την επιλογή `-u` ή `--set-upstream-to` με την εντολή `git branch` ώστε να τον συνδέσουμε οποιαδήποτε στιγμή. [source,console] ---- @@ -166,51 +176,54 @@ Branch serverfix set up to track remote branch serverfix from origin. ---- [NOTE] -.Upstream shorthand +.Συντόμευση upstream ==== -When you have a tracking branch set up, you can reference it with the `@{upstream}` or `@{u}` shorthand. -So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++))) +Όταν έχετε ορίσει έναν κλάδο παρακολούθησης, μπορείτε να αναφερόσατε σε αυτόν ως `@{upstream}` ή με τη συντομογραφία `@{u}`. +Άρα αν είσαστε στον κλάδο `master` και αυτός παρακολουθεί τον `origin/master`, μπορείτε να πείτε κάτι σαν `git merge @{u}` αντί για `git merge origin/master`, αν θέλουμε.(((@{u})))(((@{upstream}))) ==== -If you want to see what tracking branches you have set up, you can use the `-vv` option to `git branch`. -This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both. +Αν θέλουμε να δούμε ποιους κλάδους παρακολούθησης έχουμε ορίσει, μπορούμε να χρησιμοποιήσουμε την επιλογή `-vv` στην εντολή `git branch`. +Αυτή θα παραθέσει όλους τους τοπικούς κλάδους με περισσότερες πληροφορίες, όπως ποιον κλάδο παρακολουθεί κάθε κλάδος και αν ο τοπικός μας κλάδος προηγείται ή υστερεί σε σχέση με τον απομακρυσμένο κλάδο ή και τα δύο. [source,console] ---- $ git branch -vv - iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets - master 1ae2a45 [origin/master] deploying index fix -* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it - testing 5ea463a trying something new + iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets + master 1ae2a45 [origin/master] Deploy index fix +* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it + testing 5ea463a Try something new ---- -So here we can see that our `iss53` branch is tracking `origin/iss53` and is ``ahead'' by two, meaning that we have two commits locally that are not pushed to the server. -We can also see that our `master` branch is tracking `origin/master` and is up to date. -Next we can see that our `serverfix` branch is tracking the `server-fix-good` branch on our `teamone` server and is ahead by three and behind by one, meaning that there is one commit on the server we haven't merged in yet and three commits locally that we haven't pushed. -Finally we can see that our `testing` branch is not tracking any remote branch. +Εδώ μπορούμε να δούμε ότι ο κλάδος μας `iss53` παρακολουθεί τον `origin/iss53` και "`προηγείται`" κατά δύο (ahead 2), δηλαδή έχουμε κάνει δύο υποβολές τοπικά που δεν έχουν ωθηθεί στον διακομιστή. +Επίσης μπορούμε να δούμε ότι ο τοπικός μας κλάδος `master` παρακολουθεί τον `origin/master` και είναι ενημερωμένος. +Στη συνέχεια βλέπουμε ότι ο κλάδος μας `serverfix` παρακολουθεί τον κλάδο `server-fix-good` στον διακομιστή `teamone` και προηγείται κατά τρεις και υστερεί κατά μία, που σημαίνει ότι υπάρχει μία υποβολή στον διακομιστή που δεν την έχουμε συγχωνεύσει ακόμη και τρεις τοπικές υποβολές που δεν έχουμε ωθήσει ακόμη. +Τέλος, βλέπουμε ότι ο κλάδος μας `testing` δεν παρακολουθεί κανέναν απομακρυσμένο κλάδο. -It's important to note that these numbers are only since the last time you fetched from each server. -This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. -If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. -You could do that like this: `$ git fetch --all; git branch -vv` +Είναι σημαντικό να σημειώσουμε ότι αυτοί οι αριθμοί είναι οι υποβολές από την τελευταία φορά που ανακτήσαμε (fetch) από τον κάθε διακομιστή. +Αυτή η εντολή δεν ρωτά τους διακομιστές, απλά μας λέει τι έχει ήδη αποθηκευμένο τοπικά από τους διακομιστές. +Αν θέλουμε εντελώς ενημερωμένους αριθμούς υποβολών με τις οποίες προηγείται και υστερεί ο κλάδος μας, πρέπει να τρέξουμε μία εντολή `fetch` προς όλους τους απομακρυσμένους πριν τρέξουμε την παραπάνω εντολή. +Αυτό μπορούμε να το κάνουμε ως εξής: -==== Pulling +[source,console] +---- +$ git fetch --all; git branch -vv +---- -(((pulling))) -While the `git fetch` command will fetch down all the changes on the server that you don't have yet, it will not modify your working directory at all. -It will simply get the data for you and let you merge it yourself. -However, there is a command called `git pull` which is essentially a `git fetch` immediately followed by a `git merge` in most cases. -If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the `clone` or `checkout` commands, `git pull` will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch. +==== Ελκυσμοί -Generally it's better to simply use the `fetch` and `merge` commands explicitly as the magic of `git pull` can often be confusing. +(((ελκυσμός)))(((pulling))) +Ενώ η εντολή `git fetch` ανακτά όλες τις αλλαγές που δεν έχουμε ήδη από τον διακομιστή, δεν θα αλλάξει τον κατάλογο εργασίας μας καθόλου. +Απλά θα πάρει τα δεδομένα και θα μας αφήσει να τα συγχωνεύσουμε μόνοι μας. +Πάντως, υπάρχει η εντολή `git pull` η οποία ουσιαστικά στις περισσότερες περιπτώσεις είναι μία εντολή `git fetch` που ακολουθείται από μία εντολή `git merge`. +Αν έχουμε ορίσει κάποιον κλάδο παρακολούθησης όπως σας δείξαμε στην προηγούμενη ενότητα, είτε με ρητό ορισμό είτε επειδή τον έχουμε δημιουργήσει με τις εντολές `clone` ή `checkout`, η `git pull` θα αναζητήσει τον διακομιστή και κλάδο τον οποίο παρακολουθεί ο τρέχων κλάδος μας, θα ανακτήσει από τον διακομιστή και θα προσπαθήσει να συγχωνεύσει σε αυτό τον απομακρυσμένο κλάδο. -[[_delete_branches]] -==== Deleting Remote Branches +[[r_delete_branches]] +==== Διαγραφή απομακρυσμένων κλάδων -(((branches, deleting remote))) -Suppose you're done with a remote branch – say you and your collaborators are finished with a feature and have merged it into your remote's `master` branch (or whatever branch your stable codeline is in). -You can delete a remote branch using the `--delete` option to `git push`. -If you want to delete your `serverfix` branch from the server, you run the following: +(((κλάδοι, διαγραφή απομακρυσμένων))) +Ας υποθέσουμε ότι τελειώσαμε με τον απομακρυσμένο κλάδο -- π.χ. οι συνεργάτες μας και εσείς τελειώσαμε με ένα χαρακτηριστικό και το έχουμε συγχωνεύσει στον κλάδο `master` του απομακρυσμένου αποθετηρίου (ή τέλος πάντων σε οποιονδήποτε κλάδο υπάρχει η ευσταθής έκδοσή του έργου μας). +Μπορούμε να διαγράψουμε τον απομακρυσμένο κλάδο χρησιμοποιώντας την επιλογή `--delete` στην εντολή `git push`. +Αν θέλουμε να διαγράψουμε τον κλάδο `serverfix` από τον διακομιστή, τρέχουμε τα παρακάτω: [source,console] ---- @@ -219,5 +232,5 @@ To https://github.com/schacon/simplegit - [deleted] serverfix ---- -Basically all this does is remove the pointer from the server. -The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it's often easy to recover. +Βασικά αυτό που κάνει αυτή η εντολή είναι να απομακρύνει τον δείκτη από τον διακομιστή. +Ο διακομιστής Git γενικά θα διατηρήσει τα δεδομένα εκεί για λίγο καιρό, μέχρι να τρέξει μία διαδικασία συλλογής σκουπιδιών (garbage collection) ώστε αν ο κλάδος διαγράφηκε κατά λάθος, να είναι εύκολο να αποκατασταθεί. diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 654eb6c75..138e706ec 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,63 +1,64 @@ -=== Branching Workflows +=== Ροές εργασίας με διακλαδώσεις -Now that you have the basics of branching and merging down, what can or should you do with them? -In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle. +Τώρα που γνωρίζουμε τα βασικά των διαδικασιών διακλάδωσης και συγχώνευσης, το ερώτημα που τίθεται είναι τι μπορούμε ή τι θα έπρεπε να κάνουμε με αυτά. +Σε αυτή την ενότητα θα καλύψουμε μερικές συνήθεις ροές εργασίας που καθίστανται δυνατές χάρη σε αυτού του είδους την ελαφριά διαδικασία διακλάδωσης, ώστε να αποφασίσουμε αν θέλουμε να τις ενσωματώσουμε στον δικό μας κύκλο ανάπτυξης ενός έργου. -==== Long-Running Branches +==== Μακρόβιοι κλάδοι -(((branches, long-running))) -Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. -This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. +(((κλάδοι, μακρόβιοι)))(((κλάδοι, long-running))) +Επειδή το Git χρησιμοποιεί μία απλή τριμερή συγχώνευση, η συγχώνευση ενός κλάδου με κάποιον άλλο πολλές φορές κατά τη διάρκεια μία μακράς περιόδου είναι γενικά εύκολη. +Αυτό σημαίνει ότι είναι δυνατό να έχουμε πολλούς κλάδους που είναι συνεχώς ανοιχτοί και τους οποίους χρησιμοποιούμε σε διαφορετικά στάδια του κύκλου ανάπτυξης του έργου· μπορούμε να συγχωνεύουμε συχνά κάποιους από αυτούς σε άλλους. -Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch – possibly only code that has been or will be released. -They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. -It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs. +Πολλοί προγραμματιστές που χρησιμοποιούν το Git έχουν μία ροή εργασιών που υιοθετεί αυτή την προσέγγιση, για παράδειγμα στον κλάδο `master` έχουν αποκλειστικά κώδικα που είναι απολύτως σταθερός (stable) -- ενδεχομένως μόνον κώδικα που έχει δημοσιευτεί ή θα δημοσιευτεί. +Έχουν έναν άλλο παράλληλο κλάδο που τον ονομάζουν `develop` ή `next` στον οποίο δουλεύουν ή στον οποίο ελέγχουν την σταθερότητα -- αυτός δεν είναι απαραίτητα σταθερός, αλλά όποτε καθίσταται σταθερός ενδεχομένως συγχωνεύεται με τον κλάδο `master`. +Ο κλάδος αυτός χρησιμοποιείται για να ενσωματώνει _θεματικούς κλάδους_ (βραχύβιους κλάδους, όπως ο κλάδος `iss53` που είδαμε προηγουμένως) όταν αυτοί είναι έτοιμοι, ώστε να είναι σίγουροι ότι περνούν όλα τα τεστ και δεν εισάγουν σφάλματα (bugs). -In reality, we're talking about pointers moving up the line of commits you're making. -The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history. +Στην πραγματικότητα, μιλάμε για δείκτες που προχωρούν στη γραμμή των υποβολών μας. +Οι σταθεροί κλάδοι βρίσκονται πολύ πίσω στο ιστορικό υποβολών και οι πειραματικοί, καινοτόμοι κλάδοι βρίσκονται πολύ μπροστά στο ιστορικό. -.A linear view of progressive-stability branching -image::images/lr-branches-1.png[A linear view of progressive-stability branching.] +.Γραμμική προβολή διακλάδωσης με προοδευτική ευστάθεια +image::images/lr-branches-1.png[Γραμμική προβολή διακλάδωσης με προοδευτική ευστάθεια] -It's generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they're fully tested. +Γενικά είναι ευκολότερο να τους σκεφτόμαστε σαν σιλό (silo) εργασίας, από τα οποία κάθε τόσο κάποιες υποβολές, που έχουν δοκιμαστεί πλήρως, προκρίνονται σε άλλα, σταθερότερα σιλό. -[[lrbranch_b]] -.A ``silo'' view of progressive-stability branching -image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching.] +[[rlrbranch_b]] +.Προβολή "`σιλό`" διακλάδωσης με προοδευτική ευστάθεια +image::images/lr-branches-2.png[Προβολή "`σιλό`" διακλάδωσης με προοδευτική ευστάθεια] -You can keep doing this for several levels of stability. -Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. -The idea is that your branches are at various levels of stability; when they reach a more stable level, they're merged into the branch above them. -Again, having multiple long-running branches isn't necessary, but it's often helpful, especially when you're dealing with very large or complex projects. +Μπορούμε να συνεχίζουμε να κάνουμε κάτι τέτοιο για πολλά επίπεδα ευστάθειας. +Κάποια μεγαλύτερα έργα έχουν επίσης έναν κλάδο `proposed` ή `pu` (proposed updates) που έχει ενσωματωμένους κλάδους, οι οποίοι ενδεχομένως δεν είναι έτοιμοι να εισαχθούν στον κλάδο `next` ή τον κλάδο `master`. +Η λογική είναι ότι οι κλάδοι βρίσκονται σε διαφορετικά επίπεδα ευστάθειας· όταν φτάσουν σε ένα πιο σταθερό επίπεδο, συγχωνεύονται με τον κλάδο που βίσκεται από πάνω τους. +Επαναλαμβάνουμε ότι το να υπάρχουν πολλοί μακρόβιοι κλάδοι δεν είναι απαραίτητο, αλλά συχνά είναι χρήσιμο, ειδικά όταν έχουμε πολύ μεγάλα ή περίπλοκα έργα. -[[_topic_branch]] -==== Topic Branches +[[r_topic_branch]] +==== Θεματικοί κλάδοι -(((branches, topic))) -Topic branches, however, are useful in projects of any size. -A topic branch is a short-lived branch that you create and use for a single particular feature or related work. -This is something you've likely never done with a VCS before because it's generally too expensive to create and merge branches. -But in Git it's common to create, work on, merge, and delete branches several times a day. +(((κλάδοι, θεματικοί)))(((κλάδοι, topic))) +Από την άλλη, οι θεματικοί κλάδοι είναι χρήσιμοι σε έργα οποιουδήποτε μεγέθους. +Ένας θεματικός κλάδος είναι ένας βραχύβιος κλάδος, τον οποίο δημιουργούμε και χρησιμοποιούμε αποκλειστικά για μία συγκεκριμένη λειτουργικότητα (feature) ή κάποια σχετική με αυτή εργασία. +Αυτό είναι κάτι που πιθανότατα δεν έχουμε κάνει ποτέ σε ένα VCS στο παρελθόν, διότι γενικά η διαδικασία δημιουργίας και συγχώνευσης κλάδων είναι μία _ακριβή_ διαδικασία. +Όμως στο Git είναι σύνηθες κάποιος να δημιουργεί κλάδους, να εργάζεται με αυτούς, να τους συγχωνεύει και να τους διαγράφει πολλές φορές κάθε μέρα. -You saw this in the last section with the `iss53` and `hotfix` branches you created. -You did a few commits on them and deleted them directly after merging them into your main branch. -This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such. -You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on. +Αυτό το είδαμε στην προηγούμενη ενότητα με τους κλάδους `iss53` και `hotfix` που δημιουργήσαμε. +Κάναμε μερικές υποβολές και τους διαγράψαμε αμέσως αφού τους συγχωνεύσαμε με τον κύριο κλάδο. +Αυτή η τεχνική μας επιτρέπει να αλλάζουμε περιβάλλον γρήγορα και πλήρως -- επειδή η εργασία μας είναι διαχωρισμένη σε κλάδους-σιλό στους οποίους όλες οι αλλαγές έχουν να κάνουν με αυτό θέμα, είναι ευκολότερο να δούμε τι ακριβώς έχει γίνει κατά την επανεξέταση του κώδικα (code review) ή κάποια άλλη σχετική διαδικασία. +Μπορούμε να διατηρήσουμε τις αλλαγές εκεί για λεπτά, μέρες ή μήνες, να τις συγχωνεύσουμε όταν είναι έτοιμες για συγχώνευση ανεξάρτητα από τη χρονική σειρά με την οποία έχουν γίνει ή έχουν δουλευτεί. -Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch). -Your commit history will look something like this: +Για παράδειγμα ας υποθέσουμε ότι έχουμε κάνει κάποια δουλειά (στον κλάδο `master`), δημιουργήσαμε έναν κλάδο για ένα πρόβλημα (`iss91`), δουλέψαμε σε αυτό για λίγο, δημιουργήσαμε έναν άλλο κλάδο για να δοκιμάσουμε έναν άλλο τρόπο να επιλύσουμε το ίδιο πρόβλημα (`iss91v2`), επιστρέψαμε στον κλάδο `master` και δουλέψαμε εκεί για λίγο και από κει φτιάξαμε έναν άλλο κλάδο για να δουλέψουμε πάνω σε κάποια ιδέα για την οποία δεν είστε σίγουροι ότι είναι καλή ιδέα (κλάδος `dumbidea`). +Το ιστορικό υποβολών θα είναι περίπου σαν το παρακάτω: -.Multiple topic branches -image::images/topic-branches-1.png[Multiple topic branches.] +.Πολλαπλοί θεματικοί κλάδοι +image::images/topic-branches-1.png[Πολλαπλοί θεματικοί κλάδοι] -Now, let's say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. -You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two. -Your history then looks like this: +Ας υποθέσουμε τώρα ότι αποφασίσαμε ότι μας άρεσε η δεύτερη λύση, δηλαδή η `iss91v2`, στο πρόβλημα· επιπλέον δείξαμε τον κλάδο `dumbidea` στους συναδέλφους μας και αποδείχθηκε ότι είναι ιδιοφυής. +Μπορούμε να πετάξουμε τον αρχικό κλάδο `iss91` (χάνοντας τις υποβολές `C5` και `C6`) και να συγχωνεύσουμε αυτούς τους δύο. +Το ιστορικό τότε θα μοιάζει με το παρακάτω: -.History after merging `dumbidea` and `iss91v2` -image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.] +.Ιστορικό μετά τη συγχώνευση των κλάδων `dumbidea` και `iss91v2`. +image::images/topic-branches-2.png[Ιστορικό μετά τη συγχώνευση των κλάδων `dumbidea` και `iss91v2`.] -We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter. +θα δούμε με περισσότερες λεπτομέρειες διάφορες δυνατές ροές εργασίας για τα έργα μας στο Git στο κεφάλαιο <>. +Γι' αυτό καλό θα είναι να έχουμε διαβάσει αυτό το κεφάλαιο προτού αποφασίσουμε ποιο μοντέλο διακλαδώσεων θα χρησιμοποιήσουμε στο επόμενο έργο μας. -It's important to remember when you're doing all this that these branches are completely local. -When you're branching and merging, everything is being done only in your Git repository – no server communication is happening. +Όταν τα κάνουμε όλα αυτά είναι σημαντικό να θυμόμαστε ότι αυτοί οι κλάδοι είναι μόνο τοπικοί. +Όταν δημιουργούμε ή συγχωνεύουμε διακλαδώσεις, τα πάντα συμβαίνουν στο τοπικό μας αποθετήριο Git -- δεν υπάρχει καμία επικοινωνία με κανέναν διακομιστή. diff --git a/book/04-git-server/1-git-server.asc b/book/04-git-server/1-git-server.asc deleted file mode 100644 index 8e6ae12d4..000000000 --- a/book/04-git-server/1-git-server.asc +++ /dev/null @@ -1,47 +0,0 @@ -== Git on the Server - -(((serving repositories))) -At this point, you should be able to do most of the day-to-day tasks for which you'll be using Git. -However, in order to do any collaboration in Git, you'll need to have a remote Git repository. -Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they're working on if you're not careful. -Furthermore, you want your collaborators to be able to access the repository even if your computer is offline – having a more reliable common repository is often useful. -Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. - -Running a Git server is fairly straightforward. -First, you choose which protocols you want your server to communicate with. -The first section of this chapter will cover the available protocols and the pros and cons of each. -The next sections will explain some typical setups using those protocols and how to get your server running with them. -Last, we'll go over a few hosted options, if you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server. - -If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. - -A remote repository is generally a _bare repository_ – a Git repository that has no working directory. -Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it's just the Git data. -In the simplest terms, a bare repository is the contents of your project's `.git` directory and nothing else. - -include::sections/protocols.asc[] - -include::sections/git-on-a-server.asc[] - -include::sections/generating-ssh-key.asc[] - -include::sections/setting-up-server.asc[] - -include::sections/git-daemon.asc[] - -include::sections/smart-http.asc[] - -include::sections/gitweb.asc[] - -include::sections/gitlab.asc[] - -include::sections/hosted.asc[] - -=== Summary - -You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. - -Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. -If you place your data on a hosted server, it's easy to set up and maintain; however, you have to be able to keep your code on someone else's servers, and some organizations don't allow that. - -It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. diff --git a/book/04-git-server/images/bitnami.png b/book/04-git-server/images/bitnami.png deleted file mode 100644 index b7929f489..000000000 Binary files a/book/04-git-server/images/bitnami.png and /dev/null differ diff --git a/book/04-git-server/images/git-instaweb.png b/book/04-git-server/images/git-instaweb.png deleted file mode 100644 index 6c56b7105..000000000 Binary files a/book/04-git-server/images/git-instaweb.png and /dev/null differ diff --git a/book/04-git-server/images/gitlab-broadcast.png b/book/04-git-server/images/gitlab-broadcast.png deleted file mode 100644 index 5658f4e07..000000000 Binary files a/book/04-git-server/images/gitlab-broadcast.png and /dev/null differ diff --git a/book/04-git-server/images/gitlab-groups.png b/book/04-git-server/images/gitlab-groups.png deleted file mode 100644 index 486b4441c..000000000 Binary files a/book/04-git-server/images/gitlab-groups.png and /dev/null differ diff --git a/book/04-git-server/images/gitlab-menu.png b/book/04-git-server/images/gitlab-menu.png deleted file mode 100644 index 902a7f967..000000000 Binary files a/book/04-git-server/images/gitlab-menu.png and /dev/null differ diff --git a/book/04-git-server/images/gitlab-users.png b/book/04-git-server/images/gitlab-users.png deleted file mode 100644 index 4e2b20904..000000000 Binary files a/book/04-git-server/images/gitlab-users.png and /dev/null differ diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 93015d164..85816d0dc 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -1,13 +1,13 @@ -[[_generate_ssh_key]] -=== Generating Your SSH Public Key +[[r_generate_ssh_key]] +=== Δημιουργία δημόσιου κλειδιού SSH (((SSH keys))) -That being said, many Git servers authenticate using SSH public keys. -In order to provide a public key, each user in your system must generate one if they don't already have one. -This process is similar across all operating systems. -First, you should check to make sure you don't already have a key. -By default, a user's SSH keys are stored in that user's `~/.ssh` directory. -You can easily check to see if you have a key already by going to that directory and listing the contents: +Πολλοί διακομιστές Git ταυτοποιούν τους χρήστες χρησιμοποιώντας δημόσια κλειδιά SSH. +Για να παρέχουμε δημόσιο κλειδί, όλοι οι χρήστες στο σύστημά μας πρέπει να δημιουργήσουν ένα, αν δεν έχουν ήδη. +Η διαδικασία είναι παρόμοια σε όλα τα λειτουργικά συστήματα. +Πρώτα πρέπει να ελέγξουμε ότι δεν έχουμε ήδη κλειδί. +Η προεπιλεγμένη θέση στην οποία αποθηκεύονται τα κλειδιά SSH ενός χρήστη είναι ο κατάλογος `~/.ssh`. +Μπορούμε εύκολα να ελέγξουμε αν έχουμε ήδη κλειδί πηγαίνοντας σε αυτόν τον κατάλογο και βλέποντας τα περιεχόμενά του: [source,console] ---- @@ -17,13 +17,13 @@ authorized_keys2 id_dsa known_hosts config id_dsa.pub ---- -You're looking for a pair of files named something like `id_dsa` or `id_rsa` and a matching file with a `.pub` extension. -The `.pub` file is your public key, and the other file is your private key. -If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows: +Ψάχνουμε για ένα αρχείο που ονομάζεται `id_dsa` ή `id_rsa` ή κάτι παραπλήσιο και ένα ακόμα με το ίδιο όνομα αλλά κατάληξη `.pub`. +Το αρχείο με κατάληξη `.pub` είναι το δημόσιο κλειδί μας και το άλλο αρχείο είναι το ιδιωτικό κλειδί μας. +Αν δεν έχουμε τέτοια αρχεία (ή αν δεν έχουμε καν κατάλογο `.ssh`), μπορούμε να τα δημιουργήσουμε τρέχοντας ένα πρόγραμμα που ονομάζεται `ssh-keygen` και το οποίο παρέχεται με το πακέτο SSH σε συστήματα Linux και Mac και με το Git στα Windows: [source,console] ---- -$ ssh-keygen +$ ssh-keygen -o Generating public/private rsa key pair. Enter file in which to save the key (/home/schacon/.ssh/id_rsa): Created directory '/home/schacon/.ssh'. @@ -35,11 +35,13 @@ The key fingerprint is: d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local ---- -First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don't want to type a password when you use the key. +Πρώτα επιβεβαιώνει πού έχουμε αποθηκεύσει το κλειδί (`.ssh/id_rsa`) και μετά ρωτά δύο φορές για μία κωδική φράση, την οποία μπορούμε να αφήσουμε κενή, εφόσον δεν θέλουμε να πληκτρολογούμε κωδικό πρόσβασης κάθε φορά που χρησιμοποιούμε το κλειδί. +Αν πάντως θέλουμε να χρησιμοποιούμε κωδικό πρόσβασης, σιγουρευόμαστε ότι έχουμε προσθέσει την επιλογή `-o`, ώστε το ιδιωτικό κλειδί να αποθηκευτεί σε τέτοια μορφή που να αντιστέκεται στην παραβίαση του κωδικού πρόσβασης περισσότερο από ότι η προεπιλεγμένη μορφή. +Μπορούμε επίσης να χρησιμοποιήσουμε το εργαλείο `ssh-agent` για να μη χρειάζεται να εισάγουμε τον κωδικό πρόσβασης κάθε φορά. -Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you're using an SSH server setup that requires public keys). -All they have to do is copy the contents of the `.pub` file and e-mail it. -The public keys look something like this: +Τώρα κάθε χρήστης που κάνει αυτή τη διαδικασία πρέπει να στείλει το δημόσιο κλειδί του σε μας ή σε όποιον είναι ο διαχειριστής του διακομιστή Git (με την προϋπόθεση ότι χρησιμοποιούμε έναν διακομιστή με SSH που απαιτεί δημόσια κλειδιά). +Το μόνο που πρέπει να κάνει είναι να αντιγράψει τα περιεχόμενα του αρχείου `.pub` και να τα στείλει με e-mail. +Το δημόσιο κλειδί μοιάζει με κάτι τέτοιο: [source,console] ---- @@ -52,4 +54,4 @@ mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx NrRFi9wrf+M7Q== schacon@mylaptop.local ---- -For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://help.github.com/articles/generating-ssh-keys[]. +Για έναν οδηγό σε μεγαλύτερο βάθος σχετικά με τη δημιουργία κλειδιού SSH σε διάφορα λειτουργικά συστήματα, βλ. τον οδηγό του GitHub για τα κλειδιά SSH στην ιστοσελίδα https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent[^]. diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 545978eb1..fc2934da5 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -1,62 +1,61 @@ -=== Git Daemon +=== Δαίμονες του Git -(((serving repositories, git protocol))) -Next we'll set up a daemon serving repositories over the ``Git'' protocol. -This is common choice for fast, unauthenticated access to your Git data. -Remember that since it's not an authenticated service, anything you serve over this protocol is public within its network. +(((αποθετήρια εξυπηρέτησης, πρωτόκολλο git))) +Στη συνέχεια θα εγκαταστήσουμε έναν δαίμονα που θα εξυπηρετεί αποθετήρια μέσω του πρωτοκόλλου "`Git`". +Αυτή είναι μια συνήθης επιλογή για γρήγορη και χωρίς ταυτοποίηση πρόσβαση στα δεδομένα μας στο Git. +Θυμόμαστε πως δεδομένου ότι πρόκειται για μια υπηρεσία χωρίς ταυτοποίηση, οτιδήποτε παρέχεται πάνω από αυτό το πρωτόκολλο είναι δημόσιο εντός του δικτύου του. -If you're running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. -If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each. +Εάν τρέχουμε τον δαίμονα σε έναν διακομιστή εκτός firewall, θα πρέπει να χρησιμοποιείται μόνο για έργα που είναι ορατά σε όλον τον κόσμο. +Αν ο διακομιστής στον οποίο τον τρέχουμε είναι εντός firewall, μπορούμε να τον χρησιμοποιήσουμε για έργα στα οποία ένας μεγάλος αριθμός ανθρώπων ή υπολογιστών (continuous integration ή build servers) έχουν πρόσβαση μόνο για ανάγνωση, όταν δεν θέλουμε να προσθέσουμε κλειδί SSH για τον καθένα. -In any case, the Git protocol is relatively easy to set up. -Basically, you need to run this command in a daemonized manner:(((git commands, daemon))) +Σε κάθε περίπτωση, το πρωτόκολλο Git είναι σχετικά εύκολο στη ρύθμισή του. +Βασικά, θα πρέπει να εκτελέσουμε αυτή την εντολή με "`δαιμονοποιημένο`" τρόπο: (((εντολές git, δαίμονας))) [source,console] ---- -git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ +$ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/ ---- -`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. -If you're running a firewall, you'll also need to punch a hole in it at port 9418 on the box you're setting this up on. +Ο διακόπτης `--reuseaddr` επιτρέπει στον διακομιστή να επανεκκινήσει χωρίς να αναμένει αποσύνδεση των παλαιών συνδέσεων, ο διακόπτης `--base-path` επιτρέπει την κλωνοποίηση έργων χωρίς να καθορίζεται ολόκληρη η διαδρομή (path), και η διαδρομή (path) στο τέλος λέει στον δαίμονα Git πού να αναζητήσει αποθετήρια προς εξαγωγή. +Εάν τρέχουμε ένα firewall, θα χρειαστεί επίσης να του ανοίξουμε μία τρύπα στη θύρα 9418 στο κουτί που τον εγκαθιστούμε στον διακομιστή. -You can daemonize this process a number of ways, depending on the operating system you're running. -On an Ubuntu machine, you can use an Upstart script. -So, in the following file +Μπορούμε να "`δαιμονοποίησουμε`" αυτή τη διαδικασία με διάφορους τρόπους, ανάλογα με το λειτουργικό σύστημα που εκτελούμε. + +Δεδομένου ότι `systemd` είναι το πιο συνηθισμένο σύστημα init στις μοντέρνες διανομές Linux, μπορούμε να χρησιμοποιήσουμε αυτό για τον σκοπό αυτό. +Απλά βάλτε ένα αρχείο στο `/etc/systemd/system/git-daemon.service` με αυτά τα περιεχόμενα: [source,console] ---- -/etc/event.d/local-git-daemon ----- +[Unit] +Description=Start Git Daemon -you put this script: +[Service] +ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/srv/git/ /srv/git/ -[source,console] ----- -start on startup -stop on shutdown -exec /usr/bin/git daemon \ - --user=git --group=git \ - --reuseaddr \ - --base-path=/opt/git/ \ - /opt/git/ -respawn ----- +Restart=always +RestartSec=500ms -For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories – you can easily do this by creating a new user 'git-ro' and running the daemon as them. -For the sake of simplicity we'll simply run it as the same 'git' user that `git-shell` is running as. +StandardOutput=syslog +StandardError=syslog +SyslogIdentifier=git-daemon -When you restart your machine, your Git daemon will start automatically and respawn if it goes down. -To get it running without having to reboot, you can run this: +User=git +Group=git -[source,console] ----- -initctl start local-git-daemon +[Install] +WantedBy=multi-user.target ---- -On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else – as long as you get that command daemonized and watched somehow. +Αν προσέξουμε ο δαίμονας του Git daemon ξεκινά εδώ ως `git` τόσο για την ομάδα (group) όσο και για τον χρήστη (user). +Το τροποποιούμε ώστε να το προσαρμόσουμε στις ανάγκες μας και σιγουρευόμαστε ότι ο χρήστης που δίνεται υπάρχει στο σύστημα. +Επίσης, ελέγχουμε ότι το εκτελέσιμο αρχείο του Git βρίσκεται πράγματι στο `/usr/bin/git` αλλιώς αλλάζουμε τη διαδρομή (path) αναλόγως. + +Τέλος, θα εκτελέσουμε `systemctl enable git-daemon` ώστε η υπηρεσία να ξεκινά αυτόματα κατά την εκκίνηση του υπολογιστή και μπορούμε να εκκινήσούμε και να σταματήσουμε την υπηρεσία με `systemctl start git-daemon` και `systemctl stop git-daemon` αντίστοιχα. + +Σε άλλα συστήματα, ίσως θελήσουμε να χρησιμοποιήσουμε το `xinetd`, ένα script στο σύστημά μας `sysvinit` ή κάτι άλλο -- με την προϋπόθεση ότι μπορούμε δαιμονοποιήσουμε αυτή την εντολή και να την παρακολουθούμε με κάποιον τρόπο. -Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to. -You can do this in each repository by creating a file named `git-daemon-export-ok`. +Στη συνέχεια, πρέπει να ενημερώσουμε το Git ποια αποθετήρια επιτρέπουν την πρόσβαση σε διακομιστές Git χωρίς ταυτοποίηση. +Μπορούμε να το κάνουμε σε κάθε αποθετήριο δημιουργώντας ένα αρχείο που ονομάζεται `git-daemon-export-ok`. [source,console] ---- @@ -64,4 +63,4 @@ $ cd /path/to/project.git $ touch git-daemon-export-ok ---- -The presence of that file tells Git that it's OK to serve this project without authentication. +Η παρουσία αυτού του αρχείου λέει στο Git ότι επιτρέπεται να εξυπηρετήσει αυτό το έργο χωρίς ταυτοποίηση. diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index fa19180b6..0f7ec18aa 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -1,18 +1,18 @@ -[[_git_on_the_server]] -=== Getting Git on a Server +[[r_getting_git_on_a_server]] +=== Εγκατάσταση του Git σε διακομιστή -Now we'll cover setting up a Git service running these protocols on your own server. +Τώρα θα καλύψουμε τη δημιουργία μιας υπηρεσίας Git που θα εκτελεί αυτά τα πρωτόκολλα στον δικό μας διακομιστή. [NOTE] ==== -Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux based server, though it's also possible to run these services on Mac or Windows servers too. -Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved. +Εδώ θα επιδείξουμε τις εντολές και τα βήματα που απαιτούνται για να κάνουμε βασικές απλοποιημένες εγκαταστάσεις σε έναν διακομιστή σε Linux, αν και είναι επίσης δυνατή η εκτέλεση αυτών των υπηρεσιών σε διακομιστές Mac ή Windows. +Η εγκατάσταση ενός διακομιστή παραγωγής στην υποδομή μας προϋποθέτει ασφαλώς διαφορές στα μέτρα ασφαλείας ή τα εργαλεία των λειτουργικών συστημάτων, αλλά αυτό θα μας δώσει τη γενική ιδέα για το τι εμπλέκεται. ==== -In order to initially set up any Git server, you have to export an existing repository into a new bare repository – a repository that doesn't contain a working directory. -This is generally straightforward to do. -In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option.(((git commands, clone, bare))) -By convention, bare repository directories end in `.git`, like so: +Για να ρυθμίσουμε αρχικά οποιοδήποτε διακομιστή Git, πρέπει να εξάγουμε ένα υπάρχον αποθετήριο σε ένα νέο γυμνό αποθετήριο -- ένα αποθετήριο που δεν περιέχει κατάλογο εργασίας. +Αυτό είναι γενικά εύκολο να γίνει. +Για να κλωνοποιήσουμε το αποθετήριό μας και να δημιουργήσουμε ένα νέο γυμνό αποθετήριο, εκτελούμε την εντολή `clone` με την επιλογή `--bare`. (((εντολές git, clone, bare))) +Συμβατικά, οι γυμνοί κατάλογοι αποθετηρίων τελειώνουν σε `.git`, ως εξής: [source,console] ---- @@ -21,80 +21,81 @@ Cloning into bare repository 'my_project.git'... done. ---- -You should now have a copy of the Git directory data in your `my_project.git` directory. +Θα πρέπει τώρα να έχουμε ένα αντίγραφο των δεδομένων του καταλόγου Git στον κατάλογο `my_project.git`. -This is roughly equivalent to something like +Αυτό είναι σχεδόν ισοδύναμο με κάτι σαν αυτό: [source,console] ---- $ cp -Rf my_project/.git my_project.git ---- -There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing. -It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. +Υπάρχουν μερικές μικροδιαφορές στο αρχείο ρυθμίσεων· αλλά για τον σκοπό μας αυτό δεν είναι σημαντικό. +Η παραπάνω εντολή παίρνει το αποθετήριο Git μόνο του, χωρίς κατάλογο εργασίας και δημιουργεί έναν κατάλογο αποκλειστικά για αυτό. -[[_bare_repo]] -==== Putting the Bare Repository on a Server +[[r_bare_repo]] +==== Τοποθέτηση του γυμνού αποθετηρίου σε έναν διακομιστή -Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. -Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory. -Assuming that `/opt/git` exists on that server, you can set up your new repository by copying your bare repository over: +Τώρα που έχουμε ένα γυμνό αντίγραφο του αποθετηρίου μας, το μόνο που χρειάζεται να κάνουμε είναι να το βάλουμε σε έναν διακομιστή και να ρυθμίσουμε τα πρωτόκολλά μας. +Ας υποθέσουμε ότι έχουμε δημιουργήσει έναν διακομιστή που ονομάζεται `git.example.com` στον οποίο έχουμε πρόσβαση μέσω SSH και θελούμε να αποθηκεύσουμε όλα τα αποθετήρια Git στον κατάλογο `/srv/git`. +Υποθέτοντας ότι το `/opt/git` υπάρχει σε αυτόν τον διακομιστή, μπορούμε να ρυθμίσουμε το νέο αποθετήριό μας αντιγράφοντας το γυμνό αποθετήριο: [source,console] ---- -$ scp -r my_project.git user@git.example.com:/opt/git +$ scp -r my_project.git user@git.example.com:/srv/git ---- -At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running +Σε αυτό το σημείο, άλλοι χρήστες που έχουν πρόσβαση SSH στον ίδιο διακομιστή ο οποίος έχει πρόσβαση ανάγνωσης στον κατάλογο `/srv/git` μπορούν να κλωνοποιήσουν τον αποθετήριό μας τρέχοντας [source,console] ---- -$ git clone user@git.example.com:/opt/git/my_project.git +$ git clone user@git.example.com:/srv/git/my_project.git ---- -If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access. +Αν ένας χρήστης συνδεθεί με SSH σε έναν διακομιστή και έχει δικαίωμα εγγραφής στον κατάλογο `/srv/git/my_project.git`, θα έχει αυτόματα δικαίωμα ώθησης. -Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare))) +Το Git θα προσθέσει αυτόματα δικαιώματα εγγραφής σε ομάδες σε ένα αποθετήριο σωστά εάν εκτελέσουμε την εντολή `git init` με την επιλογή `--shared`. +Σημειώνουμε πως τρέχοντας αυτή την εντολή, δεν θα καταστρέψουμε καμία υποβολή, αναφορά, κτλ. στην όλη διαδικασία. (((εντολές git, init, bare))) [source,console] ---- $ ssh user@git.example.com -$ cd /opt/git/my_project.git +$ cd /srv/git/my_project.git $ git init --bare --shared ---- -You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. -Now you're ready to collaborate on the same project. +Βλέπουμε πόσο εύκολο είναι να πάρουμε ένα αποθετήριο Git, να δημιουργήσουμε μια γυμνή έκδοσή του και να την τοποθετήσουμε σε έναν διακομιστή στον οποίο εμείς και οι συνεργάτες μας έχουμε πρόσβαση μέσω SSH. +Τώρα είμαστε έτοιμοι να συνεργαστούμε στο ίδιο έργο. -It's important to note that this is literally all you need to do to run a useful Git server to which several people have access – just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. -You're ready to go – nothing else needed. +Είναι σημαντικό να σημειωθεί ότι αυτό είναι κυριολεκτικά το μόνο που χρειάζεται να κάνουμε για να τρέξουμε έναν χρήσιμο διακομιστή Git στον οποίο έχουν πρόσβαση πολλοί χρήστες -- απλά προσθέτουμε λογαριασμούς SSH σε έναν διακομιστή και ρίχνουμε ένα γυμνό αποθετήριο κάπου όπου όλοι αυτοί οι χρήστες έχουν πρόσβαση ανάγνωσης/εγγραφής. +Είμαστε έτοιμοι -- δεν χρειάζεται τίποτα άλλο. -In the next few sections, you'll see how to expand to more sophisticated setups. -This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs and more. -However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. +Στις επόμενες ενότητες θα δούμε πώς μπορούμε να επεκταθούμε σε πιο εξεζητημένες ρυθμίσεις. +Αυτή η συζήτηση θα περιλαμβάνει το πώς να αποφύγουμε τη δημιουργία λογαριασμού για κάθε χρήστη, την προσθήκη δημόσιας πρόσβασης ανάγνωσης σε αποθετήρια, την εγκατάσταση UI ιστού και πολλά άλλα. +Ωστόσο, έχουμε υπόψη ότι για να συνεργαστούμε με άλλους σε ένα ιδιωτικό έργο, το μόνο που _χρειαζόμαστε_ είναι ένας διακομιστής SSH και ένα γυμνό αποθετήριο. -==== Small Setups +==== Μικρές εγκαταστάσεις -If you're a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. -One of the most complicated aspects of setting up a Git server is user management. -If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit more difficult to arrange. +Εάν είμαστε μια μικρή επιχείρηση ή απλώς δοκιμάζουμε το Git στον οργανισμό μας και έχουμε μόνο λίγους προγραμματιστές, τα πράγματα είναι απλά. +Μια από τις πιο περίπλοκες πτυχές της εγκατάστασης ενός διακομιστή Git είναι η διαχείριση των χρηστών. +Εάν θελούμε μερικά αποθετήρια να είναι πρόσβασιμα από ορισμένους χρήστες μόνο-για-ανάγνωση και για ανάγνωση/εγγραφή από άλλους, η πρόσβαση και τα δικαιώματα μπορεί να είναι λίγο πιο δύσκολο να ρυθμιστούν. -===== SSH Access +===== Πρόσβαση μέσω SSH (((serving repositories, SSH))) -If you have a server to which all your developers already have SSH access, it's generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). -If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs. +Εάν έχουμε έναν διακομιστή στον οποίο όλοι οι προγραμματιστές μας έχουν ήδη πρόσβαση SSH, είναι γενικά ευκολότερο να δημιουργήσουμε το πρώτο αποθετήριό μας σε αυτόν, επειδή δεν χρειάζεται να κάνουμε σχεδόν καθόλου δουλειά (όπως συζητήθηκε στην προηγούμενη ενότητα). +Αν θελούμε πιο πολύπλοκα είδη δικαιωμάτων ελέγχου πρόσβασης στα αποθετήριά μας, μπορούμε να τα χειριστούμε με τα δικαιώματα συστήματος αρχείων του λειτουργικού συστήματος που τρέχει ο διακομιστής μας. -If you want to place your repositories on a server that doesn't have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them. -We assume that if you have a server with which to do this, you already have an SSH server installed, and that's how you're accessing the server. +Εάν θελούμε να τοποθετήσουμε τα αποθετήριά μας σε έναν διακομιστή που δεν διαθέτει λογαριασμούς για όλα τα μέλη της ομάδας μας για τα οποία θελούμε να έχουν δικαίωμα εγγραφής, τότε πρέπει να τους δώσουμε πρόσβαση SSH. +Αν έχουμε έναν διακομιστή με τον οποίο μπορούμε να τα κάνουμε αυτά, τότε έχουμε ήδη εγκατεστημένο έναν διακομιστή SSH και έτσι έχουμε πρόσβαση στον διακομιστή. -There are a few ways you can give access to everyone on your team. -The first is to set up accounts for everybody, which is straightforward but can be cumbersome. -You may not want to run `adduser` and set temporary passwords for every user. +Υπάρχουν μερικοί τρόποι με τους οποίους μπορούμε να δώσουμε πρόσβαση σε όλους στην ομάδα μας. +Ο πρώτος είναι να δημιουργήσουμε λογαριασμούς για όλους, κάτι που είναι απλό, αλλά μπορεί να είναι κουραστικό. +Μπορεί να μην θελούμε να τρέξουμε το `adduser` (ή το εναλλακτικό `useradd`) και να ορίσουμε προσωρινούς κωδικούς πρόσβασης για κάθε χρήστη. -A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. -At that point, everyone will be able to access that machine via the 'git' user. -This doesn't affect the commit data in any way – the SSH user you connect as doesn't affect the commits you've recorded. +Μια δεύτερη μέθοδος είναι να δημιουργήσουμε έναν μοναδικό χρήστη 'git' στο μηχάνημα, να ζητήσουμε από κάθε χρήστη που θα έχει πρόσβαση εγγραφής να μας στείλει ένα δημόσιο κλειδί SSH και να προσθέσουμε αυτό το κλειδί στο αρχείο `~/.ssh/authorized_keys` του νέου χρήστη 'git'. +Σε αυτό το σημείο, όλοι θα μπορούν να έχουν πρόσβαση σε αυτό το μηχάνημα μέσω του 'git' λογαριασμού. +Αυτό δεν επηρεάζει τα δεδομένα των υποβολών με κανέναν τρόπο -- ο χρήστης SSH που συνδέεται δεν επηρεάζει τις υποβολές που έχουμε καταγράψει. -Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. -As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work. +Ένας άλλος τρόπος είναι να στήσουμε τον διακομιστή SSH ώστρε να ταυτοποιεί μέσω ενός διακομιστή LDAP ή κάποια άλλη κεντρική πηγή ταυτοποίησης που ενδεχομένως έχουμε ήδη ρυθμίσει. +Εφόσον ο κάθε χρήστης μπορεί να αποκτήσει πρόσβαση στο κέλυφος, οποιοσδήποτε μηχανισμός ταυτοποίησης SSH που μπορούμε να σκεφτούμε θα πρέπει να λειτουργεί. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index f04943dcf..f576f4b4d 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -1,131 +1,130 @@ === GitLab (((serving repositories, GitLab)))(((GitLab))) -GitWeb is pretty simplistic though. -If you're looking for a more modern, fully featured Git server, there are some several open source solutions out there that you can install instead. -As GitLab is one of the more popular ones, we'll cover installing and using it as an example. -This is a bit more complex than the GitWeb option and likely requires more maintenance, but it is a much more fully featured option. +Το GitWeb είναι αρκετά απλοϊκό. +Αν ψάχνουμε για έναν πιο σύγχρονο διακομιστή Git με πολλές λειτουργικότητες, υπάρχουν μερικές λύσεις ανοιχτού κώδικα που μπορούμε να εγκαταστήσουμε αντ' αυτού. +Καθώς το GitLab είναι μία από τις πιο δημοφιλείς, θα δούμε την εγκατάσταση και χρήση του ως παράδειγμα. +Η εγκατάσταση του GitLab είναι λίγο πιο περίπλοκη από αυτή του GitWeb και πιθανότα απαιτεί περισσότερη συντήρηση, αλλά είναι μια επιλογή με πολύ περισσότερα χαρακτηριστικά. -==== Installation +==== Εγκατάσταση -GitLab is a database-backed web application, so its installation is a bit more involved than some other git servers. -Fortunately, this process is very well-documented and supported. +Το GitLab είναι μια διαδικτυακή εφαρμογή που βασίζεται σε βάση δεδομένων, συνεπώς η εγκατάστασή του είναι πιο απαιτητική από ότι άλλων διακομιστών Git. +Ευτυχώς, αυτή η διαδικασία έχει πολύ καλή τεκμηρίωση και υποστήριξη. +Το GitLab συνιστά ιδιαιτέρως την εγκατάσταση του GitLab στον διακομιστή μας μέσω του επίσημου πακέτου Omnibus GitLab. -There are a few methods you can pursue to install GitLab. -To get something up and running quickly, you can download a virtual machine image or a one-click installer from https://bitnami.com/stack/gitlab[], and tweak the configuration to match your particular environment.(((bitnami))) -One nice touch Bitnami has included is the login screen (accessed by typing alt-→); it tells you the IP address and default username and password for the installed GitLab. +Οι άλλες επιλογές εγκατάστασης είναι: -[[bitnami]] -.The Bitnami GitLab virtual machine login screen. -image::images/bitnami.png[The Bitnami GitLab virtual machine login screen.] +* Χάρτης GitLab Helm, για χρήση με το Kubernetes. +* Docker-οποιημένα πακέτα GitLab για χρήση με το Docker. +* Από πηγαίο κώδικα. +* Προμηθευτές cloud όπως οι AWS, Google Cloud Platform, Azure, OpenShift και Digital Ocean. -For anything else, follow the guidance in the GitLab Community Edition readme, which can be found at https://gitlab.com/gitlab-org/gitlab-ce/tree/master[]. -There you'll find assistance for installing GitLab using Chef recipes, a virtual machine on Digital Ocean, and RPM and DEB packages (which, as of this writing, are in beta). -There's also ``unofficial'' guidance on getting GitLab running with non-standard operating systems and databases, a fully-manual installation script, and many other topics. +Για περισσότερες πληροφορίες βλ. το https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/README.md[GitLab Community Edition (CE) readme^]. -==== Administration +==== Διαχείριση -GitLab's administration interface is accessed over the web. -Simply point your browser to the hostname or IP address where GitLab is installed, and log in as an admin user. -The default username is `admin@local.host`, and the default password is `5iveL!fe` (which you will be prompted to change as soon as you enter it). -Once logged in, click the ``Admin area'' icon in the menu at the top right. +Η διεπαφή διαχείρισης του GitLab είναι προσπελάσιμη μέσα από το web. +Απλά οδηγούμε το πρόγραμμα περιήγησής μας στο hostname ή τη διεύθυνση IP στην οποία είναι εγκατεστημένο το GitLab και συνδεόμαστε ως χρήστης `root`. +Ο κωδικός βασίζεται στον τύπο εγκατάστασης αλλά από προεπιλογή, ο Omnibus GitLab αυτόαματα δημιουργεί κωδικό και τον αποθηκεύει στο /etc/gitlab/initial_root_password για τουλάχιστον 24 ώρες. +Για περισσότερες πληροφορίες ακουλουθούμε το εγχειρίδιο. +Μόλις συνδεθούμε, κάνουμε κλικ στο εικονίδιο "`Admin area`" στο επάνω δεξιά μενού. -[[gitlab_menu]] -.The ``Admin area'' item in the GitLab menu. -image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu.] +[[rgitlab_menu]] +.Το εικονίδιο "`Admin area`" στο μενού του GitLab +image::images/gitlab-menu.png[Το εικονίδιο "`Admin area`" στο μενού του GitLab] -===== Users +===== Χρήστες -Users in GitLab are accounts that correspond to people. -User accounts don't have a lot of complexity; mainly it's a collection of personal information attached to login data. -Each user account comes with a *namespace*, which is a logical grouping of projects that belong to that user. -If the user +jane+ had a project named +project+, that project's url would be http://server/jane/project[]. +Όλοι όσοι χρησιμοποιούν τον διακομιστή GitLab πρέπει να έχουν λογαριασμό χρήστη. +Οι λογαριασμοί χρηστών είναι πολύ απλοί· βασικά είναι μια συλλογή προσωπικών πληροφοριών προσαρτημένα σε δεδομένα σύνδεσης. +Κάθε λογαριασμός χρήστη συνοδεύεται από έναν *ονοματοχώρο* (namespace), το οποίο είναι μια λογική ομαδοποίηση έργων που ανήκουν σε αυτόν τον χρήστη. +Εάν ο χρήστης +jane+ είχε ένα έργο με όνομα +project+, η διεύθυνση URL του έργου θα ήταν `http://server/jane/project`. -[[gitlab_users]] -.The GitLab user administration screen. -image::images/gitlab-users.png[The GitLab user administration screen.] +[[rgitlab_users]] +.Η οθόνη διαχείρισης χρηστών του GitLab +image::images/gitlab-users.png[Η οθόνη διαχείρισης χρηστών του GitLab] -Removing a user can be done in two ways. -``Blocking'' a user prevents them from logging into the GitLab instance, but all of the data under that user's namespace will be preserved, and commits signed with that user's email address will still link back to their profile. +Μπορούμε να καταργήσουμε ένα χρήστη με δύο τρόπους: +Αν "`μπλοκάρουμε`" ενα χρήστη τον εμποδίζουμε να συνδεθεί στο στιγμιότυπο (instance) του GitLab, αλλά όλα τα δεδομένα κάτω από τον ονοματοχώρο του χρήστη θα διατηρηθούν και οι υποβολές που έχει υπογράψει με τη διεύθυνση e-mail του χρήστη θα εξακολουθούν να είναι συνδεδεμένες στο προφίλ του. -``Destroying'' a user, on the other hand, completely removes them from the database and filesystem. -All projects and data in their namespace is removed, and any groups they own will also be removed. -This is obviously a much more permanent and destructive action, and its uses are rare. +Αν "`καταστρέψουμε`" ένα χρήστη, τον αφαιρούμε εντελώς από τη βάση δεδομένων και το σύστημα αρχείων. +Όλα τα έργα και τα δεδομένα στον ονοματοχώρο του θα διαγραφούν και οι ομάδες που ενδεχομένως του ανήκουν θα διαγραφούν επίσης. +Αυτή είναι προφανώς μια πολύ πιο μόνιμη και καταστροφική ενέργεια και σπάνια θα τη χρειαστούμε. -[[_gitlab_groups_section]] -===== Groups +[[r_gitlab_groups_section]] +===== Ομάδες -A GitLab group is an assemblage of projects, along with data about how users can access those projects. -Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be http://server/training/materials[]. +Μια ομάδα (group) στο GitLab είναι μια συλλογή έργων μαζί με δεδομένα σχετικά με τον τρόπο με τον οποίο οι χρήστες έχουν πρόσβαση σε αυτά τα έργα. +Κάθε ομάδα έχει ένα ονοματοχώρο έργου (ακριβώς όπως και οι χρήστες), οπότε αν η ομάδα +training+ έχει ένα έργο +materials+, η διεύθυνση URL του θα είναι `http://server/training/materials`. -[[gitlab_groups]] -.The GitLab group administration screen. -image::images/gitlab-groups.png[The GitLab group administration screen.] +[[rgitlab_groups]] +.Οθόνη διαχείρισης ομάδων του GitLab +image::images/gitlab-groups.png[Οθόνη διαχείρισης ομάδων του GitLab] -Each group is associated with a number of users, each of which has a level of permissions for the group's projects and the group itself. -These range from ``Guest'' (issues and chat only) to ``Owner'' (full control of the group, its members, and its projects). -The types of permissions are too numerous to list here, but GitLab has a helpful link on the administration screen. +Κάθε ομάδα συσχετίζεται με έναν αριθμό χρηστών, καθένας από τους οποίους έχει το δικό του επίπεδο δικαιωμάτων για τα έργα της ομάδας και την ίδια την ομάδα. +Αυτά ποικίλλουν από "`Guest`" (επισκέπτης) (έχουν πρόσβαση μόνον σε θέματα και chat) μέχρι "`Owner`" (κάτοχος) (έχει πλήρης έλεγχο της ομάδας, των μελών και των έργων της). +Οι τύποι δικαιωμάτων είναι πάρα πολλοί για να τους αναφέρουμε εδώ, αλλά το GitLab έχει έναν σχετικό χρήσιμο σύνδεσμο στην οθόνη διαχείρισης. -===== Projects +===== Έργα -A GitLab project roughly corresponds to a single git repository. -Every project belongs to a single namespace, either a user or a group. -If the project belongs to a user, the owner of the project has direct control over who has access to the project; if the project belongs to a group, the group's user-level permissions will also take effect. +Ένα έργο του GitLab αντιστοιχίζεται πάνω-κάτω σε ένα αποθετήριο Git. +Κάθε έργο ανήκει σε ένα μοναδικό ονοματοχώρο· είτε σε έναν χρήστη είτε σε μια ομάδα. +Αν το έργο ανήκει σε χρήστη, ο ιδιοκτήτης του έργου έχει άμεσο έλεγχο για το ποιος έχει πρόσβαση στο έργο· αν το έργο ανήκει σε μια ομάδα, θα ισχύουν τα δικαιώματα χρήστη της ομάδας. -Every project also has a visibility level, which controls who has read access to that project's pages and repository. -If a project is _Private_, the project's owner must explicitly grant access to specific users. -An _Internal_ project is visible to any logged-in user, and a _Public_ project is visible to anyone. -Note that this controls both git ``fetch'' access as well as access to the web UI for that project. +Κάθε έργο έχει επίσης ένα επίπεδο ορατότητας, το οποίο ελέγχει ποιος έχει πρόσβαση στη σελίδα και το αποθετήριο αυτού του έργου. +Εάν ένα έργο είναι _Private_ (ιδιωτικό), ο κάτοχος του έργου πρέπει να παρέχει ρητά πρόσβαση σε συγκεκριμένους χρήστες. +Ένα _Internal_ (εσωτερικό) έργο είναι ορατό σε οποιονδήποτε συνδεδεμένο χρήστη και ένα _Public_ (δημόσιο) έργο είναι ορατό σε οποιονδήποτε. +Σημειώνουμε ότι το επίπεδο ορατότητας του έργου ελέγχει τόσο την πρόσβαση `git fetch`, όσο και την πρόσβαση στη διαδικτυακή διεπαφή χρήστη (web UI) για αυτό το έργο. -===== Hooks +===== Άγκιστρα -GitLab includes support for hooks, both at a project or system level. -For either of these, the GitLab server will perform an HTTP POST with some descriptive JSON whenever relevant events occur. -This is a great way to connect your git repositories and GitLab instance to the rest of your development automation, such as CI servers, chat rooms, or deployment tools. +Το GitLab περιλαμβάνει υποστήριξη για άγκιστρα (hooks), τόσο σε επίπεδο έργου όσο και σε επίπεδο συστήματος. +Και για τα δύο και κάθε φορά που προκύπτουν σχετικά γεγονότα, ο διακομιστής GitLab θα εκτελέσει ένα HTTP POST με κάποια περιγραφικά JSON. +Αυτός είναι ένας πολύ καλός τρόπος σύνδεσης των αποθετηρίων μας Git και του στιγμιότυπου GitLab με τον υπόλοιπο αυτοματισμό της ανάπτυξης του έργου, όπως οι διακομιστές CI, οι χώροι συνομιλίας (chat rooms) και τα εργαλεία ανάπτυξης. -==== Basic Usage +==== Βασική χρήση -The first thing you'll want to do with GitLab is create a new project. -This is accomplished by clicking the ``+'' icon on the toolbar. -You'll be asked for the project's name, which namespace it should belong to, and what its visibility level should be. -Most of what you specify here isn't permanent, and can be re-adjusted later through the settings interface. -Click ``Create Project'', and you're done. +Το πρώτο πράγμα που θα θελήσουμε να κάνουμε με το GitLab είναι να δημιουργήσουμε ένα νέο έργο. +Αυτό επιτυγχάνεται με κλικ στο εικονίδιο "`+`" στη γραμμή εργαλείων. +Θα μας ζητηθεί το όνομα του έργου, ο ονοματοχώρος στον οποίο θέλουμε να ανήκει και το επίπεδο ορατότητάς του. +Τα περισσότερα στοιχεία από αυτά δεν είναι μόνιμα και μπορούν να επαναρυθμιστούν αργότερα στις ρυθμίσεις. +Κάνουμε κλικ στο κουμπί "`Create Project`" και τελειώσαμε. -Once the project exists, you'll probably want to connect it with a local Git repository. -Each project is accessible over HTTPS or SSH, either of which can be used to configure a Git remote. -The URLs are visible at the top of the project's home page. -For an existing local repository, this command will create a remote named `gitlab` to the hosted location: +Από τη στιγμή που το έργο αρχίζει να υπάρχει, το πιθανότερο είναι να θελήσουμε να το συνδέσουμε με ένα τοπικό αποθετήριο Git. +Κάθε έργο είναι προσβάσιμο μέσω HTTPS ή SSH, καθένα από τα οποία μπορεί να χρησιμοποιηθεί για να οριστούν οι ρυθμίσεις κατά τη διαμόρφωση ενός απομακρυσμένου Git. +Οι διευθύνσεις URL είναι ορατές στο επάνω μέρος της αρχικής σελίδας του έργου. +Αν έχουμε ένα τοπικό αποθετήριο, με την παρακάτω εντολή θα δημιουργήσουμε ένα απομακρυσμένο αποθετήριο με όνομα `gitlab` στη φιλοξενούμενη τοποθεσία: [source,console] ---- $ git remote add gitlab https://server/namespace/project.git ---- -If you don't have a local copy of the repository, you can simply do this: +Εάν δεν έχουμε τοπικό αντίγραφο του αποθετηρίου, μπορούμε απλά να τρέξουμε το εξής: [source,console] ---- $ git clone https://server/namespace/project.git ---- -The web UI provides access to several useful views of the repository itself. -Each project's home page shows recent activity, and links along the top will lead you to views of the project's files and commit log. +Η διεπαφή χρήστη web παρέχει πρόσβαση σε πολλές χρήσιμες προβολές του ίδιου του αποθετηρίου. +Η αρχική σελίδα του κάθε έργου παρουσιάζει την πρόσφατη δραστηριότητα και οι συνδέσεις στην κορυφή θα μας οδηγήσουν σε προβολές των αρχείων του έργου και του αρχείου καταγραφής υποβολών. -==== Working Together +==== Συνεργασίες -The simplest way of working together on a GitLab project is by giving another user direct push access to the git repository. -You can add a user to a project by going to the ``Members'' section of that project's settings, and associating the new user with an access level (the different access levels are discussed a bit in <<_gitlab_groups_section>>). -By giving a user an access level of ``Developer'' or above, that user can push commits and branches directly to the repository with impunity. +Ο απλούστερος τρόπος συνεργασίας σε ένα έργο GitLab είναι να δώσουμε στον άλλο χρήστη δικαίωμα άμεσης ώθησης στο αποθετήριο Git. +Μπορούμε να προσθέσουμε έναν χρήστη σε ένα έργο πηγαίνοντας στην ενότητα "`Members`" (Μέλη) των ρυθμίσεων του συγκεκριμένου έργου και δίνοντας στον νέο χρήστη ένα επίπεδο πρόσβασης (τα διάφορα επίπεδα πρόσβασης αναλύονται λίγο στην ενότητα <>). +Παρέχοντας στον χρήστη επίπεδο πρόσβασης "`Developer`" (προγραμματιστή) ή ανώτερο, ο χρήστης μπορεί να ωθήσει υποβολές και κλάδους απευθείας στο αποθετήριο. -Another, more decoupled way of collaboration is by using merge requests. -This feature enables any user that can see a project to contribute to it in a controlled way. -Users with direct access can simply create a branch, push commits to it, and open a merge request from their branch back into `master` or any other branch. -Users who don't have push permissions for a repository can ``fork'' it (create their own copy), push commits to _that_ copy, and open a merge request from their fork back to the main project. -This model allows the owner to be in full control of what goes into the repository and when, while allowing contributions from untrusted users. +Ένας άλλος, πιο ελεγχόμενος τρόπος συνεργασίας είναι με τη χρήση αιτήσεων συγχώνευσης (merge requests). +Αυτή η δυνατότητα επιτρέπει σε κάθε χρήστη που μπορεί να δει ένα έργο να συνεισφέρει σε αυτό με ελεγχόμενο τρόπο. +Οι χρήστες με άμεση πρόσβαση μπορούν απλά να δημιουργήσουν έναν κλάδο, να ωθήσουν υποβολές σε αυτόν και να θέσουν ένα αίτημα συγχώνευσης από τον κλάδο τους στον κλάδο `master` ή σε οποιονδήποτε άλλο κλάδο. +Οι χρήστες που δεν έχουν δικαίωμα ώθησης σε ένα αποθετήριο μπορούν να το αποσχίσουν (fork) (δηλ. να δημιουργήσουν το δικό τους αντίγραφο), να ωθούν υποβολές σε _αυτό_ το αντίγραφο και να κάνουν αίτημα συγχώνευσης από το αντίγραφό τους στο κύριο έργο. +Αυτό το μοντέλο επιτρέπει στον κάτοχο να έχει τον πλήρη έλεγχο του τι πηγαίνει στο αποθετήριο και πότε, καθώς επιτρέπει συνεισφορές και από μη αξιόπιστους χρήστες. -Merge requests and issues are the main units of long-lived discussion in GitLab. -Each merge request allows a line-by-line discussion of the proposed change (which supports a lightweight kind of code review), as well as a general overall discussion thread. -Both can be assigned to users, or organized into milestones. +Τα αιτήματα συγχώνευσης και τα ζητήματα που προκύπτουν είναι τα κύρια θέματα μακροχρόνιων συζητήσεων στο GitLab. +Κάθε αίτηση συγχώνευσης επιτρέπει μια γραμμή-προς-γραμμή συζήτηση για την προτεινόμενη αλλαγή (η οποία υποστηρίζει ένα ελαφρύ είδος αναθεώρησης κώδικα) καθώς και ένα νήμα γενικής συζήτησης. +Και οι δύο μπορούν να ανατεθούν σε χρήστες ή να οργανωθούν σε ορόσημα (milestones). -This section is focused mainly on the Git-related features of GitLab, but as a mature project, it provides many other features to help your team work together, such as project wikis and system maintenance tools. -One benefit to GitLab is that, once the server is set up and running, you'll rarely need to tweak a configuration file or access the server via SSH; most administration and general usage can be accomplished through the in-browser interface. +Αυτή η ενότητα επικεντρώθηκε κυρίως στις λειτουργίες του GitLab που σχετίζονται με το Git, αλλά ως ώριμο έργο, παρέχει κι άλλες πολλές λειτουργικότητες που βοηθούν την ομάδα μας να συνεργάζεται, όπως τα εργαλεία wiki και τα εργαλεία συντήρησης του συστήματος. +Ένα πλεονέκτημα για το GitLab είναι από τη στιγμή που θα εγκαταστήσουμε και ξεκινήσουμε τον διακομιστή, σπάνια θα χρειαστεί να τροποποιήσουμε κάποιο αρχείο παραμετροποίησης ή πρόσβασης στον διακομιστή μέσω SSH· σχεδόν όλη η διαχείριση και γενική χρήση μπορούν να γίνουν μέσω της διεπαφής στο πρόγραμμα περιήγησης. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index 4ff18bbc6..428b36434 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -1,17 +1,17 @@ === GitWeb (((serving repositories, GitWeb)))(((GitWeb))) -Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. -Git comes with a CGI script called GitWeb that is sometimes used for this. +Τώρα που έχουμε βασική πρόσβαση ανάγνωσης/εγγραφής και μόνο-για-ανάγνωση στο έργο μας, ίσως θελήσουμε να δημιουργήσουμε ένα απλό οπτικοκοποιητή (visualizer) ιστού. +Το Git συνοδεύεται από ένα script CGI που ονομάζεται GitWeb και χρησιμοποιείται μερικές φορές για αυτό τον σκοπό. -[[gitweb]] -.The GitWeb web-based user interface. -image::images/git-instaweb.png[The GitWeb web-based user interface.] +[[r_gitweb]] +.Η διεπαφή χρήστη του GitWeb +image::images/git-instaweb.png[Η διεπαφή χρήστη του GitWeb] -If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. -On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. -If you're running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. -To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.(((git commands, instaweb))) +Αν θέλουμε να δούμε πώς θα μοιάζει το GitWeb για το έργο μας, το Git παρέχει με μια εντολή που ενεργοποιεί ένα προσωρινό στιγμιότυπο (instance) αν έχουμε έναν ελαφρύ διακομιστή στο σύστημά μας όπως τον `lighttpd` ή τον `webrick`. +Στα μηχανήματα Linux, ο `lighttpd` είναι συχνά εγκατεστημένος, οπότε ίσως μπορούμε να τον τρέξουμε εκτελώντας `git instaweb` στον κατάλογο του έργου. +Εάν τρέχουμε Mac, το Leopard έρχεται προεγκατεστημένο με Ruby, έτσι το πιθανότερο είνα να είναι διαθέσιμος ο `webrick`. +Για να ξεκινήσουμε το `instaweb` με handler που δεν είναι lighttpd, μπορούμε να το εκτελέσουμε με την επιλογή `--httpd`. (((εντολές git, instaweb))) [source,console] ---- @@ -20,25 +20,25 @@ $ git instaweb --httpd=webrick [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] ---- -That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. -It's pretty easy on your part. -When you're done and want to shut down the server, you can run the same command with the `--stop` option: +Αυτό εκκινεί έναν διακομιστή HTTPD στη θύρα 1234 και στη συνέχεια ξεκινά αυτόματα ένα πρόγραμμα περιήγησης που ανοίγει σε αυτή τη σελίδα. +Είναι τόσο εύκολο. +Όταν τελειώσουμε και θέλουμε να τερματίσουμε τη λειτουργία του διακομιστή, μπορούμε να εκτελέσουμε την ίδια εντολή με την επιλογή `--stop`: [source,console] ---- $ git instaweb --httpd=webrick --stop ---- -If you want to run the web interface on a server all the time for your team or for an open source project you're hosting, you'll need to set up the CGI script to be served by your normal web server. -Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. -We'll walk through installing GitWeb manually very quickly. -First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: +Εάν θέλουμε να τρέχουμε συνεχώς τη διεπαφή ιστού σε έναν διακομιστή για την ομάδα μας ή για ένα έργο ανοιχτού κώδικα που φιλοξενούμε, θα πρέπει να ρυθμίσουμε το script CGI να προσφέρεται από τον συνηθισμένο web server μας. +Ορισμένες διανομές Linux έχουν ένα πακέτο `gitweb` που μπορούμε να εγκαταστήσουμε με `apt` ή `dnf`, επομένως ίσως είναι καλό να δοκιμάσουμε αυτό πρώτα. +Θα δείξουμε τη χειροκίνητη εγκατάσταση του GitWeb πολύ συνοπτικά. +Πρώτα πρέπει να πάρουμε τον πηγαίο κώδικα του Git, με τον οποίο έρχεται το GitWeb, και να δημιουργήσουμε το προσαρμοσμένο script CGI: [source,console] ---- -$ git clone git://git.kernel.org/pub/scm/git/git.git +$ git clone https://git.kernel.org/pub/scm/git/git.git $ cd git/ -$ make GITWEB_PROJECTROOT="/opt/git" prefix=/usr gitweb +$ make GITWEB_PROJECTROOT="/srv/git" prefix=/usr gitweb SUBDIR gitweb SUBDIR ../ make[2]: `GIT-VERSION-FILE' is up to date. @@ -47,8 +47,8 @@ make[2]: `GIT-VERSION-FILE' is up to date. $ sudo cp -Rf gitweb /var/www/ ---- -Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. -Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: +Παρατηρούμε ότι πρέπει να πούμε στην εντολή πού να βρει τα αποθετήρια Git με τη μεταβλητή `GITWEB_PROJECTROOT`. +Τώρα, πρέπει να κάνουμε το Apache να χρησιμοποιεί CGI για αυτό το script και για αυτόν τον σκοπό μπορούμε να προσθέσουμε ένα VirtualHost: [source,console] ---- @@ -56,7 +56,7 @@ Now, you need to make Apache use CGI for that script, for which you can add a Vi ServerName gitserver DocumentRoot /var/www/gitweb - Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch + Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch AllowOverride All order allow,deny Allow from all @@ -66,5 +66,5 @@ Now, you need to make Apache use CGI for that script, for which you can add a Vi ---- -Again, GitWeb can be served with any CGI or Perl capable web server; if you prefer to use something else, it shouldn't be difficult to set up. -At this point, you should be able to visit `http://gitserver/` to view your repositories online. +Επαναλαμβάνουμε ότι το GitWeb μπορεί να εξυπηρετηθεί από οποιονδήποτε web server, CGI ή Perl· αν προτιμάμε να χρησιμοποιήσουμε κάτι άλλο, δεν θα είναι δύσκολο να το εγκαταστήσουμε. +Σε αυτό το σημείο, θα πρέπει να μπορούμε να επισκεφτούμε την `http://gitserver/` για να δούμε τα αποθετήριά μας online. diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index e9b8b06f2..ba0c26ccc 100644 --- a/book/04-git-server/sections/hosted.asc +++ b/book/04-git-server/sections/hosted.asc @@ -1,10 +1,10 @@ -=== Third Party Hosted Options +=== Επιλογές φιλοξενίας από τρίτους -If you don't want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. -Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. -Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with. +Εάν θέλουμε να αποφύγουμε όλη τη δουλειά που εμπλέκεται στην εγκατάσταση του δικού μας διακομιστή Git, έχουμε αρκετές επιλογές για τη φιλοξενία των έργων μας σε έναν εξωτερικό, αποκλειστικό ιστότοπο φιλοξενίας. +Αυτή η επιλογή προσφέρει κάποια πλεονεκτήματα: ένας χώρος φιλοξενίας στήνεται γενικά γρήγορα και είναι εύκολο να εκκινήσουμε έργα σε αυτόν, ενώ δεν χρειάζεται να κάνουμε καμία συντήρηση ή παρακολούθηση του διακομιστή. +Ακόμα κι αν έχουμε εγκαταστήσει και τρέξει εσωτερικά τον δικό μας διακομιστή, μπορεί να θέλουμε να χρησιμοποιήσουμε έναν δημόσιο ιστότοπο φιλοξενίας για τον ανοιχτό κώδικά μας -- γενικά είναι ευκολότερο για την κοινότητα ανοιχτού κώδικα να μας βρει και να μας βοηθήσει. -These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. -To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[] +Σήμερα υπάρχει ένας τεράστιος αριθμός επιλογών φιλοξενίας από τους οποίους μπορούμε να διαλέξουμε, η καθεμία με διαφορετικά πλεονεκτήματα και μειονεκτήματα. +Μπορούμε να βρούμε μια ενημερωμένη λίστα στη σελίδα GitHosting στο κύριο wiki Git στη διεύθυνση https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHosting.html[^]. -We'll cover using GitHub in detail in <<_github>>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server. +Στο κεφάλαιο <> θα καλύψουμε τη χρήση του GitHub, διότι αυτός είναι ο μεγαλύτερος διακομιστής Git και ούτως ή άλλως ίσως χρειαστεί να αλληλεπιδράσουμε με τα έργα που φιλοξενούνται σε αυτόν, αλλά υπάρχουν και άλλοι δεκάδες διακομιστές Git από τους οποίους μπορούμε επιλέξουμε αν δεν θέλουμε να δημιουργήσουμε τον δικό μας διακομιστή Git. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 81c9e3001..4638c9c5a 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -1,98 +1,98 @@ -=== The Protocols +=== Τα πρωτόκολλα -Git can use four major protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. -Here we'll discuss what they are and in what basic circumstances you would want (or not want) to use them. +Το Git μπορεί να χρησιμοποιήσει τέσσερα διαφορετικά πρωτόκολλα για τη μεταφορά δεδομένων: Local, HTTP, Secure Shell (SSH) και Git. +Θα συζητήσουμε τι είναι αυτά τα πρωτόκολλα και σε ποιες βασικές περιστάσεις θέλουμε (ή δεν θέλουμε) να τα χρησιμοποιήσουμε. -==== Local Protocol +==== Το τοπικό πρωτόκολλο -(((protocols, local))) -The most basic is the _Local protocol_, in which the remote repository is in another directory on disk. -This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. -The latter wouldn't be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. +(((πρωτόκολλα, τοπικό))) +Το πιο βασικό είναι το _τοπικό πρωτόκολλο_, στο οποίο το απομακρυσμένο αποθετήριο βρίσκεται σε άλλο κατάλογο στον δίσκο. +Αυτό χρησιμοποιείται συχνά εάν όλοι στην ομάδα μας έχουν πρόσβαση σε ένα κοινό σύστημα αρχείων (filesystem), όπως https://en.wikipedia.org/wiki/Network_File_System[NFS^] mount ή στη σχετικά σπάνια περίπτωση που όλοι οι χρήστες συνδέονται στον ίδιο υπολογιστή. +Η τελευταία περίπτωση είναι λιγότερο ιδανική, διότι όλα τα στιγμιότυπα κώδικα του αποθετηρίου θα βρίσκονται στον ίδιο υπολογιστή, καθιστώντας πολύ πιο πιθανή μια καταστροφική απώλεια. -If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. -To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. -For example, to clone a local repository, you can run something like this: +Εάν διαθέτουμε ένα κοινόχρηστο σύστημα αρχείων, μπορούμε να κλωνοποιήσουμε, να ωθήσουμε σε και να έλξουμε από ένα αποθετήριο που βασίζεται σε τοπικά αρχεία. +Για να κλωνοποιήσουμε ένα αποθετήριο όπως αυτό ή για να το προσθέσουμε ως απομακρυσμένο σε ένα υπάρχον έργο, χρησιμοποιούμε τη διαδρομή (path) του αποθετηρίου ως διεύθυνση URL. +Για παράδειγμα, για να κλωνοποιήσουμε ένα τοπικό αποθετήριο, μπορούμε να εκτελέσουμε κάτι σαν: [source,console] ---- -$ git clone /opt/git/project.git +$ git clone /srv/git/project.git ---- -Or you can do this: +Ή κάτι σαν: [source,console] ---- -$ git clone file:///opt/git/project.git +$ git clone file:///srv/git/project.git ---- -Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. -If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. -If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. -The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out – generally after an import from another version-control system or something similar (see <<_git_internals>> for maintenance tasks). -We'll use the normal path here because doing so is almost always faster. +Το Git λειτουργεί ελαφρώς διαφορετικά αν καθορίσουμε ρητά το `file://` στην αρχή της διεύθυνσης URL. +Αν καθορίσουμε μόνο τη διαδρομή, το Git προσπαθεί να χρησιμοποιήσει hardlinks ή να αντιγράψει απευθείας τα αρχεία που χρειάζονται. +Εάν προσθέσουμε το `file://`, το Git ενεργοποιεί τις διαδικασίες που συνήθως χρησιμοποιεί για τη μεταφορά δεδομένων μέσω δικτύου, μία μέθοδο μεταφοράς των δεδομένων γενικά πολύ λιγότερο αποτελεσματική. +Ο βασικός λόγος που θα θέλαμε να χρησιμοποιήσουμε το `file://` είναι η περίπτωση κατά την οποία θέλουμε ένα καθαρό αντίγραφο του αποθετηρίου με εξωτερικές αναφορές ή αντικείμενα που απομένουν -- συνήθως μετά από εισαγωγή από ένα άλλο σύστημα ελέγχου εκδόσεων ή κάτι παρόμοιο (βλ. <> για σχετικές εργασίες συντήρησης). +Στο παρακάτω παράδειγμα θα χρησιμοποιήσουμε τη διαδρομή χωρίς το `file://` επειδή αυτό είναι σχεδόν πάντα γρηγορότερο. -To add a local repository to an existing Git project, you can run something like this: +Για να προσθέσουμε ένα τοπικό αποθετήριο σε ένα υπάρχον έργο Git, μπορούμε να εκτελέσουμε κάτι σαν: [source,console] ---- -$ git remote add local_proj /opt/git/project.git +$ git remote add local_proj /srv/git/project.git ---- -Then, you can push to and pull from that remote as though you were doing so over a network. +Στη συνέχεια, μπορούμε να ωθήσουμε και να έλξουμε από αυτό το απομακρυσμένο αποθετήριο, με όνομα `local_proj`, σαν να το κάναμε μέσα από ένα δίκτυο. -===== The Pros +===== Τα υπέρ -The pros of file-based repositories are that they're simple and they use existing file permissions and network access. -If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. -You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. -We'll discuss how to export a bare repository copy for this purpose in <<_git_on_the_server>>. +Τα πλεονεκτήματα των αποθετηρίων που βασίζονται σε αρχεία είναι ότι είναι απλά και χρησιμοποιούν τα υπάρχοντα δικαιώματα σε αρχεία και πρόσβαση στο δίκτυο. +Εάν έχουμε ήδη ένα κοινό σύστημα αρχείων στο οποίο έχει πρόσβαση ολόκληρη η ομάδα μας, η εγκατάσταση ενός αποθετηρίου είναι πολύ εύκολη. +Μπορούμε να κολλήσουμε ένα γυμνό (χωρίς αρχεία) αντίγραφο του αποθετηρίου κάπου όπου ο καθένας έχει πρόσβαση και να ορίσουμε τα δικαιώματα ανάγνωσης/εγγραφής όπως θα κάναμε για οποιονδήποτε άλλο κοινόχρηστο κατάλογο. +Θα συζητήσουμε πώς μπορούμε να κάνουμε export ένα αντίγραφο γυμνού αποθετηρίου για αυτόν τον σκοπό αυτό στο <>. -This is also a nice option for quickly grabbing work from someone else's working repository. -If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you pulling down. +Αυτή είναι επίσης μια καλή επιλογή για γρήγορη λήψη της εργασίας από το αποθετήριο εργασίας κάποιου άλλου. +Εάν εμείς και μία συνεργάτιδά μας εργαζόμαστε στο ίδιο έργο και η συνεργάτιδά μας θέλει να ελέγξουμε τη δουλειά της, η εκτέλεση μιας εντολής όπως `git pull /home/john/project` είναι συχνά ευκολότερη από ό,τι η συνεργάτιδά μας να ωθήσει σε έναν απομακρυσμένο διακομιστή και εμείς να ανακτήσουμε από αυτόν. -===== The Cons +===== Τα κατά -The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. -If you want to push from your laptop when you're at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. +Τα μειονεκτήματα αυτής της μεθόδου είναι ότι η κοινή πρόσβαση είναι γενικά πιο δύσκολη στη ρύθμιση και πρόσβαση από πολλαπλές τοποθεσίες από ότι η βασική πρόσβαση στο δίκτυο. +Αν θέλουμε να ωθήσουμε από τον φορητό μας υπολογιστή όταν είμαστε στο σπίτι, θα πρέπει να κάνουμε mount τον απομακρυσμένο δίσκο, κάτι που ενδεχομένως είναι δύσκολο και αργό σε σύγκριση με την πρόσβαση που βασίζεται στο δίκτυο. -It's important to mention that this isn't necessarily the fastest option if you're using a shared mount of some kind. -A local repository is fast only if you have fast access to the data. -A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. +Είναι σημαντικό να αναφερθεί ότι αυτή δεν είναι απαραίτητα η γρηγορότερη επιλογή, εφόσον χρησιμοποιούμε κάποιου είδους κοινό mount. +Ένα τοπικό αποθετήριο είναι γρήγορο μόνον εφόσον έχουμε γρήγορη πρόσβαση στα δεδομένα. +Ένα αποθετήριο σε NFS είναι συχνά πιο αργό από ένα αποθετήριο με πρόσβαση SSH στον ίδιο διακομιστή, κάτι που επιτρέπει στο Git να τρέχει σε τοπικούς σε κάθε σύστημα. -Finally, this protocol does not protect the repository against accidental damage. -Every user has full shell access to the "remote" directory, and there is nothing preventing them from changing or removing internal Git files and corrupting the repository. +Τέλος, το πρωτόκολλο αυτό δεν προστατεύει το αποθετήριο από τυχαίες αστοχίες. +Όλοι οι χρήστες έχουν πλήρη πρόσβαση στο κέλυφος στον "`απομακρυσμένο`" κατάλογο και τίποτα δεν τους εμποδίζει να αλλάξουν ή να αφαιρέσουν εσωτερικά αρχεία του Git και να καταστρέψουν το αποθετήριο. -==== The HTTP Protocols +==== Πρωτόκολλα HTTP -Git can communicate over HTTP in two different modes. -Prior to Git 1.6.6 there was only one way it could do this which was very simple and generally read-only. -In version 1.6.6 a new, smarter protocol was introduced that involved Git being able to intelligently negotiate data transfer in a manner similar to how it does over SSH. -In the last few years, this new HTTP protocol has become very popular since it's simpler for the user and smarter about how it communicates. -The newer version is often referred to as the ``Smart'' HTTP protocol and the older way as ``Dumb'' HTTP. -We'll cover the newer ``smart'' HTTP protocol first. +Το Git μπορεί να επικοινωνήσει μέσω HTTP με δύο διαφορετικούς τρόπους. +Πριν από το Git 1.6.6 υπήρχε μόνον ένας τρόπος, που ήταν πολύ απλοϊκός και γενικά μόνο-για-ανάγνωση. +Στην έκδοση 1.6.6 εισήχθη ένα νέο, πιο έξυπνο πρωτόκολλο το οποίο περιλάμβανει τη δυνατότητα του Git να διαπραγματεύεται έξυπνα τη μεταφορά δεδομένων με τρόπο παρόμοιο όπως μέσω SSH. +Τα τελευταία χρόνια αυτό το νέο πρωτόκολλο HTTP έχει γίνει πολύ δημοφιλές, διότι είναι απλούστερο για τους χρήστες και πιο έξυπνο όσον αφορά στον τρόπο επικοινωνίας. +Η νεότερη έκδοση αναφέρεται συχνά ως _Έξυπνο_ HTTP και ο παλαιότερος τρόπος ως _Χαζό_ HTTP. +Θα καλύψουμε πρώτα το πιο πρόσφατο Εξυπνο HTTP. -===== Smart HTTP +===== Έξυπνο HTTP -(((protocols, smart HTTP))) -The ``smart'' HTTP protocol operates very similarly to the SSH or Git protocols but runs over standard HTTP/S ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password basic authentication rather than having to set up SSH keys. +(((πρωτόκολλα, έξυπνο HTTP))) +Το Εξυπνο HTTP έχει παρόμοια λειτουργία με τα πρωτόκολλα SSH ή Git, αλλά τρέχει στις θύρες που χρησιμοποιουνται τυπικά για HTTPS και μπορεί να χρησιμοποιήσει διάφορους μηχανισμούς ταυτοποίησης HTTP, κάτι που σημαίνει ότι είναι συχνά πιο εύχρηστο για τους χρήστες από ό,τι είναι για παράδειγμα το SSH, δεδομένου ότι επιτρέπει την ταυτοποίηση με όνομα χρήστη/κωδικό πρόσβασης, αντί για κλειδιά SSH. -It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the `git://` protocol, and can also be pushed over with authentication and encryption like the SSH protocol. -Instead of having to set up different URLs for these things, you can now use a single URL for both. -If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password. -The same goes for read access. +Φαίνεται ότι πλέον είναι ο πιο δημοφιλής τρόπος χρήσης του Git, αφού μπορεί να ρυθμιστεί τόσο για να ανώνυμη ανάκτηση όπως κάνει το πρωτόκολλο `git://` όσο και για ώθηση με ταυτοποίηση και κρυπτογράφηση όπως το πρωτόκολλο SSH. +Αντί να πρέπει να ορίσουμε διαφορετικές διευθύνσεις URL για αυτά τα δύο πράγματα, μπορούμε πλέον να χρησιμοποιήσουμε μια ενιαία διεύθυνση URL και για τα δύο. +Αν προσπαθήσουμε να ωθήσουμε και το αποθετήριο απαιτεί ταυτοποίηση (όπως κανομικά πρέπει να κάνει), ο διακομιστής μπορεί να ζητήσει όνομα χρήστη και κωδικό πρόσβασης. +Το ίδιο ισχύει και για την πρόσβαση ανάγνωσης. -In fact, for services like GitHub, the URL you use to view the repository online (for example, ``https://github.com/schacon/simplegit[]'') is the same URL you can use to clone and, if you have access, push over. +Μάλιστα, για υπηρεσίες όπως το GitHub, η διεύθυνση URL που χρησιμοποιούμε για την προβολή του αποθετηρίου online (για παράδειγμα, https://github.com/schacon/simplegit[^]) είναι η ίδια διεύθυνση URL που μπορούμε να χρησιμοποιήσουμε για να κλωνοποιήσουμε και, εφόσον έχουμε πρόσβαση, να ωθήσουμε. -===== Dumb HTTP +===== Χαζό HTTP -(((protocols, dumb HTTP))) -If the server does not respond with a Git HTTP smart service, the Git client will try to fall back to the simpler ``dumb'' HTTP protocol. -The Dumb protocol expects the bare Git repository to be served like normal files from the web server. -The beauty of the Dumb HTTP protocol is the simplicity of setting it up. -Basically, all you have to do is put a bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you're done (See <<_git_hooks>>). -At that point, anyone who can access the web server under which you put the repository can also clone your repository. -To allow read access to your repository over HTTP, do something like this: +(((πρωτόκολλα, χαζό HTTP))) +Εάν ο διακομιστής δεν ανταποκρίνεται σε μια υπηρεσία έξυπνου HTTP του Git, ο πελάτης θα προσπαθήσει να χρησιμοποιήσει το απλούστερο πρωτόκολλο _Χαζό_ HTTP. +Το χαζό πρωτόκολλο αναμένει ότι το γυμνό αποθετήριο Git να εξυπηρετείται σαν να επρόκειτο για κανονικά αρχεία από τον web server. +Η ομορφιά του χαζού HTTP είναι η απλότητα στην εγκατάστασή του. +Βασικά, το μόνο που έχουμε να κάνουμε είναι να τοποθετήσουμε ένα γυμνό αποθετήριο Git κάτω από τον ριζικό κατάλογο του εγγράφου HTTP και να δημιουργήσουμε ένα συγκεκριμένο άγκιστρο `post-update`, και τελειώσαμε (βλ. <>). +Σε αυτό το σημείο, οποιοσδήποτε έχει πρόσβαση στον web server κάτω από τον οποίο έχουμε κρεμάσει το αποθετήριο, μπορεί επίσης να κλωνοποιήσει το αποθετήριο. +Για να επιτρέψουμε πρόσβαση ανάγνωσης στο αποθετήριό μας μέσω HTTP, κάνουμε κάτι σαν αυτό: [source,console] ---- @@ -103,103 +103,109 @@ $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update ---- -That's all.(((hooks, post-update))) -The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. -This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like +Αυτό είναι όλο. (((άγκιστρα, post-update))) +Το άγκιστρο `post-update` που έρχεται με το Git τρέχει την κατάλληλη εντολή (`git update-server-info`) για να κάνει την ανάκτηση και κλωνοποίηση μέσω HTTP να λειτουργούν σωστά. +Αυτή η εντολή εκτελείται όταν ωθούμε σε αυτό το αποθετήριο (ίσως μέσω SSH)· τότε, κάποιος μπορεί να κλωνοποιήσει με κάτι σαν: [source,console] ---- $ git clone https://example.com/gitproject.git ---- -In this particular case, we're using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server – just put the bare repository in its path. -The Git data is served as basic static files (see <<_git_internals>> for details about exactly how it's served). +Στη συγκεκριμένη περίπτωση, χρησιμοποιούμε τη διαδρομή `/var/www/htdocs` που είναι κοινή για διακομιστές Apache, αλλά μπορούμε να χρησιμοποιήσουμε οποιονδήποτε στατικό web server -- απλά τοποθετούμε το γυμνό αποθετήριο στη διαδρομή του. +Τα δεδομένα Git διακομίζονται ως απλά στατικά αρχεία (βλ. ενότητα <> για λεπτομέρειες σχετικά με τον τρόπο με τον οποίο διακομίζονται). -Generally you would either choose to run a read/write Smart HTTP server or simply have the files accessible as read-only in the Dumb manner. -It's rare to run a mix of the two services. +Σε γενικές γραμμές, επιλέγουμε είτε να τρέξουμε έναν διακομιστή με έξυπνο HTTP για ανάγνωση/εγγραφή είτε απλά να έχουμε πρόσβαση στα αρχεία για ανάγνωση μόνο με τον χαζό τρόπο. +Σπάνια συνδυάζονται αυτές οι δύο υπηρεσίες. -===== The Pros +===== Τα υπέρ -We'll concentrate on the pros of the Smart version of the HTTP protocol. +Θα επικεντρωθούμε στα πλεονεκτήματα της έξυπνης έκδοσης του πρωτοκόλλου HTTP. -The simplicity of having a single URL for all types of access and having the server prompt only when authentication is needed makes things very easy for the end user. -Being able to authenticate with a username and password is also a big advantage over SSH, since users don't have to generate SSH keys locally and upload their public key to the server before being able to interact with it. -For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. -It is also a very fast and efficient protocol, similar to the SSH one. +Η ευκολία να χρειάζεται μόνον μία ενιαία διεύθυνση URL για όλους τους τύπους πρόσβασης και η προτροπή για ταυτοποίηση από τον διακομιστή μόνο όταν απαιτείται έλεγχος ταυτότητας κάνουν τα πράγματα πολύ απλά για τον τελικό χρήστη. +Η ταυτοποίηση με όνομα χρήστη και κωδικό πρόσβασης είναι επίσης ένα μεγάλο πλεονέκτημα έναντι του SSH, δεδομένου ότι οι χρήστες δεν χρειάζεται να παράγουν τοπικά κλειδιά SSH και να φορτώνουν το δημόσιο κλειδί τους στον εξυπηρετητή πριν μπορέσουν να επικοινωνήσουν με αυτόν. +Για λιγότερο προηγμένους χρήστες ή χρήστες σε συστήματα όπου το SSH δεν είναι σύνηθες, αυτό αποτελεί σημαντικό πλεονέκτημα στη χρηστικότητα. +Είναι επίσης ένα πολύ γρήγορο και αποτελεσματικό πρωτόκολλο, παρόμοιο με το SSH. -You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. +Μπορούμε επίσης να διαθέτουμε τα αποθετήριά μας μόνο για ανάγνωση μέσω HTTPS, πράγμα που σημαίνει ότι μπορούμε να κρυπτογραφήσoyme τη μεταφορά του περιεχομένου· ή μπορούμε να ακόμα να κάνουμε τους πελάτες να χρησιμοποιούν ειδικά υπογεγραμμένα πιστοποιητικά SSL. -Another nice thing is that HTTP/S are such commonly used protocols that corporate firewalls are often set up to allow traffic through these ports. +Ένα άλλο υπέρ είναι ότι το HTTPS είναι τόσο διαδεδομένο πρωτόκολλο που συχνά τα εταιρικά firewall ρυθμίζονται με τέτοιον τρόπο ώστε να επιτρέπουν την κίνηση δεδομένων μέσω αυτών των θυρών. -===== The Cons +===== Τα κατά -Git over HTTP/S can be a little more tricky to set up compared to SSH on some servers. -Other than that, there is very little advantage that other protocols have over the ``Smart'' HTTP protocol for serving Git. +Το Git μέσω HTTPS εγκαθίσταται λίγο πιο δύσκολα σε σύγκριση με το SSH σε ορισμένους διακομιστές. +Εκτός από αυτό, τα άλλα πρωτόκολλα δεν έχουν κανένα σημαντικό πλεονέκτημα σε σύγκριση με το πρωτόκολλο Έξυπνο HTTP όσον αφορά στο Git. -If you're using HTTP for authenticated pushing, providing your credentials is sometimes more complicated than using keys over SSH. -There are however several credential caching tools you can use, including Keychain access on OSX and Credential Manager on Windows, to make this pretty painless. -Read <<_credential_caching>> to see how to set up secure HTTP password caching on your system. +Αν χρησιμοποιούμε HTTP για ταυτοποίηση ώθησης, η παροχή των διαπιστευτηρίων είναι κάποιες φορές πιο πολύπλοκη από τη χρήση κλειδιών SSH. +Ωστόσο, υπάρχουν αρκετά εργαλεία προσωρινής αποθήκευσης διαπιστευτηρίων που μπορούμε να χρησιμοποιήσουμε, συμπεριλαμβανομένων των Keychain στο MacOS και Credential Manager στα Windows, που καθιστούν τη διαδικασία ταυτοποίησης αρκετά ανώδυνη. +Στην ενότητα <> μπορούμε να δουμε πώς μπορούμε να ρυθμίσουμε ασφαλή προσωρινή αποθήκευση κωδικού πρόσβασης HTTP στο σύστημά μας. -==== The SSH Protocol +==== Το πρωτόκολλο SSH -(((protocols, SSH))) -A common transport protocol for Git when self-hosting is over SSH. -This is because SSH access to servers is already set up in most places – and if it isn't, it's easy to do. -SSH is also an authenticated network protocol; and because it's ubiquitous, it's generally easy to set up and use. +(((πρωτόκολλα, SSH))) +Ένα κοινό πρωτόκολλο μεταφοράς για το Git όταν αυτο-φιλοξενείται είναι το SSH. +Αυτό οφείλεται στο ότι η πρόσβαση σε διακομιστές μέσω SSH είναι ήδη ρυθμισμένη -- και αν δεν είναι, είναι εύκολο να γίνει. +Το SSH είναι επίσης πρωτόκολλο ταυτοποιημένου δικτύου και επειδή είναι πανταχού παρόν είναι γενικά εύκολο να εγκαταστασθεί και να χρησιμοποιηθεί. -To clone a Git repository over SSH, you can specify ssh:// URL like this: +Για να κλωνοποιήσουμε ένα αποθετήριο Git πάνω από SSH, μπορούμε να ορίσουμε το URL `ssh://` ως εξής: [source,console] ---- -$ git clone ssh://user@server/project.git +$ git clone ssh://[user@]server/project.git ---- -Or you can use the shorter scp-like syntax for the SSH protocol: +Ή μπορούμε να χρησιμοποιήσουμε τη συντομότερη σύνταξη τύπου scp για το πρωτόκολλο SSH: [source,console] ---- -$ git clone user@server:project.git +$ git clone [user@]server:project.git ---- -You can also not specify a user, and Git assumes the user you're currently logged in as. +Και στις δύο περιπτώσεις, αν δεν ορίσουμε το όνομα χρήστη, το Git χρησιμοποιεί το όνομα χρήστη που έχουμε στο σύστημά μας. -===== The Pros +===== Τα υπέρ -The pros of using SSH are many. -First, SSH is relatively easy to set up – SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. -Next, access over SSH is secure – all data transfer is encrypted and authenticated. -Last, like the HTTP/S, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. +Τo SSH έχει πολλά πλεονεκτήματα +Κατ' αρχάς το SSH είναι σχετικά εύκολο να εγκατασταθεί -- οι δαίμονες SSH είναι πολύ συνηθισμένοι, πολλοί διαχειριστές δικτύου έχουν εμπειρία με αυτούς και πολλά λειτουργικά συστήματα είναι εγκατεστημένα με αυτούς ή έχουν εργαλεία να τους διαχειρίζονται. +Ακόμα, η πρόσβαση μέσω SSH είναι ασφαλής -- όλη η μεταφορά δεδομένων είναι κρυπτογραφημένη και απαιτεί ταυτοποίηση. +Τέλος, όπως και το HTTPS, το Git και το πρωτόκολο local, το SSH είναι αποδοτικό με την έννοια ότι συμπιέζει τα δεδομένα όσο είναι δυνατό πριν τη μεταφορά. -===== The Cons +===== Τα κατά -The negative aspect of SSH is that you can't serve anonymous access of your repository over it. -People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn't make SSH access conducive to open source projects. -If you're using it only within your corporate network, SSH may be the only protocol you need to deal with. -If you want to allow anonymous read-only access to your projects and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch over. +Το μειονέκτημα του SSH είναι ότι δεν υποστηρίζει ανώνυμη πρόσβαση στο αποθετήριό μας. +Οι χρήστες _πρέπει_ να έχουν πρόσβαση μέσω SSH στον υπολογιστή μας ακόμα και αν είναι μόνο-για-ανάγνωση, κάτι που δεν καθιστά την πρόσβαση μέσα από SSH ενδεδειγμένη για έργα ανοικτού κώδικα, στα οποία οι χρήστες μπορεί να θέλουν μόνο να κλωνοποιήσουν το αποθετήριό μας για να το εξετάσουν. +Αν το χρησιμοποιούμε μόνο εντός του εταιρικού δικτύου μας, το SSH ίσως είναι το μοναδικό πρωτόκολλο που θα χρειαστούμε. +Αν θέλουμε να επιτρέψουμε ανώνυμη πρόσβαση για ανάγνωση μόνο στα έργα μας και επίσης θέλουμε να χρησιμοποιούμε το SSH, θα πρέπει να εγκαταστήσουμε το SSH για εμάς ώστε να ωθούμε μέσα από το SSH, αλλά κάποιο άλλο πρωτόκολλο για να ανακτήσουν (fetch) όλοι οι υπόλοιποι. -==== The Git Protocol +==== Το πρωτόκολλο Git (((protocols, git))) -Next is the Git protocol. -This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. -In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file – the daemon won't serve a repository without that file in it – but other than that there is no security. -Either the Git repository is available for everyone to clone or it isn't. -This means that there is generally no pushing over this protocol. -You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project's URL could push to your project. -Suffice it to say that this is rare. - -===== The Pros - -The Git protocol is often the fastest network transfer protocol available. -If you’re serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it’s likely that you'll want to set up a Git daemon to serve your project. -It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. - -===== The Cons - -The downside of the Git protocol is the lack of authentication. -It's generally undesirable for the Git protocol to be the only access to your project. -Generally, you'll pair it with SSH or HTTPS access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. -It's also probably the most difficult protocol to set up. -It must run its own daemon, which requires `xinetd` configuration or the like, which isn't always a walk in the park. -It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow. -Behind big corporate firewalls, this obscure port is commonly blocked. +Τέλος, έχουμε το πρωτόκολλο Git. +Το πρωτόκολλο Git είναι ένας ειδικός δαίμονας που έρχεται μαζί με το Git· ακούει στη θύρα 9418 που παρέχει μία υπηρεσία παρόμοια με το πρωτόκολλο SSH αλλά με απολύτως καμία ταυτοποίηση ή κρυπτογράφηση. +Για να διαθέσουμε ένα αποθετήριο πάνω από το πρωτόκολλο Git, πρέπει να δημιουργήσουμε το αρχείο `git-daemon-export-ok` -- ο δαίμονας δεν θα σερβίρει το αποθετήριο αν δεν έχει αυτό το αρχείο -- αλλά πέρα από αυτό δεν υπάρχει καμία ασφάλεια. +Είτε το αποθετήριο Git είναι διαθέσιμο σε όλους να το κλωνοποιήσουν είτε σε κανέναν. +Αυτό σημαίνει ότι γενικά δεν γίνεται ώθηση πάνω από αυτό το πρωτόκολλο. +Μπορούμε να ενεργοποιήσουμε την πρόσβαση ώθησης, αλλά δεδομένης της έλλειψης ταυτοποίησης αν ενεργοποιήσουμε την πρόσβαση ώθησης, οποιοσδήποτε βρίσκει το URL του έργου μας στο Internet, θα μπορεί να ωθήσει σε αυτό. +Είναι προφανές ότι αυτή η συμπεριφορά είναι σπάνια επιθυμητή. + +===== Τα υπέρ + +Το πρωτόκολλο Git είναι συχνά το πιο γρήγορο διαθέσιμο πρωτόκολλο μεταφοράς μέσα από δίκτυο. +Αν πρέπει να εξυπηρετούμε κυκλοφορία πολλών δεδομένων για ένα δημόσιο έργο ή ένα πολύ μεγάλο έργο που δεν απαιτεί ταυτοποίηση χρηστών για πρόσβαση ανάγνωσης, μάλλον θα θέλουμε έναν δαίμονα Git για να εξυπηρετήσουμε το έργο μας. +Χρησιμοποιεί τον ίδιο μηχανισμό μεταφοράς δεδομένων με το πρωτόκολλο SSH αλλά χωρίς την επιβάρυνση της κρυπτογράφησης και ταυτοποίησης. + +===== Τα κατά + +Λόγω της έλλειψης TLS ή άλλης κρυπτογράφησης, η κλωνοποίηση μέσω `git://` μπορεί να οδηγήσει σε αυθαίρετο κενό ασφάλειας εκτέλεσης κώδικα και συνεπώς πρέπει να αποφεύγεται εκτός κι αν γνωρίζουμε πολύ καλά τι κάνουμε. + +* Αν εκτελέσουμε `git clone git://example.com/project.git`, κάποιος κακόβουλος που ελέγχει, π.χ. τον router μας μπορεί να τροποποιήσει το αποθετήριο που μόλις κλωνοποιήσαμε, εισάγοντας κακόβουλο κώδικα σε αυτό. + Αν μετά μεταγλωττίσουμε/εκτελέσουμε τον κώδικα που μόλις κλωνοποιήσαμε, θα εκτελέσουμε τον κακόβουλο κώδικα. + Η εκτέλεση της εντολής `git clone http://example.com/project.git` πρέπει να αποφεύγεται για τον ίδιο λόγο. +* Η εκτέλεση της εντολής `git clone https://example.com/project.git` δεν παρουσιάζει το ίδιο πρόβλημα (εκτός κι αν ο κακόβουλος χρήστης παράσχει πιστοποιητικό TLS για το example.com). + Η εκτέλεση της εντολής `git clone git@example.com:project.git` παρουσιάζει αυτό το πρόβλημα αν αποδεχτούμε ένα λανθασμένο αποτύπωμα κλειδιού SSH. + +Επίσης δεν έχει ταυτοποίηση, δηλαδή ο καθένας μπορεί να κλωνοποιήσει το αποθετήριο (αν και συχνά αυτό ακριβώς θέλουμε). +Επίσης είναι πιθανότατα το πιο δύσκολο πρωτόκολλο από πλευράς ρύθμισης. +Πρέπει να τρέχει το δικό του δαίμονα, που απαιτεί ρύθμιση `xinetd` ή `systemd` ή κάτι παρόμοιο, το οποίο δεν είναι πάντα εύκολο. +Απαιτεί επίσης πρόσβαση στη θύρα 9418 του firewall, που δεν είναι κάποια από τις τυποποιημένες θύρες που επιτρέπουν τα firewall των εταιρικών δικτύων. +Πίσω από τα firewall μεγάλων εταιρειών, αυτή η ασυνήθιστη θύρα είναι συνήθως μπλοκαρισμένη. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 1c7beb038..b37b11c78 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -1,10 +1,16 @@ -[[_setting_up_server]] -=== Setting Up the Server +[[r_setting_up_server]] +=== Στήσιμο του διακομιστή -Let's walk through setting up SSH access on the server side. -In this example, you'll use the `authorized_keys` method for authenticating your users. -We also assume you're running a standard Linux distribution like Ubuntu. -First, you create a `git` user and a `.ssh` directory for that user. +Ας δούμε τώρα τη διαμόρφωση της πρόσβασης SSH από την πλευρά του διακομιστή. +Σε αυτό το παράδειγμα θα χρησιμοποιήσουμε τη μέθοδο `authorized_keys` για την ταυτοποίηση των χρηστών. +Υποθέτουμε ότι τρέχουμε μια τυπική διανομή Linux όπως το Ubuntu. + +[NOTE] +==== +Πολλά από όσα περιγράφονται εδώ, μπορείτε να τα αυτοματοποιήσετε με την εντολή `ssh-copy-id`, αντί να αντιγράφετε και εγκαθιστάτε δημόσια κλειδιά χειροκίνητα. +==== + +Καταρχάς, δημιουργούμε ένα χρήστη `git` και έναν κατάλογο `.ssh` για αυτόν τον χρήστη. [source,console] ---- @@ -15,9 +21,9 @@ $ mkdir .ssh && chmod 700 .ssh $ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys ---- -Next, you need to add some developer SSH public keys to the `authorized_keys` file for the `git` user. -Let's assume you have some trusted public keys and have saved them to temporary files. -Again, the public keys look something like this: +Στη συνέχεια, πρέπει να προσθέσουμε δημόσια κλειδιά SSH για προγραμματιστές στο αρχείο `authorized_keys` του χρήστη `git`. +Ας υποθέσουμε ότι έχουμε ορισμένα αξιόπιστα δημόσια κλειδιά και τα έχουμε αποθηκεύσει σε προσωρινά αρχεία. +Υπενθυμίζουμε ότι τα δημόσια κλειδιά μοιάζουν με το παρακάτω: [source,console] ---- @@ -30,7 +36,7 @@ O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair ---- -You just append them to the `git` user's `authorized_keys` file in its `.ssh` directory: +Απλά τα προσθέτουμε στο τέλος του αρχείου `authorized_keys` του χρήστη `git` στον κατάλογο `.ssh` του χρήστη: [source,console] ---- @@ -39,70 +45,70 @@ $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys ---- -Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:(((git commands, init, bare))) +Τώρα, μπορούμε να δημιουργήσουμε ένα κενό αποθετήριο για αυτό τον χρήστη, τρέχοντας `git init` με την επιλογή `--bare`, η οποία αρχικοποιεί το αποθετήριο χωρίς κατάλογο εργασίας: (((εντολές git, init, bare))) [source,console] ---- -$ cd /opt/git +$ cd /srv/git $ mkdir project.git $ cd project.git $ git init --bare -Initialized empty Git repository in /opt/git/project.git/ +Initialized empty Git repository in /srv/git/project.git/ ---- -Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. -Note that someone must shell onto the machine and create a bare repository every time you want to add a project. -Let's use `gitserver` as the hostname of the server on which you've set up your `git` user and repository. -If you're running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is (assuming that `myproject` is an existing project with files in it): +Στη συνέχεια, ο Τζον, η Τζόσι ή η Τζέσικα μπορούν να ωθήσουν την πρώτη έκδοση του έργου τους σε αυτό το αποθετήριο, προσθέτοντάς το ως απομακρυσμένο και ωθώντας έναν κλάδο. +Σημειώστε ότι κάποιος πρέπει να μπαίνει στο κέλυφος στο συγκεκριμένο μηχάνημα και να δημιουργεί ένα γυμνό αποθετήριο κάθε φορά που θέλουμε να προσθέσουμε ένα έργο. +Ας χρησιμοποιήσουμε το `gitserver` ως το hostname του διακομιστή στον οποίο έχουμε δημιουργήσει τον χρήστη `git` και το αποθετήριο. +Αν το τρέξουμε εσωτερικά και έχουμε ρυθμίσει το DNS για το `gitserver` να δείχνει σε εκείνον τον διακομιστή, τότε μπορούμε να χρησιμοποιήσουμε τις εντολές σχεδόν όπως είναι (με την προϋπόθεση ότι το `myproject` είναι ένα υπάρχων έργο με αρχεία): [source,console] ---- -# on Johns computer +# on John's computer $ cd myproject $ git init $ git add . -$ git commit -m 'initial commit' -$ git remote add origin git@gitserver:/opt/git/project.git +$ git commit -m 'Initial commit' +$ git remote add origin git@gitserver:/srv/git/project.git $ git push origin master ---- -At this point, the others can clone it down and push changes back up just as easily: +Σε αυτό το σημείο, όλοι οι άλλοι μπορούν να κλωνοποιήσουν το αποθετήριο και να ωθήσουν αλλαγές εξίσου εύκολα: [source,console] ---- -$ git clone git@gitserver:/opt/git/project.git +$ git clone git@gitserver:/srv/git/project.git $ cd project $ vim README -$ git commit -am 'fix for the README file' +$ git commit -am 'Fix for README file' $ git push origin master ---- -With this method, you can quickly get a read/write Git server up and running for a handful of developers. +Με αυτή τη μέθοδο, μπορούμε να ξεκινήσουμε γρήγορα έναν διακομιστή Git ανάγνωσης/εγγραφής για μερικούς προγραμματιστές. -You should note that currently all these users can also log into the server and get a shell as the `git` user. -If you want to restrict that, you will have to change the shell to something else in the `passwd` file. +Σημειώνουμε ότι αυτή τη στιγμή όλοι αυτοί οι χρήστες μπορούν επίσης να συνδεθούν στον διακομιστή και να ανοίξουν ένα κέλυφος ως χρήστης "`git`". +Εάν δεν θέλουμε να συμβαίνει αυτό, θα πρέπει να αλλάξουμε το κέλυφος σε κάτι άλλο στο αρχείο `/etc/passwd`. -You can easily restrict the `git` user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. -If you set this as your `git` user's login shell, then the `git` user can't have normal shell access to your server. -To use this, specify `git-shell` instead of bash or csh for your user's login shell. -To do so, you must first add `git-shell` to `/etc/shells` if it's not already there: +Μπορούμε να περιορίσουμε εύκολα τον χρήστη `git` ώστε να κάνει μόνο δραστηριότητες Git με ένα εργαλείο περιορισμένου κελύφους που ονομάζεται `git-shell` και διατίθεται στο Git. +Αν ορίσουμε αυτό ως το κέλυφος σύνδεσης του χρήστη `git`, τότε ο χρήστης `git` δεν μπορεί να έχει κανονική πρόσβαση μέσω του κελύφους στον διακομιστή σας. +Για να το χρησιμοποιήσουμε, καθορίζουμε `git-shell` αντί για `bash` ή `csh` για το κέλυφος σύνδεσης του χρήστη. +Για να συμβεί αυτό, πρέπει προηγουμένως να προσθέσουμε το `git-shell` στο `/etc/shells` αν δεν υπάρχει ήδη: [source,console] ---- -$ cat /etc/shells # see if `git-shell` is already in there. If not... +$ cat /etc/shells # see if git-shell is already in there. If not... $ which git-shell # make sure git-shell is installed on your system. -$ sudo vim /etc/shells # and add the path to git-shell from last command +$ sudo -e /etc/shells # and add the path to git-shell from last command ---- -Now you can edit the shell for a user using `chsh `: +Τώρα μπορούμε να επεξεργαστούμε το κέλυφος για έναν χρήστη χρησιμοποιώντας `chsh -s `: [source,console] ---- -$ sudo chsh git # and enter the path to git-shell, usually: /usr/bin/git-shell +$ sudo chsh git -s $(which git-shell) ---- -Now, the `git` user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine. -If you try, you'll see a login rejection like this: +Τώρα, ο χρήστης `git` μπορεί ακόμα να χρησιμοποιήσει τη σύνδεση SSH για να ωθεί και να τραβά αποθετήρια Git αλλά δεν μπορεί να ανοίξει ένα κέλυφος στο μηχάνημα. +Αν το προσπαθήσουμε, θα πάρουμε μήνυμα αποτυχίας σύνδεσης όπως το παρακάτω: [source,console] ---- @@ -112,7 +118,32 @@ hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed. ---- -Now Git network commands will still work just fine but the users won't be able to get a shell. -As the output states, you can also set up a directory in the `git` user's home directory that customizes the `git-shell` command a bit. -For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that. -Run `git help shell` for more information on customizing the shell.(((git commands, help))) +Σε αυτό το σημείο, οι χρήστες ακόμα μπορούν να χρησιμοποιήσουν πρόωθηση θύρας SSH ώστε να αποκτήσουν πρόσβαση σε οποιονδήποτε host μπορεί να φτάσει ο διακομιστής Git. +Αν δεν θέλουμε να γίνεται αυτό, μπορούμε να επεξεργαστούμε το αρχείο `authorized_keys` και να γράψουμε πριν από κάθε κλειδί που θέλουμε να περιορίσουμε το εξής + +[source,console] +---- +no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty +---- + +Το αποτέλεσμα πρέπει να μοιάζει με κάτι σαν αυτό: + +[source,console] +---- +$ cat ~/.ssh/authorized_keys +no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa +AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h +PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N +YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC +IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd +LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ +ICUvax2T9va5 gsg-keypair + +no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa +AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG... +---- + +Τώρα οι εντολές δικτύου του Git θα λειτουργούν ακόμα μια χαρά, αλλά οι χρήστες δεν θα μπορούν να ανοίξουν κάποιο κέλυφος. +Όπως αναφέρει και η έξοδος της εντολής, μπορούμε επίσης να ρυθμίσουμε έναν κατάλογο στον αρχικό κατάλογο του χρήστη `git` που προσαρμόζει ελαφρώς την εντολή `git-shell`. +Για παράδειγμα, μπορούμε να περιορίσουμε τις εντολές Git που μπορεί να δέχεται ο διακομιστής ή να προσαρμόσουμε το μήνυμα που βλέπουν οι χρήστες αν προσπαθούν να κάνουν SSH με αυτόν τον τρόπο. +Εκτελούμε `git shell help` για περισσότερες πληροφορίες σχετικά με την προσαρμογή του κελύφους στις προτιμήσεις σας. (((εντολές git, help))) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 6e8cdc25f..02443d084 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -1,14 +1,14 @@ -=== Smart HTTP +=== Έξυπνο HTTP (((serving repositories, HTTP))) -We now have authenticated access though SSH and unauthenticated access through `git://`, but there is also a protocol that can do both at the same time. -Setting up Smart HTTP is basically just enabling a CGI script that is provided with Git called `git-http-backend` on the server.(((git commands, "http-backend"))) -This CGI will read the path and headers sent by a `git fetch` or `git push` to an HTTP URL and determine if the client can communicate over HTTP (which is true for any client since version 1.6.6). -If the CGI sees that the client is smart, it will communicate smartly with it, otherwise it will fall back to the dumb behavior (so it is backward compatible for reads with older clients). +Έχουμε πλέον ταυτοποιημένη πρόσβαση μέσω SSH και μη-ταυτοποιημένη πρόσβαση μέσω του `git://`, αλλά υπάρχει και ένα πρωτόκολλο που μπορεί να κάνει και τα δύο ταυτόχρονα. +Η εγκατάσταση του Έξυπνου HTTP βασικά απλά ενεργοποιεί ένα script CGI, που παρέχεται με τον Git και ονομάζεται `git-http-backend`, στον διακομιστή. (((εντολές git, "http-backend"))) +Αυτό το CGI θα διαβάσει τη διαδρομή και τις κεφαλίδες που θα σταλούν με `git fetch` ή `git push` σε μια διεύθυνση URL HTTP και θα καθορίσει εάν ο πελάτης μπορεί να επικοινωνήσει μέσω HTTP (κάτι που ισχύει για όλους τους πελάτες από την έκδοση 1.6.6 και μετά). +Αν το CGI διαπιστώσει ότι ο πελάτης είναι έξυπνος, θα επικοινωνήσει μαζί του έξυπνα, αλλιώς θα επανέλθει στη χαζή συμπεριφορά (συνεπώς έχει προς-τα-πίσω συμβατότητα για ανάγνωσεις με τους παλαιότερους πελάτες). -Let's walk through a very basic setup. -We'll set this up with Apache as the CGI server. -If you don't have Apache setup, you can do so on a Linux box with something like this:(((Apache))) +Ας δούμε αναλυτικά μία πολύ βασική ρύθμιση. +Θα υποθέσουμε ότι ο διακομιστής CGI είναι ο Apache. +Αν δεν έχουμε Apache, μπορούμε να το κάνουμε σε ένα κουτί Linux με κάτι σαν αυτό: (((Apache))) [source,console] ---- @@ -16,61 +16,57 @@ $ sudo apt-get install apache2 apache2-utils $ a2enmod cgi alias env ---- -This also enables the `mod_cgi`, `mod_alias`, and `mod_env` modules, which are all needed for this to work properly. +Αυτό ενεργοποιεί επίσης τις λειτουργικές μονάδες (modules) `mod_cgi`, `mod_alias` και `mod_env`, που είναι απαραίτητες για να λειτουργήσει σωστά όλο αυτό. -Next we need to add some things to the Apache configuration to run the `git-http-backend` as the handler for anything coming into the `/git` path of your web server. +Θα πρέπει επίσης να ορίσουμε την ομάδα χρηστών Unix φακέλων `/srv/git` σε `www-data`, ώστε ο web server να έχει πρόσβαση ανάγνωσης και εγγραφής στα αποθετήρια, διότι ο Apache που τρέχει το script CGA θα τρέχει εξ ορισμού ως ο χρήστης: [source,console] ---- -SetEnv GIT_PROJECT_ROOT /opt/git -SetEnv GIT_HTTP_EXPORT_ALL -ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ +$ chgrp -R www-data /srv/git ---- -If you leave out `GIT_HTTP_EXPORT_ALL` environment variable, then Git will only serve to unauthenticated clients the repositories with the `git-daemon-export-ok` file in them, just like the Git daemon did. - -Then you'll have to tell Apache to allow requests to that path with something like this: +Στη συνέχεια πρέπει να προσθέσουμε κάποια πράγματα στην παραμετροποίηση του Apache για να εκτελέσουμε το `git-http-backend` ως τον handler για οτιδήποτε μπαίνει στη διαδρομή `/git` του web server μας. [source,console] ---- - - Options ExecCGI Indexes - Order allow,deny - Allow from all - Require all granted - +SetEnv GIT_PROJECT_ROOT /srv/git +SetEnv GIT_HTTP_EXPORT_ALL +ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ---- -Finally you'll want to make writes be authenticated somehow, possibly with an Auth block like this: +Εάν παραλείψουμε τη μεταβλητή περιβάλλοντος (environment variable) `GIT_HTTP_EXPORT_ALL`, τότε το Git θα εξυπηρετεί σε μη-ταυτοποιημένους πελάτες μόνο τα αποθετήρια που περιέχουν το αρχείο `git-daemon-export-ok`, ακριβώς όπως έκανε και ο δαίμονας Git. + +Στη συνέχεια θα πρέπει να πούμε στο Apache να επιτρέψει αιτήματα στο `git-http-backend` και να ταυτοποιεί με κάποιον τρόπο τις εγγραφές με ένα μπλοκ Auth σαν αυτό: [source,console] ---- - + AuthType Basic AuthName "Git Access" - AuthUserFile /opt/git/.htpasswd + AuthUserFile /srv/git/.htpasswd + Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#) Require valid-user - + ---- -That will require you to create a `.htaccess` file containing the passwords of all the valid users. -Here is an example of adding a ``schacon'' user to the file: +Αυτό προϋποθέτει την ύπαρξη ενος αρχείου `.htpasswd` που περιέχει τους κωδικούς πρόσβασης όλων των έγκυρων χρηστών. +Να ένα παράδειγμα προσθήκης του χρήστη "`schacon`" στο αρχείο : [source,console] ---- -$ htdigest -c /opt/git/.htpasswd "Git Access" schacon +$ htpasswd -c /srv/git/.htpasswd schacon ---- -There are tons of ways to have Apache authenticate users, you'll have to choose and implement one of them. -This is just the simplest example we could come up with. -You'll also almost certainly want to set this up over SSL so all this data is encrypted. +Υπάρχουν πάρα πολλοί τρόποι με τους οποίους μπορούμε να ζητήσουμε από τον Apache να ταυτοποιεί χρήστες, θα πρέπει να επιλέξουμε έναν και να τον υλοποιήσουμε. +Αυτό είναι το απλούστερο παράδειγμα που μπορέσαμε να σκεφτούμε. +Είναι σχεδόν βέβαιο ότι θα θέλήσουμε να το εγκαταστήσουμε πάνω από SSL, ώστε όλα αυτά τα δεδομένα να είναι κρυπτογραφημένα. -We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs. -The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. -It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. -You can do this with nearly any CGI-capable web server, so go with the one that you know best. +Δεν θέλουμε να μπούμε πολύ βαθιά στις ρυθμίσεις του Apache, καθώς ενδεχομένως μπορεί να χρησιμοποιούμε διαφορετικό διακομιστή ή να έχουμε διαφορετικές ανάγκες ταυτοποίησης. +Η βασική ιδέα είναι ότι το Git έρχεται με ένα CGI που ονομάζεται `git-http-backend` που όταν καλείται θα κάνει όλες τις διαπραγματεύσεις για αποστολή και λήψη δεδομένων μέσω HTTP. +Δεν υλοποιεί το ίδιο την ταυτοποίηση, αλλά αυτό μπορεί εύκολα να ελεγχθεί στο επίπεδο του web server που τον καλεί. +Μπορούμε να κάνουμε τα παραπάνω με σχεδόν οποιοδήποτε web server με δυνατότητα CGI, οπότε χρησιμοποιούμε αυτόν που γνωρίζουμε καλύτερα. [NOTE] ==== -For more information on configuring authentication in Apache, check out the Apache docs here: http://httpd.apache.org/docs/current/howto/auth.html[] +Περισσότερες πληροφορίες σχετικά με την παραμετροποίηση της ταυτοποίησης στον Apache, υπάρχουν στην τεκμηρίωση του Apache εδώ: https://httpd.apache.org/docs/current/howto/auth.html[^]. ==== diff --git a/book/05-distributed-git/1-distributed-git.asc b/book/05-distributed-git/1-distributed-git.asc deleted file mode 100644 index bb2f9ded0..000000000 --- a/book/05-distributed-git/1-distributed-git.asc +++ /dev/null @@ -1,20 +0,0 @@ -[[_distributed_git]] -== Distributed Git - -(((distributed git))) -Now that you have a remote Git repository set up as a point for all the developers to share their code, and you're familiar with basic Git commands in a local workflow, you'll look at how to utilize some of the distributed workflows that Git affords you. - -In this chapter, you'll see how to work with Git in a distributed environment as a contributor and an integrator. -That is, you'll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing. - -include::sections/distributed-workflows.asc[] - -include::sections/contributing.asc[] - -include::sections/maintaining.asc[] - -=== Summary - -You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users' contributions. -Congratulations on being an effective Git developer! -In the next chapter, you'll learn about how to use the largest and most popular Git hosting service, GitHub. diff --git a/book/05-distributed-git/images/benevolent-dictator.png b/book/05-distributed-git/images/benevolent-dictator.png deleted file mode 100644 index a742a2ed2..000000000 Binary files a/book/05-distributed-git/images/benevolent-dictator.png and /dev/null differ diff --git a/book/05-distributed-git/images/centralized_workflow.png b/book/05-distributed-git/images/centralized_workflow.png deleted file mode 100644 index 4f10782f8..000000000 Binary files a/book/05-distributed-git/images/centralized_workflow.png and /dev/null differ diff --git a/book/05-distributed-git/images/git-diff-check.png b/book/05-distributed-git/images/git-diff-check.png deleted file mode 100644 index 5dc9ae40b..000000000 Binary files a/book/05-distributed-git/images/git-diff-check.png and /dev/null differ diff --git a/book/05-distributed-git/images/integration-manager.png b/book/05-distributed-git/images/integration-manager.png deleted file mode 100644 index c877f592d..000000000 Binary files a/book/05-distributed-git/images/integration-manager.png and /dev/null differ diff --git a/book/05-distributed-git/images/large-merges-1.png b/book/05-distributed-git/images/large-merges-1.png deleted file mode 100644 index b4910f2db..000000000 Binary files a/book/05-distributed-git/images/large-merges-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/large-merges-2.png b/book/05-distributed-git/images/large-merges-2.png deleted file mode 100644 index 0fa474d13..000000000 Binary files a/book/05-distributed-git/images/large-merges-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/managed-team-1.png b/book/05-distributed-git/images/managed-team-1.png deleted file mode 100644 index 84c6f1fb3..000000000 Binary files a/book/05-distributed-git/images/managed-team-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/managed-team-2.png b/book/05-distributed-git/images/managed-team-2.png deleted file mode 100644 index 677e095df..000000000 Binary files a/book/05-distributed-git/images/managed-team-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/managed-team-3.png b/book/05-distributed-git/images/managed-team-3.png deleted file mode 100644 index b2f3e07cf..000000000 Binary files a/book/05-distributed-git/images/managed-team-3.png and /dev/null differ diff --git a/book/05-distributed-git/images/managed-team-flow.png b/book/05-distributed-git/images/managed-team-flow.png deleted file mode 100644 index 9e4d93f52..000000000 Binary files a/book/05-distributed-git/images/managed-team-flow.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-1.png b/book/05-distributed-git/images/merging-workflows-1.png deleted file mode 100644 index 54a96fc01..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-2.png b/book/05-distributed-git/images/merging-workflows-2.png deleted file mode 100644 index 6417c3de4..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-3.png b/book/05-distributed-git/images/merging-workflows-3.png deleted file mode 100644 index 1cb18c84b..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-3.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-4 2.png b/book/05-distributed-git/images/merging-workflows-4 2.png deleted file mode 100644 index 88a696a30..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-4 2.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-4.png b/book/05-distributed-git/images/merging-workflows-4.png deleted file mode 100644 index d2f079e69..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-4.png and /dev/null differ diff --git a/book/05-distributed-git/images/merging-workflows-5.png b/book/05-distributed-git/images/merging-workflows-5.png deleted file mode 100644 index 2eb257203..000000000 Binary files a/book/05-distributed-git/images/merging-workflows-5.png and /dev/null differ diff --git a/book/05-distributed-git/images/public-small-1.png b/book/05-distributed-git/images/public-small-1.png deleted file mode 100644 index afc27b29f..000000000 Binary files a/book/05-distributed-git/images/public-small-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/public-small-2.png b/book/05-distributed-git/images/public-small-2.png deleted file mode 100644 index 8632c0c35..000000000 Binary files a/book/05-distributed-git/images/public-small-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/public-small-3.png b/book/05-distributed-git/images/public-small-3.png deleted file mode 100644 index c2c33f142..000000000 Binary files a/book/05-distributed-git/images/public-small-3.png and /dev/null differ diff --git a/book/05-distributed-git/images/rebasing-1.png b/book/05-distributed-git/images/rebasing-1.png deleted file mode 100644 index a66f47cd3..000000000 Binary files a/book/05-distributed-git/images/rebasing-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/rebasing-2.png b/book/05-distributed-git/images/rebasing-2.png deleted file mode 100644 index 7be83863a..000000000 Binary files a/book/05-distributed-git/images/rebasing-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-1.png b/book/05-distributed-git/images/small-team-1.png deleted file mode 100644 index f821bf6a0..000000000 Binary files a/book/05-distributed-git/images/small-team-1.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-2.png b/book/05-distributed-git/images/small-team-2.png deleted file mode 100644 index 33e88eac0..000000000 Binary files a/book/05-distributed-git/images/small-team-2.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-3.png b/book/05-distributed-git/images/small-team-3.png deleted file mode 100644 index 9cddbb43c..000000000 Binary files a/book/05-distributed-git/images/small-team-3.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-4.png b/book/05-distributed-git/images/small-team-4.png deleted file mode 100644 index abaeee340..000000000 Binary files a/book/05-distributed-git/images/small-team-4.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-5.png b/book/05-distributed-git/images/small-team-5.png deleted file mode 100644 index ef3bba199..000000000 Binary files a/book/05-distributed-git/images/small-team-5.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-6.png b/book/05-distributed-git/images/small-team-6.png deleted file mode 100644 index 16f429bea..000000000 Binary files a/book/05-distributed-git/images/small-team-6.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-7.png b/book/05-distributed-git/images/small-team-7.png deleted file mode 100644 index ee6934d8d..000000000 Binary files a/book/05-distributed-git/images/small-team-7.png and /dev/null differ diff --git a/book/05-distributed-git/images/small-team-flow.png b/book/05-distributed-git/images/small-team-flow.png deleted file mode 100644 index 846e2c301..000000000 Binary files a/book/05-distributed-git/images/small-team-flow.png and /dev/null differ diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 7b9d23aae..abf4f9f1a 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,446 +1,461 @@ -[[_contributing_project]] -=== Contributing to a Project +[[r_contributing_project]] +=== Συνεισφέροντας σε ένα έργο (((contributing))) -The main difficulty with describing how to contribute to a project is that there are a huge number of variations on how it's done. -Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute – every project is a bit different. -Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method. - -The first variable is active contributor count – how many users are actively contributing code to this project, and how often? -In many instances, you'll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects. -For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day. -This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged. -Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. -How can you keep your code consistently up to date and your commits valid? - -The next variable is the workflow in use for the project. -Is it centralized, with each developer having equal write access to the main codeline? -Does the project have a maintainer or integration manager who checks all the patches? -Are all the patches peer-reviewed and approved? -Are you involved in that process? -Is a lieutenant system in place, and do you have to submit your work to them first? - -The next issue is your commit access. -The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't. -If you don't have write access, how does the project prefer to accept contributed work? -Does it even have a policy? -How much work are you contributing at a time? -How often do you contribute? - -All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. -We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples. - -[[_commit_guidelines]] -==== Commit Guidelines - -Before we start looking at the specific use cases, here's a quick note about commit messages. -Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. -The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches – you can read it in the Git source code in the `Documentation/SubmittingPatches` file. - -(((git commands, diff, check))) -First, you don't want to submit any whitespace errors. -Git provides an easy way to check for this – before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. - -.Output of `git diff --check`. -image::images/git-diff-check.png[Output of `git diff --check`.] - -If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. - -Next, try to make each commit a logically separate changeset. -If you can, try to make your changes digestible – don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. -Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. -If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <<_interactive_staging>>). -The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes. -This approach also makes it easier to pull out or revert one of the changesets if you need to later. -<<_rewriting_history>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history before sending the work to someone else. - -The last thing to keep in mind is the commit message. -Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. -As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. -The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior – this is a good guideline to follow. -It's also a good idea to use the imperative present tense in these messages. -In other words, use commands. -Instead of ``I added tests for'' or ``Adding tests for,'' use ``Add tests for.'' -Here is a template originally written by Tim Pope: +Η κύρια δυσκολία με την περιγραφή του τρόπου με τον οποίο μπορεί να συνεισφέρει κανείς σε ένα έργο είναι ότι υπάρχει ένας τεράστιος αριθμός παραλλαγών στον τρόπο που γίνεται κάτι τέτοιο. +Επειδή το Git είναι πολύ ευέλικτο, οι χρήστες του έχουν τη δυνατότητα να συνεργάζονται με πολλούς τρόπους και πράγματι το κάνουν, κάτι που καθιστά δύσκολο να περιγράψει κανείς πως πρέπει να συνεισφέρουμε --κάθε έργο είναι λίγο διαφορετικό από τα άλλα. +Ορισμένοι από τους παράγοντες που χρειάζεται να λάβουμε υπόψη είναι ο ενεργός αριθμός συνεργατών, η ροή εργασίας που έχει επιλεχθεί, η πρόσβασή μας στις υποβολές και ενδεχομένως η μέθοδος εξωτερικής συνεισφοράς. + +Ο πρώτος παράγοντας είναι ο ενεργός αριθμός συνεργατών --πόσοι χρήστες συμβάλλουν ενεργά στον κώδικα αυτού του έργου και πόσο συχνά; +Σε πολλές περιπτώσεις, θα έχουμε δύο ή τρεις προγραμματιστές με κάποιες υποβολές ανά ημέρα ή και λιγότερες για κάπως αδρανή έργα. +Για μεγαλύτερες εταιρείες ή έργα, ο αριθμός των προγραμματιστών μπορεί να φτάσει τις χιλιάδες, με εκατοντάδες ή χιλιάδες υποβολές να καταφτάνουν κάθε μέρα. +Αυτός ο παράγοντας είναι σημαντικός επειδή όσο περισσότεροι προγραμματιστές εμπλέκονται, τόσο περισσότερα θέματα έχουμε όσον αφορά στην καθαρή εφαρμογή και ευκολία συγχώνευσης του κώδικά μας. +Οι αλλαγές που υποβάλουμε ενδέχεται να καταστούν παρωχημένες ή να αλλοιωθούν σε σημαντικό βαθμό από εργασίες που συγχωνεύονται ενώ εργαζόμαστε ή ενώ οι αλλαγές μας αναμένουν έγκριση ή εφαρμογή. +Πώς, λοιπόν, μπορούμε να διατηρήσουμε τον κώδικά μας συνεχώς ενημερωμένο και τις υποβολές μας έγκυρες; + +Ο επόμενος παράγοντας είναι η ροή εργασίας που χρησιμοποιείται στο έργο. +Είναι συγκεντρωτική με κάθε προγραμματιστή να έχει ισότιμη πρόσβαση για εγγραφή στην κύρια γραμμή παραγωγής κώδικα; +Έχει το πρόγραμμα κάποιον συντηρητή ή διαχειριστή ενσωμάτωσης, ο οποίος ελέγχει όλα τα επιθέματα; +Περνούν τα επιθέματα κάποια διαδικασία ελέγχου από συνεργάτες ή έγκρισης; +Συμμετέχουμε εμείς σε αυτή τη διαδικασία; +Υπάρχει σύστημα υπαρχηγού και πρέπει να υποβάλλουμε την εργασία μας πρώτα σε αυτόν; + +Ο επόμενος παράγοντας είναι η το επίπεδο πρόσβασής μας όσον αφορά στις υποβολές. +Η ροή εργασίας που απαιτείται για να συνεισφέρουμε σε ένα έργο είναι πολύ διαφορετική εάν έχουμε πρόσβαση για εγγραφή στο έργο απ' ό,τι αν δεν έχουμε. +Εάν δεν έχουμε πρόσβαση για εγγραφή, πως προτιμά το έργο να δέχεται συνεισφερόμενη εργασία; +Υπάρχει κάποια σχετική πολιτική; +Πόση δουλειά υποβάλουμε κάθε φορά; +Πόσο συχνά συμβάλλουμε; + +Όλα αυτά τα ερωτήματα επηρεάζουν τον τρόπο με τον οποίο συνεισφέρουμε αποτελεσματικά σε ένα έργο και ποιες ροές εργασίας προτιμώνται ή μας είναι διαθέσιμες. +Θα καλύψουμε πτυχές καθεμιάς από αυτές τις ροές εργασίας σε μια σειρά περιπτώσεων χρήσης, από απλές μέχρι περίπλοκες· θα πρέπει να είμαστε σε θέση να κατασκευάζουμε τις ροές εργασίας που χρειαζόμαστε κάθε φορά από αυτά τα παραδείγματα. + +[[r_commit_guidelines]] +==== Κατευθυντήριες γραμμές για τις υποβολές + +Πριν ξεκινήσουμε να εξετάζουμε τις συγκεκριμένες περιπτώσεις χρήσης, ας δούμε λίγο για τα μηνύματα υποβολής. +Η ύπαρξη καλών κατευθυντήριων γραμμών σχετικά με τη δημιουργία υποβολών και η τήρησή τους διευκολύνουν την εργασία με το Git και τη συνεργασία με άλλους. +Το έργο Git παρέχει ένα έγγραφο που παραθέτει πολλές καλές συμβουλές για τη δημιουργία υποβολών για επιθέματα -- μπορούμε να το διαβάσουμε στον πηγαίο κώδικα του Git στο αρχείο `Documentation/SubmittingPatches`. + +(((εντολές git, diff, check))) +Καταρχάς δεν θέλουμε οι υποβολές μας να έχουν προβλήματα με τους λευκούς χαρακτήρες (whitespace). +Το Git παρέχει έναν εύκολο τρόπο για να ελέγξουμε τέτοιου είδους σφάλματα -- προτού υποβάλλουμε, εκτελούμε την εντολή `git diff --check`, η οποία προσδιορίζει πιθανά σφάλματα διαστημάτων και μας τα παραθέτει. + +.Έξοδος μίας `git diff --check` +image::images/git-diff-check.png[Έξοδος μίας `git diff --check`] + +Εάν εκτελέσουμε αυτή την εντολή πριν από την υποβολή, μπορούμε να διαπιστώσουμε αν πρόκειται να υποβάλλουμε προβλήματα με λευκούς χαρακτήρες που ενδεχομένως ενοχλούν άλλους προγραμματιστές. + +Δεύτερον, προσπαθούμε ώστε κάθε υποβολή να έχει ένα λογικά διακριτό σύνολο αλλαγών. +Αν είναι δυνατό, προσπαθούμε να κάνουμε τις αλλαγές μας εύπεπτες -- ας μην γράφουμε κώδικα για ένα ολόκληρο Σαββατοκύριακο σε πέντε διαφορετικά θέματα και στη συνέχεια τα υποβάλλουμε όλα ως μια τεράστια υποβολή τη Δευτέρα. +Ακόμη και αν δεν υποβάλλουμε μέσα στο Σαββατοκύριακο, χρησιμοποιούμε το στάδιο καταχώρησης τη Δευτέρα για να διαχωρίσουμε την εργασία μας σε τουλάχιστον μία υποβολή ανά ζήτημα, με ένα χρήσιμο μήνυμα ανά υποβολή. +Εάν ορισμένες από τις αλλαγές τροποποιούν το ίδιο αρχείο, προσπαθούμε να χρησιμοποιήσουμε το `git add --patch` ώστε να τοποθετήσουμε μερικώς αρχεία στο στάδιο καταχώρησης (αυτό καλύπτεται σε βάθος στην ενότητα <>). +Το στιγμιότυπο του έργου στην άκρη του κλάδου είναι το ίδιο είτε πραγματοποιούμε μία υποβολή είτε πέντε, εφόσον όλες οι αλλαγές προστίθενται σε κάποιο σημείο, οπότε προσπαθούμε να διευκολύνουμε τους συνεργάτες μας όταν θα πρέπει να ελέγξουν τις αλλαγές μας. + +Αυτή η προσέγγιση διευκολύνει επίσης την απόσυρση ή επαναφορά κάποιου συνόλου αλλαγών, εφόσον χρειαστεί να γίνει κάτι τέτοιο αργότερα. +Η ενότητα <> περιγράφει μια σειρά από χρήσιμα κόλπα που παρέχει το Git για την επανεγγραφή του ιστορικού και την αλληλεπιδραστική τοποθέτηση αρχείων στο στάδιο καταχώρησης· χρησιμοποιούμε αυτά τα εργαλεία για να δημιουργήσουμε ένα καθαρό και κατανοητό ιστορικό πριν στείλουμε το έργο σε κάποιον άλλο. + +Το τελευταίο πράγμα που πρέπει να έχουμε υπόψη είναι το μήνυμα υποβολής. +Η δημιουργία μηνυμάτων υψηλής ποιότητας διευκολύνει τη χρήση του Git και τη συνεργασία. +Έχουμε ως γενικό κανόνα τα μηνύματά μας να ξεκινούν με μία μόνο γραμμή που δεν υπερβαίνει τους 50 χαρακτήρες και περιγράφει συνοπτικά το σύνολο αλλαγών, να ακολουθεί μια κενή γραμμή και στη συνέχεια να ακολουθεί μια πιο λεπτομερής εξήγηση. +Το έργο Git απαιτεί η λεπτομερέστερη εξήγηση να περιλαμβάνει το κίνητρό μας για την αλλαγή και να αντιπαραβάλλουμε την εφαρμογή της με την προηγούμενη συμπεριφορά -- αυτή είναι μια καλή κατευθυντήρια γραμμή που πρέπει να ακολουθούμε. +Επίσης είναι καλή ιδέα να χρησιμοποιούμε την προστακτική έγκλιση σε αυτά τα μηνύματα: "`Διόρθωσε bug`" και όχι "`Διόρθωσα bug`", ή "`Διορθώνει bug`". +Ακολουθεί ένα πρότυπο που μπορούμε να ακολουθούμε και το οποίο έχουμε τροποποιήσει ελαφρά από αυτό που https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[originally written by Tim Pope^]: [source,text] ------ -Short (50 chars or less) summary of changes +---- +Σύντομη (το πολύ 50 χαρακτήρες) περίληψη των αλλαγών -More detailed explanatory text, if necessary. Wrap it to -about 72 characters or so. In some contexts, the first -line is treated as the subject of an email and the rest of -the text as the body. The blank line separating the -summary from the body is critical (unless you omit the body -entirely); tools like rebase can get confused if you run -the two together. +Λεπτομερέστερη περιγραφή, εφόσον είναι απαραίτητη. Αναδιπλώνετε σε περίπου 72 +χαρακτήρες. Σε κάποιες περιστάσεις η πρώτη γραμμή αντιμετωπίζεται ως το θέμα +ενός e-mail και οι υπόλοιπες ως το σώμα του. Η κενή γραμμή που +χωρίζει την περίληψη από τη λεπτομερή περιγραφή είναι σημαντική (εκτός κι αν η +λεπτομερής περιγραφή παραλείπεται τελείως)· εργαλεία όπως η αλλαγή βάσης (rebase) +μπορεί να προκαλέσουν σύγχυση αν εκτελούμε και δύο ταυτόχρονα. -Further paragraphs come after blank lines. +Γράφουμε το μήνυμα υποβολής μας στην προστακτική : "Διόρθωσε bug" και +όχι "Διόρθωσα bug" ή "Διορθώνει bug." Αυτή η σύμβαση ταιριάζει +με τα μηνύματα υποβολής που δημιουργούν εντολές όπως οι git merge και git revert. - - Bullet points are okay, too +Περαιτέρω παράγραφοι έρχονται μετά από κενές γραμμές. - - Typically a hyphen or asterisk is used for the bullet, - preceded by a single space, with blank lines in - between, but conventions vary here ------ +- Λίστες με κουκκίδες είναι αποδεκτές + +- Συνήθως χρησιμοποιείται παύλα ή αστερίσκος αντί για κουκκίδα, ακολουθεί ένα κενό + και κενές γραμμές ανάμεσα στα σημεία αλλά οι συμβάσεις ποικίλλουν σε αυτό το σημείο + +- Χρησιμοποιούμε προεξοχή πρώτης γραμμής +---- -If all your commit messages look like this, things will be a lot easier for you and the developers you work with. -The Git project has well-formatted commit messages – try running `git log --no-merges` there to see what a nicely formatted project-commit history looks like. +Αν όλα τα μηνύματα υποβολών μας έχουν αυτή τη μορφή, θα διευκολυνθούμε τόσο εσείς όσο και οι συνεργάτες μας. +Tο έργο Git έχει καλά μορφοποιημένα μηνύματα υποβολών. Αν τρέξετε `git log --no-merges` θα δείτε πως φαίνεται ένα όμορφα μορφοποιημένο ιστορικό υποβολών ενός έργου. -In the following examples, and throughout most of this book, for the sake of brevity this book doesn't have nicely-formatted messages like this; instead, we use the `-m` option to `git commit`. -Do as we say, not as we do. +[NOTE] +.Κάντε ό,τι λέμε, όχι ό,τι κάνουμε. +==== +Για χάρη συντομίας, πολλά από τα παραδείγματα αυτού του βιβλίου δεν έχουν μηνύματα υποβολών που είναι μορφοποιημένα όμορφα, όπως παραπάνω· αντί γι' αυτό χρησιμοποιήστε την επιλογή `-m` στην εντολή `git commit`. + +Πιο απλά, κάντε ό,τι λέμε, όχι ό,τι κάνουμε. +==== -[[_private_team]] -==== Private Small Team +[[r_private_team]] +==== Ιδιωτικές μικρές ομάδες (((contributing, private small team))) -The simplest setup you're likely to encounter is a private project with one or two other developers. -``Private,'' in this context, means closed-source – not accessible to the outside world. -You and the other developers all have push access to the repository. +Η απλούστερη ρύθμιση που ενδεχομένως θα συναντήσουμε είναι ένα ιδιωτικό έργο με έναν ή δύο ακόμα προγραμματιστές. +"`Ιδιωτικό`" εδώ σημαίνει κλειστού-κώδικα -- που δεν είναι προσβάσιμος από τον έξω κόσμο. +Εμείς και όλοι οι άλλοι προγραμματιστές έχουμε πρόσβαση ώθησης στο αποθετήριο. -In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. -You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time. -Let's see what it might look like when two developers start to work together with a shared repository. -The first developer, John, clones the repository, makes a change, and commits locally. -(The protocol messages have been replaced with `...` in these examples to shorten them somewhat.) +Σε αυτό το περιβάλλον, μπορούμε να ακολουθήσουμε μια ροή εργασίας παρόμοια με αυτή που θα ακολουθούσαμε αν χρησιμοποιούσαμε το Subversion ή κάποιο άλλο συγκεντρωτικό σύστημα. +Συνεχίζουμε να έχουμε πλεονεκτήματα όπως η υποβολή εκτός σύνδεσης και η απλούστερη διακλάδωση και συγχώνευση, αλλά η ροή εργασίας μπορεί να είναι πολύ παρόμοια· η κύρια διαφορά είναι ότι οι συγχωνεύσεις συμβαίνουν στην πλευρά του πελάτη αντί στον διακομιστή κατά τη διάρκεια της υποβολής. +Ας δούμε τι μπορεί να συμβεί όταν δύο προγραμματιστές αρχίζουν να συνεργάζονται σε ένα κοινό αποθετήριο. +Ο πρώτος προγραμματιστής, ο Τζον, κλωνοποιεί το αποθετήριο, κάνει μια αλλαγή και την υποβάλλει τοπικά. +Τα μηνύματα πρωτοκόλλου έχουν αντικατασταθεί με `...` σε αυτά τα παραδείγματα για να τα συντομεύσουμε κάπως. [source,console] ------ +---- # John's Machine $ git clone john@githost:simplegit.git -Initialized empty Git repository in /home/john/simplegit/.git/ +Cloning into 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb -$ git commit -am 'removed invalid default value' -[master 738ee87] removed invalid default value +$ git commit -am 'Remove invalid default value' +[master 738ee87] Remove invalid default value 1 files changed, 1 insertions(+), 1 deletions(-) ------ +---- -The second developer, Jessica, does the same thing – clones the repository and commits a change: +Η δεύτερη προγραμματίστρια, η Τζέσικα, κάνει το ίδιο πράγμα -- κλωνοποιεί το αποθετήριο και κάνει μια αλλαγή: [source,console] ------ +---- # Jessica's Machine $ git clone jessica@githost:simplegit.git -Initialized empty Git repository in /home/jessica/simplegit/.git/ +Cloning into 'simplegit'... ... $ cd simplegit/ $ vim TODO -$ git commit -am 'add reset task' -[master fbff5bc] add reset task +$ git commit -am 'Add reset task' +[master fbff5bc] Add reset task 1 files changed, 1 insertions(+), 0 deletions(-) ------ +---- -Now, Jessica pushes her work up to the server: +Τώρα, η Τζέσικα ωθεί την εργασία της στον διακομιστή: [source,console] ------ +---- # Jessica's Machine $ git push origin master ... To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master ------ +---- -John tries to push his change up, too: +Η τελευταία γραμμή της εξόδου δείχνει ένα χρήσιμο μήνυμα που επέστρεψε η ώθηση. +Η βασική μορφή είναι `.. fromref -> toref`, όπου `oldref` σημαίνει την παλιά αναφορά, `newref` σημαίνει την νέα αναφορά, `fromref` είναι το όνομα της τοπικής αναφοράς που ωθήθηκε και `toref` είναι το όνομα της απομακρυσμένης αναφοράς που ενημερώθηκε. +Θα βλέπουμε παρόμοια με αυτό μηνύματα στις συζητήσεις, οπότε το να έχουμε μια ιδέα του τι σημαίνουν θα μας βοηθήσει να καταλαβαίνουμε τις διάφορες καταστάσεις των αποθετηρίων. +Περισσότερες λεπτομέρειες υπάρχουν στην τεκμηρίωση της εντολής https://git-scm.com/docs/git-push[git-push^]. + +Συνεχίζοντας το παράδειγμα, λίγο αργότερα, ο Τζον κάνει κάποιες αλλαγές, τις υποβάλει στο τοπικό του αποθετήριο και προσπαθεί να τις ωθήσει στον ίδιο διακομιστή: [source,console] ------ +---- # John's Machine $ git push origin master To john@githost:simplegit.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'john@githost:simplegit.git' ------ +---- + +Σε αυτήν την περίπτωση, δεν επιτράπηκε στον Τζον να ωθήσει επειδή στο μεταξύ έχει ωθήσει η Τζέσικα τις _αλλαγές της_. +Αυτό είναι κάτι που πρέπει να καταλάβουμε καλά, αν είμαστε συνηθισμένοι στο Subversion, επειδή όπως παρατηρούμε οι δύο προγραμματιστές δεν επεξεργάστηκαν το ίδιο αρχείο. +Παρόλο που το Subversion πραγματοποιεί αυτόματα μια τέτοια συγχώνευση στον διακομιστή, αν τα αρχεία που έχουν υποστεί επεξεργασία είναι διαφορετικά, στο Git πρέπει _πρώτα_ να συγχωνεύσουμε τις υποβολές τοπικά. +Με άλλα λόγια, ο Τζον πρέπει να ανακτήσει (fetch) τις αλλαγές της Τζέσικα και να τις συγχωνεύσει στο τοπικό του αποθετήριο προτού του επιτραπεί να ωθήσει: -John isn't allowed to push because Jessica has pushed in the meantime. -This is especially important to understand if you're used to Subversion, because you'll notice that the two developers didn't edit the same file. -Although Subversion automatically does such a merge on the server if different files are edited, in Git you must merge the commits locally. -John has to fetch Jessica's changes and merge them in before he will be allowed to push: +Το πρώτο βήμα που κάνει ο Τζον είνα να ανακτήσει τη δουλειά της Τζέσικα (αυτό μόνο _ανακτά_ τη δουλειά που ανέβασε η Τζέσικα, δεν τη συγχωνεύει ακόμα στη δουλειά του Τζον): [source,console] ------ +---- $ git fetch origin ... From john@githost:simplegit + 049d078...fbff5bc master -> origin/master ------ +---- -At this point, John's local repository looks something like this: +Σε αυτό το σημείο, το τοπικό αποθετήριο του Τζον μοιάζει με αυτό: -.John's divergent history. -image::images/small-team-1.png[John's divergent history.] +.Το αποκλίνον ιστορικό του Τζον. +image::images/small-team-1.png[Το αποκλίνον ιστορικό του Τζον] -John has a reference to the changes Jessica pushed up, but he has to merge them into his own work before he is allowed to push: +Τώρα ο Τζον μπορεί να συγχωνεύσει τη δουλειά της Τζέσικα που ανέκτησε με δική του τοπική δουλειά: [source,console] ------ +---- $ git merge origin/master -Merge made by recursive. +Merge made by the 'recursive' strategy. TODO | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) ------ +---- -The merge goes smoothly – John's commit history now looks like this: +Εφόσον η συγχώνευση ολοκληρωθεί ομαλά, το ιστορικό του Τζον θα μοιάζει με αυτό: -.John's repository after merging `origin/master`. -image::images/small-team-2.png[John's repository after merging `origin/master`.] +.Το αποθετήριο του Τζον μετά τη συγχώνευση του `origin/master` +image::images/small-team-2.png[Το αποθετήριο του Τζον μετά τη συγχώνευση του `origin/master`] -Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server: +Σε αυτό το σημείο, ο Τζον μπορεί να δοκιμάσει τον κώδικά του για να βεβαιωθεί ότι δεν έχει επηρεαστεί από τη δουλειά της Τζέσικα και εφόσον όλα είναι καλά, μπορεί να ωθήσει τη νέα συγχωνευμένη εργασία του στον διακομιστή: [source,console] ------ +---- $ git push origin master ... To john@githost:simplegit.git fbff5bc..72bbc59 master -> master ------ +---- -Finally, John's commit history looks like this: +Τελικά, το ιστορικό υποβολών του Τζον θα μοιάζει με αυτό: -.John's history after pushing to the `origin` server. -image::images/small-team-3.png[John's history after pushing to the `origin` server.] +.Ιστορικό του Τζον μετά την ώθηση στον διακομιστή `origin` +image::images/small-team-3.png[Ιστορικό του Τζον μετά την ώθηση στον διακομιστή `origin`] -In the meantime, Jessica has been working on a topic branch. -She's created a topic branch called `issue54` and done three commits on that branch. -She hasn't fetched John's changes yet, so her commit history looks like this: +Στο μεταξύ, η Τζέσικα εργαζόταν πάνω σε έναν θεματικό κλάδο που ονόμασε `issue54` και έκανε τρεις υποβολές σε αυτόν. +Δεν έχει ακόμη ανακτήσει τις αλλαγές του Τζον, επομένως το ιστορικό υποβολών της μοιάζει ως εξής: -.Jessica's topic branch. -image::images/small-team-4.png[Jessica's topic branch.] +.Θεματικός κλάδος της Τζέσικα +image::images/small-team-4.png[Θεματικός κλάδος της Τζέσικα] -Jessica wants to sync up with John, so she fetches: +Ξαφνικά, η Τζέσικα μαθαίνει ότι ο Τζον ώθησε νέα δουλειά στον διακομιστή και θέλει να της ρίξει μια ματιά, οπότε ανακτά (fetch) όλα τα δεδομένα που δεν έχει, από τον διακομιστή: [source,console] ------ +---- # Jessica's Machine $ git fetch origin ... From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ------ +---- -That pulls down the work John has pushed up in the meantime. -Jessica's history now looks like this: +Έτσι, ανακτά τη δουλειά που έχει ωθήσει ο Τζον στο μεταξύ. +To ιστορικό της Τζέσικα μοιάζει τώρα με το εξής: -.Jessica's history after fetching John's changes. -image::images/small-team-5.png[Jessica's history after fetching John's changes.] +.Ιστορικό της Τζέσικα μετά την ανάκτηση των αλλαγών του Τζον +image::images/small-team-5.png[Ιστορικό της Τζέσικα μετά την ανάκτηση των αλλαγών του Τζον] -Jessica thinks her topic branch is ready, but she wants to know what she has to merge into her work so that she can push. -She runs `git log` to find out: +Η Τζέσικα θεωρεί ότι ο τοπικός της κλάδος είναι έτοιμος, αλλά θέλει να γνωρίζει ποιο μέρος της δουλειάς του Τζον πρέπει να συγχωνεύσει στη δική της δουλειά, ώστε να ωθήσει. +Εκτελεί την εντολή `git log` για να το μάθει: [source,console] ------ +---- $ git log --no-merges issue54..origin/master commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith Date: Fri May 29 16:01:27 2009 -0700 - removed invalid default value ------ + Remove invalid default value +---- + +Η σύνταξη `issue54..origin/master` είναι ένα φίλτρο της εντολής `log` που ζητά από το Git να εμφανίσει μόνο τον κατάλογο των υποβολών που βρίσκονται στον τελευταίο κλάδο (στη συγκεκριμένη περίπτωση τον `origin/master`) που δεν βρίσκονται στον πρώτο κλάδο (στη συγκεκριμένη περίπτωση "`issue54`"). +Θα εξετάσουμε λεπτομερώς σε αυτή τη σύνταξη στην ενότητα <>. -The `issue54..origin/master` syntax is a log filter that asks Git to only show the list of commits that are on the latter branch (in this case `origin/master`) that are not on the first branch (in this case `issue54`). -We'll go over this syntax in detail in <<_commit_ranges>>. +Από την έξοδο που επιστρέφεται μπορούμε να δούμε ότι υπάρχει μόνο μία υποβολή που έχει κάνει ο Τζον την οποία δεν έχει συγχωνεύσει η Τζέσικα. +Αν συγχωνεύσει τον κλάδο `origin/master`, αυτή είναι η μόνη υποβολή που θα τροποποιήσει την τοπική εργασία της. -For now, we can see from the output that there is a single commit that John has made that Jessica has not merged in. -If she merges `origin/master`, that is the single commit that will modify her local work. +Τώρα, η Τζέσικα μπορεί να συγχωνεύσει τον θεματικό της κλάδο στον δικό της `master`, να συγχωνεύσει τη δουλειά του Τζον (`origin/master`) στον δικό της κλάδο `master` και στη συνέχεια να ωθήσει ξανά στον διακομιστή. -Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again. -First, she switches back to her master branch to integrate all this work: +Πρώτα (και αφού έχει υποβάλει τη δουλειά της στον θεματικό κλάδο `issue54`), μεταβαίνει στον κύριο κλάδο της για να ενσωματώσει όλη αυτή τη δουλειά: [source,console] ------ +---- $ git checkout master Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ------ +---- -She can merge either `origin/master` or `issue54` first – they're both upstream, so the order doesn't matter. -The end snapshot should be identical no matter which order she chooses; only the history will be slightly different. -She chooses to merge in `issue54` first: +Μπορεί να συγχωνεύσει πρώτα είτε τον κλάδο `origin/master` είτε τον `issue54` -- και οι δύο είναι upstream, οπότε η σειρά δεν έχει σημασία. +Το τελικό στιγμιότυπο θα είναι πανομοιότυπο ανεξάρτητα από τη σειρά που επιλέγει· μόνο το ιστορικό θα είναι ελαφρά διαφορετικό. +Επιλέγει να συγχωνεύσει πρώτα στον `issue54`: [source,console] ------ +---- $ git merge issue54 Updating fbff5bc..4af4298 Fast forward README | 1 + lib/simplegit.rb | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) ------ +---- -No problems occur; as you can see it was a simple fast-forward. -Now Jessica merges in John's work (`origin/master`): +Δεν παρουσιάζονται προβλήματα· όπως μπορούμε να δούμε ήταν μια απλή συγχώνευση ταχυπροώθησης. +Τώρα η Τζέσικα ολοκληρώνει τη διαδικασία της τοπικής συγχώνευσης, συγχωνεύοντας την δουλειά του Τζον που κάθεται στον κλάδο `origin/master`: [source,console] ------ +---- $ git merge origin/master Auto-merging lib/simplegit.rb -Merge made by recursive. +Merge made by the 'recursive' strategy. lib/simplegit.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ------ +---- -Everything merges cleanly, and Jessica's history looks like this: +Τα πάντα συγχωνεύονται καθαρά και το ιστορικό της Τζέσικα μοιάζει με αυτό: -.Jessica's history after merging John's changes. -image::images/small-team-6.png[Jessica's history after merging John's changes.] +.Το ιστορικό της Τζέσικα μετά τη συγχώνευση των αλλαγών του Τζον +image::images/small-team-6.png[Το ιστορικό της Τζέσικα μετά τη συγχώνευση των αλλαγών του Τζον] -Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed again in the meantime): +Τώρα, ο κλάδος `origin/master` είναι προσβάσιμος από τον κλάδο `master` της Τζέσικα, οπότε θα πρέπει να είναι σε θέση να ωθήσει με επιτυχία (υποθέτοντας ότι ο Τζον δεν ώθησε ξανά στο μεταξύ): [source,console] ------ +---- $ git push origin master ... To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ------ +---- -Each developer has committed a few times and merged each other's work successfully. +Κάθε προγραμματιστής έχει υποβάλλει μερικές φορές και έχει συγχωνεύσει επιτυχώς στο έργο του άλλου. -.Jessica's history after pushing all changes back to the server. -image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] +.Το ιστορικό της Τζέσικα μετά την ώθηση όλων των αλλαγών στον διακομιστή. +image::images/small-team-7.png[Το ιστορικό της Τζέσικα μετά την ώθηση όλων των αλλαγών στον διακομιστή] -That is one of the simplest workflows. -You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated. -When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. -The general sequence is something like this: +Αυτή είναι μία από τις πιο απλές ροές εργασίας. +Εργαζόμαστε για κάποιο χρονικό διάστημα (συνήθως σε έναν θεματικό κλάδο) και συγχωνεύουμε τον κύριο κλάδο μας όταν είναι έτοιμος να ενσωματωθεί. +Όταν θέλουμε να κοινοποιήσουμε αυτή τη δουλειά, ανακτούμε και συγχωνεύουμε από το `origin/master` στο `master` αν αυτός έχει αλλάξει και τον, και τελικά ωθούμε τον κλάδο μας `master` στον διακομιστή. +Η συνήθης ακολουθία γεγονότων είναι κάτι σαν: -.General sequence of events for a simple multiple-developer Git workflow. -image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] +.Γενική ακολουθία γεγονότων για μια απλή ροή εργασίας με πολλούς προγραμματιστές +image::images/small-team-flow.png[Γενική ακολουθία γεγονότων για μια απλή ροή εργασίας με πολλούς προγραμματιστές] -==== Private Managed Team +==== Ιδιωτική ομάδα με διαχειριστή (((contributing, private managed team))) -In this next scenario, you'll look at contributor roles in a larger private group. -You'll learn how to work in an environment where small groups collaborate on features and then those team-based contributions are integrated by another party. +Σε αυτό το σενάριο, θα εξετάσουμε τους διάφορους ρόλους των συνεργατών σε μια μεγαλύτερη ιδιωτική ομάδα. +Θα μάθουμε πως να εργαζόμαστε σε ένα περιβάλλον στο οποίο οι μικρές ομάδες συνεργάζονται σε κάποια θέματα και στη συνέχεια οι συνεισφορές της κάθε ομάδας ενσωματώνονται από κάποιον άλλο. -Let's say that John and Jessica are working together on one feature, while Jessica and Josie are working on a second. -In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. -In this scenario, all work is done in team-based branches and pulled together by the integrators later. +Ας πούμε ότι ο Τζον και η Τζέσικα δουλεύουν μαζί σε μια λειτουργικότητα (ας την ονομάσουμε "`featureA`") ενώ η Τζέσικα και η Τζόσι εργάζονται σε μια άλλη (ας πούμε, "`featureB`"). +Σε αυτή την περίπτωση, η εταιρεία χρησιμοποιεί ένα είδος ροής εργασίας με διαχειριστή ενσωμάτωσης, στην οποία η εργασία των μεμονωμένων ομάδων ενσωματώνεται μόνο από ορισμένους μηχανικούς και ο κλάδος `master` του κύριου αποθετηρίου μπορεί να ενημερωθεί μόνο από αυτούς τους μηχανικούς. +Σε αυτό το σενάριο όλη η δουλειά γίνεται σε κλάδους κοινούς σε ομάδες και συγκεντρώνονται αργότερα από τους υπεύθυνους ενσωμάτωσης. -Let's follow Jessica's workflow as she works on her two features, collaborating in parallel with two different developers in this environment. -Assuming she already has her repository cloned, she decides to work on `featureA` first. -She creates a new branch for the feature and does some work on it there: +Ας ακολουθήσουμε τη ροή εργασίας της Τζέσικα καθώς εργάζεται στις δύο λειτουργικότητές της, συνεργαζόμενη παράλληλα με δύο διαφορετικούς προγραμματιστές σε αυτό το περιβάλλον. +Αν υποθέσουμε ότι η Τζέσικα έχει ήδη κλωνοποιήσει το αποθετήριό της και ότι αποφασίζει να εργαστεί πρώτα στη λειτουργικότητα `featureA`. +Δημιουργεί ένα νέο κλάδο για τη λειτουργικότητα και κάνει κάποια δουλειά σε αυτό: [source,console] ------ +---- # Jessica's Machine $ git checkout -b featureA Switched to a new branch 'featureA' $ vim lib/simplegit.rb -$ git commit -am 'add limit to log function' -[featureA 3300904] add limit to log function +$ git commit -am 'Add limit to log function' +[featureA 3300904] Add limit to log function 1 files changed, 1 insertions(+), 1 deletions(-) ------ +---- -At this point, she needs to share her work with John, so she pushes her `featureA` branch commits up to the server. -Jessica doesn't have push access to the `master` branch – only the integrators do – so she has to push to another branch in order to collaborate with John: +Σε αυτό το σημείο, πρέπει να κοινοποιήσει τη δουλειά της με τον Τζον, οπότε ωθεί τις υποβολές του κλάδου της `featureA` στον διακομιστή. +Η Τζέσικα δεν έχει πρόσβαση ώθησης στον κλάδο `master` -- μόνον οι μηχανικοί ενσωμάτωσης έχουν -- γι' αυτό πρέπει να ωθήσει σε έναν άλλο κλάδο για να συνεργαστεί με τον Τζον: [source,console] ------ +---- $ git push -u origin featureA ... To jessica@githost:simplegit.git * [new branch] featureA -> featureA ------ +---- -Jessica e-mails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now. -While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie. -To begin, she starts a new feature branch, basing it off the server's `master` branch: +Η Τζέσικα ειδοποιεί τον Τζον για να του πει ότι έχει ωθήσει μέρος της δουλειάς της σε έναν κλάδο που ονομάζεται `featureA` και μπορεί τώρα να τον δει. +Ενώ περιμένει τα σχόλια του Τζον, η Τζέσικα αποφασίζει να αρχίσει να δουλεύει στη λειτουργικότητα `featureB` με την Τζόσι. +Για να ξεκινήσει, ξεκινά έναν νέο κλάδο, με βάση τον κλάδο `master` του διακομιστή: [source,console] ------ +---- # Jessica's Machine $ git fetch origin $ git checkout -b featureB origin/master Switched to a new branch 'featureB' ------ +---- -Now, Jessica makes a couple of commits on the `featureB` branch: +Τώρα, η Τζέσικα κάνει δύο υποβολές στον κλάδο `featureB`: [source,console] ------ +---- $ vim lib/simplegit.rb -$ git commit -am 'made the ls-tree function recursive' -[featureB e5b0fdc] made the ls-tree function recursive +$ git commit -am 'Make ls-tree function recursive' +[featureB e5b0fdc] Make ls-tree function recursive 1 files changed, 1 insertions(+), 1 deletions(-) $ vim lib/simplegit.rb -$ git commit -am 'add ls-files' -[featureB 8512791] add ls-files +$ git commit -am 'Add ls-files' +[featureB 8512791] Add ls-files 1 files changed, 5 insertions(+), 0 deletions(-) ------ +---- -Jessica's repository looks like this: +Το αποθετήριο της Τζέσικα μοιάζει με αυτό: -.Jessica's initial commit history. -image::images/managed-team-1.png[Jessica's initial commit history.] +.Αρχικό ιστορικό υποβολών της Τζέσικα +image::images/managed-team-1.png[Αρχικό ιστορικό υποβολών της Τζέσικα] -She's ready to push up her work, but gets an e-mail from Josie that a branch with some initial work on it was already pushed to the server as `featureBee`. -Jessica first needs to merge those changes in with her own before she can push to the server. -She can then fetch Josie's changes down with `git fetch`: +Είναι έτοιμη να ωθήσει τη δουλειά της, αλλά λαμβάνει ένα e-mail από την Τζόσι ότι ένας κλάδος με κάποια αρχική εργασία σε αυτήν τη λειτουργικότητα έχει ήδη ωθηθεί στον διακομιστή ως `featureBee`. +Η Τζέσικα πρέπει πρώτα να συγχωνεύσει αυτές τις αλλαγές με τις δικές της, προτού να μπορέσει να ωθήσει στον διακομιστή. +Πρώτα ανακτά τις αλλαγές της Τζόσι με `git fetch`: [source,console] ------ +---- $ git fetch origin ... From jessica@githost:simplegit * [new branch] featureBee -> origin/featureBee ------ +---- -Jessica can now merge this into the work she did with `git merge`: +Με την προϋπόθεση ότι η Τζέσικα βρίσκεται ακόμα στον κλάδο της `featureB`, μπορεί να συγχωνεύσει τη δουλειά της Τζόσι με `git merge`: [source,console] ------ +---- $ git merge origin/featureBee Auto-merging lib/simplegit.rb -Merge made by recursive. +Merge made by the 'recursive' strategy. lib/simplegit.rb | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) ------ +---- -There is a bit of a problem – she needs to push the merged work in her `featureB` branch to the `featureBee` branch on the server. -She can do so by specifying the local branch followed by a colon (:) followed by the remote branch to the `git push` command: +Σε αυτό το σημείο, η Τζέσικα θέλει να ωθήσει όλο αυτόν τον συγχωνευμένο κλάδο "`featureB`" στον διακομιστή, αλλά δεν θέλει απλά να ωθήσει τον δικό της κλάδο `featureB`. +Αντίθετα, αφού η Τζόσι έχει ήδη ξεκινήσει έναν upstream κλάδο `featureBee`, η Τζέσικα θέλει να ωθήσει σε _αυτόν_ τον κλάδο, το οποίο και κάνει με την εντολή: [source,console] ------ +---- $ git push -u origin featureB:featureBee ... To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee ------ +---- -This is called a _refspec_. -See <<_refspec>> for a more detailed discussion of Git refspecs and different things you can do with them. -Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later. +Αυτό ονομάζεται _refspec_. +Μια πιο λεπτομερής συζήτηση για τα refspec του Git και διάφορα πράγματα που μπορούμε να κάνουμε με αυτά υπάρχουν στην ενότητα <>. +Παρατηρούμε επίσης τη σημαία `-u`· είναι συντομογραφία του `--set-upstream`, που ρυθμίζει τους κλάδους για ευκολότερη ώθηση και ελκυσμό (pulling) αργότερα. -Next, John e-mails Jessica to say he's pushed some changes to the `featureA` branch and asks her to verify them. -She runs a `git fetch` to pull down those changes: +Ξάφνου, η Τζέσικα παίρνει ένα e-mail από τον Τζον, που της λέει ότι έχει ωθήσει κάποιες αλλαγές στον κλάδο `featureA` στον οποίο συνεργάζονται και της ζητά να τις ρίξει μια ματιά. +Και πάλι, η Τζέσικα εκτελεί ένα `git fetch` για να ανακτήσει _ό,τι_ νέο υλικό υπάρχει στον διακομιστή, συμπεριλμβανομένων φυσικά των αλλαγών του Τζον: [source,console] ------ +---- $ git fetch origin ... From jessica@githost:simplegit 3300904..aad881d featureA -> origin/featureA ------ +---- -Then, she can see what has been changed with `git log`: +Η Τζέσικα μπορεί να δει το log της δουλειάς του Τζον συγκρίνοντας το περιεχόμενο του ενημερωμένου κλάδου `featureA` με το τοπικό της αντίγραφο του ίδιου κλάδου: [source,console] ------ +---- $ git log featureA..origin/featureA commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 Author: John Smith Date: Fri May 29 19:57:33 2009 -0700 - changed log output to 30 from 25 ------ + Increase log output to 30 from 25 +---- -Finally, she merges John's work into her own `featureA` branch: +Εφόσον της αρέσει αυτό που βλέπει μπορεί να συγχωνεύσει τη δουλειά του Τζον στον δικό της τοπικό κλάδο `featureA`: [source,console] ------ +---- $ git checkout featureA Switched to branch 'featureA' $ git merge origin/featureA @@ -448,218 +463,221 @@ Updating 3300904..aad881d Fast forward lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) ------ +---- -Jessica wants to tweak something, so she commits again and then pushes this back up to the server: +Τέλος, η Τζέσικα ίσως θέλει να κάνει μερικές μικροαλλαγές, σε όλο αυτό το υποβεβλημένο περιεχόμενο, οπότε μπορεί να κάνει τις αλλαγές που θέλει, να τις υποβάλει στον τοπικό της κλάδο `featureA` και να ωθήσει το τελικό αποτέλεσμα στον διακομιστή: [source,console] ------ -$ git commit -am 'small tweak' -[featureA 774b3ed] small tweak +---- +$ git commit -am 'Add small tweak to merged content' +[featureA 774b3ed] Add small tweak to merged content 1 files changed, 1 insertions(+), 1 deletions(-) $ git push ... To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA ------ +---- -Jessica's commit history now looks something like this: +Το ιστορικό υποβολών της Τζέσικα τώρα μοιάζει κάτι τέτοιο: -.Jessica's history after committing on a feature branch. -image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] +.Ιστορικό της Τζέσικα μετά την υποβολή σε έναν θεματικό κλάδο +image::images/managed-team-2.png[Ιστορικό της Τζέσικα μετά την υποβολή σε έναν θεματικό κλάδο] -Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. -After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: +Κάποια στιγμή, οι Τζέσικα, Τζόσι και Τζον ενημερώνουν τους διαχειριστές ενσωμάτωσης ότι οι κλάδοι `featureA` και `featureBee` στον διακομιστή είναι έτοιμοι για ενσωμάτωση στον κύριο κλάδο. +Αφού οι διαχειριστές ενσωμάτωσης συγχωνεύσουν αυτούς τους κλάδους στον κύριο κλάδο, μία ανάκτηση θα κατεβάσει τη νέα υποβολή συγχώνευσης, κάνοντας το ιστορικό να μοιάζει με αυτό: -.Jessica's history after merging both her topic branches. -image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] +.Ιστορικό της Τζέσικα μετά τη συγχώνευση και των δύο θεματικών κλάδων της +image::images/managed-team-3.png[Ιστορικό της Τζέσικα μετά τη συγχώνευση και των δύο θεματικών κλάδων της] -Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. -The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. -The sequence for the workflow you saw here is something like this: +Πολλές ομάδες τείνουν προς τη χρήση του Git εξαιτίας ακριβώς αυτής της δυνατότητας, να έχουν πολλές ομάδες που εργάζονται παράλληλα και να συγχωνεύουν τις διαφορετικές γραμμές εργασίας αργότερα. +Η ικανότητα μικρότερων υποομάδων μιας ομάδας να συνεργάζονται μέσω απομακρυσμένων κλάδων χωρίς να χρειάζεται απαραίτητα να εμπλέξουν ή να φρενάρουν ολόκληρη την ομάδα είναι ένα τεράστιο όφελος που παρέχει το Git. +Η ακολουθία της ροής εργασίας που είδαμε εδώ είναι κάτι σαν αυτό: -.Basic sequence of this managed-team workflow. -image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] +.Βασική ακολουθία αυτής της ροής εργασίας διαχειριζόμενη ομάδα +image::images/managed-team-flow.png[Βασική ακολουθία αυτής της ροής εργασίας διαχειριζόμενη ομάδα] -[[_public_project]] -==== Forked Public Project +[[r_public_project]] +==== Αποσχισμένα δημόσια έργα -(((contributing, public small project))) -Contributing to public projects is a bit different. -Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. -This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, Google Code, repo.or.cz, and others), and many project maintainers expect this style of contribution. -The next section deals with projects that prefer to accept contributed patches via e-mail. +(((συνεισφορές, δημόσια μικρά έργα))) +Η συνεργασία στα δημόσια έργα είναι κάπως διαφορετική. +Επειδή δεν έχουμε δικαιώματα για άμεση ενημέρωση κλάδων στο έργο, θα πρέπει να στέλνουμε τη δουλειά μας στους διαχειριστές με κάποιον άλλο τρόπο. +Το πρώτο παράδειγμα περιγράφει τη συνεισφορά μέσω απόσχισης (forking) σε διακομιστές Git που υποστηρίζουν την εύκολη απόσχιση. +Πολλοί διακομιστές φιλοξενίας (συμπεριλαμβανομένων των GitHub, BitBucket, repo.or.cz και άλλων) και πολλοί διαχειριστές έργων αναμένουν αυτό το στυλ συνεισφοράς. +Η επόμενη ενότητα ασχολείται με έργα που προτιμούν να δέχονται συνεισφορές/επιθέματα μέσω e-mail. -First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there. -The sequence looks basically like this: +Αρχικά, ίσως θέλουμε να κλωνοποιήσουμε το κύριο αποθετήριο, να δημιουργήσουμε έναν θεματικό κλάδο για το επίθεμα ή τα επιθέματα που σκοπεύουμε να συνεισφέρουμε και να δουλεύουμε σε αυτόν. +Η ακολουθία μοιάζει ως εξής: [source,console] ------ -$ git clone (url) +---- +$ git clone $ cd project $ git checkout -b featureA -# (work) + ... work ... $ git commit -# (work) + ... work ... $ git commit ------ +---- [NOTE] ==== -You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review – see <<_rewriting_history>> for more information about interactive rebasing. +Ίσως θελήσετε να χρησιμοποιήσετε την εντολή `rebase -i` για να συνθλίψετε (squash) την εργασία σας σε μία μόνο υποβολή ή να αναδιατάξετε την εργασία σας στις υποβολές για να διευκολύνετε τον διαχειριστή που θα ελέγξει το επίθεμά σας -- βλ. <> για περισσότερες πληροφορίες σχετικά με τη διαδραστική αλλαγή βάσης. ==== -When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project. -You then need to add in this new repository URL as a second remote, in this case named `myfork`: +Όταν ολοκληρώσουμε την εργασία μας στον κλάδο μας και είμαστε έτοιμοι να τον επιστρέψουμε στους διαχειριστές, μεταβαίνουμε στην αρχική σελίδα του έργου και κάνουμε κλικ στο κουμπί "`Fork`", ώστε να δημιουργήσουμε τη δική μας εγγράψιμη διχάλα του έργου. +Στη συνέχεια, πρέπει να προσθέσουμε το URL αυτού του αποθετηρίου ως απομακρυσμένο αποθετήριο, στη συγκεκριμένη περίπτωση ας το ονομάσουμε `myfork`: [source,console] ------ -$ git remote add myfork (url) ------ +---- +$ git remote add myfork +---- -Then you need to push your work up to it. -It's easiest to push the topic branch you're working on up to your repository, rather than merging into your master branch and pushing that up. -The reason is that if the work isn't accepted or is cherry picked, you don't have to rewind your master branch. -If the maintainers merge, rebase, or cherry-pick your work, you'll eventually get it back via pulling from their repository anyhow: +Μετά πρέπει να ωθήσουμε την εργασία μας σε αυτό το αποθετήριο. +Είναι ευκολότερο να ωθήσουμε τον θεματικό κλάδο στον οποίο εργαζόμαστε στο αποσχισμένο μας αποθετήριο παρά να τον συγχωνεύσουμε στον κλάδο `master` και να ωθήσουμε αυτόν. +Ο λόγος είναι ότι εάν η εργασία δεν γίνει αποδεκτή ή γίνουν αποδεκτά μόνο κάποια τμήματά της (cherry-picked), δεν χρειάζεται να επαναφέρουμε τον κύριο κλάδο μας (η Git `cherry-pick` λειτουργία αναλύεται με περισσότερη λεπτομέρια στο <>) +Αν οι διαχειριστές συγχωνεύσουν (`merge`), επανατοποθετήσουν (`rebase`) ή επιλέξουν μόνον τμήματα της δουλειάς μας (`cherry-pick`), τότε κάποια στιγμή θα την πάρουμε πίσω τραβώντας την από το αποθετήριό τους: + +Σε κάθε περίπτωση μπορούμε να ωθήσουμε την δουλειά μας ως εξής: [source,console] ------ +---- $ git push -u myfork featureA ------ +---- -(((git commands, request-pull))) -When your work has been pushed up to your fork, you need to notify the maintainer. -This is often called a pull request, and you can either generate it via the website – GitHub has its own Pull Request mechanism that we'll go over in <<_github>> – or you can run the `git request-pull` command and e-mail the output to the project maintainer manually. +(((εντολές git, request-pull))) +Όταν έχουμε ωθήσει τη δουλειά μας στη διχάλα μας, πρέπει να ειδοποιήσουμε τους συντηρητές του αρχικού έργου ότι έχουμε κάνει κάποια δουειά που θέλουμε να συγχωνεύσουν. +Αυτό συχνά ονομάζεται _αίτημα ελκυσμού_ (pull request) και μπορούμε είτε να το δημιουργήσουμε μέσω της ιστοσελίδας -- το GitHub έχει τον δικό του μηχανισμό "`αιτημάτων ελκυσμού`", τον οποίο θα εξετάσουμε στην ενότητα <> -- είτε να τρέξουμε την εντολή `git request-pull` και να στείλουμε την έξοδό της με e-mail στον διαχειριστή του έργου. -The `request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you're asking to be pulled in. -For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed up, she can run this: +Η εντολή `request-pull` παίρνει τον βασικό κλάδο στον οποίο θέλουμε να ελκυστεί ο θεματικός μας κλάδος και το URL του αποθετηρίου Git από το οποίο θέλουμε να τον τραβήξουν και εξάγει μια σύνοψη όλων των αλλαγών που ζητάμε να ελκυστούν. +Για παράδειγμα, αν η Τζέσικα θέλει να στείλει ένα αίτημα ελκυσμού στον Τζον και έχει κάνει δύο υποβολές στον θεματικό κλάδο που μόλις ώθησε, μπορεί να τρέξει το εξής: [source,console] ------ +---- $ git request-pull origin/master myfork The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: - John Smith (1): - added a new function +Jessica Smith (1): + Create new function are available in the git repository at: - git://githost/simplegit.git featureA + https://githost/simplegit.git featureA Jessica Smith (2): - add limit to log function - change log output to 30 from 25 + Add limit to log function + Increase log output to 30 from 25 lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) ------ +---- -The output can be sent to the maintainer – it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from. +Η έξοδος μπορεί να αποσταλεί στον συντηρητή του αποθετηρίου -- του λέει από πού διακλαδώθηκε η δουλειά, συνοψίζει τις υποβολές και λέει από πού να την τραβήξει. -On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected. -Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly. -For example, if you want to submit a second topic of work to the project, don't continue working on the topic branch you just pushed up – start over from the main repository's `master` branch: +Σε ένα έργο στο οποίο δεν είμαστε ο συντηρητής, είναι γενικά ευκολότερο να έχουμε έναν κλάδο όπως ο `master` να παρακολουθεί πάντα τον `origin/master` και να δουλεύουμε σε θεματικούς κλάδους τους οποίους μπορούμε εύκολα να διαγράψουμε αν απορριφθούν. +Η διατήρηση ξεχωριστών θεματικών κλάδων για διαφορετικά θέματα διευκολύνει επίσης την αλλαγή βάσης της εργασίας μας, αν η άκρη του κύριου αποθετηρίου έχει μετακινηθεί εν τω μεταξύ και οι υποβολές μας δεν εφαρμόζονται πλέον με καθαρό τρόπο. +Για παράδειγμα, εάν θέλουμε να δημιουργήσουμε ένα δεύτερο θέμα εργασίας στο έργο, καλό είναι να μην συνεχίζουμε να εργαζόμαστε στον κλάδο του θέματος το οποίο μόλις ωθήσαμε, αλλά να ξεκινήσουμε από τον κλάδο `master` του αποθετηρίου: [source,console] ------ +---- $ git checkout -b featureB origin/master -# (work) + ... work ... $ git commit $ git push myfork featureB -# (email maintainer) +$ git request-pull origin/master myfork + ... email generated request pull to maintainer ... $ git fetch origin ------ +---- -Now, each of your topics is contained within a silo – similar to a patch queue – that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: +Τώρα, κάθε θέμα μας περιέχεται μέσα σε ένα σιλό -- παρόμοια με μια ουρά επιθεμάτων -- το οποίο μπορούμε να ξαναγράψουμε, να επανατοποθετήσουμε και να τροποποιήσουμε χωρίς τα θέματα να παρεμβαίνουν ή να αλληλεπιδρούν μεταξύ τους, ως εξής: -.Initial commit history with `featureB` work. -image::images/public-small-1.png[Initial commit history with `featureB` work.] +.Αρχικό ιστορικό υποβολών με τη δουλειά από το `featureB` +image::images/public-small-1.png[Αρχικό ιστορικό υποβολών με τη δουλειά από το `featureB`] -Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. -In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: +Ας υποθέσουμε ότι ο συντηρητής του έργου έχει τραβήξει κάμποσα επιθέματα και έχει δοκιμάσει τον πρώτο μας κλάδο, αλλά δεν μπορεί να τον συγχωνεύσει χωρίς συγκρούσεις. +Σε αυτή την περίπτωση, μπορούμε να προσπαθήσουμε να αλλάξουμε τη βάση (rebase) αυτού του κλάδου στην κορυφή του κλάδου `origin/master`, να επιλύσουμε τις συγκρούσεις για τον διαχειριστή και στη συνέχεια να ωθήσουμε εκ νέου τις αλλαγές μας: [source,console] ------ +---- $ git checkout featureA $ git rebase origin/master $ git push -f myfork featureA ------ +---- -This rewrites your history to now look like <>. +Αυτό επανεγγράφει το ιστορικό μας, ώστε τώρα μοιάζει με το <>. -[[psp_b]] -.Commit history after `featureA` work. -image::images/public-small-2.png[Commit history after `featureA` work.] +[[r_psp_b]] +.Ιστορικό υποβολών μετά από δουλειά στο `featureA` +image::images/public-small-2.png[Ιστορικό υποβολών μετά από δουλειά στο `featureA`] -Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. -An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`). +Επειδή αλλάξαμε τη βάση του κλάδου, πρέπει να χρησιμοποιήσουμε την επιλογή `-f` στην εντολή `push`, ώστε να μπορέσουμε να αντικαταστήσουμε τον κλάδο `featureA` στον διακομιστή με μια υποβολή που δεν είναι απόγονός τoυ. +Μια εναλλακτική θα ήταν να ωθήσουμε αυτή τη νέα δουλειά σε ένα διαφορετικό κλάδο στον διακομιστή (ίσως με όνομα `featureAv2`). -Let's look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail. -You'll also take this opportunity to move the work to be based off the project's current `master` branch. -You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that up as a new branch: +Ας δούμε ένα ακόμα πιθανό σενάριο: ο διαχειριστής έχει εξετάσει την εργασία στον δεύτερό μας κλάδο και του αρέσει η ιδέα, αλλά θα ήθελε να αλλάξουμε μια-δυο λεπτομέρειες στην υλοποίησή της. +Θα εκμεταλλευτούμε αυτή την ευκαιρία για να αλλάξουμε τη βάση (rebase) της δουλειά μας ώστε να διακλαδίζεται από τον τρέχοντα κλάδο `master` του έργου. +Ξεκινάμε ένα νέο κλάδο που διακλαδίζεται από τον τρέχοντα κλάδο `origin/master`, συνθλίβουμε (squash) τις αλλαγές του `featureB` σε αυτόν, επιλύουμε τυχόν συγκρούσεις, κάνουμε τις αλλαγές στην υλοποίηση που μας ζητήθηκαν και στη συνέχεια τα ωθούμε όλα αυτά ως έναν νέο κλάδο: -(((git commands, merge, squash))) +(((εντολές git, merge, squash))) [source,console] ------ +---- $ git checkout -b featureBv2 origin/master $ git merge --squash featureB -# (change implementation) + ... change implementation ... $ git commit $ git push myfork featureBv2 ------ +---- -The `--squash` option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit. -This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. -Also the `--no-commit` option can be useful to delay the merge commit in case of the default merge process. +Η επιλογή `--squash` παίρνει όλη τη δουλειά που υπάρχει στον συγχωνευμένο κλάδο και τη στριμώχνει (squashes it) σε ένα σύνολο αλλαγών ώστε παράγει μία κατάσταση του αποθετηρίου σαν να συνέβη στην πραγματικότητα μια συγχώνευση χωρίς όμως να πραγματοποιήσει υποβολή συγχώνευσης. +Αυτό σημαίνει ότι η μελλοντική μας υποβολή θα έχει μόνο έναν γονέα και μας επιτρέπει να εισάγουμε όλες τις αλλαγές από κάποιον άλλο κλάδο και μετά να κάνουμε περισσότερες αλλαγές πριν καταγράψουμε τη νέα υποβολή. +Επίσης, μία άλλη χρήσιμη επιλογή στην περίπτωση της προεπιλεγμένης διαδικασίας συγχώνευσης είναι η `--no-commit` που αναβάλλει την υποβολής συγχώνευσης. -Now you can send the maintainer a message that you've made the requested changes and they can find those changes in your `featureBv2` branch. +Τώρα μπορούμε να στείλουμε στον διαχειριστή ένα μήνυμα ότι έχουμε κάνει τις ζητούμενες αλλαγές και μπορεί να τις βρει στον κλάδο `featureBv2`. -.Commit history after `featureBv2` work. -image::images/public-small-3.png[Commit history after `featureBv2` work.] +.Ιστορικό υποβολών μετά τη δουλειά στο `featureBv2` +image::images/public-small-3.png[Ιστορικό υποβολών μετά τη δουλειά στο `featureBv2`] -[[_project_over_email]] -==== Public Project over E-Mail +[[r_project_over_email]] +==== Δημόσιο έργο μέσω e-mail -(((contributing, public large project))) -Many projects have established procedures for accepting patches – you'll need to check the specific rules for each project, because they will differ. -Since there are several older, larger projects which accept patches via a developer mailing list, we'll go over an example of that now. +(((συνεισφορές, δημόσιο μεγάλο έργο))) +Πολλά έργα έχουν θεσπίσει διαδικασίες για την αποδοχή των επιθεμάτων -- θα πρέπει να ελέγξουμε τους συγκεκριμένους κανόνες του έργου, επειδή διαφέρουν από έργο σε έργο. +Δεδομένου ότι υπάρχουν κάποια παλαιότερα, μεγαλύτερα έργα που αποδέχονται επιθέματα μέσω mailing list προγραμματιστών, θα εξετάσουμε ένα τέτοιο παράδειγμα. -The workflow is similar to the previous use case – you create topic branches for each patch series you work on. -The difference is how you submit them to the project. -Instead of forking the project and pushing to your own writable version, you generate e-mail versions of each commit series and e-mail them to the developer mailing list: +Η ροή εργασίας είναι παρόμοια με την προηγούμενη περίπτωση -- δημιουργούμε θεματικούς κλάδους, έναν για κάθε σειρά επιθεμάτων στα οποία εργαζόμαστε. +Η διαφορά είναι στο πως τους υποβάλλουμε στο έργο. +Αντί να αποσχίσουμε μία διχάλα (fork) από το έργο και να την ωθήσουμε στη δική μας εγγράψιμη έκδοση, μπορούμε να δημιουργήσουμε εκδόσεις e-mail για κάθε σειρά υποβολών και να τις αποστείλούμε με e-mail στη mailing list προγραμματιστών: [source,console] ------ +---- $ git checkout -b topicA -# (work) + ... work ... $ git commit -# (work) + ... work ... $ git commit ------ +---- -(((git commands, format-patch))) -Now you have two commits that you want to send to the mailing list. -You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list – it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. -The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly. +(((εντολές git, format-patch))) +Τώρα έχουμε δύο υποβολές που θέλουμε να στείλουμε στη mailing list. +Χρησιμοποιούμε την `git format-patch` για να δημιουργήσουμε τα μορφοποιημένα αρχεία mbox που μπορούμε να στείλουμε με e-mail στη λίστα -- μετατρέπει κάθε υποβολή σε μήνυμα e-mail με την πρώτη γραμμή του μηνύματος υποβολής ως θέμα και το υπόλοιπο μήνυμα συν το επίθεμα, που εισάγει η υποβολή, ως σώμα του e-mail. +Η ομορφιά σε αυτό είναι ότι η εφαρμογή ενός επιθέματος από ένα μήνυμα e-mail που έχει παραχθεί με `format-patch` διατηρεί όλες τις πληροφορίες υποβολής όπως πρέπει. [source,console] ------ +---- $ git format-patch -M origin/master 0001-add-limit-to-log-function.patch -0002-changed-log-output-to-30-from-25.patch ------ +0002-increase-log-output-to-30-from-25.patch +---- -The `format-patch` command prints out the names of the patch files it creates. -The `-M` switch tells Git to look for renames. -The files end up looking like this: +Η εντολή `format-patch` εκτυπώνει τα ονόματα των αρχείων-επιθεμάτων που δημιουργεί. +Ο διακόπτης `-M` λέει στο Git να αναζητήσει μετονομασίες. +Τα αρχεία καταλήγουν να μοιάζουν ως εξής: [source,console] ------ +---- $ cat 0001-add-limit-to-log-function.patch From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 From: Jessica Smith Date: Sun, 6 Apr 2008 10:17:23 -0700 -Subject: [PATCH 1/2] add limit to log function +Subject: [PATCH 1/2] Add limit to log function Limit log functionality to the first 20 @@ -682,82 +700,82 @@ index 76f47bc..f9815f1 100644 def ls_tree(treeish = 'master') -- 2.1.0 ------ +---- -You can also edit these patch files to add more information for the e-mail list that you don't want to show up in the commit message. -If you add text between the `---` line and the beginning of the patch (the `diff --git` line), then developers can read it; but applying the patch excludes it. +Μπορούμε επίσης να επεξεργαστούμε αυτά τα αρχεία/επιθέματα για να προσθέσουμε περισσότερες πληροφορίες για τη mailing list που δεν θέλουμε να εμφανίζονται στο μήνυμα υποβολής. +Αν προσθέσουμε κείμενο μεταξύ της γραμμής `---` και της αρχής του επιθέματος (τη γραμμή `diff --git`), τότε ναι μεν οι προγραμματιστές μπορούν να το διαβάσουν, αλλά το κείμενο αυτό αγνοείται κατά τη διαδικασία εφαρμογής του επιθέματος. -To e-mail this to a mailing list, you can either paste the file into your e-mail program or send it via a command-line program. -Pasting the text often causes formatting issues, especially with ``smarter'' clients that don't preserve newlines and other whitespace appropriately. -Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you. -We'll demonstrate how to send a patch via Gmail, which happens to be the e-mail agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code. +Για να στείλουμε το παραπάνω ως e-mail σε μια mailing list, μπορούμε είτε να επικολλήσουμε το αρχείο στο πρόγραμμα e-mail είτε να το στείλουμε μέσω ενός προγράμματος γραμμής εντολών. +Η επικόλληση του κειμένου προκαλεί συχνά ζητήματα μορφοποίησης, ειδικά με "`ευφυέστερους`" πελάτες που δεν διατηρούν κατάλληλα τους χαρακτήρες αλλαγής γραμμής και άλλους λευκούς χαρακτήρες. +Ευτυχώς, το Git παρέχει ένα εργαλείο που μας βοηθά να στέλνουμε κατάλληλα μορφοποιημένα επιθέματα μέσω IMAP, κάτι που ενδεχομένως μας διευκολύνει. +Θα δείξουμε πως να στείλουμε επιθέματα μέσω του Gmail, που τυγχάνει να είναι το πρόγραμμα e-mail που γνωρίζουμε καλύτερα· μπορούμε να διαβάσουμε λεπτομερείς οδηγίες για κάποια προγράμματα e-mail στο τέλος του προαναφερθέντος αρχείου `Documentation/SubmittingPatches` στον πηγαίο κώδικα του Git. -(((git commands, config)))(((email))) -First, you need to set up the imap section in your `~/.gitconfig` file. -You can set each value separately with a series of `git config` commands, or you can add them manually, but in the end your config file should look something like this: +(((εντολές git, config)))(((e-mail))) +Πρώτα, πρέπει να ρυθμίσουμε την ενότητα imap στο αρχείο `~/.gitconfig`. +Μπορούμε να ορίσουμε ξεχωριστά κάθε τιμή με μια ακολουθία εντολών `git config` ή μπορούμε να τις προσθέσουμε χειροκίνητα· όπως και να 'χει τελικά το αρχείο config θα πρέπει να φαίνεται σαν αυτό: [source,ini] ------ +---- [imap] folder = "[Gmail]/Drafts" host = imaps://imap.gmail.com user = user@gmail.com - pass = p4ssw0rd + pass = YX]8g76G_2^sFbd port = 993 sslverify = false ------ +---- -If your IMAP server doesn't use SSL, the last two lines probably aren't necessary, and the host value will be `imap://` instead of `imaps://`. -When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server: +Αν ο διακομιστής IMAP δεν χρησιμοποιεί SSL, οι δύο τελευταίες γραμμές πιθανώς δεν είναι απαραίτητες και η τιμή host θα είναι `imap://` αντί για `imaps://`. +Όταν έχει ρυθμιστεί το αρχείο `~/.gitconfig`, μπορούμε να εκτελέσουμε την εντολή `git imap-send` για να τοποθετήσουμε τη σειρά επιθεμάτων στον φάκελο Drafts του καθορισμένου διακομιστή IMAP: [source,console] ------ +---- $ cat *.patch |git imap-send Resolving imap.gmail.com... ok Connecting to [74.125.142.109]:993... ok Logging in... sending 2 messages 100% (2/2) done ------ +---- -At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you're sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. +Σε αυτό το σημείο, θα πρέπει να μπορούμε να μεταβούμε στον φάκελο Drafts, να αλλάξουμε το πεδίο To στη mailing list στην οποία θα αποστείλούμε την ενημερωμένη έκδοση κώδικα, ενδεχομένως να κοινοποιήσουμε με CC στον υπεύθυνο συντήρησης ή όποιον είναι υπεύθυνος για αυτή την ενότητα και να το αποστείλουμε. -You can also send the patches through an SMTP server. -As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file: +Μπορούμε επίσης να στείλουμε τα επιθέματα μέσω ενός διακομιστή SMTP. +Όπως και πριν, μπορούμε να ορίσουμε ξεχωριστά κάθε τιμή με μια σειρά εντολών `git config` ή μπορούμε να τις προσθέσουμε χειροκίνητα στην ενότητα sendemail στο αρχείο `~/.gitconfig`: [source,ini] ------ +---- [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = user@gmail.com smtpserverport = 587 ------ +---- -After this is done, you can use `git send-email` to send your patches: +Μετά από αυτό, μπορούμε να χρησιμοποιήσουμε το `git send-email` για να αποστείλουμε τα επιθέματά μας: [source,console] ------ +---- $ git send-email *.patch -0001-added-limit-to-log-function.patch -0002-changed-log-output-to-30-from-25.patch +0001-add-limit-to-log-function.patch +0002-increase-log-output-to-30-from-25.patch Who should the emails appear to be from? [Jessica Smith ] Emails will be sent from: Jessica Smith Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y ------ +---- -Then, Git spits out a bunch of log information looking something like this for each patch you're sending: +Στη συνέχεια, το Git εκτοξεύει κάμποσες πληροφορίες log που μοιάζουν με κάτι σαν το παρακάτω για κάθε επίθεμα που στέλνουμε: [source,text] ------ +---- (mbox) Adding cc: Jessica Smith from \line 'From: Jessica Smith ' OK. Log says: Sendmail: /usr/sbin/sendmail -i jessica@example.com From: Jessica Smith To: jessica@example.com -Subject: [PATCH 1/2] added limit to log function +Subject: [PATCH 1/2] Add limit to log function Date: Sat, 30 May 2009 13:29:15 -0700 Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com> X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty @@ -765,10 +783,20 @@ In-Reply-To: References: Result: OK ------ +---- + +[TIP] +==== +Για βοήθεια όσον αφορά στην παραμετροποίηση του συστήματός σας και του e-mail, περισσότερες συμβουλές και κόλπα και ένα χώρο πειραματισμού για δομικές αποστολής επιθεμάτων με e-mail, επισκεφτείτε το https://git-send-email.io[git-send-email.io^]. +==== + +==== Ανακεφαλαίωση -==== Summary +Σε αυτή την ενότητα καλύψαμε διάφορες ροές εργασίας και μιλήσαμε για τις διαφορές ανάμεσα στην εργασία ως μέλος κάποιας μικρής ομάδας σε έργα κλειστού κώδικα και την εργασία σε ένα μεγάλο δημόσιο έργο. +Γνωρίζουμε πως να ελέγχουμε σφάλματα διαστημάτων πριν να υποβάλουμε αλλαγές και να γράφουμε εξαιρετικά μηνύματα υποβολής. +Μάθαμε πως να μορφοποιούμε επιθέματα και να τα στέλνουμε με email σε μια mailing list προγραμματιστών. +Καλύψαμε επίσης τις συγχωνεύσεις στο πλαίσιο των διαφορετικών ροών εργασίας. +Πλέον είμαστε καλά προετοιμασμένοι να συνεργαστούμε με άλλους σε κάποιο έργο. -This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process. -Next, you'll see how to work the other side of the coin: maintaining a Git project. -You'll learn how to be a benevolent dictator or integration manager. +Στη συνέχεια, θα δούμε πως εργαζόμαστε στην άλλη όψη του νομίσματος: τη συντήρηση ενός έργου Git. +Θα μάθουμε πως να είμαστε καλοπροαίρετοι δικτάτορες ή διαχειριστές ενσωμάτωσης. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 7afff414b..ade8dfc8a 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,89 +1,102 @@ -=== Distributed Workflows - -(((workflows))) -Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. -In centralized systems, every developer is a node working more or less equally on a central hub. -In Git, however, every developer is potentially both a node and a hub – that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. -This opens a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility. -We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. - -==== Centralized Workflow - -(((workflows, centralized))) -In centralized systems, there is generally a single collaboration model–the centralized workflow. -One central hub, or repository, can accept code, and everyone synchronizes their work to it. -A number of developers are nodes – consumers of that hub – and synchronize to that one place. - -.Centralized workflow. -image::images/centralized_workflow.png[Centralized workflow.] - -This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. -The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes. -This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git. - -If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. -Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other. -Say John and Jessica both start working at the same time. -John finishes his change and pushes it to the server. -Then Jessica tries to push her changes, but the server rejects them. -She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges. -This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with. - -This is also not limited to small teams. -With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously. - -[[_integration_manager]] -==== Integration-Manager Workflow - -(((workflows, integration manager))) -Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's. -This scenario often includes a canonical repository that represents the ``official'' project. -To contribute to that project, you create your own public clone of the project and push your changes to it. -Then, you can send a request to the maintainer of the main project to pull in your changes. -The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. -The process works as follows (see <>): - -1. The project maintainer pushes to their public repository. -2. A contributor clones that repository and makes changes. -3. The contributor pushes to their own public copy. -4. The contributor sends the maintainer an e-mail asking them to pull changes. -5. The maintainer adds the contributor's repo as a remote and merges locally. -6. The maintainer pushes merged changes to the main repository. - -[[wfdiag_b]] -.Integration-manager workflow. -image::images/integration-manager.png[Integration-manager workflow.] - -(((forking))) -This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see. -One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. -Contributors don't have to wait for the project to incorporate their changes – each party can work at their own pace. - -==== Dictator and Lieutenants Workflow - -(((workflows, dictator and lieutenants))) -This is a variant of a multiple-repository workflow. -It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. -Various integration managers are in charge of certain parts of the repository; they're called lieutenants. -All the lieutenants have one integration manager known as the benevolent dictator. -The benevolent dictator's repository serves as the reference repository from which all the collaborators need to pull. -The process works like this (see <>): - -1. Regular developers work on their topic branch and rebase their work on top of `master`. - The `master` branch is that of the dictator. -2. Lieutenants merge the developers' topic branches into their `master` branch. -3. The dictator merges the lieutenants' `master` branches into the dictator's `master` branch. -4. The dictator pushes their `master` to the reference repository so the other developers can rebase on it. - -[[wfdiag_c]] -.Benevolent dictator workflow. -image::images/benevolent-dictator.png[Benevolent dictator workflow.] - -This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments. -It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. - -==== Workflows Summary - -These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. -Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows. -In the next section, you'll learn about a few common patterns for contributing to a project. +=== Κατανεμημένες ροές εργασίας + +(((ροές εργασίας))) +Σε αντίθεση με τα Συγκεντρωτικά Συστήματα Ελέγχου Έκδοσεων (CVCS), η κατανεμημένη φύση του Git μας επιτρέπει να είμαστε πολύ πιο ευέλικτοι όσον αφορά στη συνεργασία των προγραμματιστών στο πλαίσιο ενός έργου. +Στα συγκεντρωτικά συστήματα κάθε προγραμματιστής είναι ένας κόμβος που συνεργάζεται λίγο πολύ εξίσου με έναν κεντρικό κόμβο (hub). +Ωστόσο, στο Git, κάθε προγραμματιστής είναι δυνητικά τόσο κόμβος όσο και κεντρικό σημείο -- δηλαδή, κάθε προγραμματιστής μπορεί να συνεισφέρει κώδικα σε άλλα αποθετήρια και να διαχειρίζεται ένα δημόσιο αποθετήριο στο οποίο άλλοι μπορούν να βασίσουν τη δική τους εργασία και στο οποίο μπορούν να συνεισφέρουν. +Αυτό παρέχει ένα ευρύ φάσμα δυνατοτήτων όσον αφορά στις ροές εργασίας για το έργο μας ή/και την ομάδα μας· θα καλύψουμε μερικά συνηθισμένα μοντέλα που εκμεταλλεύονται αυτή την ευελιξία. +Θα αναλύσουμε τα δυνατά σημεία αλλά και τις ενδεχόμενες αδυναμίες κάθε μοντέλου· μπορούμε να επιλέξουμε μόνον ένα από αυτά ή να δανειστούμε λειτουργικότητες από περισσότερα και να τις ταιριάξουμε. + +==== Συγκεντρωτική ροή εργασίας + +(((ροές εργασίας, συγκεντρωτική))) +Στα συγκεντρωτικά συστήματα υπάρχει γενικά ένα ενιαίο μοντέλο συνεργασίας -- η συγκεντρωτική ροή εργασίας. +Μόνο ένας κεντρικός κόμβος ή _αποθετήριο_ μπορεί να δεχθεί κώδικα και όλοι συγχρονίζουν το έργασία τους με αυτόν. +Οι προγραμματιστές είναι περιφερειακοί κόμβοι -- καταναλωτές αυτού του κεντρικού κόμβου -- και συγχρονίζονται με αυτή την κεντρική τοποθεσία. + +.Συγκεντρωτική ροή εργασίας +image::images/centralized_workflow.png[Συγκεντρωτική ροή εργασίας] + +Αυτό σημαίνει ότι εάν δύο προγραμματιστές κλωνοποιήσουν από τον κεντρικό κόμβο και κάνουν αλλαγές και οι δύο, ο πρώτος προγραμματιστής που θα ωθήσει τις αλλαγές τους μπορεί να το κάνει χωρίς προβλήματα. +Ο δεύτερος προγραμματιστής πρέπει να συγχωνεύσει την εργασία του πρώτου πριν ωθήσει τις δικές του αλλαγές, ώστε να μην αντικαταστήσει τις αλλαγές του πρώτου προγραμματιστή. +Αυτό ισχύει και στο Git όπως και στο Subversion (((Subversion))) (ή οποιοδήποτε CVCS) και αυτό το μοντέλο λειτουργεί απολύτως καλά και στο Git. + +Εάν είμαστε ήδη εξοικειωμένοι με μια συγκεντρωτική κεντρική ροή εργασίας στην εταιρεία ή την ομάδα μας, μπορούμε εύκολα να συνεχίσουμε να χρησιμοποούμε αυτή τη ροή εργασίας με το Git. +Απλά δημιουργούμε ένα μοναδικό αποθετήριο και δίνουμε σε όλα τα μέλη της ομάδας μας δικαίωμα ώθησης (push access)· το Git δεν επιτρέπει στους χρήστες να επανεγγράψουν ο ένας τη δουλειά του άλλου. + +Ας υποθέσουμε ότι ο Τζον και η Τζέσικα αρχίζουν να εργάζονται την ίδια στιγμή. +Ο Τζον ολοκληρώνει την αλλαγή του και την ωθεί στον διακομιστή. +Στη συνέχεια η Τζέσικα προσπαθεί να ωθήσει τις αλλαγές της, αλλά ο διακομιστής τις απορρίπτει. +Της λέει ότι προσπαθεί να ωθήσει αλλαγές χωρίς ταχυπροώθηση και ότι δεν θα μπορέσει να το κάνει μέχρι να ανακτήσει τις αλλαγές που υπάρχουν ήδη και να τις συγχωνεύσει. +Αυτή η ροή εργασίας είναι ελκυστική για πολλούς, επειδή είναι ένα μοντέλο με το οποίο είναι εξοικειωμένοι και έχουν άνεση. + +Αυτό δεν περιορίζεται μόνο στις μικρές ομάδες. +Με το μοντέλο διακλάδωσης του Git είναι δυνατό για εκατοντάδες προγραμματιστές να δουλέψουν με επιτυχία σε ένα μόνο έργο μέσω δεκάδων κλάδων ταυτόχρονα. + +[[r_integration_manager]] +==== Ροή εργασίας με διαχειριστή ενσωμάτωσης (integration manager) + +(((ροές εργασίας, διαχειριστής ενσωμάτωσης))) +Επειδή το Git μας επιτρέπει να έχουμε πολλαπλά απομακρυσμένα αποθετήρια, είναι δυνατό να έχουμε μια ροή εργασίας στην οποία κάθε προγραμματιστής έχει δικαίωμα εγγραφής στο δικό του δημόσιο αποθετήριο και δικαίωμα ανάγνωσης σε όλα τα άλλα αποθετήρια. +Αυτό το σενάριο περιλαμβάνει συχνά ένα κανονικό (canonical) αποθετήριο που αντιπροσωπεύει το "`επίσημο`" έργο. +Για να συνεισφέρουμε σε αυτό το έργο, δημιουργούμε τον δικό μας δημόσιο κλώνο του έργου και ωθούμε τις αλλαγές μας σε αυτόν. +Στη συνέχεια, μπορούμε να στείλουμε ένα αίτημα στον διαχειριστή του κύριου έργου να τραβήξει τις αλλαγές μας. +Τότε ο διαχειριστής μπορεί να προσθέσει το αποθετήριό μας ως απομακρυσμένο, να δοκιμάσει τις αλλαγές μας τοπικά, να τις συγχωνεύσει στον κλάδο του και να τις ωθήσει στο αποθετήριό του. +Η διαδικασία λειτουργεί ως εξής (βλ. <>): + +1. Ο διαχειριστής του έργου ωθεί στο δημόσιο αποθετήριό του. +2. Ένας συνεργάτης κλωνοποιεί αυτό το αποθετήριο και κάνει αλλαγές. +3. Ο συνεργάτης ωθεί στο δικό του δημόσιο αντίγραφο. +4. Ο συνεργάτης αποστέλλει στον διαχειριστή ένα e-mail ζητώντας του να τραβήξει τις αλλαγές. +5. Ο διαχειριστής προσθέτει το αποθετήριο του συνεργάτη ως απομακρυσμένο και συγχωνεύει τοπικά. +6. Ο διαχειριστής ωθεί τις συγχωνευμένες αλλαγές στο κύριο αποθετήριο. + +[[rwfdiag_b]] +.Ροή εργασίας με διαχειριστη ενσωμάτωσης. +image::images/integration-manager.png[Ροή εργασίας με διαχειριστη ενσωμάτωσης] + +(((απόσχιση))) +Αυτή είναι μια πολύ συνηθισμένη ροή εργασίας με εργαλεία όπως το GitHub ή το GitLab, που βασίζονται σε κεντρικούς κόμβους και στην οποία είναι εύκολο να κλωνοποιήσουμε ένα έργο και να ωθήσουμε τις αλλαγές μας στον δικό μας κλώνο, όπου μπορούν να τις δουν όλοι. +Ένα από τα κύρια πλεονεκτήματα αυτής της προσέγγισης είναι ότι μπορούμε να συνεχίσουμε να εργαζόμαστε και ο διαχειριστής του κύριου αποθετηρίου μπορεί να τραβήξει τις αλλαγές μας όποτε θέλει. +Οι συνεργάτες δεν χρειάζεται να περιμένουν το έργο να ενσωματώσει τις αλλαγές τους -- ο καθένας μπορεί να εργαστεί με τον δικό του ρυθμό. + +==== Ροή εργασίας δικτάτορα και υπαρχηγών + +(((ροές εργασίας, δικτάτορας και υπαρχηγοί))) +Αυτή είναι μια παραλλαγή της ροής εργασίας πολλαπλών αποθετηρίων. +Χρησιμοποιείται γενικά από τεράστια έργα με εκατοντάδες συνεργάτες· ένα διάσημο παράδειγμα είναι ο πυρήνας του Linux. +Διάφοροι διαχειριστές ενσωμάτωσης είναι υπεύθυνοι για ορισμένα τμήματα του αποθετηρίου· αυτοί ονομάζονται _υπαρχηγοί_. +Όλοι οι υπαρχηγοί έχουν έναν διευθυντή ενσωμάτωσης γνωστό και ως καλόβουλο δικτάτορα. +Το αποθετήριο του καλόβουλου δικτάτορα χρησιμεύει ως αποθετήριο αναφοράς από το οποίο όλοι οι συνεργάτες τραβούν αρχεία. +Η διαδικασία λειτουργεί ως εξής (βλ. <>): + +1. Οι απλοί προγραμματιστές ασχολούνται με τον θεματικό κλάδο τους και επανατοποθετούν (rebase) την εργασία τους στον κλάδο `master`. + Ο κλάδος `master` ανήκει στο αποθετήριο αναφοράς στο οποίο ωθεί ο δικτάτορας. +2. Οι υπαρχηγοί συγχωνεύουν τους κλάδους των προγραμματιστών ο καθένας στον δικό τους κλάδο `master`. +3. Ο δικτάτορας συγχωνεύει τους κλάδους `master` των υπαρχηγών στον κλάδο `master` του δικτάτορα. +4. Ο δικτάτορας ωθεί τον δικό του κλάδο `master` στο αποθετήριο αναφοράς, έτσι ώστε οι άλλοι προγραμματιστές να μπορέσουν να επανατοποθετηθούν σε αυτόν. + +[[rwfdiag_c]] +.Ροή εργασίας με καλόβουλο δικτάτορα. +image::images/benevolent-dictator.png[Ροή εργασίας με καλόβουλο δικτάτορα] + +Αυτό το είδος ροής εργασίας δεν είναι συνηθισμένο, αλλά μπορεί να είναι χρήσιμο σε πολύ μεγάλα έργα ή σε αυστηρά ιεραρχικά περιβάλλοντα. +Επιτρέπει στον επικεφαλής του έργου (δικτάτορα) να αναθέσει μεγάλο μέρος της εργασίας και να συλλέξει μεγάλα υποσύνολα κώδικα σε διάφορες χρονικές στιγμές πριν τα ενσωματώσει. + +[[_patterns_for_managing_source_code_branches]] +==== Μοτίβα Διαχείριση Πηγαίου Κώδικα σε Κλάδους + +[NOTE] +==== +Ο Martin Fowler έχει κάνει έναν οδηγό "Μοτίβα Διαχείριση Πηγαίου Κώδικα σε Κλάδους" ("Patterns for Managing Source Code Branches"). +Αυτός ο οδηγός καλύπτει όλες τις κοινές ροές εργασίας του Git, και εξηγεί πως/πότε να τα χρησιμοποιούμε. +Υπάρχει κιόλας ένας τομέας σύγκρισης υψηλής και χαμηλής συχνότητας ενσωμάτωσης. + +https://martinfowler.com/articles/branching-patterns.html[^] +==== + +==== Περίληψη ροών εργασίας + +Αυτές είναι μερικές συνήθεις ροές εργασίας που καθίστανται δυνατές με ένα κατανεμημένο σύστημα όπως το Git, αλλά βλέπετε ότι είναι δυνατές πολλές παραλλαγές οι οποίες ενδεχομένως ταιριάζουν περισσότερο στη δική μας ροή εργασίας. +Τώρα που μπορείτε (όπως ελπίζουμε) να προσδιορίσετε ποιος συνδυασμός ροών εργασίας σας βολεύει, θα καλύψουμε μερικά πιο συγκεκριμένα παραδείγματα για το πώς να επιτύχετε τους κύριους ρόλους που συνθέτουν τις διαφορετικές ροές. +Στην επόμενη ενότητα, θα μάθουμε μερικά κοινά μοτίβα συνεισφοράς σε ένα έργο. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 9c106d7ab..0fd2007d9 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -1,110 +1,110 @@ -=== Maintaining a Project +=== Συντήρηση ενός έργου (((maintaining a project))) -In addition to knowing how to effectively contribute to a project, you'll likely need to know how to maintain one. -This can consist of accepting and applying patches generated via `format-patch` and e-mailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project. -Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run. +Εκτός από το να γνωρίζουμε πως να συμβάλλουμε αποτελεσματικά σε ένα έργο, πιθανότατα θα χρειαστεί να ξέρουμε πως να διαχειριζόμαστε ένα αποθετήριο. +Αυτό μπορεί να συνίσταται στην αποδοχή και εφαρμογή των επιθεμάτων που δημιουργούνται με το `format-patch` και στέλνονται με e-mail σε εμάς ή στην ενσωμάτωση αλλαγών σε απομακρυσμένους κλάδους για αποθετήρια που έχουμε προσθέσει ως απομακρυσμένα στο έργο μας. +Είτε διαχειριζόμαστε ένα τυπικό αποθετήριο είτε θέλουμε να βοηθήσουμε επαληθεύοντας ή εγκρίνοντας επιθέματα, πρέπει να ξέρουμε πως να δέχομαστε την εργασία με τρόπο που είναι κατά το δυνατό ξεκάθαρος στους άλλους συνεργάτες και βιώσιμος από εμάς μακροπρόθεσμα. -==== Working in Topic Branches +==== Εργασία σε θεματικούς κλάδους -(((branches, topic))) -When you're thinking of integrating new work, it's generally a good idea to try it out in a topic branch – a temporary branch specifically made to try out that new work. -This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it. -If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. -The maintainer of the Git project tends to namespace these branches as well – such as `sc/ruby_client`, where `sc` is short for the person who contributed the work. -As you'll remember, you can create the branch based off your master branch like this: +(((κλάδοι, θεματικοί))) +Όταν σκεφτόμαστε να ενσωματώσουμε νέα δουλειά, είναι γενικά καλή ιδέα να το δοκιμάζουμε σε έναν _θεματικό κλάδο_ -- έναν προσωρινό κλάδο ειδικά σχεδιασμένο για να δοκιμάσουμε αυτή την εργασία. +Με αυτόν τον τρόπο, είναι εύκολο να τροποποιήσουμε ένα επίθεμα ξεχωριστά και να το παρατήσουμε αν δεν λειτουργεί μέχρι να έχουμε χρόνο να ξανασχολήθουμε μαζί του. +Αν δημιουργήσουμε ένα απλό όνομα κλάδου με βάση το θέμα της εργασίας που πρόκειται να δοκιμάσουμε, όπως `ruby_client` ή κάτι παρόμοια περιγραφικό, μπορούμε εύκολα να το θυμόμαστε, ακόμα κι αν χρειαστεί να το εγκαταλείψουμε για αρκετό καιρό και να επιστρέψουμε σε αυτό αργότερα. +Οι διαχειριστές έργων Git συνηθίζουν επίσης να οργανώνουν αυτούς τους κλάδους σε ονοματοχώρους (namespaces) -- όπως `sc/ruby_client`, όπου το `sc` είναι συντομογραφία για τον προγραμματιστή που συνεισέφερε την εργασία. +Όπως θυμόμαστε, μπορούμε να δημιουργήσουμε τον κλάδο που να βασίζεται στο `master` κλάδο μας ως εξής: [source,console] ------ +---- $ git branch sc/ruby_client master ------ +---- -Or, if you want to also switch to it immediately, you can use the `checkout -b` option: +Εναλλακτικά, αν θέλουμε να μεταβούμε σε αυτόν αμέσως, μπορούμε να χρησιμοποιήσουμε την επιλογή `-b`: [source,console] ------ +---- $ git checkout -b sc/ruby_client master ------ +---- -Now you're ready to add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches. +Τώρα είμαστε έτοιμοι να προσθέσουμε τη συνεισφορά μας σε αυτόν τον θεματικό κλάδο και να προσδιορίσουμε αν θέλουμε να τον συγχωνεύσουμε στους μακροβιότερους κλάδους μας. -[[_patches_from_email]] -==== Applying Patches from E-mail +[[r_patches_from_email]] +==== Εφαρμογή επιθεμάτων από e-mail -(((email, applying patches from))) -If you receive a patch over e-mail that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. -There are two ways to apply an e-mailed patch: with `git apply` or with `git am`. +(((e-mail, επιλογή επιθεμάτων από))) +Αν λάβουμε επίθεμα μέσω e-mail και πρέπει να το ενσωματώσουμε στο έργο μας, πρέπει να το εφαρμόσουμε στον θεματικό κλάδο για να το αξιολογήσουμε. +Υπάρχουν δύο τρόποι για να εφαρμόσουμε ένα επίθεμα που λάβαμε με e-mail: με `git apply` ή με `git am`. -===== Applying a Patch with apply +===== Εφαρμογή επιθέματος με `git apply` -(((git commands, apply))) -If you received the patch from someone who generated it with the `git diff` or a Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. -Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: +(((εντολές git, apply))) +Εάν λάβαμε το επίθεμα από κάποιον που το δημιούργησε με την εντολή `git diff` ή `diff` του Unix (κάτι που δεν συνιστάται, όπως δούμε στην επόμενη ενότητα), μπορούμε να το εφαρμόσουμε με την εντολή `git apply`. +Αν υποθέσουμε ότι έχουμε αποθηκεύσει το επίθεμα στον φάκελο `/tmp/patch-ruby-client.patch`, μπορούμε να το εφαρμόσουμε ως εξής: [source,console] ------ +---- $ git apply /tmp/patch-ruby-client.patch ------ +---- -This modifies the files in your working directory. -It's almost identical to running a `patch -p1` command to apply the patch, although it's more paranoid and accepts fewer fuzzy matches than patch. -It also handles file adds, deletes, and renames if they're described in the `git diff` format, which `patch` won't do. -Finally, `git apply` is an ``apply all or abort all'' model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. -`git apply` is overall much more conservative than `patch`. -It won't create a commit for you – after running it, you must stage and commit the changes introduced manually. +Αυτή η εντολή τροποποιεί τα αρχεία στον κατάλογο εργασίας μας. +Είναι σχεδόν πανομοιότυπη με την εκτέλεση της εντολής `patch -p1` για την εφαρμογή του επιθέματος, αν και είναι πιο παρανοϊκή και δέχεται λιγότερες ασαφείς αντιστοιχίσεις από ότι η patch. +Επίσης, διαχειρίζεται προσθήκες, διαγραφές και μετονομασίες αρχείων εφόσον περιγράφονται στη μορφή `git diff`, κάτι που δεν κάνει η `patch`. +Τέλος, η `git apply` είναι ένα μοντέλο "`όλα ή τίποτα`" ("`apply all or abort all`") όπου είτε όλες οι αλλαγές εφαρμόζονται είτε καμία, ενώ η `patch` μπορεί να εφαρμόσει μερικώς επιθέματα αφήνοντας τον κατάλογο εργασίας μας σε μία περίεργη κατάσταση. +Η `git apply` είναι γενικά πολύ πιο συντηρητική από την `patch`. +Δεν θα δημιουργήσει αυτόματα κάποια υποβολή για μας -- μετά την εκτέλεσή της, θα πρέπει να βάλουμε τις αλλαγές στο στάδιο καταχώρησης και να τις υποβάλουμε οι ίδιοι χειροκίνητα. -You can also use git apply to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch: +Μπορούμε επίσης να χρησιμοποιήσουμε την `git apply` για να διαπιστώσουμε αν ένα επίθεμα εφαρμόζεται καθαρά πριν δοκιμάσουμε την εφαρμογή του -- μπορούμε να εκτελέσουμε το `git apply --check` με το επίθεμα: [source,console] ------ -$ git apply --check 0001-seeing-if-this-helps-the-gem.patch +---- +$ git apply --check 0001-see-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply ------ +---- -If there is no output, then the patch should apply cleanly. -This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want. +Εάν δεν τυπωθεί κάτι, τότε το επίθεμα θα πρέπει να εφαρμοστεί χωρίς προβλήματα. +Αυτή η εντολή επίσης τερματίζει με μη-μηδενική κατάσταση αν ο έλεγχος αποτύχει, οπότε μπορούμε να τη χρησιμοποιήσουμε σε scripts, αν χρειαστεί. -[[_git_am]] -===== Applying a Patch with `am` +[[r_git_am]] +===== Εφαρμογή επιθέματος με την `am` -(((git commands, am))) -If the contributor is a Git user and was good enough to use the `format-patch` command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. -If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you. -You should only have to use `git apply` for legacy patches and things like that. +(((εντολές git, am))) +Εάν ο συνεισφέρων είναι χρήστης του Git και ήταν αρκετά καλός ώστε να χρησιμοποιήσει την εντολή `format-patch` για να δημιουργήσει το επίθεμα, τότε η εργασία μας είναι ευκολότερη διότι το επίθεμα περιέχει πληροφορίες για τον συγγραφέα και ένα μήνυμα υποβολής για εμάς. +Αν είναι δυνατό, καλό είναι να ενθαρρύνουμε τους συνεργάτες μας να χρησιμοποιούν την `format-patch` αντί για την `diff` για να δημιουργούν επιθέματα για μας. +Θα πρέπει να χρησιμοποιούμε την `git apply` μόνον για επιθέματα παλιού τύπου (legacy). -To apply a patch generated by `format-patch`, you use `git am`. -Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more e-mail messages in one text file. -It looks something like this: +Για να εφαρμόσουμε ένα επίθεμα που δημιουργείται με την `format-patch`, χρησιμοποιούμε την `git am` (η εντολή ονομάζεται `am` γιατί χρησιμοποιείται ως "εφαρμογή μιας σειράς επιθεμάτων από το mailbox"). +Από τεχνικής άποψης, η `git am` έχει φτιαχτεί για να διαβάζει ένα αρχείο mbox, που είναι μία απλή μορφή αρχείου κειμένου για την αποθήκευση ενός ή περισσοτέρων μηνυμάτων e-mail σε ένα αρχείο κειμένου. +Μοιάζει με κάτι τέτοιο: [source,console] ------ +---- From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 From: Jessica Smith Date: Sun, 6 Apr 2008 10:17:23 -0700 -Subject: [PATCH 1/2] add limit to log function +Subject: [PATCH 1/2] Add limit to log function Limit log functionality to the first 20 ------ +---- -This is the beginning of the output of the format-patch command that you saw in the previous section. -This is also a valid mbox e-mail format. -If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time. +Αυτή είναι η αρχή της εξόδου της εντολής `git format-patch` που είδαμε στην προηγούμενη ενότητα· επίσης είναι μια έγκυρη μορφή ηλεκτρονικού μηνύματος mbox. +Εάν κάποιος μας έχει στείλει ηλεκτρονικά το επίθεμα χρησιμοποιώντας την `git send-email` και το κατεβάσουμε σε μορφή mbox, τότε μπορούμε να κατευθυνούμε την `git am` στο αρχείο mbox και αυτό θα αρχίσει να εφαρμόζει όλα τα επιθέματα που βλέπει. +Εάν τρέχουμε ένα πρόγραμμα-πελάτη e-mail που μπορεί να αποθηκεύσει πολλά μηνύματα e-mail σε μορφή mbox, μπορούμε να αποθηκεύσουμε ολόκληρες σειρές επιθεμάτων σε ένα αρχείο και στη συνέχεια να χρησιμοποιήσουμε την `git am` για να εφαρμόσουμε το καθένα ξεχωριστά. -However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: +Ωστόσο, αν κάποιος χρήστης ανέβασε ένα επίθεμα που δημιουργήθηκε με την `git format-patch` σε ένα σύστημα εισιτηρίων ή κάτι παρόμοιο, μπορούμε να αποθηκεύσουμε το αρχείο τοπικά και να περάσουμε το αρχείο που αποθηκεύσαμε στην `git am` για να το εφαρμόσουμε: [source,console] ------ +---- $ git am 0001-limit-log-function.patch -Applying: add limit to log function ------ +Applying: Add limit to log function +---- -You can see that it applied cleanly and automatically created the new commit for you. -The author information is taken from the e-mail's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the e-mail. -For example, if this patch was applied from the mbox example above, the commit generated would look something like this: +Μπορούμε να δούμε ότι το επίθεμα εφαρμόστηκε καθαρά και η νέα υποβολή δημιουργήθηκε για μας αυτόματα. +Οι πληροφορίες του συγγραφέα λαμβάνονται από τις κεφαλίδες `From` και `Date` του e-mail και το μήνυμα της υποβολής λαμβάνεται από το `Subject` και το σώμα (πριν από το επίθεμα) του μηνύματος. +Για παράδειγμα, εάν αυτή η ενημερωμένη έκδοση κώδικα εφαρμόστηκε από το παραπάνω παράδειγμα mbox, η υποβολή που θα δημιουργούνταν θα φαινόταν κάπως έτσι: ------ +[source,console] +---- $ git log --pretty=fuller -1 commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 Author: Jessica Smith @@ -112,422 +112,433 @@ AuthorDate: Sun Apr 6 10:17:23 2008 -0700 Commit: Scott Chacon CommitDate: Thu Apr 9 09:19:06 2009 -0700 - add limit to log function + Add limit to log function Limit log functionality to the first 20 ------ +---- -The `Commit` information indicates the person who applied the patch and the time it was applied. -The `Author` information is the individual who originally created the patch and when it was originally created. +Οι πληροφορίες στο πεδίο `Commit` υποδεικνύουν το άτομο που εφάρμοσε το επίθεμα και την ώρα που έγινε η εφαρμογή αυτή. +Οι πληροφορίες στο πεδίο `Author` υποδεικνύουν το άτομο που αρχικά δημιούργησε το επίθεμα και πότε δημιουργήθηκε για πρώτη φορά. -But it's possible that the patch won't apply cleanly. -Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven't applied yet. -In that case, the `git am` process will fail and ask you what you want to do: +Αλλά είναι πιθανό ότι το επίθεμα δεν θα εφαρμοστεί καθαρά. +Ίσως ο κύριος κλάδος μας να έχει αποκλίσει πολύ από τον κλάδο από τον οποίο είχε φτιαχτεί αυτό το επίθεμα ή το επίθεμα εξαρτάται από ένα άλλο επίθεμα που δεν έχουμε εφαρμόσει ακόμα. +Σε αυτή την περίπτωση, η διαδικασία με την `git am` θα αποτύχει και θα μας ρωτήσει τι θέλουμε να κάνουμε: [source,console] ------ -$ git am 0001-seeing-if-this-helps-the-gem.patch -Applying: seeing if this helps the gem +---- +$ git am 0001-see-if-this-helps-the-gem.patch +Applying: See if this helps the gem error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply Patch failed at 0001. When you have resolved this problem run "git am --resolved". 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". ------ +---- -This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. -You solve this issue much the same way – edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch: +Αυτή η εντολή τοποθετεί σημάνσεις σύγκρουσης σε όλα τα αρχεία με τα οποία αντιμετωπίζει προβλήματα, όπως μια σύγκρουση συγχώνευσης ή αλλαγής βάσης. +Μπορούμε να επιλύσουμε αυτό το πρόβλημα λίγο-πολύ με τον ίδιο τρόπο -- επεξεργαζόμαστε το αρχείο για να επιλύσουμε τη σύγκρουση, τοποθετούμε το νέο αρχείο στο στάδιο καταχώρησης και στη συνέχεια εκτελούμε την εντολή `git am --resolved` για να συνεχίσουμε στο επόμενο επίθεμα: [source,console] ------ +---- $ (fix the file) $ git add ticgit.gemspec $ git am --resolved -Applying: seeing if this helps the gem ------ +Applying: See if this helps the gem +---- -If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge. -This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository. -If you do have that commit – if the patch was based on a public commit – then the `-3` option is generally much smarter about applying a conflicting patch: +Εάν θέλουμε το Git να δοκιμάσει να επιλύσει τη σύγκρουση με λίγο πιο έξυπνο τρόπο, μπορούμε να περάσουμε την επιλογή `-3` στην `git am`, η οποία θα κάνει το Git να επιχειρήσει μια τριμερή συγχώνευση. +Αυτή η επιλογή δεν είναι ενεργοποιημένη εξ ορισμού, επειδή δεν λειτουργεί εφόσον η υποβολή στην οποία λέει το επίθεμα ότι βασίζεται δεν βρίσκεται στο αποθετήριό μας. +Αν έχουμε αυτή την υποβολή -- για παράδειγμα αν το επίθεμα βασίστηκε σε δημόσια υποβολή -- τότε η επιλογή `-3` είναι γενικά πολύ πιο έξυπνη όσον αφορά στην εφαρμογή ενός συγκρουόμενου επιθέματος λογισμικού: [source,console] ------ -$ git am -3 0001-seeing-if-this-helps-the-gem.patch -Applying: seeing if this helps the gem +---- +$ git am -3 0001-see-if-this-helps-the-gem.patch +Applying: See if this helps the gem error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... No changes -- Patch already applied. ------ +---- -In this case, this patch had already been applied. -Without the `-3` option, it looks like a conflict. +Σε αυτή την περίπτωση, χωρίς την επιλογή `-3`, το επίθεμα θα θεωρούνταν σύγκρουση. +Αφού χρησιμοποιήθηκε η επιλογή `-3`, το επίθεμα εφαρμόστηκε καθαρά. -If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it: +Αν εφαρμόζουμε μια σειρά από επιθέματα από ένα mbox, μπορούμε επίσης να εκτελέσουμε την εντολή `am` σε διαδραστική (interactive) λειτουργία, η οποία σταματά σε κάθε επίθεμα που βρίσκει και ρωτά αν θέλουμε να το εφαρμόσουμε: [source,console] ------ +---- $ git am -3 -i mbox Commit Body is: -------------------------- -seeing if this helps the gem +See if this helps the gem -------------------------- Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ------ +---- -This is nice if you have a number of patches saved, because you can view the patch first if you don't remember what it is, or not apply the patch if you've already done so. +Αυτό είναι βολικό όταν έχουμε αποθηκεύσει μερικά επιθέματα, επειδή μπορούμε να τα δούμε πρώτα ή να μην τα εφαρμόσουμε εάν το έχουμε κάνει ήδη. -When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch. +Όταν όλα τα επιθέματα για το θέμα μας εφαρμοστούν και υποβληθούν στον κλάδο μας, μπορούμε να επιλέξουμε εάν και πως θα τα ενσωματώσουμε σε έναν μακροβιότερο κλάδο. -[[_checking_out_remotes]] -==== Checking Out Remote Branches +[[r_checking_out_remotes]] +==== Checkοut απομακρυσμένων κλάδων (((branches, remote))) -If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally. +Εάν η συνεισφορά προήλθε από έναν χρήστη Git που δημιούργησε το δικό του αποθετήριο, ώθησε μερικές αλλαγές σε αυτό και έπειτα μας έστειλε τη διεύθυνση URL του αποθετηρίου και το όνομα του απομακρυσμένου κλάδου στον οποίο έγιναν οι αλλαγές, μπορούμε να το προσθέσουμε ως απομακρυσμένο και να κάνουμε συγχωνεύσεις τοπικά. -For instance, if Jessica sends you an e-mail saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally: +Για παράδειγμα, εάν η Τζέσικα μας στείλει ένα e-mail που λέει ότι έχει μία εξαιρετική νέα λειτουργικότητα στον κλάδο `ruby-client` του αποθετηρίου της, μπορούμε να τη δοκιμάσουμε προσθέτοντας το αποθετήριο ως απομακρυσμένο και κάνοντας check out τον κλάδο τοπικά: [source,console] ------ -$ git remote add jessica git://github.com/jessica/myproject.git +---- +$ git remote add jessica https://github.com/jessica/myproject.git $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client ------ +---- -If she e-mails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup. +Εάν η Τζέσικα ξαναστείλει e-mail αργότερα με κάποιον άλλο κλάδο που περιέχει άλλο ένα εξαιρετικό χαρακτηριστικό, μπορούμε να κάνουμε απευθείας `fetch` και `checkout` τοπικά διότι έχουμε ήδη το απομακρυσμένο αποθετήριο εγκατεστημένο. -This is most useful if you're working with a person consistently. -If someone only has a single patch to contribute once in a while, then accepting it over e-mail may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. -You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. -However, scripts and hosted services may make this easier – it depends largely on how you develop and how your contributors develop. +Αυτό είναι ιδιαίτερα χρήσιμο αν συνεργαζόμαστε με ένα άτομο συχνά. +Εάν κάποιος συνεισφέρει ένα επίθεμα μόνο μία στις τόσες, τότε η αποδοχή του μέσω e-mail είναι ενδεχομένως λιγότερο χρονοβόρα από το να πρέπει όλοι να τρέχουν το δικό τους διακομιστή και να προσθαφαιρούν απομακρυσμένους διακομιστές συνεχώς για να πάρουν μιά χούφτα επιθέματα. +Επίσης, είναι μάλλον απίθανο να θέλουμε να έχουμε εκατοντάδες απομακρυσμένους διακομιστές, έναν για καθένα που συνεισφέρει καναδυό επιθέματα μια στο τόσο. +Ωστόσο, τα scripts και φιλοξενούμενες υπηρεσίες μπορεί να μας διευκολύνουν -- αυτό εξαρτάται σε μεγάλο βαθμό από τον τρόπο με τον οποίο εμείς και οι συνεισφέροντες αναπτύσσουμε τον κώδικά μας. -The other advantage of this approach is that you get the history of the commits as well. -Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access. +Το άλλο πλεονέκτημα αυτής της προσέγγισης είναι ότι έχουμε και το ιστορικό των υποβολών. +Παρόλο που ίσως έχουμε ζητήματα συγχώνευσης, γνωρίζουμε πού βρίσκεται η σχετική εργασία τους στο ιστορικό μας· μια κατάλληλη τριμερής συγχώνευση είναι η προτιμότερη επιλογή από τη χρήση της επιλογής `-3` με την ελπίδα ότι το επίθεμα δημιουργήθηκε από μια δημόσια υποβολή στην οποία έχουμε πρόσβαση. -If you aren't working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. -This does a one-time pull and doesn't save the URL as a remote reference: +Εάν δεν συνεργαζόμαστε συχνά με ένα άτομο, αλλά εξακολουθούμε να θέλουμε να ελκύσουμε (pull) από αυτόν με αυτό τον τρόπο, μπορούμε να δώσουμε τη διεύθυνση URL του απομακρυσμένου αποθετηρίου στην εντολή `git pull`. +Αυτό κάνει ένα και μοναδικό ελκυσμό και δεν αποθηκεύει τη διεύθυνση URL ως απομακρυσμένη αναφορά: [source,console] ------ +---- $ git pull https://github.com/onetimeguy/project From https://github.com/onetimeguy/project * branch HEAD -> FETCH_HEAD -Merge made by recursive. ------ +Merge made by the 'recursive' strategy. +---- -[[_what_is_introduced]] -==== Determining What Is Introduced +[[r_what_is_introduced]] +==== Προσδιορισμός του τι έχει εισαχθεί (((branches, diffing))) -Now you have a topic branch that contains contributed work. -At this point, you can determine what you'd like to do with it. -This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch. +Τώρα έχουμε έναν θεματικό κλάδο που περιέχει συνεισφορές. +Σε αυτό το σημείο, μπορούμε να αποφασίσουμε τι θα θέλαμε να κάνουμε με αυτόν. +Αυτή η ενότητα επανεξετάζει μερικές εντολές, ώστε να μπορούμε να δούμε πως μπορούμε να τις χρησιμοποιήσουμε για να ελέγξουμε τι ακριβώς θα εισάγουμε αν συγχωνεύσουμε αυτόν τον θεματικό κλάδο στον κύριο κλάδο μας. -It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch. -You can exclude commits in the master branch by adding the `--not` option before the branch name. -This does the same thing as the `master..contrib` format that we used earlier. -For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this: +Συχνά είναι χρήσιμο να πάρουμε μια ανασκόπηση όλων των υποβολών που βρίσκονται σε αυτόν τον κλάδο, αλλά δεν βρίσκονται στον `master` κλάδο μας. +Μπορούμε να αποκλείσουμε υποβολές στον `master` μας προσθέτοντας την επιλογή `--not` πριν από το όνομα του κλάδου. +Αυτό είναι το ίδιο με τη μορφή `master..contrib` που χρησιμοποιήσαμε νωρίτερα. +Για παράδειγμα, εάν ο συνεισφέρων μας στείλει δύο επιθέματα και δημιουργήσουμε έναν κλάδο με το όνομα `contrib` και εφαρμόσουμε αυτά τα επιθέματα εκεί, μπορούμε να τρέξουμε το εξής: [source,console] ------ +---- $ git log contrib --not master commit 5b6235bd297351589efc4d73316f0a68d484f118 Author: Scott Chacon Date: Fri Oct 24 09:53:59 2008 -0700 - seeing if this helps the gem + See if this helps the gem commit 7482e0d16d04bea79d0dba8988cc78df655f16a0 Author: Scott Chacon Date: Mon Oct 22 19:38:36 2008 -0700 - updated the gemspec to hopefully work better ------ + Update gemspec to hopefully work better +---- -To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit. +Για να δούμε τι αλλαγές εισάγει κάθε υποβολή, θυμόμαστε ότι μπορούμε να περάσουμε την επιλογή `-p` στο `git log` και θα προσαρτήσει το αποτέλεσμα της diff που εισήχθη σε κάθε υποβολή. -To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. -You may think to run this: +Για να δούμε το πλήρες diff που θα παίρναμε αν συγχωνεύαμε αυτόν τον θεματικό κλάδο με ένα άλλο κλάδο, ίσως χρειαστεί να χρησιμοποιήσουμε ένα περίεργο τέχνασμα για να έχουμε τα σωστά αποτελέσματα. +Ίσως σκεφτούμε να εκτελέσουμε το εξής: [source,console] ------ +---- $ git diff master ------ +---- -This command gives you a diff, but it may be misleading. -If your `master` branch has moved forward since you created the topic branch from it, then you'll get seemingly strange results. -This happens because Git directly compares the snapshots of the last commit of the topic branch you're on and the snapshot of the last commit on the `master` branch. -For example, if you've added a line in a file on the `master` branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line. +Αυτή η εντολή μας δίνει ένα diff, αλλά μπορεί να είναι παραπλανητικό. +Εάν ο κλάδος μας `master` έχει προχωρήσει από τότε που δημιουργήσαμε αυτόν τον θεματικό κλάδο, τότε θα πάρουμε φαινομενικά παράξενα αποτελέσματα. +Αυτό συμβαίνει επειδή το Git συγκρίνει άμεσα το στιγμιότυπο της τελευταίας υποβολής του θεματικού κλάδου στον οποίο βρισκόμαστε με το στιγμιότυπο της τελευταίας υποβολής στον κλάδο `master`. +Για παράδειγμα, αν έχουμε προσθέσει μια γραμμή σε ένα αρχείο στον κλάδο `master`, μια άμεση σύγκριση των στιγμιότυπων θα μοιάζει σαν ο θεματικός κλάδος να πρόκειται να καταργήσει αυτή τη γραμμή. -If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch. +Αν ο κλάδος `master` είναι άμεσος πρόγονος του θεματικού κλάδου μας, αυτό δεν είναι πρόβλημα· αλλά αν τα δύο ιστορικά έχουν αποκλίσει, η διαφορά θα μοιάζει σαν να προσθέτουμε όλα τα νέα στοιχεία στον θεματικό κλάδο και να καταργούμε ό,τι υπάρχει μόνον στον κλάδο `master`. -What you really want to see are the changes added to the topic branch – the work you'll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch. +Αυτό που πραγματικά θέλουμε να δούμε είναι οι αλλαγές που έχουν προστεθεί στον θεματικό κλάδο -- την εργασία που θα εισάγουμε αν συγχωνεύσουμε αυτόν τον κλάδο με τον `master` κλάδο. +Αυτό μπορούμε να το κάνουμε βάζοντας το Git να συγκρίνει την τελευταία υποβολή στον θεματικό κλάδο μας με τον πρώτο κοινό πρόγονο που έχει με τον `master` κλάδο. -Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it: +Από τεχνικής άποψης, αυτό μπορούμε να το καταφέρουμε αν εντοπίσουμε τον κοινό πρόγονο και στη συνέχεια τρέξουμε τη διαφορά diff σε αυτό: [source,console] ------ +---- $ git merge-base contrib master 36c7dba2c95e6bbb78dfa822519ecfec6e1ca649 $ git diff 36c7db ------ +---- + +ή πιο συνεκτικά: + +[source,console] +---- +$ git diff $(git merge-base contrib master) +---- -However, that isn't convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. -In the context of the `diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: +Ωστόσο, κανένα από τα δύο δεν είναι ιδιαίτερα βολικό, γι' αυτό το Git παρέχει μια άλλη συντόμευση για να κάνει το ίδιο πράγμα: τη σύνταξη με τις τρεις τελείες. +Στο πλαίσιο της εντολής `git diff`, μπορούμε να βάλουμε τρεις τελείες μετά από ένα άλλο κλάδο για να κάνουμε ένα `diff` μεταξύ της τελευταίας υποβολής του κλάδου που βρισκόμαστε και του κοινού προγόνου της με έναν άλλο κλάδο: [source,console] ------ +---- $ git diff master...contrib ------ +---- + +Αυτή η εντολή μας δείχνει μόνο τη δουλειά που έχει εισάγει ο τρέχων θεματικός κλάδος μας από τον κοινό πρόγονο του με τον `master`. +Αυτή είναι μια πολύ χρήσιμη σύνταξη που πρέπει να θυμόμαστε. -This command shows you only the work your current topic branch has introduced since its common ancestor with master. -That is a very useful syntax to remember. +==== Ενσωμάτωση συνεισφερθείσας εργασίας -==== Integrating Contributed Work +(((ενσωμάτωση εργασίας))) +Όταν όλη δουλειά στον θεματικό κλάδο μας είναι έτοιμη να ενσωματωθεί σε ένα πιο κεντρικό κλάδο, το ερώτημα που ανακύπτει είναι πως να το κάνουμε. +Επιπλέον, ποια ροή εργασίας θέλουμε να χρησιμοποιήσουμε για να συντηρήσουμε το έργο μας; +Έχουμε αρκετές επιλογές και στη συνέχεια θα καλύψουμε μερικές από αυτές. -(((integrating work))) -When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. -Furthermore, what overall workflow do you want to use to maintain your project? -You have a number of choices, so we'll cover a few of them. +===== Συγχώνευση ροών εργασίας -===== Merging Workflows +(((ροές εργασίας, συγχώνευση))) +Μια απλή ροή εργασίας είναι αυτή στην οποία συγχωνεύουμε την εργασία μας στον κλάδο `master`. +Σε αυτό το σενάριο, έχουμε ένα κύριο κλάδο που περιέχει κυρίως ευσταθή κώδικα. +Όταν εργαζόμαστε σε έναν θεματικό κλάδο που έχουμε φτιάξει ή τον οποίο έχει συνεισφέρει κάποιος και έχουμε επαληθεύσει, τον συγχωνεύουμε στον master μας, διαγράφουμε τον θεματικό κλάδο και στη συνέχεια συνεχίζουμε τη διαδικασία. -(((workflows, merging))) -One simple workflow merges your work into your `master` branch. -In this scenario, you have a `master` branch that contains basically stable code. -When you have work in a topic branch that you've done or that someone has contributed and you've verified, you merge it into your master branch, delete the topic branch, and then continue the process. -If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <> and merge `ruby_client` first and then `php_client` next, then your history will end up looking like <>. +Εάν έχουμε ένα αποθετήριο με εργασία σε δύο κλάδους που ονομάζονται `ruby_client` και `php_client`, που μοιάζει με το <>, και συγχωνεύσουμε πρώτα τον `ruby_client` και στη συνέχεια τον `php_client`, τότε το ιστορικό μας θα καταλήξει να μοιάζει με το <>. -[[merwf_a]] -.History with several topic branches. -image::images/merging-workflows-1.png[History with several topic branches.] +[[r_merwf_a]] +.Ιστορικό με θεματικούς κλάδους +image::images/merging-workflows-1.png[Ιστορικό με θεματικούς κλάδους] -[[merwf_b]] -.After a topic branch merge. -image::images/merging-workflows-2.png[After a topic branch merge.] +[[r_merwf_b]] +.Ιστορικό μετά από συγχώνευση θεματικών κλάδων +image::images/merging-workflows-2.png[Ιστορικό μετά από συγχώνευση θεματικών κλάδων] -That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. +Αυτή είναι πιθανότατα η απλούστερη ροή εργασίας, αλλά μπορεί να είναι προβληματική αν έχουμε να κάνουμε με μεγαλύτερα ή πιο ευσταθή έργα στα οποία θέλουμε να είμαστε πολύ προσεκτικοί σχετικά με το τι εισάγουμε. -If you have a more important project, you might want to use a two-phase merge cycle. -In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. -You regularly push both of these branches to the public repository. -Each time you have a new topic branch to merge in (<>), you merge it into `develop` (<>); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (<>). +Αν έχουμε ένα πιο σημαντικό έργο, ίσως θέλουμε να χρησιμοποιήσουμε έναν κύκλο συγχώνευσης δύο φάσεων. +Σε αυτό το σενάριο έχουμε δύο μακρόβιους κλάδους, `master` και `develop`, στους οποίους καθορίζουμε ότι ο `master` ενημερώνεται μόνο όταν δημιουργείται μία πολύ σταθερή έκδοση και όλος ο νέος κώδικας είναι ενσωματωμένος στον κλάδο `develop`. +Ωθούμε και τους δύο αυτούς κλάδους τακτικά σε ένα δημόσιο αποθετήριο. +Κάθε φορά που έχουμε έναν νέο θεματικό κλάδο να συγχωνεύσουμε (<>), τον συγχωνεύουμε στον κλάδο `develop` (<>)· τότε, όταν κάνουμε tag μια έκδοση (release), ταχυπροωθούμε τον `master` σε όποιον κλάδο βρίσκεται ο ευσταθής κλάδος `develop` (<>). -[[merwf_c]] -.Before a topic branch merge. -image::images/merging-workflows-3.png[Before a topic branch merge.] +[[r_merwf_c]] +.Πριν από τη συγχώνευση θεματικού κλάδου. +image::images/merging-workflows-3.png[Πριν από τη συγχώνευση θεματικού κλάδου] -[[merwf_d]] -.After a topic branch merge. -image::images/merging-workflows-4.png[After a topic branch merge.] +[[r_merwf_d]] +.Μετά τη συγχώνευση θεματικού κλάδου. +image::images/merging-workflows-4.png[Μετά τη συγχώνευση θεματικού κλάδου] -[[merwf_e]] -.After a project release. -image::images/merging-workflows-5.png[After a topic branch release.] +[[r_merwf_e]] +.Μετά τη δημοσιοποίηση έκδοσης. +image::images/merging-workflows-5.png[Μετά τη δημοσιοποίηση έκδοσης] -This way, when people clone your project's repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff. -You can also continue this concept, having an integrate branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch. +Με αυτόν τον τρόπο, όταν κάποιος κλωνοποιεί το αποθετήριο του έργου μας, μπορεί είτε να μεταβεί στον κλάδο `master`, να χτίσει την πιο πρόσφατη ευσταθή έκδοση και να συμβαδίζει με αυτή εύκολα, είτε να μεταβεί στον κλάδο `develop`, που περιέχει τις πιο πρόσφατες εξελίξεις. +Μπορούμε επίσης να επεκτείνουμε αυτό το μοντέλο και να έχουμε έναν κλάδο ολοκλήρωσης `integrate` στο οποίο όλες οι εργασίες συγχωνεύονται. +Στη συνέχεια, όταν το codebase σε αυτόν τον κλάδο είναι ευσταθές και περνάει τα τεστ, μπορούμε να το συγχωνεύσουμε σε έναν κλάδο `develop`· και όταν και αυτός έχει αποδειχθεί ευσταθής για κάποιο χρονικό διάστημα, τον ταχυπροωθούμε στον `master` κλάδο μας. -===== Large-Merging Workflows +===== Ροές εργασίας μεγάλης συγχώνευσης -(((workflows, "merging (large)"))) -The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. -When new work is introduced by contributors, it's collected into topic branches in the maintainer's repository in a manner similar to what we've described (see <>). -At this point, the topics are evaluated to determine whether they're safe and ready for consumption or whether they need more work. -If they're safe, they're merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. +(((ροές εργασίας, μεγάλης συγχώνευσης))) +Το έργο Git έχει τέσσερις μακρόβιους κλάδους: τους `master`,` next` και `seen` (παλιότερα `pu` -- proposed updates) για νέες εργασίες και τον `maint` για συντήρηση backport. +Όταν εισάγονται νέες εργασίες από συνεργάτες, συλλέγονται σε θεματικούς κλάδους στο αποθετήριο του διαχειριστή με τρόπο παρόμοιο με αυτόν που έχουμε περιγράψει (βλ. <>). +Σε αυτό το σημείο, τα θέματα αξιολογούνται για να διαπιστωθεί αν είναι ασφαλή και έτοιμα προς κατανάλωση ή αν χρειάζονται περισσότερη δουλειά. +Αν είναι ασφαλή, συγχωνεύονται στον κλάδο `next` και αυτός ο κλάδος ωθείται, ώστε όλοι να μπορούν να δοκιμάσουν τα θέματα που ενσωματώθηκαν. -[[merwf_f]] -.Managing a complex series of parallel contributed topic branches. -image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] +[[r_merwf_f]] +.Διαχείριση περίπλοκης ακολουθίας παράλληλων συνεισφερθέντων θεματικών κλάδων +image::images/large-merges-1.png[Διαχείριση περίπλοκης ακολουθίας παράλληλων συνεισφερθέντων θεματικών κλάδων] -If the topics still need work, they're merged into `pu` instead. -When it's determined that they're totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn't yet graduate to `master`. -This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: +Εάν τα θέματα θέλουν ακόμα δουλειά, συγχωνεύονται στον `seen`. +Όταν διαπιστωθεί ότι είναι τελείως ευσταθή, τα θέματα επανασυγχωνεύονται στον `master`. +Στη συνέχεια οι κλάδοι `next` και `seen` γίνονται ξανά build από τον κλάδο `master`. +Αυτό σημαίνει ότι ο `master` προχωρά σχεδόν πάντα, ο `next` επανατοποθετείται περιστασιακά και ο `seen` επανατοποθετείται ακόμα πιο συχνά: -.Merging contributed topic branches into long-term integration branches. -image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] +.Συγχώνευση συνεισφερθέντων θεματικών κλάδων σε μακρόβιους κλάδους ενσωμάτωσης +image::images/large-merges-2.png[Συγχώνευση συνεισφερθέντων θεματικών κλάδων σε μακρόβιους κλάδους ενσωμάτωσης] -When a topic branch has finally been merged into `master`, it's removed from the repository. -The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. -Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. +Όταν ένας θεματικός κλάδος έχει τελικά συγχωνευτεί στον `master`, αφαιρείται από το αποθετήριο. +Το έργο Git διαθέτει επίσης έναν κλάδο `maint` που αποσχίζεται (forked) από την τελευταία δημοσιευμένη έκδοση (release) ώστε να παρέχει επιθέματα backport για την περίπτωση που απαιτείται έκδοση συντήρησης. +Έτσι, όταν κλωνοποιούμε το αποθετήριο Git, έχουμε τέσσερις κλάδους στους οποίους μπορούμε να μεταβούμε για να αξιολογήσουμε το έργο σε διαφορετικά στάδια ανάπτυξης, ανάλογα με το πόσο σύγχρονος θέλουμε να είμαστε ή πως θέλουμε να συνεισφέρουμε· και ο συντηρητής έχει μια δομημένη ροή εργασίας για να τους βοηθήσει να ελέγξουν νέες συνεισφορές. +Η ροή εργασίας του Git είναι εξειδικευμένη. +Για να το κατανοήσουμε πλήρως μπορούμε να δούμε το https://github.com/git/git/blob/master/Documentation/howto/maintain-git.adoc[Git Maintainer's guide^]. -[[_rebase_cherry_pick]] -===== Rebasing and Cherry Picking Workflows +[[r_rebase_cherry_pick]] +===== Ροές εργασίας με αλλαγή βάσης και ανθολόγηση (((workflows, rebasing and cherry-picking))) -Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. -When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. -If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. +Άλλοι συντηρητές προτιμούν να επανατοποθετούν (rebase) ή να ανθολογούν (cherry-pick) τις συνεισφορές στην κορυφή του `master` κλάδου τους, αντί να τις συγχωνεύουν, για να διατηρήσουν ένα κυρίως γραμμικό ιστορικό. +Όταν εργαζόμαστε σε έναν θεματικό κλάδο και έχουμε αποφασίσει ότι θέλουμε να τον ενσωματώσουμε, μεταβαίνουμε σε αυτόν και εκτελούμε την εντολή `rebase` για να ξαναχτίσουμε τις αλλαγές με νέα βάση τον `master` (ή τον `develop` κ.ο.κ.) κλάδο μας. +Αν αυτό λειτουργεί καλά, τότε μπορούμε να ταχυπροωθήσουμε τον κύριο κλάδο μας οπότε θα καταλήξουμε με ένα γραμμικό ιστορικό έργου. -(((git commands, cherry-pick))) -The other way to move introduced work from one branch to another is to cherry-pick it. -A cherry-pick in Git is like a rebase for a single commit. -It takes the patch that was introduced in a commit and tries to reapply it on the branch you're currently on. -This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you'd prefer to cherry-pick it rather than run rebase. -For example, suppose you have a project that looks like this: +(((εντολές git, cherry-pick))) +Ο άλλος τρόπος για να μετακινήσουμε εργασία που εισάγεται από τον ένα κλάδο στον άλλο είναι η ανθολόγηση (cherry-pick). +Η ανθολόγηση στο Git είναι σαν μια αλλαγή βάσης μίας μόνο υποβολής. +Παίρνει το επίθεμα που εισήχθη σε μια υποβολή και προσπαθεί να το ξαναεφαρμόσει στον κλάδο στον οποίο βρισκόμαστε αυτή τη στιγμή. +Η ανθολόγηση είναι χρήσιμη εάν έχουμε αρκετές υποβολές σε έναν θεματικό κλάδο και θέλουμε να ενσωματώσουμε μόνο μία από αυτές ή εάν έχουμε μόνο μία υποβολή σε έναν θεματικό κλάδο και προτιμάμε να την ανθολογήσουμε αντί να αλλάξουμε τη βάση της. +Για παράδειγμα, ας υποθέσουμε ότι έχουμε ένα έργο που μοιάζει με αυτό: -.Example history before a cherry-pick. -image::images/rebasing-1.png[Example history before a cherry-pick.] +.Παράδειγμα ιστορικού πριν την ανθολόγηση +image::images/rebasing-1.png[Παράδειγμα ιστορικού πριν την ανθολόγηση] -If you want to pull commit `e43a6` into your master branch, you can run +Αν θέλουμε να ελκύσουμε την υποβολή `e43a6` στον `master`, μπορούμε να εκτελέσουμε: [source,console] ------ -$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf +---- +$ git cherry-pick e43a6 Finished one cherry-pick. [master]: created a0a41a9: "More friendly message when locking the index fails." 3 files changed, 17 insertions(+), 3 deletions(-) ------ +---- -This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. -Now your history looks like this: +Αυτή η εντολή τραβά την ίδια αλλαγή με αυτή που εισήχθη στην `e43a6`, αλλά παίρνουμε μια νέα τιμή SHA-1 για την υποβολή επειδή η ημερομηνία κατά την οποία εφαρμόστηκε είναι διαφορετική. +Τώρα το ιστορικό μας μοιάζει με αυτό: -.History after cherry-picking a commit on a topic branch. -image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] +.Ιστορικό μετά την ανθολόγηση υποβολής σε έναν θεματικό κλάδο +image::images/rebasing-2.png[Ιστορικό μετά την ανθολόγηση υποβολής σε έναν θεματικό κλάδο] -Now you can remove your topic branch and drop the commits you didn't want to pull in. +Πλέον μπορούμε να καταργήσουμε τον θεματικό κλάδο και να εγκαταλείψουμε τις υποβολές που δεν θέλαμε να ελκύσουμε. ===== Rerere -(((git commands, rerere)))(((rerere))) -If you're doing lots of merging and rebasing, or you're maintaining a long-lived topic branch, Git has a feature called ``rerere'' that can help. +(((εντολές git, rerere)))(((rerere))) +Εάν κάνουμε πολλές συγχωνεύσεις και αλλαγές βάσης ή διατηρούμε ένα μακρόβιο θεματικό κλάδο, το Git διαθέτει μια λειτουργία που λέγεται "`rerere`" και η οποία μπορεί να μας βοηθήσει. -Rerere stands for ``reuse recorded resolution'' – it's a way of shortcutting manual conflict resolution. -When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it. +Rerere σημαίνει "`reuse recorded resolution`" (`"επαναχρησιμοποίηση καταγεγραμμένης επίλυσης`") -- είναι ένας τρόπος σύντομης αντιμετώπισης της μη-αυτόματης επίλυσης συγκρούσεων. +Όταν η rerere είναι ενεργοποιημένη, το Git θα διατηρήσει ένα σύνολο εικόνων πριν και μετά από επιτυχείς συγχωνεύσεις και αν παρατηρήσει ότι υπάρχει μια σύγκρουση που μοιάζει ακριβώς με μία που έχουμε ήδη επιλύσει, θα χρησιμοποιήσει απλώς το επίθεμα από την τελευταία φορά, χωρίς να μας ενοχλήσει. -This feature comes in two parts: a configuration setting and a command. -The configuration setting is `rerere.enabled`, and it's handy enough to put in your global config: +Αυτό το χαρακτηριστικό αποτελείται από δύο μέρη: μια παραμετροποίηση και μια εντολή. +Η παραμετροποίηση είναι `rerere.enabled` και είναι αρκετά βολική ώστε να την έχουμε στο καθολικό μας αρχείο config: [source,console] ---- $ git config --global rerere.enabled true ---- -Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future. +Τώρα, κάθε φορά που κάνουμε μια συγχώνευση που επιλύει διενέξεις, η επίλυση θα καταγράφεται στην κρυφή μνήμη για την περίπτωση που τη χρειαστούμε στο μέλλον. -If you need to, you can interact with the rerere cache using the `git rerere` command. -When it's invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if `rerere.enabled` is set to `true`). -There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. -We will cover rerere in more detail in <<_rerere>>. +Αν χρειαστεί, μπορούμε να αλληλεπιδράσουμε με τη μνήμη cache rerere χρησιμοποιώντας την εντολή `git rerere`. +Όταν καλείται χωρίς διακόπτες, το Git ελέγχει τη βάση δεδομένων επιλύσεων και προσπαθεί να βρει μια αντιστοίχιση με τις τρέχουσες συγκρούσεις συγχώνευσης και να τις επιλύσει (αν και αυτό γίνεται αυτόματα αν το `rerere.enabled` οριστεί σε `true`). +Υπάρχουν επίσης δευτερεύουσες εντολές για να δούμε τι θα εγγραφεί, να διαγράψουμε συγκεκριμένη ανάλυση από την προσωρινή μνήμη και να καθαρίσουμε ολόκληρη την προσωρινή μνήμη (cache). +Θα καλύψουμε την rerere με περισσότερες λεπτομέρειες στην ενότητα <>. -[[_tagging_releases]] -==== Tagging Your Releases +[[r_tagging_releases]] +==== Δημιουργία ετικετών για τις δημοσιευμένες εκδόσεις (((tags)))(((tags, signing))) -When you've decided to cut a release, you'll probably want to drop a tag so you can re-create that release at any point going forward. -You can create a new tag as discussed in <<_git_basics_chapter>>. -If you decide to sign the tag as the maintainer, the tagging may look something like this: +Όταν αποφασίσουμε να δημοσιοποίησουμε μια έκδοση, πιθανώς θέλουμε να αφήσουμε μια ετικέτα ώστε να μπορούμε να δημιουργήσουμε εκ νέου αυτή την έκδοση σε οποιοδήποτε σημείο στο μέλλον. +μπορούμε να δημιουργήσουμε μια νέα ετικέτα όπως περιγράφεται στην ενότητα <>. +Αν αποφασίσουμε να υπογράψουμε την ετικέτα ως ο συντηρητής, η ετικέτα μπορεί να φαίνεται κάπως έτσι: [source,console] ------ +---- $ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 ------ +---- -If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. -The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. -To do this, you can figure out which key you want by running `gpg --list-keys`: +Εάν υπογράφουμε τις ετικέτες μας, μπορεί να έχουμε πρόβλημα όσον αφορά στη διανομή του δημόσιου κλειδιού PGP που χρησιμοποιείται για την υπογραφή των ετικετών μας. +Ο συντηρητής του έργου Git έχει επιλύσει αυτό το ζήτημα συμπεριλαμβάνοντας το δημόσιο κλειδί του ως ένα blob στο αποθετήριο και στη συνέχεια προσθέτοντας μια ετικέτα που δείχνει κατευθείαν σε αυτό το περιεχόμενο. +Για να το κάνουμε αυτό, πρέπει να καταλάβουμε ποιο κλειδί θέλουμε εκτελώντας την εντολή `gpg --list-keys`: [source,console] ------ +---- $ gpg --list-keys /Users/schacon/.gnupg/pubring.gpg --------------------------------- pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09] uid Scott Chacon sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] ------ +---- -Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob: +Στη συνέχεια, μπορούμε να εισάγουμε απευθείας το κλειδί στη βάση δεδομένων Git, αν το εξάγουμε και το παροχετεύσουμε στο `git hash-object`, το οποίο γράφει ένα νέο blob με αυτά τα περιεχόμενα στο Git και μας επιστρέφει τον SHA-1 του blob: [source,console] ------ +---- $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 ------ +---- -Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you: +Τώρα που έχουμε τα περιεχόμενα του κλειδιού μας στο Git, μπορούμε να δημιουργήσουμε μια ετικέτα που να δείχνει απευθείας σε αυτό δίνοντας τη νέα τιμή SHA-1 που μας έδωσε η εντολή `hash-object`: [source,console] ------ +---- $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 ------ +---- -If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone. -If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG: +Εάν εκτελέσουμε `git push --tags`, η ετικέτα `maintainer-pgp-pub` θα κοινοποιηθεί σε όλους. +Αν κάποιος θέλει να επαληθεύσει μια ετικέτα, μπορεί να εισάγει απευθείας το PGP κλειδί μας τραβώντας το blob απευθείας από τη βάση δεδομένων και εισάγοντάς το στο GPG: [source,console] ------ +---- $ git show maintainer-pgp-pub | gpg --import ------ +---- -They can use that key to verify all your signed tags. -Also, if you include instructions in the tag message, running `git show ` will let you give the end user more specific instructions about tag verification. +Μπορεί να χρησιμοποιήσει αυτό το κλειδί για να ελέγξει όλες τις ετικέτες που έχουμε υπογράψει. +Επίσης, αν συμπεριλάβουμε οδηγίες στο μήνυμα της ετικέτας, η λειτουργία `git show ` θα μας επιτρέψει να δώσουμε στον τελικό χρήστη πιο συγκεκριμένες οδηγίες σχετικά με την επαλήθευση ετικετών. -[[_build_number]] -==== Generating a Build Number +[[r_build_number]] +==== Παραγωγή αριθμού build -(((build numbers)))(((git commands, describe))) -Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. -Git gives you the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you're describing: +(((αριθμοί build)))(((εντολές git, describe))) +Επειδή το Git δεν έχει αύξοντες αριθμούς όπως `v123` ή το ισοδύναμο για τις υποβολές, αν θέλουμε να έχουμε ένα ανθρωπανάγνωστο όνομα για κάθε υποβολή, μπορούμε να εκτελέσουμε `git describe` σε αυτή την υποβολή. +Το Git κατασκευάζει ένα αλφαριθμητικό το οποίο αποτελείται από το όνομα της πλησιέστερης χρονικά ετικέτας με τον αριθμό υποβολών στην κορυφή της ετικέτας και τη μερική τιμή SHA-1 της υποβολής που περιγράφουμε (με τον χαρακτήρα "`g`" στην αρχή, που σημαίνει Git): [source,console] ------ +---- $ git describe master v1.6.2-rc1-20-g8c5b85c ------ +---- -This way, you can export a snapshot or build and name it something understandable to people. -In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this. -If you're describing a commit that you have directly tagged, it gives you the tag name. +Με αυτό τον τρόπο, μπορούμε να εξάγουμε ένα στιγμιότυπο ή build και να τα ονομάσουμε με κάτι κατανοητό από ανθρώπους. +Μάλιστα, αν δημιουργήσουμε το Git από τον πηγαίο κώδικά του, που έχει κλωνοποιηθεί από το αποθετήριο Git, το `git --version` μας δίνει κάτι που μοιάζει με αυτό. +Αν περιγράφουμε μια υποβολή, στην οποία έχουμε προσαρτήσει μια ετικέτα, μας δίνει το όνομα της ετικέτας. -The `git describe` command favors annotated tags (tags created with the `-a` or `-s` flag), so release tags should be created this way if you're using `git describe`, to ensure the commit is named properly when described. -You can also use this string as the target of a checkout or show command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. -For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated. +Η εντολή `git describe` απαιτεί επισημασμένες ετικέτες (ετικέτες που δημιουργούνται με τις σημαίες `-a` ή `-s`)· αν θέλουμε να χρησιμοποιήσουμε και τις απλές (μη-επισημασμένες) ετικέτες, προσθέτουμε την επιλογή `--tags` στην εντολή. +Μπορούμε επίσης να χρησιμοποιήσουμε αυτή τη συμβολοσειρά ως τον στόχο μιας εντολής `git checkout` ή `git show` αν και βασίζεται στη συντομευμένη τιμή SHA-1 (τα τελευταία ψηφία), οπότε ίσως να μην ισχύει για πάντα. +Για παράδειγμα, ο πυρήνας Linux αυξήθηκε πρόσφατα από 8 σε 10 χαρακτήρες για να εξασφαλίσει τη μοναδικότητα αντικειμένων SHA-1, με αποτέλεσμα τα παλαιότερα ονόματα που δημιουργήθηκαν από την `git describe` να μην είναι έγκυρα πλέον. -[[_preparing_release]] -==== Preparing a Release +[[r_preparing_release]] +==== Προετοιμασία μίας δημοσιευμένης έκδοσης -(((releasing)))(((git commands, archive))) -Now you want to release a build. -One of the things you'll want to do is create an archive of the latest snapshot of your code for those poor souls who don't use Git. -The command to do this is `git archive`: +(((δημοσίευση έκδοσης (release) )))(((εντολές git, archive))) +Τώρα θέλουμε να δημοσιεύσουμε ένα build. +Ένα από τα πράγματα που θα θελήσουμε να κάνουμε είναι να δημιουργήσουμε ένα αρχείο (archive) του τελευταίου στιγμιότυπου του κώδικά μας για τα άτομα που δεν χρησιμοποιούν το Git. +Η εντολή για να γίνει αυτό είναι `git archive`: [source,console] ------ +---- $ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz ------ +---- -If someone opens that tarball, they get the latest snapshot of your project under a project directory. -You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`: +Αν κάποιος ανοίξει αυτό το tarball, θα πάρει το τελευταίο στιγμιότυπο του έργου μας μέσα σε έναν κατάλογο με όνομα `project`. +Μπορούμε επίσης να δημιουργήσουμε ένα αρχείο zip με τον ίδιο τρόπο, αν περάσουμε την επιλογή `--format=zip` στην `git archive`: [source,console] ------ +---- $ git archive master --prefix='project/' --format=zip > `git describe master`.zip ------ +---- -You now have a nice tarball and a zip archive of your project release that you can upload to your website or e-mail to people. +Τώρα έχουμε ένα ωραιότατο tarball και ένα αρχείο zip της έκδοσης του έργου μας που μπορούμε να ανεβάσουμε στον ιστότοπό μας ή να στείλουμε με e-mail σε άλλους. -[[_the_shortlog]] -==== The Shortlog +[[r_the_shortlog]] +==== Η εντολή `shortlog` -(((git commands, shortlog))) -It's time to e-mail your mailing list of people who want to know what's happening in your project. -A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or e-mail is to use the `git shortlog` command. -It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1: +(((εντολές git, shortlog))) +Ήρθε η ώρα να στείλουμε e-mail στα μέλη της mailing list που θέλουν να μάθουν τι συμβαίνει στο έργο μας. +Ένας καλός τρόπος να αποκτήσουμε γρήγορα ένα είδος μητρώου αλλαγών (changelog) από ό,τι έχει προστεθεί στο έργο μας από την τελευταία έκδοση ή το e-mail μας είναι να χρησιμοποιήσουμε την εντολή `git shortlog`. +Συνοψίζει όλες τις υποβολές στο εύρος υποβολών που της δίνουμε· για παράδειγμα, παρακάτω δίνεται μια περίληψη όλων των υποβολών από την τελευταία έκδοση, εάν η τελευταία έκδοσή μας ονομάστηκε `v1.0.1`: [source,console] ------ +---- $ git shortlog --no-merges master --not v1.0.1 -Chris Wanstrath (8): +Chris Wanstrath (6): Add support for annotated tags to Grit::Tag Add packed-refs annotated tag support. Add Grit::Commit#to_patch @@ -540,6 +551,6 @@ Tom Preston-Werner (4): dynamic version method Version bump to 1.0.2 Regenerated gemspec for version 1.0.2 ------ +---- -You get a clean summary of all the commits since v1.0.1, grouped by author, that you can e-mail to your list. +Παίρνουμε μια καθαρή σύνοψη όλων των υποβολών από την `v1.0.1` και μετά, ομαδοποιημένων κατά συγγραφέα, που μπορούμε να στείλουμε με e-mail στη λίστα μας. diff --git a/book/06-github/1-github.asc b/book/06-github/1-github.asc deleted file mode 100644 index ecd727a81..000000000 --- a/book/06-github/1-github.asc +++ /dev/null @@ -1,35 +0,0 @@ -[[_github]] -== GitHub - -(((GitHub))) -GitHub is the single largest host for Git repositories, and is the central point of collaboration for millions of developers and projects. -A large percentage of all Git repositories are hosted on GitHub, and many open-source projects use it for Git hosting, issue tracking, code review, and other things. -So while it's not a direct part of the Git open source project, there's a good chance that you'll want or need to interact with GitHub at some point while using Git professionally. - -This chapter is about using GitHub effectively. -We'll cover signing up for and managing an account, creating and using Git repositories, common workflows to contribute to projects and to accept contributions to yours, GitHub's programmatic interface and lots of little tips to make your life easier in general. - -If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to <<_git_tools>>. - -[WARNING] -.Interfaces Change -==== -It's important to note that like many active websites, the UI elements in these screenshots are bound to change over time. -Hopefully the general idea of what we're trying to accomplish here will still be there, but if you want more up to date versions of these screens, the online versions of this book may have newer screenshots. -==== - -include::sections/1-setting-up-account.asc[] - -include::sections/2-contributing.asc[] - -include::sections/3-maintaining.asc[] - -include::sections/4-managing-organization.asc[] - -include::sections/5-scripting.asc[] - -=== Summary - -Now you're a GitHub user. -You know how to create an account, manage an organization, create and push to repositories, contribute to other people's projects and accept contributions from others. -In the next chapter, you'll learn more powerful tools and tips for dealing with complex situations, which will truly make you a Git master. diff --git a/book/06-github/callouts/1.pdf b/book/06-github/callouts/1.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/10.pdf b/book/06-github/callouts/10.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/10.png b/book/06-github/callouts/10.png index 80872645f..821ef4cee 100644 Binary files a/book/06-github/callouts/10.png and b/book/06-github/callouts/10.png differ diff --git a/book/06-github/callouts/2.pdf b/book/06-github/callouts/2.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/2.png b/book/06-github/callouts/2.png index 4bb6abc07..e881df133 100644 Binary files a/book/06-github/callouts/2.png and b/book/06-github/callouts/2.png differ diff --git a/book/06-github/callouts/3.pdf b/book/06-github/callouts/3.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/3.png b/book/06-github/callouts/3.png index e132a559f..200d58251 100644 Binary files a/book/06-github/callouts/3.png and b/book/06-github/callouts/3.png differ diff --git a/book/06-github/callouts/4.pdf b/book/06-github/callouts/4.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/5.pdf b/book/06-github/callouts/5.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/5.png b/book/06-github/callouts/5.png index 76375432e..e52d3a842 100644 Binary files a/book/06-github/callouts/5.png and b/book/06-github/callouts/5.png differ diff --git a/book/06-github/callouts/6.pdf b/book/06-github/callouts/6.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/7.pdf b/book/06-github/callouts/7.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/7.png b/book/06-github/callouts/7.png index 009bf1a1c..f07d991f9 100644 Binary files a/book/06-github/callouts/7.png and b/book/06-github/callouts/7.png differ diff --git a/book/06-github/callouts/8.pdf b/book/06-github/callouts/8.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/callouts/8.png b/book/06-github/callouts/8.png index 2470994e8..c99ae9e7a 100644 Binary files a/book/06-github/callouts/8.png and b/book/06-github/callouts/8.png differ diff --git a/book/06-github/callouts/9.pdf b/book/06-github/callouts/9.pdf old mode 100755 new mode 100644 diff --git a/book/06-github/images/2fa-1.png b/book/06-github/images/2fa-1.png deleted file mode 100644 index 20a6e599f..000000000 Binary files a/book/06-github/images/2fa-1.png and /dev/null differ diff --git a/book/06-github/images/account-settings.png b/book/06-github/images/account-settings.png deleted file mode 100644 index 622171a60..000000000 Binary files a/book/06-github/images/account-settings.png and /dev/null differ diff --git a/book/06-github/images/avatar-crop.png b/book/06-github/images/avatar-crop.png deleted file mode 100644 index cd1671ae6..000000000 Binary files a/book/06-github/images/avatar-crop.png and /dev/null differ diff --git a/book/06-github/images/blink-01-start.png b/book/06-github/images/blink-01-start.png deleted file mode 100644 index be140e19e..000000000 Binary files a/book/06-github/images/blink-01-start.png and /dev/null differ diff --git a/book/06-github/images/blink-02-pr.png b/book/06-github/images/blink-02-pr.png deleted file mode 100644 index 968165717..000000000 Binary files a/book/06-github/images/blink-02-pr.png and /dev/null differ diff --git a/book/06-github/images/blink-03-pull-request-open.png b/book/06-github/images/blink-03-pull-request-open.png deleted file mode 100644 index 703508651..000000000 Binary files a/book/06-github/images/blink-03-pull-request-open.png and /dev/null differ diff --git a/book/06-github/images/blink-04-email.png b/book/06-github/images/blink-04-email.png deleted file mode 100644 index af3090e74..000000000 Binary files a/book/06-github/images/blink-04-email.png and /dev/null differ diff --git a/book/06-github/images/blink-04-pr-comment.png b/book/06-github/images/blink-04-pr-comment.png deleted file mode 100644 index 4e31e7732..000000000 Binary files a/book/06-github/images/blink-04-pr-comment.png and /dev/null differ diff --git a/book/06-github/images/blink-05-general-comment.png b/book/06-github/images/blink-05-general-comment.png deleted file mode 100644 index 1c3f4f3ee..000000000 Binary files a/book/06-github/images/blink-05-general-comment.png and /dev/null differ diff --git a/book/06-github/images/blink-06-final.png b/book/06-github/images/blink-06-final.png deleted file mode 100644 index 06dc9de6d..000000000 Binary files a/book/06-github/images/blink-06-final.png and /dev/null differ diff --git a/book/06-github/images/blink-pull-request-open copy.png b/book/06-github/images/blink-pull-request-open copy.png deleted file mode 100644 index ad7976e3c..000000000 Binary files a/book/06-github/images/blink-pull-request-open copy.png and /dev/null differ diff --git a/book/06-github/images/blink-pull-request-open.png b/book/06-github/images/blink-pull-request-open.png deleted file mode 100644 index 3c43df3c3..000000000 Binary files a/book/06-github/images/blink-pull-request-open.png and /dev/null differ diff --git a/book/06-github/images/collaborators.png b/book/06-github/images/collaborators.png deleted file mode 100644 index ba126100d..000000000 Binary files a/book/06-github/images/collaborators.png and /dev/null differ diff --git a/book/06-github/images/email-settings.png b/book/06-github/images/email-settings.png deleted file mode 100644 index 0291aeacc..000000000 Binary files a/book/06-github/images/email-settings.png and /dev/null differ diff --git a/book/06-github/images/emoji.png b/book/06-github/images/emoji.png deleted file mode 100644 index 83c8cd21b..000000000 Binary files a/book/06-github/images/emoji.png and /dev/null differ diff --git a/book/06-github/images/forkbutton.png b/book/06-github/images/forkbutton.png deleted file mode 100644 index 9bc4c7988..000000000 Binary files a/book/06-github/images/forkbutton.png and /dev/null differ diff --git a/book/06-github/images/hubot.png b/book/06-github/images/hubot.png deleted file mode 100644 index 510b265f6..000000000 Binary files a/book/06-github/images/hubot.png and /dev/null differ diff --git a/book/06-github/images/maint-01-email.png b/book/06-github/images/maint-01-email.png deleted file mode 100644 index 1477b36de..000000000 Binary files a/book/06-github/images/maint-01-email.png and /dev/null differ diff --git a/book/06-github/images/maint-02-merge.png b/book/06-github/images/maint-02-merge.png deleted file mode 100644 index 69efa4b65..000000000 Binary files a/book/06-github/images/maint-02-merge.png and /dev/null differ diff --git a/book/06-github/images/maint-03-email-resp.png b/book/06-github/images/maint-03-email-resp.png deleted file mode 100644 index dbd3e6486..000000000 Binary files a/book/06-github/images/maint-03-email-resp.png and /dev/null differ diff --git a/book/06-github/images/maint-04-target.png b/book/06-github/images/maint-04-target.png deleted file mode 100644 index 0b153962b..000000000 Binary files a/book/06-github/images/maint-04-target.png and /dev/null differ diff --git a/book/06-github/images/maint-05-mentions.png b/book/06-github/images/maint-05-mentions.png deleted file mode 100644 index 35b60f3d0..000000000 Binary files a/book/06-github/images/maint-05-mentions.png and /dev/null differ diff --git a/book/06-github/images/maint-06-unsubscribe.png b/book/06-github/images/maint-06-unsubscribe.png deleted file mode 100644 index eaf6e2cfd..000000000 Binary files a/book/06-github/images/maint-06-unsubscribe.png and /dev/null differ diff --git a/book/06-github/images/maint-07-notifications.png b/book/06-github/images/maint-07-notifications.png deleted file mode 100644 index 7d07a4b2a..000000000 Binary files a/book/06-github/images/maint-07-notifications.png and /dev/null differ diff --git a/book/06-github/images/maint-08-notifications-page.png b/book/06-github/images/maint-08-notifications-page.png deleted file mode 100644 index d4998614d..000000000 Binary files a/book/06-github/images/maint-08-notifications-page.png and /dev/null differ diff --git a/book/06-github/images/maint-09-contrib.png b/book/06-github/images/maint-09-contrib.png deleted file mode 100644 index f6d9af3ce..000000000 Binary files a/book/06-github/images/maint-09-contrib.png and /dev/null differ diff --git a/book/06-github/images/maint-10-default-branch.png b/book/06-github/images/maint-10-default-branch.png deleted file mode 100644 index bd251d6ce..000000000 Binary files a/book/06-github/images/maint-10-default-branch.png and /dev/null differ diff --git a/book/06-github/images/maint-11-transfer.png b/book/06-github/images/maint-11-transfer.png deleted file mode 100644 index 5dc5724cf..000000000 Binary files a/book/06-github/images/maint-11-transfer.png and /dev/null differ diff --git a/book/06-github/images/markdown-01-example.png b/book/06-github/images/markdown-01-example.png deleted file mode 100644 index 10bbf18cb..000000000 Binary files a/book/06-github/images/markdown-01-example.png and /dev/null differ diff --git a/book/06-github/images/markdown-02-tasks.png b/book/06-github/images/markdown-02-tasks.png deleted file mode 100644 index 6dafbc739..000000000 Binary files a/book/06-github/images/markdown-02-tasks.png and /dev/null differ diff --git a/book/06-github/images/markdown-03-task-summary.png b/book/06-github/images/markdown-03-task-summary.png deleted file mode 100644 index 536aa094f..000000000 Binary files a/book/06-github/images/markdown-03-task-summary.png and /dev/null differ diff --git a/book/06-github/images/markdown-04-fenced-code.png b/book/06-github/images/markdown-04-fenced-code.png deleted file mode 100644 index ca3482f90..000000000 Binary files a/book/06-github/images/markdown-04-fenced-code.png and /dev/null differ diff --git a/book/06-github/images/markdown-05-quote.png b/book/06-github/images/markdown-05-quote.png deleted file mode 100644 index 02a8451ad..000000000 Binary files a/book/06-github/images/markdown-05-quote.png and /dev/null differ diff --git a/book/06-github/images/markdown-06-emoji-complete.png b/book/06-github/images/markdown-06-emoji-complete.png deleted file mode 100644 index ce9492002..000000000 Binary files a/book/06-github/images/markdown-06-emoji-complete.png and /dev/null differ diff --git a/book/06-github/images/markdown-07-emoji.png b/book/06-github/images/markdown-07-emoji.png deleted file mode 100644 index b535756d6..000000000 Binary files a/book/06-github/images/markdown-07-emoji.png and /dev/null differ diff --git a/book/06-github/images/markdown-08-drag-drop.png b/book/06-github/images/markdown-08-drag-drop.png deleted file mode 100644 index 1dfb3b981..000000000 Binary files a/book/06-github/images/markdown-08-drag-drop.png and /dev/null differ diff --git a/book/06-github/images/mentions-01-syntax.png b/book/06-github/images/mentions-01-syntax.png deleted file mode 100644 index c960b0c94..000000000 Binary files a/book/06-github/images/mentions-01-syntax.png and /dev/null differ diff --git a/book/06-github/images/mentions-02-render.png b/book/06-github/images/mentions-02-render.png deleted file mode 100644 index 5b4bfee3d..000000000 Binary files a/book/06-github/images/mentions-02-render.png and /dev/null differ diff --git a/book/06-github/images/mentions-03-closed.png b/book/06-github/images/mentions-03-closed.png deleted file mode 100644 index cf3ef9e2d..000000000 Binary files a/book/06-github/images/mentions-03-closed.png and /dev/null differ diff --git a/book/06-github/images/new-repo.png b/book/06-github/images/new-repo.png deleted file mode 100644 index 485515bd6..000000000 Binary files a/book/06-github/images/new-repo.png and /dev/null differ diff --git a/book/06-github/images/neworg.png b/book/06-github/images/neworg.png deleted file mode 100644 index db47fff0a..000000000 Binary files a/book/06-github/images/neworg.png and /dev/null differ diff --git a/book/06-github/images/newrepo.png b/book/06-github/images/newrepo.png deleted file mode 100644 index cd508f165..000000000 Binary files a/book/06-github/images/newrepo.png and /dev/null differ diff --git a/book/06-github/images/newrepoform.png b/book/06-github/images/newrepoform.png deleted file mode 100644 index 28fa6a7e4..000000000 Binary files a/book/06-github/images/newrepoform.png and /dev/null differ diff --git a/book/06-github/images/notifications.png b/book/06-github/images/notifications.png deleted file mode 100644 index 6768db4d8..000000000 Binary files a/book/06-github/images/notifications.png and /dev/null differ diff --git a/book/06-github/images/orgs-01-page.png b/book/06-github/images/orgs-01-page.png deleted file mode 100644 index 149773fe9..000000000 Binary files a/book/06-github/images/orgs-01-page.png and /dev/null differ diff --git a/book/06-github/images/orgs-02-teams.png b/book/06-github/images/orgs-02-teams.png deleted file mode 100644 index 46f5f2cee..000000000 Binary files a/book/06-github/images/orgs-02-teams.png and /dev/null differ diff --git a/book/06-github/images/orgs-03-audit.png b/book/06-github/images/orgs-03-audit.png deleted file mode 100644 index 4f0639896..000000000 Binary files a/book/06-github/images/orgs-03-audit.png and /dev/null differ diff --git a/book/06-github/images/pr-01-fail.png b/book/06-github/images/pr-01-fail.png deleted file mode 100644 index 80331c1d0..000000000 Binary files a/book/06-github/images/pr-01-fail.png and /dev/null differ diff --git a/book/06-github/images/pr-02-merge-fix.png b/book/06-github/images/pr-02-merge-fix.png deleted file mode 100644 index 9da163222..000000000 Binary files a/book/06-github/images/pr-02-merge-fix.png and /dev/null differ diff --git a/book/06-github/images/reposettingslink.png b/book/06-github/images/reposettingslink.png deleted file mode 100644 index 45e60162f..000000000 Binary files a/book/06-github/images/reposettingslink.png and /dev/null differ diff --git a/book/06-github/images/scripting-01-services.png b/book/06-github/images/scripting-01-services.png deleted file mode 100644 index 07c20103c..000000000 Binary files a/book/06-github/images/scripting-01-services.png and /dev/null differ diff --git a/book/06-github/images/scripting-02-email-service.png b/book/06-github/images/scripting-02-email-service.png deleted file mode 100644 index 209bfe766..000000000 Binary files a/book/06-github/images/scripting-02-email-service.png and /dev/null differ diff --git a/book/06-github/images/scripting-03-webhook.png b/book/06-github/images/scripting-03-webhook.png deleted file mode 100644 index 103eb92a8..000000000 Binary files a/book/06-github/images/scripting-03-webhook.png and /dev/null differ diff --git a/book/06-github/images/scripting-04-webhook-debug.png b/book/06-github/images/scripting-04-webhook-debug.png deleted file mode 100644 index 617e41eec..000000000 Binary files a/book/06-github/images/scripting-04-webhook-debug.png and /dev/null differ diff --git a/book/06-github/images/scripting-05-access-token.png b/book/06-github/images/scripting-05-access-token.png deleted file mode 100644 index 175077178..000000000 Binary files a/book/06-github/images/scripting-05-access-token.png and /dev/null differ diff --git a/book/06-github/images/scripting-06-comment.png b/book/06-github/images/scripting-06-comment.png deleted file mode 100644 index 52448174d..000000000 Binary files a/book/06-github/images/scripting-06-comment.png and /dev/null differ diff --git a/book/06-github/images/scripting-07-status.png b/book/06-github/images/scripting-07-status.png deleted file mode 100644 index a34314d96..000000000 Binary files a/book/06-github/images/scripting-07-status.png and /dev/null differ diff --git a/book/06-github/images/signup.png b/book/06-github/images/signup.png deleted file mode 100644 index 916a882c3..000000000 Binary files a/book/06-github/images/signup.png and /dev/null differ diff --git a/book/06-github/images/ssh-keys.png b/book/06-github/images/ssh-keys.png deleted file mode 100644 index b9dec471b..000000000 Binary files a/book/06-github/images/ssh-keys.png and /dev/null differ diff --git a/book/06-github/images/your-profile.png b/book/06-github/images/your-profile.png deleted file mode 100644 index 50fa0c1e7..000000000 Binary files a/book/06-github/images/your-profile.png and /dev/null differ diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 922efc5d5..e3655930e 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,95 +1,97 @@ -=== Account Setup and Configuration +=== Δημιουργία λογαριασμού και ρύθμισή του (((GitHub, user accounts))) -The first thing you need to do is set up a free user account. -Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. +Το πρώτο πράγμα που πρέπει να κάνουμε είναι να δημιουργήσουμε έναν δωρεάν λογαριασμό χρήστη. +Απλά επισκεφτόμαστε τη διεύθυνση https://github.com[^], επιλέγουμε ένα όνομα χρήστη που δεν το έχει πάρει κάποιος άλλος, δίνουμε μια διεύθυνση e-mail και έναν κωδικό πρόσβασης και κάνουμε κλικ στο μεγάλο πράσινο κουμπί "`Sign up for GitHub`". -.The GitHub sign-up form. -image::images/signup.png[The GitHub sign-up form.] +.Η φόρμα εγγραφής του GitHub. +image::images/signup.png[Η φόρμα εγγραφής του GitHub.] -The next thing you'll see is the pricing page for upgraded plans, but it's safe to ignore this for now. -GitHub will send you an email to verify the address you provided. -Go ahead and do this, it's pretty important (as we'll see later). +Το επόμενο πράγμα που θα δούμε είναι η σελίδα τιμολόγησης για αναβαθμισμένα πακέτα, αλλά είναι ασφαλές να την αγνοήσουμε προς το παρόν. +Το GitHub θα μας στείλει ένα μήνυμα e-mail για να επαληθεύσουμε τη διεύθυνση που δώσαμε. +Ας το κάνουμε· είναι πολύ σημαντικό όπως θα δούμε αργότερα. [NOTE] ==== -GitHub provides all of its functionality with free accounts, with the limitation that all of your projects are fully public (everyone has read access). -GitHub's paid plans include a set number of private projects, but we won't be covering those in this book. +Το GitHub παρέχει όλες τις λειτουργίες του με δωρεάν λογαριασμούς, εκτός από κάποια προχωρημένα χαρακτηριστικά + +Τα πακέτα του GitHub με πληρωμή περιλαμβάνουν έναν ορισμένο αριθμό ιδιωτικών έργων, αλλά δεν θα τα καλύψουμε σε αυτό το βιβλίο. +Για να πάρετε περισσότερες πληροφορίες σχετικά με τα διαθέσιμα πακέτα και για την συγκρίση τους, επισκεφθείτε https://github.com/pricing[^]. ==== -Clicking the Octocat logo at the top-left of the screen will take you to your dashboard page. -You're now ready to use GitHub. +Κάνοντας κλικ στο λογότυπο Octocat στην επάνω αριστερή γωνία της οθόνης, θα μεταβούμε στη σελίδα του πίνακα ελέγχου. +Είμαστε πλέον έτοιμοι να χρησιμοποιήσουμε το GitHub. -==== SSH Access +==== Πρόσβαση με SSH -(((SSH keys, with GitHub))) -As of right now, you're fully able to connect with Git repositories using the `https://` protocol, authenticating with the username and password you just set up. -However, to simply clone public projects, you don't even need to sign up - the account we just created comes into play when we fork projects and push to our forks a bit later. +(((κλειδιά SSH, with GitHub))) +Ήδη μπορούμε να συνδεθούμε πλήρως με αποθετήρια Git χρησιμοποιώντας το πρωτόκολλο `https://`, και να ταυτοποιηθούμε με το όνομα χρήστη και τον κωδικό πρόσβασης που μόλις δημιουργήσαμε. +Πάντως, αν θέλουμε μόνον να κλωνοποιήσουμε δημόσια έργα, δεν χρειάζεται καν να συνδεθούμε —ο λογαριασμός που μόλις δημιουργήσαμε θα χρειαστεί όταν αποσχίσουμε κάποιο έργο και ωθήσουμε στις διχάλες μας αργότερα. -If you'd like to use SSH remotes, you'll need to configure a public key. -(If you don't already have one, see <<_generate_ssh_key>>.) -Open up your account settings using the link at the top-right of the window: +Εάν θέλουμε να χρησιμοποιήσουμε απομακρυσμένα αποθετήρια μέσω SSH, θα πρέπει να δημιουργήσουμε ένα δημόσιο κλειδί. +(Εάν δεν έχουμε ήδη ένα, ανατρέχουμε στην ενότητα <>.) +Ανοίγουμε τις ρυθμίσεις του λογαριασμού μας χρησιμοποιώντας το σύνδεσμο που βρίσκεται στην επάνω δεξιά γωνία του παραθύρου: -.The ``Account settings'' link. -image::images/account-settings.png[The ``Account settings'' link.] +.Ο σύνδεσμος "`Account settings`". +image::images/account-settings.png[Ο σύνδεσμος “Account settings”.] -Then select the ``SSH keys'' section along the left-hand side. +Στη συνέχεια, επιλέγουμε την ενότητα "`SSH keys`" στην αριστερή πλευρά. -.The ``SSH keys'' link. -image::images/ssh-keys.png[The ``SSH keys'' link.] +.Ο σύνδεσμος "`SSH keys`". +image::images/ssh-keys.png[Ο σύνδεσμος “SSH keys”.] -From there, click the "`Add an SSH key`" button, give your key a name, paste the contents of your `~/.ssh/id_rsa.pub` (or whatever you named it) public-key file into the text area, and click ``Add key''. +Από εκεί, κάνουμε κλικ στο κουμπί "`Add an SSH key`", δίνουμε στο κλειδί μας ένα όνομα, επικολλούμε τα περιεχόμενα του αρχείου δημόσιου κλειδιού (`~/.ssh/id_rsa.pub` ή όπως αλλιώς το έχουμε ονομάσει) και κάνουμε κλικ στο κουμπί "`Add key`". [NOTE] ==== -Be sure to name your SSH key something you can remember. -You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for. +Είναι σημαντικό να ονομάζουμε το κλειδί SSH με ένα όνομα που μπορούμε να θυμηθούμε. +Μπορούμε να ονομάσουμε καθένα από τα κλειδιά μας (π.χ. "My Laptop" ή "Work Account"), έτσι ώστε αν χρειαστεί να ανακαλέσουμε ένα κλειδί αργότερα, να μπορούμε εύκολα να πούμε ποιο αναζητούμε. ==== -[[_personal_avatar]] -==== Your Avatar +[[r_personal_avatar]] +==== Το avatar -Next, if you wish, you can replace the avatar that is generated for you with an image of your choosing. -First go to the ``Profile'' tab (above the SSH Keys tab) and click ``Upload new picture''. +Στη συνέχεια, αν το επιθυμούμε, μπορούμε να αντικαταστήσουμε το avatar που δημιουργήθηκε για εμάς με μια εικόνα της επιλογής μας. +Πρώτα πηγαίνουμε στην καρτέλα "`Profile`" (πάνω από την καρτέλα ``SSH Keys'') και κάνουμε κλικ στο "`Upload new picture`".. -.The ``Profile'' link. -image::images/your-profile.png[The ``Profile'' link.] +.Ο σύνδεσμος "`Profile`". +image::images/your-profile.png[Ο σύνδεσμος “Profile”.] -We'll choose a copy of the Git logo that is on our hard drive and then we get a chance to crop it. +Θα επιλέξουμε ένα αντίγραφο του λογότυπου Git που βρίσκεται στο σκληρό δίσκο μας και στη συνέχεια θα έχουμε την ευκαιρία να τον περικόψουμε. -.Crop your avatar -image::images/avatar-crop.png[Crop your uploaded avatar.] +.Περικοπή του avatar. +image::images/avatar-crop.png[Περικοπή του μεταφορτωμένου avatar.] -Now anywhere you interact on the site, people will see your avatar next to your username. +Τώρα οπουδήποτε αλληλεπιδράμε στον ιστότοπο, οι χρήστες θα βλέπουν το avatar μας δίπλα στο όνομα χρήστη μας. -If you happen to have uploaded an avatar to the popular Gravatar service (often used for Wordpress accounts), that avatar will be used by default and you don't need to do this step. +Αν τυχαίνει να έχουμε ανεβάσει ένα avatar στη δημοφιλή υπηρεσία Gravatar (που χρησιμοποιείται συχνά για λογαριασμούς Wordpress), αυτό το avatar θα χρησιμοποιηθεί εκ προεπιλογής και δεν χρειάζεται να κάνουμε αυτό το βήμα. -==== Your Email Addresses +==== Οι διευθύνσεις μας e-mail -The way that GitHub maps your Git commits to your user is by email address. -If you use multiple email addresses in your commits and you want GitHub to link them up properly, you need to add all the email addresses you have used to the Emails section of the admin section. +Ο τρόπος με τον οποίο το GitHub αντιστοιχίζει τις υποβολές μας στον χρήστη που είμαστε είναι μέσω διεύθυνσης e-mail μας. +Εάν χρησιμοποιούμε πολλές διευθύνσεις e-mail στις υποβολές μας και θέλουμε το GitHub να τις συνδέσει σωστά, θα πρέπει να προσθέσουμε όλες τις διευθύνσεις e-mail που έχουμε χρησιμοποιήσει στην ενότητα Emails της ενότητας admin. -[[_add_email_addresses]] -.Add email addresses -image::images/email-settings.png[Add all your email addresses.] +[[r_add_email_addresses]] +.Προσθήκη διευθύνσεων e-mail +image::images/email-settings.png[Προσθήκη όλων των διευθύνσεων e-mail.] -In <<_add_email_addresses>> we can see some of the different states that are possible. -The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. -The second address is verified and so can be set as the primary if you wish to switch them. -The final address is unverified, meaning that you can't make it your primary address. -If GitHub sees any of these in commit messages in any repository on the site, it will be linked to your user now. +Στην εικόνα <> μπορούμε να δούμε κάποιες από τις διαφορετικές δυνατές καταστάσεις. +Η επάνω διεύθυνση έχει επαληθευτεί και ορίζεται ως η κύρια διεύθυνση, που σημαίνει ότι σε αυτήν θα λαμβάνουμε ειδοποιήσεις και αποδείξεις. +Η δεύτερη διεύθυνση έχει επαληθευτεί και έτσι μπορεί να οριστεί ως η κύρια διεύθυνση αν θέλουμε να την αλλάξουμε. +Η τελική διεύθυνση δεν έχει επαληθευτεί, πράγμα που σημαίνει ότι δεν μπορούμε να την καταστήσουμε κύρια διεύθυνση μας. +Πλέον, αν το GitHub βλέπει κάποια από αυτές στα μηνύματα υποβολών σε οποιοδήποτε αποθετήριο στον ιστότοπο, θα τη συνδέει με τον χρήστη ο οποίος είμαστε. -==== Two Factor Authentication +==== Ταυτοποίηση δύο παραγόντων -Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. -Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. -Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account. +Τέλος, για επιπρόσθετη ασφάλεια, θα πρέπει σίγουρα να ορίσουμε _ταυτοποίηση δύο παραγόντων_ ("`Two-factor authentication`") ή "`2FA`". +Η ταυτοποίηση δύο παραγόντων είναι ένας μηχανισμός ταυτοποίησης που γίνεται ολοένα και πιο δημοφιλής και μετριάζει τον κίνδυνο να εκτεθεί ο λογαριασμός μας, αν κάποιος καταφέρει και κλέψει τον κωδικό πρόσβασής μας. +Αν την ενεργοποιήσουμε, το GitHub θα μας ζητήσει δύο διαφορετικές μεθόδους ταυτοποίησης, έτσι ώστε εάν κάποια από αυτές παραβιαστεί, ο εισβολέας δεν θα μπορέσει να αποκτήσει πρόσβαση στον λογαριασμό μας. -You can find the Two-factor Authentication setup under the Security tab of your Account settings. +Μπορούμε να βρούμε τη ρύθμιση Two-factor Authentication στην καρτέλα Security των ρυθμίσεων του λογαριασμού μας. -.2FA in the Security Tab -image::images/2fa-1.png[2FA in the Security Tab] +.2FA στην καρτέλα Security. +image::images/2fa-1.png[2FA στην καρτέλα Security] -If you click on the ``Set up two-factor authentication'' button, it will take you to a configuration page where you can choose to use a phone app to generate your secondary code (a ``time based one-time password''), or you can have GitHub send you a code via SMS each time you need to log in. +Εφόσον κάνουμε κλικ στο κουμπί "`Set up two-factor authentication`", θα μεταβούμε σε μια σελίδα διαμόρφωσης όπου μπορούμε να επιλέξουμε να χρησιμοποιήσουμε μια εφαρμογή τηλεφώνου για να δημιουργήσουμε τον δευτερεύοντα κωδικό μας (έναν "`κωδικό πρόσβασης μίας χρήσης περιορισμένης χρονικής διάρκειας`") ή μπορούμε να ζητήσουμε από το GitHub να μας στέλνει έναν κωδικό μέσω SMS κάθε φορά που θέλουμε να συνδεθούμε. -After you choose which method you prefer and follow the instructions for setting up 2FA, your account will then be a little more secure and you will have to provide a code in addition to your password whenever you log into GitHub. +Αφού επιλέξουμε τη μέθοδο που προτιμάμε και ακολουθήσουμε τις οδηγίες για τη ρύθμιση του 2FA, ο λογαριασμός μας θα είναι λίγο πιο ασφαλής και θα πρέπει να παράσχουμε έναν επιπρόσθετο κωδικό, πέραν του κωδικού πρόσβασής μας, κάθε φορά που συνδεόμαστε στο GitHub. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 8c41da535..9e454b019 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -1,65 +1,74 @@ -=== Contributing to a Project +=== Συνεισφορά σε έργο -Now that our account is set up, let's walk through some details that could be useful in helping you contribute to an existing project. +Τώρα που ο λογαριασμός μας έχει ρυθμιστεί, ας δούμε κάποιες λεπτομέρειες που θα μπορούσαν να μας βοηθήσουν να συμβάλλουμε σε ένα υπάρχων έργο. -==== Forking Projects +==== Αποσχισμένα έργα -(((forking))) -If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project. -What this means is that GitHub will make a copy of the project that is entirely yours; it lives in your user's namespace, and you can push to it. +(((απόσχιση))) +Εάν θέλουμε να συνεισφέρουμε σε ένα υπάρχον έργο στο οποίο δεν έχουμε πρόσβαση ώθησης, μπορούμε να "`αποσχίσουμε`" (fork) το έργο. +Αυτό σημαίνει ότι το GitHub θα κάνει ένα αντίγραφο του έργου που είναι εξ ολοκλήρου δικό μας· ζει στον ονοματοχώρο του χρήστη που είμαστε και μπορούμε να ωθήσουμε σε αυτό. [NOTE] ==== -Historically, the term ``fork'' has been somewhat negative in context, meaning that someone took an open source project in a different direction, sometimes creating a competing project and splitting the contributors. -In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner. +Ιστορικά, ο όρος "`διχάλα`" (fork) είχε αρνητική χροιά, σήμαινε ότι κάποιος πήρε ένα έργο ανοιχτού κώδικα προς μια διαφορετική κατεύθυνση, δημιουργώντας μερικές φορές ένα ανταγωνιστικό έργο και χωρίζοντας τους συνεισφέροντες. +Στο GitHub, μία "`διχάλα`" (fork) είναι απλά το ίδιο έργο στον δικό μας ονοματοχώρο, που μας επιτρέπει να κάνουμε αλλαγές σε ένα έργο δημοσίως, δηλαδή να συμβάλλουμε με έναν πιο ανοιχτό τρόπο. ==== -This way, projects don’t have to worry about adding users as collaborators to give them push access. -People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next. -This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in. +Με αυτόν τον τρόπο, τα έργα δεν χρειάζεται να ανησυχούν για την προσθήκη χρηστών ως συνεργατών για να τους δώσουν πρόσβαση ώθησης. +Οι συνεργάτες μπορούν να αποσχίσουν ένα έργο, να ωθήσουν σε αυτό και να συμβάλουν τις αλλαγές τους στο αρχικό αποθετήριο δημιουργώντας κάτι που ονομάζεται _αίτημα έλξης_ (pull request), το οποίο θα καλύψουμε στη συνέχεια. +Το αίτημα έλξης ανοίγει ένα νήμα συζήτησης με αναθεώρηση κώδικα, στο οποίο ο ιδιοκτήτης και ο συνεισφέρων μπορούν στη συνέχεια να επικοινωνούν σχετικά με τις αλλαγές μέχρι ο ιδιοκτήτης να ικανοποιηθεί από αυτές, οπότε μπορεί να τις συγχωνεύσει (merge). -To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page. +Για να αποσχίσουμε ένα έργο, επισκεφτόμαστε τη σελίδα του έργου και κάνουμε κλικ στο κουμπί "`Fork`" στο πάνω δεξί μέρος της σελίδας. -.The ``Fork'' button. -image::images/forkbutton.png[The ``Fork'' button.] +.Το κουμπί "`Fork`" +image::images/forkbutton.png[Το κουμπί "`Fork`"] -After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code. +Μετά από λίγα δευτερόλεπτα, θα μεταφερθούμε στη νέα, δική μας σελίδα του έργου, με το δικό μας αντίγραφο του κώδικα στο οποίο έχουμε δικαίωμα επεξεργασίας. +[[r_ch06-github_flow]] +==== Η ροή εργασίας του GitHub -[[_github_flow]] -==== The GitHub Flow +(((GitHub, ροή))) +Το GitHub είναι σχεδιασμένο γύρω από μια συγκεκριμένη συνεργατική ροή εργασίας, με επίκεντρο τα αιτήματα έλξης. +Αυτή η ροή λειτουργεί είτε συνεργαζόμαστε με μια ομάδα με μεγάλη συνοχή σε ένα κοινό αποθετήριο, είτε με μια εταιρεία διασκορπισμένη σε όλο τον κόσμο, είτε ένα δίκτυο αγνώστων μεταξύ τους που συμβάλλουν σε ένα έργο μέσω δεκάδων διχαλών. +Στο επίκεντρό της έχει τη ροή εργασιών της ενότητας <> που καλύπτεται στο κεφάλαιο <>. -(((GitHub, Flow))) -GitHub is designed around a particular collaboration workflow, centered on Pull Requests. -This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. -It is centered on the <<_topic_branch>> workflow covered in <<_git_branching>>. +Ας δούμε πώς λειτουργεί γενικά: -Here's how it generally works: +1. Δημιουργούμε μια διχάλα (fork) του project +2. Δημιουργούμε έναν θεματικό κλάδο από τον κλάδο `master`. +3. Κάνουμε ορισμένες υποβολές ώστε αν βελτιώσουμε το έργο. +4. Ωθούμε αυτόν τον κλάδο στο έργο του GitHub. +5. Υποβάλλουμε ένα αίτημα έλξης στο GitHub. +6. Συζητάμε και, προαιρετικά, συνεχίζουμε να υποβάλλουμε. +7. Ο ιδιοκτήτης του έργου συγχωνεύει τον κλάδο ή κλείνει το αίτημα έλξης. +8. Συγχρονίζουμε το ενημερωμένο `master` πίσω στην διχάλα μας (fork). -1. Create a topic branch from `master`. -2. Make some commits to improve the project. -3. Push this branch to your GitHub project. -4. Open a Pull Request on GitHub. -5. Discuss, and optionally continue committing. -6. The project owner merges or closes the Pull Request. +Αυτή είναι βασικά η ροή εργασίας με διαχειριστή ενσωμάτωσης που καλύπτεται στην ενότητα <>, αλλά οι ομάδες, αντί να χρησιμοποιούν email για να επικοινωνούν και να αναθεωρούν τις αλλαγές, χρησιμοποιούν τα εργαλεία της ιστοσελίδας του GitHub. -This is basically the Integration Manager workflow covered in <<_integration_manager>>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. +Ας δούμε ένα παράδειγμα πρότασης αλλαγής σε ένα έργο ανοιχτού κώδικα, που φιλοξενείται στο GitHub χρησιμοποιώντας αυτήν τη ροή. -Let's walk through an example of proposing a change to an open source project hosted on GitHub using this flow. +[TIP] +==== +Μπορείτε να χρησιμοποιήσετε το επίσημο *GitHub CLI* εργαλείο αντί διαδικτυακής διασύνδεσης του GitHub, για τα περισσότερα πράγματα. +Το εργαλείο μπορεί να χρησιμοποιηθεί σε Windows, macOS, και Linux συστήματα. +Μεταβείτε στο https://cli.github.com/[GitHub CLI homepage^] για οδηγίες εγκατάστασεις και το εγχειρίδιο χρήσης. +==== -===== Creating a Pull Request +===== Δημιουργία αιτήματος έλξης -Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[]. +Ο Tony ψάχνει κώδικα για να τρέξει στον προγραμματιζόμενο μικροελεγκτή του, Arduino, και βρήκε ένα εξαιρετικό πρόγραμμα στο GitHub στη διεύθυνση https://github.com/schacon/blink[^]. -.The project we want to contribute to. -image::images/blink-01-start.png[The project we want to contribute to.] +.Το έργο στο οποίο θέλουμε να συμβάλλουμε +image::images/blink-01-start.png[Το έργο στο οποίο θέλουμε να συμβάλλουμε] -The only problem is that the blinking rate is too fast, we think it's much nicer to wait 3 seconds instead of 1 in between each state change. -So let's improve the program and submit it back to the project as a proposed change. +Το μόνο πρόβλημα είναι ότι ο ρυθμός με τον οποίο αναβοσβήνει το φωτάκι είναι πολύ γρήγορος. +Θεωρούμε ότι θα ήταν πολύ καλύτερα αν περιμένε 3 δευτερόλεπτα αντί για 1 μεταξύ κάθε αλλαγής κατάστασης. +Ας βελτιώσουμε λοιπόν το πρόγραμμα και ας υποβάλουμε τη βελτίωση στο έργο ως μια προτεινόμενη αλλαγή. -First, we click the 'Fork' button as mentioned earlier to get our own copy of the project. -Our user name here is ``tonychacon'' so our copy of this project is at `https://github.com/tonychacon/blink` and that's where we can edit it. -We will clone it locally, create a topic branch, make the code change and finally push that change back up to GitHub. +Πρώτα, κάνουμε κλικ στο κουμπί 'Fork', όπως αναφέρθηκε προηγουμένως, για να λάβουμε το δικό μας αντίγραφο του έργου. +Το όνομα χρήστη εδώ είναι "`tonychacon`", οπότε το αντίγραφο αυτού του έργου είναι στη διεύθυνση `https://github.com/tonychacon/blink` και εκεί μπορούμε να το επεξεργαστούμε. +Θα το κλωνοποιήσουμε τοπικά, θα δημιουργήσουμε έναν θεματικό κλάδο, θα κάνουμε αλλαγές στον κώδικα και τέλος θα ωθήσουμε αυτήν την αλλαγή πίσω στο GitHub. [source,console] ---- @@ -70,7 +79,9 @@ $ cd blink $ git checkout -b slow-blink <2> Switched to a new branch 'slow-blink' -$ sed -i '' 's/1000/3000/' blink.ino <3> +$ sed -i '' 's/1000/3000/' blink.ino (macOS) <3> +# If you're on a Linux system, do this instead: +# $ sed -i 's/1000/3000/' blink.ino <3> $ git diff --word-diff <4> diff --git a/blink.ino b/blink.ino @@ -86,8 +97,8 @@ void loop() { [-delay(1000);-]{+delay(3000);+} // wait for a second } -$ git commit -a -m 'three seconds is better' <5> -[slow-blink 5ca509d] three seconds is better +$ git commit -a -m 'Change delay to 3 seconds' <5> +[slow-blink 5ca509d] Change delay to 3 seconds 1 file changed, 2 insertions(+), 2 deletions(-) $ git push origin slow-blink <6> @@ -102,107 +113,135 @@ To https://github.com/tonychacon/blink * [new branch] slow-blink -> slow-blink ---- -<1> Clone our fork of the project locally -<2> Create a descriptive topic branch -<3> Make our change to the code -<4> Check that the change is good -<5> Commit our change to the topic branch -<6> Push our new topic branch back up to our GitHub fork +<1> Κλωνοποιούμε τη διχάλα του έργου σε τοπικό επίπεδο +<2> Δημιουργούμε έναν περιγραφικό θεματικό κλάδο +<3> Κάνουμε την αλλαγή που θέλουμε στον κώδικα +<4> Ελέγχουμε ότι η αλλαγή είναι καλή +<5> Υποβάλλουμε την αλλαγή στον θεματικό κλάδο +<6> Ωθούμε τον νέο θεματικό κλάδο στη διχάλα μας (fork) στο GitHub -Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and present us with a big green button to check out our changes and open a Pull Request to the original project. +Τώρα, αν επιστρέψουμε στη διχάλα μας στο GitHub, μπορούμε να δούμε πως το GitHub παρατήρησε ότι ωθήσαμε έναν νέο θεματικό κλάδο και μας εμφανίζει ένα μεγάλο πράσινο κουμπί για να κάνουμε checkout τις αλλαγές μας και να υποβάλουμε ένα αίτημα έλξης στο αρχικό έργο. -You can alternatively go to the ``Branches'' page at `https://github.com///branches` to locate your branch and open a new Pull Request from there. +Εναλλακτικά, μπορούμε να μεταβούμε στη σελίδα "`Branches`" στη διεύθυνση `\https://github.com///branches` για να εντοπίσουμε τον κλάδο μας και να υποβάλουμε ένα νέο αίτημα έλξης από εκεί. -.Pull Request button -image::images/blink-02-pr.png[Pull Request button] +.Κουμπί Pull request. +image::images/blink-02-pr.png[Κουμπί Pull request.] -(((GitHub, pull requests))) -If we click that green button, we'll see a screen that allows us to create a title and description for the change we would like to request so the project owner has a good reason to consider it. It is generally a good idea to spend some effort making this description as useful as possible so the author knows why this is being suggested and why it would be a valuable change for them to accept. +(((GitHub, αιτήματα έλξης))) +Αν κάνουμε κλικ σε αυτό το πράσινο κουμπί, θα δούμε μια οθόνη που μας επιτρέπει να δημιουργήσουμε έναν τίτλο και μια περιγραφή για την αλλαγή που αιτούμαστε, ώστε ο ιδιοκτήτης του έργου να έχει κάποιον καλό λόγο να την εξετάσει. +Είναι γενικά καλή ιδέα να καταβάλλουμε λίγη προσπάθεια ώστε να καταστήσουμε αυτήν την περιγραφή όσο το δυνατόν πιο χρήσιμη, ώστε ο συντάκτης να γνωρίζει γιατί προτείνεται αυτή η αλλαγή και γιατί θα πρέπει να την αποδεχτεί. -We also see a list of the commits in our topic branch that are ``ahead'' of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner. +Επίσης, βλέπουμε μια λίστα των υποβολών μας στον θεματικό κλάδο μας που "`προηγείται`" του κλάδου `master` (στην περίπτωση αυτή, μόνο κατά μία υποβολή) και ένα ενοποιημένο diff όλων των αλλαγών που θα γίνουν σε περίπτωση που αυτός ο κλάδος συγχωνευτεί από τον ιδιοκτήτη του έργου. -.Pull Request creation page -image::images/blink-03-pull-request-open.png[Pull Request creation] +.Σελίδα δημιουργίας αιτήματος έλξης. +image::images/blink-03-pull-request-open.png[Σελίδα δημιουργίας αιτήματος έλξης] -When you hit the 'Create pull request' button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it. +Όταν πατήσουμε το κουμπί 'Create pull request' σε αυτήν την οθόνη, ο ιδιοκτήτης του έργου, από το οποίο αποσχιστήκαμε, θα λάβει ειδοποίηση ότι κάποιος προτείνει μια αλλαγή και θα συνδεθεί σε μια σελίδα που περιέχει όλες αυτές τις πληροφορίες. [NOTE] ==== -Though Pull Requests are used commonly for public projects like this when the contributor has a complete change ready to be made, it's also often used in internal projects _at the beginning_ of the development cycle. Since you can keep pushing to the topic branch even *after* the Pull Request is opened, it's often opened early and used as a way to iterate on work as a team within a context, rather than opened at the very end of the process. +Παρόλο που τα αιτήματα έλξης χρησιμοποιούνται συνήθως για δημόσια έργα όπως αυτό, στο οποίο ο συνεισφέρων έχει μια πλήρη αλλαγή έτοιμη προς υλοποίηση, επίσης συχνά χρησιμοποιείται σε ιδιωτικά έργα _στην αρχή_ του κύκλου ανάπτυξης. +Επειδή μπορούμε να συνεχίσουμε να ωθούμε στον θεματικό κλάδο *ακόμα και μετά* την υποβολή του αιτήματος έλξης, η υποβολή του αιτήματος έλξης δεν γίνεται στο τέλος της διαδικασίας, αλλά νωρίς και αποτελεί έναν τρόπο σταδιακής βελτίωσης της εργασίας με συνεισφορές από όλη την ομάδα. ==== -===== Iterating on a Pull Request +===== Επανάληψη αιτήματος έλξης -At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on. +Σε αυτό το σημείο, ο ιδιοκτήτης του έργου μπορεί να εξετάσει την προτεινόμενη αλλαγή και να τη συγχωνεύσει, να την απορρίψει ή να τη σχολιάσει. +Ας πούμε ότι του αρέσει η ιδέα, αλλά θα προτιμούσε το φως να είναι σβησμένο για περισσότερο χρόνο από όσο είναι αναμμένο. -Where this conversation may take place over email in the workflows presented in <<_distributed_git>>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines. +Ενώ αυτή η συζήτηση πραγματοποιείται μέσω email στις ροές εργασίας που παρουσιάζονται στην ενότητα <>, στο GitHub αυτό συμβαίνει στο διαδίκτυο. +Ο ιδιοκτήτης του έργου μπορεί να ελέγξει το ενοποιημένο diff και να αφήσει ένα σχόλιο κάνοντας κλικ σε οποιαδήποτε από τις γραμμές. -.Comment on a specific line of code in a Pull Request -image::images/blink-04-pr-comment.png[PR line comment] +.Σχόλιο σε οποιαδήποτε γραμμή του κώδικα σε αίτημα έλξης. +image::images/blink-04-pr-comment.png[Σχόλιο σε γραμμή κατά το αίτημα έλξης] -Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this: +Μόλις ο διαχειριστής κάνει αυτό το σχόλιο, ο χρήστης που υπέβαλε το αίτημα έλξης (όπως και οποιοσδήποτε άλλος παρακολουθεί το αποθετήριο) θα λάβει μια ειδοποίηση. +Θα δούμε πώς αυτό είναι δυνατό να προσωποποιηθεί αργότερα, αλλά εάν είχε ενεργοποιημένες τις ειδοποιήσεις μέσω email, ο Tony θα λάμβανε ένα μήνυμα όπως αυτό: -[[_email_notification]] -.Comments sent as email notifications -image::images/blink-04-email.png[Email notification] +[[r_email_notification]] +.Σχόλια που στέλνονται ως email. +image::images/blink-04-email.png[Σχόλια που στέλνονται ως email] -Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well. +Οποιοσδήποτε μπορεί να αφήσει γενικά σχόλια σχετικά με το αίτημα έλξης. +Στην εικόνα <> μπορούμε να δούμε ένα παράδειγμα ενός ιδιοκτήτη έργου που σχολιάζει μια γραμμή κώδικα και στη συνέχεια αφήνει ένα γενικό σχόλιο στο τμήμα συζήτησης. +Μπορούμε να δούμε ότι τα σχόλια του κώδικα συμπεριλαμβάνονται και στη συνομιλία. -[[_pr_discussion]] -.Pull Request discussion page -image::images/blink-05-general-comment.png[PR discussion page] +[[r_pr_discussion]] +.Σελίδα συζήτησης αιτήματος +image::images/blink-05-general-comment.png[Σελίδα συζήτησης αιτήματος] -Now the contributor can see what they need to do in order to get their change accepted. Luckily this is also a very simple thing to do. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push. +Τώρα ο συνεισφέρων μπορεί να δει τι πρέπει να κάνει για να γίνει αποδεκτή η αλλαγή του. +Ευτυχώς αυτό είναι επίσης πολύ απλό. +Ενώ μέσω ηλεκτρονικού ταχυδρομείου θα χρειαζόταν να αναιρέσουμε τη σειρά αλλαγών και να την υποβάλουμε εκ νέου στην ηλεκτρονική λίστα αλληλογραφίας, με το GitHub απλά ξαναϋποβάλουμε (commit) τον θεματικό κλάδο και τον ξαναωθούμε (push). Αυτό θα ενημερώσει αυτόματα το αίτημα έλξης. +Στην εικόνα <>, βλέπουμε επίσης ότι το παλιό σχόλιο έχει συμπτυχθεί στο ενημερωμένο αίτημα έλξης, διότι είχε γίνει για μία γραμμή που πλέον έχει τροποποιηθεί. -If the contributor does that then the project owner will get notified again and when they visit the page they will see that it's been addressed. In fact, since a line of code changed that had a comment on it, GitHub notices that and collapses the outdated diff. +Προσθήκη υποβολών σε ένα ήδη υπάρχων αίτημα έλξης δεν στέλνει ειδοποίηση, οπότε όταν ο Tony ωθήσει τις διορθώσεις θα επιλέξει να αφήσει ένα σχόλιο για να ενημερώσει τον ιδιοκτήτη έργου ότι έκανε τις αλλάγες που του είχαν ζητηθεί. -[[_pr_final]] -.Pull Request final -image::images/blink-06-final.png[PR final] +[[r_pr_final]] +.Τελικό αίτημα έλξης +image::images/blink-06-final.png[Τελικό αίτημα έλξης] -An interesting thing to notice is that if you click on the ``Files Changed'' tab on this Pull Request, you'll get the ``unified'' diff -- that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In `git diff` terms, it basically automatically shows you `git diff master...` for the branch this Pull Request is based on. See <<_what_is_introduced>> for more about this type of diff. +Κάτι ενδιαφέρον, που πρέπει να παρατηρήσουμε, είναι ότι αν κάνουμε κλικ στην καρτέλα "`Files Changed`" σε αυτό το αίτημα έλξης, θα πάρουμε την "`uniενοποιημένηfied`" diff —δηλαδή, τη συνολική αθροιστικά διαφορά που θα εισαγόταν στον κύριο κλάδο αν αυτός ο θεματικός κλάδος συγχωνευόταν. +Με όρους `git diff`, ουσιαστικά μας δείχνει αυτόματα `git diff master...<κλάδος>` για τον κλάδο στον οποίο βασίζεται αυτό το αίτημα έλξης. +Περισσότερες πληροφορίες σχετικά με αυτό το είδος diff υπάρχουν στην ενότητα <>. -The other thing you'll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a ``non-fast-forward'' merge, meaning that even if the merge *could* be a fast-forward, it will still create a merge commit. +Το άλλο που πρέπει να παρατηρήσουμε είναι ότι το GitHub ελέγχει εάν το αίτημα έλξης συγχωνεύεται χωρίς συγκρούσεις και σε αυτήν την περίπτωση μας παρέχει ένα κουμπί για να κάνουμε τη συγχώνευση στον διακομιστή. +Αυτό το κουμπί εμφανίζεται μόνο αν έχουμε πρόσβαση εγγραφής στο αποθετήριο και αν είναι δυνατή μια τετριμμένη συγχώνευση. +Εάν κάνουμε κλικ σ' αυτό το κουμπί, το GitHub θα εκτελέσει μια συγχώνευση "`non-fast-forward`", κάτι που σημαίνει ότι ακόμα και αν η συγχώνευση *θα μπορούσε* να είναι ταχυπροώθηση, θα δημιουργήσει μια υποβολή συγχώνευσης. -If you would prefer, you can simply pull the branch down and merge it locally. If you merge this branch into the `master` branch and push it to GitHub, the Pull Request will automatically be closed. +Αν προτιμάμε, μπορούμε απλά να έλξουμε τον κλάδο μας στον υπολογιστή μας και τον συγχωνεύσουμε τοπικά. +Εάν συγχωνεύσουμε αυτόν τον κλάδο στον κλάδο `master` και τον ωθήσουμε στο GitHub, το αίτημα έλξης θα κλείσει αυτόματα. -This is the basic workflow that most GitHub projects use. Topic branches are created, Pull Requests are opened on them, a discussion ensues, possibly more work is done on the branch and eventually the request is either closed or merged. +Αυτή είναι η βασική ροή εργασίας που χρησιμοποιούν τα περισσότερα έργα του GitHub. +Δημιουργούνται θεματικοί κλάδοι, υποβάλλονται αιτήματα έλξης, ακολουθεί συζήτηση, ενδεχομένως γίνεται επιπλέον δουλειά στον κλάδο και τελικά το αίτημα είτε κλείνει είτε συγχωνεύεται. [NOTE] -.Not Only Forks +.Όχι μόνον απόσχιση ==== -It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking necessary. +Είναι σημαντικό να σημειώσουμε ότι μπορούμε επίσης να ανοίξουμε ένα αίτημα έλξης μεταξύ δύο κλάδων στο ίδιο αποθετήριο. +Εάν εργαζόμαστε σε ένα χαρακτηριστικό με κάποιον και έχουμε και οι δύο πρόσβαση για εγγραφή στο έργο, μπορούμε να ωθήσουμε έναν θεματικό κλάδο στο αποθετήριο και να υποβάλουμε ένα αίτημα έλξης του από τον κλάδο `master` του ίδιου έργου, ώστε να ξεκινήσει η αναθεώρηση κώδικα και η διαδικασία συζήτησης. +Η απόσχιση δεν είναι απαραίτητη. ==== -==== Advanced Pull Requests +==== Προχωρημένα αιτήματα έλξης -Now that we've covered the basics of contributing to a project on GitHub, let's cover a few interesting tips and tricks about Pull Requests so you can be more effective in using them. +Τώρα που καλύψαμε τα βασικά στοιχεία της συνεισφοράς σε ένα έργο στο GitHub, ας καλύψουμε μερικές ενδιαφέρουσες συμβουλές και κόλπα σχετικά με τα αιτήματα έλξης, ώστε να τα χρησιμοποιούμε αποτελεσματικότερα. -===== Pull Requests as Patches +===== Αιτήματα έλξης ως επιθέματα -It's important to understand that many projects don't really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging. +Είναι σημαντικό να καταλάβουμε ότι πολλά έργα, όσον αφορά στα αιτήματα έλξης, δεν βλέπουν ουρές τέλειων επιθεμάτων που πρέπει να εφαρμόζονται χωρίς συγκρούσεις το ένα μετά το άλλο, αντίθετα με τα περισσότερα έργα που βασίζονται σε ηλεκτρονική λίστα αλληλογραφίας, που βλέπουν _συνεισφορές_ από σειρές επιθεμάτων. +Τα περισσότερα έργα του GitHub σκέφτονται τους κλάδους αιτημάτων έλξης ως επαναληπτικές συνομιλίες γύρω από μια προτεινόμενη αλλαγή, με αποκορύφωμα μια ενοποιημένη diff που εφαρμόζεται με τη συγχώνευση. -This is an important distinction, because generally the change is suggested before the code is thought to be perfect, which is far more rare with mailing list based patch series contributions. This enables an earlier conversation with the maintainers so that arriving at the proper solution is more of a community effort. When code is proposed with a Pull Request and the maintainers or community suggest a change, the patch series is generally not re-rolled, but instead the difference is pushed as a new commit to the branch, moving the conversation forward with the context of the previous work intact. +Αυτή είναι μια σημαντική διάκριση, διότι γενικά η αλλαγή προτείνεται προτού ο κώδικας θεωρηθεί τέλειος, κάτι που είναι πολύ σπάνιο με τις συνεισφορές σειρών επιθεμάτων με βάση ηλεκτρονικές λίστες αλληλογραφίας. +Αυτό επιτρέπει μια προηγούμενη συζήτηση με τους διαχειριστές συνεπώς η επίτευξη της σωστής λύσης είναι κατά μείζοντα λόγο μια συλλογική προσπάθεια της κοινότητας. +Όταν ο κώδικας προτείνεται με ένα αίτημα έλξης και οι διαχειριστές ή η κοινότητα προτείνουν μια αλλαγή, η σειρά των επιθεμάτων γενικά δεν επαναφέρεται· αντίθετα η διαφορά ωθείται ως νέα υποβολή στον κλάδο, προχωρώντας τη συζήτηση και αφήνοντας το υπόλοιπο πλαίσιο άθικτο. -For instance, if you go back and look again at <<_pr_final>>, you'll notice that the contributor did not rebase his commit and send another Pull Request. Instead they added new commits and pushed them to the existing branch. This way if you go back and look at this Pull Request in the future, you can easily find all of the context of why decisions were made. Pushing the ``Merge'' button on the site purposefully creates a merge commit that references the Pull Request so that it's easy to go back and research the original conversation if necessary. +Για παράδειγμα, αν δούμε ξανά την εικόνα <>, θα παρατηρήσουμε ότι ο συνεισφέρων δεν άλλαξε τη βάση της υποβολής του και έστειλε άλλο αίτημα έλξης. +Αντίθετα, πρόσθεσε νέες υποβολές και τις ώθησε στον υφιστάμενο κλάδο. +Με αυτόν τον τρόπο, αν επανέλθουμε και εξετάσουμε αυτό το αίτημα έλξης στο μέλλον, μπορούμε εύκολα να βρούμε όλο το πλαίσιο όσον αφορά στο γιατί λήφθησαν οι συγκεκριμένες αποφάσεις. +Πατώντας το κουμπί "`Merge`" δημιουργεί σκόπιμα μια υποβολή συγχώνευσης που αναφέρεται στο αίτημα έλξης, έτσι ώστε να είναι εύκολο να επιστρέψουμε και να διερευνήσουμε την αρχική συνομιλία, εφόσον χρειαστεί κάτι τέτοιο. -===== Keeping up with Upstream +===== Συμβαδίζοντας με το upstream -If your Pull Request becomes out of date or otherwise doesn't merge cleanly, you will want to fix it so the maintainer can easily merge it. GitHub will test this for you and let you know at the bottom of every Pull Request if the merge is trivial or not. +Αν το αίτημα έλξης δεν είναι ενημερωμένο ή δεν συγχωνεύεται χωρίς συγκρούσεις για κάποιον άλλο λόγο, θα χρειαστεί να το διορθώσουμε, έτσι ώστε ο διαχειριστής να μπορεί να το συγχωνεύσει εύκολα. +Το GitHub θα το προσπαθήσει και θα μας ενημερώσει στο κάτω μέρος κάθε αιτήματος έλξης εάν η συγχώνευση είναι τετριμμένη ή όχι. -[[_pr_fail]] -.Pull Request does not merge cleanly -image::images/pr-01-fail.png[PR merge failure] +[[r_pr_fail]] +.Αποτυχία συγχώνευσης αιτήματος έλξης +image::images/pr-01-fail.png[Αποτυχία συγχώνευσης αιτήματος έλξης.] -If you see something like <<_pr_fail>>, you'll want to fix your branch so that it turns green and the maintainer doesn't have to do extra work. +Εάν δούμε κάτι σαν την εικόνα <>, θα χρειαστεί να διορθώσουμε τον κλάδο μας έτσι ώστε ο κλάδος να γίνει πράσινος και ο διαχειριστής να μην χρειάζεται να κάνει επιπρόσθετη εργασία. -You have two main options in order to do this. You can either rebase your branch on top of whatever the target branch is (normally the `master` branch of the repository you forked), or you can merge the target branch into your branch. +Για να το κάνουμε αυτό, έχουμε δύο βασικές. +Μπορούμε είτε να αλλάξουμε τη βάση (rebase) του κλάδου μας πάνω στον κλάδο-προορισμό, όποιος κι αν είναι αυτός (συνήθως ο κλάδος `master` του αποθετηρίου μας) είτε μπορούμε να συγχωνεύσουμε (merge) τον κλάδο-προορισμό στον κλάδο μας. -Most developers on GitHub will choose to do the latter, for the same reasons we just went over in the previous section. What matters is the history and the final merge, so rebasing isn't getting you much other than a slightly cleaner history and in return is *far* more difficult and error prone. +Οι περισσότεροι προγραμματιστές στο GitHub θα επιλέξουν να κάνουν το τελευταίο, για τους ίδιους λόγους που αναφέραμε στην προηγούμενη ενότητα. +Αυτό που έχει σημασία είναι το ιστορικό και η τελική συγχώνευση, συνεπώς η αλλαγή βάσης (rebase), αν και είναι *πολύ* πιο δύσκολη και επιρρεπής σε σφάλματα, δεν μας προσφέρει τίποτα άλλο παρεκτός ένα ελαφρώς καθαρότερο ιστορικό. -If you want to merge in the target branch to make your Pull Request mergeable, you would add the original repository as a new remote, fetch from it, merge the main branch of that repository into your topic branch, fix any issues and finally push it back up to the same branch you opened the Pull Request on. +Εάν θέλουμε να συγχωνεύσουμε (merge) τον κλάδο-προορισμό, ώστε να καταστήσουμε το αίτημα έλξης συγχωνεύσιμο, θα προσθέσουμε το αρχικό αποθετήριο ως νέο απομακρυσμένο, θα το παραλάβουμε (fetch), θα συγχωνεύσουμε τον κύριο κλάδο αυτού του αποθετηρίου στον θεματικό κλάδο μας, θα διορθώσουμε τυχόν προβλήματα και τελικά θα τον ωθήσουμε στον ίδιο κλάδο στον οποίο ανοίξαμε το αίτημα έλξης. -For example, let's say that in the ``tonychacon'' example we were using before, the original author made a change that would create a conflict in the Pull Request. Let's go through those steps. +Για παράδειγμα, ας πούμε ότι στο παράδειγμα "`tonychacon`" που χρησιμοποιούσαμε πριν, ο αρχικός συγγραφέας έκανε μια αλλαγή που θα δημιουργούσε μια σύγκρουση στο αίτημα έλξης. +Ας δούμε αυτά τα βήματα. [source,console] ---- @@ -237,100 +276,124 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Add the original repository as a remote named ``upstream'' -<2> Fetch the newest work from that remote -<3> Merge the main branch into your topic branch -<4> Fix the conflict that occurred -<5> Push back up to the same topic branch +<1> Προσθέτουμε το αρχικό αποθετήριο ως απομακρυσμένο με όνομα `upstream` +<2> Λαμβάνουμε τη νεότερη έκδοση του απομακρυσμένου αποθετηρίου +<3> Συγχωνεύουμε τον κύριο κλάδο στον θεματικό κλάδο +<4> Διορθώνουμε τη σύγκρουση που συνέβη +<5> Ωθούμε ξανά στον ίδιο θεματικό κλάδο. -Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly. +Μόλις το κάνουμε αυτό, το αίτημα έλξης θα ενημερωθεί αυτόματα και θα επανελεγχθεί για να διαπιστωθεί εάν συγχωνεύεται καθαρά. -[[_pr_merge_fix]] -.Pull Request now merges cleanly -image::images/pr-02-merge-fix.png[PR fixed] +[[r_pr_merge_fix]] +.Το αίτημα έλξης τώρα συγχωνεύεται χωρίς συγκρούσεις +image::images/pr-02-merge-fix.png[Το αίτημα έλξης τώρα συγχωνεύεται χωρίς συγκρούσεις] -One of the great things about Git is that you can do that continuously. If you have a very long-running project, you can easily merge from the target branch over and over again and only have to deal with conflicts that have arisen since the last time that you merged, making the process very manageable. +Ένα από τα σπουδαία πράγματα σχετικά με το Git είναι ότι μπορούμε να το κάνουμε αυτό συνεχώς. +Εάν έχουμε ένα πολύ μακρόβιο έργο, μπορούμε εύκολα να συγχωνεύουμε τον κλάδο-προορισμό ξανά και ξανά και να αντιμετωπίζουμε μόνον τις συγκρούσεις που έχουν προκύψει από την τελευταία φορά που συγχωνεύθήκαμε, κάνοντας τη διαδικασία πολύ διαχειρίσιμη. -If you absolutely wish to rebase the branch to clean it up, you can certainly do so, but it is highly encouraged to not force push over the branch that the Pull Request is already opened on. If other people have pulled it down and done more work on it, you run into all of the issues outlined in <<_rebase_peril>>. Instead, push the rebased branch to a new branch on GitHub and open a brand new Pull Request referencing the old one, then close the original. +Εάν θέλουμε οπωσδήποτε να αλλάξουμε τη βάση (rebase) του κλάδου για να τον καθαρίσουμε, μπορούμε σίγουρα να το κάνουμε, αλλά συνιστάται έντονα να μην εξαναγκάσουμε την ώθηση του κλάδου στον οποίο βασίζεται το αίτημα έλξης. +Εάν άλλοι συνεργάτες τον έχουν ελξει και κάνουν άλλη δουλειά σε αυτόν, θα συναντήσουμε σε όλα τα προβλήματα που περιγράφονται στην ενότητα <>. +Αντίθετα, συνιστάται να ωθήσουμε τον επανατοποθετημένο κλάδο σε έναν νέο κλάδο στο GitHub και να υποβάλλουμε ένα καινούργιο αίτημα έλξης αναφέροντας το παλιό και στη συνέχεια να κλείσουμε το αρχικό. -===== References +===== Αναφορές -Your next question may be ``How do I reference the old Pull Request?''. It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub. +Η επόμενη ερώτησή μας μπορεί να είναι "`Πώς μπορώ να αναφερθώ στο παλιό αίτημα έλξης;`". +Αποδεικνύεται ότι υπάρχουν πάρα πολλοί τρόποι να αναφερόμαστε σε άλλα πράγματα, σχεδόν οπουδήποτε μπορούμε να γράψουμε στο GitHub. -Let's start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can't have Pull Request #3 _and_ Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put `#` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#` to reference something in another repository. +Ας ξεκινήσουμε με το πώς μπορούμε να αναφερθούμε σε κάποιο άλλο ζήτημα (issue) ή αίτημα έλξης. +Σε όλα τα ζητήματα και τα αιτήματα έλξης έχουν εκχωρηθεί αριθμοί που είναι μοναδικοί στο πλαίσιο του έργου. +Για παράδειγμα, δεν μπορούμε να έχουμε Pull Request +#3+ και Issue +#3+. +Αν θέλουμε να αναφερθούμε σε οποιοδήποτε αίτημα έλξης ή ζήτημα από οποιοδήποτε άλλο, απλά να γράφουμε `+#<αρθ>+` σε οποιοδήποτε σχόλιο ή περιγραφή. +Μπορούμε επίσης να είμαστε πιο συγκεκριμένοι αν το αίτημα έλξης ή ζήτημα βρίσκεται κάπου αλλού· γράφουμε `username#<αρθ>` αν αναφερόμαστε σε ένα αίτημα έλξης ή ζήτημα σε μια διχάλα του αποθετηρίου στο οποίο βρισκόμαστε ή `username/repo#<αρθ>` για να αναφερθούμε σε κάτι που βρίσκεται σε άλλο αποθετήριο. -Let's look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <<_pr_references>>. +Ας δούμε ένα παράδειγμα. +Ας υποθέσουμε ότι αλλάξαμε τη βάση του κλάδου στο προηγούμενο παράδειγμα, δημιουργήσαμε ένα νέο αίτημα έλξης για αυτό και τώρα θέλουμε να αναφερθούμε στο παλιό αίτημα έλξης από το νέο. +Θέλουμε επίσης να αναφερθούμε σε ένα ζήτημα στη διχάλα του αποθετηρίου και ένα ζήτημα σε ένα εντελώς διαφορετικό έργο. +Μπορούμε να συμπληρώσουμε την περιγραφή ακριβώς όπως στην εικόνα <>. -[[_pr_references]] -.Cross references in a Pull Request. -image::images/mentions-01-syntax.png[PR references] +[[r_pr_references]] +.Αναφορές σε αιτήματα έλξης +image::images/mentions-01-syntax.png[Αναφορές σε αιτήματα έλξης.] -When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>. +Όταν υποβάλουμε αυτό το αίτημα έλξης, θα δούμε όλες οι αναφορές να εμφανίζονται όπως στην εικόνα <>. -[[_pr_references_render]] -.Cross references rendered in a Pull Request. -image::images/mentions-02-render.png[PR references rendered] +[[r_pr_references_render]] +.Εμφάνιση αναφορών σε αίτημα έλξης +image::images/mentions-02-render.png[Εμφάνιση αναφορών σε αίτημα έλξης.] -Notice that the full GitHub URL we put in there was shortened to just the information needed. +Παρατηρούμε ότι η πλήρης διεύθυνση URL του GitHub που βάλουμε εκεί συντομεύτηκε μόνο στις απαραίτητες πληροφορίες. -Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <<_pr_closed>>. +Τώρα, αν ο Tony επιστρέψει και κλείσει το αρχικό αίτημα έλξης, θα δούμε ότι επειδή το έχουμε αναφέρει στο νέο αίτημα, το GitHub δημιούργησε αυτόματα ένα συμβάν trackback στο χρονολόγιο του αιτήματος έλξης. +Αυτό σημαίνει ότι όποιος επισκέπτεται αυτό το αίτημα έλξης και βλέπει ότι είναι κλειστό, μπορεί εύκολα να συνδεθεί με εκείνο το αίτημα έλξης που το αντικατέστησε. +Ο σύνδεσμος θα μοιάζει με το <> -[[_pr_closed]] -.Cross references rendered in a Pull Request. -image::images/mentions-03-closed.png[PR closed] +[[r_pr_closed]] +.Εμφάνιση αναφορών σε κλειστό αίτημα έλξης. +image::images/mentions-03-closed.png[Εμφάνιση αναφορών σε κλειστό αίτημα έλξης.] -In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues. +Εκτός από τον αριθμό έκδοσης, μπορούμε επίσης να αναφερθούμε σε μια συγκεκριμένη υποβολή με τον αριθμό SHA-1. +Πρέπει να χρησιμοποιήσουμε και τους 40 χαρακτήρες του SHA-1, αλλά εάν το GitHub το δει σε ένα σχόλιο, θα συνδεθεί άμεσα με την υποβολή. +Επαναλαμβάνουμε ότι μπορούμε να αναφερθούμε σε υποβολές σε διχάλες ή άλλα αποθετήρια με τον ίδιο τρόπο που κάναμε με τα ζητήματα. -==== Markdown +==== Markdown με άρωμα GitHub -Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly. +Η σύνδεση με άλλα θέματα είναι μόνο ένα από τα πολλά ενδιαφέροντα πράγματα που μπορούμε να κάνουμε με σχεδόν οποιοδήποτε πλαίσιο κειμένου στο GitHub. +Στις περιγραφές των ζητημάτων και αιτημάτων έλξης, τα σχόλια, τα σχόλια κώδικα και πολλά άλλα, μπορούμε να χρησιμοποιήσουμε κάτι που ονομάζεται "`Markdown με άρωμα GitHub`" (GitHub flavored Markdown). +Η Markdown είναι σαν να γράφουμε απλό κείμενο, το οποίο όμως εμφανίζεται με πλούσια μορφοποίηση. -See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown. +Δείτε την εικόνα <> για ένα παράδειγμα του πώς μπορούν να γραφτούν σχόλια ή κείμενο και στη συνέχεια να αποδοθούν χρησιμοποιώντας την Markdown. -[[_example_markdown]] -.An example of Markdown as written and as rendered. -image::images/markdown-01-example.png[Example Markdown] +[[r_example_markdown]] +.Παράδειγμα της Markdown: γραφή και εμφάνιση +image::images/markdown-01-example.png[Παράδειγμα της Markdown: γραφή και εμφάνιση] -===== GitHub Flavored Markdown +Η Markdown με άρωμα GitHub προσθέτει περισσότερα πράγματα που μπορούμε να κάνουμε πέρα από τη βασική σύνταξη Markdown. +Όλα αυτά μπορούν να είναι πραγματικά χρήσιμα όταν δημιουργούμε αιτήματα έλξης, σχόλια ή περιγραφές. -The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. These can all be really useful when creating useful Pull Request or Issue comments or descriptions. +===== Λίστες καθηκόντων -====== Task Lists +Η πρώτη πραγματικά χρήσιμη λειτουργία της Markdown που υπάρχει μόνο στο GitHub, για να χρησιμοποιείται σε αιτήματα έλξης, είναι η λίστα εργασιών. +Μια λίστα εργασιών είναι μια λίστα κουτιών επιλογής για πράγματα, που θέλουμε να υλοποιηθούν. +Η τοποθέτησή τους σε ένα ζήτημα ή αίτημα έλξης συνήθως υποδεικνύει κάτι που θέλουμε να γίνει πριν να θεωρήσουμε ότι το στοιχείο αυτό έχει ολοκληρωθεί. -The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. A task list is a list of checkboxes of things you want to get done. Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete. +Μπορούμε να δημιουργήσουμε μια λίστα εργασιών όπως αυτή: -You can create a task list like this: - -[source] +[source,text] ---- - [X] Write the code - [ ] Write all the tests - [ ] Document the code ---- -If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_task_lists>> +Αν συμπεριλάβουμε αυτό στην περιγραφή ενός αιτήματος έλξης ή ενός ζητήματος μας, θα το δούμε να εμφανίζεται όπως στην εικόνα <>. -[[_task_lists]] -.Task lists rendered in a Markdown comment. -image::images/markdown-02-tasks.png[Example Task List] +[[r_eg_task_lists]] +.Λίστα καθηκόντων όπως εμφανίζεται σε σχόλιο Markdown. +image::images/markdown-02-tasks.png[Παράδειγμα λίστας καθηκόντων.] -This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off. +Αυτό χρησιμοποιείται συχνά στα αιτήματα έλξης για να υποδείξουμε τι θα επιθυμούσαμε να γίνει στον κλάδο πριν να συγχωνευτεί το αίτημα έλξης. +Το ωραίο είναι ότι μπορεί κανείς να κάνει κλικ στα πλαίσια ελέγχου για να ενημερώσει το σχόλιο —δεν χρειάζεται να επεξεργαστούμε άμεσα την Markdown για να τσεκάρουμε ή ξετσεκάρουμε αυτά τα καθήκοντα. -What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <<_task_list_progress>>. +Επιπλέον το GitHub ψάχνει για λίστες καθηκόντων στα ζητήματά μας και τα αιτήματα έλξης και θα τα δείξει ως μεταδεδομένα στις σελίδες που τα παραθέτουν. +Για παράδειγμα, εάν έχουμε ένα αίτημα έλξης με εργασίες και κοιτάζουμε τη σελίδα επισκόπησης όλων των αιτημάτων έλξης, μπορούμε να δούμε σε τι βαθμό έχουν υλοποιηθεί. +Αυτό βοηθά στην ανάλυση των αιτημάτων έλξης σε υποκαθήκοντα και βοηθά στην παρακολούθηση της προόδου του κλάδου από όλους. +Μπορούμε να δούμε ένα τέτοιο παράδειγμα στην εικόνα <> -[[_task_list_progress]] -.Task list summary in the Pull Request list. -image::images/markdown-03-task-summary.png[Example Task List] +[[r_task_list_progress]] +.περίληψη λίστας καθηκόντων σε αίτημα έλξης. +image::images/markdown-03-task-summary.png[Παράδειγμα λίστας καθηκόντων.] -These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature. +Κάτι τέτοιο είναι εξαιρετικά χρήσιμο όταν ανοίγουμε νωρίς ένα αίτημα έλξης, για να παρακολουθούμε την πρόοδο υλοποίησής του. -====== Code Snippets +===== Αποσπάσματα κώδικα -You can also add code snippets to comments. This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement. +Μπορούμε επίσης να προσθέσουμε αποσπάσματα κώδικα σε σχόλια. +Αυτό είναι ιδιαίτερα χρήσιμο εάν θέλουμε να παρουσιάσουμε κάτι που _θα μπορούσαμε_ να προσπαθήσουμε να κάνουμε, πριν το υλοποιήσουμε ως υποβολή στον κλάδο μας. +Χρησιμοποιείται συχνά και για την προσθήκη παραδειγμάτων κώδικα για το τι δεν λειτουργεί ή για το τι θα μπορούσε να υλοποιήσει αυτό το αίτημα έλξης. -To add a snippet of code you have to ``fence'' it in backticks. +Για να προσθέσουμε ένα κομμάτι κώδικα, πρέπει να το "`περικλείσουμε`" σε βαρείες. -[source] +[source,text] ---- ```java for(int i=0 ; i < 5 ; i++) @@ -340,19 +403,22 @@ for(int i=0 ; i < 5 ; i++) ``` ---- -If you add a language name like we did there with 'java', GitHub will also try to syntax highlight the snippet. In the case of the above example, it would end up rendering like <<_md_code>>. +Εάν προσθέσουμε ένα όνομα γλώσσας όπως κάναμε εκεί με τη λέξη 'java', το GitHub θα προσπαθήσει επίσης να επισημάνει συντακτικά το απόσπασμα. +Στην περίπτωση του παραπάνω παραδείγματος, θα καταλήξει σαν την εικόνα <> -[[_md_code]] -.Rendered fenced code example. -image::images/markdown-04-fenced-code.png[Rendered fenced code] +[[r_md_code]] +.Παράδειγμα απόδοσης κώδικα περικλεισμένου σε βαρείες. +image::images/markdown-04-fenced-code.png[Παράδειγμα απόδοσης κώδικα περικλεισμένου σε βαρείες.] -====== Quoting +===== Παράθεμα -If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you. +Εάν απαντάμε σε ένα μικρό κομμάτι ενός μακροσκελούς σχολίου, μπορούμε να κάνουμε επιλεκτική παράθεση από το άλλο σχόλιο ξεκινώντας τις γραμμές με τον χαρακτήρα `>`. +Στην πραγματικότητα, αυτό είναι τόσο σύνηθες και τόσο χρήσιμο ώστε υπάρχει συντόμευση πληκτρολογίου για αυτό. +Εάν επιλέξουμε κείμενο σε ένα σχόλιο στο οποίο θέλουμε να απαντήσουμε άμεσα και πατήσουμε το πλήκτρο `r`, θα παρατεθεί αυτό το κείμενο στο πλαίσιο σχολίων. -The quotes look something like this: +Τα παραθέματα μοιάζουν με το παρακάτω: -[source] +[source,text] ---- > Whether 'tis Nobler in the mind to suffer > The Slings and Arrows of outrageous Fortune, @@ -360,23 +426,26 @@ The quotes look something like this: How big are these slings and in particular, these arrows? ---- -Once rendered, the comment will look like <<_md_quote>>. +Μόλις αποδοθεί, το σχόλιο θα μοιάζει με την εικόνα <> -[[_md_quote]] -.Rendered quoting example. -image::images/markdown-05-quote.png[Rendered quoting] +[[r_md_quote]] +.Παράδειγμα απόδοσης παραθέματος. +image::images/markdown-05-quote.png[Απόδοση παραθέματος.] -====== Emoji +===== Emoji -Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for. +Τέλος, στα σχόλιά μας μπορούμε επίσης να χρησιμοποιήσουμε emoji. +Τα emoji χρησιμοποιούνται πραγματικά πολύ εκτενώς στα σχόλια που βλέπουμε σε πολλά ζητήματα και αιτήματα έλξης στο GitHub. +Μάλιστα, υπάρχει ένας βοηθός emoji στο GitHub. +Αν πληκτρολογούμε ένα σχόλιο και ξεκινάμε με ένα χαρακτήρα `:`, μία λίστα αυτόματης συμπλήρωσης θα μας βοηθήσει να βρούμε αυτό που ψάχνουμε. -[[_md_emoji_auto]] -.Emoji autocompleter in action. -image::images/markdown-06-emoji-complete.png[Emoji autocompleter] +[[r_md_emoji_auto]] +.Λίστα αυτόματης συμπλήρωσης emoji. +image::images/markdown-06-emoji-complete.png[Λίστα αυτόματης συμπλήρωσης emoji] -Emojis take the form of `::` anywhere in the comment. For instance, you could write something like this: +Τα emoji έχουν τη μορφή `:<όνομα>:` οπουδήποτε στο σχόλιο. Για παράδειγμα, θα μπορούσαμε να γράψουμε κάτι σαν αυτό: -[source] +[source,text] ---- I :eyes: that :bug: and I :cold_sweat:. @@ -387,28 +456,93 @@ I :eyes: that :bug: and I :cold_sweat:. :clap::tada::panda_face: ---- -When rendered, it would look something like <<_md_emoji>>. - -[[_md_emoji]] -.Heavy emoji commenting. -image::images/markdown-07-emoji.png[Emoji] +Αυτό θα εμφανιστεί όπως στην εικόνα <> -Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in. +[[r_md_emoji]] +.Σχολιασμός με πολλά emoji. +image::images/markdown-07-emoji.png[Emoji.] +Δεν είναι δα και ό,τι πιο χρήσιμο, αλλά είναι μία διασκεδαστική νότα και μέσο έκφρασης συναισθημάτων σε ένα μέσο στο οποίο είναι δύσκολη η μεταφορά συναισθημάτων με άλλον τρόπο. [NOTE] ==== -There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at: +Στην πραγματικότητα υπάρχουν αρκετές διαδικτυακές υπηρεσίες που κάνουν χρήση των χαρακτήρων emoji σήμερα. +Ένα εξαιρετικό σκονάκι για emoji υπάρχει στο: -http://www.emoji-cheat-sheet.com +https://www.webfx.com/tools/emoji-cheat-sheet/[^] ==== -====== Images +===== Εικόνες + +Το παρακάτω στην πραγματικότητα δεν είναι Markdown με άρωμα GitHub, αλλά είναι εξαιρετικά χρήσιμο. +Η προσθήκη συνδέσμων σε εικόνες μπορεί να είναι μπελάς, αφού η εύρεση και ενσωμάτωση των URL των εικόνων μπορεί να είναι δύσκολη. +Γι' αυτό, το GitHub μάς επιτρέπει να μεταφέρουμε και να ενσωματώσουμε εικόνες σε περιοχές κειμένου με μεταφορά-και-απόθεση. + +[[r_md_drag]] +.Μεταφορά-και-απόθεση εικόνων για μεταφόρτωσή και αυτόματη ενσωμάτωσή τους +image::images/markdown-08-drag-drop.png[Μεταφορά-και-απόθεση εικόνων.] + +Αν ανατρέξουμε στην εικόνα <>, μπορούμε να δούμε μια μικρή υπόδειξη "`Parsed as Markdown`" πάνω από την περιοχή κειμένου. +Κάνοντας κλικ σε αυτό θα μας δοθεί ένα πλήρες σκονάκι με ό,τι μπορούμε να κάνουμε με την Markdown στο GitHub. + +[[r_fetch_and_push_on_different_repositories]] +==== Διατήρησε το δημόσιο Github αποθετήριο ενημερωμένο -This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them. +Μόλις δημιουργήσουμε μια διχάλα ενός Github αποθετηρίου, το δικό μας αποθετήριο (η δικιά μας "διχάλα" (fork)) υπάρχει ανεξάρτητα από το αρχικό. +Συγκεκριμένα, μόλις το αρχικο αποθετήριο έχει νέες υποβολές, το Github μας ενημερώνει με ένα μήνυμα: + +[source,text] +---- +This branch is 5 commits behind progit:master. +---- + +Αλλά το δικό μας Github αποθετήριο ποτέ δεν θα ενημερωθεί αυτόματα από το Github, αυτό είναι κάτι που πρέπει να κάνουμε μόνοι μας. +Ευτυχώς, αυτό είναι πολύ εύκολο να γίνει. + +Μια πιθανότητα για να γίνει αυτό δεν απαιτεί καμία ρύθμιση. +Για παράδειγμα, αν έχουμε δημιουργήσει μια διχάλα από το `https://github.com/progit/progit2.git`, τότε μπορούμε να κρατήσουμε το `master` κλάδο ενημερωμένο ως εξής: + +[source,console] +---- +$ git checkout master <1> +$ git pull https://github.com/progit/progit2.git <2> +$ git push origin master <3> +---- + +<1> Αν βρισκόμασταν σε άλλο κλάδο, γυρνάμε στο `master`. +<2> Λαμβάνουμε τις αλλαγές από το `https://github.com/progit/progit2.git` και τις συγχωνεύουμε στο `master`. +<3> Ωθούμε το `master` κλάδο στο `origin`. + +Αυτό δουλεύει, αλλά είναι λίγο κουραστικό να πρέπει να γράφουμε το URL λήψης κάθε φορά. +Μπορούμε να αυτοματοποιήσουμε αυτή τη δουλειά με μερικές αλλαγές: + +[source,console] +---- +$ git remote add progit https://github.com/progit/progit2.git <1> +$ git fetch progit <2> +$ git branch --set-upstream-to=progit/master master <3> +$ git config --local remote.pushDefault origin <4> +---- + +<1> Προσθέτουμε το πηγαίο αποθετήριο και του δίνουμε ένα όνομα. + Εδώ, επιλέξαμε να το ονομάσουμε `progit`. +<2> Δημιουργούμε μια αναφορά στους κλάδους του progit, και συγκεκριμένα στο `master`. +<3> Θέτουμε το `master` κλάδο να λαμβάνει από το απομακρυσμένο `progit`. +<4> Ορίζουμε το προεπιλεγμένο αποθετήριο ώθησης σε `origin`. + +Μόλις το κάνουμε αυτό, η ροή εργασίας γίνετα πολύ πιο απλή: + +[source,console] +---- +$ git checkout master <1> +$ git pull <2> +$ git push <3> +---- -[[_md_drag]] -.Drag and drop images to upload them and auto-embed them. -image::images/markdown-08-drag-drop.png[Drag and drop images] +<1> Αν ήμασταν σε άλλο κλάδο, γυρνάμε στο `master`. +<2> Λαμβάνουμε αλλαγές από το `progit` και τις συγχωνεύουμε στο `master`. +<3> Ωθούμε το `master` κλάδο στο `origin`. -If you look back at <<_pr_references>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub. +Αυτή η προσέγγιση μπορεί να είναι χρήσιμη, αλλά δεν είναι χωρίς μειονεκτήματα. +Το Git θα κάνει ευχαρίστως αυτή την δουλειά για εμάς αΘόρυβα, αλλά δεν θα μας προειδοποιήσει αν κάνουμε μια υποβολή στο `master`, τραβήξουμε από το `progit`, μετά ωθήσουμε στο `origin` -- όλες αυτές οι λειτουργίες είναι έγκυρες με αυτό το στήσιμο. +Οπότε θα πρέπει να προσέχουμε ποτέ να μην υποβάλουμε απευθείας στο `master`, αφού αυτός ο κλάδος ουσιασικά ανήκει στο απομακρυσμένο αποθετήριο. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 9b967a2a0..46105faf4 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -1,134 +1,134 @@ -[[_maintaining_gh_project]] -=== Maintaining a Project +[[r_maintaining_gh_project]] +=== Συντήρηση ενός έργου -Now that we're comfortable contributing to a project, let's look at the other side: creating, maintaining and administering your own project. +Τώρα που έχουμε την αυτοπεποίθηση να συνεισφέρουμε σε ένα έργο, ας δούμε την άλλη πλευρά: τη δημιουργία, συντήρηση και διαχείριση του δικού μας έργου. -==== Creating a New Repository +==== Δημιουργία νέου αποθετηρίου -Let's create a new repository to share our project code with. -Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. +Ας δημιουργήσουμε ένα νέο αποθετήριο για να μοιραστούμε τον κώδικα του έργου μας. +Ξεκινάμε κάνοντας κλικ στο κουμπί ``New repository'' στη δεξιά πλευρά του ταμπλό ή στο κουμπί ``+'' στην επάνω γραμμή εργαλείων δίπλα στο όνομα χρήστη μας όπως φαίνεται στην εικόνα <>. -.The ``Your repositories'' area. -image::images/newrepo.png[The ``Your repositories'' area.] +.Η περιοχή ``Your repositories'' +image::images/newrepo.png[Η περιοχή ``Your repositories''.] -[[_new_repo_dropdown]] -.The ``New repository'' dropdown. -image::images/new-repo.png[The ``new repository'' dropdown.] +[[r_new_repo_dropdown]] +.Η αναπτυσσόμενη λίστα ``New repository''. +image::images/new-repo.png[Η αναπτυσσόμενη λίστα ``New repository''.] -This takes you to the ``new repository'' form: +Αυτό μας μεταφέρει στη φόρμα ``Νew repository'': -.The ``new repository'' form. -image::images/newrepoform.png[The ``new repository'' form.] +.Η φόρμα ``New repository''. +image::images/newrepoform.png[Η φόρμα ``New repository''.] -All you really have to do here is provide a project name; the rest of the fields are completely optional. -For now, just click the ``Create Repository'' button, and boom – you have a new repository on GitHub, named `/`. +Το μόνο που έχουμε να κάνουμε εδώ είναι να δώσουμε ένα όνομα έργου. Τα υπόλοιπα πεδία είναι εντελώς προαιρετικά. +Προς το παρόν, απλά κάνουμε κλικ στο κουμπί ``Create Repository'' και αμέσως έχουμε ένα νέο αποθετήριο στο GitHub, το οποίο ονομάζεται `<χρήστης>/<όνομα_έργου>`. -Since you have no code there yet, GitHub will show you instructions for how create a brand-new Git repository, or connect an existing Git project. -We won't belabor this here; if you need a refresher, check out <<_git_basics_chapter>>. +Εφόσον δεν έχουμε ακόμα κανένα κώδικα, το GitHub θα μας δείξει οδηγίες για τον τρόπο δημιουργίας ενός ολοκαίνουργιου αποθετηρίου Git ή τη σύνδεση ενός υπάρχοντος έργου Git. +Δεν θα εντρυφήσουμε εδώ· τα σχετικά υπάρχουν στο κεφάλαιο <>. -Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with. -Every project on GitHub is accessible over HTTP as `https://github.com//`, and over SSH as `git@github.com:/`. -Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them. +Τώρα που το έργο μας φιλοξενείται στο GitHub, μπορούμε να δώσουμε τη διεύθυνση URL σε οποιονδήποτε θέλουμε να μοιραστούμε το έργο μας. +Κάθε έργο στο GitHub είναι προσβάσιμο μέσω HTTP στη διεύθυνση `\https://github.com//`, και μέσω SSH ως `\git@github.com:/`. +Το Git μπορεί να ανακτήσει από και να ωθήσει προς και τις δύο αυτές διευθύνσεις URL, αλλά η πρόσβαση ταυτοποιείται με βάση τα διαπιστευτήρια του χρήστη που συνδέεται σε αυτές. [NOTE] ==== -It is often preferable to share the HTTP based URL for a public project, since the user does not have to have a GitHub account to access it for cloning. -Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL. -The HTTP one is also exactly the same URL they would paste into a browser to view the project there. +Συχνά είναι προτιμότερο να μοιραζόμαστε τη διεύθυνση URL μέσω HTTP για ένα δημόσιο έργο, καθώς ο χρήστης δεν χρειάζεται να έχει λογαριασμό στο GitHub ώστε να έχει πρόσβαση σε αυτόν για κλωνοποίηση. +Οι χρήστες θα πρέπει να έχουν λογαριασμό και μεταφορτωμένο κλειδί SSH για να αποκτήσουν πρόσβαση στο έργο μας, εφόσον τους δώσουμε τη διεύθυνση URL μέσω SSH. +Το HTTP είναι ακριβώς το ίδιο URL με αυτό που θα επικολλούσε κανείς σε ένα πρόγραμμα περιήγησης για να δει το έργο σε αυτό. ==== -==== Adding Collaborators +==== Προσθήκη συνεργατών -If you're working with other people who you want to give commit access to, you need to add them as ``collaborators''. -If Ben, Jeff, and Louise all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project. -Doing so will give them ``push'' access, which means they have both read and write access to the project and Git repository. +Εάν εργαζόμαστε με άλλα άτομα στα οποία θέλουμε να επιτρέψουμε την πρόσβαση, πρέπει να τα προσθέσουμε ως ``συνεργάτες'' (collaborators). +Αν ο Ben, ο Jeff και η Louise έχουν λογαριασμούς στο GitHub και θέλουμε να τους δώσουμε δικαίωμα ώθησης στο αποθετήριό μας, μπορούμε να τους προσθέσουμε στο έργο μας. +Κάτι τέτοιο θα τους δώσει πρόσβαση ώθησης, που σημαίνει ότι έχουν δικαίωμα τόσο ανάγνωσης όσο και εγγραφής στο έργο και στο αποθετήριο Git. -Click the ``Settings'' link at the bottom of the right-hand sidebar. +Κάνουμε κλικ στον σύνδεσμο ``Settings'' στο κάτω μέρος της δεξιάς πλευρικής μπάρας. -.The repository settings link. -image::images/reposettingslink.png[The repository settings link.] +.Ο σύνδεσμος ``Settings'' του αποθετηρίου. +image::images/reposettingslink.png[Ο σύνδεσμος ``Settings'' του αποθετηρίου.] -Then select ``Collaborators'' from the menu on the left-hand side. -Then, just type a username into the box, and click ``Add collaborator.'' -You can repeat this as many times as you like to grant access to everyone you like. -If you need to revoke access, just click the ``X'' on the right-hand side of their row. +Στη συνέχεια επιλέγουμε ``Collaborators'' από το μενού στα αριστερά. +Μετά πληκτρολογούμε ένα όνομα χρήστη στο πλαίσιο και κάνουμε κλικ στο κουμπί ``Add collaborator''. +Μπορούμε να επαναλάβουμε αυτήν τη διαδικασία όσες φορές θέλουμε ώστε να δώσουμε πρόσβαση σε όποιον θέλουμε. +Αν χρειαστεί να ανακαλέσουμε την πρόσβαση κάποιου χρήστη, απλά κάνουμεε κλικ στο ``×'' στα δεξιά της σειράς του. -.Repository collaborators. -image::images/collaborators.png[The repository collaborators box.] +.Το πλαίσιο με τους συνεργάτες του αποθετηρίου. +image::images/collaborators.png[Το πλαίσιο με τους συνεργάτες του αποθετηρίου.] -==== Managing Pull Requests +==== Διαχείριση αιτημάτων έλξης -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 Pull Request yourself. +Τώρα που έχουμε ένα έργο με κώδικα και ενδεχομένως μερικούς συνεργάτες που έχουν πρόσβαση ώθησης, ας δούμε τι πρέπει να κάνουμε όταν έχουμε ένα αίτημα έλξης. -Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. -The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch. +Τα αιτήματα έλξης προέρχεται είτε από έναν κλάδο σε μία διχάλα του αποθετηρίου μας είτε από άλλον κλάδο στο ίδιο αποθετήριο. +Η μόνη διαφορά είναι ότι τα αιτήματα έλξης από κλάδους που βρίσκονται σε διχάλα υποβάλλονται συχνά από χρήστες στων οποίων τους κλάδους δεν μπορούμε να ωθήσουμε όπως και αυτοί δεν μπορούν να ωθήσουν προς τους δικούς μας, ενώ με στα αιτήματα έλξης από το ίδιο αποθετήριο, γενικά και τα δύο μέρη έχουν πρόσβαση στον κλάδο. -For these examples, let's assume you are ``tonychacon'' and you've created a new Arduino code project named ``fade''. +Για αυτά τα παραδείγματα, ας υποθέσουμε ότι είμαστε ο `tonychacon` και έχουμε δημιουργήσει ένα νέο έργο με κώδικα Arduino που ονομάζεται `fade`. -[[_email_notifications]] -===== Email Notifications +[[r_email_notifications]] +===== Ειδοποιήσεις e-mail -Someone comes along and makes a change to your code and sends you a Pull Request. -You should get an email notifying you about the new Pull Request and it should look something like <<_email_pr>>. +Κάποιος κάνει μια αλλαγή στον κώδικά μας και μας στέλνει ένα αίτημα έλξης. +Θα πρέπει να λάβουμε ένα μήνυμα e-mail που μας ειδοποιεί για το νέο αίτημα έλξης που θα μοιάζει σαν αυτό της εικόνας <> -[[_email_pr]] -.Email notification of a new Pull Request. -image::images/maint-01-email.png[Pull Request email notification] +[[r_email_pr]] +.Ειδοποίηση email για νέο αίτημα έλξης. +image::images/maint-01-email.png[Ειδοποίηση email για νέο αίτημα έλξης.] -There are a few things to notice about this email. -It will give you a small diffstat -- a list of files that have changed in the Pull Request and by how much. -It gives you a link to the Pull Request on GitHub. -It also gives you a few URLs that you can use from the command line. +Σε αυτό το μήνυμα e-mail παρατηρούμε τα εξής. +Μας δίνει ένα μικρό diffstat —μια λίστα των αρχείων που έχουν αλλάξει στο αίτημα έλξης και κατά πόσο έχουν αλλάξει. +Mας δίνει ένα σύνδεσμο προς το αίτημα έλξης στο GitHub. +Mας δίνει επίσης μερικές διευθύνσεις URL που μπορούμε να χρησιμοποιήσουμε από τη γραμμή εντολών. -If you notice the line that says `git pull patch-1`, this is a simple way to merge in a remote branch without having to add a remote. -We went over this quickly in <<_checking_out_remotes>>. -If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes. +Η γραμμή που λέει `git pull patch-1`, είναι ένας απλός τρόπος για να συγχωνεύσουμε έναν απομακρυσμένο κλάδο χωρίς να χρειάζεται να προσθέσουμε ένα απομακρυσμένο αποθετήριο. +Αυτό το είδαμε εν συντομία στην ενότητα <>. +Αν θέλουμε, μπορούμε να δημιουργήσουμε έναν θεματικό κλάδο, να μεταβούμε σε αυτόν και στη συνέχεια να εκτελέσουμε αυτήν την εντολή για να συγχωνεύσουμε τις αλλαγές του αιτήματος έλξης. -The other interesting URLs are the `.diff` and `.patch` URLs, which as you may guess, provide unified diff and patch versions of the Pull Request. -You could technically merge in the Pull Request work with something like this: +Οι άλλες ενδιαφέρουσες διευθύνσεις URL είναι οι διευθύνσεις `.diff` και `.patch`, οι οποίες, όπως μπορεί να μαντέψει κανείς, παρέχουν ενοποιημένες εκδόσεις της diff και του επιθέματος του αιτήματος έλξης. +Θα μπορούσαμε να συγχωνεύσουμε την εργασία του αιτήματος έλξης με κάτι σαν αυτό: [source,console] ---- -$ curl http://github.com/tonychacon/fade/pull/1.patch | git am +$ curl https://github.com/tonychacon/fade/pull/1.patch | git am ---- -===== Collaborating on the Pull Request +===== Συνεργασία σε αίτημα έλξης -As we covered in <<_github_flow>>, you can now have a conversation with the person who opened the Pull Request. -You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere. +Όπως είδαμε στην ενότητα <>, μπορούμε να έχουμε μια συνομιλία με το άτομο που υπέβαλε το αίτημα έλξης. +Μπορούμε να σχολιάζουμε συγκεκριμένες γραμμές κώδικα, ολόκληρες υποβολές ακόμα και ολόκληρο το ίδιο το αίτημα έλξης, χρησιμοποιώντας τη Markdown με άρωμα GitHub. -Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. -They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread. +Κάθε φορά που κάποιος άλλος σχολιάζει το αίτημα έλξης, θα συνεχίσουμε να λαμβάνουμε ειδοποιήσεις μέσω e-mail, ώστε να γνωρίζουμε ότι υπάρχει τρέχουσα δραστηριότητα. +Το καθένα θα περιέχει έναν σύνδεσμο προς το αίτημα έλξης όπου συμβαίνει η δραστηριότητα και επίσης να απαντήσουμε άμεσα στο email για να σχολιάσουμε στο νήμα του αιτήματος έλξης. -.Responses to emails are included in the thread. -image::images/maint-03-email-resp.png[Email response] +.Οι απαντήσεις στα e-mails περιλαμβάνονται στο νήμα συζήτησης. +image::images/maint-03-email-resp.png[Απάντηση e-mail.] -Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull ` syntax we saw earlier, or by adding the fork as a remote and fetching and merging. +Μόλις ο κώδικας βρίσκεται σε μία κατάσταση που μας αρέσει και θέλουμε να τον συγχωνεύσουμε, μπορούμε είτε να έλξουμε τον κώδικα και να τον συγχωνεύσουμε τοπικά, είτε με τη σύνταξη `git pull <κλάδος>` που είδαμε προηγουμένως, είτε προσθέτοντας τη διχάλα ως απομακρυσμένο αποθετήριο και ανακτώντας και συγχωνεύοντας. -If the merge is trivial, you can also just hit the ``Merge'' button on the GitHub site. -This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. -This means that no matter what, every time you hit the merge button, a merge commit is created. -As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link. +Εάν η συγχώνευση είναι τετριμμένη, μπορούμε επίσης να πατήσουμε το κουμπί ``Merge'' στην τοποθεσία GitHub. +Αυτό θα κάνει μια συγχώνευση ``μη-ταχυπροώθησης'', δημιουργώντας μια υποβολή συγχώνευσης ακόμα και αν ήταν δυνατή μια συγχώνευση ταχυπροώθησης. +Αυτό σημαίνει ότι όπως και νά 'χει, κάθε φορά που πατάμε το κουμπί συγχώνευσης, δημιουργείται μια υποβολή συγχώνευσης. +Όπως μπορούμε να δούμε στην εικόνα <>, το GitHub μας δίνει όλες αυτές τις πληροφορίες εάν κάνουμε κλικ στον σύνδεσμο ``hint''. -[[_merge_button]] -.Merge button and instructions for merging a Pull Request manually. -image::images/maint-02-merge.png[Merge button] +[[r_merge_button]] +.Κουμπί ``Merge'' και οδηγίες για συγχώνευση αιτήματος έλξης +image::images/maint-02-merge.png[Κουμπί ``Merge'' και οδηγίες για συγχώνευση αιτήματος έλξης] -If you decide you don't want to merge it, you can also just close the Pull Request and the person who opened it will be notified. +Εάν αποφασίσουμε ότι δεν θέλουμε να συγχωνεύσουμε το αίτημα έλξης, μπορούμε επίσης να το κλείσουμε και το άτομο που το υπέβαλε θα ειδοποιηθεί. -[[_pr_refs]] -===== Pull Request Refs +[[r_pr_refs]] +===== Refs αιτημάτων έλξης -If you're dealing with a *lot* of Pull Requests and don't want to add a bunch of remotes or do one time pulls every time, there is a neat trick that GitHub allows you to do. -This is a bit of an advanced trick and we'll go over the details of this a bit more in <<_refspec>>, but it can be pretty useful. +Εάν έχουμε να κάνουμε με *πολλά* αιτήματα έλξης και δεν θέλουμε να προσθέσουμε πολλά απομακρυσμένα αποθετήρια ή να κάνουμε μία έλξη κάθε φορά, υπάρχει ένα ωραίο κόλπο που μας επιτρέπει να κάνουμε το GitHub. +Είναι λίγο προηγμένο τέχνασμα και θα δούμε τις λεπτομέρειές του σε μεγαλύτερο βάθος στην ενότητα <>, αλλά μπορεί να είναι αρκετά χρήσιμο. -GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. -By default you don't get them when you clone, but they are there in an obscured way and you can access them pretty easily. +Το GitHub δημοσιοποιεί τους κλάδους αιτημάτων έλξης ενός αποθετηρίου ως ένα είδος ψευδο-κλάδων στον διακομιστή. +Εκ προεπιλογής δεν τους λαμβάνουμε όταν κλωνοποιούμε ένα αποθετήριο, αλλά υπάρχουν σε αυτό με κάποιον ασαφή και ομιχλώδη τρόπο και μπορούμε να έχουμε αρκετά εύκολη πρόσβαση σε αυτούς. -To demonstrate this, we're going to use a low-level command (often referred to as a ``plumbing'' command, which we'll read about more in <<_plumbing_porcelain>>) called `ls-remote`. -This command is generally not used in day-to-day Git operations but it's useful to show us what references are present on the server. +Για να το δείξουμε αυτό, θα χρησιμοποιήσουμε μια εντολή χαμηλού επιπέδου (που συχνά αναφέρεται ως εντολή "`διοχέτευσης`" (plumbing), την `ls-remote`, για την οποία θα πούμε περισσότερα στην ενότητα <>). +Αυτή η εντολή γενικά δεν χρησιμοποιείται στις καθημερινές λειτουργίες του Git, αλλά μας χρησιμεύει να δούμε ποιες αναφορές υπάρχουν στον διακομιστή. -If we run this command against the ``blink'' repository we were using earlier, we will get a list of all the branches and tags and other references in the repository. +Αν εκτελέσουμε αυτήν την εντολή για το αποθετήριο "`blink`" που χρησιμοποιούσαμε νωρίτερα, θα έχουμε μια λίστα με όλους τους κλάδους, ετικέτες και άλλες αναφορές στο αποθετήριο. [source,console] ---- @@ -143,16 +143,16 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head 31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge ---- -Of course, if you're in your repository and you run `git ls-remote origin` or whatever remote you want to check, it will show you something similar to this. +Φυσικά, εάν βρισκόμαστε στο δικό μας αποθετήριο και εκτελέσουμε `git ls-remote origin` ή οποιοδήποτε απομακρυσμένο αποθετήριο θέλουμε να ελέγξουμε, θα μας δείξει κάτι παρόμοιο με αυτό. -If the repository is on GitHub and you have any Pull Requests that have been opened, you'll get these references that are prefixed with `refs/pull/`. -These are basically branches, but since they're not under `refs/heads/` you don't get them normally when you clone or fetch from the server -- the process of fetching ignores them normally. +Αν το αποθετήριο βρίσκεται στο GitHub και έχουμε υποβεβλημένα αίτηματα έλξης, θα λάβουμε αυτές τις αναφορές, με πρόθεμα `refs/pull/`. +Αυτές είναι ουσιαστικά κλάδοι, αλλά επειδή δεν βρίσκονται στον `refs/heads/`, δεν τις παίρνουμε όταν κλωνοποιούμε ή ανακτούμε από τον διακομιστή —κάτω από κανονικές συνθήκες η διαδικασία της ανάκτησης τούς αγνοεί. -There are two references per Pull Request - the one that ends in `/head` points to exactly the same commit as the last commit in the Pull Request branch. -So if someone opens a Pull Request in our repository and their branch is named `bug-fix` and it points to commit `a5a775`, then in *our* repository we will not have a `bug-fix` branch (since that's in their fork), but we _will_ have `pull//head` that points to `a5a775`. -This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes. +Υπάρχουν δύο αναφορές ανά αίτημα έλξης —αυτή που τελειώνει σε `/head` δείχνει στην ίδια ακριβώς υποβολή με την τελευταία υποβολή στον κλάδο του αιτήματος έλξης. +Έτσι, αν κάποιος υποβάλει ένα αίτημα έλξης στο αποθετήριό μας και ο κλάδος του ονομάζεται `bug-fix` και δείχνει στην υποβολή `a5a775`, τότε στο *δικό μας* αποθετήριο δεν θα έχουμε κλάδο `bug-fix ' (αφού αυτός βρίσκεται στη δική του διχάλα), αλλά θα έχουμε `pull/<αε#>/head` που δείχνει στην `a5a775`. +Αυτό σημαίνει ότι μπορούμε πολύ εύκολα να έλξουμε κάθε κλάδο ενός αιτήματος έλξης χωρίς να χρειαστεί να προσθέσουμε κάμποσα απομακρυσμένα αποθετήρια. -Now, you could do something like fetching the reference directly. +Τώρα, μπορούμε να ανακτήσουμε απευθείας την αναφορά. [source,console] ---- @@ -161,26 +161,28 @@ From https://github.com/libgit2/libgit2 * branch refs/pull/958/head -> FETCH_HEAD ---- -This tells Git, ``Connect to the `origin` remote, and download the ref named `refs/pull/958/head`.'' -Git happily obeys, and downloads everything you need to construct that ref, and puts a pointer to the commit you want under `.git/FETCH_HEAD`. -You can follow that up with `git merge FETCH_HEAD` into a branch you want to test it in, but that merge commit message looks a bit weird. -Also, if you're reviewing a *lot* of pull requests, this gets tedious. +Αυτό λέει στο Git, "`συνδέσου στο απομακρυσμένο αποθετήριο `origin` και κατέβασε το ref με όνομα `refs/pull/958/head`.`" +Το Git υπακούει και κατεβάζει ό,τι χρειαζόμαστε για να κατασκευάσουμε αυτό το ref και βάζει έναν δείκτη στην υποβολή που θέλουμε στο αρχείο `.git/FETCH_HEAD`. +Μπορούμε να τη συγχωνεύσουμε με την εντολή `git merge FETCH_HEAD` σε έναν κλάδο στον οποίο θέλουμε να το δοκιμάσουμε, αλλά αυτό το μήνυμα συγχώνευσης φαίνεται λίγο παράξενο. +Επίσης, εάν εξετάζουμε *πολλά* αιτήματα έλξης, κάτι τέτοιο γίνεται κουραστικό. -There's also a way to fetch _all_ of the pull requests, and keep them up to date whenever you connect to the remote. -Open up `.git/config` in your favorite editor, and look for the `origin` remote. -It should look a bit like this: +Υπάρχει επίσης ένας τρόπος για να ανακτήσουμε _όλα_ τα αιτήματα έλξης και να τα κρατάμε ενημερωμένα κάθε φορά που συνδεόμαστε στο απομακρυσμένο αποθετήριο. +Ανοίγουμε το `.git/config` στον αγαπημένο μας επεξεργαστή κειμένου και αναζητούμε το απομακρυσμένο αποθετήριο `origin`. +Θα πρέπει να μοιάζει κάπως έτσι: +[source,ini] ---- [remote "origin"] url = https://github.com/libgit2/libgit2 fetch = +refs/heads/*:refs/remotes/origin/* ---- -That line that begins with `fetch =` is a ``refspec.'' -It's a way of mapping names on the remote with names in your local `.git` directory. -This particular one tells Git, "the things on the remote that are under `refs/heads` should go in my local repository under `refs/remotes/origin`." -You can modify this section to add another refspec: +Αυτή η γραμμή που αρχίζει με `fetch =` είναι ένα "`refspec`" +Είναι ένας τρόπος απεικόνισης ονομάτων του απομακρυσμένου αποθετηρίου με ονόματα στον τοπικό μας κατάλογο `.git`. +Αυτό το συγκεκριμένο λέει στο Git, "τα πράγματα στο απομακρυσμένο αποθετήριο που βρίσκονται κάτω από το `refs/heads` θα πρέπει να πάνε στο τοπικό μου αποθετήριο κάτω από το `refs/remotes/origin`." +Μπορούμε να τροποποιήσουμε αυτό το τμήμα ώστε να προσθέσουμε ένα ακόμα refspec: +[source,ini] ---- [remote "origin"] url = https://github.com/libgit2/libgit2.git @@ -188,8 +190,8 @@ You can modify this section to add another refspec: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* ---- -That last line tells Git, ``All the refs that look like `refs/pull/123/head` should be stored locally like `refs/remotes/origin/pr/123`.'' -Now, if you save that file, and do a `git fetch`: +Αυτή η τελευταία γραμμή λέει στο Git, "`Όλα τα refs που μοιάζουν με το `refs/pull/123/head` θα πρέπει να αποθηκεύονται τοπικά όπως το `refs/remotes/origin/pr/123`.`" +Τώρα αν αποθηκεύσουμε αυτό το αρχείο και εκτελέσουμε την `git fetch`, παίρνουμε: [source,console] ---- @@ -201,8 +203,8 @@ $ git fetch # … ---- -Now all of the remote pull requests are represented locally with refs that act much like tracking branches; they're read-only, and they update when you do a fetch. -This makes it super easy to try the code from a pull request locally: +Τώρα όλα τα απομακρυσμένα αιτήματα έλξης αναπαριστώνται τοπικά με αναφορές που λειτουργούν σαν παρακολουθούμενοι κλάδων· είναι μόνο για ανάγνωση και ενημερώνονται όταν κάνουμε `fetch`. +Αυτό καθιστά πανεύκολο το να δοκιμάσουμε τον κώδικα από ένα αίτημα έλξης σε τοπικό επίπεδο: [source,console] ---- @@ -212,86 +214,85 @@ Branch pr/2 set up to track remote branch pr/2 from origin. Switched to a new branch 'pr/2' ---- -The eagle-eyed among you would note the `head` on the end of the remote portion of the refspec. -There's also a `refs/pull/#/merge` ref on the GitHub side, which represents the commit that would result if you push the ``merge'' button on the site. -This can allow you to test the merge before even hitting the button. +Αν είστει εξαιρετικά παρατηρητικοί, θα έχετε εντοπίσει το `head` στο τέλος του απομακρυσμένου τμήματος του refspec. +Υπάρχει επίσης ένας σύνδεσμος `refs/pull/#/merge` στην πλευρά του GitHub, που αντιπροσωπεύει την υποβολή που θα προκύψει αν πατήσουμε το κουμπί "`Merge`". +Αυτό μπορεί να μας επιτρέψει να δοκιμάσουμε τη συγχώνευση ακόμη και πριν πατήσουμε το κουμπί. +===== Αιτήματα έλξης σε αιτήματα έλξης -===== Pull Requests on Pull Requests +Όχι μόνο μπορούμε να υποβάλουμε αιτήματα έλξης που έχουν ως στόχο τον κεντρικό ή τον κύριο κλάδο, αλλά μπορούμε να υποβάλουμε αίτημα έλξης με στόχο οποιονδήποτε κλάδο στο δίκτυο. +Μάλιστα, μπορούμε ακόμη υποβάλουμε αίτημα έλξης σε ένα άλλο αίτημα έλξης. -Not only can you open Pull Requests that target the main or `master` branch, you can actually open a Pull Request targeting any branch in the network. -In fact, you can even target another Pull Request. +Εάν δούμε αίτημα έλξης που κινείται προς τη σωστή κατεύθυνση και έχουμε μια ιδέα για μια αλλαγή που εξαρτάται από αυτήν ή δεν είμαστε βέβαιοι ότι είναι καλή ιδέα ή απλά δεν έχουμε πρόσβαση ώθησης στον κλάδο-στόχο, μπορούμε να υποβάλουμε ένα αίτημα έλξης απευθείας σε αυτό. -If you see a Pull Request that is moving in the right direction and you have an idea for a change that depends on it or you're not sure is a good idea, or you just don't have push access to the target branch, you can open a Pull Request directly to it. +Όταν πάμε να υποβάλουμε ένα αίτημα έλξης, υπάρχει ένα πλαίσιο στο επάνω μέρος της σελίδας που καθορίζει από ποιον και προς ποιον κλάδο αιτούμαστε να έλξουμε. +Αν πατήσουμε το κουμπί ``Edit'' στα δεξιά του πλαισίου μπορούμε να αλλάξουμε όχι μόνο τους κλάδους αλλά και τη διχάλα. -When you go to open a Pull Request, there is a box at the top of the page that specifies which branch you're requesting to pull to and which you're requesting to pull from. -If you hit the ``Edit'' button at the right of that box you can change not only the branches but also which fork. +[[r_pr_targets]] +.Χειροκίνητη αλλαγή της διχάλας και κλάδου σε αίτημα έλξης +image::images/maint-04-target.png[Χειροκίνητη αλλαγή της διχάλας και κλάδου σε αίτημα έλξης] -[[_pr_targets]] -.Manually change the Pull Request target fork and branch. -image::images/maint-04-target.png[PR targets] +Εδώ μπορούμε αρκετά εύκολα να ζητήσουμε να συγχωνεύσουμε τον νέο μας κλάδο σε άλλο αίτημα έλξης ή σε άλλο πηδάλιο του έργου. -Here you can fairly easily specify to merge your new branch into another Pull Request or another fork of the project. +==== Μνημονεύσεις (mentions) και Eιδοποιήσεις -==== Mentions and Notifications +Το GitHub έχει επίσης ένα πολύ ωραίο ενσωματωμένο σύστημα ειδοποιήσεων, το οποίο μπορεί να είναι χρήσιμο όταν έχουμε ερωτήσεις ή χρειαζόμαστε ανταπόκριση από συγκεκριμένα άτομα ή ομάδες. -GitHub also has a pretty nice notifications system built in that can come in handy when you have questions or need feedback from specific individuals or teams. +Σε οποιοδήποτε σχόλιο αν αρχίσουμε να πληκτρολογούμε έναν χαρακτήρα `@` θα αρχίσει να συμπληρώνεται αυτόματα με τα ονόματα και τα ονόματα χρήστη των ατόμων που συνεργάζονται ή συνεισφέρουν στο έργο. -In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. +.Πληκτρολογούμε `@` για να μνημονεύσουμε κάποιον +image::images/maint-05-mentions.png[Πληκτρολογούμε `@` για να μνημονεύσουμε (mention) κάποιον] -.Start typing @ to mention someone. -image::images/maint-05-mentions.png[Mentions] +Μπορούμε επίσης να μνημονεύσουμε έναν χρήστη που δεν βρίσκεται σε αυτό το αναπτυσσόμενο μενού, αλλά συχνά ο αυτόματος συμπληρωτής το κάνει πιο γρήγορα. -You can also mention a user who is not in that dropdown, but often the autocompleter can make it faster. +Αφού δημοσιεύσουμε ένα σχόλιο με αναφορά σε κάποιον χρήστη, αυτός ο χρήστης θα ειδοποιηθεί. +Αυτό σημαίνει ότι αυτός είναι ένας πραγματικά πιο αποτελεσματικός τρόπος να προσελκύσουμε τους άλλους σε συνομιλίες από όσο το να κάνουμε μία δημοσκόπηση. +Πολύ συχνά σε αιτήματα έλξης στο GitHub οι χρήστες προσελκύσουν άλλους χρήστες στις ομάδες τους ή την επιχείρησή τους για να εξετάσουν ένα ζήτημα ή ένα αίτημα έλξης. -Once you post a comment with a user mention, that user will be notified. -This means that this can be a really effective way of pulling people into conversations rather than making them poll. -Very often in Pull Requests on GitHub people will pull in other people on their teams or in their company to review an Issue or Pull Request. +Εάν κάποιος μνημονευτεί σε ένα αίτημα έλξης ή ζήτημα, θα γίνει ``συνδρομητής'' σε αυτό και θα συνεχίσει να λαμβάνει ειδοποιήσεις οποιαδήποτε στιγμή κάποια δραστηριότητα συμβαίνει σε αυτό. +Θα είμαστε επίσης συνδρομητές σε κάτι αν το ανοίξουμε, εάν παρακολουθούμε το αποθετήριο ή σχολιάσουμε κάτι. +Αν δεν θέλουμε πλέον να λαμβάνουμε ειδοποιήσεις, υπάρχει ένα κουμπί ``Unsubscribe'' στη σελίδα που μπορούμε να κάνουμε κλικ για να σταματήσουμε να λαμβάνουμε ενημερώσεις σχετικά με αυτό. -If someone gets mentioned on a Pull Request or Issue, they will be ``subscribed'' to it and will continue getting notifications any time some activity occurs on it. -You will also be subscribed to something if you opened it, if you're watching the repository or if you comment on something. -If you no longer wish to receive notifications, there is an ``Unsubscribe'' button on the page you can click to stop receiving updates on it. +.Διαγραφή από λίστα ενημερώσεων για ένα ζήτημα ή αίτημα έλξης +image::images/maint-06-unsubscribe.png[Διαγραφή από λίστα ενημερώσεων για ζήτημα ή αίτημα έλξης] -.Unsubscribe from an Issue or Pull Request. -image::images/maint-06-unsubscribe.png[Unsubscribe] +===== Η σελίδα των ειδοποιήσεων -===== The Notifications Page +Όταν λέμε "`ειδοποιήσεις`" εδώ σε σχέση με το GitHub, εννοούμε έναν συγκεκριμένο τρόπο με τον οποίο το GitHub προσπαθεί να έρθει σε επαφή μαζί μας όταν συμβαίνουν κάτι και υπάρχουν διάφοροι τρόποι με τους οποίους μπορούμε να τις διαμορφώσουμε. +Αν μεταβούμε στην καρτέλα "`Notification center`" από τη σελίδα ρυθμίσεων, μπορούμε να δούμε μερικές από τις επιλογές που έχουμε. -When we mention ``notifications'' here with respect to GitHub, we mean a specific way that GitHub tries to get in touch with you when events happen and there are a few different ways you can configure them. -If you go to the ``Notification center'' tab from the settings page, you can see some of the options you have. +.Επιλογές κέντρου ειδοποιήσεων +image::images/maint-07-notifications.png[Επιλογές κέντρου ειδοποιήσεων] -.Notification center options. -image::images/maint-07-notifications.png[Notification center] +Οι δύο επιλογές είναι να λαμβάνουμε ειδοποιήσεις σχετικά μέσω "`Email`" και μέσω "`Web`" και μπορούμε να επιλέξουμε είτε μία από τις δύο, καμία από τις δύο ή και τις δύο όταν συμμετέχουμε ενεργά σε ό,τι συμβαίνει ή για δραστηριότητες στα αποθετήρια που παρακολουθούμε. -The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching. +====== Ειδοποιήσεις μέσω web -====== Web Notifications +Οι ειδοποιήσεις ιστού υπάρχουν μόνο στο GitHub και μπορούμε να τις δούμε μόνο στο GitHub. +Εάν έχουμε επιλέξει αυτήν την επιλογή στις προτιμήσεις μας και ενεργοποιηθεί μια ειδοποίηση για μας, θα δούμε μια μικρή μπλε κουκίδα πάνω από το εικονίδιο ειδοποιήσεων μας στο επάνω μέρος της οθόνης, όπως φαίνεται στην εικόνα <> -Web notifications only exist on GitHub and you can only check them on GitHub. -If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. +[[r_not_center]] +.Κέντρο ειδοποιήσεων +image::images/maint-08-notifications-page.png[Κέντρο ειδοποιήσεων] -[[_not_center]] -.Notification center. -image::images/maint-08-notifications-page.png[Notification center] +Εάν κάνουμε κλικ σ' αυτό, θα δούμε μια λίστα με όλα τα στοιχεία για τα οποία έχουμε ειδοποιηθεί, ομαδοποιημένα κατά έργο. +Μπορούμε να φιλτράρουμε τις ειδοποιήσεις ενός συγκεκριμένου έργου κάνοντας κλικ στο όνομά του στην αριστερή πλευρική μπάρα. +Μπορούμε επίσης να επιβεβαιώσουμε τη λήψη της ειδοποίησης κάνοντας κλικ στο εικονίδιο tick δίπλα σε οποιαδήποτε ειδοποίηση ή να επιβεβαιώσουμε τη λήψη _όλων_ των ειδοποιήσεων σε ένα έργο κάνοντας κλικ στο εικονίδιο tick στο πάνω μέρος της ομάδας. +Υπάρχει επίσης ένα κουμπί σίγασης δίπλα σε κάθε σημάδι επιλογής στο οποίο μπορούμε να κάνουμε κλικ για να μην λαμβάνουμε άλλες ειδοποιήσεις σχετικά με το συγκεκριμένο στοιχείο. -If you click on that, you will see a list of all the items you have been notified about, grouped by project. -You can filter to the notifications of a specific project by clicking on its name in the left hand sidebar. -You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifications in a project by clicking the checkmark at the top of the group. -There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item. +Όλα αυτά τα εργαλεία είναι πολύ χρήσιμα για τη διαχείριση μεγάλου αριθμού ειδοποιήσεων. +Πολλοί έμπειροι χρήστες του GitHub απενεργοποιούν απλώς όλες τις ειδοποιήσεις ηλεκτρονικού ταχυδρομείου και διαχειρίζονται όλες τις ειδοποιήσεις τους μέσω αυτής της οθόνης. -All of these tools are very useful for handling large numbers of notifications. -Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen. +====== Ειδοποιήσεις μέσω e-mail -====== Email Notifications +Οι ειδοποιήσεις μέσω e-mail είναι ο άλλος τρόπος με τον οποίο μπορούμε να χειριστούμε τις ειδοποιήσεις μέσα από το GitHub. +Εάν έχουμε ενεργοποιήσει αυτήν τη λειτουργία, θα λαμβάνουμε μηνύματα e-mail για κάθε ειδοποίηση. +Είδαμε παραδείγματα αυτής της λειτουργίας στην ενότητα <> και την εικόνα <>. +Τα μηνύματα e-mail επίσης θα ταξινομούντα κατά νήμα, κάτι πολύ χρήσιμο εφόσον χρησιμοποιούμε ένα πρόγραμμα e-mail που υποστηρίζει τα νήματα. -Email notifications are the other way you can handle notifications through GitHub. -If you have this turned on you will get emails for each notification. -We saw examples of this in <<_email_notification>> and <<_email_pr>>. -The emails will also be threaded properly, which is nice if you're using a threading email client. +Υπάρχει επίσης μία σημαντική ποσότητα μεταδεδομένων ενσωματωμένων στις κεφαλίδες των μηνυμάτων e-mail που μας στέλνει το GitHub, κάτι που μπορεί να είναι πραγματικά χρήσιμο για τη δημιουργία προσαρμοσμένων φίλτρων και κανόνων. -There is also a fair amount of metadata embedded in the headers of the emails that GitHub sends you, which can be really helpful for setting up custom filters and rules. - -For instance, if we look at the actual email headers sent to Tony in the email shown in <<_email_pr>>, we will see the following among the information sent: +Για παράδειγμα, αν κοιτάξουμε τις πραγματικές κεφαλίδες e-mail που αποστέλλονται στον Tony στο e-mail που εμφανίζεται στην εικόνα <>, θα δούμε τα παρακάτω μεταξύ των πληροφοριών που στάλθηκαν: [source,mbox] ---- @@ -306,71 +307,71 @@ List-Unsubscribe: ,... X-GitHub-Recipient-Address: tchacon@example.com ---- -There are a couple of interesting things here. -If you want to highlight or re-route emails to this particular project or even Pull Request, the information in `Message-ID` gives you all the data in `///` format. -If this were an issue, for example, the `` field would have been ``issues'' rather than ``pull''. +Υπάρχουν μερικά ενδιαφέροντα πραγματάκια εδώ. +Εάν θέλουμε να επισημάνουμε ή να επαναπροωθήσουμε τα μηνύματα e-mail σε αυτό το συγκεκριμένο έργο ή ακόμα και το αίτημα έλξης, οι πληροφορίες στο "Message-ID" μάς παρέχουν όλα τα δεδομένα στη μορφή `<χρήστης>/<έργο>/<τύπος>`. +Αν αυτό ήταν ένα ζήτημα, για παράδειγμα, το πεδίο `<τύπος>` θα έλεγε `issues` αντί για `pull`. -The `List-Post` and `List-Unsubscribe` fields mean that if you have a mail client that understands those, you can easily post to the list or ``Unsubscribe'' from the thread. -That would be essentially the same as clicking the ``mute'' button on the web version of the notification or ``Unsubscribe'' on the Issue or Pull Request page itself. +Τα πεδία `List-Post` και` List-Unsubscribe` σημαίνουν ότι αν έχουμε ένα πρόγραμμα e-mail που τα καταλαβαίνει, μπορούμε εύκολα να αναρτήσουμε στη λίστα ή να διαγραφούμε από το νήμα. +Αυτό θα ήταν ουσιαστικά το ίδιο με το κλικ στο κουμπί ``Mute'' στη διαδικτυακή μορφή της ειδοποίησης ή ``Unsubscribe'' στη σελίδα ζητημάτων ή αιτημάτων έλξης. -It's also worth noting that if you have both email and web notifications enabled and you read the email version of the notification, the web version will be marked as read as well if you have images allowed in your mail client. +Αξίζει επίσης να σημειωθεί ότι εάν έχουμε ενεργοποιήσει και τις δύο μορφές ειδοποιήσεων (e-mail και ιστού) και διαβάσουμε την έκδοση e-mail της ειδοποίησης, η ειδοποίηση ιστού θα επισημανθεί ως αναγνωσμένη (εφόσον επιτρέπουμε εικόνες στο πρόγραμμα e-mail μας). -==== Special Files +==== Ειδικά αρχεία -There are a couple of special files that GitHub will notice if they are present in your repository. +Υπάρχουν μερικά ειδικά αρχεία τα οποία θα παρατηρήσει το GitHub εάν υπάρχουν στο αποθετήριό μας. -==== README +==== Αρχείο README -The first is the `README` file, which can be of nearly any format that GitHub recognizes as prose. -For example, it could be `README`, `README.md`, `README.asciidoc`, etc. -If GitHub sees a README file in your source, it will render it on the landing page of the project. +Το πρώτο είναι το αρχείο `README`, το οποίο μπορεί να είναι σχεδόν κάθε μορφής που αναγνωρίζει το GitHub ως κείμενο. +Για παράδειγμα, θα μπορούσε να είναι `README`, `README.md`, `README.asciidoc`, κ.λπ. +Αν το GitHub δει ένα αρχείο `README`, θα εμφανίσει στην αρχική σελίδα του έργου. -Many teams use this file to hold all the relevant project information for someone who might be new to the repository or project. -This generally includes things like: +Πολλές ομάδες χρησιμοποιούν αυτό το αρχείο για να κρατήσουν όλες τις σχετικές πληροφορίες σχετικά με το έργο για κάποιον που μπορεί να είναι νέος στο αποθετήριο ή το έργο. +Αυτό γενικά περιλαμβάνει πράγματα όπως: -* What the project is for -* How to configure and install it -* An example of how to use it or get it running -* The license that the project is offered under -* How to contribute to it +* Σε τι αφορά το έργο +* Πώς να το ρυθμίσουμε και εγκαταστήσουμε +* Ένα παράδειγμα για το πώς να το χρησιμοποιήσουμε ή να το τρέξουμε +* Η άδεια χρήσης του έργου +* Πώς να συμβάλλουμε σε αυτό -Since GitHub will render this file, you can embed images or links in it for added ease of understanding. +Δεδομένου ότι το GitHub θα προβάλει αυτό το αρχείο, μπορούμε να ενσωματώσουμε εικόνες ή συνδέσμους σε αυτό, ώστε να είναι κκατανοητό πιο εύκολα. -==== CONTRIBUTING +==== Αρχείο CONTRIBUTING -The other special file that GitHub recognizes is the `CONTRIBUTING` file. -If you have a file named `CONTRIBUTING` with any file extension, GitHub will show <<_contrib_file>> when anyone starts opening a Pull Request. +Το άλλο ειδικό αρχείο που αναγνωρίζει το GitHub είναι το αρχείο `CONTRIBUTING`. +Εάν έχουμε ένα αρχείο που ονομάζεται `CONTRIBUTING` με οποιαδήποτε κατάληξη αρχείου, το GitHub θα εμφανίσει την εικόνα <>, όταν κάποιος ξεκινά την υποβολή ενός αιτήματος έλξης. -[[_contrib_file]] -.Opening a Pull Request when a CONTRIBUTING file exists. -image::images/maint-09-contrib.png[Contributing notice] +[[r_contrib_file]] +.Υποβολή αιτήματος έλξης όταν υπάρχει αρχείο `CONTRIBUTING` +image::images/maint-09-contrib.png[Υποβολή αιτήματος έλξης όταν υπάρχει αρχείο `CONTRIBUTING`] -The idea here is that you can specify specific things you want or don't want in a Pull Request sent to your project. -This way people may actually read the guidelines before opening the Pull Request. +Η ιδέα εδώ είναι ότι μπορούμε να καθορίσουμε συγκεκριμένα πράγματα που θέλουμε ή δεν θέλουμε σε ένα αίτημα έλξης που υποβάλλεται στο έργο μας. +Με αυτόν τον τρόπο, οι χρήστες μπορούν να διαβάσουν τις οδηγίες πριν υποβάλουν ένα αίτημα έλξης. -==== Project Administration +==== Διαχείριση έργων -Generally there are not a lot of administrative things you can do with a single project, but there are a couple of items that might be of interest. +Γενικά, δεν υπάρχουν πολλά διαχειριστικά πράγματα που μπορούμε να κάνουμε με ένα μόνο έργο, αλλά υπάρχουν μερικά στοιχεία που μπορεί να ενδιαφέρουν. -===== Changing the Default Branch +===== Αλλαγή του προεπιλεγμένου κλάδου -If you are using a branch other than ``master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository's settings page under the ``Options'' tab. +Αν χρησιμοποιούμε κλάδο διαφορετικό από τον `master` ως τον προεπιλεγμένο μας κλάδο στον οποίο θέλουμε να υποβάλλονται τα αιτήματα έλξης ή να φαίνεται εκ προεπιλογής, μπορούμε να το αλλάξουμε στη σελίδα ρυθμίσεων του αποθετηρίου κάτω από την καρτέλα ``Options''. -[[_default_branch]] -.Change the default branch for a project. -image::images/maint-10-default-branch.png[Default branch] +[[r_default_branch]] +.Αλλαγή του προεπιλεγμένου κλάδου για ένα έργο +image::images/maint-10-default-branch.png[Αλλαγή του προεπιλεγμένου κλάδου για ένα έργο] -Simply change the default branch in the dropdown and that will be the default for all major operations from then on, including which branch is checked out by default when someone clones the repository. +Απλά αλλάζουμε τον προεπιλεγμένο κλάδο στο αναπτυσσόμενο μενού και αυτός θα είναι ο προεπιλεγμένος κλάδος για όλες τις σημαντικές λειτουργίες στο εξής, συμπεριλαμβανομένου του ποιος κλάδος ελέγχεται εκ προεπιλογής όταν κάποιος κλωνοποιεί το αποθετήριο. -===== Transferring a Project +===== Μεταβίβαση έργου -If you would like to transfer a project to another user or an organization in GitHub, there is a ``Transfer ownership'' option at the bottom of the same ``Options'' tab of your repository settings page that allows you to do this. +Εάν θέλουμε να μεταβιβάσουμε ένα έργο σε άλλον χρήστη ή οργανισμό στο GitHub, υπάρχει μια επιλογή ``Transfer ownership'' στο κάτω μέρος της καρτέλας ``Options'' της σελίδας ρυθμίσεων του αποθετηρίου που μας επιτρέπει να το κάνουμε. -[[_transfer_project]] -.Transfer a project to another GitHub user or Organization. -image::images/maint-11-transfer.png[Transfer] +[[r_transfer_project]] +.Μεταβίβαση έργου σε άλλον χρήστη ή οργάνωση του GitHub +image::images/maint-11-transfer.png[Μεταβίβαση έργου σε άλλον χρήστη ή οργάνωση του GitHub] -This is helpful if you are abandoning a project and someone wants to take it over, or if your project is getting bigger and want to move it into an organization. +Αυτό είναι χρήσιμο εάν εγκαταλείπουμε ένα έργο και κάποιος θέλει να το αναλάβει ή εάν το έργο μας μεγαλώνει και θέλουμε να το μεταβιβάσουμε σε κάποιον οργανισμό. -Not only does this move the repository along with all its watchers and stars to another place, it also sets up a redirect from your URL to the new place. -It will also redirect clones and fetches from Git, not just web requests. +Η μεταβίβαση του έργου δεν μετακινεί απλά το αποθετήριο μαζί με όλους τους παρατηρητές και τα αστέρια σε ένα άλλο μέρος, αλλά επίσης θέτει μια ανακατεύθυνση διεύθυνσης URL από το δικό μας URL στη στη νέα θέση. +Επίσης, ανακατευθύνει τους κλώνους και τις ανακτήσεις από το Git, όχι μόνο από το διαδίκτυο. diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 3dde89536..a87138fdb 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -1,72 +1,72 @@ -[[_github_orgs]] -=== Managing an organization +[[r_ch06-github_orgs]] +=== Διαχείριση οργανισμώνν (((GitHub, organizations))) -In addition to single-user accounts, GitHub has what are called Organizations. -Like personal accounts, Organizational accounts have a namespace where all their projects exist, but many other things are different. -These accounts represent a group of people with shared ownership of projects, and there are many tools to manage subgroups of those people. -Normally these accounts are used for Open Source groups (such as ``perl'' or ``rails'') or companies (such as ``google'' or ``twitter''). +Εκτός από λογαριασμούς ενός χρήστη, το GitHub έχει κάτι που ονομάζεται _οργανισμός_ (organizations). +Όπως οι προσωπικοί λογαριασμοί, οι λογαριασμοί οργανισμών έχουν έναν ονοματοχώρο όπου υπάρχουν όλα τα έργα τους, όμως διαφέρουν σε πολλά άλλα πράγματα. +Αυτοί οι λογαριασμοί αντιπροσωπεύουν μια ομάδα ατόμων με κοινή ιδιοκτησία έργων και υπάρχουν πολλά εργαλεία για τη διαχείριση υποομάδων αυτών των ατόμων. +Συνήθως αυτοί οι λογαριασμοί χρησιμοποιούνται για ομάδες ανοιχτού κώδικα (π.χ. "`perl`" ή "`rails`") ή εταιρείες (π.χ. "`google`" ή "`twitter`"). -==== Organization Basics +==== Βασικά στοιχεία οργανισμών -An organization is pretty easy to create; just click on the ``+'' icon at the top-right of any GitHub page, and select ``New organization'' from the menu. +Είναι πολύ εύκολο να δημιουργηθεί ένας οργανισμός· απλά κάνουμε κλικ στο εικονίδιο "`+`" στην πάνω δεξιά γωνία οποιασδήποτε σελίδας του GitHub και επιλέγουμε "`New organization`" ("`Νέος οργανισμός`") από το μενού. -.The ``New organization'' menu item. -image::images/neworg.png[The ``New organization'' menu item.] +.Το στοιχείο μενού "`New organization`". +image::images/neworg.png[Το στοιχείο μενού “New organization”.] -First you'll need to name your organization and provide an email address for a main point of contact for the group. -Then you can invite other users to be co-owners of the account if you want to. +Πρώτα θα πρέπει να δώσουμε ένα όνομα στον οργανισμό μας και μια διεύθυνση email ως κύριο στοιχείο επικοινωνίας για την ομάδα. +Στη συνέχεια μπορούμε να προσκαλέσουμε άλλους χρήστες να είναι συνδιοκτήτες αυτού του λογαριασμού, εφόσον το θέλουμε. -Follow these steps and you'll soon be the owner of a brand-new organization. -Like personal accounts, organizations are free if everything you plan to store there will be open source. +Αν ακολουθήσουμε αυτά τα βήματα σύντομα θα είμαστε ιδιοκτήτες ενός ολοκαίνουργιου οργανισμού. +Όπως οι προσωπικοί λογαριασμοί, οι οργανισμοί είναι δωρεάν, εφόσον όλα όσα σχεδιάζουμε να αποθηκεύσουμε εκεί είναι ανοιχτού κώδικα. -As an owner in an organization, when you fork a repository, you'll have the choice of forking it to your organization's namespace. -When you create new repositories you can create them either under your personal account or under any of the organizations that you are an owner in. -You also automatically ``watch'' any new repository created under these organizations. +Ως ιδιοκτήτης ενός οργανισμού, όταν αποσχίζουμε ένα απόθετήριο από ένα άλλο, θα έχουμε την επιλογή να το αποσχίσουμε στον ονοματοχώρο του οργανισμού μας. +Όταν δημιουργούμε νέα αποθετήρια, μπορούμε να τα δημιουργήσουμε είτε στον προσωπικό μας λογαριασμό είτε σε οποιονδήποτε οργανισμό είμαστε ιδιοκτήτες. +Μπορούμε επίσης αυτόματα να "`παρακολουθούμε`" κάθε νέο αποθετήριο που δημιουργήθηκε κάτω από αυτούς τους οργανισμούς. -Just like in <<_personal_avatar>>, you can upload an avatar for your organization to personalize it a bit. -Also just like personal accounts, you have a landing page for the organization that lists all of your repositories and can be viewed by other people. +Όπως και στην εικόνα <>, μπορούμε να ανεβάσουμε ένα avatar για τον οργανισμό μας για να τον προσωποποιήσουμε λίγο. +Επίσης, ακριβώς όπως στους προσωπικούς λογαριασμούς, υπάρχει μια σελίδα για τον οργανισμό που παραθέτει όλα τα αποθετήριά του και είναι ορατή και σε άλλους. -Now let's cover some of the things that are a bit different with an organizational account. +Τώρα θα καλύψουμε μερικά από τα πράγματα που είναι λίγο διαφορετικά σε έναν λογαριασμό οργανισμού από ότι σε προσωπικούς λογαριασμούς. -==== Teams +==== Ομάδες -Organizations are associated with individual people by way of teams, which are simply a grouping of individual user accounts and repositories within the organization and what kind of access those people have in those repositories. +Οι οργανισμοί συνδέονται με μεμονωμένα άτομα μέσω ομάδων, οι οποίες αποτελούν απλά μία ταξινόμηση μεμονωμένων λογαριασμών χρηστών και αποθετηρίων εντός του οργανισμού και το είδος πρόσβασης που έχουν τα συγκεκριμένα άτομα σε αυτά τα αποθετήρια. -For example, say your company has three repositories: `frontend`, `backend`, and `deployscripts`. -You'd want your HTML/CSS/Javascript developers to have access to `frontend` and maybe `backend`, and your Operations people to have access to `backend` and `deployscripts`. -Teams make this easy, without having to manage the collaborators for every individual repository. +Για παράδειγμα, ας πούμε ότι η εταιρεία μας διαθέτει τρία αποθετήρια: `frontend`, `backend` και `deployscripts`. +Θα θέλαμε οι προγραμματιστές HTML/CSS/Javascript να έχουν πρόσβαση στο `frontend` και ίσως στο `backend` και οι επιχειρησιακοί να έχουν πρόσβαση στα `backend` και `deployscripts`. +Οι ομάδες το καθιστούν αυτό εύκολο, χωρίς να χρειάζεται να διαχειριζόμαστε τους συνεργάτες για κάθε μεμονωμένο αποθετήριο. -The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organization. +Η σελίδα του οργανισμού μάς δείχνει έναν απλό πίνακα ελέγχου όλων των αποθετηρίων, των χρηστών και των ομάδων που βρίσκονται κάτω από αυτόν τον οργανισμό. -[[_org_page]] -.The Organization page. -image::images/orgs-01-page.png[] +[[r_org_page]] +.Η σελίδα του οργανισμού +image::images/orgs-01-page.png[Η σελίδα του οργανισμού.] -To manage your Teams, you can click on the Teams sidebar on the right hand side of the page in <<_org_page>>. -This will bring you to a page you can use to add members to the team, add repositories to the team or manage the settings and access control levels for the team. -Each team can have read only, read/write or administrative access to the repositories. -You can change that level by clicking the ``Settings'' button in <<_team_page>>. +Για να διαχειριστούμε τις ομάδες μας, μπορούμε να κάνουμε κλικ στην πλευρική μπάρα Teams στο δεξί μέρος της σελίδας στην εικόνα <> +Αυτό θα μας φέρει σε μια σελίδα που μπορούμε να χρησιμοποιήσουμε για να προσθέσουμε μέλη στην ομάδα, να προσθέσουμε αποθετήρια στην ομάδα ή να διαχειριστούμε τις ρυθμίσεις και τα επίπεδα ελέγχου πρόσβασης για την ομάδα. +Κάθε ομάδα μπορεί να έχει πρόσβαση μόνο-για-ανάγνωση, ανάγνωση/εγγραφή ή και δικαιώματα administrator στα αποθετήρια. +Μπορούμε να αλλάξουμε το επίπεδο πρόσβασης κάνοντας κλικ στο κουμπί "`Settings`" στην <>. -[[_team_page]] -.The Team page. +[[r_team_page]] +.Η σελίδα της ομάδας. image::images/orgs-02-teams.png[] -When you invite someone to a team, they will get an email letting them know they've been invited. +Όταν προσκαλούμε κάποιον σε μια ομάδα, θα λάβει ένα e-mail που θα τους ενημερώνει ότι έχουν προσκληθεί. -Additionally, team `@mentions` (such as `@acmecorp/frontend`) work much the same as they do with individual users, except that *all* members of the team are then subscribed to the thread. -This is useful if you want the attention from someone on a team, but you don't know exactly who to ask. +Επιπλέον, τα `@mentions` της ομάδας (όπως π.χ. `@acmecorp/frontend`) λειτουργούν λίγο-πολύ όπως και για μεμονωμένους μεμονωμένους χρήστες με τη διαφορά ότι *όλα* τα μέλη της ομάδας αποκτούν συνδρομή στο νήμα. +Αυτό είναι χρήσιμο εάν θέλουμε να τραβήξουμε την προσοχή κάποιου σε μια ομάδα, αλλά δεν ξέρουμε ακριβώς ποιον να ρωτήσουμε. -A user can belong to any number of teams, so don't limit yourself to only access-control teams. -Special-interest teams like `ux`, `css`, or `refactoring` are useful for certain kinds of questions, and others like `legal` and `colorblind` for an entirely different kind. +Ένας χρήστης μπορεί να ανήκει πολλές ομάδες, οπότε μην περιορίζεστε μόνο σε ομάδες ελέγχου πρόσβασης. +Οι ομάδες ειδικού ενδιαφέροντος, όπως π.χ. `ux`, `css` ή `refactoring`, είναι χρήσιμες για ορισμένα είδη ερωτήσεων και άλλες όπως οι `legal` και `colorblind` για εντελώς άλλα είδη. -==== Audit Log +==== Μητρώο ελέγχων -Organizations also give owners access to all the information about what went on under the organization. -You can go to the 'Audit Log' tab and see what events have happened at an organization level, who did them and where in the world they were done. +Επιπλέον, οι οργανισμοί παρέχουν στους ιδιοκτήτες πρόσβαση σε όλες τις πληροφορίες σχετικά με το τι συνέβαινε στο πλαίσιο του οργανισμού. +Μπορούμε να μεταβούμε στην καρτέλα 'Audit Log' ('Μητρώο ελέγχων') και να δούμε τι συνέβη σε επίπεδο οργανισμού, ποιος το έκανε και πού έγινε. -[[_audit_log]] -.The Audit log. -image::images/orgs-03-audit.png[] +[[r_audit_log]] +.Το μητρώο ελέγχων. +image::images/orgs-03-audit.png[Το μητρώο ελέγχων.] -You can also filter down to specific types of events, specific places or specific people. +Μπορούμε επίσης να φιλτράρουμε συγκεκριμένους τύπους συμβάντων, συγκεκριμένους τόπους ή συγκεκριμένα άτομα. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index c6497ea50..28c7d1336 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -1,63 +1,63 @@ -=== Scripting GitHub +=== Συγγραφή script στο GitHub -So now we've covered all of the major features and workflows of GitHub, but any large group or project will have customizations they may want to make or external services they may want to integrate. +Πλέον, έχουμε καλύψει όλες τις σημαντικές λειτουργίες και τις ροές εργασίας του GitHub, αλλά κάθε μεγάλη ομάδα ή έργο θα έχει εξατομικεύσεις που ενδεχομένως θέλουν να κάνουν ή εξωτερικές υπηρεσίες που ενδεχομένως θα ήθελαν να ενσωματώσουν. -Luckily for us, GitHub is really quite hackable in many ways. -In this section we'll cover how to use the GitHub hooks system and its API to make GitHub work how we want it to. +Ευτυχώς για μας, το GitHub είναι πραγματικά αρκετά παραβιάσιμο (hackable) με πολλούς τρόπους. +Σε αυτήν την ενότητα θα περιγράψουμε πώς να χρησιμοποιήσουμε το σύστημα αγκίστρων του GitHub και το API του, ώστε να επιβάλλουμε το GitHub να λειτουργεί όπως θέλουμε. -==== Hooks +==== Υπηρεσίες και Άγκιστρα -The Hooks and Services section of GitHub repository administration is the easiest way to have GitHub interact with external systems. +Η ενότητα Αγκίστρων και Υπηρεσιών της διαχείρισης ενός αποθετηρίου GitHub είναι ο ευκολότερος τρόπος να κάνουμε το GitHub να επικοινωνήσει με εξωτερικά συστήματα. -===== Services +===== Υπηρεσίες -First we'll take a look at Services. -Both the Hooks and Services integrations can be found in the Settings section of your repository, where we previously looked at adding Collaborators and changing the default branch of your project. -Under the ``Webhooks and Services'' tab you will see something like <<_services_hooks>>. +Πρώτα θα ρίξουμε μια ματιά στις Υπηρεσίες. +Οι ενσωματώσεις τόσο αγκίστρων όσο και υπηρεσιών βρίσκονται στην ενότητα Settings του αποθετηρίου, όπου προηγουμένως εξετάσαμε την προσθήκη συνεργατών και την αλλαγή του προεπιλεγμένου κλάδου του έργου μας. +Στην καρτέλα "`Webhooks and Services`" θα δούμε κάτι σαν την εικόνα <> -[[_services_hooks]] -.Services and Hooks configuration section. -image::images/scripting-01-services.png[Services and hooks] +[[r_services_hooks]] +.Ενότητα ρυθμίσεων υπηρεσιών και αγκίστρων. +image::images/scripting-01-services.png[Υπηρεσίες και άγκιστρα.] -There are dozens of services you can choose from, most of them integrations into other commercial and open source systems. -Most of them are for Continuous Integration services, bug and issue trackers, chat room systems and documentation systems. -We'll walk through setting up a very simple one, the Email hook. -If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>. +Υπάρχουν δεκάδες υπηρεσίες από τις οποίες μπορούμε να επιλέξουμε, κυρίως υπηρεσίες ενσωμάτωσης σε άλλα εμπορικά ή ανοιχτά συστήματα. +Οι περισσότερες από αυτές προορίζονται για υπηρεσίες _συνεχούς ενσωμάτωσης_ (continuous integration), παρακολούθησης σφαλμάτων και προβλημάτων, συστήματα χώρων συζήτησης (chat room) και συστήματα τεκμηρίωσης. +Θα δούμε βήμα-βήμα τη δημιουργία ενός πολύ απλού αγκίστρου, του αγκίστρου ηλεκτρονικού ταχυδρομείου. +Εάν επιλέξουμε "`email`" από την αναπτυσσόμενη λίστα "`Add Service`", θα πάρουμε μια οθόνη διαμόρφωσης όπως στην εικόνα <> -[[_service_config]] -.Email service configuration. -image::images/scripting-02-email-service.png[Email service] +[[r_service_config]] +.Ρύθμιση της υπηρεσίας e-mail. +image::images/scripting-02-email-service.png[Ρύθμιση της υπηρεσίας e-mail] -In this case, if we hit the ``Add service'' button, the email address we specified will get an email every time someone pushes to the repository. -Services can listen for lots of different types of events, but most only listen for push events and then do something with that data. +Σε αυτήν την περίπτωση, εάν πατήσουμε το κουμπί "`Add Service`", η διεύθυνση e-mail που καθορίσαμε θα λάβει ένα μήνυμα e-mail κάθε φορά που κάποιος ωθεί στο αποθετήριο. +Οι υπηρεσίες μπορούν να ακούν πολλούς διαφορετικούς τύπους συμβάντων, αλλά οι περισσότερες ακούν μόνο συμβάντα ώθησης και στη συνέχεια κάνουν κάτι με αυτά τα δεδομένα. -If there is a system you are using that you would like to integrate with GitHub, you should check here to see if there is an existing service integration available. -For example, if you're using Jenkins to run tests on your codebase, you can enable the Jenkins builtin service integration to kick off a test run every time someone pushes to your repository. +Εάν υπάρχει ένα σύστημα που χρησιμοποιούμε που θα θέλαμε να ενσωματώσουμε στο GitHub, θα πρέπει να ελέγξουμε εδώ για να δούμε εάν υπάρχει διαθέσιμη κάποια υπηρεσία ενσωμάτωσης. +Για παράδειγμα, αν χρησιμοποιούμε το Jenkins για να εκτελέσουμε δοκιμές στον κώδικά μας, μπορούμε να ενεργοποιήσουμε την ενσωματωμένη στο Jenkins υπηρεσία ενσωμάτωσης για να ξεκινήσουμε μια δοκιμαστική λειτουργία κάθε φορά που κάποιος ωθεί κάτι στο αποθετήριό μας. -===== Hooks +===== Άγκιστρα -If you need something more specific or you want to integrate with a service or site that is not included in this list, you can instead use the more generic hooks system. -GitHub repository hooks are pretty simple. -You specify a URL and GitHub will post an HTTP payload to that URL on any event you want. +Εάν χρειαζόμαστε κάτι πιο συγκεκριμένο ή θέλουμε να ενσωματώσουμε μια υπηρεσία ή έναν ιστότοπο που δεν περιλαμβάνεται σε αυτήν τη λίστα, μπορούμε αντ' αυτού να χρησιμοποιήσουμε το πιο γενικό σύστημα αγκίστρων. +Τα άγκιστρα αποθετηρίων στο GitHub είναι αρκετά απλά. +Ορίζουμε μια διεύθυνση URL και το GitHub θα αποστείλει ένα ωφέλιμο φορτίο HTTP σε αυτήν τη διεύθυνση URL, όποτε συμβαίνει κάποιο συμβάν που θέλουμε. -Generally the way this works is you can setup a small web service to listen for a GitHub hook payload and then do something with the data when it is received. +Γενικά, ο τρόπος με τον οποίο λειτουργεί αυτό είναι ότι μπορούμε να εγκαταστήσουμε μια μικρή υπηρεσία ιστού που να ακούει κάποια χρήσιμα άγκιστρα GitHub και στη συνέχεια κάνουμε κάτι με τα δεδομένα όταν παραληφθούν. -To enable a hook, you click the ``Add webhook'' button in <<_services_hooks>>. -This will bring you to a page that looks like <<_web_hook>>. +Για να ενεργοποιήσουμε ένα άγκιστρο, κάνουμε κλικ στο κουμπί "`Add webhook`" στο <>. +Αυτό θα μας φέρει σε μια σελίδα που μοιάζει με αυτήν της εικόνας <> -[[_web_hook]] -.Web hook configuration. -image::images/scripting-03-webhook.png[Web hook] +[[r_web_hook]] +.Ρύθμιση αγκίστρων ιστού. +image::images/scripting-03-webhook.png[Άγκιστρα ιστού.] -The configuration for a web hook is pretty simple. -In most cases you simply enter a URL and a secret key and hit ``Add webhook''. -There are a few options for which events you want GitHub to send you a payload for -- the default is to only get a payload for the `push` event, when someone pushes new code to any branch of your repository. +Η διαμόρφωση για ένα άγκιστρο ιστού είναι αρκετά απλή. +Στις περισσότερες περιπτώσεις απλά εισάγουμε μια διεύθυνση URL και ένα μυστικό κλειδί και κάνουμε κλικ στο "`Add webhook`". +Υπάρχουν μερικές επιλογές όσον αφορά στο για ποια συμβάντα θέλουμε το GitHub να μας στείλει ένα ωφέλιμο φορτίο —η προεπιλογή είναι να πάρει μόνο ένα ωφέλιμο φορτίο για το συμβάν `push`, όταν, δηλαδή, κάποιος ωθήσει νέο κώδικα σε οποιονδήποτε κλάδο του αποθετηρίου μας. -Let's see a small example of a web service you may set up to handle a web hook. -We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing. +Ας δούμε ένα μικρό παράδειγμα μιας υπηρεσίας ιστού που μπορούμε να στήσουμε για να χειριστούμε ένα άγκιστρο ιστού. +Θα χρησιμοποιήσουμε το πλαίσιο ιστού της Ruby, Sinatra, αφού είναι αρκετά περιεκτικό και μπορούμε εύκολα να δούμε τι κάνουμε. -Let's say we want to get an email if a specific person pushes to a specific branch of our project modifying a specific file. -We could fairly easily do that with code like this: +Ας υποθέσουμε ότι θέλουμε να λάβουμε ένα μήνυμα e-mail, αν ένα συγκεκριμένο άτομο ωθήσει σε έναν συγκεκριμένο κλάδο του έργου μας που τροποποιεί ένα συγκεκριμένο αρχείο. +Θα μπορούσαμε να το κάνουμε εύκολα με κώδικα όπως αυτός: [source,ruby] ---- @@ -93,36 +93,37 @@ post '/payload' do end ---- -Here we're taking the JSON payload that GitHub delivers us and looking up who pushed it, what branch they pushed to and what files were touched in all the commits that were pushed. -Then we check that against our criteria and send an email if it matches. +Εδώ παίρνουμε το ωφέλιμο φορτίο JSON που μας παραδίδει το GitHub και αναζητούμε σε αυτό ποιος το ώθησε, σε ποιον κλάδο ωθήθηκε και ποια αρχεία είχαν τροποποιηθεί σε όλες τις υποβολές που ωθήθηκαν. +Στη συνέχεια αντιπαραβάλλουμε αυτές τις πληροφορίες με τα κριτήρια μας και στέλνουμε ένα μήνυμα e-mail, αν ικανοποιούνται. -In order to develop and test something like this, you have a nice developer console in the same screen where you set the hook up. -You can see the last few deliveries that GitHub has tried to make for that webhook. -For each hook you can dig down into when it was delivered, if it was successful and the body and headers for both the request and the response. -This makes it incredibly easy to test and debug your hooks. +Προκειμένου να αναπτύξουμε και να δοκιμάσουμε κάτι τέτοιο, έχουμε μια ωραία κονσόλα προγραμματιστή στην ίδια οθόνη στην οποία ρυθμίζουμε το άγκιστρο. +Μπορούμε να δούμε τις τελευταίες παραδόσεις που προσπάθησε να κάνει το GitHub για αυτό το άγκιστρο ιστού. +Για κάθε άγκιστρο μπορούμε να ξετρυπώσουμε πότε παραδόθηκε, εάν η παράδοση ήταν επιτυχής καθώς και το σώμα και τις κεφαλίδες τόσο για το αίτημα όσο και για την απάντηση. +Αυτό καθιστά απίστευτα εύκολο τον έλεγχο και τον εντοπισμό σφαλμάτων στα άγκιστρά μας. -[[_web_hook_debug]] -.Web hook debugging information. -image::images/scripting-04-webhook-debug.png[Webhook debug] +[[r_web_hook_debug]] +.Πληροφορίες εντοπισμού σφαλμάτων σε άγκιστρο ιστού. +image::images/scripting-04-webhook-debug.png[Εντοπισμός σφαλμάτων σε άγκιστρο ιστού.] -The other great feature of this is that you can redeliver any of the payloads to test your service easily. +Το άλλο σπουδαίο χαρακτηριστικό του είναι ότι μπορούμε να ξαναπαραδώσουμε οποιοδήποτε από τα ωφέλιμα φορτία για να δοκιμάσουμε εύκολα την υπηρεσία μας. -For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at: https://developer.github.com/webhooks/ +Για περισσότερες πληροφορίες σχετικά με τον τρόπο εγγραφής των αγκίστρων ιστού και όλων των διαφορετικών τύπων συμβάντων που μπορούμε να ακούσουμε, μπορούμε να μεταβούμε στην τεκμηρίωση του GitHub Developer στη διεύθυνση: https://docs.github.com/en/webhooks-and-events/webhooks/about-webhooks[^]. -==== The GitHub API +==== Το API του GitHub (((GitHub, API))) -Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? What if you need to automate something like adding collaborators or labeling issues? +Οι υπηρεσίες και τα άγκιστρα μάς δίνουν έναν τρόπο να λαμβάνουμε ειδοποιήσεις ωθήσεων για γεγονότα που συμβαίνουν στα αποθετήριά μας. Αλλά τι γίνεται αν χρειαζόμαστε περισσότερες πληροφορίες σχετικά με αυτά τα γεγονότα; +Τι γίνεται αν πρέπει να αυτοματοποιήσουμε κάποια ενέργεια όπως την προσθήκη συνεργατών ή επισήμανση ζητημάτων; -This is where the GitHub API comes in handy. -GitHub has tons of API endpoints for doing nearly anything you can do on the website in an automated fashion. -In this section we'll learn how to authenticate and connect to the API, how to comment on an issue and how to change the status of a Pull Request through the API. +Σε αυτές τις περιπτώσεις είναι χρήσιμο το API του GitHub. +Το GitHub έχει αμέτρητα σημεία σύνδεσης με το API για να κάνει σχεδόν ο,τιδήποτε μπορούμε να κάνουμε στον ιστότοπο με αυτοματοποιημένο τρόπο. +Σε αυτήν την ενότητα θα μάθουμε πώς να ταυτοποιούμαστε και να συνδεόμαστε στο API, πώς να σχολιάζουμε ένα ζήτημα και πώς να αλλάξουμε την κατάσταση ενός αιτήματος έλξης μέσω του API. -==== Basic Usage +==== Βασική χρήση -The most basic thing you can do is a simple GET request on an endpoint that doesn't require authentication. -This could be a user or read-only information on an open source project. -For example, if we want to know more about a user named ``schacon'', we can run something like this: +Το πιο βασικό πράγμα που μπορούμε να κάνουμε είναι ένα απλό αίτημα GET σε ένα σημείο σύνδεσης που δεν απαιτεί ταυτοποίηση. +Αυτό θα μπορούσε να είναι πληροφορίες για κάποιον χρήστη ή πληροφορίες μόνο-για-ανάγνωση σε ένα έργο ανοιχτού κώδικα. +Για παράδειγμα, εάν θέλουμε να μάθουμε περισσότερα για έναν χρήστη που ονομάζεται "`schacon`", μπορούμε να τρέξουμε κάτι τέτοιο: [source,javascript] ---- @@ -140,8 +141,8 @@ $ curl https://api.github.com/users/schacon } ---- -There are tons of endpoints like this to get information about organizations, projects, issues, commits -- just about anything you can publicly see on GitHub. -You can even use the API to render arbitrary Markdown or find a `.gitignore` template. +Υπάρχουν πάρα πολλά τέτοια σημεία σύνδεσης για να λαμβάνουμε πληροφορίες σχετικά με οργανισμούς, έργα, θέματα, υποβολές —σχεδόν για ο,τιδήποτε μπορούμε να δούμε δημοσίως στο GitHub. +Μπορούμε ακόμη να χρησιμοποιήσουμε το API για να κάνουμε αποδώσουμε αυθαίρετη Markdown ή να βρούμε ένα πρότυπο `.gitignore`. [source,javascript] ---- @@ -158,39 +159,38 @@ $ curl https://api.github.com/gitignore/templates/Java *.war *.ear -# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml +# virtual machine crash logs, see https://www.java.com/en/download/help/error_hotspot.xml hs_err_pid* " } ---- +==== Σχολιασμός θέματος -==== Commenting on an Issue +Ωστόσο, αν θέλουμε να κάνουμε μια ενέργεια στον ιστότοπο, όπως να σχολιάσουμε ένα ζήτημα ή αίτημα έλξης ή αν θέλουμε να προβάλουμε ή να αλληλεπιδράσουμε με ιδιωτικό περιεχόμενο, θα χρειαστεί να επαληθεύσουμε την ταυτότητά μας. -However, if you want to do an action on the website such as comment on an Issue or Pull Request or if you want to view or interact with private content, you'll need to authenticate. +Υπάρχουν πολλοί τρόποι ταυτοποίησης. +Μπορούμε να χρησιμοποιήσουμε τη βασική ταυτοποίηση μόνο με το όνομα χρήστη και τον κωδικό πρόσβασής μα, αλλά γενικά είναι καλύτερο να χρησιμοποιήσουμε ένα προσωπικό token (διακριτικό) πρόσβασης. +Μπορούμε να δημιουργήσουμε ένα τέτοιο token από την καρτέλα "`Applications`" της σελίδας ρυθμίσεων. -There are several ways to authenticate. -You can use basic authentication with just your username and password, but generally it's a better idea to use a personal access token. -You can generate this from the ``Applications'' tab of your settings page. - -[[_access_token]] -.Generate your access token from the ``Applications'' tab of your settings page. +[[r_access_token]] +.Δημιουργία διακριτικού πρόσβασης από την καρτέλα "`Applications`" της σελίδας ρυθμίσεων. image::images/scripting-05-access-token.png[Access Token] -It will ask you which scopes you want for this token and a description. -Make sure to use a good description so you feel comfortable removing the token when your script or application is no longer used. +Θα μας ρωτήσει ποια πεδία εφαρμογής (scopes) θέλουμε για αυτό το διακριτικό και μια περιγραφή. +Πρέπει να βεβαιωθούμε ότι χρησιμοποιούμε μια καλή περιγραφή, ώστε να αισθανόμαστε άνετα με την αφαίρεση του διακριτικού όταν το script ή η εφαρμογή μας δεν χρησιμοποιείται πλέον. -GitHub will only show you the token once, so be sure to copy it. -You can now use this to authenticate in your script instead of using a username and password. -This is nice because you can limit the scope of what you want to do and the token is revocable. +Το GitHub θα μας δείξει μόνο μία φορά το διακριτικό, οπότε πρέπει να φροντίσουμε να το αντιγράψουμε. +Τώρα μπορούμε να χρησιμοποιήσουμε το διακριτικό για ταυτοποίηση αντί για όνομα χρήστη και κωδικό πρόσβασης. +Αυτό είναι ωραίο επειδή μπορούμε να περιορίσουμε το πεδίο εφαρμογής του τι θέλουμε να κάνουμε και το διακριτικό μπορεί να ανακληθεί. -This also has the added advantage of increasing your rate limit. -Without authenticating, you will be limited to 60 requests per hour. -If you authenticate you can make up to 5,000 requests per hour. +Έχει επίσης το πρόσθετο πλεονέκτημα ότι αυξάνεται το επιτρεπτό όριο του ρυθμού αιτημάτων. +Χωρίς ταυτοποίηση, περιοριζόμαστε σε 60 αιτήματα ανά ώρα. +Με ταυτοποίηση μπορούμε να έχουμε μέχρι και 5.000 αιτήματα ανά ώρα. -So let's use it to make a comment on one of our issues. -Let's say we want to leave a comment on a specific issue, Issue #6. -To do so we have to do an HTTP POST request to `repos///issues//comments` with the token we just generated as an Authorization header. +Ας το χρησιμοποιήσουμε, λοιπόν, για να σχολιάσουμε ένα από τα ζητήματά μας. +Ας υποθέσουμε ότι θέλουμε να αφήσουμε ένα σχόλιο σε ένα συγκεκριμένο ζήτημα, το ζήτημα #6. +Για να γίνει αυτό, πρέπει να κάνουμε ένα αίτημα HTTP POST στο `repos/<χρήστης>/<αποθετήριο>/issues/<αρθ>/comments` με το διακριτικό που μόλις δημιουργήσαμε ως το πεδίο Authorization στην κεφαλίδα. [source,javascript] ---- @@ -214,23 +214,23 @@ $ curl -H "Content-Type: application/json" \ } ---- -Now if you go to that issue, you can see the comment that we just successfully posted as in <<_api_comment>>. +Τώρα, αν πάμε σε αυτό το ζήτημα, μπορούμε να δούμε το σχόλιο που μόλις δημοσιεύσαμε όπως στην εικόνα <> -[[_api_comment]] -.A comment posted from the GitHub API. -image::images/scripting-06-comment.png[API Comment] +[[r_api_comment]] +.Σχόλιο που αναρτήθηκε από το API του API. +image::images/scripting-06-comment.png[Σχόλιο που αναρτήθηκε από το API του API.] -You can use the API to do just about anything you can do on the website -- creating and setting milestones, assigning people to Issues and Pull Requests, creating and changing labels, accessing commit data, creating new commits and branches, opening, closing or merging Pull Requests, creating and editing teams, commenting on lines of code in a Pull Request, searching the site and on and on. +Μπορούμε να χρησιμοποιήσουμε το API για να κάνουμε σχεδόν ο,τιδήποτε μπορούμε να κάνουμε στον ιστότοπο: να δημιουργήσουμε και ορίσουμε ορόσημα (milestones), να αναθέσουμε στους χρήστες ζητήματα και αιτήματα έλξης, να δημιουργήσουμε και αλλάξουμε ετικέτες, να προσβούμε σε δεδομένα υποβολών, να δημιουργήσουμε νέες υποβολές και κλάδους, να ανοίξουμε, κλείσουμε ή συγχωνεύσουμε αιτημάτα έλξης, να δημιουργήσουμε και να επεξεργαστούμε ομάδες, να σχολιάσουμε συγκεκριμένες γραμμές κώδικα σε ένα αίτημα έλξης, να κάνουμε αναζητήσεις στη σελίδα και ούτω καθεξής. -==== Changing the Status of a Pull Request +==== Αλλαγή της κατάστασης ενός αιτήματος έλξης -One final example we'll look at since it's really useful if you're working with Pull Requests. -Each commit can have one or more statuses associated with it and there is an API to add and query that status. +Θα δούμε ένα τελευταίο παράδειγμα, καθώς είναι πραγματικά χρήσιμο, όταν εργαζόμαστε με αιτήματα έλξης. +Κάθε υποβολή μπορεί να έχει μία ή περισσότερες καταστάσεις συνδεδεμένες με αυτήν και υπάρχει ένα API για να προσθέσουμε κατάσταση ή να ρωτήσουμε ποια είναι η κατάσταση. -Most of the Continuous Integration and testing services make use of this API to react to pushes by testing the code that was pushed, and then report back if that commit has passed all the tests. -You could also use this to check if the commit message is properly formatted, if the submitter followed all your contribution guidelines, if the commit was validly signed -- any number of things. +Οι περισσότερες από τις υπηρεσίες συνεχιζούς ενσωμάτωσης και δοκιμών κάνουν χρήση αυτού του API για να αντιδράσουν σε ωθήσεις δοκιμάζοντας τον κώδικα που ωθήθηκε και στη συνέχεια να υποβάλουν αναφορά αν η υποβολή έχει περάσει όλες τις δοκιμές. +Θα μπορούσαμε επίσης να το χρησιμοποιήσουμε για να ελέγξουμε αν το μήνυμα υποβολής είναι σωστά μορφοποιημένο, αν αυτός που το υπέβαλλε ακολούθησε όλες τις κατευθυντήριες γραμμές συνεισφορών, εάν η υποβολή ήταν έγκυρα υπογεγραμμένη και άλλα πολλά πράγματα. -Let's say you set up a webhook on your repository that hits a small web service that checks for a `Signed-off-by` string in the commit message. +Ας υποθέσουμε ότι έχουμε δημιουργήσει ένα άγκιστρο ιστού στο αποθετήριό μας που ενεργοποιεί μια μικρή υπηρεσία ιστού που ελέγχει αν υπάρχει η συμβολοσειρά `Signed-off-by` στο μήνυμα υποβολής. [source,ruby] ---- @@ -275,27 +275,27 @@ post '/payload' do end ---- -Hopefully this is fairly simple to follow. -In this web hook handler we look through each commit that was just pushed, we look for the string 'Signed-off-by' in the commit message and finally we POST via HTTP to the `/repos///statuses/` API endpoint with the status. +Ελπίζουμε ότι είναι αρκετά απλό, για να το καταλάβετε. +Σε αυτόν τον χειριστή αγκίστρων ιστού εξετάζουμε κάθε υποβολή που μόλις ωθήθηκε, αναζητούμε τη συμβολοσειρά `Signed-off-by` στο μήνυμα της υποβολής και τέλος κάνουμε POST μέσω HTTP στο σημείο σύνδεσης `/repos/<χρήστης>/<αποθετήριο>/statuses/` την κατάσταση. -In this case you can send a state ('success', 'failure', 'error'), a description of what happened, a target URL the user can go to for more information and a ``context'' in case there are multiple statuses for a single commit. -For example, a testing service may provide a status and a validation service like this may also provide a status -- the ``context'' field is how they're differentiated. +Σε αυτήν την περίπτωση μπορούμε να στείλουμε μια κατάσταση ('επιτυχία', 'αποτυχία', 'σφάλμα' ('success', 'failure', 'error')), μια περιγραφή του τι συνέβη, μια διεύθυνση URL στην οποία μπορεί να μεταβεί ο χρήστης για περισσότερες πληροφορίες και ένα "`πλαίσιο`" (context) σε περίπτωση που υπάρχουν πολλαπλές καταστάσεις για μία μόνο υποβολή. +Για παράδειγμα, μια υπηρεσία δοκιμών μπορεί να παρέχει μια κατάσταση και μια υπηρεσία επικύρωσης, όπως αυτή, μπορεί επίσης να παρέχει μια κατάσταση —το πεδίο "`context`" είναι εκεί όπου διαφοροποιούνται. -If someone opens a new Pull Request on GitHub and this hook is set up, you may see something like <<_commit_status>>. +Εάν κάποιος ανοίξει ένα νέο αίτημα έλξης στο GitHub και αυτό το άγκιστρο έχει στηθεί, ίσως δούμε κάτι σαν την εικόνα <> -[[_commit_status]] -.Commit status via the API. -image::images/scripting-07-status.png[Commit status] +[[r_commit_status]] +.Κατάσταση υποβολής μέσα από το API. +image::images/scripting-07-status.png[Κατάσταση υποβολής.] -You can now see a little green check mark next to the commit that has a ``Signed-off-by'' string in the message and a red cross through the one where the author forgot to sign off. -You can also see that the Pull Request takes the status of the last commit on the branch and warns you if it is a failure. -This is really useful if you're using this API for test results so you don't accidentally merge something where the last commit is failing tests. +Τώρα μπορούμε να δούμε ένα μικρό πράσινο σημάδι ελέγχου δίπλα στην υποβολή που περιέχει μια συμβολοσειρά "`Signed-off-by`" στο μήνυμα και ένα κόκκινο σταυρό σε εκείνο στο οποίο ο συγγραφέας του ξέχασε να υπογράψει. +Μπορούμε επίσης να δούμε ότι το αίτημα έλξης την κατάσταση της τελευταίας υποβολής στον κλάδο και μας προειδοποιεί εάν έχει αποτύχει. +Αυτό είναι πραγματικά χρήσιμο εάν χρησιμοποιούμε αυτό το API για αποτελέσματα δοκιμών, έτσι ώστε να μην συγχωνεύσουμε κατά λάθος κάτι του οποίου η τελευταία υποβολή είχε αποτύχει. ==== Octokit -Though we've been doing nearly everything through `curl` and simple HTTP requests in these examples, several open-source libraries exist that make this API available in a more idiomatic way. -At the time of this writing, the supported languages include Go, Objective-C, Ruby, and .NET. -Check out http://github.com/octokit[] for more information on these, as they handle much of the HTTP for you. +Παρόλο που σε αυτά τα παραδείγματα κάναμε σχεδόν τα πάντα μέσα από την `curl` και απλά αιτήματα HTTP, υπάρχουν αρκετές βιβλιοθήκες ανοιχτού κώδικα που κάνουν αυτό το API διαθέσιμο με πιο ιδιωματικό τρόπο. +Όταν γράφεται αυτό το κείμενο, οι υποστηριζόμενες γλώσσες περιλαμβάνουν τις Go, Objective-C, Ruby και .NET. +Για περισσότερες πληροφορίες σχετικά με αυτά, δεδομένου ότι χειρίζονται μεγάλο μέρος του HTTP για εμάς, μπορούμε να ανατρέξουμε στην https://github.com/octokit[^]. -Hopefully these tools can help you customize and modify GitHub to work better for your specific workflows. -For complete documentation on the entire API as well as guides for common tasks, check out https://developer.github.com[]. +Αυτά τα εργαλεία θα μας βοηθήσουν να εξατομικεύσουμε και να τροποποιήσουμε το GitHub ώστε να λειτουργεί καλύτερα για τις συγκεκριμένες ροές εργασίας μας. +Πλήρη τεκμηρίωση σχετικά με ολόκληρο το API καθώς και οδηγούς για συνήθεις εργασίες, μπρορούμε να βρούμε στην σελίδα https://docs.github.com/[^]. diff --git a/book/07-git-tools/1-git-tools.asc b/book/07-git-tools/1-git-tools.asc deleted file mode 100644 index 073eae5fd..000000000 --- a/book/07-git-tools/1-git-tools.asc +++ /dev/null @@ -1,42 +0,0 @@ -[[_git_tools]] -== Git Tools - -By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. -You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. - -Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point. - -include::sections/revision-selection.asc[] - -include::sections/interactive-staging.asc[] - -include::sections/stashing-cleaning.asc[] - -include::sections/signing.asc[] - -include::sections/searching.asc[] - -include::sections/rewriting-history.asc[] - -include::sections/reset.asc[] - -include::sections/advanced-merging.asc[] - -include::sections/rerere.asc[] - -include::sections/debugging.asc[] - -include::sections/submodules.asc[] - -include::sections/bundling.asc[] - -include::sections/replace.asc[] - -include::sections/credentials.asc[] - -=== Summary - -You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. -When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. -If you want to use subprojects in your project, you’ve learned how to accommodate those needs. -At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so. diff --git a/book/07-git-tools/callouts/1.pdf b/book/07-git-tools/callouts/1.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/10.pdf b/book/07-git-tools/callouts/10.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/10.png b/book/07-git-tools/callouts/10.png index 80872645f..821ef4cee 100644 Binary files a/book/07-git-tools/callouts/10.png and b/book/07-git-tools/callouts/10.png differ diff --git a/book/07-git-tools/callouts/2.pdf b/book/07-git-tools/callouts/2.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/2.png b/book/07-git-tools/callouts/2.png index 4bb6abc07..e881df133 100644 Binary files a/book/07-git-tools/callouts/2.png and b/book/07-git-tools/callouts/2.png differ diff --git a/book/07-git-tools/callouts/3.pdf b/book/07-git-tools/callouts/3.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/3.png b/book/07-git-tools/callouts/3.png index e132a559f..200d58251 100644 Binary files a/book/07-git-tools/callouts/3.png and b/book/07-git-tools/callouts/3.png differ diff --git a/book/07-git-tools/callouts/4.pdf b/book/07-git-tools/callouts/4.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/5.pdf b/book/07-git-tools/callouts/5.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/5.png b/book/07-git-tools/callouts/5.png index 76375432e..e52d3a842 100644 Binary files a/book/07-git-tools/callouts/5.png and b/book/07-git-tools/callouts/5.png differ diff --git a/book/07-git-tools/callouts/6.pdf b/book/07-git-tools/callouts/6.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/7.pdf b/book/07-git-tools/callouts/7.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/7.png b/book/07-git-tools/callouts/7.png index 009bf1a1c..f07d991f9 100644 Binary files a/book/07-git-tools/callouts/7.png and b/book/07-git-tools/callouts/7.png differ diff --git a/book/07-git-tools/callouts/8.pdf b/book/07-git-tools/callouts/8.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/callouts/8.png b/book/07-git-tools/callouts/8.png index 2470994e8..c99ae9e7a 100644 Binary files a/book/07-git-tools/callouts/8.png and b/book/07-git-tools/callouts/8.png differ diff --git a/book/07-git-tools/callouts/9.pdf b/book/07-git-tools/callouts/9.pdf old mode 100755 new mode 100644 diff --git a/book/07-git-tools/git-credential-read-only b/book/07-git-tools/git-credential-read-only old mode 100755 new mode 100644 index ec8f4d1f4..9e984dca9 --- a/book/07-git-tools/git-credential-read-only +++ b/book/07-git-tools/git-credential-read-only @@ -11,7 +11,7 @@ OptionParser.new do |opts| end.parse! exit(0) unless ARGV[0].downcase == 'get' # <2> -exit(0) unless File.exists? path +exit(0) unless File.exist? path known = {} # <3> while line = STDIN.gets @@ -22,7 +22,7 @@ end File.readlines(path).each do |fileline| # <4> prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first - if prot == known['protocol'] and host == known['host'] then + if prot == known['protocol'] and host == known['host'] and user == known['username'] then puts "protocol=#{prot}" puts "host=#{host}" puts "username=#{user}" diff --git a/book/07-git-tools/images/double-dot.png b/book/07-git-tools/images/double-dot.png deleted file mode 100644 index a95ba68a9..000000000 Binary files a/book/07-git-tools/images/double-dot.png and /dev/null differ diff --git a/book/07-git-tools/images/replace1.png b/book/07-git-tools/images/replace1.png deleted file mode 100644 index 100610c51..000000000 Binary files a/book/07-git-tools/images/replace1.png and /dev/null differ diff --git a/book/07-git-tools/images/replace2.png b/book/07-git-tools/images/replace2.png deleted file mode 100644 index 58fb531d4..000000000 Binary files a/book/07-git-tools/images/replace2.png and /dev/null differ diff --git a/book/07-git-tools/images/replace3.png b/book/07-git-tools/images/replace3.png deleted file mode 100644 index 3fafe80a5..000000000 Binary files a/book/07-git-tools/images/replace3.png and /dev/null differ diff --git a/book/07-git-tools/images/replace4.png b/book/07-git-tools/images/replace4.png deleted file mode 100644 index 021319ef7..000000000 Binary files a/book/07-git-tools/images/replace4.png and /dev/null differ diff --git a/book/07-git-tools/images/replace5.png b/book/07-git-tools/images/replace5.png deleted file mode 100644 index 74b8523e0..000000000 Binary files a/book/07-git-tools/images/replace5.png and /dev/null differ diff --git a/book/07-git-tools/images/rerere1.png b/book/07-git-tools/images/rerere1.png deleted file mode 100644 index 06bcef32d..000000000 Binary files a/book/07-git-tools/images/rerere1.png and /dev/null differ diff --git a/book/07-git-tools/images/rerere2.png b/book/07-git-tools/images/rerere2.png deleted file mode 100644 index 36021e32f..000000000 Binary files a/book/07-git-tools/images/rerere2.png and /dev/null differ diff --git a/book/07-git-tools/images/rerere3.png b/book/07-git-tools/images/rerere3.png deleted file mode 100644 index 83e29b754..000000000 Binary files a/book/07-git-tools/images/rerere3.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-checkout.png b/book/07-git-tools/images/reset-checkout.png deleted file mode 100644 index 69b2f892f..000000000 Binary files a/book/07-git-tools/images/reset-checkout.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex1.png b/book/07-git-tools/images/reset-ex1.png deleted file mode 100644 index b1adbfe9c..000000000 Binary files a/book/07-git-tools/images/reset-ex1.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex2.png b/book/07-git-tools/images/reset-ex2.png deleted file mode 100644 index 6cac4be0a..000000000 Binary files a/book/07-git-tools/images/reset-ex2.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex3.png b/book/07-git-tools/images/reset-ex3.png deleted file mode 100644 index e29b78c48..000000000 Binary files a/book/07-git-tools/images/reset-ex3.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex4.png b/book/07-git-tools/images/reset-ex4.png deleted file mode 100644 index 0fb210a9a..000000000 Binary files a/book/07-git-tools/images/reset-ex4.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex5.png b/book/07-git-tools/images/reset-ex5.png deleted file mode 100644 index 11b00201d..000000000 Binary files a/book/07-git-tools/images/reset-ex5.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-ex6.png b/book/07-git-tools/images/reset-ex6.png deleted file mode 100644 index 091285eea..000000000 Binary files a/book/07-git-tools/images/reset-ex6.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-hard.png b/book/07-git-tools/images/reset-hard.png deleted file mode 100644 index f2f8e0030..000000000 Binary files a/book/07-git-tools/images/reset-hard.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-mixed.png b/book/07-git-tools/images/reset-mixed.png deleted file mode 100644 index d6ae60abe..000000000 Binary files a/book/07-git-tools/images/reset-mixed.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-path1.png b/book/07-git-tools/images/reset-path1.png deleted file mode 100644 index 0036c4093..000000000 Binary files a/book/07-git-tools/images/reset-path1.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-path2.png b/book/07-git-tools/images/reset-path2.png deleted file mode 100644 index ca117fb79..000000000 Binary files a/book/07-git-tools/images/reset-path2.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-path3.png b/book/07-git-tools/images/reset-path3.png deleted file mode 100644 index a6cb5d43d..000000000 Binary files a/book/07-git-tools/images/reset-path3.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-soft.png b/book/07-git-tools/images/reset-soft.png deleted file mode 100644 index aab1fe6bd..000000000 Binary files a/book/07-git-tools/images/reset-soft.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-squash-r1.png b/book/07-git-tools/images/reset-squash-r1.png deleted file mode 100644 index 7bd260ad2..000000000 Binary files a/book/07-git-tools/images/reset-squash-r1.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-squash-r2.png b/book/07-git-tools/images/reset-squash-r2.png deleted file mode 100644 index 46f9ea4e3..000000000 Binary files a/book/07-git-tools/images/reset-squash-r2.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-squash-r3.png b/book/07-git-tools/images/reset-squash-r3.png deleted file mode 100644 index 23f82730d..000000000 Binary files a/book/07-git-tools/images/reset-squash-r3.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-start.png b/book/07-git-tools/images/reset-start.png deleted file mode 100644 index bbfa8eab9..000000000 Binary files a/book/07-git-tools/images/reset-start.png and /dev/null differ diff --git a/book/07-git-tools/images/reset-workflow.png b/book/07-git-tools/images/reset-workflow.png deleted file mode 100644 index 43bd27f38..000000000 Binary files a/book/07-git-tools/images/reset-workflow.png and /dev/null differ diff --git a/book/07-git-tools/images/undomerge-reset.png b/book/07-git-tools/images/undomerge-reset.png deleted file mode 100644 index 99bd7f792..000000000 Binary files a/book/07-git-tools/images/undomerge-reset.png and /dev/null differ diff --git a/book/07-git-tools/images/undomerge-revert.png b/book/07-git-tools/images/undomerge-revert.png deleted file mode 100644 index 1f32a63eb..000000000 Binary files a/book/07-git-tools/images/undomerge-revert.png and /dev/null differ diff --git a/book/07-git-tools/images/undomerge-revert2.png b/book/07-git-tools/images/undomerge-revert2.png deleted file mode 100644 index af9e58877..000000000 Binary files a/book/07-git-tools/images/undomerge-revert2.png and /dev/null differ diff --git a/book/07-git-tools/images/undomerge-revert3.png b/book/07-git-tools/images/undomerge-revert3.png deleted file mode 100644 index c1e8e8ba4..000000000 Binary files a/book/07-git-tools/images/undomerge-revert3.png and /dev/null differ diff --git a/book/07-git-tools/images/undomerge-start.png b/book/07-git-tools/images/undomerge-start.png deleted file mode 100644 index 5891cbedf..000000000 Binary files a/book/07-git-tools/images/undomerge-start.png and /dev/null differ diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 7e0477977..02fb60225 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -1,28 +1,28 @@ -[[_advanced_merging]] -=== Advanced Merging +[[r_advanced_merging]] +=== Προχωρημένη Συγχώνευση -Merging in Git is typically fairly easy. -Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be surprised by one enormous conflict at the end of the series. +Οι συγχωνεύσεις στο Git είναι συνήθως αρκετά εύκολη υπόθεση. +Το ότι το Git καθιστά εύκολη τη συγχώνευση ενός κλάδου πολλές φορές, σημαίνει ότι μπορούμε να έχουμε έναν πολύ μακρόβιο κλάδο, τον οποίο να ενημερώνουμε κάθε τόσο, επιλύοντας μικρές συγκρούσεις συχνά, αντί να εκπλαγούμε από μια τεράστια σύγκρουση στο τέλος. -However, sometimes tricky conflicts do occur. -Unlike some other version control systems, Git does not try to be overly clever about merge conflict resolution. -Git's philosophy is to be smart about determining when a merge resolution is unambiguous, but if there is a conflict, it does not try to be clever about automatically resolving it. -Therefore, if you wait too long to merge two branches that diverge quickly, you can run into some issues. +Εντούτοις, μερικές φορές προκύπτουν δύσκολες συγκρούσεις. +Σε αντίθεση με κάποια άλλα συστήματα ελέγχου εκδόσεων, το Git δεν προσπαθεί να είναι υπερβολικά έξυπνο όσον αφορά στην επίλυση συγκρούσεων. +Η φιλοσοφία του Git είναι να είναι έξυπνο στο να προσδιορίζει πότε μια επίλυση συγχώνευσης μπορεί να γίνει χωρίς συγκρούσεις αλλά εφόσον υπάρχει σύγκρουση, δεν προσπαθεί να είναι έξυπνο για την αυτόματη επίλυσή της. +Επομένως, αν περιμένουμε πολύ για να συγχωνεύσουμε δύο κλάδους που αποκλίνουν με ταχύτητα, μπορεί να αντιμετωπίσουμε προβλήματα. -In this section, we'll go over what some of those issues might be and what tools Git gives you to help handle these more tricky situations. -We'll also cover some of the different, non-standard types of merges you can do, as well as see how to back out of merges that you've done. +Σε αυτήν την ενότητα, θα αναφερθούμε σε τι προβλήματα μπορεί να συναντήσουμε και τι εργαλεία μας δίνει το Git για να βοηθήσουμε να χειριστούμε αυτές δύσκολες καταστάσεις. +Θα καλύψουμε επίσης μερικούς από τους διαφορετικούς, μη τυποποιημένους τύπους συγχώνευσης που μπορούμε να κάνουμε καθώς και να δούμε πώς μπορούμε να βγούμε από συγχωνεύσεις που έχουμε ήδη κάνει. -==== Merge Conflicts +==== Συγκρούσεις συγχωνεύσεων -While we covered some basics on resolving merge conflicts in <<_basic_merge_conflicts>>, for more complex conflicts, Git provides a few tools to help you figure out what's going on and how to better deal with the conflict. +Έχουμε καλύψει κάποια βασικά στοιχεία για την επίλυση των συγκρούσεων συγχώνευσης στην ενότητα <>· για πιο πολύπλοκες συγκρούσεις το Git παρέχει μερικά εργαλεία για να μας βοηθήσει να καταλάβουμε τι συμβαίνει και πώς να αντιμετωπίσουμε καλύτερα τη σύγκρουση. -First of all, if at all possible, try to make sure your working directory is clean before doing a merge that may have conflicts. -If you have work in progress, either commit it to a temporary branch or stash it. -This makes it so that you can undo *anything* you try here. -If you have unsaved changes in your working directory when you try a merge, some of these tips may help you lose that work. +Πρώτα απ' όλα, αν είναι δυνατόν, προσπαθούμε να βεβαιωθούμε ότι ο κατάλογος εργασίας μας είναι καθαρός πριν κάνουμε μια συγχώνευση που μπορεί να έχει συγκρούσεις. +Εάν έχουμε εργασία σε εξέλιξη, είτε την υποβάλουμε σε έναν προσωρινό κλάδο είτε την παρακαταθέτουμε (stash). +Αν το κάνουμε αυτό, τότε μπορούμε να ακυρώσουμε *ο,τιδήποτε* δοκιμάσουμε εδώ. +Εάν έχουμε μη αποθηκευμένες αλλαγές στον κατάλογο εργασίας μας όταν συγχωνεύουμε, ορισμένες από αυτές τις συμβουλές μπορεί να μας κάνουν να χάσουμε αυτήν την εργασία. -Let's walk through a very simple example. -We have a super simple Ruby file that prints 'hello world'. +Ας δούμε ένα πολύ απλό παράδειγμα. +Έχουμε ένα πολύ απλό αρχείο Ruby που εκτυπώνει 'hello world'. [source,ruby] ---- @@ -35,8 +35,8 @@ end hello() ---- -In our repository, we create a new branch named `whitespace` and proceed to change all the Unix line endings to DOS line endings, essentially changing every line of the file, but just with whitespace. -Then we change the line ``hello world'' to ``hello mundo''. +Στο αποθετήριό μας, δημιουργούμε έναν νέο κλάδο που ονομάζεται `whitespace` και προχωράμε στην αλλαγή όλων των τερματισμών γραμμής Unix σε τερματισούς γραμμής DOS, δηλαδή ουσιαστικά αλλάζουμε κάθε γραμμή του αρχείου, αλλά μόνο με κενά. +Στη συνέχεια, αλλάζουμε τη γραμμή "`hello world`" στο "`hello mundo`". [source,console] ---- @@ -45,8 +45,8 @@ Switched to a new branch 'whitespace' $ unix2dos hello.rb unix2dos: converting file hello.rb to DOS format ... -$ git commit -am 'converted hello.rb to DOS' -[whitespace 3270f76] converted hello.rb to DOS +$ git commit -am 'Convert hello.rb to DOS' +[whitespace 3270f76] Convert hello.rb to DOS 1 file changed, 7 insertions(+), 7 deletions(-) $ vim hello.rb @@ -65,12 +65,12 @@ index ac51efd..e85207e 100755 hello() -$ git commit -am 'hello mundo change' -[whitespace 6d338d2] hello mundo change +$ git commit -am 'Use Spanish instead of English' +[whitespace 6d338d2] Use Spanish instead of English 1 file changed, 1 insertion(+), 1 deletion(-) ---- -Now we switch back to our `master` branch and add some documentation for the function. +Τώρα επιστρέφουμε στον κλάδο `master` και προσθέτουμε κάποια τεκμηρίωση στη συνάρτηση. [source,console] ---- @@ -91,12 +91,12 @@ index ac51efd..36c06c8 100755 puts 'hello world' end -$ git commit -am 'document the function' -[master bec6336] document the function +$ git commit -am 'Add comment documenting the function' +[master bec6336] Add comment documenting the function 1 file changed, 1 insertion(+) ---- -Now we try to merge in our `whitespace` branch and we'll get conflicts because of the whitespace changes. +Προσπαθούμε να συγχωνέψουμε τον κλάδο μας `whitespace`· θα έχουμε συγκρούσεις εξαιτίας των αλλαγών στα λευκά διαστήματα. [source,console] ---- @@ -106,12 +106,12 @@ CONFLICT (content): Merge conflict in hello.rb Automatic merge failed; fix conflicts and then commit the result. ---- -[[_abort_merge]] -===== Aborting a Merge +[[r_abort_merge]] +===== Απόρριψη συγχώνευσης -We now have a few options. -First, let's cover how to get out of this situation. -If you perhaps weren't expecting conflicts and don't want to quite deal with the situation yet, you can simply back out of the merge with `git merge --abort`. +Έχουμε κάποιες επιλογές. +Πρώτον, ας δούμε πώς θα βγούμε από αυτήν την κατάσταση. +Εάν δεν αναμέναμε τις συγκρούσεις και δεν θέλουμε να ασχοληθούμε με αυτήν την κατάσταση, μπορούμε απλά να βγούμε από τη συγχώνευση με την εντολή `git merge --abort`. [source,console] ---- @@ -125,21 +125,21 @@ $ git status -sb ## master ---- -The `git merge --abort` option tries to revert back to your state before you ran the merge. -The only cases where it may not be able to do this perfectly would be if you had unstashed, uncommitted changes in your working directory when you ran it, otherwise it should work fine. +Η επιλογή `git merge --abort` προσπαθεί να μας επιστρέψει στην κατάστασή μας πριν εκτελέσουμε τη συγχώνευση. +Οι μόνες περιπτώσεις στις οποίες μπορεί να μην είναι σε θέση να το κάνει τέλεια, είναι εάν είχαμε μη παρακατατεθειμένες, μη υποβεβλημένες αλλαγές στον κατάλογο εργασίας όταν την τρέξαμε, αλλιώς θα πρέπει να δουλέψει μια χαρά. -If for some reason you just want to start over, you can also run `git reset --hard HEAD`, and your repository will be back to the last committed state. -Remember that any uncommitted work will be lost, so make sure you don't want any of your changes. +Αν για κάποιο λόγο θέλουμε απλώς να αρχίσουμε από την αρχή, μπορούμε επίσης να εκτελέσουμε την `git reset --hard HEAD` και το αποθετήριό μας θα επιστρέψει στην τελευταία υποβεβλημένη κατάσταση. +Είναι σημαντικό να Θυμόμαστε ότι οποιαδήποτε μη υποβεβλημένη εργασία θα χαθεί, οπότε πρέπει να είμαστε σίγουροι ότι δεν θέλουμε αυτές τις αλλαγές. -===== Ignoring Whitespace +===== Αγνόηση των λευκών χαρακτήρων -In this specific case, the conflicts are whitespace related. -We know this because the case is simple, but it's also pretty easy to tell in real cases when looking at the conflict because every line is removed on one side and added again on the other. -By default, Git sees all of these lines as being changed, so it can't merge the files. +Στη συγκεκριμένη περίπτωση οι συγκρούσεις σχετίζονται με τους λευκούς χαρακτήρες. +Το γνωρίζουμε αυτό διότι η περίπτωση είναι απλή αλλά είναι επίσης πολύ εύκολο να το καταλάβει κανείς και στην πραγματικότητα όταν εξετάζουμε τη σύγκρουση επειδή κάθε γραμμή έχει αφαιρεθεί από το ένα αρχείο και έχει προστεθεί ξανά στο άλλο. +Εκ προεπιλογής, το Git βλέπει όλες αυτές τις γραμμές ως τροποποιημένες, οπότε δεν μπορεί να συγχωνεύσει τα αρχεία. -The default merge strategy can take arguments though, and a few of them are about properly ignoring whitespace changes. -If you see that you have a lot of whitespace issues in a merge, you can simply abort it and do it again, this time with `-Xignore-all-space` or `-Xignore-space-change`. -The first option ignores whitespace **completely** when comparing lines, the second treats sequences of one or more whitespace characters as equivalent. +Η προεπιλεγμένη στρατηγική συγχώνευσης πάντως μπορεί να πάρει ορίσματα και μερικά από αυτά είναι για να αγνοούν σωστά τις αλλαγές στους λευκούς χαρακτήρες. +Αν δούμε ότι έχουμε πολλά προβλήματα με τους λευκούς χαρακτήρες σε μια συγχώνευση, μπορούμε απλά να την ακυρώσουμε και να την ξανακάνουμε, αυτήν τη φορά με το την επιλογή `-Xignore-all-space` ή την `-Xignore-space-change`. +Η πρώτη επιλογή αγνοεί *εντελώς* τους λευκούς χαρακτήρες κατά τη σύγκριση γραμμών, ενώ η δεύτερη αντιμετωπίζει τις αλληλουχίες ενός ή περισσότερων λευκών χαρακτήρων ως ισοδύναμες. [source,console] ---- @@ -150,28 +150,28 @@ Merge made by the 'recursive' strategy. 1 file changed, 1 insertion(+), 1 deletion(-) ---- -Since in this case, the actual file changes were not conflicting, once we ignore the whitespace changes, everything merges just fine. +Δεδομένου ότι σε αυτήν την περίπτωση, οι πραγματικές αλλαγές του αρχείου δεν δημιουργούσαν συγκρούσεις, όταν αγνοήσουμε τις αλλαγές στους λευκούς χαρακτήρες, όλα πάνε μια χαρά. -This is a lifesaver if you have someone on your team who likes to occasionally reformat everything from spaces to tabs or vice-versa. +Αυτό είναι σωτήριο εάν έχουμε κάποιον στην ομάδα μας που του αρέσει να επαναμορφοποιεί περιστασιακά τα πάντα από διαστήματα σε στηλοθέτες ή το αντίστροφο. -[[_manual_remerge]] -===== Manual File Re-merging +[[r_manual_remerge]] +===== Χειροκίνητη επανασυγχώνευση αρχείου -Though Git handles whitespace pre-processing pretty well, there are other types of changes that perhaps Git can't handle automatically, but are scriptable fixes. -As an example, let's pretend that Git could not handle the whitespace change and we needed to do it by hand. +Παρόλο που το Git επεξεργάζεται την προεπεξεργασία των λευκών χώρων αρκετά καλά, υπάρχουν και άλλα είδη αλλαγών που ίσως το Git δεν μπορεί να χειριστεί αυτόματα αλλά είναι αλλαγές που μπορούν να διορθωθούν με το κατάλληλο script. +Για παράδειγμα, ας υποθέσουμε ότι το Git δεν μπόρεσε να χειριστεί την αλλαγή του λευκού χαρακτήρα και έπρεπε να τη χειριστούμε χειροκίνητα. -What we really need to do is run the file we're trying to merge in through a `dos2unix` program before trying the actual file merge. -So how would we do that? +Αυτό που πραγματικά πρέπει να κάνουμε είναι να περάσουμε το αρχείο που προσπαθούμε να συγχωνεύσουμε μέσα από το πρόγραμμα `dos2unix` προτού δοκιμάσουμε την πραγματική συγχώνευση αρχείων. +Πώς το κάνουμε αυτό; -First, we get into the merge conflict state. -Then we want to get copies of my version of the file, their version (from the branch we're merging in) and the common version (from where both sides branched off). -Then we want to fix up either their side or our side and re-try the merge again for just this single file. +Πρώτα, μπαίνουμε στην κατάσταση σύγκρουσης συγχώνευσης. +Στη συνέχεια, θέλουμε να λάβουμε αντίγραφα της δικής μας έκδοσης του αρχείου, της δικής τους (από τον κλάδο που συγχωνεύουμε) έκδοσης και της κοινής έκδοσης (από όπου και οι δύο πλευρές διακλαδίζονται). +Στη συνέχεια, θέλουμε να διορθώσουμε είτε την πλευρά τους είτε την πλευρά μας και να ξαναδοκιμάσουμε τη συγχώνευση και πάλι μόνο για αυτό το μοναδικό αρχείο. -Getting the three file versions is actually pretty easy. -Git stores all of these versions in the index under ``stages'' which each have numbers associated with them. -Stage 1 is the common ancestor, stage 2 is your version and stage 3 is from the `MERGE_HEAD`, the version you're merging in (``theirs''). +Η λήψη των τριών εκδόσεων αρχείων είναι πραγματικά εύκολη. +Το Git αποθηκεύει όλες αυτές τις εκδόσεις στο ευρετήριο κάτω από τα "`stages`" τα οποία έχουν το καθένα από αυτά έναν συσχετισμένο αριθμό. +Το στάδιο 1 είναι ο κοινός πρόγονος, το στάδιο 2 είναι η δική μας έκδοση και το στάδιο 3 είναι από το `MERGE_HEAD`, δηλαδή, την έκδοση που συγχωνεύουμε ("`theirs`"). -You can extract a copy of each of these versions of the conflicted file with the `git show` command and a special syntax. +Μπορούμε να εξάγουμε ένα αντίγραφο από καθεμία από αυτές τις εκδόσεις του αρχείου που βρίσκεται σε σύγκρουση με την εντολή `git show` και μια ειδική σύνταξη. [source,console] ---- @@ -180,7 +180,7 @@ $ git show :2:hello.rb > hello.ours.rb $ git show :3:hello.rb > hello.theirs.rb ---- -If you want to get a little more hard core, you can also use the `ls-files -u` plumbing command to get the actual SHA-1s of the Git blobs for each of these files. +Αν θέλουμε να το γίνουμε λίγο πιο σκληροπυρηνικοί, μπορούμε επίσης να χρησιμοποιήσουμε την εντολή `ls-files -u` για να λάβουμε τα πραγματικά SHA-1s του Git blobs για καθένα από αυτά τα αρχεία. [source,console] ---- @@ -190,9 +190,9 @@ $ git ls-files -u 100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb ---- -The `:1:hello.rb` is just a shorthand for looking up that blob SHA-1. +Το `:1:hello.rb` είναι απλά μια συντομογραφία για να αναζητήσει κανείς τον αριθμό SHA-1 εκείνου του blob. -Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known `git merge-file` command which does just that. +Τώρα που έχουμε το περιεχόμενο και των τριών σταδίων στον κατάλογο εργασίας μας, μπορούμε να διορθώσουμε χειροκίνητα τη δική τους για να διορθώσουμε το πρόβλημα των λευκών διαστημάτων χώρου και να συγχωνεύσουμε ξανά το αρχείο με την ελάχιστα γνωστή εντολή `git merge-file` που κάνει ακριβώς αυτό. [source,console] ---- @@ -219,14 +219,14 @@ index 36c06c8,e85207e..0000000 hello() ---- -At this point we have nicely merged the file. -In fact, this actually works better than the `ignore-space-change` option because this actually fixes the whitespace changes before merge instead of simply ignoring them. -In the `ignore-space-change` merge, we actually ended up with a few lines with DOS line endings, making things mixed. +Σε αυτό το σημείο έχουμε συγχωνεύσει το αρχείο ωραιότατα. +Στην πραγματικότητα, αυτός ο τρόπος είναι καλύτερος από την επιλογή `ignore-space-change`, διότι επιδιορθώνει πραγματικά τις αλλαγές των λευκών διαστημάτω πριν από τη συγχώνευση αντί απλά να τις αγνοεί. +Στη συγχώνευση `ignore-space-change`, στην πραγματικότητα καταλήξαμε με μερικές γραμμές με τερματισμό γραμμής DOS και με μερικές γραμμές με τερματισμό γραμμής Unix, άρα μπερδέψαμε τα πράγματα. -If you want to get an idea before finalizing this commit about what was actually changed between one side or the other, you can ask `git diff` to compare what is in your working directory that you're about to commit as the result of the merge to any of these stages. -Let's go through them all. +Εάν θέλουμε να πάρουμε μια ιδέα πριν οριστικοποιήσουμε αυτήν την υποβολή για το τι πραγματικά άλλαξε μεταξύ της μιας ή της άλλης πλευράς, μπορούμε να ζητήσουμε από το `git diff` να συγκρίνουμε τι υπάρχει στον κατάλογο εργασίας που πρόκειται να υποβάλουμε ως αποτέλεσμα της συγχώνευσης σε οποιοδήποτε από αυτά τα στάδια. +Ας τα δούμε όλα. -To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours` +Για να συγκρίνουμε το αποτέλεσμά μας με αυτό που είχαμε στον κλάδο μας πριν από τη συγχώνευση, με άλλα λόγια, για να δούμε τι εισήγαγε η συγχώνευση, μπορούμε να εκτελέσουμε την `git diff --ours` [source,console] ---- @@ -247,10 +247,10 @@ index 36c06c8..44d0a25 100755 hello() ---- -So here we can easily see that what happened in our branch, what we're actually introducing to this file with this merge, is changing that single line. +Είναι φανερό ότι αυτό που συνέβη στον κλάδο μας, αυτό που εισάγουμε στην πραγματικότητα σε αυτό το αρχείο με αυτήν τη συγχώνευση, αλλάζει μία και μόνο γραμμή. -If we want to see how the result of the merge differed from what was on their side, you can run `git diff --theirs`. -In this and the following example, we have to use `-b` to strip out the whitespace because we're comparing it to what is in Git, not our cleaned up `hello.theirs.rb` file. +Αν θέλουμε να δούμε πώς το αποτέλεσμα της συγχώνευσης διέφερε από αυτό που υπήρχε στη δική τους πλευρά, μπορούμε να εκτελέσουμε την `git diff --theirs`. +Σε αυτό και στο επόμενο παράδειγμα, πρέπει να χρησιμοποιήσουμε την επιλογή `-b` για να εξαλείψουμε τον λευκό χαρακτήρα επειδή το συγκρίνουμε με αυτό που υπάρχει στο Git, όχι το καθαρισμένο αρχείο μας `hello.theirs.rb`. [source,console] ---- @@ -269,7 +269,7 @@ index e85207e..44d0a25 100755 end ---- -Finally, you can see how the file has changed from both sides with `git diff --base`. +Τέλος, βλέπουμε πώς το αρχείο έχει αλλάξει και από τις δύο πλευρές με το `git diff --base`. [source,console] ---- @@ -291,7 +291,7 @@ index ac51efd..44d0a25 100755 hello() ---- -At this point we can use the `git clean` command to clear out the extra files we created to do the manual merge but no longer need. +Σε αυτό το σημείο μπορούμε να χρησιμοποιήσουμε την εντολή `git clean` για να διαγράψουμε τα επιπλέον αρχεία που δημιουργήσαμε ώστε να κάνουμε τη χειροκίνητη συγχώνευση αλλά δεν χρειαζόμαστε πλέον. [source,console] ---- @@ -301,29 +301,29 @@ Removing hello.ours.rb Removing hello.theirs.rb ---- -[[_checking_out_conflicts]] +[[r_checking_out_conflicts]] ===== Checking Out Conflicts -Perhaps we're not happy with the resolution at this point for some reason, or maybe manually editing one or both sides still didn't work well and we need more context. +Ίσως δεν είμαστε ευχαριστημένοι με την επίλυση σε αυτό το σημείο για κάποιο λόγο, ή ίσως η χειροκίνητη επεξεργασία μιας ή και των δύο πλευρών ακόμα δεν λειτούργησε καλά και χρειαζόμαστε περισσότερο περιβάλλον. -Let's change up the example a little. -For this example, we have two longer lived branches that each have a few commits in them but create a legitimate content conflict when merged. +Ας δούμε ένα λίγο διαφορετικό παράδειγμα. +Για αυτό το παράδειγμα, έχουμε δύο μακροβιότερους κλάδους, ο καθένας από τους οποίους έχει μερικές υποβολές, αλλά όταν συγχωνεύονται δημιουργείται σύγκρουση περιεχομένου. [source,console] ---- $ git log --graph --oneline --decorate --all -* f1270f7 (HEAD, master) update README -* 9af9d3b add a README -* 694971d update phrase to hola world -| * e3eb223 (mundo) add more tests -| * 7cff591 add testing script -| * c3ffff1 changed text to hello mundo +* f1270f7 (HEAD, master) Update README +* 9af9d3b Create README +* 694971d Update phrase to 'hola world' +| * e3eb223 (mundo) Add more tests +| * 7cff591 Create initial testing script +| * c3ffff1 Change text to 'hello mundo' |/ -* b7dcc89 initial hello world code +* b7dcc89 Initial hello world code ---- -We now have three unique commits that live only on the `master` branch and three others that live on the `mundo` branch. -If we try to merge the `mundo` branch in, we get a conflict. +Τώρα έχουμε τρεις μοναδικές υποβολές που ζουν μόνο στον κλάδο `master` και τρεις άλλες που ζουν στον κλάδο `mundo`. +Αν προσπαθήσουμε να συγχωνεύσουμε τον κλάδο `mundo`, παίρνουμε σύγκρουση. [source,console] ---- @@ -333,8 +333,8 @@ CONFLICT (content): Merge conflict in hello.rb Automatic merge failed; fix conflicts and then commit the result. ---- -We would like to see what the merge conflict is. -If we open up the file, we'll see something like this: +Θα θέλαμε να δούμε τι είναι αυτή η σύγκρουση. +Αν ανοίξουμε το αρχείο, θα δούμε κάτι τέτοιο: [source,ruby] ---- @@ -351,25 +351,25 @@ end hello() ---- -Both sides of the merge added content to this file, but some of the commits modified the file in the same place that caused this conflict. +Και οι δύο πλευρές της συγχώνευσης πρόσθεσαν περιεχόμενο σε αυτό το αρχείο, αλλά μερικές από τις υποβολές τροποποίησαν το αρχείο στον ίδιο σημείο και αυτό προκάλεσε τη σύγκρουση. -Let's explore a couple of tools that you now have at your disposal to determine how this conflict came to be. -Perhaps it's not obvious how exactly you should fix this conflict. -You need more context. +Ας εξερευνήσουμε μερικά εργαλεία που έχουμε πλέον στη διάθεσή μας για να καθορίσουμε πώς προέκυψε αυτή η σύγκρουση. +Ίσως δεν είναι προφανές πώς ακριβώς πρέπει να διορθώσουμε αυτήν τη σύγκρουση. +Χρειαζόμαστε περισσότερες πληροφορίες για το πλαίσιο της σύγκρουσης. -One helpful tool is `git checkout` with the `--conflict' option. -This will re-checkout the file again and replace the merge conflict markers. -This can be useful if you want to reset the markers and try to resolve them again. +Ένα χρήσιμο εργαλείο είναι η εντολή `git checkout` με την επιλογή `--conflict`. +Αυτή η εντολή θα ξανά-μεταβεί στο αρχείο και θα αντικαταστήσει τις επισημάνσεις σύγκρουσης. +Αυτό είναι χρήσιμο αν θέλουμε να αλλάξουμε τη μορφή των επισημάνσεων και να ξαναπροσπαθήσουμε να επιλύσουμε τις συγκρούσεις. -You can pass `--conflict` either `diff3` or `merge` (which is the default). -If you pass it `diff3`, Git will use a slightly different version of conflict markers, not only giving you the ``ours'' and ``theirs'' versions, but also the ``base'' version inline to give you more context. +Μπορούμε να περάσουμε στην επιλογή `--conflict` είτε την τιμή `diff3` είτε την `merge` (που είναι η προεπιλογή). +Εάν της περάσουμε την `diff3`, το Git θα χρησιμοποιήσει μια ελαφρώς διαφορετική έκδοση των επισημάνσεων σύγκρουσης, όχι μόνο να μας δώσει τις εκδόσεις "`ours`" και "`theirs`" αλλά και την έκδοση "`base`" για να πάρουμε περισσότερες πληροφορίες για το πλαίσιο της σύγκρουσης. [source,console] ---- $ git checkout --conflict=diff3 hello.rb ---- -Once we run that, the file will look like this instead: +Μόλις το τρέξουμε, το αρχείο θα μοιάζει με αυτό: [source,ruby] ---- @@ -388,58 +388,58 @@ end hello() ---- -If you like this format, you can set it as the default for future merge conflicts by setting the `merge.conflictstyle` setting to `diff3`. +Εάν μας αρέσει αυτή η μορφή, μπορούμε να την ορίσουμε ως προεπιλογή για μελλοντικές συγκρούσεις συγχώνευσης, θέτοντας την τιμή της `merge.conflictstyle` σε `diff3`. [source,console] ---- $ git config --global merge.conflictstyle diff3 ---- -The `git checkout` command can also take `--ours` and `--theirs` options, which can be a really fast way of just choosing either one side or the other without merging things at all. +Η εντολή `git checkout` μπορεί επίσης να πάρει τις επιλογές `--ours` και `--their', οι οποίες μπορεί να είναι ένας πολύ γρήγορος τρόπος για να επιλέξουμε απλά τη μια πλευρά ή την άλλη χωρίς να συγχωνεύσουμε τίποτα. -This can be particularly useful for conflicts of binary files where you can simply choose one side, or where you only want to merge certain files in from another branch - you can do the merge and then checkout certain files from one side or the other before committing. +Αυτό μπορεί να είναι ιδιαίτερα χρήσιμο για συγκρούσεις δυαδικών αρχείων, όπου μπορούμε απλά να επιλέξουμε τη μία πλευρά ή στις οποίες θέλουμε να συγχωνεύσουμε μόνο ορισμένα αρχεία από κάποιον άλλον κλάδο —μπορούμε να κάνουμε τη συγχώνευση και στη συνέχεια να ενημερώσουμε (checkout) ορισμένα αρχεία από τη μια ή την άλλη πλευρά πριν από την υποβολή. -[[_merge_log]] -===== Merge Log +[[r_merge_log]] +===== Συγχώνευση μητρώου -Another useful tool when resolving merge conflicts is `git log`. -This can help you get context on what may have contributed to the conflicts. -Reviewing a little bit of history to remember why two lines of development were touching the same area of code can be really helpful sometimes. +Ένα άλλο χρήσιμο εργαλείο κατά την επίλυση συγχωνεύσεων συγχώνευσης είναι το `git log`. +Αυτό μπορεί να μας βοηθήσει να αποκτήσουμε πληροφορίες σχετικά με το τι μπορεί να συνέβαλε στις συγκρούσεις. +Η επισκόπηση μικρού μέρους του ιστορικού για να θυμηθούμε γιατί δύο γραμμές ανάπτυξης επηρέασαν την ίδια περιοχή του κώδικα μπορεί να είναι πραγματικά χρήσιμη μερικές φορές. -To get a full list of all of the unique commits that were included in either branch involved in this merge, we can use the ``triple dot'' syntax that we learned in <<_triple_dot>>. +Για να πάρουμε μια πλήρη λίστα με όλες τις μοναδικές υποβολές που συμπεριλήφθησαν σε οποιονδήποτε κλάδο που συμμετέχει σε αυτήν τη συγχώνευση, μπορούμε να χρησιμοποιήσουμε τη σύνταξη "`τριπλής τελείας`" που είδαμε στην ενότητα <>. [source,console] ---- $ git log --oneline --left-right HEAD...MERGE_HEAD -< f1270f7 update README -< 9af9d3b add a README -< 694971d update phrase to hola world -> e3eb223 add more tests -> 7cff591 add testing script -> c3ffff1 changed text to hello mundo +< f1270f7 Update README +< 9af9d3b Create README +< 694971d Update phrase to 'hola world' +> e3eb223 Add more tests +> 7cff591 Create initial testing script +> c3ffff1 Change text to 'hello mundo' ---- -That's a nice list of the six total commits involved, as well as which line of development each commit was on. +Αυτή είναι μια ωραιότατη λίστα των έξι συνολικά υποβολών που εμπλέκονται, καθώς και σε ποια γραμμή ανάπτυξης έγινε η κάθε υποβολή. -We can further simplify this though to give us much more specific context. -If we add the `--merge` option to `git log`, it will only show the commits in either side of the merge that touch a file that's currently conflicted. +Μπορούμε να απλουστεύσουμε περαιτέρω αυτήν τη λίστα για να πάρουμε ακόμα πιο συγκεκριμένες πληροφορίες για το πλαίσιο της σύγκρουσης. +Αν προσθέσουμε την επιλογή `--merge` στην `git log`, θα εμφανιστούν μόνο οι υποβολές σε κάθε πλευρά της συγχώνευσης που ακούμπησαν ένα αρχείο που βρίσκεται σε σύγκρουση. [source,console] ---- $ git log --oneline --left-right --merge -< 694971d update phrase to hola world -> c3ffff1 changed text to hello mundo +< 694971d Update phrase to 'hola world' +> c3ffff1 Change text to 'hello mundo' ---- -If you run that with the `-p` option instead, you get just the diffs to the file that ended up in conflict. -This can be **really** helpful in quickly giving you the context you need to help understand why something conflicts and how to more intelligently resolve it. +Αντίθετα αν την τρέξουμε με την επιλογή `-p`, θα πάρουμε μόνον αντί να πάρουμε μόνο τα diff του αρχείου που κατέληξε σε σύγκρουση. +Αυτό μπορεί να είναι *πραγματικά* χρήσιμο για να μας δώσει γρήγορα το πλαίσιο που χρειαζόμαστε για να καταλάβουμε γιατί κάτι συγκρούεται και πώς να επιλύσουμε πιο έξυπνα τη σύγκρουση. -===== Combined Diff Format +===== Μορφή συνδυασμένου diff -Since Git stages any merge results that are successful, when you run `git diff` while in a conflicted merge state, you only get what is currently still in conflict. -This can be helpful to see what you still have to resolve. +Εφόσον το Git βάζει στο στάδιο καταχώρισης όλα τα επιτυχημένα αποτελέσματα συγχώνευσης, όταν εκτελούμε την `git diff`, ενώ βρισκόμαστε σε κατάσταση σύγκρουσης συγχώνευσης, παίρνουμε μόνο ό,τι είναι ακόμα σε σύγκρουση. +Αυτό μπορεί να μας βοηθήσει να δούμε τι πρέπει ακόμα να επιλύσουμε. -When you run `git diff` directly after a merge conflict, it will give you information in a rather unique diff output format. +Όταν τρέχουμε την `git diff` αμέσως μετά από μια σύγκρουση συγχώνευσης, θα μας δώσει πληροφορίες σε μια μοναδική μορφή εξόδου της diff. [source,console] ---- @@ -462,13 +462,13 @@ index 0399cd5,59727f0..0000000 hello() ---- -The format is called ``Combined Diff'' and gives you two columns of data next to each line. -The first column shows you if that line is different (added or removed) between the ``ours'' branch and the file in your working directory and the second column does the same between the ``theirs'' branch and your working directory copy. +Η μορφή αυτή ονομάζεται "`Συνδυασμένη diff`" και μας δίνει δύο στήλες δεδομένων δίπλα σε κάθε γραμμή. +Η πρώτη στήλη μας δείχνει αν αυτή η γραμμή διαφέρει (προστέθηκε ή αφαιρέθηκε) ανάμεσα στον κλάδο "`ours`" και το αρχείο στον κατάλογο εργασίας μας και η δεύτερη στήλη κάνει το ίδιο αλλά ανάμεσα στον κλάδο "`theirs`" και τον κατάλογο εργασίας μας. -So in that example you can see that the `<<<<<<<` and `>>>>>>>` lines are in the working copy but were not in either side of the merge. -This makes sense because the merge tool stuck them in there for our context, but we're expected to remove them. +Έτσι σε αυτό το παράδειγμα μπορούμε να δούμε ότι οι γραμμές `<<<<<<<` και `>>>>>>>` βρίσκονται στο αντίγραφο εργασίας αλλά δεν βρίσκονται σε καμία πλευρά της συγχώνευσης. +Αυτό έχει νόημα επειδή το εργαλείο συγχώνευσης τις βάλει εκεί δεδομένου του συγκεκριμένου πλαισίου της σύγκρουσης, αλλά αναμένει από μας τα τις αφαιρέσουμε. -If we resolve the conflict and run `git diff` again, we'll see the same thing, but it's a little more useful. +Αν επιλύσουμε τη σύγκρουση και τρέξουμε ξανά την `git diff`, θα δούμε το ίδιο πράγμα αλλά είναι λίγο πιο χρήσιμο. [source,console] ---- @@ -490,11 +490,11 @@ index 0399cd5,59727f0..0000000 hello() ---- -This shows us that ``hola world'' was in our side but not in the working copy, that ``hello mundo'' was in their side but not in the working copy and finally that ``hola mundo'' was not in either side but is now in the working copy. -This can be useful to review before committing the resolution. +Αυτό μας δείχνει ότι το "`hola world`" βρισκόταν στην πλευρά μας αλλά όχι στο αντίγραφο εργασίας, ότι το "`hello mundo`" ήταν στο πλευρό τους αλλά όχι στο αντίγραφο εργασίας και τέλος ότι το "`hola mundo`" δεν ήταν σε καμία πλευρά, αλλά τώρα βρίσκεται στο αντίγραφο εργασίας. +Αυτό μπορεί να είναι χρήσιμο για μία επισκόπηση πριν την υποβολή της επίλυσης. -You can also get this from the `git log` for any merge after the fact to see how something was resolved after the fact. -Git will output this format if you run `git show` on a merge commit, or if you add a `--cc` option to a `git log -p` (which by default only shows patches for non-merge commits). +Μπορούμε επίσης να πάρουμε αυτό από την `git log` για οποιαδήποτε συγχώνευση μετά τη συγχώνευση για να δούμε πώς κάτι επιλύθηκε. +Το Git θα εκτυπώσει σε αυτήν τη μορφή αν εκτελέσουμε την `git show` σε μια υποβολή συγχώνευσης ή εάν προσθέσουμε την επιλογή `--cc 'σε μία `git log -p` (η οποία εκ προεπιλογής εμφανίζει μόνο επιθέματα για υποβολές που δεν είναι συγχωνεύσεις). [source,console] ---- @@ -525,45 +525,45 @@ index 0399cd5,59727f0..e1d0799 hello() ---- -[[_undoing_merges]] -==== Undoing Merges +[[r_undoing_merges]] +==== Αναίρεση συγχώνευσης -Now that you know how to create a merge commit, you'll probably make some by mistake. -One of the great things about working with Git is that it's okay to make mistakes, because it's possible (and in many cases easy) to fix them. +Τώρα που ξέρουμε πώς να δημιουργήσουμε υποβολές συγχώνευσης, θα κάνουμε πιθανώς κάποια κατά λάθος. +Ένα από τα σπουδαία πράγματα της εργασίας στο Git είναι ότι δεν πειράζει αν κάνουμε λάθη, επειδή είναι δυνατό (και σε πολλές περιπτώσεις εύκολο) να τα διορθώσουμε. -Merge commits are no different. -Let's say you started work on a topic branch, accidentally merged it into `master`, and now your commit history looks like this: +Οι υποβολές συγχώνευσης δεν διαφέρουν. +Ας υποθέσουμε ότι ξεκινήσαμε να εργαζόμαστε σε έναν θεματικό κλάδο, τον συγχωνεύσαμε τον κατά λάθος στον `master` και τώρα το ιστορικό των υποβολών μας μοιάζει με αυτό: -.Accidental merge commit -image::images/undomerge-start.png[Accidental merge commit.] +.Ακούσια υποβολή συγχώνευσης +image::images/undomerge-start.png[Ακούσια υποβολή συγχώνευσης.] -There are two ways to approach this problem, depending on what your desired outcome is. +Υπάρχουν δύο τρόποι προσέγγισης αυτού του προβλήματος, ανάλογα με το ποιο επιθυμούμε να είναι το αποτέλεσμα. ===== Fix the references -If the unwanted merge commit only exists on your local repository, the easiest and best solution is to move the branches so that they point where you want them to. -In most cases, if you follow the errant `git merge` with `git reset --hard HEAD~`, this will reset the branch pointers so they look like this: +Εάν η ανεπιθύμητη υποβολή συγχώνευσης υπάρχει μόνο στο τοπικό αποθετήριο, η ευκολότερη και καλύτερη λύση είναι να μετακινήσουμε τους κλάδους ώστε να δείχνουν εκεί όπου θέλουμε. +Στις περισσότερες περιπτώσεις, αν μετά από μία `git merge` εκτελέσουμε την `git reset --hard HEAD~`, αυτό θα επαναφέρει τους δείκτες κλάδων, οπότε θα μοιάζουν με αυτό: -.History after `git reset --hard HEAD~` -image::images/undomerge-reset.png[History after `git reset --hard HEAD~`.] +.Το ιστορικό μετά την `git reset --hard HEAD~`. +image::images/undomerge-reset.png[Το ιστορικό μετά την `git reset --hard HEAD~`.] -We covered `reset` back in <<_git_reset>>, so it shouldn't be too hard to figure out what's going on here. -Here's a quick refresher: `reset --hard` usually goes through three steps: +Καλύψαμε την `reset` στην ενότητα <>, επομένως δεν πρέπει να είναι πολύ δύσκολο να καταλάβουμε τι συμβαίνει εδώ. +Ορίστε μία γρήγορη υπενθύμιση: η `reset --hard` συνήθως περνάει από τρία βήματα: -. Move the branch HEAD points to. - In this case, we want to move `master` to where it was before the merge commit (`C6`). -. Make the index look like HEAD. -. Make the working directory look like the index. +. Μετακινούμε τον κλάδο στον οποίο δείχνει τον HEAD. + Σε αυτήν την περίπτωση, θέλουμε να μετακινήσουμε τον `master` εκεί όπου βρισκόταν πριν την υποβολή συγχώνευσης (`C6`). +. Κάνουμε το ευρετήριο να μοιάζει με τον HEAD. +. Κάνουμε τον κατάλογο εργασίας να μοιάζει με το ευρετήριο. -The downside of this approach is that it's rewriting history, which can be problematic with a shared repository. -Check out <<_rebase_peril>> for more on what can happen; the short version is that if other people have the commits you're rewriting, you should probably avoid `reset`. -This approach also won't work if any other commits have been created since the merge; moving the refs would effectively lose those changes. +Το μειονέκτημα αυτής της προσέγγισης είναι ότι πρόκειται για επανεγγραφή του ιστορικού, το οποίο μπορεί να είναι προβληματικό με ένα κοινό αποθετήριο. +Στην ενότητα <> υπάρχουν περισσότερα σχετικά με το τι μπορεί να συμβεί· με λίγα λόγια αυτό αν κάποιος άλλος έχει τις υποβολές που αλλάζουμε, θα πρέπει μάλλον να αποφύγουμε την `reset`. +Αυτή η προσέγγιση επίσης δεν θα λειτουργήσει εάν έχουν γίνει άλλες υποβολές μετά από τη συγχώνευση· η μετακίνηση των refs ουσιαστικά θα χάσει αυτές τις αλλαγές. -[[_reverse_commit]] -===== Reverse the commit +[[r_reverse_commit]] +===== Eπαναφορά της υποβολής -If moving the branch pointers around isn't going to work for you, Git gives you the option of making a new commit which undoes all the changes from an existing one. -Git calls this operation a ``revert'', and in this particular scenario, you'd invoke it like this: +Εάν η μετακίνηση των δεικτών των κλάδων από δω κι από κει δεν μας βοηθά, το Git μάς δίνει τη δυνατότητα να κάνουμε μια νέα υποβολή, η οποία ακυρώνει όλες τις αλλαγές από μία υπάρχουσα. +Το Git ονομάζει αυτήν τη λειτουργία "`επαναφορά`" ("`revert`") και σε αυτό το συγκεκριμένο σενάριο, θα τη χρησιμοποιήσουμε ως εξής: [source,console] ---- @@ -571,17 +571,17 @@ $ git revert -m 1 HEAD [master b1d8379] Revert "Merge branch 'topic'" ---- -The `-m 1` flag indicates which parent is the ``mainline'' and should be kept. -When you invoke a merge into `HEAD` (`git merge topic`), the new commit has two parents: the first one is `HEAD` (`C6`), and the second is the tip of the branch being merged in (`C4`). -In this case, we want to undo all the changes introduced by merging in parent #2 (`C4`), while keeping all the content from parent #1 (`C6`). +Η επισήμανση `-m 1` υποδεικνύει ποιος γονέας είναι η "`κύρια γραμμή`" και θα πρέπει να διατηρηθεί. +Όταν ξεκινάμε μια συγχώνευση στον `HEAD` (`git merge topic'), η νέα υποβολή έχει δύο γονείς: ο πρώτος είναι ο `HEAD` (`C6`) και ο δεύτερος είναι η κορυφή του κλάδου που συγχωνεύεται (`C4`). +Σε αυτήν την περίπτωση, θέλουμε να αναιρέσουμε όλες τις αλλαγές που εισήχθησαν με τη συγχώνευση του γονέα #2 (`C4`), διατηρώντας όλο το περιεχόμενο από τον γονέα #1 (`C6`). -The history with the revert commit looks like this: +Το ιστορικό μετά την επαναφορά της υποβολής μοιάζει ως εξής: -.History after `git revert -m 1` -image::images/undomerge-revert.png[History after `git revert -m 1`.] +.Ιστορικό μετά την `git revert -m 1` +image::images/undomerge-revert.png[Ιστορικό μετά την `git revert -m 1`.] -The new commit `^M` has exactly the same contents as `C6`, so starting from here it's as if the merge never happened, except that the now-unmerged commits are still in `HEAD`'s history. -Git will get confused if you try to merge `topic` into `master` again: +Η νέα υποβολή `^M` έχει ακριβώς το ίδιο περιεχόμενο με την `C6`, οπότε ξεκινώντας από εδώ είναι σαν να μην συνέβη ποτέ η συγχώνευση, εκτός από το γεγονός ότι οι υποβολές που τώρα δεν έχουν μεσολαβήσει εξακολουθούν να βρίσκονται στο ιστορικό του `HEAD`. +Το Git θα μπερδευτεί αν προσπαθήσουμε να συγχωνεύσουμε ξανά τον `topic` στον `master`: [source,console] ---- @@ -589,13 +589,13 @@ $ git merge topic Already up-to-date. ---- -There's nothing in `topic` that isn't already reachable from `master`. -What's worse, if you add work to `topic` and merge again, Git will only bring in the changes _since_ the reverted merge: +Δεν υπάρχει τίποτα στο `topic` που δεν είναι ήδη προσπελάσιμο από τον `master`. +Ακόμα χειρότερα, αν προσθέσουμε εργασία στον `topic` και συγχωνεύσουμε ξανά, το Git θα φέρει μόνο τις αλλαγές που έγιναν _από την αναστροφή και μετά_: -.History with a bad merge -image::images/undomerge-revert2.png[History with a bad merge.] +.Ιστορικό με κακή συγχώνευση +image::images/undomerge-revert2.png[Ιστορικό με κακή συγχώνευση.] -The best way around this is to un-revert the original merge, since now you want to bring in the changes that were reverted out, *then* create a new merge commit: +Ο καλύτερος τρόπος να λύσουμε αυτό το πρόβλημα είναι να ξε-επαναφέρουμε την αρχική συγχώνευση, αφού τώρα θέλουμε να ξαναφέρουμε τις αλλαγές που είχαν επαναφερθεί, *και μετά* να κάνουμε μια νέα υποβολή συγχώνευσης: [source,console] ---- @@ -604,31 +604,31 @@ $ git revert ^M $ git merge topic ---- -.History after re-merging a reverted merge -image::images/undomerge-revert3.png[History after re-merging a reverted merge.] +.Ιστορικό μετά την επανασυγχώνευση μίας συγχώνευσης που είχε επαναφερθεί +image::images/undomerge-revert3.png[στορικό μετά την επανασυγχώνευση μίας συγχώνευσης που είχε επαναφερθεί.] -In this example, `M` and `^M` cancel out. -`^^M` effectively merges in the changes from `C3` and `C4`, and `C8` merges in the changes from `C7`, so now `topic` is fully merged. +Σε αυτό το παράδειγμα, οι `M` και `^M` αλληλοεξουδετερώνονται. +Η `^^M` ουσιαστικά συγχωνεύει τις αλλαγές από `C3` και `C4`, και η `C8` συγχωνεύει τις αλλαγές από την `C7`, έτσι τώρα ο `topic` συγχωνεύεται πλήρως. -==== Other Types of Merges +==== Άλλα είδη συγχωνεύσεων -So far we've covered the normal merge of two branches, normally handled with what is called the ``recursive'' strategy of merging. -There are other ways to merge branches together however. -Let's cover a few of them quickly. +Μέχρι στιγμής καλύψαμε τη συνηθισμένη συγχώνευση δύο κλάδων, τα οποία φυσιολογικά αντιμετωπίζεται με τη λεγόμενη "`αναδρομική`" στρατηγική συγχώνευσης. +Υπάρχουν κι άλλοι τρόποι συγχώνευσης των κλάδων. +Ας δούμε μερικούς από αυτούς συνοπτικά. -===== Our or Theirs Preference +===== Προτίμηση "`δική μας`" ή "`δική τους`" -First of all, there is another useful thing we can do with the normal ``recursive'' mode of merging. -We've already seen the `ignore-all-space` and `ignore-space-change` options which are passed with a `-X` but we can also tell Git to favor one side or the other when it sees a conflict. +Πρώτα απ 'όλα, υπάρχει ένα άλλο χρήσιμο πράγμα που μπορούμε να κάνουμε με τον συνήθη "`αναδρομικό`" τρόπο συγχώνευσης. +Έχουμε ήδη δει τις επιλογές `ignore-all-space` και 'ignore-space-change` που έχουν περάσει με την επιλογή `-X`, αλλά μπορούμε επίσης να πούμε στο Git να ευνοεί τη μία ή την άλλη πλευρά όταν βλέπει μια σύγκρουση. -By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it. -If you would prefer for Git to simply choose a specific side and ignore the other side instead of letting you manually merge the conflict, you can pass the `merge` command either a `-Xours` or `-Xtheirs`. +Εκ προεπιλογής, όταν το Git βλέπει μια σύγκρουση μεταξύ δύο κλάδων, που συγχωνεύονται, θα προσθέσει επισημάνσεις σύγκρουσης συγχώνευσης στον κώδικά μας, θα επισημάνει το αρχείο ως συγκρουόμενο και θα αφήσει εμάς να επιλύσουμε τη σύγκρουση. +Εάν προτιμάμε το Git να επιλέξει απλά μια συγκεκριμένη πλευρά και να αγνοήσει την άλλη πλευρά αντί να αφήνει εμάς να συγχωνεύσουμε με χειροκίνητα τη σύγκρουση, μπορούμε να περάσουμε στην εντολή `merge` είτε ένα `-Xours` είτε ένα `-Xtheirs`. -If Git sees this, it will not add conflict markers. -Any differences that are mergeable, it will merge. -Any differences that conflict, it will simply choose the side you specify in whole, including binary files. +Εάν το Git δει μία από αυτές τις επιλογές, δεν θα προσθέσει δείκτες σύγκρουσης. +Τυχόν διαφορές που μπορούν να συγχωνευθούν, θα συγχωνευθούν. +Οποιεσδήποτε διαφορές που συγκρούονται, απλά θα επιλέξει αποκλειστικά την πλευρά που καθορίζουμε και αυτό ισχύει και για δυαδικά αρχεία. -If we go back to the ``hello world'' example we were using before, we can see that merging in our branch causes conflicts. +Επιστρέφουμε στο παράδειγμα "`hello world`" που χρησιμοποιήσαμε πριν και βλέπουμε ότι η συγχώνευση στον κλάδο μας προκαλεί συγκρούσεις. [source,console] ---- @@ -639,7 +639,7 @@ Resolved 'hello.rb' using previous resolution. Automatic merge failed; fix conflicts and then commit the result. ---- -However if we run it with `-Xours` or `-Xtheirs` it does not. +Ωστόσο, αν την τρέξουμε με `-Xours` ή `-XTheirs` δεν προκαλεί συγκρούσεις. [source,console] ---- @@ -652,17 +652,17 @@ Merge made by the 'recursive' strategy. create mode 100644 test.sh ---- -In that case, instead of getting conflict markers in the file with ``hello mundo'' on one side and ``hola world'' on the other, it will simply pick ``hola world''. -However, all the other non-conflicting changes on that branch are merged successfully in. +Σε αυτήν την περίπτωση, αντί να πάρουμε επισημάνσεις σύγκρουσης στο αρχείο με "`hello mundo`" στη μία πλευρά και "`hola world`" από την άλλη, θα επιλέξει απλά "`hola world`". +Ωστόσο, όλες οι άλλες αλλαγές, που δεν δημιουργούν συγκρούσεις, σε αυτόν τον κλάδο συγχωνεύονται με επιτυχία. -This option can also be passed to the `git merge-file` command we saw earlier by running something like `git merge-file --ours` for individual file merges. +Αυτή η επιλογή μπορεί επίσης να μεταβιβαστεί στην εντολή `git merge-file` που είδαμε νωρίτερα τρέχοντας κάτι σαν το `git merge-file --ours` για συγχωνεύσεις μεμονωμένων αρχείων. -If you want to do something like this but not have Git even try to merge changes from the other side in, there is a more draconian option, which is the ``ours'' merge _strategy_. -This is different from the ``ours'' recursive merge _option_. +Εάν θέλουμε να κάνουμε κάτι τέτοιο αλλά δεν έχουμε προσπαθήσει να συγχωνεύσουμε τις αλλαγές από την άλλη πλευρά, υπάρχει μια πιο δρακόντεια επιλογή, η οποία είναι η _στρατηγική_ συγχώνευσης "`ours`". +Αυτή είναι διαφορετική από την _επιλογή_ αναδρομικής συγχώνευσης "`ours`". -This will basically do a fake merge. -It will record a new merge commit with both branches as parents, but it will not even look at the branch you're merging in. -It will simply record as the result of the merge the exact code in your current branch. +Αυτό θα κάνει βασικά μια ψεύτικη συγχώνευση. +Θα καταγράψει μια νέα υποβολή συγχώνευσης με τους δύο κλάδους ως γονείς, αλλά δεν θα εξετάσει καν τον κλάδο τον οποίο συγχωνευουμε. +Θα καταγράψει απλώς ως αποτέλεσμα της συγχώνευσης τον ακριβή κώδικα στον τρέχοντα κλάδο μας. [source,console] ---- @@ -672,11 +672,11 @@ $ git diff HEAD HEAD~ $ ---- -You can see that there is no difference between the branch we were on and the result of the merge. +Μπορούμε να δούμε ότι δεν υπάρχει διαφορά μεταξύ του κλάδου στον οποίο βρισκόμασταν και του αποτελέσματος της συγχώνευσης. -This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on. -For example, say you branched off a ``release'' branch and have done some work on it that you will want to merge back into your ``master'' branch at some point. -In the meantime some bugfix on ``master'' needs to be backported into your `release` branch. -You can merge the bugfix branch into the `release` branch and also `merge -s ours` the same branch into your `master` branch (even though the fix is already there) so when you later merge the `release` branch again, there are no conflicts from the bugfix. +Αυτό μπορεί συχνά να είναι χρήσιμο στο να ξεγελάσει το Git ώστε να νομίζει ότι ένας κλάδος είναι ήδη συγχωνευμένος όταν κάνει μία συγχώνευση αργότερα. +Για παράδειγμα, ας πούμε ότι διακλαδώσαμε από έναν κλάδο "`release`", κάναμε κάποια εργασία σε αυτόν την οποία θα θελήσουμε να συγχωνεύσουμε ξανά τον κλάδο "`master`" σε κάποια στιγμή. +Εν τω μεταξύ, η διόρθωση ενός bug, `bugfix` στον "`master`" πρέπει να μεταφερθεί στον κλάδο `release`. +Μπορούμε να συγχωνεύσουμε τον κλάδο bugfix στον κλάδο `release` και επίσης να τρέξουμε `merge -s ours` για να συγχωνεύσουμε τον ίδιο κλάδο στον `master` (παρά το ότι η διόρθωση του bug υπάρχει ήδη εκεί) έτσι ώστε όταν συγχωνεύσουμε ξανά τον κλάδο `release` να μην υπάρχουν συγκρούσεις από τη διόρθωση σφαλμάτων. include::subtree-merges.asc[] diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 369a4a845..8dd692f2a 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -1,20 +1,20 @@ -[[_bundling]] -=== Bundling +[[r_bundling]] +=== Δεμάτιασμα δεδομένων -Though we've covered the common ways to transfer Git data over a network (HTTP, SSH, etc), there is actually one more way to do so that is not commonly used but can actually be quite useful. +Αν και καλύψαμε τους συνήθεις τρόπους μεταφοράς των δεδομένων του Git μέσω δικτύου (HTTP, SSH κ.λπ.), υπάρχει πράγματι ένας ακόμη τρόπος να το κάνουμε αυτό που δεν χρησιμοποιείται συνήθως, αλλά μπορεί να είναι πραγματικά πολύ χρήσιμος. -Git is capable of ``bundling'' its data into a single file. -This can be useful in various scenarios. -Maybe your network is down and you want to send changes to your co-workers. -Perhaps you're working somewhere offsite and don't have access to the local network for security reasons. -Maybe your wireless/ethernet card just broke. -Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via `format-patch`. +Το Git είναι ικανό να "`δεματιάζει`" (bundle) τα δεδομένα του σε ένα μοναδικό αρχείο. +Αυτό μπορεί να είναι χρήσιμο σε διάφορες περιστάσεις. +Ίσως το δίκτυό μας να είναι πεσμένο και θέλουμε να στείλουμε αλλαγές στους συναδέλφους μας. +Ίσως εργαζόμαστε κάπου εξ αποστάσεως και δεν έχουμε πρόσβαση στο τοπικό δίκτυο για λόγους ασφαλείας. +Ίσως η κάρτα μας ασύρματου δικτύου / δικτύου ethernet μόλις χάλασε. +Ίσως δεν έχουμε επί του παρόντος πρόσβαση σε έναν κοινόχρηστο διακομιστή, θέλουμε να στείλουμε διορθώσεις με e-mail σε κάποιον χρήστη και δεν θέλουμε να μεταφέρουμε 40 υποβολές μέσω της `format-patch`. -This is where the `git bundle` command can be helpful. -The `bundle` command will package up everything that would normally be pushed over the wire with a `git push` command into a binary file that you can email to someone or put on a flash drive, then unbundle into another repository. +Σε αυτές τις περιστάσεις η εντολή `git bundle` μπορεί να είναι χρήσιμη. +Η εντολή `bundle` πακετάρει όλα όσα θα έπρεπε κανονικά να ωθηθούν πάνω από το δίκτυο με την εντολή `git push` σε ένα δυαδικό αρχείο το οποίο μπορούμε να στείλουμε με email σε κάποιον ή να τοποθετήσουμε μια flash drive και στη συνέχεια να ξεπακετάρουμε σε κάποιο άλλο αποθετήριο. -Let's see a simple example. -Let's say you have a repository with two commits: +Ας δούμε ένα απλό παράδειγμα. +Ας υποθέσουμε ότι έχουμε ένα αποθετήριο με δύο υποβολές: [source,console] ---- @@ -32,7 +32,7 @@ Date: Wed Mar 10 07:34:01 2010 -0800 first commit ---- -If you want to send that repository to someone and you don't have access to a repository to push to, or simply don't want to set one up, you can bundle it with `git bundle create`. +Εάν θέλουμε να στείλουμε αυτό το αποθετήριο σε κάποιον και δεν έχουμε πρόσβαση σε κάποιο άλλο αποθετήριο για να το ωθήσουμε ή απλά δεν θέλουμε να εγκαταστήσουμε ένα, μπορούμε να το δεματιάσουμε με την `git bundle create`. [source,console] ---- @@ -44,28 +44,29 @@ Writing objects: 100% (6/6), 441 bytes, done. Total 6 (delta 0), reused 0 (delta 0) ---- -Now you have a file named `repo.bundle` that has all the data needed to re-create the repository's `master` branch. -With the `bundle` command you need to list out every reference or specific range of commits that you want to be included. -If you intend for this to be cloned somewhere else, you should add HEAD as a reference as well as we've done here. +Τώρα έχουμε ένα αρχείο με όνομα `repo.bundle` που έχει όλα τα δεδομένα που απαιτούνται για να δημιουργηθεί εκ νέου ο κλάδος `master` του αποθετηρίου. +Στην εντολή `bundle` πρέπει να παραθέσουμε κάθε αναφορά ή συγκεκριμένο εύρος υποβολών θέλουμε να συμπεριλάβουμε. +Αν σκοπεύουμε να κλωνοποιηθεί κάπου αλλού, θα πρέπει να προσθέσουμε τον HEAD ως αναφορά, όπως κάναμε εδώ. -You can email this `repo.bundle` file to someone else, or put it on a USB drive and walk it over. +Μπορούμε να στείλουμε το αρχείο `repo.bundle` με e-mail σε κάποιον άλλο, ή να το τοποθετήσουμε σε μια μονάδα USB και να το δώσουμε. -On the other side, say you are sent this `repo.bundle` file and want to work on the project. -You can clone from the binary file into a directory, much like you would from a URL. +Από την άλλη, ας πούμε ότι κάποιος μας έχει στείλει αυτό το αρχείο `repo.bundle` και θέλουμε να εργαστούμε στο έργο. +Μπορούμε να κλωνοποιήσουμε από το δυαδικό αρχείο σε έναν κατάλογο, όπως θα κάναμε από μια διεύθυνση URL. [source,console] ---- $ git clone repo.bundle repo -Initialized empty Git repository in /private/tmp/bundle/repo/.git/ +Cloning into 'repo'... +... $ cd repo $ git log --oneline -9a466c5 second commit -b1ec324 first commit +9a466c5 Second commit +b1ec324 First commit ---- -If you don't include HEAD in the references, you have to also specify `-b master` or whatever branch is included because otherwise it won't know what branch to check out. +Εάν δεν συμπεριλαμβάνουμε τον `HEAD` στις αναφορές, πρέπει επίσης να καθορίσουμε το `-b master` ή οποιονδήποτε κλάδο περιλαμβάνεται επειδή αλλιώς δεν θα ξέρει σε ποιον κλάδο να μεταβεί. -Now let's say you do three commits on it and want to send the new commits back via a bundle on a USB stick or email. +Τώρα ας υποθέσουμε ότι κάνουμε τρεις υποβολές σε αυτό και θέλουμε να στείλουμε τις νέες υποβολές πίσω σε ένα δεμάτι με ένα USB stick ή e-mail. [source,console] ---- @@ -77,14 +78,14 @@ c99cf5b fourth commit - second repo b1ec324 first commit ---- -First we need to determine the range of commits we want to include in the bundle. -Unlike the network protocols which figure out the minimum set of data to transfer over the network for us, we'll have to figure this out manually. - Now, you could just do the same thing and bundle the entire repository, which will work, but it's better to just bundle up the difference - just the three commits we just made locally. +Πρώτα πρέπει να καθορίσουμε το εύρος υποβολών που θέλουμε να συμπεριλάβουμε στη δέσμη. +Σε αντίθεση με τα πρωτόκολλα δικτύου που καθορίζουν το ελάχιστο σύνολο δεδομένων που θα μεταφερθούν μέσω του δικτύου για εμάς, θα πρέπει να το βρούμε αυτό μόνοι μας. +Θα μπορούσαμε να κάνουμε το ίδιο πράγμα και να δεματιάσουμε ολόκληρο το αποθετήριο, και κάτι τέτοιο θα λειτουργήσει, αλλά είναι καλύτερα να δεματιάσουμε τη διαφορά —ακριβώς τις τρεις υποβολές που κάναμε τοπικά. -In order to do that, you'll have to calculate the difference. -As we described in <<_commit_ranges>>, you can specify a range of commits in a number of ways. -To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`. -You can test that with the `log` command. +Για να γίνει αυτό, θα πρέπει να υπολογίσουμε τη διαφορά. +Όπως περιγράψαμε στην ενότητα <>, μπορούμε να καθορίσουμε μια σειρά υποβολών με διάφορους τρόπους. +Για να πάρουμε τις τρεις υποβολές που έχουμε στον `master` κλάδο μας και που δεν ήταν στον κλάδο που αρχικά κλωνοποιήσαμε, μπορούμε να χρησιμοποιήσουμε κάτι σαν `origin/master..master` ή `master ^origin/master`. +Ας το δοκιμάσουμε με την εντολή `log`. [source,console] ---- @@ -94,8 +95,8 @@ c99cf5b fourth commit - second repo 7011d3d third commit - second repo ---- -So now that we have the list of commits we want to include in the bundle, let's bundle them up. -We do that with the `git bundle create` command, giving it a filename we want our bundle to be and the range of commits we want to go into it. +Τώρα, λοιπόν, που έχουμε τον κατάλογο των υποβολών που θέλουμε να συμπεριλάβουμε στο δεμάτι, ας τις δεματιάσουμε. +Αυτό το κάνουμε με την εντολή `git bundle create`, στην οποία δίνουμε το όνομα αρχείου που θέλουμε να έχει το δεμάτι μας και το εύρος των υποβολών που θέλουμε να το κάνουμε. [source,console] ---- @@ -107,11 +108,11 @@ Writing objects: 100% (9/9), 775 bytes, done. Total 9 (delta 0), reused 0 (delta 0) ---- -Now we have a `commits.bundle` file in our directory. -If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime. +Τώρα έχουμε ένα αρχείο `commits.bundle` στον κατάλογό μας. +Αν το πάρουμε και το στείλουμε στη συνεργάτιδα μας, τότε μπορεί να το εισάγει στο αρχικό αποθετήριο, ακόμα κι αν σε αυτό έχει γίνει περαιτέρω δουλειά εν τω μεταξύ. -When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository. -The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the necessary ancestors to reconstitute it properly. +Όταν παίρνει το δεμάτι, μπορεί να το επιθεωρήσει για να δει τι περιέχει πριν το εισάγει στο αποθετήριό της. +Η πρώτη εντολή είναι η εντολή `bundle verify` που θα διασφαλίσει ότι το αρχείο είναι στην πραγματικότητα ένα έγκυρο δεμάτι Git και ότι έχουμε όλους τους απαραίτητους προγόνους για να το ανασυνθέσουμε σωστά. [source,console] ---- @@ -123,8 +124,8 @@ The bundle requires these 1 ref ../commits.bundle is okay ---- -If the bundler had created a bundle of just the last two commits they had done, rather than all three, the original repository would not be able to import it, since it is missing requisite history. -The `verify` command would have looked like this instead: +Αν αυτός που δημιούργησε το δεμάτι είχε συμπεριλάβει μόνο τις δύο τελευταίες υποβολές που είχε κάνει και όχι και τις τρεις, το αρχικό αποθετήριο δεν θα μπορούσε να το εισάγει, δεδομένου ότι λείπει το απαιτούμενο ιστορικό. +Η εντολή `verify` θα επέστρεφε: [source,console] ---- @@ -133,8 +134,8 @@ error: Repository lacks these prerequisite commits: error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 third commit - second repo ---- -However, our first bundle is valid, so we can fetch in commits from it. -If you want to see what branches are in the bundle that can be imported, there is also a command to just list the heads: +Ωστόσο, το πρώτο μας δεμάτι είναι έγκυρο, έτσι μπορούμε να αναακτήσουμε υποβολές από αυτό. +Αν θέλουμε να δούμε ποιοι κλάδοι βρίσκονται στο δεμάτι που μπορεί να εισαχθεί, υπάρχει επίσης μια εντολή για να παραθέσουμε μόνον τις κεφαλές: [source,console] ---- @@ -142,9 +143,9 @@ $ git bundle list-heads ../commits.bundle 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master ---- -The `verify` sub-command will tell you the heads as well. -The point is to see what can be pulled in, so you can use the `fetch` or `pull` commands to import commits from this bundle. -Here we'll fetch the 'master' branch of the bundle to a branch named 'other-master' in our repository: +Η υπο-εντολή `verify` επίσης θα μας πει τις κεφαλές. +Ο σκοπός είναι να μπορούμε να δούμε τι μπορούμε να έλξουμε, ώστε να μπορούμε να χρησιμοποιήσουμε τις εντολές `fetch` ή `pull` για να εισάγουμε υποβολές από αυτό το δεμάτι. +Εδώ θα ανακτήσουμε τον `master` κλάδο του δεματιού σε έναν κλάδο που ονομάζεται `other-master` στο αποθετήριό μας: [source,console] ---- @@ -153,7 +154,7 @@ From ../commits.bundle * [new branch] master -> other-master ---- -Now we can see that we have the imported commits on the 'other-master' branch as well as any commits we've done in the meantime in our own 'master' branch. +Τώρα βλέπουμε ότι έχουμε τις εισαγόμενες υποβολές στον κλάδο `other-master` καθώς και τις υποβολές που έχουμε κάνει εν τω μεταξύ στον δικό μας κλάδο `master`. [source,console] ---- @@ -167,4 +168,4 @@ $ git log --oneline --decorate --graph --all * b1ec324 first commit ---- -So, `git bundle` can be really useful for sharing or doing network-type operations when you don't have the proper network or shared repository to do so. +Έτσι, η `git bundle` μπορεί να είναι πραγματικά χρήσιμη για να μοιραζόμαστε ή να κάνουμε δικτυακές ενέργειες όταν δεν έχουμε το κατάλληλο δίκτυο ή κοινόχρηστο αποθετήριο για να τις κάνουμε. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 72059802b..82efa1ea8 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -1,49 +1,50 @@ -[[_credential_caching]] -=== Credential Storage - -(((credentials))) -(((git commands, credential))) -If you use the SSH transport for connecting to remotes, it's possible for you to have a key without a passphrase, which allows you to securely transfer data without typing in your username and password. -However, this isn't possible with the HTTP protocols – every connection needs a username and password. -This gets even harder for systems with two-factor authentication, where the token you use for a password is randomly generated and unpronounceable. - -Fortunately, Git has a credentials system that can help with this. -Git has a few options provided in the box: - -* The default is not to cache at all. - Every connection will prompt you for your username and password. -* The ``cache'' mode keeps credentials in memory for a certain period of time. - None of the passwords are ever stored on disk, and they are purged from the cache after 15 minutes. -* The ``store'' mode saves the credentials to a plain-text file on disk, and they never expire. - This means that until you change your password for the Git host, you won't ever have to type in your credentials again. - The downside of this approach is that your passwords are stored in cleartext in a plain file in your home directory. -* If you're using a Mac, Git comes with an ``osxkeychain'' mode, which caches credentials in the secure keychain that's attached to your system account. - This method stores the credentials on disk, and they never expire, but they're encrypted with the same system that stores HTTPS certificates and Safari auto-fills. -* If you're using Windows, you can install a helper called ``winstore.'' - This is similar to the ``osxkeychain'' helper described above, but uses the Windows Credential Store to control sensitive information. - It can be found at https://gitcredentialstore.codeplex.com[]. - -You can choose one of these methods by setting a Git configuration value: +[[r_credential_caching]] +=== Αποθήκευση διαπιστευτηρίων + +(((διαπιστευτήρια))) +(((εντολές git, διαπιστευτήρια))) +Εάν χρησιμοποιούμε τη μεταφορά μέσω SSH για τη σύνδεση με απομακρυσμένα αποθετήρια, είναι πιθανό να έχουμε ένα κλειδί χωρίς κωδική φράση, η οποία μας επιτρέπει να μεταφέρουμε δεδομένα με ασφάλεια χωρίς να πληκτρολογούμε το όνομα χρήστη και τον κωδικό πρόσβασής μας. +Ωστόσο, αυτό δεν είναι δυνατό με τα πρωτόκολλα HTTP —κάθε σύνδεση χρειάζεται ένα όνομα χρήστη και έναν κωδικό πρόσβασης. +Αυτό γίνεται ακόμα πιο δύσκολο για συστήματα με ταυτοποίηση δύο παραγόντων, όπου το διακριτικό (token) που χρησιμοποιούμε για έναν κωδικό πρόσβασης παράγεται τυχαία και δεν μπορεί να ωθηθεί. + +Ευτυχώς, το Git διαθέτει ένα σύστημα διαπιστευτηρίων που μπορεί να μας βοηθήσει σε αυτό το πρόβλημα. +Το Git προσφέρει τις παρακάτω επιλογές: + +* Η προεπιλογή είναι να μην αποθηκεύει καθόλου διαπιστευτήρια. +  Κάθε σύνδεση θα μας ζητάει το όνομα χρήστη και τον κωδικό πρόσβασής μας. +* Κατά τη λειτουργία "`cache`" διατηρεί τα διαπιστευτήρια στη μνήμη για ορισμένο χρονικό διάστημα. +  Κανένας από τους κωδικούς πρόσβασης δεν αποθηκεύεται ποτέ στον δίσκο και οι κωδικοί πρόσβασης διαγράφονται από την προσωρινή μνήμη μετά από 15 λεπτά. +* Κατά τη λειτουργία "`store`" τα διαπιστευτήρια αποθηκεύονται σε ένα αρχείο απλού κειμένου στον δίσκο και δεν λήγουν ποτέ. +  Αυτό σημαίνει ότι μέχρι να αλλάξουμε τον κωδικό πρόσβασης για τον κεντρικό υπολογιστή Git, δεν θα χρειαστεί ποτέ να πληκτρολογήσουμε ξανά τα διαπιστευτήριά μας. +  Το μειονέκτημα αυτής της προσέγγισης είναι ότι οι κωδικοί πρόσβασης αποθηκεύονται σε αρχείο απλού κειμένου στον προσωπικό μας κατάλογο. +* Εάν χρησιμοποιούμε Mac, το Git έρχεται με τη λειτουργία "`osxkeychain`", η οποία αποθηκεύει τα διαπιστευτήρια στην ασφαλή κλειδοθήκη (keychain) που είναι συνδεδεμένη με το λογαριασμό μας στο σύστημα. +  Αυτή η μέθοδος αποθηκεύει τα διαπιστευτήριά μας στον δίσκο και δεν λήγει ποτέ, αλλά είναι κρυπτογραφημένα με το ίδιο σύστημα που αποθηκεύει τα πιστοποιητικά HTTPS και την αυτόματη συμπλήρωση του Safari. +* Εάν χρησιμοποιούμε Windows, μπορούμε να ενεργοποιήσουμε το *Git Credential Manager* χαρακτηριστικό όταν εγκαθηστούμε το Git https://gitforwindows.org/[Git για Windows] ή σε ξεχωριστή εγκατάσταση https://github.com/git-ecosystem/git-credential-manager/releases/latest[the latest GCM] ως αυτόνομο service. +  Είναι παρόμοιος με τον βοηθό "`osxkeychain`" που περιγράφεται παραπάνω, αλλά χρησιμοποιεί το Windows Credential Store (Χώρος Αποθήκευσης Διαπιστευτηρίων) για τον έλεγχο ευαίσθητων πληροφοριών. + Μπορεί επίσης να εξυπηρετήση διαπιστευτήρια για WSL1 ή WSL2. + Βλ. https://github.com/git-ecosystem/git-credential-manager#readme[GCM Οδηγίες Εγκατάστασης] για περισσότερες πληροφορίες. + +Μπορούμε να επιλέξουμε μία από αυτές τις μεθόδους ρυθμίζοντας την τιμή μίας μεταβλητής διαμόρφωσης του Git: [source,console] ---- $ git config --global credential.helper cache ---- -Some of these helpers have options. -The ``store'' helper can take a `--file ` argument, which customizes where the plaintext file is saved (the default is `~/.git-credentials`). -The ``cache'' helper accepts the `--timeout ` option, which changes the amount of time its daemon is kept running (the default is ``900'', or 15 minutes). -Here's an example of how you'd configure the ``store'' helper with a custom file name: +Μερικοί από αυτούς τους βοηθούς έχουν επιλογές. +Ο βοηθός "`store`" μπορεί να πάρει ένα όρισμα `--file <διαδρομή>`, το οποίο καθορίζει πού θα αποθηκεύεται το αρχείο απλού κειμένου (η προεπιλογή είναι το `~/.git-credentials`). +Ο βοηθός "`cache`" δέχεται την επιλογή `--timeout <δευτερόλεπτα> ', η οποία αλλάζει το χρονικό διάστημα για το οποίο ο δαίμονάς του συνεχίζει να τρέχει (η προεπιλογή είναι `900`, δηλαδή 15 λεπτά). +Ακολουθεί ένα παράδειγμα του πώς θα ρυθμίζουμε τον βοηθό "`store`" με ένα όνομα προσαρμοσμένου αρχείου: [source,console] ---- -$ git config --global credential.helper store --file ~/.my-credentials +$ git config --global credential.helper 'store --file ~/.my-credentials' ---- -Git even allows you to configure several helpers. -When looking for credentials for a particular host, Git will query them in order, and stop after the first answer is provided. -When saving credentials, Git will send the username and password to *all* of the helpers in the list, and they can choose what to do with them. -Here's what a `.gitconfig` would look like if you had a credentials file on a thumb drive, but wanted to use the in-memory cache to save some typing if the drive isn't plugged in: +Το Git ακόμη μας επιτρέπει να ρυθμίσουμε διάφορους βοηθούςς. +Όταν αναζητάμε διαπιστευτήρια για έναν συγκεκριμένο κεντρικό υπολογιστή, το Git θα τα εξετάζει με τη σειρά και θα σταματήσει μετά την πρώτη απάντηση. +Κατά την αποθήκευση διαπιστευτηρίων, το Git θα στείλει το όνομα χρήστη και τον κωδικό πρόσβασης σε *όλους* τους βοηθούς της λίστας και αυτοί μπορούν να επιλέξουν τι να τους κάνουν. +Ακολουθεί ένα παράδειγμα του πώς θα έμοιαζε το `.gitconfig` αν είχαμε ένα αρχείο διαπιστευτηρίων σε ένα USB stick, αλλά θέλαμε να χρησιμοποιήσουμε την προσωρινή μνήμη για να γλιτώσουμε λίγη πληκτρολόγηση εάν η μονάδα δεν είναι συνδεδεμένη: [source,ini] ---- @@ -52,26 +53,26 @@ Here's what a `.gitconfig` would look like if you had a credentials file on a th helper = cache --timeout 30000 ---- -==== Under the Hood +==== Πώς λειτουργεί -How does this all work? -Git's root command for the credential-helper system is `git credential`, which takes a command as an argument, and then more input through stdin. +Πώς λειτουργεί όλο αυτό; +Η βασική εντολή του Git για το σύστημα βοηθών διαπιστευτηρίων είναι η `git credential`, η οποία παίρνει μια εντολή ως όρισμα και άλλες εισόδους από το stdin. -This might be easier to understand with an example. -Let's say that a credential helper has been configured, and the helper has stored credentials for `mygithost`. -Here's a session that uses the ``fill'' command, which is invoked when Git is trying to find credentials for a host: +Αυτό είναι ίσως ευκολότερο να κατανοηθεί με ένα παράδειγμα. +Ας υποθέσουμε ότι ένας βοηθός διαπιστευτηρίων έχει ρυθμιστεί και ο βοηθός έχει αποθηκεύσει τα διαπιστευτήρια για τον διακομιστή `mygithost`. +Ακολουθεί μια συνεδρία που χρησιμοποιεί την εντολή "`fill`", η οποία ενεργοποιείται όταν το Git προσπαθεί να βρει διαπιστευτήρια για έναν διακομιστή: [source,console] ---- -$ git credential fill <1> -protocol=https <2> +$ git credential fill <1> +protocol=https <2> host=mygithost -<3> -protocol=https <4> + <3> +protocol=https <4> host=mygithost username=bob password=s3cre7 -$ git credential fill <5> +$ git credential fill <5> protocol=https host=unknownhost @@ -83,15 +84,15 @@ username=bob password=s3cre7 ---- -<1> This is the command line that initiates the interaction. -<2> Git-credential is then waiting for input on stdin. - We provide it with the things we know: the protocol and hostname. -<3> A blank line indicates that the input is complete, and the credential system should answer with what it knows. -<4> Git-credential then takes over, and writes to stdout with the bits of information it found. -<5> If credentials are not found, Git asks the user for the username and password, and provides them back to the invoking stdout (here they're attached to the same console). +<1> Αυτή είναι η γραμμή εντολών που ενεργοποιεί την αλληλεπίδραση. +<2> Η `git credential` στη συνέχεια αναμένει είσοδο από το stdin. +    Το παρέχουμε με αυτά που γνωρίζουμε: το πρωτόκολλο και το όνομα του κεντρικού υπολογιστή. +<3> Μια κενή γραμμή υποδεικνύει ότι η είσοδος είναι πλήρης και το σύστημα διαπιστευτηρίων πρέπει να απαντήσει με αυτό που γνωρίζει. +<4> Η `git credential` γράφει στο stdout τις πληροφορίες που βρήκε. +<5> Εάν δεν εντοπιστούν διαπιστευτήρια, το Git ζητάει από τον χρήστη το όνομα χρήστη και τον κωδικό πρόσβασης και τα επαναφέρει στην κλήση του stdout (εδώ είναι συνδεδεμένα στην ίδια κονσόλα). -The credential system is actually invoking a program that's separate from Git itself; which one and how depends on the `credential.helper` configuration value. -There are several forms it can take: +Το σύστημα διαπιστευτηρίων στην πραγματικότητα καλεί ένα πρόγραμμα που είναι ξεχωριστό από το ίδιο το Git· ποιο πρόγραμμα και πώς το καλεί εξαρτάται από την τιμή της μεταβλητής ρύθμισης `credential.helper`. +Μπορεί να πάρει διάφορες μορφές: [options="header"] |====== @@ -102,87 +103,89 @@ There are several forms it can take: | `!f() { echo "password=s3cre7"; }; f` | Code after `!` evaluated in shell |====== -So the helpers described above are actually named `git-credential-cache`, `git-credential-store`, and so on, and we can configure them to take command-line arguments. -The general form for this is ``git-credential-foo [args] .'' -The stdin/stdout protocol is the same as git-credential, but they use a slightly different set of actions: +Έτσι οι βοηθοί που περιγράφηκαν παραπάνω στην πραγματικότητα ονομάζονται `git-credential-cache`, `git-credential-store` κ.ο.κ. και μπορούμε να τους ρυθμίσουμε ώστε να λάβουν ορίσματα από τη γραμμή εντολών. +Η γενική μορφή είναι "`git-credential-foo [args] <ενέργεια>`". +Το πρωτόκολλο stdin/stdout είναι το ίδιο με αυτό της `git-credential`, αλλά χρησιμοποιούν ένα ελαφρώς διαφορετικό σύνολο ενεργειών: -* `get` is a request for a username/password pair. -* `store` is a request to save a set of credentials in this helper's memory. -* `erase` purge the credentials for the given properties from this helper's memory. +* `get` είναι ένα αίτημα για ένα ζεύγος ονόματος χρήστη/κωδικού πρόσβασης. +* `store` είναι ένα αίτημα για να αποθηκεύσουμε ένα σύνολο διαπιστευτηρίων στη μνήμη αυτού του βοηθού. +* `erase` είναι αίτημα διαγραφής των διαπιστευτηρίων για τις δοσμένες ιδιότητες από τη μνήμη αυτού του βοηθού. -For the `store` and `erase` actions, no response is required (Git ignores it anyway). -For the `get` action, however, Git is very interested in what the helper has to say. -If the helper doesn't know anything useful, it can simply exit with no output, but if it does know, it should augment the provided information with the information it has stored. -The output is treated like a series of assignment statements; anything provided will replace what Git already knows. +Για τις ενέργειες `store` και `delete`, δεν απαιτείται απάντηση (το Git τις αγνοεί ούτως ή άλλως). +Για την ενέργεια `get`, ωστόσο, το Git ενδιαφέρεται πολύ για το τι έχει να πει ο βοηθός. +Αν ο βοηθός δεν γνωρίζει τίποτα χρήσιμο, μπορεί απλά να τερματίσει χωρίς έξοδο, αλλά αν γνωρίζει, θα πρέπει να αυξήσει τις παρεχόμενες πληροφορίες με τις πληροφορίες που έχει αποθηκεύσει. +Η έξοδος αντιμετωπίζεται σαν μια ακολουθία δηλώσεων εκχώρησης· ο,τιδήποτε παρέχεται θα αντικαταστήσει αυτό που ήδη γνωρίζει το Git. -Here's the same example from above, but skipping git-credential and going straight for git-credential-store: +Ακολουθεί το ίδιο παράδειγμα όπως προηγουμένως, αλλά παρακάμπτοντας την `git-credential` και πηγαίνοντας κατευθείαν στην `git-credential-store`: [source,console] ---- -$ git credential-store --file ~/git.store store <1> +$ git credential-store --file ~/git.store store <1> protocol=https host=mygithost username=bob password=s3cre7 -$ git credential-store --file ~/git.store get <2> +$ git credential-store --file ~/git.store get <2> protocol=https host=mygithost -username=bob <3> +username=bob <3> password=s3cre7 ---- -<1> Here we tell `git-credential-store` to save some credentials: the username ``bob'' and the password ``s3cre7'' are to be used when `https://mygithost` is accessed. -<2> Now we'll retrieve those credentials. - We provide the parts of the connection we already know (`https://mygithost`), and an empty line. -<3> `git-credential-store` replies with the username and password we stored above. +<1> Εδώ λέμε στην `git-credential-store` να αποθηκεύσει κάποια διαπιστευτήρια: το όνομα χρήστη "`bob`" και ο κωδικός πρόσβασης "`s3cre7`" πρέπει να χρησιμοποιούνται όταν προσπελασζουμε τη διεύθυνση `https://mygithost`. +<2> Τώρα ανακτούμε αυτά τα διαπιστευτήρια. +    Παρέχουμε τα τμήματα της σύνδεσης που ήδη γνωρίζουμε (`https://mygithost`) και μια κενή γραμμή. +<3> Η `git-credential-store` απαντά με το όνομα χρήστη και τον κωδικό πρόσβασης που αποθηκεύσαμε παραπάνω. -Here's what the `~/git.store` file looks like: +Το αρχείο `~/git.store` τώρα μοιάζει με αυτό: -[source] +[source,ini] ---- https://bob:s3cre7@mygithost ---- -It's just a series of lines, each of which contains a credential-decorated URL. -The `osxkeychain` and `winstore` helpers use the native format of their backing stores, while `cache` uses its own in-memory format (which no other process can read). +Είναι μόνο για μια σειρά γραμμών, καθεμία από τις οποίες περιέχει μια διεύθυνση URL διακοσμημένη με διαπιστευτήρια. +Οι βοηθοί `osxkeychain` και `wincred` χρησιμοποιούν την εγγενή μορφή των καταστημάτων υποστήριξης, ενώ η `cache` χρησιμοποιεί τη δική της μορφή μνήμης (η οποία δεν μπορεί να διαβάσει καμία άλλη διαδικασία). -==== A Custom Credential Cache +==== Μία εξατομικευμένη προσωρινή μνήμη διαπιστευτηρίων -Given that `git-credential-store` and friends are separate programs from Git, it's not much of a leap to realize that _any_ program can be a Git credential helper. -The helpers provided by Git cover many common use cases, but not all. -For example, let's say your team has some credentials that are shared with the entire team, perhaps for deployment. -These are stored in a shared directory, but you don't want to copy them to your own credential store, because they change often. -None of the existing helpers cover this case; let's see what it would take to write our own. -There are several key features this program needs to have: +Δεδομένου ότι η `git-credential-store` και οι φίλοι της είναι προγράμματα ξεχωριστά από το Git, δεν είναι και μεγάλο διανοητικό άλμα να συνειδητοποιήσουμε ότι _οποιοδήποτε_ πρόγραμμα μπορεί να είναι βοηθός διαπιστευτηρίων Git. +Οι βοηθοί που παρέχονται από το Git καλύπτουν πολλές κοινές περιπτώσεις χρήσης αλλά όχι όλες. +Για παράδειγμα, ας υποθέσουμε ότι η ομάδα μας έχει ορισμένα διαπιστευτήρια που είναι κοινά σε ολόκληρη την ομάδα, ίσως για ανάπτυξη. +Αυτά αποθηκεύονται σε έναν κοινόχρηστο κατάλογο, αλλά δεν θέλουμε να τα αντιγράψουμε στο δικό μας κατάστημα διαπιστευτηρίων, επειδή αλλάζουν συχνά. +Κανένας από τους υπάρχοντες βοηθούς δεν καλύπτει αυτήν την περίπτωση· ας δούμε τι θα χρειαζόταν για να γράψουμε το δικό μας. +Υπάρχουν πολλά χαρακτηριστικά-κλειδά που πρέπει να έχει ένα τέτοιο πρόγραμμα: -. The only action we need to pay attention to is `get`; `store` and `erase` are write operations, so we'll just exit cleanly when they're received. -. The file format of the shared-credential file is the same as that used by `git-credential-store`. -. The location of that file is fairly standard, but we should allow the user to pass a custom path just in case. +. Η μόνη ενέργεια την οποία πρέπει να προσέξουμε πολύ είναι η `get`· οι `store` και `erase` είναι λειτουργίες εγγραφής, επομένως απλά θα τερματίσουμε χωρίς έξοδο όταν τις λάβουμε. +. Η μορφή αρχείου του αρχείου κοινόχρηστων διαπιστευτηρίων είναι ίδια με αυτήν που χρησιμοποιείται από την `git-credential-store`. +. Η τοποθεσία αυτού του αρχείου είναι αρκετά τυπική, αλλά θα πρέπει να δώσουμε τη δυνατότητα στον χρήστη να δίνει άλλη διαδρομή στην περίπτωση που το θέλει. -Once again, we'll write this extension in Ruby, but any language will work so long as Git can execute the finished product. -Here's the full source code of our new credential helper: +Επαναλαμβάνουμε ότι θα γράψουμε αυτήν την επέκταση σε Ruby, αλλά οποιαδήποτε γλώσσα θα λειτουργήσει εφόσον το Git μπορεί να εκτελέσει το τελικό προϊόν. +Εδώ είναι ο πλήρης πηγαίος κώδικας του νέου μας βοηθού διαπιστευτηρίων: [source,ruby] --------- +---- include::../git-credential-read-only[] --------- +---- -<1> Here we parse the command-line options, allowing the user to specify the input file. The default is `~/.git-credentials`. -<2> This program only responds if the action is `get` and the backing-store file exists. -<3> This loop reads from stdin until the first blank line is reached. - The inputs are stored in the `known` hash for later reference. -<4> This loop reads the contents of the storage file, looking for matches. - If the protocol and host from `known` match this line, the program prints the results to stdout and exits. +<1> Εδώ αναλύουμε τις επιλογές της γραμμής εντολών, επιτρέποντας στον χρήστη να καθορίσει το αρχείο εισόδου. + Η προεπιλογή είναι `~/.git-credentials`. +<2> Αυτό το πρόγραμμα αποκρίνεται μόνον εάν η ενέργεια είναι `get` και το αρχείο backing-store υπάρχει. +<3> Αυτός ο βρόχος διαβάζει από την stdin μέχρι να συναντήσει την πρώτη κενή γραμμή. +    Οι είσοδοι αποθηκεύονται στο πίνακα αναζήτηση `known` για μεταγενέστερη αναφορά. +<4> Αυτός ο βρόχος διαβάζει τα περιεχόμενα του αρχείου αποθήκευσης αναζητώντας αντιστοιχίες. +    Εάν το πρωτόκολλο και ο κεντρικός υπολογιστής από τη μεταβλητή `known` ταιριάζουν με αυτήν τη γραμμή, το πρόγραμμα εκτυπώνει τα αποτελέσματα στην stdout και τερματίζει. -We'll save our helper as `git-credential-read-only`, put it somewhere in our `PATH` and mark it executable. -Here's what an interactive session looks like: +Αποθηκεύουμε τον βοηθό μας ως `git-credential-read-only`, τον βάζουμε κάπου στο `PATH` μας και τον επισημόνουμε ως εκτελέσιμο. +Ακολουθεί μια διαδραστική συνεδρία: [source,console] ---- $ git credential-read-only --file=/mnt/shared/creds get protocol=https host=mygithost +username=bob protocol=https host=mygithost @@ -190,11 +193,11 @@ username=bob password=s3cre7 ---- -Since its name starts with ``git-'', we can use the simple syntax for the configuration value: +Επειδή το όνομά του ξεκινάει με "`git-`", μπορούμε να χρησιμοποιήσουμε την απλή σύνταξη για την τιμή της μεταβλητής ρύθμισης: [source,console] ---- -$ git config --global credential.helper read-only --file /mnt/shared/creds +$ git config --global credential.helper 'read-only --file /mnt/shared/creds' ---- -As you can see, extending this system is pretty straightforward, and can solve some common problems for you and your team. +Όπως μπορούμε να δούμε, η επέκταση αυτού του συστήματος είναι αρκετά απλή και μπορεί να λύσει μερικά κοινά προβλήματα για εμάς και την ομάδα μας. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index bf65ddf8f..d73ff4322 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -1,45 +1,48 @@ -=== Debugging with Git +=== Αποσφαλμάτωση με το Git -Git also provides a couple of tools to help you debug issues in your projects. -Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. +Το Git μάς παρέχει επίσης μερικά εργαλεία που μας βοηθούν να αποσφαλματώσουμε τα έργα μας. +Επειδή το Git έχει σχεδιαστεί για να λειτουργεί για σχεδόν οποιοδήποτε είδος έργου, αυτά τα εργαλεία είναι αρκετά γενικά, αλλά συχνά μπορούν να μας βοηθήσουν να εντοπίσουμε ένα σφάλμα ή έναν ένοχο όταν τα πράγματα πάνε στραβά. -[[_file_annotation]] -==== File Annotation +[[r_file_annotation]] +==== Επισημείωση αρχείων -If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. -It shows you what commit was the last to modify each line of any file. -So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. -This example uses the `-L` option to limit the output to lines 12 through 22: +Αν εντοπίζουμε ένα σφάλμα στον κώδικά μας και θέλουμε να μάθουμε πότε εισήχθη και γιατί, η επισημείωση (annotation) του αρχείου είναι συχνά το καλύτερο εργαλείο μας. +Μας δείχνει ποια ήταν η τελευταία υποβολή που τροποποποίησε κάθε γραμμή οποιουδήποτε αρχείου. +Έτσι, εάν δούμε ότι μια μέθοδος στον κώδικά μας έχει σφάλματα, μπορούμε να επισημειώσουμε το αρχείο με `git blame` για να δούμε πότε άλλαξε τελευταία φορά κάθε γραμμή της μεθόδου και από ποιον. + +Το παρακάτω παράδειγμα χρησιμοποιεί την `git blame` για να καθορίσει ποια υποβολή και ποιος υποβολέας ήταν υπεύθυνος για τις γραμμές στο πάνω-επίπεδο του Linux kernel `Makefile` και, επιπλέον, χρησιμοποιεί την επιλογή `-L` για να περιορίσει την έξοδο στις γραμμές 69 έως 82 αυτού του αρχείου: [source,console] ---- -$ git blame -L 12,22 simplegit.rb -^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 12) def show(tree = 'master') -^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 13) command("git show #{tree}") -^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 14) end -^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 15) -9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 16) def log(tree = 'master') -79eaf55d (Scott Chacon 2008-04-06 10:15:08 -0700 17) command("git log #{tree}") -9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 18) end -9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 19) -42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20) def blame(path) -42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21) command("git blame #{path}") -42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end ----- - -Notice that the first field is the partial SHA-1 of the commit that last modified that line. -The next two fields are values extracted from that commit–the author name and the authored date of that commit – so you can easily see who modified that line and when. -After that come the line number and the content of the file. -Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. -That commit is when this file was first added to this project, and those lines have been unchanged since. -This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here. - -Another cool thing about Git is that it doesn’t track file renames explicitly. -It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. -One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. -If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. -For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`. -By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from: +$ git blame -L 69,82 Makefile +b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line") +b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $(V) +^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71) endif +^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE +^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73) KBUILD_VERBOSE = 0 +^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 74) endif +^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 75) +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1) +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 77) quiet = +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 78) Q = +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 79) else +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 80) quiet=quiet_ +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 81) Q = @ +066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 82) endif +---- + +Παρατηρούμε ότι το πρώτο πεδίο είναι ο μερικός αριθμός SHA-1 της υποβολής που τροποποίησε τελευταία αυτήν τη γραμμή. +Τα επόμενα δύο πεδία είναι τιμές που εξάχθηκαν από αυτήν την υποβολή —το όνομα συγγραφέα και η ημερομηνία επεξεργασίας αυτής της υποβολής— για να μπορούμε εύκολα να δούμε ποιος τροποποίησε αυτήν τη γραμμή και πότε. +Ακολουθούν ο αριθμός γραμμής και το περιεχόμενο του αρχείου. +Επισής σημειώνουμε ότι `^1da177e4c3f4` γραμμές υποβολής, όπου το `^` πρόθεμα υποδηλώνει ότι οι γραμμές εισήχθησαν στην πρώτη υποβολή του αποθετηρίου και δεν έχουν αλλάξει από τότε. +Αυτό δημιουργεί μία μικρή σύγχυση, καθώς μέχρι στιγμής έχουμε δει τουλάχιστον τρεις διαφορετικούς τρόπους με τους οποίους το Git χρησιμοποιεί το `^` για να τροποποιήσει τον αριθμό SHA-1 μίας υποβολής, αλλά εδώ σημαίνει αυτό το πράγμα. + +Ένα άλλο πολύ ωραίο χαρακτηριστικό για το Git είναι ότι δεν παρακολουθεί απόλυτα το όνομα του αρχείου. +Καταγράφει τα στιγμιότυπα και στη συνέχεια προσπαθεί να καταλάβει τι μετονομάστηκε σιωπηρά, μετά την μετονομασία. +Μία από τις πιο ενδιαφέρουσες λειτουργίες αυτού είναι ότι μπορούμε να του ζητήσουμε επίσης να καταλάβει όλα τα είδη των κινήσεων του κώδικα. +Εάν μεταβιβάσουμε την επιλογή `-C` στην `git blame`, το Git αναλύει το αρχείο που επισημειώνουμε και προσπαθεί να καταλάβει από πού προήλθαν αποσπάσματα κώδικα μέσα του, εφόσον είχαν αντιγραφεί από κάπου αλλού. +Για παράδειγμα, ας πούμε ότι επανασχεδιάζουμε ένα αρχείο που ονομάζεται `GITServerHandler.m` σε πολλά αρχεία, ένα από τα οποία είναι `GITPackUpload.m`. +Αν κατηγορήσουμε το `GITPackUpload.m` με την επιλογή `-C`, μπορούμε να δούμε από πού προήλθαν τμήματα του κώδικα: [source,console] ---- @@ -59,22 +62,22 @@ ad11ac80 GITPackUpload.m (Scott 2009-03-24 150) 56ef2caf GITServerHandler.m (Scott 2009-01-05 153) ---- -This is really useful. -Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file. -Git tells you the original commit where you wrote those lines, even if it was in another file. +Αυτό είναι πραγματικά χρήσιμο. +Κανονικά, παίρνουμε ως αρχική υποβολή την υποβολή από την οποία αντιγράψαμε τον κώδικα, επειδή αυτή είναι η πρώτη φορά που αγγίξαμε αυτές τις γραμμές σε αυτό το αρχείο. +Το Git μάς λέει την αρχική υποβολή στην οποία γράψαμε αυτές τις γραμμές ακόμα κι αν ήταν σε άλλο αρχείο. -[[_binary_search]] -==== Binary Search +[[r_binary_search]] +==== Δυαδική αναζήτηση -Annotating a file helps if you know where the issue is to begin with. -If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help. -The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue. +Η επισημείωση ενός αρχείου βοηθάει αν ξέρουμε ήδη πού βρίσκεται το πρόβλημα. +Αν δεν ξέρουμε τι είναι χαλασμένο και υπήρξαν δεκάδες ή εκατοντάδες υποβολές από την τελευταία κατάσταση όπου γνωρίζουμε ότι ο κώδικας λειτουργούσε, πιθανότατα θα στραφούμε προς την `git bisect` για βοήθεια. +Η εντολή `bisect` (διχοτόμηση) κάνει μια δυαδική αναζήτηση μέσα στο ιστορικό των υποβολών μας για να μας βοηθήσει να εντοπίσουμε το συντομότερο δυνατό ποια υποβολή εισήγαγε ένα πρόβλημα. -Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. -You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong. -You can bisect the code to find out. -First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken. -Then, you must tell bisect when the last known good state was, using `git bisect good [good_commit]`: +Ας υποθέσουμε ότι μόλις ωθήσαμε μια έκδοση του κώδικά μας στην παραγωγή, παίρνουμε αναφορές σφαλμάτων σχετικά με κάτι που δεν συνέβαινε στο περιβάλλον ανάπτυξης και δεν μπορούμε να φανταστούμε γιατί ο κώδικας το κάνει αυτό. +Πηγαίνουμε πίσω στον κώδικά μας και αποδεικνύεται ότι μπορούμε να αναπαραγάγουμε το πρόβλημα, αλλά δεν μπορούμε να καταλάβουμε τι το δημιουργεί. +Μπορούμε να _διχοτομήσουμε_ τον κώδικα για να το ανακαλύψουμε. +Αρχικά τρέχουμε την `git bisect start` για να ξεκινήσει η διαδικασία της διοχοτόμησης και στη συνέχεια την `git bisect bad` για να πούμε στο σύστημα ότι η τρέχουσα υποβολή που χρησιμοποιούμε είναι χαλασμένη. +Στη συνέχεια, πρέπει να πούμε στην `bisect` ποια ήταν η τελευταία γνωστή καλή κατάσταση, χρησιμοποιώντας την `git bisect good `: [source,console] ---- @@ -85,10 +88,10 @@ Bisecting: 6 revisions left to test after this [ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo ---- -Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. -At this point, you can run your test to see if the issue exists as of this commit. -If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit. -It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey: +Το Git κατάλαβε ότι περίπου 12 υποβολές ήρθαν μεταξύ της υποβολής που σημειώσαμε ως της τελευταίας καλής υποβολής (v1.0) και της τρέχουσας κακής έκδοσης, και μετέβη (checkout) τη μεσαία για εμάς. +Σε αυτό το σημείο, μπορούμε να εκτελέσουμε κάποια δοκιμασία για να διαπιστώσουμε εάν υπάρχει το πρόβλημα σε αυτήν την υποβολή. +Εάν υπάρχει, τότε εισήχθη κάποια στιγμή πριν από αυτήν τη μεσαία υποβολή· αν δεν υπάρχει, τότε το πρόβλημα εισήχθη κάποια στιγμή μετά τη μεσαία υποβολή. +Αποδεικνύεται ότι το πρόβλημα δεν υπάρχει εδώ και το λέμε αυτό στο Git πληκτρολογώντας `git bisect good` και συνεχίζουμε την αναζήτηση του σφάλματος: [source,console] ---- @@ -97,8 +100,8 @@ Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing ---- -Now you’re on another commit, halfway between the one you just tested and your bad commit. -You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`: +Τώρα είμαστε σε μια άλλη υποβολή, στα μισά του δρόμου μεταξύ εκείνης που μόλις δοκιμάσαμε και της κακής υποβολής. +Πραγματοποιούμε ξανά τη δοκιμή μας και διαπιστώνουμε ότι αυτή η υποβολή είναι χαλασμένη, οπότε ενημερώνουμε σχετικά το Git με την `git bisect bad`: [source,console] ---- @@ -107,8 +110,8 @@ Bisecting: 1 revisions left to test after this [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table ---- -This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. -It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug: +Αυτή η υποβολή είναι μια χαρά, και τώρα το Git διαθέτει όλες τις πληροφορίες που χρειάζεται για να προσδιορίσει πού εισήχθη το πρόβλημα. +Μας λέει τον αριθμό SHA-1 της πρώτης κακής υποβολής και μας δείχνει μερικές από τις πληροφορίες της υποβολής και ποια αρχεία τροποποιήθηκαν σε αυτήν την υποβολή, ώστε να μπορούμε να καταλάβουμε τι ήταν αυτό που μπορεί να έχει εισάγει αυτό το σφάλμα: [source,console] ---- @@ -124,17 +127,17 @@ Date: Tue Jan 27 14:48:32 2009 -0800 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config ---- -When you’re finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you’ll end up in a weird state: +Εφόσον έχουμε τελειώσει, θα πρέπει να εκτελέσουμε την `git bisect reset` για να επαναφέρουμε τον `HEAD` στο σημείο που ήμασταν πριν ξεκινήσουμε αλλιώς θα καταλήξουμε σε μια περίεργη κατάσταση: [source,console] ---- $ git bisect reset ---- -This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes. -In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`. -First, you again tell it the scope of the bisect by providing the known bad and good commits. -You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second: +Αυτό είναι ένα ισχυρό εργαλείο που μπορεί να μας βοηθήσει να ελέγξουμε εκατοντάδες υποβολές για το πού εισήχθη ένα σφάλμα μέσα σε λίγα λεπτά. +Μάλιστα, αν έχουμε ένα script που θα τερματίσει με έξοδο 0 εάν το έργο είναι καλό ή όχι-0, αν το έργο είναι κακό, μπορούμε να αυτοματοποιήσουμε πλήρως την `git bisect`. +Καταρχάς της λέμε ξανά το εύρος της διχοτόμησης παρέχοντας τις γνωστές κακές και καλές υποβολές. +Αυτό μπορούμε να το κάνουμε με την εντολή `bisect start`, αναφέροντας πρώτα τη γνωστή κακή υποβολή και μετά τη γνωστή καλή υποβολη: [source,console] ---- @@ -142,5 +145,5 @@ $ git bisect start HEAD v1.0 $ git bisect run test-error.sh ---- -Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit. -You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you. +Με αυτόν τον τρόπο εκτελείται αυτόματα το `test-error.sh` σε κάθε ελεγχόμενη απόσπαση μέχρι να βρει η Git την πρώτη χαλασμένη υποβολή. +Μπορούμε επίσης να εκτελέσουμε κάτι σαν `make` ή `make tests` ή ό,τι διαθέτουμε που εκτελεί αυτοματοποιημένες δοκιμές για εμάς. diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index d448ebc53..90d8de6f5 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -1,11 +1,11 @@ -[[_interactive_staging]] -=== Interactive Staging +[[r_interactive_staging]] +=== Διαδραστική εργασία με το στάδιο καταχώρισης -Git comes with a couple of scripts that make some command-line tasks easier. -Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. -These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. -This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you. -If you run `git add` with the `-i` or `--interactive` option, Git goes into an interactive shell mode, displaying something like this: +Εδώ θα δούμε μερικές διαδραστικές εντολές που μπορούν να μας βοηθήσουν να επεξεργαστούμε εύκολα τις υποβολές μας ώστε να περιλάβουμε μόνο ορισμένους συνδυασμούς και τμήματα αρχείων. +Αυτά τα εργαλεία είναι πολύ χρήσιμα αν τροποποιήσουμε κάμποσα αρχεία και στη συνέχεια αποφασίσουμε ότι θέλουμε αυτές οι αλλαγές να είναι σε περισσότερες συνεκτικές υποβολές και όχι σε μια μεγάλη ακατάστατη υποβολή. +Με αυτόν τον τρόπο μπορούμε να βεβαιωθούμε ότι οι υποβολές μας είναι λογικά διαχωρισμένες και μπορούν εύκολα να αναθεωρηθούν από τους προγραμματιστές που συνεργάζονται μαζί μας. + +Αν εκτελέσουμε την `git add` με την επιλογή `-i` ή `--interactive`, το Git μεταβαίνει σε λειτουργία διαδραστικού κελύφους, εμφανίζοντας κάτι σαν αυτό: [source,console] ---- @@ -16,24 +16,23 @@ $ git add -i 3: unchanged +5/-1 lib/simplegit.rb *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp What now> ---- -You can see that this command shows you a much different view of your staging area – basically the same information you get with `git status` but a bit more succinct and informative. -It lists the changes you’ve staged on the left and unstaged changes on the right. +Μπορούμε να δούμε ότι αυτή η εντολή μας δείχνει μια πολύ διαφορετική εικόνα του σταδίου καταχώρισής μας —βασικά δίνει τις ίδιες πληροφορίες που παίρνουμε με την `git status` αλλά λίγο πιο συνοπτικά και ενημερωτικά. +Εμφανίζει τις αλλαγές που έχουμε προετοιμάσει για υποβολή στα αριστερά και τις υπόλοιπες στα δεξιά. -After this comes a Commands section. -Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged. +Μετά από αυτό έρχεται ένα τμήμα "`Εντολών`" ("`Commands`"), που μπορούμε να κάνουμε πολλά πράγματα, όπως προσθήκη αρχείων στο στάδιο καταχώρισης, απόσυρση αρχείων από το στάδιο καταχώρισης, προσθήκη τμημάτων αρχείων στο στάδιο καταχώρισης, προσθήκη μη παρακολουθύμενων αρχείων και εμφάνιση diff αρχείων που βρίσκονται στο στάδιο καταχώρισης. -==== Staging and Unstaging Files +==== Προσθήκη σε και απόσυρση από το στάδιο καταχώρισης -If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage: +Εάν πληκτρολογήσουμε `2` ή `u` στην ερώτηση `What now>`, το script μάς ρωτά ποια αρχεία που θέλουμε να προστεθούν στο στάδιο καταχώρισης: [source,console] ---- -What now> 2 +What now> u staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html @@ -41,7 +40,7 @@ What now> 2 Update>> ---- -To stage the TODO and index.html files, you can type the numbers: +Για να προσθέσουμε τα `TODO` και `index.html`, μπορούμε να πληκτρολογήσουμε τους αριθμούς τους: [source,console] ---- @@ -53,8 +52,8 @@ Update>> 1,2 Update>> ---- -The `*` next to each file means the file is selected to be staged. -If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you: +Το `*` δίπλα σε κάθε αρχείο σημαίνει ότι το αρχείο έχει επιλεγεί για να προστεθεί στο στάδιο καταχώρισης. +Εάν πατήσουμε το πλήκτρο Enter αφού πληκτρολογήσουμε κάτι στην προτροπή `Update>>`, το Git παίρνει ο,τιδήποτε έχει επιλεγεί και το προσθέτει στο στάδιο καταχώρισης: [source,console] ---- @@ -62,24 +61,24 @@ Update>> updated 2 paths *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help -What now> 1 + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp +What now> s staged unstaged path 1: +0/-1 nothing TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb ---- -Now you can see that the TODO and index.html files are staged and the simplegit.rb file is still unstaged. -If you want to unstage the TODO file at this point, you use the `3` or `r` (for revert) option: +Τώρα μπορούμε να δούμε ότι τα αρχεία `TODO` και `index.html` έχουν προστεθεί στο στάδιο καταχώρισης ενώ το αρχείο `simplegit.rb` εξακολουθεί να είναι εκτός του σταδίου καταχώρισης. +Αν τώρα θέλουμε να αποσύρουμε το αρχείο `TODO` από το στάδιο καταχώρισης, χρησιμοποιήσουμε την επιλογή `r` ή `3` (συντομογραφία για revert): [source,console] ---- *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help -What now> 3 + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp +What now> r staged unstaged path 1: +0/-1 nothing TODO 2: +1/-1 nothing index.html @@ -93,30 +92,30 @@ Revert>> [enter] reverted one path ---- -Looking at your Git status again, you can see that you’ve unstaged the TODO file: +Αν κοιτάξουμε πάλι την κατάσταση του Git, θα δούμε ότι το αρχείο `TODO` έχει αποσυρθεί από το στάδιο καταχώρισης: [source,console] ---- *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help -What now> 1 + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp +What now> s staged unstaged path 1: unchanged +0/-1 TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb ---- -To see the diff of what you’ve staged, you can use the `6` or `d` (for diff) command. -It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. -This is much like specifying `git diff --cached` on the command line: +Για να δούμε το diff των αρχείων που βρίσκονται στο στάδιο καταχώρισης, μπορούμε να χρησιμοποιήσουμε την εντολή `d` ή `6` (συντομογραφία για το diff). +Μας παρουσιάζει τη λίστα με τα αρχεία του σταδίου καταχώρισης και μπορούμε να επιλέξουμε εκείνα των οποίων το diff θέλουμε να δούμε. +Αυτό μοιάζει πολύ με την `git diff --cached` στη γραμμή εντολών: [source,console] ---- *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help -What now> 6 + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp +What now> d staged unstaged path 1: +1/-1 nothing index.html Review diff>> 1 @@ -134,14 +133,14 @@ index 4d07108..4335f49 100644