Pull requests

Ένα pull request (PR), που ονομάζεται επίσης merge request στο GitLab, είναι μια αίτηση ενσωμάτωσης: «εδώ είναι η δουλειά μου σε έναν κλάδο, παρακαλώ αναθεωρήστε την και έπειτα συγχωνεύστε την στο main». Είναι το σημείο συνάντησης μεταξύ του κώδικα και της ομάδας.

Ένα PR δεν είναι μόνο ένα κουμπί «συγχώνευση». Είναι ένας χώρος συζήτησης γύρω από τον κώδικα: σχόλια, προτάσεις, αυτόματες δοκιμές, επικύρωση. Εκεί κρίνεται η ποιότητα.

Πριν ανοίξετε ένα PR, πρέπει να έχετε στείλει τον κλάδο σας στο GitHub.

Βήμα 1 — Αποστολή του κλάδου:

git switch feature/recherche
git push -u origin feature/recherche

Βήμα 2 — Άνοιγμα του PR (δύο επιλογές):

• Στη διεπαφή GitHub: εμφανίζεται ένα banner «Compare & pull request»· κάνετε κλικ, επιλέγετε τον κλάδο βάσης (main) και τον κλάδο σύγκρισης (feature/recherche).
• Από τη γραμμή εντολών με το GitHub CLI:

# Δημιουργία του PR χωρίς να φύγετε από το τερματικό
gh pr create --base main --head feature/recherche \
  --title "Ajout de la recherche" \
  --body "Implémente la barre de recherche avec filtres."

Μια καλή περιγραφή PR περιέχει:

Ο τίτλος και η περιγραφή διαβάζονται από ανθρώπους βιαστικούς. Να είστε σαφείς: «Διορθώνει το crash στη σύνδεση» αξίζει χίλιες φορές περισσότερο από «fix bug».

🔧 Μίνι-άσκηση — Από τον τρέχοντα κλάδο feature/recherche, δημιουργήστε ένα pull request προς το main με το gh, δίνοντας έναν σαφή τίτλο.

gh pr create --base main --head feature/recherche \
  --title "Ajout de la recherche" --body "Implémente la barre de recherche."

Η αναθεώρηση κώδικα (code review) είναι η καρδιά του PR: ένας ή περισσότεροι συνάδελφοι διαβάζουν τις τροποποιήσεις, θέτουν ερωτήσεις, προτείνουν βελτιώσεις και καταλήγουν να εγκρίνουν ή να ζητήσουν αλλαγές.

Οι τρεις δυνατές αποφάσεις στο GitHub:

Από την πλευρά του συγγραφέα, μετά από σχόλια, διορθώνουμε και ξαναστέλνουμε: το PR ενημερώνεται αυτόματα.

# Διόρθωση μετά την αναθεώρηση
git switch feature/recherche
# ... τροποποιήσεις ...
git commit -am "Prise en compte des retours de revue"
git push          # το PR ενημερώνεται μόνο του

Τι κοιτάζει ένας καλός reviewer:

• Ο κώδικας κάνει αυτό που ισχυρίζεται; (σωστή λογική)
• Είναι ευανάγνωστος και συντηρήσιμος;
• Υπάρχουν δοκιμές; Η CI περνάει στο πράσινο;
• Προβλήματα ασφάλειας ή απόδοσης;

Η αναθεώρηση κώδικα δεν είναι κρίση του προσώπου, αλλά συλλογική βελτίωση του προϊόντος. Κρίνουμε τον κώδικα, ποτέ τον συγγραφέα. Και υπογραμμίζουμε επίσης ό,τι είναι καλά φτιαγμένο.

Μόλις το PR εγκριθεί και η CI είναι πράσινη, το συγχωνεύουμε. Το GitHub προτείνει τρεις μεθόδους, που αλλάζουν τη μορφή του ιστορικού.

# Συγχώνευση από το τερματικό με το GitHub CLI
gh pr merge 42 --squash --delete-branch

Μετά τη συγχώνευση, καθαρίζουμε:

# Διαγραφή του απομακρυσμένου κλάδου (συχνά αυτόματη)
git push origin --delete feature/recherche

# Ενημέρωση του τοπικού
git switch main
git pull origin main

# Διαγραφή του τοπικού κλάδου
git branch -d feature/recherche

Το squash and merge είναι πολύ δημοφιλές: μία λειτουργία = ένα καθαρό commit στο main. Το ιστορικό γίνεται μια ευανάγνωστη λίστα λειτουργιών, και όχι ένας σωρός από «wip», «fix typo», «oups».

🔧 Μίνι-άσκηση — Με το gh, συγχωνεύστε το PR αριθμός 42 με squash και διαγράψτε τον κλάδο μαζί. Γράψτε την εντολή.

Ένα αποτελεσματικό PR είναι μικρό, σαφές και δοκιμασμένο. Ακολουθούν οι συνήθειες των αποδοτικών ομάδων.

