ΠΑΝΕΠΙΣΤΗΜΙΟ ΜΑΚΕΔΟΝΙΑΣ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ ΤΜΗΜΑΤΟΣ ΕΦΑΡΜΟΣΜΕΝΗΣ ΠΛΗΡΟΦΟΡΙΚΗΣ

ΠΑΝΕΠΙΣΤΗΜΙΟ ΜΑΚΕΔΟΝΙΑΣ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ ΤΜΗΜΑΤΟΣ ΕΦΑΡΜΟΣΜΕΝΗΣ ΠΛΗΡΟΦΟΡΙΚΗΣ ΕΞΑΓΩΓΗ ΔΕΔΟΜΕΝΩΝ ΑΠΟ ΑΠΟΘΕΤΗΡΙΑ ΣΦΑΛΜΑΤΩΝ. ΑΝΑΛΥΣΗ ΔΕΔΟΜΕΝΩΝ ΜΕ ΣΚΟΠΟ ΤΗ ΔΙΕΡΕΥΝΗΣΗ ΤΗΣ ΣΥΧΝΟΤΗΤΑΣ ΕΜΦΑΝΙΣΗΣ ΚΑΙ ΤΗΣ ΤΑΧΥΤΗΤΑΣ ΕΠΙΛΥΣΗΣ Διπλωματική Εργασία Του Κωνσταντίνου Παππά Θεσσαλονίκη, 10/2015

ΕΞΑΓΩΓΗ ΔΕΔΟΜΕΝΩΝ ΑΠΟ ΑΠΟΘΕΤΗΡΙΑ ΣΦΑΛΜΑΤΩΝ. ΑΝΑΛΥΣΗ ΔΕΔΟΜΕΝΩΝ ΜΕ ΣΚΟΠΟ ΤΗ ΔΙΕΡΕΥΝΗΣΗ ΤΗΣ ΣΥΧΝΟΤΗΤΑΣ ΕΜΦΑΝΙΣΗΣ ΚΑΙ ΤΗΣ ΤΑΧΥΤΗΤΑΣ ΕΠΙΛΥΣΗΣ Πτυχίο Οργάνωσης και Διοίκησης Επιχειρήσεων, 2006 υποβαλλόμενη για τη μερική εκπλήρωση των απαιτήσεων του ΜΕΤΑΠΤΥΧΙΑΚΟΥ ΤΙΤΛΟΥ ΣΠΟΥΔΩΝ ΣΤΗΝ ΕΦΑΡΜΟΣΜΕΝΗ ΠΛΗΡΟΦΟΡΙΚΗ Επιβλέπων Καθηγητής Χατζηγεωργίου Αλέξανδρος Εγκρίθηκε από την τριμελή εξεταστική επιτροπή την 22/10/2015 Ονοματεπώνυμο 1 Ονοματεπώνυμο 2 Ονοματεπώνυμο 3 ΧΑΤΖΗΓΕΩΡΓΙΟΥ ΑΛΕΞΑΝΔΡΟΣ ΓΕΩΡΓΙΑΔΗΣ ΧΡΗΣΤΟΣ ΣΤΕΙΑΚΑΚΗΣ ΕΜΜΑΝΟΥΗΛ Κωνσταντίνος Παππάς

ΠΕΡΙΛΗΨΗ Υπάρχει πλέον μια πληθώρα διαθέσιμων έργων ανοιχτού κώδικα, οργανωμένα σε διαφόρων τύπων αποθετήρια, καθώς και πληροφοριών σχετικά με αυτά διαθέσιμα στον κάθε ερευνητή. Η πληθώρα αυτή αποθετηρίων όμως έρχεται με κάποιες δυσκολίες οι οποίες πρέπει να λαμβάνονται υπόψη σε κάθε ερευνητική προσπάθεια. Ενώ υπάρχει αρκετός όγκος βιβλιογραφίας και μελετών που ασχολούνται με τα αποθετήρια κώδικα, ο κύριος όγκος ασχολείται με τα αποθετήρια σφαλμάτων και πιο συγκεκριμένα με την πρόβλεψη εμφάνισης σφαλμάτων και τους τρόπους αναγνώρισης διπλών σφαλμάτων από αυτοματοποιημένες μηχανές εκμάθησης. Υπάρχει μικρή αναφορά στη μέτρηση του αριθμού σφαλμάτων και τη διάρκεια επίλυσης αυτών ενώ θα μπορούσαν να αποτελούν σημαντικούς δείκτες για την συνολική πορεία του έργου και την συνολική απόδοση της ομάδας που εργάζεται σε αυτά. Σκοπός της εργασίας αυτής είναι η μελέτη αποθετηρίων σφαλμάτων. Από τα δεδομένα που θα εξαχθούν από τα αποθετήρια αυτά, θα μελετηθούν οι τάσεις της συχνότητας εμφάνισης σφαλμάτων σε έργα ανοιχτού κώδικα και της ταχύτητας επίλυσης αυτών στο πέρασμα του χρόνου. Η εργασία αυτή παρουσιάζει κάποια γενικά στοιχεία περί αποθετηρίων και των ειδών τους. Επίσης εξερευνά τους κυριότερους τρόπους δουλειάς με τα αποθετήρια κώδικα (workflows). Τέλος για την πραγματοποίηση μιας ποσοτικής μελέτης δεδομένων από ένα αποθετήριο κώδικα επικεντρώνεται στο γνωστότερο αποθετήριο κώδικα αυτή τη στιγμή στο Διαδίκτυο το GitHub. Παρουσιάζει μερικά γενικά στοιχεία για τον τρόπο με τον οποίο λειτουργεί και τις λειτουργίες που μπορεί να προσφέρει στους χρήστες του. Στη συνέχεια εξετάζει 20 αποθετήρια σφαλμάτων από τα πιο δημοφιλή έργα του GitHub για να δώσει απάντηση στα ερωτήματα: 1. Ποια είναι η γενική τάση του αριθμού εμφάνισης σφαλμάτων στα αποθετήρια σφαλμάτων του GitHub με το πέρασμα του χρόνου; 2. Πώς μεταβάλλεται ο συνολικός χρόνος επίλυσης σφαλμάτων με το πέρασμα του χρόνου; Παρουσιάζεται η μεθοδολογία και τα εργαλεία που χρησιμοποιήθηκαν για την άντληση και την επεξεργασία δεδομένων από τα αποθετήρια σφαλμάτων καθώς και οι τελικές παρατηρήσεις και τα συμπεράσματα τα οποία προκύπτουν από αυτές. Τέλος προτείνονται συγκεκριμένοι τρόποι επέκτασης της έρευνας πάνω στα ερευνητικά ερωτήματα 1 και 2. Λέξεις Κλειδιά: αποθετήρια σφαλμάτων, github, ροή εργασιών, workflow

ABSTRACT: There is a plethora of open source code projects on the internet, organized in various types of repositories as well as an abundance of related information, available to any researcher. This plethora however presents certain difficulties which should be taken into consideration in every research attempt. While there is quite a big amount of literature and studies about code repositories, the main body focuses on bug repositories and more specifically, with bug appearance prediction and methods of determining duplicate bug reports using automated machine language methods. Unfortunately there is but a small amount of references concerning bug counts and their corresponding resolution durations. These indexes could prove of great use to assessing the overall progress of a code project and the overall performance of a development team. The aim of this post-graduate thesis is the study of bug repositories. The data extracted from such repositories will provide insight to bug resolution time and occurrence frequency and through time in open source code development projects. The following thesis presents some general information about repositories and their classifications. It also explores the main workflows used in code repositories. Finally for the execution of a quantitative study of code repository data it will focus on the currently largest code repository on the internet, namely Github. Some general information about how Github works and what type of services it provides to its users will be presented. It then examines 20 of the most popular repositories on Github in order to answer the following research questions: 1. What is the general trend in bug occurrence frequency in Github bug repositories over time? 2. How does the overall bug resolution time vary with time? The tools and methodology utilized for the extraction and processing of data is presented as well as some final remarks and conclusions derived from this study. Finally a few recommendations concerning the advancement of the aforementioned research questions are proposed. Keywords: bug repositories, github, workflow

ΕΥΧΑΡΙΣΤΙΕΣ Θα ήθελα να ευχαριστήσω τον επιβλέποντα καθηγητή μου κ. Αλέξανδρο Χατζηγεωργίου για την αμέριστη υπομονή και συμπαράστασή του καθώς και τον υποψήφιο διδάκτορα κ. Θεόδωρο Χαϊκάλη για την πολύτιμη βοήθειά που προσέφερε καθόλη τη διάρκεια της εκπόνησης της εργασίας αυτής.

