Pull Request: Τι είναι, διαδικασία δημιουργίας και code review

Τι είναι το Pull Request;

Pull Request (PR) — είναι ένα επίσημο αίτημα για την ενσωμάτωση αλλαγών από ένα branch σε ένα άλλο στο πλαίσιο ενός κατανεμημένου συστήματος ελέγχου εκδόσεων. Το PR αποτελεί κεντρικό στοιχείο της συνεργατικής ανάπτυξης στις πλατφόρμες GitHub, GitLab και Bitbucket, συνδυάζοντας συζήτηση κώδικα, αυτόματο έλεγχο και διαδικασία έγκρισης αλλαγών.

Η ονομασία “Pull Request” αντικατοπτρίζει την ουσία της λειτουργίας: ο προγραμματιστής ζητά (request) από τον κάτοχο του αποθετηρίου να “τραβήξει” (pull) τις αλλαγές του. Ο όρος εισήχθη από το GitHub το 2008 — πριν από αυτό, παρόμοιος μηχανισμός υπήρχε με τη μορφή patches και merge request (όρος του GitLab). Σήμερα, το PR είναι το de facto πρότυπο για ομαδική ανάπτυξη με Git.

Σύμφωνα με τα στοιχεία GitHub Octoverse, 2025, το 89% των open-source έργων απαιτεί τη δημιουργία PR για την υποβολή αλλαγών. Στην εταιρική ανάπτυξη, το ποσοστό αυτό φτάνει το 95%. Το PR δεν είναι απλώς ένα τεχνικό εργαλείο, αλλά μέρος της κουλτούρας ανάπτυξης: μέσω του PR γίνεται μεταφορά γνώσης, εντοπισμός σφαλμάτων και συμφωνία αρχιτεκτονικών αποφάσεων.

Στοιχεία ενός Pull Request

Ένα τυπικό PR αποτελείται από τίτλο, περιγραφή, λίστα αλλαγμένων αρχείων (diff), σχόλια ελεγκτών και καταστάσεις ελέγχων CI. Κάθε PR συνδέεται με ένα συγκεκριμένο branch-πηγή και ένα branch-στόχο, και μετά τη συγχώνευση μπορεί να διαγραφεί αυτόματα.

Πώς να δημιουργήσετε Pull Request

Η δημιουργία PR ξεκινά με τη δημοσίευση του feature branch στο απομακρυσμένο αποθετήριο. Μετά το push, ο προγραμματιστής ανοίγει το PR μέσω της διεπαφής της πλατφόρμας ή μέσω CLI (gh, glab). Ας δούμε τη διαδικασία με παράδειγμα το GitHub.

Push branch και άνοιγμα PR

Το πρώτο βήμα — κάντε push το feature branch στο απομακρυσμένο αποθετήριο και δημιουργήστε Pull Request μέσω web διεπαφής ή γραμμής εντολών.

# Δημιουργία και προώθηση feature branch
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Δημιουργία PR μέσω GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Μετά τη δημιουργία PR, το GitHub εκτελεί αυτόματα CI pipelines (GitHub Actions), ελέγχει για συγκρούσεις με το branch-στόχο και προσκαλεί ελεγκτές. Το πρότυπο περιγραφής PR μπορεί να ρυθμιστεί μέσω του .github/PULL_REQUEST_TEMPLATE.md, ώστε όλα τα PR να περιέχουν υποχρεωτικές ενότητες: σκοπός, αλλαγές, δοκιμές, σχετικές εργασίες.

Περιγραφή και ετικέτες

Μια ποιοτική περιγραφή PR περιλαμβάνει: σύνδεσμο προς την εργασία (issue/ticket), σύντομη περιγραφή αλλαγών, οδηγίες δοκιμής και λίστα σχετικών αλλαγών. Οι ετικέτες (bug, feature, refactoring) βοηθούν στην κατηγοριοποίηση PR, ενώ οι assignees και reviewers ορίζονται αυτόματα μέσω CODEOWNERS.

# Ορισμός ελεγκτών μέσω CODEOWNERS (αρχείο στη ρίζα του αποθετηρίου)
# Παράδειγμα .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Δημιουργία PR με ορισμό ελεγκτών μέσω gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — ένας τυπικός μηχανισμός GitHub/GitLab για αυτόματο ορισμό ελεγκτών ανάλογα με τα αλλαγμένα αρχεία. Για παράδειγμα, οποιεσδήποτε αλλαγές στον κατάλογο src/auth/ ορίζουν αυτόματα τους team-auth και senior-dev ως ελεγκτές. Αυτό επιταχύνει τη διαδικασία και διασφαλίζει ότι τα κατάλληλα άτομα θα δουν το PR.

