Merge Request (MR): τι είναι, πώς να το δημιουργήσετε και διαδικασία αναθεώρησης

Τι είναι το Merge Request (MR);

Merge Request (MR) — αίτημα ενσωμάτωσης αλλαγών από έναν κλάδο Git σε άλλον, που εκκινεί τη διαδικασία αναθεώρησης κώδικα και αυτόματου ελέγχου. Σε αντίθεση με την άμεση συγχώνευση μέσω κονσόλας, το MR δημιουργεί μια επίσημη διαδικασία: ο προγραμματιστής περιγράφει τις αλλαγές, ορίζει αναθεωρητές, εκκινεί το CI/CD και λαμβάνει ανατροφοδότηση πριν από την εφαρμογή των αλλαγών. Αποτελεί βασικό στοιχείο του GitLab, αλλά ο ανάλογος μηχανισμός στο GitHub ονομάζεται Pull Request (PR).

Σύμφωνα με το GitLab Documentation, 2026, στο GitLab δημιουργούνται πάνω από 80 εκατομμύρια Merge Request ετησίως. Κάθε MR περιέχει τέσσερα βασικά στοιχεία: περιγραφή (description) με πλαίσιο αλλαγών, λίστα commits (commits), διαφορά κώδικα (diff) και συζήτηση (discussion thread). Χωρίς ένα από αυτά τα στοιχεία, το MR θεωρείται ελλιπές.

Merge Request (MR) επιλύει τρία καθήκοντα: αποτρέπει άμεσες αλλαγές σε προστατευμένους κλάδους (main, develop), εξασφαλίζει έλεγχο ποιότητας μέσω αναθεώρησης και διατηρεί το ιστορικό συζητήσεων για μελλοντικούς προγραμματιστές. Στο GitLab, η κατάσταση MR εμφανίζεται στη διεπαφή με χρωματικές ενδείξεις: γκρι για Draft, πορτοκαλί για αναμονή, πράσινο για Approved, μωβ για Merged και κόκκινο για Closed.

Ορολογία: MR, PR και CR

Σε διάφορες πλατφόρμες Git, το Merge Request ονομάζεται διαφορετικά. Το GitLab χρησιμοποιεί “Merge Request” (MR), το GitHub — “Pull Request” (PR). Αναλογία — Change Request (CR) στο Gerrit. Και τα τρία αναφέρονται στην ίδια διαδικασία: αίτημα ενσωμάτωσης αλλαγών μέσω αναθεώρησης κώδικα. Η επιλογή του όρου εξαρτάται μόνο από την πλατφόρμα που χρησιμοποιείται στο έργο.

# Δημιουργία κλάδου με αλλαγές
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Το MR μπορεί να δημιουργηθεί μέσω UI GitLab/GitHub ή CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: ποια είναι η διαφορά μεταξύ GitLab και GitHub

Merge Request στο GitLab και Pull Request στο GitHub — είναι λειτουργικά πανομοιότυποι μηχανισμοί με διαφορετικές ονομασίες. Η διαφορά οφείλεται στην ιστορία: το GitLab αρχικά τοποθετήθηκε ως εναλλακτική λύση Self-Hosted για το GitHub και επέλεξε τον όρο “Merge Request” για τη διαδικασία συγχώνευσης. Το GitHub, που ξεκίνησε νωρίτερα, χρησιμοποίησε το “Pull Request” — αίτημα “τραβήγματος” (pull) των αλλαγών στον κύριο κλάδο.

Σύμφωνα με το GitHub Docs, 2024, και τα δύο εργαλεία υποστηρίζουν το ίδιο σύνολο λειτουργιών: περιγραφή με Markdown, ορισμό αναθεωρητών, σχολιασμό συγκεκριμένων γραμμών κώδικα, καταστάσεις ελέγχου και αυτόματη συγχώνευση όταν πληρούνται οι προϋποθέσεις. Οι διαφορές αφορούν τη διεπαφή και πρόσθετες δυνατότητες.