Περιεχόμενα ΕΙΣΑΓΩΓΗ... 7 ΠΡΟΒΛΗΜΑ ΣΗΜΑΝΤΙΚΟΤΗΤΑ ΤΟΥ ΘΕΜΑΤΟΣ... 7 ΣΚΟΠΟΣ ΣΤΟΧΟΙ... 7 ΕΡΩΤΗΜΑΤΑ... 8 ΔΙΑΡΘΡΩΣΗ ΤΗΣ ΜΕΛΕΤΗΣ... 8 ΒΙΒΛΙΟΓΡΑΦΙΚΗ ΕΠΙΣΚΟΠΗΣΗ ΘΕΩΡΗΤΙΚΟ ΥΠΟΒΑΡΘΡΟ... 9 ΑΠΟΘΕΤΗΡΙΑ... 9 ΑΠΟΘΕΤΗΡΙΟ GITHUB... 10 ΕΙΣΑΓΩΓΗ... 10 ΙΣΤΟΡΙΚΑ... 11 ΛΕΙΤΟΥΡΓΙΕΣ... 12 ΡΟΕΣ ΕΡΓΑΣΙΩΝ (WORKFLOWS)... 16 ΤΟ ΣΥΓΚΕΝΤΡΩΤΙΚΟ ΜΟΝΤΕΛΟ... 17 ΠΩΣ ΔΟΥΛΕΥΕΙ... 18 ΔΙΑΧΕΙΡΙΣΗ ΣΥΓΚΡΟΥΣΕΩΝ... 18 ΠΑΡΑΔΕΙΓΜΑ... 19 ΜΟΝΤΕΛΟ ΚΛΑΔΩΝ ΛΕΙΤΟΥΡΓΙΩΝ... 21 ΠΩΣ ΔΟΥΛΕΥΕΙ... 21 PULL REQUESTS... 22 ΠΑΡΑΔΕΙΓΜΑ... 22 MONTELO GITFLOW... 24 ΚΛΑΔΟΙ ΛΕΙΤΟΥΡΓΙΩΝ... 25 ΚΛΑΔΟΙ ΕΚΔΟΣΗΣ... 26 ΚΛΑΔΟΙ ΣΥΝΤΗΡΗΣΗΣ... 26 ΠΑΡΑΔΕΙΓΜΑ... 27 ΜΟΝΤΕΛΟ FORKING... 28 ΠΩΣ ΔΟΥΛΕΥΕΙ... 29 ΤΟ ΕΠΙΣΗΜΟ ΑΠΟΘΕΤΗΡΙΟ... 30 ΔΙΑΚΛΑΔΩΣΕΙΣ ΣΤΟ ΜΟΝΤΕΛΟ FORKING... 30 ΠΑΡΑΔΕΙΓΜΑ... 31 ΜΕΘΟΔΟΛΟΓΙΑ... 33 ΑΠΟΤΕΛΕΣΜΑΤΑ... 46 ΕΠΙΛΟΓΟΣ... 48 ΣΥΝΟΨΗ ΚΑΙ ΣΥΜΠΕΡΑΣΜΑΤΑ... 48 ΜΕΛΛΟΝΤΙΚΕΣ ΕΠΕΚΤΑΣΕΙΣ... 49 ΒΙΒΛΙΟΓΡΑΦΙΑ... 51

ΕΙΣΑΓΩΓΗ ΠΡΟΒΛΗΜΑ ΣΗΜΑΝΤΙΚΟΤΗΤΑ ΤΟΥ ΘΕΜΑΤΟΣ Όπως διαπιστώνουν οι Rodrigues et al. (2012) την τελευταία δεκαετία, η άνοδος το φαινομένου του ανοιχτού πηγαίου κώδικα και των κατανεμημένων συστημάτων ελέγχου έκδοσης κώδικα, έχουν καταστήσει ένα τεράστιο όγκο δεδομένων, χρήσιμο για ερευνητικούς σκοπούς, διαθέσιμο στους ερευνητές. Έτσι έχουμε την ευκαιρία να αποκτήσουμε δεδομένα από ένα μεγάλο αριθμό έργων κώδικα, με ένα οργανωμένο και δομημένο τρόπο, ώστε να είμαστε σε θέση να εξάγουμε εύκολα πληροφορίες από αυτά για να χρησιμοποιηθούν για ερευνητικούς σκοπούς. Μπορούμε να βρούμε πολλές πληροφορίες για τα έργα κώδικα που υπάρχουν στο διαδίκτυο ακριβώς επειδή φιλοξενούνται σε διάφορους τύπους αποθετηρίων, τα οποίο εξυπηρετούν διαφορετικούς σκοπούς το καθένα. Η εργασία αυτή ασχολείται με τα αποθετήρια σφαλμάτων. Στα σημεία αυτά που συγκεντρώνονται όλα τα σφάλματα που παρουσιάζονται κατά την ανάπτυξη ενός έργου κώδικα. Ποια δεδομένα μπορούν να εξαχθούν για τα σφάλματα αυτά από τα αποθετήρια; Πώς μπορούν να χρησιμοποιηθούν για την εξαγωγή χρήσιμων συμπερασμάτων για την πορεία του έργου; Η εξαγωγή κάποιων ποσοτικών δεδομένων από τα αποθετήρια σφαλμάτων και η ερμηνεία αυτών μπορεί να έχει πολλά οφέλη για όλους τους εμπλεκόμενους σε ένα έργο ανάπτυξης κώδικα. Χρησιμοποιώντας τη γνώση αυτή, οι διαχειριστές μπορούν να διαθέσουν πόρους για τη δοκιμή του κώδικα πιο αποτελεσματικά, οι προγραμματιστές μπορούν να επικεντρώσουν την προσοχή τους στα πιο «επικίνδυνα» σημεία κώδικα και οι δοκιμαστές του κώδικα μπορούν να επικεντρώσουν πιο αποτελεσματικά τις δοκιμές τους. ΣΚΟΠΟΣ ΣΤΟΧΟΙ Σκοπός της εργασίας αυτής είναι η μελέτη αποθετηρίων σφαλμάτων. Μετά τη συνοπτική επεξήγηση των διαφορετικών τύπων αποθετηρίων και των διαφορετικών τρόπων δουλειάς και συνεργασίας σε ένα τέτοιο αποθετήριο, θα γίνει μια ποσοτική μέτρηση σε ένα δείγμα από 20 έργα που φιλοξενούνται σε αποθετήρια σφαλμάτων και πιο συγκεκριμένα στο δημοφιλέστερο αποθετήριο κώδικα το Github. Από τα δεδομένα που θα εξαχθούν θα μελετηθούν οι τάσεις της συχνότητας εμφάνισης σφαλμάτων σε έργα ανοιχτού κώδικα και της ταχύτητας επίλυσης αυτών στο πέρασμα του χρόνου.

ΕΡΩΤΗΜΑΤΑ Η εργασία θέτει 2 βασικά ερευνητικά ερωτήματα τα οποία θα εξερευνήσει και θα προσπαθήσει να απαντήσει. 1. Ποια είναι η γενική τάση του αριθμού εμφάνισης σφαλμάτων στα αποθετήρια σφαλμάτων του GitHub με το πέρασμα του χρόνου; 2. Πώς μεταβάλλεται ο συνολικός χρόνος επίλυσης σφαλμάτων με το πέρασμα του χρόνου; Για την απάντηση των ερωτημάτων αυτών θα υποθέσουμε ότι όλα τα ζητήματα που θα αντλήσουμε είναι σχετικά με τον δημοσιευμένο κώδικα. Επίσης ότι δεν υπάρχουν διπλές και τριπλές αναφορές για το ίδιο σφάλμα μιας και το επίκεντρο είναι η γενική τάση εμφάνισης και επίλυσης σφαλμάτων. Η έρευνα και τα συμπεράσματα βασίζεται στην μελέτη ενός δείγματος 20 έργων κώδικα από τα πιο δημοφιλή στο αποθετήριο σφαλμάτων GitHub. Τα συμπεράσματα αφορούν στα 20 αυτά έργα και δεν επεκτείνονται απαραίτητα σε όλα τα έργα ανοιχτού κώδικα τα οποία φιλοξενούνται σε αποθετήρια σφαλμάτων. ΔΙΑΡΘΡΩΣΗ ΤΗΣ ΜΕΛΕΤΗΣ Αρχικά εξηγούμε έννοιες σχετικές με τα αποθετήρια. Ποιοι τύποι υπάρχουν, υπάρχουν, πως χρησιμοποιούνται και τι στοιχεία μπορούν να εξάγουν οι ερευνητές από αυτά. Γίνεται σύντομη αναφορά στις δυσκολίες που μπορεί να συναντήσει ο ερευνητής όταν προσπαθεί να αντλήσει δεδομένα από αποθετήρια. Κατόπιν παρουσιάζονται κάποια επίσης γενικά στοιχεία για το Github, την ιστορία του, τις υπηρεσίες του και την Διεπαφή Προγραμματισμού Εφαρμογών (API) που παρέχει για την άντληση δεδομένων. Γίνεται μια εκτενής αναφορά στις ροές εργασίων που χρησιμοποιούνται από ομάδες που εργάζονται σε έργα τα οποία φιλοξενούνται στο Github Μετά από μια σύντομη συζήτηση της υπάρχουσας βιβλιογραφίας γύρω από την μελέτη αποθετηρίων σφαλμάτων παρουσιάζεται η μεδοδολογία που ακολουθήθηκε για την εξαγωγή δεδομένων από το δείγμα των 20 έργων του Github. Τέλος παρουσιάζονται τα ευρήματα των μετρήσεων, τα συμπεράσματα που μπορούν να εξαχθούν από αυτά και προτείνονται τρόποι με τους οποίους μπορούν να χρησιμοποιηθούν σε περαιτέρω μελέτες πάνω στα αποθετήρια σφαλμάτων.

ΒΙΒΛΙΟΓΡΑΦΙΚΗ ΕΠΙΣΚΟΠΗΣΗ ΘΕΩΡΗΤΙΚΟ ΥΠΟΒΑΡΘΡΟ ΑΠΟΘΕΤΗΡΙΑ Την τελευταία δεκαετία, η άνοδος το φαινομένου του ανοιχτού πηγαίου κώδικα και των κατανεμημένων συστημάτων ελέγχου έκδοσης κώδικα, έχουν καταστήσει ένα τεράστιο όγκο δεδομένων, χρήσιμο για ερευνητικούς σκοπούς, διαθέσιμο στους ερευνητές. Έτσι έχουμε την ευκαιρία να αποκτήσουμε δεδομένα από ένα μεγάλο αριθμό έργων κώδικα, με ένα οργανωμένο και δομημένο τρόπο, ώστε να είμαστε σε θέση να εξάγουμε εύκολα πληροφορίες από αυτά για να χρησιμοποιηθούν για ερευνητικούς σκοπούς. Μπορούμε να βρούμε πολλές πληροφορίες για τα έργα κώδικα που υπάρχουν στο διαδίκτυο ακριβώς επειδή φιλοξενούνται σε διάφορους τύπους αποθετηρίων, τα οποίο εξυπηρετούν διαφορετικούς σκοπούς το καθένα. Οι Rodriguez et al. (2012) κατηγοριοποιούν τα αποθετήρια αυτά σε διάφορες κατηγορίες και περιγράφουν τα διαφορετικά προβλήματα που μπορεί να δημιουργηθούν κατά την ερευνητική προσπάθεια πάνω σε αυτά. Οι κυριότερες κατηγορίες αποθετηρίων είναι οι εξής: Πηγαίου κώδικα Ο πιο βασικός τύπος. Ο πηγαίος κώδικας μπορεί να μελετηθεί ως προς το μέγεθος και την πολυπλοκότητα Σύστημα Διαχείρισης Πηγαίου κώδικα Τα συστήματα αυτά καθιστούν δυνατή την αποθήκευση όλων των αλλαγών πάνω στον πηγαίο κώδικα. Επίσης επιτρέπουν την παράλληλη εργασία πάνω στον ίδιο κώδικα από διαφορετικούς προγραμματιστές. Κάθε αλλαγή πάνω στον κώδικα αποθηκεύεται μαζί με μια πληθώρα στοιχείων (συγγραφέας, ημερομηνία, λόγος δημιουργίας κτλ) Σύστημα παρακολούθησης σφαλμάτων Τα συστήματα αυτά διαχειρίζονται Σφάλματα, ελαττώματα και προβληματικά κομμάτια κώδικα με τη βοήθεια συστημάτων ticketing. Οι χρήστες και οι προγραμματιστές μπορούν να υποβάλλουν αιτήματα (tickets) με τη διόρθωση ή τη νέα λειτουργία που επιθυμούν. Τα συστήματα αποθηκεύουν τις πληροφορίες αυτές μαζί με τα στοιχεία του υποβολέα. Σε πολλές περιπτώσεις αποθηκεύουν και όλες τις επικοινωνίες μεταξύ των μελών σχετικά με το κάθε αίτημα. Συστήματα ανταλλαγής μηνυμάτων Στην περίπτωση των έργων ανοιχτού κώδικα όλες οι επικοινωνίες είναι διαθέσιμες στον καθένα υπό τη μορφή λιστών μηνυμάτων (mailing lists). Υπάρχουν επίσης και πλατφόρμες ανταλλαγής μηνυμάτων όπως mirc φόρα. Συμπληρωματικά στοιχεία για το έργο (meta-data) Χρήσιμα στοιχεία για το έργο όπως γλώσσα προγραμματισμού, πεδίο εφαρμογής κα.

