config.asc

Διαμόρφωση Git

Όπως έχουμε δει σύντομα στο ch01-introduction.asc, μπορούμε να καθορίσουμε τις ρυθμίσεις των παραμέτρων του Git με την εντολή git config. Ένα από τα πρώτα πράγματα που κάναμε ήταν να δημιουργήσουμε το όνομά μας και τη διεύθυνση ηλεκτρονικού ταχυδρομείου μας:

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]

Τώρα θα μάθουμε μερικές από τις πιο ενδιαφέρουσες επιλογές που μπορούμε να ορίσουμε με αυτόν τον τρόπο για να προσαρμόσουμε τη χρήση του Git μας.

Πρώτα όμως, μια γρήγορη ανασκόπηση: Το Git χρησιμοποιεί μια σειρά αρχείων ρυθμίσεων (configuration files) για να καθορίσει τη μη προεπιλεγμένη συμπεριφορά που μπορεί να θέλουμε. Το πρώτο μέρος στο οποίο ψάχνει το Git για αυτές τις τιμές είναι σε ένα αρχείο /etc/gitconfig, το οποίο περιέχει τιμές για κάθε χρήστη στο σύστημα και σε όλα τα αποθετήριά του. Εάν τρέξουμε το git config με την επιλογή --system, τότε το Git διαβάζει από και γράφει σε αυτό το αρχείο συγκεκριμένα.

Το επόμενο μέρος στο οποίο ψάχνει το Git είναι το αρχείο ~/.gitconfig (ή ~/.config/git/ config), το οποίο είναι συγκεκριμένος για κάθε χρήστη. Μπορούμε να κάνουμε το Git να διαβάζει από και να γράφει σε αυτό το αρχείο περνώντας την επιλογή --global.

Τέλος, το Git αναζητά τιμές διαμόρφωσης στο αρχείο ρυθμίσεων στον κατάλογο του Git (.git/config) του οποιουδήποτε αποθετηρίου χρησιμοποιούμε αυτήν τη στιγμή. Αυτές οι τιμές είναι συγκεκριμένες για αυτό το αποθετήριο.

Καθένα από αυτά τα `επίπεδα'' (σύστημα, παγκόσμιο, τοπικό) παρακάμπτει τις τιμές του προηγούμενου επίπεδου, έτσι ώστε, για παράδειγμα, οι τιμές στο `.git/config παρακάμπτουν εκείνες του /etc/gitconfig.

Note	Τα αρχεία ρυθμίσεων του Git είναι απλό κείμένο, επομένως μπορούμε επίσης να ορίσουμε αυτές τις τιμές με χειροκίνητη επεξεργασία του αρχείου και εισαγωγή της σωστής σύνταξης. Πάντως γενικά είναι ευκολότερο να εκτελέσουμε την εντολή git config.

Βασική διαμόρφωση πελάτη

Οι επιλογές διαμόρφωσης που αναγνωρίζονται από το Git εμπίπτουν σε δύο κατηγορίες: πλευράς πελάτη και πλευράς διακομιστή. Η πλειονότητα των επιλογών είναι από την πλευρά του πελάτη —διαμόρφωση των προσωπικών μας προτιμήσεων εργασίας. Υποστηρίζονται πολλές επιλογές διαμόρφωση, αλλά ένα μεγάλο μέρος από αυτές είναι χρήσιμες μόνο σε ορισμένες οριακές περιπτώσεις. Εδώ θα καλύψουμε μόνο τις πιο συνηθισμένες και πιο χρήσιμες. Εάν θέλουμε να δούμε μια λίστα με όλες τις επιλογές που αναγνωρίζει η έκδοση του Git, μπορούμε να εκτελέσουμε

$ man git-config

Αυτή η εντολή παραθέτει περιέχει όλες τις διαθέσιμες επιλογές με αρκετές λεπτομέρειες. Μπορούμε επίσης να βρούμε αυτό το υλικό αναφοράς στη διεύθυνση http://git-scm.com/docs/git-config.html.

