Δημιουργείται ένας νέος κλάδος από τον master
, τον οποίο ονομάζουμε test
.
Υπάρχουν αρκετοί προγραμματιστές που είτε δεσμεύουν στο master
είτε δημιουργούν άλλους κλάδους και αργότερα συγχωνεύονται στο master
.
Ας υποθέσουμε ότι η εργασία στο test
διαρκεί αρκετές ημέρες και θέλετε να κρατάτε συνεχώς το test
ενημερωμένο με commits μέσα στο master
.
Θα έκανα το git pull origin master
από το test
.
Ερώτηση 1: Είναι αυτή η σωστή προσέγγιση; Άλλοι προγραμματιστές θα μπορούσαν εύκολα να δουλέψουν στα ίδια αρχεία που δούλεψα εγώ btw.
Η εργασία μου στο test
έχει τελειώσει και είμαι έτοιμος να το συγχωνεύσω πίσω στο master
. Εδώ είναι οι δύο τρόποι που μπορώ να σκεφτώ:
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
Δεν χρησιμοποιώ το --rebase
γιατί από όσο καταλαβαίνω, το rebase θα πάρει τις αλλαγές από το master
και θα συσσωρεύσει τις δικές μου πάνω σε αυτές, άρα θα μπορούσε να αντικαταστήσει τις αλλαγές που έκαναν άλλοι άνθρωποι.
Ερώτηση 2: Ποια από αυτές τις δύο μεθόδους είναι σωστή; Ποια είναι η διαφορά;
Ο στόχος σε όλα αυτά είναι να διατηρώ τον κλάδο test
μου ενημερωμένο με τα πράγματα που συμβαίνουν στο master
και αργότερα θα μπορούσα να τα συγχωνεύσω πίσω στο master
ελπίζοντας να διατηρήσω το χρονοδιάγραμμα όσο το δυνατόν πιο γραμμικό.
Πώς θα το έκανα αυτό
git checkout master
git pull origin master
git merge test
git push origin master
Εάν έχω έναν τοπικό κλάδο από έναν απομακρυσμένο, δεν αισθάνομαι άνετα με τη συγχώνευση άλλων κλάδων εκτός από αυτόν με τον απομακρυσμένο. Επίσης, δεν θα προωθούσα τις αλλαγές μου, μέχρι να'είμαι ευχαριστημένος με αυτό που θέλω να προωθήσω και επίσης δεν θα'δεν θα προωθούσα καθόλου πράγματα, που είναι μόνο για μένα και το τοπικό μου αποθετήριο. Από την περιγραφή σας φαίνεται ότι το test
είναι μόνο για εσάς; Επομένως, δεν υπάρχει λόγος να το δημοσιεύσετε.
Το git προσπαθεί πάντα να σέβεται τις δικές σας και τις αλλαγές των άλλων, το ίδιο και το --rebase
. Δεν νομίζω ότι μπορώ να το εξηγήσω κατάλληλα, οπότε ρίξτε μια ματιά στο the Git book - Rebasing ή στο git-ready: Intro into rebasing για μια μικρή περιγραφή. Είναι ένα αρκετά καλό χαρακτηριστικό
Αυτή είναι μια πολύ πρακτική ερώτηση, αλλά όλες οι παραπάνω απαντήσεις δεν είναι πρακτικές.
Όπως το
git checkout master
git pull origin master
git merge test
git push origin master
Αυτή η προσέγγιση έχει δύο ζητήματα:
Δεν είναι ασφαλής, επειδή δεν γνωρίζουμε αν υπάρχουν συγκρούσεις μεταξύ του κλάδου δοκιμών και του κύριου κλάδου.
Θα "συμπιέσει" όλες τις δοκιμαστικές δεσμεύσεις σε μια δέσμευση συγχώνευσης στο master- δηλαδή στο master branch, δεν μπορούμε να δούμε όλα τα αρχεία καταγραφής αλλαγών του test branch.
Έτσι, όταν υποψιαζόμαστε ότι υπάρχουν κάποιες συγκρούσεις, μπορούμε να έχουμε τις ακόλουθες λειτουργίες git:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Δοκιμάστε τη "συγχώνευση" πριν από την "δέσμευση", αποφύγετε μια γρήγορη δέσμευση με τη μέθοδο "no-off",
Αν προκύψει σύγκρουση, μπορούμε να εκτελέσουμε το git status
για να ελέγξουμε λεπτομέρειες σχετικά με τις συγκρούσεις και να προσπαθήσουμε να τις λύσουμε
git status
Μόλις επιλύσουμε τις συγκρούσεις, ή αν δεν υπάρχει σύγκρουση, τις επιβεβαιώνουμε
και τις προωθούμε
.
git commit -m 'merge test branch'
git push
Αλλά με αυτόν τον τρόπο θα χάσουμε το ιστορικό των αλλαγών που καταγράφονται στον κλάδο δοκιμών και θα καταστήσει τον κλάδο master δύσκολο για τους άλλους προγραμματιστές να κατανοήσουν το ιστορικό του έργου.
Έτσι, η καλύτερη μέθοδος είναι να χρησιμοποιήσουμε το rebase
αντί για το merge
(υποθέστε, όταν αυτή τη φορά, έχουμε λύσει τις συγκρούσεις κλάδων).
Ακολουθεί ένα απλό παράδειγμα, για προχωρημένες λειτουργίες, ανατρέξτε στο http://git-scm.com/book/en/v2/Git-Branching-Rebasing.
git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
Ναι, όταν έχετε κάνει uppers, όλα τα commits του κλάδου Test's θα μετακινηθούν στην κεφαλή του κλάδου Master. Το σημαντικότερο πλεονέκτημα του rebasing είναι ότι έχετε ένα γραμμικό και πολύ πιο καθαρό ιστορικό του έργου.
Το μόνο πράγμα που πρέπει να αποφύγετε είναι: μην χρησιμοποιείτε ποτέ το rebase
σε δημόσιο κλάδο, όπως ο κλάδος master.
Ποτέ μην κάνετε λειτουργίες όπως οι ακόλουθες:
git checkout master
git rebase -i test
Λεπτομέρειες για https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
παράρτημα:
Ούτε μια επαναφορά ούτε μια συγχώνευση θα πρέπει να αντικαταστήσει τις αλλαγές οποιουδήποτε (εκτός αν το επιλέξετε όταν επιλύετε μια σύγκρουση).
Η συνήθης προσέγγιση κατά την ανάπτυξη είναι
git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
Όταν είστε έτοιμοι να συγχωνεύσετε πίσω στο master,
git checkout master
git log ..test # if you're curious
git merge test
git push
Αν ανησυχείτε μήπως σπάσετε κάτι κατά τη συγχώνευση, το git merge --abort
είναι εκεί για εσάς.
Η χρήση του push και στη συνέχεια του pull ως μέσο συγχώνευσης είναι ανόητη. Δεν είμαι επίσης σίγουρος γιατί σπρώχνετε το test στο origin.