Ενημέρωση PR βάσει ελέγχου

Μετά τη λήψη σχολίων από τον ελεγκτή, ο προγραμματιστής κάνει διορθώσεις στο ίδιο feature branch και κάνει push νέα commits — το PR ενημερώνεται αυτόματα. Είναι σημαντικό να μην γίνεται επαναγραφή ιστορικού (rebase) σε ένα δημοσιευμένο feature branch εάν το PR είναι ήδη ανοιχτό, καθώς αυτό σπάει τους συνδέσμους προς συγκεκριμένα commits στα σχόλια.

# Εφαρμογή αλλαγών σύμφωνα με τα σχόλια του ελεγκτή
git checkout feature/biometric-auth
# διόρθωση κώδικα
git commit -m "fix: handle biometric timeout per review"
git push

# το PR ενημερώνεται αυτόματα
# Μετά την έγκριση — συγχώνευση PR μέσω διεπαφής GitHub

Διαδικασία code review

Code review — το κεντρικό στοιχείο ενός Pull Request. Ο ελεγκτής ελέγχει τις αλλαγές για ορθότητα, στυλ κώδικα, ασφάλεια και αρχιτεκτονική συνοχή. Ένα ποιοτικό review όχι μόνο αποτρέπει σφάλματα, αλλά διαδίδει γνώση σχετικά με τη βάση κώδικα εντός της ομάδας.

Οι Engineering Practices της Google (2025) συνιστούν τις ακόλουθες αρχές code review: ο ελεγκτής πρέπει να κατανοεί το πλαίσιο των αλλαγών, να δίνει συγκεκριμένες συστάσεις αντί για γενικές παρατηρήσεις και να διαχωρίζει τεχνικά και υφολογικά σχόλια. Ο χρόνος ελέγχου δεν πρέπει να υπερβαίνει τις 24 ώρες από τη δημιουργία του PR.

Για την ανάπτυξη εφαρμογών κινητών, το code review περιλαμβάνει συγκεκριμένους ελέγχους: συμβατότητα με targetSdk, σωστή διαχείριση lifecycle (Android) / view lifecycle (iOS), απουσία διαρροών μνήμης (LeakCanary, Instruments), υποστήριξη σκούρου θέματος και τοπικοποίηση. Αυτοί οι έλεγχοι μπορούν να αυτοματοποιηθούν μέσω linters και Detekt/ktlint.

Τύποι σχολίων

Οι πλατφόρμες PR υποστηρίζουν τρεις τύπους σχολίων: γενικά (στο σύνολο του PR), γραμμικά (σε συγκεκριμένη γραμμή κώδικα) και προτάσεις (suggestions με κώδικα προς αντικατάσταση). Τα suggestions επιτρέπουν την εφαρμογή αλλαγής με ένα κλικ, επιταχύνοντας τη διαδικασία και μειώνοντας τον αριθμό επαναλήψεων.

Αφού επιλυθούν όλα τα σχόλια και ολοκληρωθούν οι έλεγχοι CI, ο ελεγκτής στέλνει έγκριση (Approved). Το PR μπορεί να συγχωνευθεί. Το GitHub και το GitLab υποστηρίζουν κανόνες προστασίας branch: υποχρεωτικός αριθμός εγκρίσεων, υποχρεωτικοί έλεγχοι CI, απαγόρευση push στο main χωρίς PR. Για έργα κινητών, η προστασία branch περιλαμβάνει επίσης έλεγχο build: το PR δεν μπορεί να συγχωνευθεί εάν η εφαρμογή δεν μεταγλωττίζεται (gradle build failed / xcodebuild failed).

Επίλυση συγκρούσεων στο PR

Οι συγκρούσεις συγχώνευσης σε ένα Pull Request είναι συνηθισμένο φαινόμενο σε ενεργή ομαδική εργασία. Οι πλατφόρμες προσφέρουν επίλυση συγκρούσεων μέσω web διεπαφής (για απλές συγκρούσεις) ή συνιστούν τοπική επίλυση. Το GitHub Actions ελέγχει αυτόματα τη δυνατότητα συγχώνευσης σε κάθε push στο feature branch και επισημαίνει το PR ως conflicted εάν η συγχώνευση δεν είναι εφικτή.