===== 'core.editor`

Προκειμένου να δημιουργήσουμε και να επεξεργαστούμε τα μηνύματα commit και tag, το Git χρησιμοποιεί όποιον επεξεργαστή κειμένου έχουμε ορίσει ως προεπιλεγμένο ($VISUAL ή $EDITOR) ή αλλιώς μετακυλά στον επεξεργαστή vi . Για να αλλάξουμε αυτήν την προεπιλογή σε κάτι άλλο, μπορούμε να χρησιμοποιήσουμε τη ρύθμιση core.editor:

$ git config --global core.editor emacs

Τώρα, ανεξάρτητα από το τι έχει οριστεί ως προεπιλεγμένος επεξεργαστής στο κέλυφος, το Git θα τρέξει τον Emacs για να επεξεργαστεί τα μηνύματα.

commit.template

Εάν ορίσουμε αυτήν την παράμετρο να έχει ως τιμή τη διαδρομή ενός αρχείου στο σύστημά μας, το Git θα χρησιμοποιεί αυτό το αρχείο ως το προεπιλεγμένο μήνυμα όταν υποβάλλουμε. Για παράδειγμα, ας υποθέσουμε ότι δημιουργούμε ένα πρότυπο (template) αρχείο στο ~/.gitmessage.txt που μοιάζει με αυτό:

subject line

what happened

[ticket: X]

Για να πούμε στο Git να το χρησιμοποιήσει ως προεπιλεγμένο μήνυμα που εμφανίζεται στον επεξεργαστή μας όταν εκτελούμε το git commit, ορίζουμε την παράμετρο διαμόρφωσης commit.template:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Στη συνέχεια όταν υποβάλλουμε, ο επεξεργαστής κειμένου μας θα εμφανίσει κάτι τέτοιο ως προτροπή για μήνυμα υποβολής:

subject line

what happened