# Αυτόματη σύνδεση ενός issue στην περιγραφή
gh pr create --title "Ajout export CSV" \
  --body "Permet d'exporter les données en CSV. Closes #57"

Ένα PR 1 000 γραμμών λαμβάνει ένα «LGTM» (looks good to me) χωρίς πραγματική ανάγνωση — κανείς δεν έχει το θάρρος να τα διαβάσει όλα. Ένα PR 50 γραμμών λαμβάνει πολύτιμα σχόλια. Μικρό = σοβαρή αναθεώρηση.

🔧 Μίνι-άσκηση — Ποια λέξη-κλειδί προσθέτετε στην περιγραφή ενός PR για να κλείσει αυτόματα το issue #57 κατά τη συγχώνευση;

Question 1 : Σε τι χρησιμεύει ένα pull request;

a) Να διαγράψετε έναν κλάδο

b) Να ζητήσετε αναθεώρηση και ενσωμάτωση ενός κλάδου σε έναν άλλο

c) Να εγκαταστήσετε το Git

d) Να κλωνοποιήσετε ένα αποθετήριο

Question 2 : Τι πρέπει να κάνετε πριν μπορέσετε να ανοίξετε ένα PR στο GitHub;

a) Να διαγράψετε το main

b) Να στείλετε τον κλάδο στο απομακρυσμένο αποθετήριο (git push)

c) Να κλείσετε το τερματικό

d) Να απενεργοποιήσετε την CI

Question 3 : Τι σημαίνει «Request changes» σε μια αναθεώρηση;

a) Ο κώδικας εγκρίθηκε

b) Χρειάζονται διορθώσεις πριν από τη συγχώνευση

c) Το PR διαγράφηκε

d) Δημιουργείται νέο αποθετήριο

Question 4 : Ποια μέθοδος συγχώνευσης συμπιέζει όλα τα commits του κλάδου σε ένα;

a) Create a merge commit

b) Squash and merge

c) Rebase and merge

d) Cherry-pick

Question 5 : Γιατί να προτιμάτε μικρά pull requests;

a) Καταναλώνουν λιγότερο δίσκο

b) Αναθεωρούνται πιο γρήγορα και πιο σοβαρά

c) Το GitHub τα καθιστά υποχρεωτικά

d) Αποφεύγουν τη συγγραφή δοκιμών

Οδηγία

Ολοκληρώσατε μια λειτουργία στον κλάδο feature/footer. Εκτελέστε τον πλήρη κύκλο ενός pull request με το GitHub CLI (gh):

1. Στείλτε τον κλάδο.
2. Ανοίξτε ένα PR προς το main με σαφή τίτλο και σύνδεσμο issue (Closes #12).
3. Μόλις εγκριθεί, συγχωνεύστε το με squash και διαγράψτε τον κλάδο.
4. Ενημερώστε το τοπικό σας αποθετήριο.

Διόρθωση

# 1. Αποστολή του κλάδου
git switch feature/footer
git push -u origin feature/footer

# 2. Άνοιγμα του pull request
gh pr create --base main --head feature/footer \
  --title "Ajout du pied de page du site" \
  --body "Ajoute un footer responsive avec liens et mentions légales. Closes #12"

# 3. Μετά την έγκριση: συγχώνευση squash + διαγραφή του κλάδου
gh pr merge --squash --delete-branch

# 4. Ενημέρωση του τοπικού
git switch main
git pull origin main
git branch -d feature/footer

Αναμενόμενο αποτέλεσμα:

$ git log --oneline -1
a1b2c3d Ajout du pied de page du site (#13)

Ο αριθμός σε παρένθεση (#13) προστίθεται αυτόματα από το GitHub: είναι ο αριθμός του PR. Κάνοντας κλικ επιστρέφετε σε όλη τη συζήτηση αναθεώρησης. Πλήρης ιχνηλασιμότητα.

Σημεία που πρέπει να θυμάστε

1. Ένα pull request ζητά αναθεώρηση και έπειτα συγχώνευση ενός κλάδου: είναι χώρος συζήτησης.
2. Δημιουργία PR: αποστολή του κλάδου, έπειτα άνοιγμα μέσω της διεπαφής ή gh pr create.
3. Η αναθεώρηση κώδικα καταλήγει σε Approve, Request changes ή Comment· κρίνουμε τον κώδικα, όχι τον συγγραφέα.
4. Τρεις μέθοδοι συγχώνευσης: merge commit, squash and merge, rebase and merge.
5. Καλές πρακτικές: μικρά PR, ένα μόνο θέμα, πράσινη CI, συνδεδεμένο issue.
6. Μετά τη συγχώνευση: διαγραφή του κλάδου και ενημέρωση του τοπικού.

Η συνέχεια

Κατέχετε τον κύκλο συνεισφοράς στο δικό σας αποθετήριο. Το μάθημα 04 — Συνεργατική ροή εργασίας ανοίγει την ευρύτερη συνεργασία: fork, clone, issues και καλές πρακτικές ομάδας.