Στοιχεία χρήσης Δεδομένα που προκύπτουν από το πόσες φορές έχει κατέβει ένα έργο κώδικα από χρήστη ή προγραμματιστή. Στην ίδια έρευνα περιγράφονται και τα κυριότερα προβήματα που παρουσιάζονται για τον ερευνητή όταν προσπαθέι να μελετήσει έργα ανοιχτού κώδικα. Σαν κύρια προβλήματα, με κάποιες υποπεριπτώσεις, περιγράφονται τα: Προβλήματα που δημιουργούνται κατά την εξαγωγή των δεδομένων Δυνατότητα αναπαραγωγής Προβλήματα ποιότητας δεδομένων σχετικά με μηχανές εκμάθησης. Όπως φαίνεται από τα παραπάνω υπάρχει πλέον μια πληθώρα διαθέσιμων έργων ανοιχτού κώδικα, οργανωμένα σε διαφόρων τύπων αποθετήρια, καθώς και πληροφοριών σχετικά με αυτά διαθέσιμα στον κάθε ερευνήτη. Η πληθώρα αυτή όμως έρχεται με κάποιες δυσκολίες οι οποίες πρέπει να λαμβάνονται υπόψη σε κάθε ερευνητική προσπάθεια. ΑΠΟΘΕΤΗΡΙΟ GITHUB ΕΙΣΑΓΩΓΗ Υπάρχει ένας μεγάλος αριθμός αποθετηρίων στο Διαδίκτυο. Στα αποθετήρια αυτά φιλοξενείται μεγάλος αριθμός έργων ανοιχτού πηγαίου κώδικα, τα οποία είναι δημόσια και διαθέσιμα στον κάθε προγραμματιστή ή χρήστη. Κάθε ενδιαφερόμενος μπορεί να συνδεθεί και να έχει πρόσβαση στον πηγαίο κώδικα, να τον κατεβάσει, να τον τροποποιήσει, να υποβάλλει τις αλλαγές του για ενσωμάτωση με τον κύριο κώδικα του έργου. Μπορεί επίσης να επικοινωνήσει με άλλους προγραμματιστές που ασχολούνται με το ίδιο έργο, να ανταλλάξει μηνύματα πάνω στις αλλαγές αυτές, καθώς και να στείλει αναφορές για προβληματικό κώδικα ή σφάλματα κώδικα και να ζητήσει καινούριες λειτουργίες. Τα σύγχρονα αποθετήρια συνδυάζουν πολλές από τις λειτουργίες που περιγράφονται παραπάνω, όπως για παράδειγμα αποθήκευση πηγαίου κώδικα, σύστημα διαχείρισης σφαλμάτων και ανταλλαγή μηνυμάτων μεταξύ των χρηστών, παρέχοντας στους χρήστες τους ένα ολοκληρωμένο περιβάλλον ανάπτυξης και διαχείρισης του κώδικα, έτσι ώστε μεγάλος αριθμός χρηστών και προγραμματιστών να μπορεί να συμμετάσχει στη διαδικασία ανάπτυξης και εξέλιξης των έργων ανοιχτού κώδικα. Μερικά τέτοια αποθετήρια είναι τα GitHub (https://github.com/), Bitbucket (https://bitbucket.org/), Google Developers (https://developers.google.com/)(πρώην Google Code)

SourceForge(https://code.google.com/), JavaForge(http://www.javaforge.com/login.spr) κ.α. Όλα τα αποθετήρια αυτά παρέχουν (με μικρές παραλλαγές) τις διάφορες υπηρεσίες στους χρήστες τους. Η επιλογή του αποθετηρίου είναι καθαρά θέμα προσωπικής προτίμησης από τον κάθε προγραμματιστή ή διαχειριστή του έργου. Πώς δουλεύει ένα σύγχρονο αποθετήριο κώδικα στο Διαδίκτυο; Ποιες λειτουργίες και υπηρεσίες παρέχει στους χρήστες του; Ποια μοντέλα χρησιμοποιούνται στον τρόπο οργάνωσης δουλειάς σε τέτοιο ανοιχτό περιβάλλον ανάπτυξης κώδικα; Για την εξερεύνηση αυτών των ερωτημάτων επιλέχτηκε το Github ως αντιπροσωπευτικό αποθετήριο ανοιχτού πηγαίου κώδικα. Το GitHub αποτελεί το μεγαλύτερο αποθετήριο έργων ανοιχτού πηγαίου κώδικα αυτή τη στιγμή, το οποίο διαθέτει τους περισσότερους ενεργούς χρήστες. Άλλος ένας λόγος για την επιλογή αυτή (εκτός από την δημοφιλία της συγκεκριμένης πλατφόρμας) είναι και η πάρα πολύ αποτελεσματική Διεπαφή Προγραμματισμού Εφαρμογών(API) η οποία παρέχει τη δυνατότητα εύκολης και γρήγορης εξαγωγής αναλυτικότατων δεδομένων για κάθε έργο κώδικα που φιλοξενείται από την πλατφόρμα. Μετά την εξερεύνηση των λειτουργιών του GitHub και των χαρακτηριστικών μεθόδων εργασίας σε ένα τέτοιο περιβάλλον προέκυψαν τα εξής ερευνητικά ερωτήματα σε σχέση με τις επιδόσεις τέτοιων κοινοτήτων προγραμματιστών όπως σχηματίζονται σε πλατφόρμες όπως το GitHub. Ποια είναι η συχνότητα εμφάνισης σφαλμάτων σε αποθετήρια όπως το GitHub; Ποια είναι η ταχύτητα επίλυσης των σφαλμάτων αυτών; Τα ερωτήματα αυτά θα εξεταστούν με τη χρήση εμπειρικών δεδομένων από έργα κώδικα που φιλοξενούνται στο GitHub. ΙΣΤΟΡΙΚΑ To GitHub είναι μια διαδικτυακή υπηρεσία η οποία προσφέρει όλες τις λειτουργίες κατανεμημένου ελέγχου εκδόσεων (distributed version control systems ή DVCS) και διαχείρισης κώδικα που προσφέρει η τεχνολογία git, ενώ προσθέτει και τις δικές της λειτουργίες. Το GitHub παρέχει ένα γραφικό περιβάλλον διαχείρισης στους χρήστες του το οποίο είναι διαθέσιμο και από σταθερούς υπολογιστές αλλά και από κινητά. Επίσης παρέχει λειτουργίες ελέγχου πρόσβασης στον κώδικα και διάφορα εργαλεία συνεργασίας όπως η παρακολούθηση ελαττωμάτων (bug tracking), η διαχείριση εργασιών (task management) και συστήματα τύπου wiki για την παρακολούθηση του κάθε έργου. (Williams (2012)) Το Github προσφέρει πλάνα και για ιδιωτικά repositories κώδικα άλλα και για δημόσια, το οποία συνήθως χρησιμοποιούνται για την φιλοξενία έργων κώδικα

ανοιχτού λογισμικού. Το 2015 το Github αναφέρει πάνω από 9 εκατομμύρια χρήστες και πάνω από 21, 1 εκατομμύρια repositories, μεγέθη που το καθιστούν τη μεγαλύτερη αποθήκη πηγαίου κώδικα στον κόσμο. (Gousios et al (2014)) Η ανάπτυξη της πλατφόρμας ξεκίνησε τον Οκτώβριο του 2007 και η ιστοσελίδα ολοκληρώθηκε τον Απρίλιο του 2008 από τους Tom Preston-Werner, Chris Wanstrath, and PJ Hyett, αφού προηγήθηκε μια σύντομη περίοδος δοκιμαστικής (beta) λειτουργίας. (Weis(2014)) Τα έργα στο GitHub μπορούν να προσπελαστούν και να διαχειριστούν χρησιμοποιώντας τη διεπαφή της γραμμής εντολών Git και όλες οι συνηθισμένες εντολές του Git δουλεύουν με αυτό. Το GitHub επιτρέπει επίσης σε εγγεγραμμένους χρήστες και μη να προσπελάσουν δημόσια repositories πηγαίου κώδικα ενώ υπάρχει και μια πληθώρα προγραμμάτων και εφαρμογών που χρησιμοποιούν το API του GitHub για να συνδεθούν με αυτό. Η ιστοσελίδα παρέχει λειτουργίες παρόμοιες με αυτές των κοινωνικών δικτύων όπως feeds, followers και wikis καθώς και κοινωνικά δίκτυα γράφων για να απεικονίσει πώς οι προγραμματιστές εργάζονται πάνω στις διαφορετικές εκδόσεις του κώδικά και πώς ενσωματώνουν τις αλλαγές τους, εξελίσσοντας έτσι τον πρωτότυπο κώδικα και διαμορφώνοντας με τον τρόπο αυτό την τελική έκδοση κάθε προγραμματιστικού έργου. Για να μπορέσει ο κάθε χρήστης να συνεισφέρει κώδικα, θα πρέπει να εγγραφεί στην πλατφόρμα, τα ανοιχτά και δημόσια έργα όμως είναι ελεύθερα προς κατέβασμα στον καθένα. Οι εγγεγραμμένοι χρήστες μπορούν να συζητήσουν μεταξύ τους, να διαχειριστούν και να δημιουργήσουν αποθετήρια να υποβάλλουν τις αλλαγές τους στα αποθετήρια άλλων χρηστών και να δουν τις αλλαγές που κάνουν άλλοι στον ίδιο κώδικα. (Wikipedia, Github (2015)) ΛΕΙΤΟΥΡΓΙΕΣ To GitHub παρέχει ένα πακέτο από εργαλεία που επιτρέπουν στους χρήστες του να είναι κοινωνικοί μεταξύ τους. Τα εργαλεία αυτά είναι φτιαγμένα γύρω από το σύστημα ελέγχου εκδόσεων Git και ενσωματώνει λειτουργικότητα παρόμοια με αυτή των κοινωνικών δικτύων, η οποία κάνει την ταυτότητα του κάθε προγραμματιστή και όλες τους τις ενέργειες ορατές σε όλους τους άλλους. Η μοναδικότητα του GitHub έγγυται ακριβώς στο ότι δημοσιοποιεί τις ταυτότητες, τα προφίλ καθώς και όλα τα εσωτερικά κομμάτια κώδικα και τις ενέργειες που πραγματοποιούνται πάνω σε αυτά σε μια πολύ μεγάλη κοινότητα χρηστών. (L. Dabbish et al (2012)) Στην ιστοσελίδα του GitHub οι προγραμματιστές δημιουργούν προφίλ τα οποία μπορούν προαιρετικά να εμπλουτιστούν με προσωπικές πληροφορίες, όπως η χρήση εικόνας (η οποία αντιπροσωπεύει το χρήστη στις κινήσεις του σε όλη την ιστοσελίδα), διεύθυνση email, όνομα οργανισμού, τοποθεσία και προσωπική ιστοσελίδα. Το προφίλ του κάθε προγραμματιστή είναι ορατό στους άλλους χρήστες και απεικονίζει όλα τα από αποθετήρια στα οποία έχει δουλέψει

ή δουλεύει αυτή τη στιγμή και μια λίστα με τις πιο πρόσφατες δραστηριότητες στην ιστοσελίδα. Εικόνα 0-1. Στιγμιότυπο προφίλ χρήστη στο GitHub Σύμφωνα με τις πιο πρόσφατες αναφορές το Github φιλοξενεί 21, 1 εκατομμύρια αποθετήρια. Ενώ η πλειοψηφία των έργων στο GitHub φαίνεται να είναι αποθετήρια κώδικα ενός και μόνου προγραμματιστή, υπάρχει πλειάδα έργων στα οποία συμμετέχουν πολλοί προγραμματιστές τα οποία είναι αρκετά μεγάλα και σε μέγεθος άλλα και σε διάρκεια ζωής. Κάθε αποθετήριο στο GitHub έχει τη δική του ξεχωριστή σελίδα, η οποία φιλοξενεί όλα τα αρχεία πηγαίου κώδικα, ιστορικό παραδόσεων (commit history), θέματα πάνω στον κώδικα τα οποία ακόμα εκκρεμούν και άλλα δεδομένα σχετικά με το έργο. Οι προγραμματιστές έχουν τη δυνατότητα να δημιουργούν συνδέσμους απευθείας σε συγκεκριμένα σημεία του κώδικα. Η δυνατότητα αυτή προσφέρει μεγάλη ευελιξία στην παρακολούθηση κώδικα στον οποίο συμμετέχουν πολλά άτομα ταυτόχρονα και επιτρέπει την κυκλοφορία των πληροφορίων αυτών και έξω από τα όρια της πλατφόρμας του GitHub στο ευρύτερο Διαδίκτυο. (L. Dabbish et al (2012)) Οι ενέργειες στο GitHub προκύπτουν όταν κάποιος χρήστης κάνει κάποια άλλαγη σε κάποιο κομμάτι κώδικα ή έχει κάποια διάδραση με κάποιο άλλο άτομο μέσω της ιστοσελίδας. Οι ενέργειες αυτές μπορούν να είναι σχετικές με τον κώδικα, επικοινωνία με άλλα άτομα ή εγγραφή σε κάποιο καινούριο αποθετήριο κώδικα (subscription). Οι ενέργειες που γίνονται πάνω στον κώδικα ή είναι σχετικές με τον κώδικα περιλαμβάνουν τις αλλαγές κώδικα (commits), τη δημιουργία κλάδου στον κώδικα (forking) και την υποβολή αιτήματος αποδοχής κάποιου καινούριου κομματιού κώδικα (pull request). Οι ιδιοκτήτες

και διαχειριστές των έργων (project owners) μπορούν να κάνουν commits με την απευθείας επεξεργασία των αρχείων του πηγαίου κώδικα. Οι προγραμματιστές που δεν έχουν δικαιώματα απευθείας αλλαγών, θα πρέπει να δημιουργήσουν ένα αντίγραφο του κώδικα (fork) το οποίο μπορούν να επεξεργαστούν και να αλλάξουν ελεύθερα χωρίς να επηρεάζεται το αρχικό αποθετήριο. Στη συνέχεια μπορούν να υποβάλλουν κάποιες ή όλες τις αλλαγές που έκαναν στο αντίγραφό τους με τη μορφή ενός pull request. Ο ιδιοκτήτης του έργου ή κάποιος χρήστης με δικαιώματα αλλαγών στον αρχικό πηγαίο κώδικα μπορεί να εγκρίνει τις αλλαγές αυτές και τότε οι αλλαγές γίνονται μέρος του κεντρικού αποθετηρίου και μέρος του αρχικού πηγαίου κώδικα. Οι προγραμματιστές έχουν επίσης τη δυνατότητα να επικοινωνούν μεταξύ τους καθόλη τη διάρκεια της διαδικασίας αυτής χρησιμοποιώντας τα κοινωνικά εργαλεία του GitHub και υποβάλλοντας τις παρατηρήσεις, απορίες, διορθώσεις τους πάνω στις αλλαγές του κώδικα σε οποιοδήποτε σημείο (commit, issue, pull request). Όλες οι ενέργειες αυτές καταγράφοντα και αρχειοθετούνται και η ενημερώσεις φτάνουν σε όλους τους χρήστες μέσω των ενεργειών της παρακολούθησης(follow) και της συνδρομής(subscribe). Οι προγραμματιστές μπορούν να ακολουθούν άλλους προγραμματιστές και τα αποθετήριά τους με το να τους εντάσσουν σε μια ροή νέων (news feed) με πολύ συχνές ειδοποιήσεις για τις ενέργειες που λαμβάνουν χώρα σε κάθε έργο(l. Dabbish et al (2012)) Εικόνα 0-2. Στιγμιότυπο ροή πληροφοριών έργου στο GitHub

Οι ενέργειες που αφορούν σε κώδικα καταχωρούνται και αυτές με τη σειρά τους με την πάροδο του χρόνου. Η ροή των ενεργειών παρουσιάζει μια πρόσφατη ιστορία των commits, issues και pull requests καθώς και όλων των σχολίων που έγιναν πάνω σε αυτά από τους εμπλεκόμενους χρήστες. Όλες αυτές οι πληροφορίες απεικονίζονται με απλό και ευανάγνωστο τρόπο στην ξεχωριστή σελίδα του κάθε έργου. (L. Dabbish et al (2012)) Στις παραπάνω ενότητες παρουσιάσαμε κάποια γενικά στοιχεία για το GitHub καθώς και αναφερθήκαμε πιο αναλυτικά στις συγκεκριμένες λειτουργίες που προσφέρει στους χρήστες και τους προγραμματιστές. Επίσης αναφερθήκαμε στις διαφορετικές ενέργειες που μπορεί κάποιος να πραγματοποιήσει στο περιβάλλον του GitHub, οι οποίες βασίζονται στις μεθόδους που παρέχει η τεχνολογία git. Παρακάτω θα εξερευνήσουμε με ποιους τρόπους μπορεί κάποιος να οργανώσει τον τρόπο δουλειάς του ώστε να εκμεταλλευτεί όλα τα εργαλεία που το προσφέρει το GitHub και να μπορέσει να αυξήσει την αποδοτικότητα και την παραγωγικότητα μιας ομάδας προγραμματιστών οι οποίοι εργάζονται απομακρυσμένα πάνω στο ίδιο έργο.

ΡΟΕΣ ΕΡΓΑΣΙΩΝ (WORKFLOWS) Τα συστήματα κατανεμημένου ελέγχου εκδόσεων δίνουν τη δυνατότητα στις ομάδες προγραμματιστών να δομήσουν την διαδικασία ανάπτυξης λογισμικού ανεξάρτητα, επιτρέποντας την παράλληλη εργασία πάνω στον ίδιο κώδικα. Αυτό σημαίνει πως δημιουργούνται θέματα οργάνωσης και εκτέλεσης αυτών των εργασιών, ώστε να επιτυγχάνεται η σωστή συνεργασία και η συνεννόηση μεταξύ των μελών της ομάδας. (Kalliamvakou et al (2014)) Η επιλογή πρακτικών ανάπτυξης λογισμικού έχει επιπτώσεις στην συνεργασία των μελών της ομάδας ανάπτυξης. Για παράδειγμα τα συστήματα ελέγχου εκδόσεων μπορεί να στρέφονται γύρω από τη διαχείριση του πηγαίου κώδικα, άλλα είναι άμεσα συνδεδεμένα με την διαδικασία που ακολουθεί η κάθε ομάδα για να μπορεί να διαχειρίζεται τις συνεισφορές κάθε μέλους της στο έργο. Η ροή εργασιών (workflow) που προκύπτει περιγράφει με ποιον τρόπο εργάζεται η ομάδα και ορίζει ποιες και πότε είναι αναγκαίες οι διαδράσεις μεταξύ των μελών της ομάδας. Με τρόπο αυτό ορίζεται ένα συγκεκριμένο πλαίσιο εργασίας μέσα στο οποίο κινούνται όλα τα μέλη της ομάδας. (B. O Sullivan (2009)) Τα συστήματα κατανεμημένου ελέγχου εκδόσεων δίνουν τη δυνατότητα ανάπτυξης λογισμικού με πιο ανεξάρτητο τρόπο. Τα μέλη της ομάδας διατηρούν το δικό τους τοπικό αντίγραφο κώδικα και χρησιμοποιούν κλάδους (branches) για να εργάζονται πάνω σε καινούριες λειτουργίες ή διορθώσεις ανεξάρτητα από τα υπόλοιπα μέλη της ομάδας, ελαχιστοποιώντας έτσι τα σημεία επαφής μεταξύ τους. Τα συστήματα κατανεμημένου ελέγχου εκδόσεων δημιουργούν διαφορετικά μοντέλα ροής εργασιών. (S. Chacon (2009)) Παρακάτω παρουσιάζουμε τι είναι μια ροή εργασίας και τι είδους μοντέλων ροών εργασίας χρησιμοποιούνται στην ανάπτυξη λογισμικού από ομάδες που χρησιμοποιούν πλατφόρμες σαν το GitHub. Μια ροή εργασίας αποτελείται από μια σειρά συνδεδεμένων βημάτων, προκειμένου να ολοκληρωθεί μια εργασία. Είναι μια απεικόνιση της ακολουθίας των πράξεων, που δηλώθηκαν ως έργο ενός ατόμου, μιας ομάδα προσώπων, του προσωπικού ενός οργανισμού, ή ενός ή περισσότερων απλών ή πολύπλοκων μηχανισμών. Ροή εργασίας μπορεί να θεωρηθεί οποιαδήποτε αφαίρεση πραγματικής δουλειάς, που διαχωρίζεται σε επιμέρους εργασίες, οι οποίες πρέπει να πραγματωθούν σε μια σειρά. Για σκοπούς ελέγχου, η ροή εργασίας μπορεί να είναι η απεικόνιση μιας πραγματικής δουλειάς στο πλαίσιο μιας επιλεγμένης άποψης. Δηλαδή, μια εικονική αναπαράσταση της πραγματικής εργασίας. Η ροή που περιγράφεται συχνά αναφέρεται σε ένα έγγραφο που έχει μεταφερθεί από το ένα στάδιο στο άλλο. Workflow (2015) Μια ροή εργασίας είναι ένα πρότυπο για να αντιπροσωπεύει μια πραγματική δουλειά για την περαιτέρω εκτίμηση, π.χ., για την περιγραφή μιας αξιόπιστης επαναλαμβανόμενης αλληλουχίας ενεργειών. Πιο αφηρημένα, μια ροή

εργασίας είναι ένα μοτίβο δραστηριοτήτων που περιγράφει μια συστηματική οργάνωση των πόρων, των καθορισμένων ρόλων, των ενεργειών και των ροών πληροφοριών που περιλαμβάνονται για την ολοκλήρωση μιας εργασίας. Περιγράφει την διαδικασία μιας εργασίας, με τρόπο που μπορεί να τεκμηριωθεί και να μαθευτεί. Οι ροές εργασίας σχεδιάστηκαν για να πετύχουν την επεξεργασία προθέσεων κάποιου είδους, όπως τη φυσική μεταμόρφωση, τη παροχή υπηρεσιών ή την επεξεργασία των πληροφοριών. (Wikipedia, Workflow (2015)) Στο περιβάλλον της ανάπτυξης κώδικα στην πλατφόρμα του GitHub αυτό σημαίνει πως οι ομάδες προγραμματιστών και κάθε καινούριο μέλος της κοινότητας το οποίο αποφασίζει να συμμετέχει και να συνεισφέρει κώδικα θα πρέπει από πριν να γνωρίζει και να ακολουθεί τον κύκλο αυτό εργασιών όπως έχει οριστεί από τους δημιουργούς, ιδιοκτήτες ή διαχειριστές του έργου. Οι προγραμματιστές που εργάζονται με το GitHub ουσιαστικά εργάζονται χρησιμοποιώντας όλες τις διαθέσιμες λειτουργίες και εντολές του εργαλείου ελέγχου εκδόσεων κώδικα git. Η εργασία με ένα τόσο ευέλικτο εργαλείο δημιουργεί και το ζήτημα της επιλογής και του κατάλληλου κύκλου εργασιών με τον οποίο θα εργάζονται όλοι οι προγραμματιστές επάνω στο έργο και θα διασφαλίζεται η σωστή και χωρίς λάθη εξέλιξη και ενημέρωση του πηγαίου κώδικα. H ποικιλία των πιθανών κύκλων εργασιών μπορεί να δημιουργήσει δυσκολία στο σχηματισμό της ροής εργασιών όταν πρόκειται για έργο στην πλατφόρμα GitHub. Παρακάτω παρουσιάζονται μερικά από τα πιο διαδεδομένα μοντέλα workflows στις ομάδες ανάπτυξης λογισμικού. ΤΟ ΣΥΓΚΕΝΤΡΩΤΙΚΟ ΜΟΝΤΕΛΟ Η μετάβαση σε ένα περιβάλλον κατανεμημένου ελέγχου εκδόσεων (DVCS) μπορεί να φαίνεται σαν μεγάλο εγχείρημα, άλλα στην πραγματικότητα δε χρειάζεται να αλλάξει κάτι στην υπάρχουσα ροή εργασιών για να χρησιμοποιήσει το GitHub. Παρόλαυτα η μετάβαση στην πλατφόρμα GitHub και η χρήση των εντολών git προσφέρουν κάποια πλεονεκτήματα έναντι του παραδοσιακού συστήματος ελέγχου εκδόσεων (SVN). Πρώτον, δίνει σε κάθε προγραμματιστή το δικό του τοπικό αντίγραφο ολόκληρου του πηγαίου κώδικα. Δημιουργείται με αυτόν τον τρόπο ένα απομονωμένο περιβάλλον το οποίοι επιτρέπει σε κάθε προγραμματιστή να εργάζεται ανεξάρτητα από οποιαδήποτε αλλαγή μπορεί να συμβαίνει την ίδια στιγμή στο ίδιο έργο από κάποιον άλλο προγραμματιστή. Μπορούν έτσι να κάνουν όσες προσθήκες κώδικα επιθυμούν στο δικό τους αντίγραφο χωρίς να ανησυχούν για το ποιες άλλες αλλαγές γίνονται στον ίδιο πηγαίο κώδικα και τι επίπτωση θα έχουν στον τελικό πηγαίο κώδικα.

Δεύτερον οι προγραμματιστές αποκτούν πρόσβαση στις λειτουργίες της δημιουργίας κλάδων (branching) και ενοποίησης αυτών (merging). Σε αντίθεση με το παραδοσιακό SVN, οι κλάδοι στο git είναι πολύ καλύτερα σχεδιασμένοι και με περισσότερες δικλείδες ασφαλείας για να μπορούν οι όποιες αλλαγές να ενσωματώνονται ασφαλώς στον πηγαίο κώδικα και να μοιράζονται οι αλλαγές μεταξύ αποθετηρίων. Atlassian Git Tutorial (2015) ΠΩΣ ΔΟΥΛΕΥΕΙ Το Συγκεντρωτικό μοντέλο δουλεύει με τον εξής τρόπο. Χρησιμοποιεί ένα κεντρικό αποθετήριο το οποίο έχει το ρόλο του μοναδικού σημείου εισαγωγής αλλαγών στο έργο. Ο κεντρικός κλάδος ανάπτυξης κώδικα ονομάζεται master και όλες οι αλλαγές υποβάλλονται σε αυτόν. Το μοντέλο αυτό δεν απαιτεί τη δημιουργία άλλων κλάδων. Η ροή ξεκινάει όταν οι προγραμματιστές δημιουργούν ένα αντίγραφο του πηγαίου κώδικα. Στο αντίγραφο αυτό κάνουν τις αλλαγές στα αρχεία του κώδικα και υποβάλλουν τις αλλαγές με ένα commit. Με τη διαφορά ότι οι αλλαγές αυτές αποθηκεύονται τοπικά και είναι απομονωμένες ολοκληρωτικά από το κεντρικό αποθετήριο. Αυτό δίνει τη δυνατότητα στους προγραμματιστές να αναβάλλουν τον συγχρονισμό με το κεντρικό αποθετήριο μέχρι να φτάσουν σε ένα βολικό για αυτούς σημείο. Για να δημοσιοποιήσουν τις αλλαγές τους στο πρωτότυπο έργο, οι προγραμματιστές εκτελούν μια εντολή push από το τοπικό τους αντίγραφο στο κεντρικό αποθετήριο. Η διαδικασία αυτή προσθέτει όλες τις αλλαγές που δεν έχουν περαστεί από το τοπικό αντίγραφό στο κεντρικό αποθετήριο. (Atlassian Git Tutorial (2015)) ΔΙΑΧΕΙΡΙΣΗ ΣΥΓΚΡΟΥΣΕΩΝ Το κεντρικό αποθετήριο αντιπροσωπεύει το επίσημο έργο, επομένως το ιστορικό υποβολών (commits) θεωρείται ιερό και αμετάβλητο. Εάν οι αλλαγές ενός προγραμματιστή δε συμφωνούν απόλυτα με το κεντρικό αποθετήριο το GitHub θα αρνηθεί να ενσωματώσει τις αλλαγές γιατί αυτό θα άλλαζε προηγούμενες επίσημες υποβολές κώδικα. Πριν μπορέσει ο προγραμματιστής να υποβάλλει κώδικα, θα πρέπει να πάρει πρώτα όλες τις αλλαγές οι οποίες έχουν καταχωρηθεί στο κεντρικό αποθετήριο μέχρι εκείνη τη στιγμή και να βασίσει τις δικές του αλλαγές και προσθήκες πάνω σε αυτές. Το αποτέλεσμα είναι ένα απολύτως γραμμικό ιστορικό αλλαγών στο κεντρικό αποθετήριο. Εάν οι τοπικές αλλαγές έρχονται σε αντίθεση με το κεντρικό αποθετήριο, η διαδικασία παγώνει για να μπορεί ο προγραμματιστής να λύσει τα προβλήματα συγκρούσεων και να συνεχίσει αργότερα χωρίς προβλήματα. (Atlassian Git Tutorial (2015))

ΠΑΡΑΔΕΙΓΜΑ Στο παρακάτω παράδειγμα θα δούμε πως 2 προγραμματιστές ο John και η Mary μπορούν να δουλέψουν σε ξεχωριστά κομμάτια κώδικα και να μοιραστούν τις αλλαγές του μέσω ενός κεντρικού αποθετηρίου. Όλοι προγραμματιστές δημιουργούν τοπικά αντίγραφα του κεντρικού αποθετηρίου. O John εργάζεται πάνω στις δικές του αλλαγές στον πηγαίο κώδικα. Εφόσον δουλεύει στο τοπικό του αντίγραφο, ο John μπορεί να δημιουργήσει όσες αλλαγές στον κώδικα θέλει και να τις υποβάλλει όποια χρονική στιγμή αυτός θέλει. Αυτό είναι χρήσιμο διότι δε χρειάζεται να ανησυχεί για τις αλλαγές στο κεντρικό αποθετήριο, ειδικά όταν πρόκειται για αλλαγές σε μεγάλα κομμάτια κώδικα τα οποία θα πρέπει να σπάσουν σε μικρότερα κομμάτια. Εντωμεταξύ η Mary δουλεύει πάνω στις δικές τις αλλαγές στο δικό τις τοπικό αντίγραφο του πηγαίου κώδικα. Όπως και ο John, δε χρειάζεται να ανησυχεί για το τι συμβαίνει στο κεντρικό αποθετήριο, ούτε και στο αποθετήριο του John γιατί δουλεύουν εντελώς ξεχωριστά και απομονωμένα. Ο John δημοσιεύει τη δουλειά του. Οι αλλαγές του ανεβαίνουν στο κεντρικό αποθετήριο, το οποίο εφόσον παραμένει αμετάβλητο από την τελευταία φορά που δημιουργήθηκε τοπικό αντίγραφό, θα δεχτεί τις αλλαγές χωρίς κανένα πρόβλημα.

Μετά την υποβολή από τον John, προσπαθεί η Mary με τη σειρά της να υποβάλλει τις δικές της αλλαγές στο κεντρικό αποθετήριο. Εφόσον όμως το δικό της αντίγραφό είναι πλέον διαφορετικό (μετά τις αλλαγές του John) η Mary δεν μπορεί να ολοκληρώσει την υποβολή. Θα πρέπει να πάρει ένα καινούριο αντίγραφό του κεντρικού αποθετηρίου και πάνω εκεί να ενσωματώσει τις αλλαγές τις. Η Mary αναπροσαρμόζει το τοπικό της αντίγραφό με τις αλλαγές του John. Ουσιαστικά ξαναπαίρνει ένα αντίγραφο για να το προσθέσει το τοπικό της μαζί με όλες τις αλλαγές που ανέβηκαν τελευταία από τον John. Η Mary λύνει ένα πρόβλημα σύγκρουσης που παρουσιάστηκε στον δικό της κώδικα με τις αλλαγές του John. Εάν η Mary και ο John δούλευαν σε διαφορετικά σημεία κώδικα δε θα προέκυπταν συγκρούσεις και η Mary θα μπορούσε να συνεχίσει κανονικά στο επόμενο βήμα.

Η Mary δημοσιεύει επιτυχώς τις δικές της αλλαγές στο κεντρικό αποθετήριο. Πίνακας 1. Παράδειγμα Συγκεντρωτικού Μοντέλου ΜΟΝΤΕΛΟ ΚΛΑΔΩΝ ΛΕΙΤΟΥΡΓΙΩΝ Μια εξέλιξη από το Συγκεντρωτικό μοντέλο είναι το μοντέλο το οποίο βασίζεται στη δημιουργία κλάδων ανάπτυξης λειτουργίας (Feature Branches) και αποτελεί έναν εύκολο τρόπο για να ενθαρρύνεται η συνεργασία και να βελτιωθεί η επικοινωνία μεταξύ των προγραμματιστών. Η κεντρική ιδέα πίσω από τον κλάδο λειτουργίας είναι ότι όλη η ανάπτυξη λογισμικού γύρω από μια συγκεκριμένη λειτουργία θα πρέπει να συμβαίνει σε έναν κλάδο του αρχικού πηγαίου κώδικα και όχι πάνω στον αρχικό κώδικα τον ίδιο. Η ενθυλάκωση αυτή σημαίνει ότι είναι εύκολο για πολλούς προγραμματιστές να δουλέψουν πάνω σε μια λειτουργία χωρίς να επεμβαίνουν στον αρχικό κώδικα. Επίσης σημαίνει ότι ο πρωτότυπος πηγαίος κώδικας δε θα περιέχει ποτέ κώδικα που δεν λειτουργούν, ένα τεράστιο πλεονέκτημα για περιβάλλοντα συνεχούς ενσωμάτωσης κώδικα. Ενθυλακώνοντας την ανάπτυξη των λειτουργιών κάνει επίσης δυνατή τη χρήση των pull requests, τα οποία είναι ένας τρόπος για να ξεκινήσει η συζήτηση σχετικά με έναν κλάδο του έργου. Δίνεται η ευκαιρία στους προγραμματιστές να δώσουν την έγκριση τους πάνω σε ένα καινούριο κομμάτι κώδικα ή μια λειτουργία πριν αυτή ενσωματωθεί στον επίσημο πηγαίο κώδικα του έργου. Επίσης δίνει τη δυνατότητα να ζητηθεί βοήθεια από άλλους προγραμματιστές εάν κατά τη διάρκεια της ανάπτυξης κώδικα συναντηθούν δυσκολίες. (Atlassian Git Tutorial (2015)) ΠΩΣ ΔΟΥΛΕΥΕΙ Το μοντέλο χρησιμοποιεί και αυτό ένα κεντρικό αποθετήριο. Αντί όμως να γίνεται υποβολές αλλαγών απευθείας σε αυτό, δημιουργούνται νέοι κλάδοι (branches) κάθε φορά που οι προγραμματιστές θέλουν να δουλέψουν πάνω σε κάτι καινούριο. Τα ονόματα των κλάδων θα πρέπει να έχουν περιγραφικά ονόματα για να μπορεί κάθε κάδος να έχει ξεκάθαρο σκοπό και λειτουργία. Οι κλάδοι μπορούν να επεξεργάζονται τους κλάδους κανονικά όπως θα έκαναν και τον κύριο κορμό του πηγαίου κώδικα και να πραγματοποιούν αναπροσαρμογές, αλλαγές και υποβολές κώδικα όσες φορές θέλουν.

Επιπλέον οι κλάδοι μπορούν (και θα έπρεπε) να υποβληθούν στο κεντρικό αποθετήριο. Με τον τρόπο αυτό μπορεί μια καινούρια λειτουργία να μοιραστεί και με την υπόλοιπη κοινότητα προγραμματιστών χωρίς να πειραχτεί επίσημος κώδικας. Επίσης είναι και ένας πολύ χρήσιμος τρόπος για να κρατιέται αρχείο της δουλειάς του κάθε προγραμματιστή. (Atlassian Git Tutorial (2015)) PULL REQUESTS Εκτός από την απομονωμένη ανάπτυξη λογισμικού, οι κλάδοι δίνουν τη δυνατότητα για τη συζήτηση των αλλαγών μέσω των pull requests. Μόλις ένας προγραμματιστής ολοκληρώνει μια λειτουργία δεν την ενσωματώνει κατευθείαν στο κεντρικό αποθετήριο. Αντί αυτού προωθεί τον κλάδο στο κεντρικό αποθετήριο και υποβάλλει ένα αίτημα pull request. Αυτή η ενέργεια δίνει την ευκαιρία σε άλλους προγραμματιστές να αξιολογήσουν τις αλλαγές πριν αυτές γίνουν μέρος του επίσημου πηγαίου κώδικα. Η επισκόπηση κώδικα είναι ένα μεγάλο πλεονέκτημα των pull requests. Κάθε pull request είναι ουσιαστικά μια συζήτηση πάνω σε ένα συγκεκριμένο κλάδο. Αυτό σημαίνει ότι μπορούν να χρησιμοποιηθούν και πολύ νωρίτερα στη διαδικασία ανάπτυξης λογισμικού. Όταν ένα προγραμματιστής συναντήσει δυσκολίες μπορεί για να παράδειγμα να ανοίξει ένα pull request. Αυτό θα ειδοποιήσει όλους τους ενδιαφερόμενους, οι οποίοι θα μπορούν να δουν την ερώτηση δίπλα στα σχετικά commits. Όταν ένα pull request γίνεται δεκτό η διαδικασία είναι παρόμοια με το συγκεντρωτικό μοντέλο. Πρώτα ο προγραμματιστής αναπροσαρμόζει το τοπικό του αντίγραφο με τον επίσημο πηγαίο κώδικα. Κατόπιν ενσωματώνει τον κλάδο του με το κεντρικό κορμό του κώδικα και ο ανανεωμένος κορμός του κώδικα ανεβαίνει εκ νέου στο κεντρικό αποθετήριο. (Atlassian Git Tutorial (2015)) ΠΑΡΑΔΕΙΓΜΑ H Mary ξεκινάει μια καινούρια λειτουργία. Προτού ξεκινήσει θα χρειαστεί έναν καινούριο, απομονωμένο κλάδο για να δουλέψει. Στον κλάδο αυτό η Mary ξεκινάει να δουλεύει τη λειτουργία με όσα commits επιθυμεί.

Η Mary πηγαίνει για μεσημεριανό. Έχει προσθέσει μερικά commits καθόλη τη διάρκεια του πρωινού. Μπορεί επίσης να ανεβάσει το branch στο κεντρικό αποθετήριο. Αυτό είναι ένα βολικό backup και εάν η Mary συνεργαζόταν με άλλους, θα είχαν την ευκαιρία να δουν τα αρχικά της commits. H Mary τελειώνει τη λειτουργία της. Πριν μπορέσει να την ενσωματώσει στον κεντρικό κορμό του έργου θα πρέπει να υποβάλλει ένα pull request για να ειδοποιήσει και την υπόλοιπη ομάδα ότι έχει τελειώσει. Ο Bill λαμβάνει το pull request της Mary. Αποφασίζει ότι θέλει να κάνει μερικές αλλαγές πριν το ενσωματώσει στον κεντρικό κορμό και αυτός και η Mary έχουν μια μικρή συζήτηση μέσω του pull request. Η Mary κάνει τις αλλαγές που ζήτησε ο Bill. Για να κάνει τις αλλαγές χρησιμοποιεί τα ίδια βήματα που ακολούθησε στο πρώτα βήμα της διαδικασίας. Κάνει αλλαγές, δημιουργεί commits και τα προωθεί στο server του έργου. Όλες οι αλλαγές είναι ορατές και από τον Bill μέσα από το pull request από όπου μπορεί να κάνει σχόλια και διορθώσεις. Αν ήθελε, θα μπορούσε και ο Bill να πάρει τον κλάδο της Mary στο δικό του τοπικό αποθετήριο και να κάνει τις δικές του αλλαγές οι οποίες θα εμφανίζονταν στο pull request. Μόλις ο Bill είναι έτοιμος να αποδεχτεί το pull request της Mary κάποιος θα πρέπει να ενσωματώσει τον κλάδο της Mary στον κεντρικό κορμό του project. Αυτό μπορεί να

γίνει είτε από τον Bill είτε από τη Mary. Πίνακας 2. Μοντέλο Κλάδων Λειτουργιών Εντωμεταξύ όσο ο Bill και η Mary δουλεύουν στο branch της Mary και το συζητούν στο pull request της Mary, o John κάνει την ίδια δουλειά στο δικό του branch. Με την απομόνωση λειτουργιών σε ξεχωριστούς κλάδους, όλοι μπορούν να δουλέψουν ανεξάρτητα. (Atlassian Git Tutorial (2015)) MONTELO GITFLOW Εικόνα 0-3. Μοντέλο Gitflow Το μοντέλο Gitflow χρησιμοποιεί και αυτό ένα κεντρικό αποθετήριο σαν τον κόμβο επικοινωνίας για όλους τους προγραμματιστές. Όπως και στο συγκεντρωτικό και το μοντέλο κλάδων, οι προγραμματιστές εργάζονται τοπικά και προωθούν τις αλλαγές του στο κεντρικό αποθετήριο. Αντί για ένα μοναδικό κλάδο, αυτό το μοντέλο χρησιμοποιεί 2 κλάδους για να κρατάει το ιστορικό του έργου. Η υπόλοιπη ροή εργασιών έχει να κάνει με τη διαφοροποίηση μεταξύ των 2 αυτών κύριων κλάδων. (Atlassian Git Tutorial (2015))

ΚΛΑΔΟΙ ΛΕΙΤΟΥΡΓΙΩΝ Εικόνα 0-4.Κλάδοι λειτουργιών Κάθε καινούρια λειτουργία θα πρέπει να έχει το δικό της κλάδο, ο οποίος μπορεί να ανέβει στο κεντρικό αποθετήριο για αποθήκευση και συζήτηση με άλλου προγραμματιστές. Με τη διαφορά ότι οι κλάδοι δεν προέρχονται από τον κεντρικό κορμό του έργου άλλα από τα από τον κλάδο Ανάπτυξης (στο σχήμα Develop). Όταν μια λειτουργία ολοκληρωθεί ενσωματώνεται στον κλάδο Ανάπτυξης. Με τον τρόπο αυτό οι λειτουργίες δεν διαδρούν ποτέ με τον κεντρικό κορμό. (Atlassian Git Tutorial (2015))

ΚΛΑΔΟΙ ΕΚΔΟΣΗΣ Εικόνα 0-5. Κλάδοι Εκδόσεων Όταν ο κλάδος ανάπτυξης έχει αποκτήσει αρκετές λειτουργίες έτοιμες για παράδοση (ή μια συγκεκριμένη ημερομηνία παράδοσης πλησιάζει), δημιουργείται ένας νέος κλάδος παράδοσης. Η δημιουργία αυτού του κλάδου σηματοδοτεί την έναρξη ενός νέου κύκλου παράδοσης. Αυτό σημαίνει ότι στον κλάδο παράδοσης που δημιουργήθηκε δεν προστίθενται άλλες νέες λειτουργίες, παρά μόνο εργασίες αποσφαλμάτωσης, δημιουργίας εγγράφων τεκμηρίωσης και άλλων εργασιών σχετικών με την παράδοση. Μόλις είναι έτοιμη για παράδοση, η καινούρια έκδοση ενσωματώνεται στον κεντρικό κορμό του έργου με έναν αριθμό έκδοσης και στον κλάδο ανάπτυξης ο οποίος θα μπορούσε να συνεχίζει να εμπλουτίζεται με νέες λειτουργίες για την επόμενη έκδοση. Η χρήση αποκλειστικού κλάδου εργασιών για την προετοιμασία παραδόσεων καθιστά δυνατή τη χρήση ομάδων προγραμματιστών οι οποίες θα είναι επιφορτισμένες άλλες με την προετοιμασία της καινούριας έκδοσης του έργου προς παράδοση και άλλες με την ανάπτυξη λειτουργών για την επόμενη έκδοση του έργου.(atlassian Git Tutorial (2015)) ΚΛΑΔΟΙ ΣΥΝΤΗΡΗΣΗΣ Οι κλάδοι συντήρησης χρησιμοποιούνται για γρήγορες διορθώσεις στις τελικές εκδόσεις του προϊόντος. Αυτός είναι ο μοναδικός κλάδος ο οποίος θα πρέπει να διακλαδώνεται απευθείας από τον κεντρικό κορμό του έργου. Μόλις κάποια

επιδιόρθωση ολοκληρωθεί, η αλλαγή θα πρέπει να ενσωματώνεται και στον κεντρικό κορμό άλλα και στον κλάδο ανάπτυξης. Η ύπαρξη αποκλειστικής γραμμής ανάπτυξης για τη διόρθωση σφαλμάτων επιτρέπει στην ομάδα να αντιμετωπίζει προβλήματα που προκύπτουν χωρίς να διακόπτει την υπόλοιπη ροή εργασιών ή να περιμένει την επόμενη έκδοση για να ενσωματώσει τις διορθώσεις. (Atlassian Git Tutorial (2015)) ΠΑΡΑΔΕΙΓΜΑ Το παρακάτω παράδειγμα δείχνει πως αυτή η ροή εργασιών μπορεί να χρησιμοποιηθεί για να διαχειριστεί ένα κύκλο παράδοσης ενός έργου κώδικα. Δημιουργείται ένα νέο αποθετήριο στο οποίο δημιουργούνται ένα κύριος κλάδος και ένας κλάδος Ανάπτυξης. Η Mary και o John ξεκινούν καινούριες εργασίες. Και οι δύο θα πρέπει να δημιουργήσουν ξεχωριστούς κλάδους για τις λειτουργίες που δουλεύουν βασισμένους στον κλάδο Ανάπτυξης. H Mary τελειώνει τη λειτουργία της. Μετά από μερικά commits η Mary αποφασίζει ότι η λειτουργία της είναι έτοιμη. Εάν η ομάδα χρησιμοποιεί pull requests τώρα θα πρέπει να υποβάλλει ένα για ενσωμάτωση της λειτουργίας της στον κλάδο Ανάπτυξης. Όσο ο John δουλεύει ακόμα στη δική του λειτουργία, η Mary ετοιμάζεται για την πρώτη επίσημη έκδοση του έργου. Χρησιμοποιεί έναν καινούριο κλάδο Παράδοσης για να ενθυλακώσει τις προετοιμασίες για παράδοση. Εδώ γίνονται εργασίες δοκιμών, καθαρισμού του κώδικα, ανανέωσης της τεκμηρίωσης κ.α. Μόλις προστεθεί ο κλάδος Παράδοσης στο αποθετήριο κάθε λειτουργία που δεν είναι ήδη στον κλάδο Ανάπτυξης παγώνει μέχρι τον επόμενο κύκλο παράδοσης.

Η Mary ολοκληρώνει την παράδοση. Μόλις η καινούρια έκδοση είναι έτοιμη, η Mary την ενσωματώνει στον κεντρικό κορμό και στον κλάδο Ανάπτυξης και μετά σβήνει τον κλάδο Παράδοσης. Η ενσωμάτωση στον κλάδο Ανάπτυξης είναι πολύ σημαντική έτσι ώστε οποιεσδήποτε αλλαγές γίναν στη διαδικασία της προετοιμασίας για παράδοση να είναι διαθέσιμες και στον κλάδο Ανάπτυξης. Ο τελικός χρήστης ανακαλύπτει ένα σφάλμα. Μπορεί να το κάνει αυτό με την υποβολή ενός παραπόνου για κάποιο σφάλμα στην πιο πρόσφατη έκδοση. Για να αντιμετωπιστεί το σφάλμα, ένας κλάδος Συντήρησης δημιουργείται από τον κεντρικό κορμό και ενσωματώνεται ξανά και στον κεντρικό κορμό άλλα και στον κλάδο Ανάπτυξης. Πίνακας 3 Παράδειγμα Μοντέλο Gitflow ΜΟΝΤΕΛΟ FORKING Το μοντέλο forking είναι διαφορετικό σε σχέση με τα υπόλοιπα μοντέλα που παρουσιάστηκαν παραπάνω. Αντί να χρησιμοποιεί ένα και μοναδικό αποθετήριο το οποίο χρησιμεύει σαν κεντρικό σημείο από το οποίο ξεκινάν και στο οποίο καταλήγουν όλες οι αλλαγές στον πηγαίο κώδικα, το μοντέλο αυτό δίνει σε κάθε προγραμματιστή το δικό του κεντρικό αποθετήριο στο server. Αυτό σημαίνει ότι κάθε ένας προγραμματιστής ο οποίος συνεισφέρει κώδικα δεν έχει ένα άλλα δυο αποθετήρια. Ένα ιδιωτικό τοπικό αποθετήριο και ένα δημόσιο αποθετήριο επάνω στο server.

Εικόνα 0-6. Μοντέλο Forking Το κύριο πλεονέκτημα αυτού του μοντέλου είναι ότι οι συνεισφορές στον κώδικα μπορούν να ενσωματώνονται χωρίς να χρειάζεται κάθε ένας προγραμματιστής να προωθεί τις αλλαγές του στο κεντρικό αποθετήριο του έργου. Αντί αυτού προωθούν τις αλλαγές τους στο δικό τους αποθετήριο στο server και μόνο ο επικεφαλής του έργου μπορεί να ενσωματώσει τις αλλαγές στο κεντρικό αποθετήριο. Αυτό επιτρέπει στον εκάστοτε επικεφαλής του έργου να δέχεται τις αλλαγές τις οποίες υποβάλλουν οι προγραμματιστές χωρίς να χρειάζεται να τους δίνει πρόσβαση στο κεντρικό αποθετήριο του έργου. Το αποτέλεσμα αυτού του μοντέλου είναι μια κατανεμημένη ροή εργασιών, η οποία προσφέρει έναν ευέλικτο τρόπο σε μεγάλες ομάδες (συμπεριλαμβανομένων και μη έμπιστων τρίτων) για να μπορούν να συνεργάζονται με ασφαλή τρόπο. Το χαρακτηριστικό αυτό επίσης το καθιστά μοντέλο κατάλληλο για έργα ανοιχτού πηγαίου κώδικα. (Atlassian Git Tutorial (2015)) ΠΩΣ ΔΟΥΛΕΥΕΙ Όπως και με τα άλλα μοντέλα ροής εργασιών, το Forking μοντέλο ξεκινάει με τη δημιουργία ενός κεντρικού αποθετηρίου στο server το οποίο θα είναι και το επίσημο αποθετήριο του έργου. Στη συνέχεια όμως, κάθε προγραμματιστή ο οποίος επιθυμεί να εργαστεί πάνω στο έργο και να συνεισφέρει, δεν δημιουργεί τοπικό αντίγραφο από το επίσημο αποθετήριο. Αντί αυτού, δημιουργούν μια διακλάδωση (fork) του επίσημου αποθετηρίου και εκεί δημιουργούν το online αντίγραφό τους. Το νέο αυτό αντίγραφο χρησιμεύει σαν το δικό τους προσωπικό και δημόσιο, online αποθετήριο. Κανένας άλλος προγραμματιστής δεν μπορεί να προωθήσει αλλαγές σε αυτό άλλα όλοι μπορούν να τραβήξουν αλλαγές από αυτό. Μετά τη δημιουργία του fork ακολουθεί και η δημιουργία του τοπικού αντιγράφου αυτού. Αυτό το αντίγραφο

θα εξυπηρετεί ως το προσωπικό περιβάλλον ανάπτυξης κώδικα όπως είδαμε και στα παραπάνω μοντέλα. Όταν έρθει η ώρα για τη δημοσιοποίηση μιας καινούριας αλλαγής, η αλλαγή αυτή προωθείται από το τοπικό αντίγραφο στο online προσωπικό αποθετήριο και όχι το επίσημο. Ακολουθεί η καταχώρηση ενός pull request στο επίσημο κεντρικό αποθετήριο, γεγονός το οποίο γνωστοποιεί στον υπεύθυνο διαχείρισης του έργου ότι υπάρχει μια αλλαγή έτοιμη για ενσωμάτωση με τον κεντρικό πηγαίο κώδικα. Το pull request επίσης αποτελεί μια ευκαιρία για γόνιμη συζήτηση μεταξύ των ενδιαφερομένων προγραμματιστών πάνω στον κώδικα προς υποβολή. Για να ενσωματωθεί το καινούριο κομμάτι κώδικα στον επίσημο αποθετήριο, ο διαχειριστής τραβάει τις αλλαγές από το προσωπικό online αποθετήριο του προγραμματιστή στο δικό του τοπικό αντίγραφο. Αφού ελέγξει ότι η ενσωμάτωση δε θα προξενήσει προβλήματα στην εκτέλεση του επίσημου κώδικα εκτελεί την εντολή ενσωμάτωσης στο επίσημο αποθετήριο επάνω στο server. Η αλλαγή γίνεται πλέον μέρος του επίσημου κώδικα και όλοι οι εμπλεκόμενοι προγραμματιστές θα πρέπει να ενημερώσουν τα δικά του αντίγραφα (online και τοπικά) με τον καινούριο επίσημο πηγαίο κώδικα. (Atlassian Git Tutorial (2015)) ΤΟ ΕΠΙΣΗΜΟ ΑΠΟΘΕΤΗΡΙΟ Εϊναι σημαντικό να κατανοήσουμε ότι η ύπαρξη ενός επίσημου αποθετηρίου είναι απλά μια σύμβαση μεταξύ των συμβαλλομένων μερών και ότι από τεχνικής πλευράς δεν έχει καμία διαφορά από τα υπόλοιπα αποθετήρια. Η μόνη διαφορά του επίσημου αποθετηρίου με τα υπόλοιπα είναι ότι αυτό ανήκει στον ιδιοκτήτη/διαχειριστή του έργου. ΔΙΑΚΛΑΔΩΣΕΙΣ ΣΤΟ ΜΟΝΤΕΛΟ FORKING Όλα αυτά τα προσωπικά, δημόσια αποθετήρια του μοντέλου, είναι στην πραγματικότητα ένας βολικός τρόπος για να μοιράζονται οι προγραμματιστές κλάδους του κώδικα (branches) μεταξύ τους. Όλοι οι εμπλεκόμενοι θα πρέπει να χρησιμοποιούν κλάδους για να διαχωρίζουν τις μεμονωμένες λειτουργίες όπως στο μοντέλο Κλάδων Λειτουργιών και το μοντέλο Gitflow.

ΠΑΡΑΔΕΙΓΜΑ Ο διαχειριστής του έργου δημιουργεί το επίσημο αποθετήριο. Το αποθετήριο αυτό θα πρέπει να είναι εντελώς κενό. Οι προγραμματιστές δημιουργούν τα δικά τους δημόσια αποθετήρια. Ουσιαστικά δημιουργούν αντίγραφα του επίσημου αποθετηρίου στο server. Τα αποθετήρια αυτά θα πρέπει να είναι εντελώς κενά. Οι προγραμματιστές δημιουργούν τα τοπικά τους αντίγραφα αντίστοιχα. Οι προγραμματιστές εργάζονται πάνω στον κώδικα στα τοπικά τους αποθετήρια. Μπορούν να κάνουν όσα commits και branches θέλουν όπως και στα άλλα μοντέλα. Όλες οι αλλαγές τους δεν θα είναι ορατές από άλλους μέχρι να τις προωθήσουν στα αντίστοιχα προσωπικά τους αποθετήρια στο server. Οι προγραμματιστές δημοσιοποιούν τον κώδικά τους. Μόλις είναι έτοιμοι για τη δημοσιοποίηση θα πρέπει να κάνουν τις εξής ενέργειες: 1) Να προωθήσουν τον κώδικα στα αποθετήριά τους στο server όπου μπορούν να τα δουν όλοι οι εμπλεκόμενοι. 2) Να υποβάλουν ένα pull request για να ειδοποιήσουν τον διαχειριστή ότι επιθυμούν να ενσωματώσουν τον κώδικάς τους στο επίσημο αποθετήριο. Ο διαχειριστής ενσωματώνει τον κώδικα στον επίσημο αποθετήριο. Αφού λάβει το pull request του προγραμματιστή, θα πρέπει να αποφασίσει αν θα ενσωματώσει τον κώδικα. Αυτό μπορεί να γίνει με 2 τρόπους: 1)Με απευθείας έλεγχο του κώδικα από το pull request. 2) Με έλεγχο του κώδικα μέσω του τοπικού

