Ποιος είναι ο καλύτερος (και ασφαλέστερος) τρόπος για τη συγχώνευση ενός κλάδου του Git στο master;

Δημιουργείται ένας νέος κλάδος από τον 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 ελπίζοντας να διατηρήσω το χρονοδιάγραμμα όσο το δυνατόν πιο γραμμικό.

uneet7
Επεξεργασμένη ερώτηση Κάνε Ιανουάριος 2019 в 7:21
Προγραμματισμός
git branching-and-merging git-merge git-branch
Κάνε Απρίλιος 2011 в 12:01
25 προβολές
Λύση

Πώς θα το έκανα αυτό

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 για μια μικρή περιγραφή. Είναι ένα αρκετά καλό χαρακτηριστικό

Noctis
Επεξεργασμένη απάντηση Κάνε Ιούνιος 2016 в 12:02
Σχόλια (19)

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

Όπως το

git checkout master
git pull origin master
git merge test
git push origin master

Αυτή η προσέγγιση έχει δύο ζητήματα:

  1. Δεν είναι ασφαλής, επειδή δεν γνωρίζουμε αν υπάρχουν συγκρούσεις μεταξύ του κλάδου δοκιμών και του κύριου κλάδου.

  2. Θα "συμπιέσει" όλες τις δοκιμαστικές δεσμεύσεις σε μια δέσμευση συγχώνευσης στο 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

παράρτημα:

Semnodime
Επεξεργασμένη απάντηση Κάνε Σεπτέμβριος 2018 в 8:36
Σχόλια (8)

Ούτε μια επαναφορά ούτε μια συγχώνευση θα πρέπει να αντικαταστήσει τις αλλαγές οποιουδήποτε (εκτός αν το επιλέξετε όταν επιλύετε μια σύγκρουση).

Η συνήθης προσέγγιση κατά την ανάπτυξη είναι

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.

raylu
Επεξεργασμένη απάντηση Κάνε Οκτώβριος 2013 в 9:47
Σχόλια (7)