Τώρα που ο λογαριασμός μας έχει ρυθμιστεί, ας δούμε κάποιες λεπτομέρειες που θα μπορούσαν να μας βοηθήσουν να συμβάλλουμε σε ένα υπάρχον έργο.
Εάν θέλουμε να συνεισφέρουμε σε ένα υπάρχον έργο στο οποίο δεν έχουμε πρόσβαση ώθησης, μπορούμε να ``αποσχίσουμε'' (fork) το έργο. Αυτό σημαίνει ότι το GitHub θα κάνει ένα αντίγραφο του έργου που είναι εξ ολοκλήρου δικό μας· ζει στον ονοματοχώρο του χρήστη που είμαστε και μπορούμε να ωθήσουμε σε αυτό.
|
Note
|
Ιστορικά, ο όρος |
Με αυτόν τον τρόπο, τα έργα δεν χρειάζεται να ανησυχούν για την προσθήκη χρηστών ως συνεργατών για να τους δώσουν πρόσβαση ώθησης. Οι συνεργάτες μπορούν να αποσχίσουν ένα έργο, να ωθήσουν σε αυτό και να συμβάλουν τις αλλαγές τους στο αρχικό αποθετήριο δημιουργώντας κάτι που ονομάζεται αίτημα έλξης (pull request), το οποίο θα καλύψουμε στη συνέχεια. Το αίτημα έλξης ανοίγει ένα νήμα συζήτησης με αναθεώρηση κώδικα, στο οποίο ο ιδιοκτήτης και ο συνεισφέρων μπορούν στη συνέχεια να επικοινωνούν σχετικά με τις αλλαγές μέχρι ο ιδιοκτήτης να ικανοποιηθεί από αυτές, οπότε μπορεί να τις συγχωνεύσει.
Για να αποσχίσουμε ένα έργο, επισκεφτόμαστε τη σελίδα του έργου και κάνουμε κλικ στο κουμπί ``Fork'' στο πάνω δεξί μέρος της σελίδας.
Μετά από λίγα δευτερόλεπτα, θα μεταφερθούμε στη νέα, δική μας σελίδα του έργου, με το δικό μας αντίγραφο του κώδικα στο οποίο έχουμε δικαίωμα επεξεργασίας.
Το GitHub είναι σχεδιασμένο γύρω από μια συγκεκριμένη συνεργατική ροή εργασίας, με επίκεντρο τα αιτήματα έλξης. Αυτή η ροή λειτουργεί είτε συνεργαζόμαστε με μια ομάδα με μεγάλη συνοχή σε ένα κοινό αποθετήριο, είτε με μια εταιρεία διασκορπισμένη σε όλο τον κόσμο, είτε ένα δίκτυο αγνώστων μεταξύ τους που συμβάλλουν σε ένα έργο μέσω δεκάδων διχαλών. Στο επίκεντρό της έχει τη ροή εργασιών της ενότητας ch03-git-branching.asc που καλύπτεται στο κεφάλαιο ch03-git-branching.asc.
Ας δούμε πώς λειτουργεί γενικά:
-
Δημιουργούμε έναν θεματικό κλάδο από τον κλάδο
master. -
Κάνουμε ορισμένες υποβολές ώστε αν βελτιώσουμε το έργο.
-
Ωθούμε αυτόν τον κλάδο στο έργο του GitHub.
-
Υποβάλλουμε ένα αίτημα έλξης στο GitHub.
-
Συζητάμε και, προαιρετικά, συνεχίζουμε να υποβάλλουμε.
-
Ο ιδιοκτήτης του έργου συγχωνεύει τον κλάδο ή κλείνει το αίτημα έλξης.
Αυτή είναι βασικά η ροή εργασίας με διαχειριστή ενσωμάτωσης που καλύπτεται στην ενότητα ch05-distributed-git.asc, αλλά οι ομάδες, αντί να χρησιμοποιούν email για να επικοινωνούν και να αναθεωρούν τις αλλαγές, χρησιμοποιούν τα εργαλεία της ιστοσελίδας του GitHub.
Ας δούμε ένα παράδειγμα πρότασης αλλαγής σε ένα έργο ανοιχτού κώδικα, που φιλοξενείται στο GitHub χρησιμοποιώντας αυτήν τη ροή.
Ο Tony ψάχνει κώδικα για να τρέξει στον προγραμματιζόμενο μικροελεγκτή του, Arduino, και βρήκε ένα εξαιρετικό πρόγραμμα στο GitHub στη διεύθυνση https://github.com/schacon/blink.
Το μόνο πρόβλημα είναι ότι ο ρυθμός με τον οποίο αναβοσβήνει το φωτάκι είναι πολύ γρήγορος. Θεωρούμε ότι θα ήταν πολύ καλύτερα αν περιμένε 3 δευτερόλεπτα αντί για 1 μεταξύ κάθε αλλαγής κατάστασης. Ας βελτιώσουμε λοιπόν το πρόγραμμα και ας υποβάλουμε τη βελτίωση στο έργο ως μια προτεινόμενη αλλαγή.
Πρώτα, κάνουμε κλικ στο κουμπί `Fork'', όπως αναφέρθηκε προηγουμένως, για να λάβουμε το δικό μας αντίγραφο του έργου.
Το όνομα χρήστη εδώ είναι `tonychacon, οπότε το αντίγραφο αυτού του έργου είναι στη διεύθυνση https://github.com/tonychacon/blink και εκεί μπορούμε να το επεξεργαστούμε.
Θα το κλωνοποιήσουμε τοπικά, θα δημιουργήσουμε έναν θεματικό κλάδο, θα κάνουμε αλλαγές στον κώδικα και τέλος θα ωθήσουμε αυτήν την αλλαγή πίσω στο GitHub.
$ git clone https://github.com/tonychacon/blink (1)
Cloning into 'blink'...
$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'
$ sed -i '' 's/1000/3000/' blink.ino (3)
$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// η ρουτίνα loop τρέχει ξανά και ξανά για πάντα:
void loop() {
digitalWrite(led, HIGH); // άναψε το LED (HIGH είναι η τάση)
[-delay(1000);-]{+delay(3000);+} // περίμενε 1 δευτερόλεπτο
digitalWrite(led, LOW); // σβήσε το LED κάνοντας την τάση LOW
[-delay(1000);-]{+delay(3000);+} // περίμενε 1 δευτερόλεπτο
}
$ git commit -a -m 'three seconds is better' (5)
[slow-blink 5ca509d] three seconds is better
1 file changed, 2 insertions(+), 2 deletions(-)
$ git push origin slow-blink (6)
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
* [new branch] slow-blink -> slow-blink-
Κλωνοποιούμε τη διχάλα του έργου σε τοπικό επίπεδο
-
Δημιουργούμε έναν περιγραφικό θεματικό κλάδο
-
Κάνουμε την αλλαγή που θέλουμε στον κώδικα
-
Ελέγχουμε ότι η αλλαγή είναι καλή
-
Υποβάλλουμε την αλλαγή στον θεματικό κλάδο
-
Ωθούμε τον νέο θεματικό κλάδο στη διχάλα μας στο GitHub
Τώρα, αν επιστρέψουμε στη διχάλα μας στο GitHub, μπορούμε να δούμε πως το GitHub παρατήρησε ότι ωθήσαμε έναν νέο θεματικό κλάδο και μας εμφανίζει ένα μεγάλο πράσινο κουμπί για να κάνουμε checkout τις αλλαγές μας και να υποβάλουμε ένα αίτημα έλξης στο αρχικό έργο.
Εναλλακτικά, μπορούμε να μεταβούμε στη σελίδα `branches'' στη διεύθυνση `https://github.com/<χρήστης>/<έργο>/branches για να εντοπίσουμε τον κλάδο μας και να υποβάλουμε ένα νέο αίτημα έλξης από εκεί.
Αν κάνουμε κλικ σε αυτό το πράσινο κουμπί, θα δούμε μια οθόνη που μας επιτρέπει να δημιουργήσουμε έναν τίτλο και μια περιγραφή για την αλλαγή που αιτούμαστε, ώστε ο ιδιοκτήτης του έργου να έχει κάποιον καλό λόγο να την εξετάσει. Είναι γενικά καλή ιδέα να καταβάλλουμε λίγη προσπάθεια ώστε να καταστήσουμε αυτήν την περιγραφή όσο το δυνατόν πιο χρήσιμη, ώστε ο συντάκτης να γνωρίζει γιατί προτείνεται αυτή η αλλαγή και γιατί θα πρέπει να την αποδεχτεί.
Επίσης, βλέπουμε μια λίστα των υποβολών μας στον θεματικό κλάδο μας που `προηγείται'' του κλάδου `master (στην περίπτωση αυτή, μόνο κατά μία υποβολή) και ένα ενοποιημένο diff όλων των αλλαγών που θα γίνουν σε περίπτωση που αυτός ο κλάδος συγχωνευτεί από τον ιδιοκτήτη του έργου.
Όταν πατήσουμε το κουμπί ``Create pull request'' σε αυτήν την οθόνη, ο ιδιοκτήτης του έργου, από το οποίο αποσχιστήκαμε, θα λάβει ειδοποίηση ότι κάποιος προτείνει μια αλλαγή και θα συνδεθεί σε μια σελίδα που περιέχει όλες αυτές τις πληροφορίες.
|
Note
|
Παρόλο που τα αιτήματα έλξης χρησιμοποιούνται συνήθως για δημόσια έργα όπως αυτό, στο οποίο ο συνεισφέρων έχει μια πλήρη αλλαγή έτοιμη προς υλοποίηση, επίσης συχνά χρησιμοποιείται σε ιδιωτικά έργα στην αρχή του κύκλου ανάπτυξης. Επειδή μπορούμε να συνεχίσουμε να ωθούμε στον θεματικό κλάδο ακόμα και μετά την υποβολή του αιτήματος έλξης, η υποβολή του αιτήματος έλξης δεν γίνεται στο τέλος της διαδικασίας, αλλά νωρίς και αποτελεί έναν τρόπο σταδιακής βελτίωσης της εργασίας με συνεισφορές από όλη την ομάδα. |
Σε αυτό το σημείο, ο ιδιοκτήτης του έργου μπορεί να εξετάσει την προτεινόμενη αλλαγή και να τη συγχωνεύσει, να την απορρίψει ή να τη σχολιάσει. Ας πούμε ότι του αρέσει η ιδέα, αλλά θα προτιμούσε το φως να είναι σβησμένο για περισσότερο χρόνο από όσο είναι ανσμμένο.
Ενώ αυτή η συζήτηση πραγματοποιείται μέσω email στις ροές εργασίας που παρουσιάζονται στην ενότητα ch05-distributed-git.asc, στο GitHub αυτό συμβαίνει στο διαδίκτυο. Ο ιδιοκτήτης του έργου μπορεί να ελέγξει το ενοποιημένο diff και να αφήσει ένα σχόλιο κάνοντας κλικ σε οποιαδήποτε από τις γραμμές.
Μόλις ο διαχειριστής κάνει αυτό το σχόλιο, ο χρήστης που υπέβαλε το αίτημα έλξης (όπως και οποιοσδήποτε άλλος παρακολουθεί το αποθετήριο) θα λάβει μια ειδοποίηση. Θα δούμε πώς αυτό είναι δυνατό να προσωποποιηθεί αργότερα, αλλά εάν είχε ενεργοποιημένες τις ειδοποιήσεις μέσω email, ο Tony θα λάμβανε ένα μήνυμα όπως αυτό:
Οποιοσδήποτε μπορεί να αφήσει γενικά σχόλια σχετικά με το αίτημα έλξης. Στην εικόνα Σελίδα συζήτησης αιτήματος μπορούμε να δούμε ένα παράδειγμα ενός ιδιοκτήτη έργου που σχολιάζει μια γραμμή κώδικα και στη συνέχεια αφήνει ένα γενικό σχόλιο στο τμήμα συζήτησης. Μπορούμε να δούμε ότι τα σχόλια του κώδικα συμπεριλαμβάνονται και στη συνομιλία.
Τώρα ο συνεισφέρων μπορεί να δει τι πρέπει να κάνει για να γίνει αποδεκτή η αλλαγή του. Ευτυχώς αυτό είναι επίσης πολύ απλό. Ενώ μέσω ηλεκτρονικού ταχυδρομείου θα χρειαζόταν να αναιρέσουμε τη σειρά αλλαγών και να την υποβάλουμε εκ νέου στην ηλεκτρονική λίστα αλληλογραφίας, με το GitHub απλά ξαναϋποβάλουμε (commit) τον θεματικό κλάδο και τον ξαναωθούμε (push). Αυτό θα ενημερώσει αυτόματα το αίτημα έλξης. Στην εικόνα Τελικό αίτημα έλξης, βλέπουμε επίσης ότι το παλιό σχόλιο έχει συμπτυχθεί στο ενημερωμένο αίτημα έλξης, διότι είχε γίνει για μία γραμμή που πλέον έχει τροποποιηθεί.
Κάτι ενδιαφέρον, που πρέπει να παρατηρήσουμε, είναι ότι αν κάνουμε κλικ στην καρτέλα Files changed'' σε αυτό το αίτημα έλξης, θα πάρουμε την ενοποιημένη'' diff —δηλαδή, τη συνολική αθροιστικά διαφορά που θα εισαγόταν στον κύριο κλάδο αν αυτός ο θεματικός κλάδος συγχωνευόταν. Με όρους git diff, ουσιαστικά μας δείχνει αυτόματα git diff master…<κλάδος> για τον κλάδο στον οποίο βασίζεται αυτό το αίτημα έλξης. Περισσότερες πληροφορίες σχετικά με αυτό το είδος diff υπάρχουν στην ενότητα ch05-distributed-git.asc.
Το άλλο που πρέπει να παρατηρήσουμε είναι ότι το GitHub ελέγχει εάν το αίτημα έλξης συγχωνεύεται χωρίς συγκρούσεις και σε αυτήν την περίπτωση μας παρέχει ένα κουμπί για να κάνουμε τη συγχώνευση στον διακομιστή. Αυτό το κουμπί εμφανίζεται μόνο αν έχουμε πρόσβαση εγγραφής στο αποθετήριο και αν είναι δυνατή μια τετριμμένη συγχώνευση. Εάν κάνουμε κλικ σ' αυτό το κουμπί, το GitHub θα εκτελέσει μια συγχώνευση ``non-fast forward'', κάτι που σημαίνει ότι ακόμα και αν η συγχώνευση θα μπορούσε να είναι ταχυπροώθηση, θα δημιουργήσει μια υποβολή συγχώνευσης.
Αν προτιμάμε, μπορούμε απλά να έλξουμε τον κλάδο μας στον υπολογιστή μας και τον συγχωνεύσουμε τοπικά. Εάν συγχωνεύσουμε αυτόν τον κλάδο στον κλάδο master και τον ωθήσουμε στο GitHub, το αίτημα έλξης θα κλείσει αυτόματα.
Αυτή είναι η βασική ροή εργασίας που χρησιμοποιούν τα περισσότερα έργα του GitHub. Δημιουργούνται θεματικοί κλάδοι, υποβάλλονται αιτήματα έλξης, ακολουθεί συζήτηση, ενδεχομένως γίνεται επιπλέον δουλειά στον κλάδο και τελικά το αίτημα είτε κλείνει είτε συγχωνεύεται.
|
Note
|
Όχι μόνον απόσχιση
Είναι σημαντικό να σημειώσουμε ότι μπορούμε επίσης να ανοίξουμε ένα αίτημα έλξης μεταξύ δύο κλάδων στο ίδιο αποθετήριο. Εάν εργαζόμαστε σε ένα χαρακτηριστικό με κάποιον και έχουμε και οι δύο πρόσβαση για εγγραφή στο έργο, μπορούμε να ωθήσουμε έναν θεματικό κλάδο στο αποθετήριο και να υποβάλουμε ένα αίτημα έλξης του από τον κλάδο |
Τώρα που καλύψαμε τα βασικά στοιχεία της συνεισφοράς σε ένα έργο στο GitHub, ας καλύψουμε μερικές ενδιαφέρουσες συμβουλές και κόλπα σχετικά με τα αιτήματα έλξης, ώστε να τα χρησιμοποιούμε αποτελεσματικότερα.
Είναι σημαντικό να καταλάβουμε ότι πολλά έργα, όσον αφορά στα αιτήματα έλξης, δεν βλέπουν ουρές τέλειων επιθεμάτων που πρέπει να εφαρμόζονται χωρίς συγκρούσεις το ένα μετά το άλλο, αντίθετα με τα περισσότερα έργα που βασίζονται σε ηλεκτρονική λίστα αλληλογραφίας, που βλέπουν συνεισφορές από σειρές επιθεμάτων. Τα περισσότερα έργα του GitHub σκέφτονται τους κλάδους αιτημάτων έλξης ως επαναληπτικές συνομιλίες γύρω από μια προτεινόμενη αλλαγή, με αποκορύφωμα μια ενοποιημένη diff που εφαρμόζεται με τη συγχώνευση.
Αυτή είναι μια σημαντική διάκριση, διότι γενικά η αλλαγή προτείνεται προτού ο κώδικας θεωρηθεί τέλειος, κάτι που είναι πολύ σπάνιο με τις συνεισφορές σειρών επιθεμάτων με βάση ηλεκτρονικές λίστες αλληλογραφίας. Αυτό επιτρέπει μια προηγούμενη συζήτηση με τους διαχειριστές συνεπώς η επίτευξη της σωστής λύσης είναι κατά μείζοντα λόγο μια συλλογική προσπάθεια της κοινότητας. Όταν ο κώδικας προτείνεται με ένα αίτημα έλξης και οι διαχειριστές ή η κοινότητα προτείνουν μια αλλαγή, η σειρά των επιθεμάτων γενικά δεν επαναφέρεται· αντίθετα η διαφορά ωθείται ως νέα υποβολή στον κλάδο, προχωρώντας τη συζήτηση και αφήνοντας το υπόλοιπο πλαίσιο άθικτο.
Για παράδειγμα, αν δούμε ξανά την εικόνα Τελικό αίτημα έλξης, θα παρατηρήσουμε ότι ο συνεισφέρων δεν άλλαξε τη βάση της υποβολής του και έστειλε άλλο αίτημα έλξης. Αντίθετα, πρόσθεσε νέες υποβολές και τις ώθησε στον υφιστάμενο κλάδο. Με αυτόν τον τρόπο, αν επανέλθουμε και εξετάσουμε αυτό το αίτημα έλξης στο μέλλον, μπορούμε εύκολα να βρούμε όλο το πλαίσιο όσον αφορά στο γιατί λήφθησαν οι συγκεκριμένες αποφάσεις. Πατώντας το κουμπί ``Merge'' δημιουργεί σκόπιμα μια υποβολή συγχώνευσης που αναφέρεται στο αίτημα έλξης, έτσι ώστε να είναι εύκολο να επιστρέψουμε και να διερευνήσουμε την αρχική συνομιλία, εφόσον χρειαστεί κάτι τέτοιο.
Αν το αίτημα έλξης δεν είναι ενημερωμένο ή δεν συγχωνεύεται χωρίς συγκρούσεις για κάποιον άλλο λόγο, θα χρειαστεί να το διορθώσουμε, έτσι ώστε ο διαχειριστής να μπορεί να το συγχωνεύσει εύκολα. Το GitHub θα το προσπαθήσει και θα μας ενημερώσει στο κάτω μέρος κάθε αιτήματος έλξης εάν η συγχώνευση είναι τετριμμένη ή όχι.
Εάν δούμε κάτι σαν την εικόνα Αποτυχία συγχώνευσης αιτήματος έλξης, θα χρειαστεί να διορθώσουμε τον κλάδο μας έτσι ώστε ο κλάδος να γίνει πράσινος και ο διαχειριστής να μην χρειάζεται να κάνει επιπρόσθετη εργασία.
Για να το κάνουμε αυτό, έχουμε δύο βασικές. Μπορούμε είτε να αλλάξουμε τη βάση (rebase) του κλάδου μας πάνω στον κλάδο-προορισμό, όποιος κι αν είναι αυτός (συνήθως ο κλάδος master του αποθετηρίου μας) είτε μπορούμε να συγχωνεύσουμε (merge) τον κλάδο-προορισμό στον κλάδο μας.
Οι περισσότεροι προγραμματιστές στο GitHub θα επιλέξουν να κάνουν το τελευταίο, για τους ίδιους λόγους που αναφέραμε στην προηγούμενη ενότητα. Αυτό που έχει σημασία είναι το ιστορικό και η τελική συγχώνευση, συνεπώς η αλλαγή βάσης (rebase), αν και είναι πολύ πιο δύσκολη και επιρρεπής σε σφάλματα, δεν μας προσφέρει τίποτα άλλο παρεκτός ένα ελαφρώς καθαρότερο ιστορικό.
Εάν θέλουμε να συγχωνεύσουμε (merge) τον κλάδο-προορισμό, ώστε να καταστήσουμε το αίτημα έλξης συγχωνεύσιμο, θα προσθέσουμε το αρχικό αποθετήριο ως νέο απομακρυσμένο, θα το παραλάβουμε (fetch), θα συγχωνεύσουμε τον κύριο κλάδο αυτού του αποθετηρίου στον θεματικό κλάδο μας, θα διορθώσουμε τυχόν προβλήματα και τελικά θα τον ωθήσουμε στον ίδιο κλάδο στον οποίο ανοίξαμε το αίτημα έλξης.
Για παράδειγμα, ας πούμε ότι στο παράδειγμα tonychacon που χρησιμοποιούσαμε πριν, ο αρχικός συγγραφέας έκανε μια αλλαγή που θα δημιουργούσε μια σύγκρουση στο αίτημα έλξης. Ας δούμε αυτά τα βήματα.
$ git remote add upstream https://github.com/schacon/blink (1)
$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
* [new branch] master -> upstream/master
$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.
$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
into slower-blink
$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
ef4725c..3c8d735 slower-blink -> slow-blink-
Προσθέτουμε το αρχικό αποθετήριο ως απομακρυσμένο με όνομα
upstream -
Λαμβάνουμε τη νεότερη έκδοση του απομακρυσμένου αποθετηρίου
-
Συγχωνεύουμε τον κύριο κλάδο στον θεματικό κλάδο
-
Διορθώνουμε τη σύγκρουση που συνέβη
-
Ωθούμε ξανά στον ίδιο θεματικό κλάδο.
Μόλις το κάνουμε αυτό, το αίτημα έλξης θα ενημερωθεί αυτόματα και θα επανελεγχθεί για να διαπιστωθεί εάν συγχωνεύεται καθαρά.
Ένα από τα σπουδαία πράγματα σχετικά με το Git είναι ότι μπορούμε να το κάνουμε αυτό συνεχώς. Εάν έχουμε ένα πολύ μακρόβιο έργο, μπορούμε εύκολα να συγχωνεύουμε τον κλάδο-προορισμό ξανά και ξανά και να αντιμετωπίζουμε μόνον τις συγκρούσεις που έχουν προκύψει από την τελευταία φορά που συγχωνεύθήκαμε, κάνοντας τη διαδικασία πολύ διαχειρίσιμη.
Εάν θέλουμε οπωσδήποτε να αλλάξουμε τη βάση (rebase) του κλάδου για να τον καθαρίσουμε, μπορούμε σίγουρα να το κάνουμε, αλλά συνιστάται έντονα να μην εξαναγκάσουμε την ώθηση του κλάδου στον οποίο βασίζεται το αίτημα έλξης. Εάν άλλοι συνεργάτες τον έχουν ελξει και κάνουν άλλη δουλειά σε αυτόν, θα συναντήσουμε σε όλα τα προβλήματα που περιγράφονται στην ενότητα ch03-git-branching.asc. Αντίθετα, συνιστάται να ωθήσουμε τον επανατοποθετημένο κλάδο σε έναν νέο κλάδο στο GitHub και να υποβάλλουμε ένα καινούργιο αίτημα έλξης αναφέροντας το παλιό και στη συνέχεια να κλείσουμε το αρχικό.
Η επόμενη ερώτησή μας μπορεί να είναι ``Πώς μπορώ να αναφερθώ στο παλιό αίτημα έλξης;'' Αποδεικνύεται ότι υπάρχουν πάρα πολλοί τρόποι να αναφερόμαστε σε άλλα πράγματα, σχεδόν οπουδήποτε μπορούμε να γράψουμε στο GitHub.
Ας ξεκινήσουμε με το πώς μπορούμε να αναφερθούμε σε κάποιο άλλο ζήτημα (issue) ή αίτημα έλξης. Σε όλα τα ζητήματα και τα αιτήματα έλξης έχουν εκχωρηθεί αριθμοί που είναι μοναδικοί στο πλαίσιο του έργου.
Για παράδειγμα, δεν μπορούμε να έχουμε Pull Request 3 και Issue #3.
Αν θέλουμε να αναφερθούμε σε οποιοδήποτε αίτημα έλξης ή ζήτημα από οποιοδήποτε άλλο, απλά να γράφουμε <αρθ> σε οποιοδήποτε σχόλιο ή περιγραφή.
Μπορούμε επίσης να είμαστε πιο συγκεκριμένοι αν το αίτημα έλξης ή ή ζήτημα βρίσκεται κάπου αλλού· γράφουμε username#<αρθ> αν αναφερόμαστε σε ένα αίτημα έλξης ή ζήτημα σε μια διχάλα του αποθετηρίου στο οποίο βρισκόμαστε ή username/repo#<αρθ> για να αναφερθούμε σε κάτι που βρίσκεται σε άλλο αποθετήριο.
Ας δούμε ένα παράδειγμα. Ας υποθέσουμε ότι αλλάξαμε τη βάση του κλάδου στο προηγούμενο παράδειγμα, δημιουργήσαμε ένα νέο αίτημα έλξης για αυτό και τώρα θέλουμε να αναφερθούμε στο παλιό αίτημα έλξης από το νέο. Θέλουμε επίσης να αναφερθούμε σε ένα ζήτημα στη διχάλα του αποθετηρίου και ένα ζήτημα σε ένα εντελώς διαφορετικό έργο. Μπορούμε να συμπληρώσουμε την περιγραφή ακριβώς όπως στην εικόνα Αναφορές σε αιτήματα έλξης.
Όταν υποβάλουμε αυτό το αίτημα έλξης, θα δούμε όλες οι αναφορές να εμφανίζονται όπως στην εικόνα Εμφάνιση αναφορών σε αίτημα έλξης.
Παρατηρούμε ότι η πλήρης διεύθυνση URL του GitHub που βάλουμε εκεί συντομεύτηκε μόνο στις απαραίτητες πληροφορίες.
Τώρα, αν ο Tony επιστρέψει και κλείσει το αρχικό αίτημα έλξης, θα δούμε ότι επειδή το έχουμε αναφέρει στο νέο αίτημα, το GitHub δημιούργησε αυτόματα ένα συμβάν trackback στο χρονολόγιο του αιτήματος έλξης. Αυτό σημαίνει ότι όποιος επισκέπτεται αυτό το αίτημα έλξης και βλέπει ότι είναι κλειστό, μπορεί εύκολα να συνδεθεί με εκείνο το αίτημα έλξης που το αντικατέστησε. Ο σύνδεσμος θα μοιάζει με το Εμφάνιση αναφορών σε κλειστό αίτημα έλξης.
Εκτός από τον αριθμό έκδοσης, μπορούμε επίσης να αναφερθούμε σε μια συγκεκριμένη υποβολή με τον αριθμό SHA-1. Πρέπει να χρησιμοποιήσουμε και τους 40 χαρακτήρες του SHA-1, αλλά εάν το GitHub το δει σε ένα σχόλιο, θα συνδεθεί άμεσα με την υποβολή. Επαναλαμβάνουμε ότι μπορούμε να αναφερθούμε σε υποβολές σε διχάλες ή άλλα αποθετήρια με τον ίδιο τρόπο που κάναμε με τα ζητήματα.
Η σύνδεση με άλλα θέματα είναι μόνο ένα από τα πολλά ενδιαφέροντα πράγματα που μπορούμε να κάνουμε με σχεδόν οποιοδήποτε πλαίσιο κειμένου στο GitHub. Στις περιγραφές των ζητημάτων και αιτημάτων έλξης, τα σχόλια, τα σχόλια κώδικα και πολλά άλλα, μπορούμε να χρησιμοποιήσουμε κάτι που ονομάζεται ``Markdown με άρωμα GitHub'' (GitHub flavored Markdown). Η Markdown είναι σαν να γράφουμε απλό κείμενο, το οποίο όμως εμφανίζεται με πλούσια μορφοποίηση.
Δείτε την εικόνα Παράδειγμα της Markdown: γραφή και εμφάνιση για ένα παράδειγμα του πώς μπορούν να γραφτούν σχόλια ή κείμενο και στη συνέχεια να αποδοθούν χρησιμοποιώντας την Markdown.
Η Markdown με άρωμα GitHub προσθέτει περισσότερα πράγματα που μπορούμε να κάνουμε πέρα από τη βασική σύνταξη Markdown. Όλα αυτά μπορούν να είναι πραγματικά χρήσιμα όταν δημιουργούμε αιτήματα έλξης, σχόλια ή περιγραφές.
Η πρώτη πραγματικά χρήσιμη λειτουργία της Markdown που υπάρχει μόνο στο GitHub, για να χρησιμοποιείται σε αιτήματα έλξης, είναι η λίστα εργασιών. Μια λίστα εργασιών είναι μια λίστα κουτιών επιλογής για πράγματα, που θέλουμε να υλοποιηθούν. Η τοποθέτησή τους σε ένα ζήτημα ή αίτημα έλξης συνήθως υποδεικνύει κάτι που θέλουμε να γίνει πριν να θεωρήσουμε ότι το στοιχείο αυτό έχει ολοκληρωθεί.
Μπορούμε να δημιουργήσουμε μια λίστα εργασιών όπως αυτή:
- [X] Write the code
- [ ] Write all the tests
- [ ] Document the codeΑν συμπεριλάβουμε αυτό στην περιγραφή ενός αιτήματος έλξης ή ενός ζητήματος μας, θα το δούμε να εμφανίζεται όπως στην εικόνα Λίστα καθηκόντων όπως εμφανίζεται σε σχόλιο Markdown..
Αυτό χρησιμοποιείται συχνά στα αιτήματα έλξης για να υποδείξουμε τι θα επιθυμούσαμε να γίνει στον κλάδο πριν να συγχωνευτεί το αίτημα έλξης. Το ωραίο είναι ότι μπορεί κανείς να κάνει κλικ στα πλαίσια ελέγχου για να ενημερώσει το σχόλιο —δεν χρειάζεται να επεξεργαστούμε άμεσα την Markdown για να τσεκάρουμε ή ξετσεκάρουμε αυτά τα καθήκοντα.
Επιπλέον το GitHub ψάχνει για λίστες καθηκόντων στα ζητήματά μας και τα αιτήματα έλξης και θα τα δείξει ως μεταδεδομένα στις σελίδες που τα παραθέτουν. Για παράδειγμα, εάν έχουμε ένα αίτημα έλξης με εργασίες και κοιτάζουμε τη σελίδα επισκόπησης όλων των αιτημάτων έλξης, μπορούμε να δούμε σε τι βαθμό έχουν υλοποιηθεί. Αυτό βοηθά στην ανάλυση των αιτημάτων έλξης σε υποκαθήκοντα και βοηθά στην παρακολούθηση της προόδου του κλάδου από όλους. Μπορούμε να δούμε ένα τέτοιο παράδειγμα στην εικόνα περίληψη λίστας καθηκόντων σε αίτημα έλξης.
Κάτι τέτοιο είναι εξαιρετικά χρήσιμο όταν ανοίγουμε νωρίς ένα αίτημα έλξης, για να παρακολουθούμε την πρόοδο υλοποίησής του.
Μπορούμε επίσης να προσθέσουμε αποσπάσματα κώδικα σε σχόλια. Αυτό είναι ιδιαίτερα χρήσιμο εάν θέλουμε να παρουσιάσουμε κάτι που θα μπορούσαμε να προσπαθήσουμε να κάνουμε, πριν το υλοποιήσουμε ως υποβολή στον κλάδο μας. Χρησιμοποιείται συχνά και για την προσθήκη παραδειγμάτων κώδικα για το τι δεν λειτουργεί ή για το τι θα μπορούσε να υλοποιήσει αυτό το αίτημα έλξης.
Για να προσθέσουμε ένα κομμάτι κώδικα, πρέπει να το περικλείσουμε σε βαρείες.
```java
for(int i=0 ; i < 5 ; i++)
{
System.out.println("i is : " + i);
}
```Εάν προσθέσουμε ένα όνομα γλώσσας όπως κάναμε εκεί με τη λέξη 'java', το GitHub θα προσπαθήσει επίσης να επισημάνει συντακτικά το απόσπασμα. Στην περίπτωση του παραπάνω παραδείγματος, θα καταλήξει σαν την εικόνα Παράδειγμα απόδοσης κώδικα περικλεισμένου σε βαρείες.
Εάν απαντάμε σε ένα μικρό κομμάτι ενός μακροσκελούς σχολίου, μπορούμε να κάνουμε επιλεκτική παράθεση από το άλλο σχόλιο ξεκινώντας τις γραμμές με τον χαρακτήρα >. Στην πραγματικότητα, αυτό είναι τόσο σύνηθες και τόσο χρήσιμο ώστε υπάρχει συντόμευση πληκτρολογίου για αυτό. Εάν επιλέξουμε κείμενο σε ένα σχόλιο στο οποίο θέλουμε να απαντήσουμε άμεσα και πατήσουμε το πλήκτρο r, θα παρατεθεί αυτό το κείμενο στο πλαίσιο σχολίων.
Τα παραθέματα μοιάζουν με το παρακάτω:
> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,
How big are these slings and in particular, these arrows?Μόλις αποδοθεί, το σχόλιο θα μοιάζει με την εικόνα Παράδειγμα απόδοσης παραθέματος.
Τέλος, στα σχόλιά μας μπορούμε επίσης να χρησιμοποιήσουμε emoji. Τα emoji χρησιμοποιούνται πραγματικά πολύ εκτενώς στα σχόλια που βλέπουμε σε πολλά ζητήματα και αιτήματα έλξης στο GitHub. Μάλιστα, υπάρχει ένας βοηθός emoji στο GitHub. Αν πληκτρολογούμε ένα σχόλιο και ξεκινάμε με ένα χαρακτήρα :, μία λίστα αυτόματης συμπλήρωσης θα μας βοηθήσει να βρούμε αυτό που ψάχνουμε.
Τα emoji έχουν τη μορφή :<όνομα>: οπουδήποτε στο σχόλιο. Για παράδειγμα, θα μπορούσαμε να γράψουμε κάτι σαν αυτό:
I :eyes: that :bug: and I :cold_sweat:.
:trophy: for :microscope: it.
:+1: and :sparkles: on this :ship:, it's :fire::poop:!
:clap::tada::panda_face:Αυτό θα εμφανιστεί όπως στην εικόνα << _md_emoji>>
Δεν είναι δα και ό,τι πιο χρήσιμο, αλλά είναι μία διασκεδαστική νότα και μέσο έκφρασης συναισθημάτων σε ένα μέσο στο οποίο είναι δύσκολη η μεταφορά συναισθημάτων με άλλον τρόπο.
|
Note
|
Στην πραγματικότητα υπάρχουν αρκετές διαδικτυακές υπηρεσίες που κάνουν χρήση των χαρακτήρων emoji σήμερα. Ένα εξαιρετικό σκονάκι για emoji υπάρχει στο: |
Το παρακάτω στην πραγματικότητα δεν είναι Markdown με άρωμα GitHub, αλλά είναι εξαιρετικά χρήσιμο. Η προσθήκη συνδέσμων σε εικόνες μπορεί να είναι μπελάς, αφού η εύρεση και ενσωμάτωση των URL των εικόνων μπορεί να είναι δύσκολη. Γι' αυτό, το GitHub μάς επιτρέπει να μεταφέρουμε και να ενσωματώσουμε εικόνες σε περιοχές κειμένου με μεταφορά-και-απόθεση.
Αν ανατρέξουμε στην εικόνα Αναφορές σε αιτήματα έλξης, μπορούμε να δούμε μια μικρή υπόδειξη Parsed as Markdown πάνω από την περιοχή κειμένου. Κάνοντας κλικ σε αυτό θα μας δοθεί ένα πλήρες σκονάκι με ό,τι μπορούμε να κάνουμε με την Markdown στο GitHub.