[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

Εάν η ομάδα μας έχει μια πολιτική για τα μηνύματα υποβολής, τότε η τοποθέτηση ενός προτύπου για αυτήν την πολιτική στο σύστημά μας και η διαμόρφωση του Git να το χρησιμοποιεί εκ προεπιλογής θα αυξήσει την πιθανότητα να ακολουθείται τακτικά αυτή η πολιτική.

core.pager

Αυτή η ρύθμιση καθορίζει ποιος σελιδοποιητής (pager) χρησιμοποιείται όταν το Git παραθέτει έξοδο όπως log και diff. Μπορούμε να διοχετεύσουμε την έξοδο στον more ή στον αγαπημένο μας σελιδοποιητή (εκ προεπιλογής, είναι ο less) ή μπορούμε να την απενεργοποιήσουμε θέτοντάς τη σε μια κενή συμβολοσειρά:

$ git config --global core.pager ''

Εάν εκτελέσουμε το παραπάνω, το Git θα εμφανίσει ολόκληρη την έξοδο όλων των εντολών, ανεξάρτητα από το μακροσκελής είναι.

user.signingkey

Εάν δημιουργούμε υπογεγραμμένες επισημειωμένες ετικέτες (όπως συζητήθηκε στην ενότητα ch07-git-tools.asc), η ρύθμιση του κλειδιού υπογραφής GPG ως τιμή παραμέτρου διευκολύνει την κατάσταση. Ορίζουμε το ID κλειδιού μας ως εξής:

$ git config --global user.signingkey <id_κλειδιού_gpg>

Τώρα, μπορούμε να υπογράφουμε ετικέτες χωρίς να χρειάζεται να καθορίζουμε το κλειδί μας κάθε φορά με την εντολή git tag

$ git tag -s <tag-name>

core.excludesfile

Μπορούμε να βάλουμε μοτίβα στο αρχείο .gitignore του έργου μας, ώστε να το Git να μην τα βλέπει μη-παρακολουθούμενα αρχεία ή προσπαθεί να τα βάλει στο στάδιο καταχώρισης τρέχουμε git add σε αυτά, όπως αναφέρθηκε στην ενότητα ch02-git-basics.asc.

Όμως μερικές φορές θέλουμε να αγνοήσουμε ορισμένα αρχεία για όλα τα αποθετήρια με τα οποία εργαζόμαστε. Εάν ο υπολογιστής μας τρέχει σε Mac OS X, ίσως γνωρίζουμε τα αρχεία .DS_Store· αν ο προτιμώμενος επεξεργαστής μας είναι ο Emacs ή ο Vim, γνωρίζουμε τα αρχεία που τελειώνουν σε ~.

Αυτή η ρύθμιση μάς επιτρέπει να γράψουμε ένα είδος καθολικού αρχείου .gitignore. Εάν δημιουργήσουμε ένα αρχείο ~/.gitignore_global με αυτά τα περιεχόμενα:

*~
.DS_Store

1. και τρέχουμε το git config --global core.excludesfile ~/.gitignore_global, το Git δεν θα μας ενοχλήσει ξανά για αυτά τα αρχεία.

help.autocorrect

Εάν πληκτρολογήσουμε λανθασμένα μια εντολή, μας δείχνει κάτι τέτοιο:

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

Did you mean this?
    checkout

Το Git προσπαθεί να καταλάβει τι εννοούσαμε, αλλά εξακολουθεί να αρνείται να το κάνει. Αν ορίσουμε την επιλογή help.autocorrect στην τιμή 1, τότε το Git θα τρέξει την εντολή αντί για εμάς:

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

Ας σημειωθεί ότι το `0.1 seconds'' προκύπτει από την τιμή 1 στην οποία θέσαμε το `help.autocorrect, αφού στην πραγματικότητα η help.autocorrect είναι ένας ακέραιος που αναπαριστά δέκατα του δευτερολέπτου. Έτσι, αν τη θέσουμε στην τιμή 50, το Git θα περιμένει 5 δευτερόλεπτα να αλλάξουμε γνώμη πριν εκτελέσει αυτο-διορθωμένη εντολή.

Χρώματα στο Git

Το Git υποστηρίζει πλήρως την έγχρωμη εκτύπωση στο τερματικού, η οποία βοηθά σημαντικά στη γρήγορη και εύκολη παραγωγή των εντολών. Ορισμένες επιλογές μπορούν να μας βοηθήσουν να ορίσουμε τον χρωματισμό στις προτιμήσεις μας.

color.ui

Το Git χρωματίζει αυτόματα το μεγαλύτερο μέρος της εξόδου του, αλλά υπάρχει ένας κύριος διακόπτης με τον οποίο μπορούμε να απενεργοποιήσουμε αυτήν τη συμπεριφορά, αν δεν μας αρέσει. Για να απενεργοποιήσουμε την έγχρωμη έξοδο του τερματικού Git, κάνουμε τα εξής:

$ git config --global color.ui false

Η προεπιλεγμένη ρύθμιση είναι auto, με την οποία τα χρωματίζεται η έξοδος όταν πηγαίνει κατευθείαν σε ένα τερματικό, αλλά ο χρωματισμός των κωδικών ελέγχου παραλείπεται όταν η έξοδος ανακατευθύνεται σε παροχέτευση (pipe) ή αρχείο.

Μπορούμε επίσης να τη ρυθμίσουμε σε always για να αγνοήσουμε τη διαφορά μεταξύ των τερματικών και των παροχετεύσεων. Αυτό είναι κάτι που Θα το θέλουμε σπάνια· στις περισσότερες περιπτώσεις εάν θέλουμε χωρματικούς κώδικες χρώματος στην έξοδο, μπορούμε απλά να περάσουμε μια σημαία --color στην εντολή Git για να την εξαναγκάσουμε να χρησιμοποιήσει χρωματικούς κώδικες. Η προεπιλεγμένη ρύθμιση είναι σχεδόν πάντα αυτό που θα θελήσουμε.

color.*

Εάν θέλουμε να είμαστε πιο συγκεκριμένοι σχετικά με το ποιες εντολές θέλουμε να είναι χρωματισμένες και πώς, το Git παρέχει ρυθμίσεις χρωματισμού συγκεκριμένων εντολών. Καθεμία από αυτές μπορεί να οριστεί σε 'true`, 'false` ή always:

color.branch
color.diff
color.interactive
color.status

Επιπλέον, καθεμία από αυτές έχει υπο-ρυθμίσεις διαιρέσεις που μπορούμε να χρησιμοποιήσουμε για να ορίσουμε συγκεκριμένα χρώματα για τμήματα της εξόδου, αν θέλουμε να παρακάμψουμε κάθε χρώμα. Για παράδειγμα, για να ορίσουμε τις μετα-πληροφορίες στην έξοδο diff μας σε μπλε προσκήνιο, μαύρο φόντο και έντονο κείμενο, μπορούμε να εκτελέσουμε

$ git config --global color.diff.meta "blue black bold"

Μπορούμε να ορίσουμε το χρώμα σε οποιαδήποτε από τις ακόλουθες τιμές: normal, black, red, green, yellow, blue, magenta, cyan ή white.

Εάν θέλουμε ένα χαρακτηριστικό, όπως οι έντονοι χαρακτήρες στο προηγούμενο παράδειγμα, μπορούμε να επιλέξουμε από bold, dim, ul (υπογράμμιση), blink και reverse (εναλλαγή προσκηνίου και φόντου).

Εξωτερικά εργαλεία συγχώνευσης και diff

Παρόλο που το Git έχει μια εσωτερική υλοποίηση της diff, που είναι αυτό που έχουμε δείξει σε αυτό το βιβλίο, μπορούμε να εγκαταστήσουμε ένα εξωτερικό εργαλείο αντί αυτού. Μπορούμε επίσης να ορίσουμε ένα γραφικό εργαλείο επίλυσης σσυγκρούσεων συγχώνευσης αντί να χρειάζεται να επιλύσουμε χειροκίνητα τις συγκρούσεις. Θα επιδείξουμε τη ρύθμιση του Perforce Visual Merge Tool (P4Merge) για να κάνουμε τις επιλύσεις της diff και των συγχωνεύσεων, επειδή είναι ένα ωραίο γραφικό εργαλείο και είναι δωρεάν.

Αν θέλουμε να το δοκιμάσουμε, το P4Merge λειτουργεί σε όλες τις μεγάλες πλατφόρμες, οπότε θα πρέπει να είμαστε σε θέση να το κάνουμε. Στα παραδείγματα Θα χρησιμοποιήσουμε ονόματα διαδρομών που λειτουργούν σε συστήματα Mac και Linux· για Windows, θα πρέπει να αλλάξουμε το /usr/local/bin σε μια εκτελέσιμη διαδρομή στο περιβάλλον μας.

Για να ξεκινήσουμε, πρέπει να κατεβάσουμε το P4Merge από την http://www.perforce.com/downloads/Perforce/. Στη συνέχεια θα δημιουργήσουμε εξωτερικά wrapper script για να εκτελέσουμε τις εντολές μας. Θα χρησιμοποιήσουμε τη διαδρομή Mac για το εκτελέσιμο· σε άλλα συστήματα, θα είναι όπου θα εγκατασταθεί το δυαδικό αρχείο p4merge. Ρυθμίζουμε ένα wrapper script συγχώνευσης που ονομάζεται extMerge και καλεί το εκτελέσιμο αρχείο μας με όλες τις παραμέτρους:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

Το περιτύλιγμα της diff ελέγχει για να βεβαιωθεί ότι υπάρχουν επτά παράμετροι και μεταβιβάζει δύο από αυτές στο script συγχώνευσης. Εκ προεπιλογής, το Git διαβιβάζει τις ακόλουθες παραμέτρους στο πρόγραμμα diff:

path old-file old-hex old-mode new-file new-hex new-mode

Επειδή θέλουμε μόνο τις παραμέτρους old-file και` new-file`, χρησιμοποιούμε το wrapper script για να περάσουμε αυτές που χρειαζόμαστε.

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

Πρέπει επίσης να βεβαιωθούμε ότι αυτά τα εργαλεία είναι εκτελέσιμα:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

Τώρα μπορούμε να ρυθμίσουμε το αρχείο config για να χρησιμοποιήσουμε τα προσαρμοσμένα εργαλεία επίλυσης συγχωνεύσεων και diff. Αυτό χρειάζεται μερικές ρυθμίσεις: merge.tool για να πει στο Git ποια στρατηγική να χρησιμοποιήσει, mergetool.<εργαλείο>.cmd για να καθορίσει τον τρόπο εκτέλεσης της εντολής, mergetool.<εργαλείο>.trustExitCode για να πει στο Git αν ο κωδικός τερματισμού του προγράμματος υποδεικνύει μια επιτυχημένη επίλυση συγχώνευσης ή όχι και diff.external για να πει στο Git τι εντολή τρέχει για τα diff. Έτσι, μπορούμε είτε να εκτελέσουμε τέσσερις εντολές config

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
  'extMerge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

είτε να επεξεργαστούμε το αρχείο ~/.gitconfig για να προσθέσουμε αυτές τις γραμμές:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

Μετά από όλα αυτά, εάν εκτελέσουμε κάποια εντολή diff όπως αυτή:

$ git diff 32d1776b1^ 32d1776b1

αντί να πάρουμε την έξοδο diff στη γραμμή εντολών, το Git ξεκινά το P4Merge, το οποίο μοιάζει με αυτό:

Figure 1. P4Merge.

Εάν προσπαθήσουμε να συγχωνεύσουμε δύο κλάδους και στη συνέχεια έχουμε συγκρούσεις συγχώνευσης, μπορούμε να εκτελέσουμε την εντολή git mergetool· θα ξεκινήσει το P4Merge για να μας επιτρέψει να επιλύσουμε τις συγκρούσεις μέσω αυτού του γραφικού εργαλείου.

Το ωραίο με αυτήν τη ρύθυμιση wrapper είναι ότι μπορούμε να αλλάξουμε εύκολα τα εργαλεία diff και συγχώνευσης. Για παράδειγμα, για να αλλάξουμε τα εργαλεία extDiff και extMerge και να εκτελέσουμε το εργαλείο KDiff3, το μόνο που έχουμε να κάνουμε είναι να επεξεργαστούμε το αρχείο extMerge:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

Τώρα, το Git θα χρησιμοποιήσει το εργαλείο KDiff3 για την προβολή των diff και την επίλυση συγκρούσεων συγχώνευσης.

Το Git είναι προ-ρυθμισμένο ώστε να χρησιμοποιεί διάφορα άλλα εργαλεία επίλυσης συγκρούσεων συγχώνευσης χωρίς να χρειάζεται να ρύθμιση της cmd. Για να δούμε μια λίστα με τα εργαλεία που υποστηρίζει, μπορούμε να κάνουμε το εξής:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

Αν δεν ενδιαφερόμαστε να χρησιμοποιήσουμε το KDiff3 για diff, αλλά θέλουμε να το χρησιμοποιήσουμε μόνο για επίλυση συγκρούσεων συγχώνευσης και η εντολή kdiff3 βρίσκεται στη διαδρομή μας, τότε μπορούμε να εκτελέσουμε

$ git config --global merge.tool kdiff3

Αν τρέξουμε αυτό αντί να ρυθμίσουμε τα αρχεία extMerge και` extDiff`, το Git θα χρησιμοποιήσει το KDiff3 για την ανάλυση συγχώνευσης και το κανονικό εργαλείο diff του Git για τις διαφορές.

Μορφοποίηση και λευκοί χαρακτήρες

Τα ζητήματα της μορφοποίησης και των λευκών χαρακτήρων είναι από τα προβλήματα που είναι δυσδιάκριτα και προκαλούν μεγάλη αγανάκτηση στους προγραμματιστές όταν συνεργάζονται, ειδικά αν εργάζονται σε διαφορετικές πλατφόρμες. Είναι πολύ εύκολο τα επιθέματα ή άλλες συνεργατικές εργασίες να εισάγουν δυσδιάκριτες αλλαγές στους λευκούς χαρακτήρες, επειδή οι επεξεργαστές κειμένου τους εισάγουν σιωπηλά και αν τα αρχεία μας έστω αγγίξουν ένα σύστημα των Windows, οι χαρακτήρες αλλαγής γραμμής τους ενδέχεται να αντικατασταθούν. Το Git έχει μερικές επιλογές για να βοηθήσει σε αυτά τα θέματα.

core.autocrlf

Εάν προγραμματίζουμε σε Windows και εργαζόμαστε με άτομα που δεν δουλεύουν σε άλλη πλατφόρμα (ή το αντίστροφο), πιθανότατα θα συναντήσουμε προβλήματα σχετικά με τους χαρακτήρες τερματισμού των γραμμών. Αυτό οφείλεται στο γεγονός ότι τα Windows χρησιμοποιούν τόσο χαρακτήρα επαναφοράς (carriage return —CR) όσο και αλλαγής γραμμής (line feed —LF) για την αλλαγή γραμμής στα αρχεία του ενώ τα συστήματα Mac και Linux χρησιμοποιούν μόνο τον χαρακτήρα αλλαγής γραμμής. Αυτό είναι ένα λεπτό, αλλά απίστευτα ενοχλητικό γεγονός της εργασίας σε διαφορετικές πλατφόρμες· πολλοί επεξεργαστές στα Windows σιωπηρά αντικαθιστούν τους υπάρχοντες χαρακτήρες τερματισμού γραμμών LF με CRLF ή εισάγουν και τους δύο χαρακτήρες αλλαγής γραμμής όταν ο χρήστης πατήσει το πλήκτρο Enter.

Το Git μπορεί να το χειριστεί αυτόματα μετατρέποντας τις λήξεις γραμμών CRLF σε LF όταν προσθέτουμε ένα αρχείο στο ευρετήριο και αντίστροφα όταν μεταφέρει κώδικα στο σύστημα αρχείων μας. Μπορούμε να ενεργοποιήσουμε αυτήν τη λειτουργία με τη ρύθμιση core.autocrlf. Αν βρισκόμαστε σε μηχάνημα Windows, το ρυθμίζοζυμε σε true —αυτό μετατρέπει τους χαρακτήρες τερματισμού γραμμής LF σε CRLF όταν κάνουμε ενημερώνουμε (checkout) τον κώδικα:

$ git config --global core.autocrlf true

Αν βρισκόμαστε σε ένα σύστημα Linux ή Mac που χρησιμοποιεί τερματισμούς γραμμής LF, τότε δεν θέλουμε το Git να τα μετατρέπει αυτόματα όταν ενημερώνουμε (checkout) τα αρχεία. Ωστόσο, εάν ένα αρχείο με λήξεις CRLF εισαχθεί τυχαία, τότε ίσως θέλουμε το Git να το διορθώσει. Μπορούμε να πούμε στο Git να μετατρέψει το CRLF σε LF για την commit, αλλά όχι το αντίστροφο, θέτοντας το core.autocrlf για είσοδο:

$ git config --global core.autocrlf input

Αυτή η ρύθμιση θα μας αφήσει με τερματισμούς γραμμών CRLF στην ενημέρωση (checkout) σε Windows, αλλά τερματισμούς LF τερματισμούς σε συστήματα Mac και Linux και στο αποθετήριο.

Εάν είμαστε προγραμματιστές Windows και εκτελούμε ένα έργο μόνο για Windows, τότε μπορούμε να απενεργοποιήσουμε αυτήν τη λειτουργία, καταγράφοντας τις επαναφορές φορέα στο αποθετήριο θέτοντας την τιμή core.autocrlf σε false:

$ git config --global core.autocrlf false

core.whitespace

Το Git έρχεται προκαθορισμένο για να ανιχνεύσει και να διορθώνει κάποια κενά θέματα λευκών χαρακτήρων. Μπορεί να αναζητήσει έξι συνήθη προβλήματα με λευκούς χαρακτήρες —τρία είναι ενεργοποιημένα εκ προεπιλογής και μπορούν να απενεργοποιηθούν και τρία είναι απενεργοποιημένα εκ προεπιλογής, αλλά μπορούν να ενεργοποιηθούν.

Τα τρία που είναι ενεργοποιημένα εκ προεπιλογής είναι: το blank-at-eol, που αναζητά διαστήματα στο τέλος μιας γραμμής· το blank-at-eof, που αναζητά κενές γραμμές στο τέλος ενός αρχείου· και το `space-before-tab', που αναζητά κενά πριν από στηλοθέτες (tabs) στην αρχή μιας γραμμής.

Τα τρία που είναι απενεργοποιημένα εκ προεπιλογής, αλλά μπορούν να ενεργοποιηθούν είναι: το indent-with-non-tab, που αναζητά γραμμές που αρχίζουν με κενά αντί για στηλοθέτες (και ελέγχεται από την επιλογή tabwidth)· το tab-in-indent, που ψάχνει για στηλοθέτες στην εσοχής μιας γραμμής· και το cr-at-eol, που λέει στο Git ότι οι χαρακτήρες επαναφοράς φορέα στο τέλος των γραμμών επιτρέπονται.

Μπορούμε να πούμε στο Git ποια από αυτά θέλουμε να ενεργοποιήσουμε θέτοντας core.whitespace στις τιμές που θέλουμε ή όχι, χωρισμένες με κόμματα. Μπορούμε να απενεργοποιήσουμε τις ρυθμίσεις είτε αφήνοντας τις έξω από τη συμβολοσειρά ρυθμίσεων είτε προτάσσοντας ένα - μπροστά από την τιμή. Για παράδειγμα, αν τα θέλουμε όλα εκτός από το cr-at-eol, μπορούμε να το κάνουμε ως εξής:

$ git config --global core.whitespace \
    trailing-space,space-before-tab,indent-with-non-tab

Το Git θα ανιχνεύσει αυτά τα θέματα όταν εκτελούμε μια εντολή git diff και θα προσπαθήσει να τα χρωματίσει ώστε ενδεχομένως να μπορέσουμε να τα διορθώσουμε πριν τα υποβάλλουμε. Επίσης, θα χρησιμοποιήσει αυτές τις τιμές για να μας βοηθήσει όταν εφαρμόζουμε επιθέματα με το git apply. Όταν εφαρμόζουμε επιθέματα, μπορούμε να ζητήσουμε από το Git να μας προειδοποιήσει εάν αυτά έχουν τα συγκεκριμένα προβλήματα λευκών χαρακτήρων:

$ git apply --whitespace=warn <επίθεμα>

Ή μπορούμε να βάλουμε το Git να προσπαθήσει να διορθώσει αυτόματα το πρόβλημα πριν την εφαρμογή του επιθέματος:

$ git apply --whitespace=fix <επίθεμα>

Αυτές οι επιλογές ισχύουν και για την εντολή git rebase. Αν έχουμε υποβάλει προβλήματα με λευκούς χαρακτήρες, αλλά δεν έχουμε ωθήσει ακόμα, μπορούμε να εκτελέσουμε την git rebase --whitespace = fix ώστε το Git να διορθώσει αυτόματα τα προβλήματα με τους λευκούς χαρακτήρες, καθώς ξαναγράφει τα επιθέματα.

Ρυθμίσεις διακομιστή

Αν και δεν υπάρχουν πολλές επιλογές διαμόρφωσης για την πλευρά του διακομιστή στο Git, υπάρχουν πάντως μερικές ενδιαφέρουσες που ενδεχομένως αξίζει να τις λάβουμε υπόψη.

receive.fsckObjects

Το Git είναι σε θέση να βεβαιωθεί ότι κάθε αντικείμενο που λαμβάνεται κατά τη διάρκεια μιας ώθησης εξακολουθεί να ταιριάζει με το άθροισμα ελέγχου SHA-1 και επισημαίνει έγκυρα αντικείμενα. Ωστόσο, αυτό δεν το κάνει εκ προεπιλογής· είναι μια αρκετά ακριβή λειτουργία και μπορεί να επιβραδύνει τη λειτουργία, ειδικά σε μεγάλα αποθετήρια ή ωθήσεις. Αν θέλουμε το Git να ελέγχει τη συνέπεια των αντικειμένων σε κάθε ώθηση, μπορούμε να το αναγκάσουμε να το κάνει θέτοντας την receive.fsckObjects σε true:

$ git config --system receive.fsckObjects true

Τώρα το Git θα ελέγχει την ακεραιότητα του αποθετηρίου μας πριν γίνεται αποδεκτή κάθε ώθηση για να βεβαιωθεί ότι οι ελαττωματικοί (ή κακόβουλοι) πελάτες δεν εισάγουν διεφθαρμένα δεδομένα.

receive.denyNonFastForwards

Εάν αλλάξουμε τη βάση υποβολής που έχουμε ήδη ωθήσει και στη συνέχεια προσπαθούμε να την ξαναωθήσουμε ή με κάποιον άλλο τρόπο επιχειρούμε να ωθήσουμε μια υποβολή σε ένα απομακρυσμένο κλάδο που δεν περιέχει την υποβολή στην οποία δείχνει ο απομακρυσμένος τρέχων κλάδος, θα εισπράξουμε άρνηση. Αυτή είναι γενικά καλή πολιτική· αλλά στην περίπτωση της αλλαγής βάσης, μπορούμε να δηλώσουμε ότι γνωρίζουμε τι κάνουμε και μπορούμε να επιβάλουμε την ενημέρωση του απομακρυσμένου κλάδου με μια σημαία -f στην εντολή push.

Για να πούμε στο Git να αρνείται τις υποχρεωτικές ωθήσεις, θέτουμς receive.denyNonFastForwards:

$ git config --system receive.denyNonFastForwards true

Ο άλλος τρόπος με τον οποίο μπορούμε να κάνουμε αυτό είναι μέσω των αγκίστρων λήψης από την πλευρά του διακομιστή, τα οποία θα καλύψουμε λίγο. Αυτή η προσέγγιση μάς επιτρέπει να κάνουμε πιο περίπλοκα πράγματα, όπως να αρνηθούμε μη-ταχείς προωθήσεις σε ένα συγκεκριμένο υποσύνολο χρηστών.

receive.denyDeletes

Ένας από τους τρόπους αντιμετώπισης της πολιτικής denyNonFastForwards είναι ο χρήστης να διαγράψει τον κλάδο και στη συνέχεια να τον ωθήσει ξανά με τη νέα αναφορά. Για να το αποφύγουμε αυτό, ορίζουμε την επιλογή receive.denyDeletes σε true:

$ git config --system receive.denyDeletes true

Αυτό αρνείται τη διαγραφή κλάδων ή ετικετών —κανένας χρήστης δεν μπορεί να το κάνει. Για να καταργήσουμε απομακρυσμένους κλάδους, πρέπει να αφαιρέσουμε τα αρχεία ref από τον διακομιστή με μη-αυτόματο τρόπο. Υπάρχουν επίσης πιο ενδιαφέροντες τρόποι για να το κάνουμε αυτό ανά χρήστη μέσω ACLs, όπως θα μάθουμε στο [r_an_example_git_enforced_policy].