Πώς να δημιουργήσετε Merge Request: οδηγός βήμα προς βήμα

Η δημιουργία Merge Request (MR) ξεκινά με τη δημοσίευση του κλάδου με αλλαγές στο απομακρυσμένο αποθετήριο. Μετά το push στο GitLab ή το GitHub, εμφανίζεται το κουμπί “Create Merge Request” ή “Compare & Pull Request” στη διεπαφή. Ο προγραμματιστής συμπληρώνει την περιγραφή, υποδεικνύει τον κλάδο-στόχο (συνήθως develop ή main), ορίζει αναθεωρητές και προσθέτει ετικέτες (labels).

Σύμφωνα με το GitLab Documentation, 2025, ένα τυπικό MR περιέχει τίτλο έως 72 χαρακτήρες, περιγραφή με πρότυπο (template) και σύνδεσμο προς την εργασία (issue). Η περιγραφή πρέπει να απαντά στις ερωτήσεις: τι έγινε, γιατί, πώς δοκιμάστηκε. Το GitLab υποστηρίζει αυτόματο κλείσιμο issue κατά τη συγχώνευση μέσω των λέξεων-κλειδιών Closes, Fixes, Resolves.

# Παράδειγμα προτύπου .gitlab/merge_request_templates/default.md
## What does this MR do?

[Σύντομη περιγραφή αλλαγών: τι και γιατί]

## How to test

1. Εκτέλεση ./gradlew test
2. Έλεγχος LoginActivity με δοκιμαστικό token
3. Βεβαιωθείτε ότι δεν υπάρχει οπισθοδρόμηση στο AuthManager

## Related issues

Closes #142

Κύκλος ζωής MR: από Draft έως Merged

Merge Request (MR) περνά από πέντε καταστάσεις στο GitLab. Η πρώτη — Draft (πρόχειρο), σημειώνεται με το πρόθεμα “Draft:” στον τίτλο και μπλοκάρει τη συγχώνευση. Μετά την προετοιμασία, ο προγραμματιστής αφαιρεί το Draft και το MR μεταβαίνει στην κατάσταση Opened — ξεκινά η αναθεώρηση κώδικα και εκκινείται το pipeline CI/CD.

Σύμφωνα με το GitLab Docs, 2024, στην κατάσταση Opened, οι αναθεωρητές εξετάζουν το diff, αφήνουν σχόλια και ζητούν αλλαγές μέσω Resolve Threads. Όταν όλα τα νήματα είναι κλειστά και το CI/CD ολοκληρωθεί με επιτυχία, ο υπεύθυνος προγραμματιστής ορίζει Approve. Στη συνέχεια, το MR μπορεί να συγχωνευθεί με το κουμπί Merge ή να περιμένει αυτόματη συγχώνευση (Auto-merge).

GitLab υποστηρίζει τρεις παραλλαγές τελικής κατάστασης: Merged (επιτυχώς συγχωνευμένο), Closed (κλειστό χωρίς συγχώνευση, π.χ. κατά την απόρριψη λειτουργίας) και Reopened (εκ νέου άνοιγμα μετά το κλείσιμο). Κάθε κατάσταση καταγράφεται στο Activity Timeline MR για έλεγχο.

Αυτόματες καταστάσεις και ενεργοποιητές

Το GitLab ενημερώνει αυτόματα την κατάσταση Merge Request κατά την εμφάνιση γεγονότων: κατά την push νέων commits, τα Approvals επαναφέρονται, σε επιτυχημένο CI pipeline η κατάσταση γίνεται Pipeline passed, σε σφάλμα — Pipeline failed (η συγχώνευση μπλοκάρεται). Μπορεί να ρυθμιστεί Auto-merge: το MR συγχωνεύεται αυτόματα μετά από επιτυχημένο CI και λήψη όλων των απαιτούμενων εγκρίσεων.

