Απρουβάρω / Κάνω approve: τι είναι, approval και code review στο Git

Τι είναι το απρούβ pull request

Απρούβ (approval) είναι μια θετική αξιολόγηση ενός pull request, που σημαίνει ότι ο reviewer έλεγξε τον κώδικα, δεν βρήκε κρίσιμα προβλήματα και θεωρεί τις αλλαγές έτοιμες για συγχώνευση. Στο περιβάλλον του GitHub αυτό είναι το πράσινο κουμπί "Approve" στη σελίδα του PR. Μετά το απρούβ, ο συγγραφέας (ή οποιοδήποτε μέλος με δικαιώματα εγγραφής) μπορεί να εκτελέσει το merge.

Η διαδικασία του απρούβ αποτελεί μέρος των Branch Protection Rules. Οι ιδιοκτήτες του repository ορίζουν υποχρεωτικές απαιτήσεις: ελάχιστο πλήθος απρούβ (π.χ. 1 ή 2), ποιος μπορεί να κάνει απρούβ (ιδιοκτήτες κώδικα, μέλη της ομάδας) και αν το PR πρέπει να επαναλαμβάνει το απρούβ μετά από αλλαγές (Dismiss stale reviews). Χωρίς ρύθμιση κανόνων, το απρούβ είναι προαιρετικό βήμα, αλλά στις επαγγελματικές ομάδες είναι υποχρεωτικό.

Το GitLab χρησιμοποιεί έναν παρόμοιο μηχανισμό με την ονομασία Approval Rules. Στο GitLab μπορείτε να ρυθμίσετε πόσα απρούβ απαιτούνται από διαφορετικές ομάδες (π.χ. 2 από τους προγραμματιστές backend και 1 από τους DevOps). Μετά τη λήψη όλων των υποχρεωτικών απρούβ, το PR ξεκλειδώνει αυτόματα για merge εφόσον το pipeline CI/CD είναι πράσινο.

Τύποι review: Approve, Request Changes, Comment

Στο GitHub και στο GitLab υπάρχουν τρεις τύποι review που μπορεί να αφήσει ο reviewer σε ένα pull request. Κάθε τύπος έχει διαφορετικό καθεστώς και συνέπειες για τη διαδικασία συγχώνευσης. Το Approve είναι πράσινο, το Request Changes κόκκινο και το Comment ουδέτερο γκρι. Η επιλογή του τύπου εξαρτάται από την ποιότητα του κώδικα και την ετοιμότητα των αλλαγών για αποδοχή.

Approve — ο reviewer επιβεβαιώνει: ο κώδικας είναι γραμμένος σωστά, πληροί τα πρότυπα, δεν περιέχει προφανή σφάλματα και μπορεί να συγχωνευτεί. Το Approve δεν σημαίνει ότι ο κώδικας είναι ιδανικός — μόνο ότι είναι αρκετά καλός για παραγωγή. Αν υπάρχουν μικρές παρατηρήσεις (στυλ, ονοματολογία), μπορούν να αφεθούν ως σχόλια χωρίς αποκλεισμό του PR.

Request Changes — ο reviewer βρίσκει προβλήματα που πρέπει να διορθωθούν πριν το merge: λογικά σφάλματα, ευπάθειες, παραβίαση της αρχιτεκτονικής, έλλειψη tests. Μετά το Request Changes το PR μπλοκάρεται και για να ξεκλειδώσει απαιτείται νέο απρούβ από τον ίδιο reviewer (εάν είναι ενεργή η επιλογή Dismiss stale reviews σε νέα commits).

• Approve — ο κώδικας είναι έτοιμος για συγχώνευση, μπορείτε να κάνετε merge μετά το πέρασμα του CI.
• Request Changes — υποχρεωτικές διορθώσεις, το PR είναι μπλοκαρισμένο μέχρι νέου review.
• Comment — γενική παρατήρηση ή πρόταση χωρίς αποκλεισμό του PR.

Ρύθμιση κανόνων απρούβ στο repository