αντιγράφου. Αυτό γίνεται κυρίως όταν υπάρχει κίνδυνος να προκύψει πρόβλημα στην ενσωμάτωση του καινούριου κώδικα. Τότε ο διαχειριστής θα πρέπει να τον ενσωματώσει μέσω του δικού τοπικού αντιγράφου ώστε να μπορεί να διαπιστώσει τα λάθη αυτά και να τα διορθώσει. Οι προγραμματιστές συγχρονίζουν τα αποθετήρια τους με το επίσημο. Έτσι έχουν πάντα τον ενημερωμένο κώδικα με όλες τις αλλαγές που έχουν ενσωματωθεί από το διαχειριστή. Πίνακας 4 Παράδειγμα Μοντέλου Forking Το μοντέλο forking δημιουργεί ένα ακόμα επίπεδο αφαίρεσης πάνω από το μοντέλο κλάδων λειτουργιών. Αντί να μοιράζονται οι κλάδοι απευθείας μέσω ενός κεντρικού αποθετηρίου, οι συνεισφορές δημοσιεύονται σε ένα δημόσιο αποθετήριο στο server το οποίο ανήκει αποκλειστικά στον εκάστοτε προγραμματιστή. Το χαρακτηριστικό αυτό κάνει μοντέλο forking ένα πολύ δυνατό εργαλείο για ομάδες που δεν έχουν δυνατή συνοχή. Οποιοσδήποτε προγραμματιστής μπορεί να μοιραστεί κώδικα με οποιοδήποτε άλλον προγραμματιστή και κάθε κλάδος μπορεί να ενσωματωθεί στο επίσημο αποθετήριο του έργου. (Atlassian Git Tutorial (2015)) Στην προηγούμενη εξετάσαμε τι είναι η ροή εργασιών, πώς αυτή επηρεάζει τον τρόπο δουλειάς μιας ομάδας ανάπτυξης λογισμικού η οποία λειτουργεί στο GitHub και ποιες είναι οι βασικές ροές εργασιών πάνω στις οποίες μπορεί να εργαστεί μια ομάδα χρησιμοποιώντας μια πλατφόρμα σαν το GitHub και εργαλεία σαν το git. Σε αυτή την ενότητα θα περιγράψουμε τη μέθοδο και τα ευρήματα της εμπειρικής μελέτης από έργα ανοιχτού πηγαίου κώδικα τα οποία φιλοξενούνται στο GitHub.