Βέλτιστες πρακτικές Pull Request

Αποτελεσματικά Pull Request επιταχύνουν το code review και μειώνουν τον αριθμό σφαλμάτων. Μια μελέτη της SmartBear (2025) έδειξε ότι PR με μέγεθος έως 200 γραμμές κώδικα λαμβάνουν 2 φορές περισσότερα ουσιαστικά σχόλια από PR με περισσότερες από 1000 γραμμές, ενώ ο χρόνος review μειώνεται 3 φορές.

• Μικρά PR — το βέλτιστο μέγεθος είναι 100-300 γραμμές. Χωρίστε μεγάλα PR σε λογικά μέρη: κάθε PR λύνει ένα πρόβλημα. Αυτό απλοποιεί το review και μειώνει την πιθανότητα συγκρούσεων
• Σαφής περιγραφή — τίτλος σύμφωνα με το Conventional Commits (feat:, fix:, refactor:), το σώμα του PR περιέχει “tι και γιατί”, όχι “πώς” (ο κώδικας μιλάει από μόνος του). Πρότυπο: σκοπός → αλλαγές → δοκιμές → σχετικές εργασίες
• Γρήγορη ανατροφοδότηση — review εντός 24 ωρών. Εάν το PR περιμένει περισσότερο από μία ημέρα, η ομάδα χάνει το πλαίσιο και αυξάνονται οι συγκρούσεις κατά τη συγχώνευση
• Αυτοματοποίηση — linters, formatters και tests πρέπει να εκτελούνται αυτόματα κατά τη δημιουργία PR. Μην επιτρέπετε συγχώνευση PR με αποτυχημένους ελέγχους CI
• Draft PR — χρησιμοποιήστε το για πρώιμη συζήτηση αρχιτεκτονικής. Το Draft PR δεν απαιτεί review και δεν μπορεί να συγχωνευθεί, αλλά επιτρέπει την εμφάνιση κώδικα σε συναδέλφους σε πρώιμο στάδιο

Επιπλέον πρακτικές: μην δημιουργείτε PR την Παρασκευή το βράδυ (κανείς δεν θα κάνει review μέχρι τη Δευτέρα), ζητήστε review από 1-2 άτομα (περισσότερα επιβραδύνουν τη διαδικασία χωρίς βελτίωση ποιότητας), χρησιμοποιήστε squash merge για συμπίεση ιστορικού πριν από τη συγχώνευση. Για έργα κινητών, συνιστάται επίσης να προσθέτετε στην περιγραφή PR έναν σύνδεσμο προς δοκιμαστική build (Firebase App Distribution / TestFlight), ώστε ο ελεγκτής να μπορεί να ελέγξει τις αλλαγές σε λειτουργική εφαρμογή.

Pull Request σε διαφορετικές πλατφόρμες

Οι κύριες πλατφόρμες για εργασία με Pull Request είναι GitHub, GitLab και Bitbucket. Παρά την κοινή ιδέα, κάθε μία έχει ιδιαιτερότητες που πρέπει να ληφθούν υπόψη κατά την επιλογή εργαλείου για την ομάδα.

GitHub — η πιο δημοφιλής πλατφόρμα με τη μεγαλύτερη κοινότητα, Actions για CI/CD και εκτεταμένο οικοσύστημα εφαρμογών (GitHub Marketplace). GitLab ξεχωρίζει με ενσωματωμένο CI/CD και δυνατότητα πλήρους self-hosted ανάπτυξης. Bitbucket είναι στενά ενσωματωμένο με Jira και το οικοσύστημα Atlassian, δημοφιλές σε εταιρικά περιβάλλοντα.

Για την ανάπτυξη εφαρμογών κινητών, η επιλογή πλατφόρμας συχνά καθορίζεται από τις δυνατότητες CI/CD: το GitHub Actions υποστηρίζει macOS runners για build iOS, το GitLab έχει ενσωματωμένους runners για iOS/Android, το Bitbucket ενσωματώνεται καλά με το Firebase Test Lab. Ανεξάρτητα από την πλατφόρμα, η διαδικασία PR παραμένει ίδια: branch → review → CI → merge.