Οι Branch Protection Rules είναι ο μηχανισμός του GitHub για τον έλεγχο ποιότητας των συγχωνεύσεων. Ρυθμίζονται στα Settings → Branches για κάθε προστατευμένο branch (main, develop, release/*). Βασικές παράμετροι: πλήθος υποχρεωτικών απρούβ, ιδιοκτήτες κώδικα (CODEOWNERS), υποχρεωτικός έλεγχος CI/CD και απαγόρευση push χωρίς PR.

Η παράμετρος Dismiss stale pull request approvals — αφαιρεί αυτόματα τα απρούβ αν προστεθεί νέο commit στο PR. Αυτό διασφαλίζει ότι οι reviewers εγκρίνουν ακριβώς την έκδοση του κώδικα που θα συγχωνευτεί. Χωρίς αυτή τη ρύθμιση, ο συγγραφέας μπορεί να προσθέσει νέο κώδικα μετά το απρούβ και αυτός να μπει στο main χωρίς νέο έλεγχο.

CODEOWNERS — αρχείο στη ρίζα του repository που ορίζει τους υπεύθυνους για διαφορετικούς φακέλους. Αν το PR αφορά αρχεία που ανήκουν σε ιδιοκτήτη κώδικα, το απρούβ του γίνεται υποχρεωτικό. Το CODEOWNERS επιτρέπει την κατανομή των τομέων ευθύνης: ο προγραμματιστής iOS είναι υπεύθυνος για τα αρχεία Swift, ο DevOps — για τα configs του Docker, οι testers — για τα σενάρια δοκιμών.

# Παράδειγμα αρχείου CODEOWNERS στη ρίζα του repository

# Οι προγραμματιστές iOS κατέχουν τον κώδικα Swift
*.swift @team/ios-developers

# Ο DevOps κατέχει τη διαμόρφωση CI/CD
.github/workflows/* @devops-team

# Οι μηχανικοί QA ελέγχουν τα tests
**/tests/* @qa-engineers

# Προεπιλεγμένοι ιδιοκτήτες για οτιδήποτε άλλο
* @tech-leads

Code review πριν από το απρούβ: τι να ελέγχετε

Code review πριν από το απρούβ είναι μια συστηματική εξέταση του κώδικα, όχι μια βιαστική ματιά στο diff. Ένα ποιοτικό code review περιλαμβάνει έλεγχο της αρχιτεκτονικής, της λογικής, του στυλ, των tests και της ασφάλειας. Χωρίς αυτόν τον έλεγχο, το απρούβ γίνεται μια τυπική διαδικασία και όχι εργαλείο ελέγχου ποιότητας.

Τι ελέγχεται κατά πρώτο λόγο: η λογική των αλλαγών — λύνει ο κώδικας το ζητούμενο, υπάρχουν παρενέργειες, είναι σωστή η διαχείριση των οριακών περιπτώσεων. Tests — καλύπτουν τα νέα tests όλα τα σενάρια, περνούν τα υπάρχοντα tests μετά τις αλλαγές. Ασφάλεια — υπάρχουν SQL injections, XSS, διαρροές ευαίσθητων δεδομένων.

Τι δεν πρέπει να αποτελεί αντικείμενο του review: το στυλ μορφοποίησης (γι' αυτό υπάρχουν linters και formatters), αρχιτεκτονικές αποφάσεις που έχουν ληφθεί εκ των προτέρων (συζητούνται πριν τη συγγραφή του κώδικα). Αν το review ξεπερνά τις 400 γραμμές ή διαρκεί πάνω από μία ώρα — είναι σημάδι ότι η εργασία είναι πολύ μεγάλη και χρειάζεται αποδόμηση. Βέλτιστες πρακτικές review — τμήματα των 200-400 γραμμών εντός 24 ωρών από τη δημιουργία του PR.

• Λογική — ορθότητα της λύσης, διαχείριση σφαλμάτων, οριακές περιπτώσεις.
• Tests — κάλυψη νέων σεναρίων, πέρασμα των υπαρχόντων, απουσία flaky tests.
• Ασφάλεια — απουσία injections, σωστή διαφυγή εξόδου, πρόσβαση στα δεδομένα.
• Επιδόσεις — αποδοτικότητα των αλγορίθμων, περιττά ερωτήματα, διαρροές μνήμης.
• Τεκμηρίωση — έχει ενημερωθεί η τεκμηρίωση, είναι κατανοητά τα σχόλια στα πολύπλοκα σημεία.

Workflow με απρούβ στην ομάδα

Ένα τυπικό workflow με απρούβ σε ομάδα 5-10 προγραμματιστών έχει ως εξής: ο προγραμματιστής δημιουργεί PR, ορίζει reviewers (συνήθως 1-2 άτομα από την ομάδα ή τους ιδιοκτήτες κώδικα), το CI/CD τρέχει αυτόματους ελέγχους. Αφού ληφθούν όλα τα υποχρεωτικά απρούβ και το CI είναι πράσινο, ο συγγραφέας κάνει merge. Ο χρόνος από τη δημιουργία του PR έως το merge είναι κατά μέσο όρο από 2 ώρες έως 2 ημέρες, ανάλογα με την πολυπλοκότητα.

Τα GitHub Actions επιτρέπουν αυτοματοποίηση του merge μετά το απρούβ. Εάν έχουν ρυθμιστεί κανόνες branch, το GitHub μπλοκάρει μόνο του το merge μέχρι να πληρούνται όλες οι προϋποθέσεις. Κάποιες ομάδες χρησιμοποιούν bors-ng ή Mergify — bots που συγχωνεύουν αυτόματα το PR αφού ληφθούν όλα τα απρούβ και περάσει το CI. Αυτό επιταχύνει τη διαδικασία και εξαλείφει τον ανθρώπινο παράγοντα στο merge.

Η σύγχρονη προσέγγιση είναι το trunk-based development με branches σύντομης διάρκειας ζωής. Σε αυτό το workflow το απρούβ πρέπει να ληφθεί μέσα σε λίγες ώρες, διαφορετικά η εργασία θεωρείται ξεπερασμένη και απαιτεί νέο συγχρονισμό με το main. Οι ομάδες με υψηλή κουλτούρα review επιδιώκουν χρόνο απρούβ όχι μεγαλύτερο από 4 εργάσιμες ώρες.

Λάθη στο απρούβ και πώς να τα αποφύγετε

Το πιο συνηθισμένο λάθος είναι το τυπικό απρούβ χωρίς πραγματικό έλεγχο του κώδικα. Όταν το PR είναι μεγάλο ή το deadline είναι κοντά, ο reviewer μπορεί να πατήσει Approve χωρίς να εμβαθύνει στις αλλαγές. Αυτό απαξιώνει όλη τη διαδικασία code review. Λύση: να ορίζετε όριο στο μέγεθος του PR (όχι πάνω από 400 γραμμές) και να χρησιμοποιείτε εργαλεία ανάλυσης κώδικα (SonarQube, CodeClimate) για αυτόματο έλεγχο.

Το δεύτερο λάθος — το υπερβολικά αυστηρό απρούβ. Η προσδοκία ιδανικού κώδικα μπλοκάρει την ανάπτυξη. Οι reviewers μερικές φορές ζητούν να διορθωθούν στιλιστικές παρατηρήσεις που δεν επηρεάζουν την ποιότητα. Λύση: να διαχωρίζετε καθαρά τις υποχρεωτικές παρατηρήσεις (μπλοκαρισμένες) από τις προαιρετικές προτάσεις (σχόλια). Το GitHub επιτρέπει να δηλώσετε ρητά αν ένα σχόλιο είναι μπλοκαριστικό.

Το τρίτο λάθος — απρούβ χωρίς έλεγχο του CI/CD. Ακόμα και αν ο κώδικας φαίνεται σωστός, μπορεί να μην μεταγλωττίζεται ή να αποτυγχάνει στα tests. Τα ρυθμισμένα Branch Protection μπλοκάρουν αυτόματα το merge σε κόκκινο CI, αλλά κάποιες ομάδες απενεργοποιούν αυτή την προστασία για ταχύτητα. Λύση: να ελέγχετε πάντα την κατάσταση του CI πριν το απρούβ και να μην εγκρίνετε ποτέ PR με κόκκινο pipeline.

• Τυπικό απρούβ — απουσία πραγματικού ελέγχου του κώδικα. Λύση: όριο 400 γραμμών ανά PR.
• Υπερβολική αυστηρότητα — αποκλεισμός λόγω στιλιστικών παρατηρήσεων. Λύση: διαχωρισμός σε blocking και optional.
• Αγνόηση του CI — απρούβ με κόκκινο pipeline. Λύση: να ελέγχετε πάντα την κατάσταση των ελέγχων.
• Ορισμός του συγγραφέα — απρούβ από τον συγγραφέα του PR. Λύση: ρύθμιση Branch Protection κατά του συγγραφέα.