• Draft — πρόχειρο, το CI εκκινείται αλλά η συγχώνευση είναι μπλοκαρισμένη
• Opened — έτοιμο για αναθεώρηση, ορισμένοι αναθεωρητές, pipeline ενεργό
• Approved — έχει ληφθεί ο απαιτούμενος αριθμός εγκρίσεων
• Merged — οι αλλαγές έχουν συγχωνευθεί στον κλάδο-στόχο
• Closed — κλειστό χωρίς συγχώνευση

Κανόνες αναθεώρησης κώδικα στο Merge Request

Αναθεώρηση κώδικα στο Merge Request (MR) — υποχρεωτικό στάδιο στα περισσότερα εμπορικά έργα. Σύμφωνα με τα δεδομένα έρευνας της SmartBear, 2023, η αναθεώρηση κώδικα με MR μειώνει τον αριθμό ελαττωμάτων κατά 30–60% και επιταχύνει την ενσωμάτωση νέων προγραμματιστών. Βασικός κανόνας — κάθε MR ελέγχεται από τουλάχιστον έναν, κατά προτίμηση δύο προγραμματιστές που δεν συμμετείχαν στη συγγραφή του κώδικα.

Ο έλεγχος MR περιλαμβάνει πέντε κριτήρια: ορθότητα λογικής, συμμόρφωση με το στυλ κώδικα, κάλυψη δοκιμών, ασφάλεια και απόδοση. Στο GitLab μπορούν να ρυθμιστούν Required Approvals — υποχρεωτικός αριθμός εγκρίσεων πριν από τη συγχώνευση, π.χ. 2 εγκρίσεις για main και 1 για develop.

Συζήτηση στο MR γίνεται σε Threads — σχόλια σε συγκεκριμένες γραμμές κώδικα. Κάθε νήμα πρέπει να είναι resolved (κλειστό) πριν από τη συγχώνευση. Για επιτάχυνση της αναθεώρησης, συνιστάται ο περιορισμός του μεγέθους MR: 200–400 γραμμές αλλαγών. Σύμφωνα με το Google Research (2022), τα MR με όγκο άνω των 400 γραμμών ελέγχονται 30% λιγότερο αποτελεσματικά.

Pipeline CI/CD στο Merge Request

Κατά τη δημιουργία Merge Request (MR), το pipeline CI/CD εκκινείται αυτόματα. Στο GitLab, αυτό γίνεται μέσω του αρχείου .gitlab-ci.yml, στο GitHub — μέσω GitHub Actions workflow. Το pipeline περιλαμβάνει την κατασκευή του έργου (build), την εκτέλεση μοναδιαίων δοκιμών (unit tests), linters (lint), στατική ανάλυση (SAST) και έλεγχο κάλυψης κώδικα.

Σύμφωνα με το GitLab Blog, 2024, η κατάσταση pipeline εμφανίζεται απευθείας στο MR: πράσινο τικ (passed), κόκκινος σταυρός (failed) ή κίτρινος κύκλος (running). Εάν το pipeline αποτύχει, το GitLab μπλοκάρει το κουμπί Merge μέχρι τη διόρθωση. Στις ρυθμίσεις μπορεί να ενεργοποιηθεί το “Merge when pipeline succeeds” — αυτόματη συγχώνευση μετά από επιτυχημένο pipeline.

# .gitlab-ci.yml — παράδειγμα για έργο Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Μέθοδοι συγχώνευσης: Squash, Merge Commit, Fast-Forward

GitLab και GitHub προσφέρουν τρεις μεθόδους συγχώνευσης για Merge Request. Η επιλογή εξαρτάται από την πολιτική της ομάδας και την επιθυμητή καθαρότητα ιστορικού. Merge Commit — δημιουργεί ξεχωριστό commit συγχώνευσης, διατηρώντας ολόκληρο το ιστορικό του κλάδου λειτουργίας. Squash — συνδυάζει όλα τα commits του κλάδου σε ένα commit στον κλάδο-στόχο. Fast-Forward — εφαρμόζει τα commits γραμμικά χωρίς commit συγχώνευσης.

Σύμφωνα με το GitLab Docs, 2025, το Squash προτιμάται σε έργα με υψηλή πυκνότητα commits (20+ commits σε έναν κλάδο λειτουργίας). Το Fast-Forward είναι υποχρεωτικό για Trunk-Based Development. Το Merge Commit χρησιμοποιείται στο Git Flow για τη διατήρηση της σημασιολογίας διακλάδωσης.

• Merge Commit — διατηρεί το ιστορικό, δημιουργεί commit συγχώνευσης, κατάλληλο για Git Flow
• Squash — συνδυάζει όλα τα commits σε ένα, καθαρό ιστορικό, τα ενδιάμεσα commits χάνονται
• Fast-Forward — γραμμικό ιστορικό χωρίς commit συγχώνευσης, υποχρεωτικό σε TBD

Βέλτιστες πρακτικές: πώς να γράψετε ένα καλό MR

Ένα ποιοτικό Merge Request (MR) συντομεύει τον χρόνο αναθεώρησης και μειώνει τον αριθμό σφαλμάτων. Πρώτος κανόνας — ένα MR λύνει μία εργασία. Εάν οι αλλαγές επηρεάζουν πολλές άσχετες λειτουργίες, πρέπει να χωριστούν σε ξεχωριστά MR. Δεύτερος — ο τίτλος MR πρέπει να είναι κατατοπιστικός: “Add OAuth2 authentication with Google provider” αντί για “Fix stuff” ή “Update code”.

Σύμφωνα με το Google Engineering Practices, 2024, ένα καλό MR περιέχει περιγραφή πλαισίου: γιατί είναι απαραίτητες οι αλλαγές, πώς δοκιμάστηκαν, ποιοι είναι οι κίνδυνοι. Το μέγεθος MR δεν πρέπει να υπερβαίνει τις 400 γραμμές αλλαγών. Εάν ο όγκος είναι μεγαλύτερος — η εργασία πρέπει να αποσυντεθεί σε υποεργασίες. Για τεκμηρίωση και δοκιμές, επιτρέπονται εξαιρέσεις, αλλά με επεξήγηση.

Merge Request (MR) πρέπει να περιλαμβάνει αυτόματες δοκιμές για τη νέα λειτουργικότητα. Στο GitLab μπορεί να ρυθμιστεί η πολιτική Coverage Check — το MR μπλοκάρεται αυτόματα εάν η κάλυψη κώδικα έχει πέσει κάτω από το όριο (π.χ., 80%). Αυτό εγγυάται ότι η νέα λειτουργικότητα δεν μειώνει τη συνολική ποιότητα του έργου.

• Ένα MR — μία εργασία: αποσυνθέστε μεγάλες αλλαγές σε πολλά μικρά MR
• Περιγραφή με πρότυπο: χρησιμοποιήστε .gitlab/merge_request_templates για ομοιομορφία
• Μέγεθος έως 400 γραμμές: τα μεγάλα MR ελέγχονται πιο αργά και με περισσότερα σφάλματα
• Υποχρεωτικές δοκιμές: οι νέες λειτουργίες πρέπει να καλύπτονται από μοναδιαίες δοκιμές

Πρότυπα περιγραφής MR

Το GitLab υποστηρίζει πρότυπα Merge Request μέσω αρχείων .gitlab/merge_request_templates/. Το πρότυπο περιλαμβάνει ενότητες: τι έγινε, πώς να δοκιμάσετε, σχετικές εργασίες και λίστα ελέγχου. Η χρήση προτύπων επιταχύνει τη δημιουργία MR και εγγυάται ότι οι προγραμματιστές δεν θα ξεχάσουν να αναφέρουν σημαντικές πληροφορίες. Στην περιγραφή MR αναφέρεται υποχρεωτικά το σχετικό issue (Closes #N) για αυτόματο κλείσιμο εργασιών κατά τη συγχώνευση.