Pertanyaan Cara terbaik (dan paling aman) untuk menggabungkan cabang git ke dalam master


Cabang baru dari master dibuat, kami menyebutnya test.

Ada beberapa pengembang yang berkomitmen untuk master atau buat cabang lain dan kemudian bergabung master.

Katakanlah bekerja test memakan waktu beberapa hari dan Anda ingin terus menyimpannya test diperbarui dengan komit di dalamnya master.

Saya akan melakukannya git pull origin master dari test.

Pertanyaan 1: Apakah ini pendekatan yang tepat? Pengembang lain dapat dengan mudah bekerja pada file yang sama karena saya telah bekerja btw.


Pekerjaan saya di test sudah selesai dan saya siap untuk menggabungkannya kembali master. Inilah dua cara yang dapat saya pikirkan:

SEBUAH: 

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

Saya tidak menggunakan --rebase karena dari pengertian saya, rebase akan mendapatkan perubahan dari master dan menumpuk tambang di atasnya sehingga dapat menimpa perubahan yang dibuat orang lain.

Pertanyaan 2: Yang mana dari kedua metode ini yang benar? Apa bedanya di sana?

Tujuan dalam semua ini adalah untuk menjaga saya test cabang diperbarui dengan hal-hal yang terjadi di master dan kemudian saya bisa menggabungkannya kembali master berharap untuk menjaga garis waktu linier mungkin.


1463
2018-04-09 00:01


asal


Jawaban:


Bagaimana saya akan melakukan ini

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

Jika saya memiliki cabang lokal dari cabang jarak jauh, saya tidak merasa nyaman untuk menggabungkan cabang-cabang lain daripada yang ini dengan remote. Saya juga tidak akan mendorong perubahan saya, sampai saya senang dengan apa yang ingin saya dorong dan juga saya tidak akan mendorong semuanya, itu hanya untuk saya dan repositori lokal saya. Dalam deskripsi Anda tampaknya, itu test hanya untukmu? Jadi tidak ada alasan untuk mempublikasikannya.

git selalu mencoba untuk menghormati Anda dan orang lain berubah, dan begitu juga --rebase. Saya tidak berpikir saya bisa menjelaskannya dengan tepat, jadi lihatlah buku Git - Rebase atau git-ready: Intro menjadi rebasing untuk sedikit deskripsi. Ini fitur yang cukup keren


2158
2018-04-09 00:45



Ini adalah pertanyaan yang sangat praktis, tetapi semua jawaban di atas tidak praktis.

Seperti

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

Pendekatan ini memiliki dua masalah:

  1. Ini tidak aman, karena kita tidak tahu apakah ada konflik antara cabang uji dan cabang utama.

  2. Ini akan "memeras" semua tes berkomitmen menjadi satu gabungan komit pada master; artinya di cabang master, kita tidak bisa melihat semua catatan perubahan dari cabang uji.

Jadi, ketika kita mencurigai akan ada beberapa konflik, kita dapat mengikuti operasi git:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Uji merge sebelum commit, hindari komit yang bergerak cepat dengan --no-ff,

Jika konflik ditemui, kita bisa lari git status untuk memeriksa detail tentang konflik dan mencoba menyelesaikannya

git status

Setelah kami menyelesaikan konflik, atau jika tidak ada konflik, kami commit dan push mereka

git commit -m 'merge test branch'
git push

Tapi cara ini akan kehilangan riwayat perubahan yang dicatat di cabang uji, dan itu akan membuat cabang master menjadi sulit bagi pengembang lain untuk memahami sejarah proyek.

Jadi metode terbaik adalah yang harus kita gunakan rebase dari pada merge (misalkan, ketika saat ini, kami telah menyelesaikan konflik cabang).

Berikut ini adalah satu contoh sederhana, untuk operasi lanjutan, silakan lihat 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

Ya, ketika Anda memiliki bagian atasnya, semua komitmen dari cabang Test akan dipindahkan ke kepala cabang Master. Manfaat utama dari rebasing adalah Anda mendapatkan sejarah proyek yang lebih linear dan lebih bersih.

Satu-satunya hal yang perlu Anda hindari adalah: tidak pernah digunakan rebase di cabang publik, seperti cabang utama.

seperti operasi berikut:

git checkout master
git rebase -i test

tidak pernah melakukan operasi ini.

Detail untuk https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

lampiran:


260
2018-03-14 12:13



Baik rebase maupun penggabungan harus menimpa perubahan siapa pun (kecuali Anda memilih untuk melakukannya ketika menyelesaikan konflik).

Pendekatan yang biasa dilakukan saat mengembangkan

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

Ketika Anda siap untuk bergabung kembali menjadi tuan,

git checkout master
git log ..test # if you're curious
git merge test
git push

Jika Anda khawatir tentang melanggar sesuatu pada penggabungan, git merge --abort ada untukmu.

Menggunakan dorongan dan kemudian menarik sebagai sarana penggabungan itu konyol. Saya juga tidak yakin mengapa Anda mendorong tes ke asal.


73
2018-04-10 00:17



Selain Jawaban KingCrunches, Saya sarankan untuk digunakan

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Anda mungkin telah membuat banyak komit di cabang lain, yang seharusnya hanya menjadi satu komit di cabang master. Untuk menjaga sejarah commit sebersih mungkin, Anda mungkin ingin menekan semua commit Anda dari cabang uji menjadi satu commit dalam cabang master (lihat juga: Git: Untuk squash atau tidak squash?). Kemudian Anda juga dapat menulis ulang pesan komit kepada sesuatu yang sangat ekspresif. Sesuatu yang mudah dibaca dan dipahami, tanpa menggali kode.

sunting: Anda mungkin tertarik

Jadi di GitHub, saya akhirnya melakukan hal berikut untuk cabang fitur mybranch:

Dapatkan yang terbaru dari asal

$ git checkout master
$ git pull origin master

Temukan hash basis gabungan:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Sekarang pastikan hanya yang pertama pick, sisanya s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Selanjutnya pilih pesan komit yang sangat bagus dan dorong ke GitHub. Buat permintaan tarik kemudian.

Setelah penggabungan permintaan tarik, Anda dapat menghapusnya secara lokal:

$ git branch -d mybranch

dan di GitHub

$ git push origin :mybranch

20
2018-04-21 08:18



Ini adalah alur kerja yang saya gunakan di pekerjaan saya dengan tim. Skenarionya seperti yang Anda gambarkan. Pertama, ketika saya selesai bekerja test Saya rebase dengan master untuk menarik apa yang telah ditambahkan pada master selama waktu yang saya kerjakan test cabang.

git pull -r upstream master

Ini akan menarik perubahan untuk dikuasai karena Anda bercabang test cabang dan terapkan, lalu terapkan perubahan yang Anda buat untuk menguji "di atas" status master saat ini. Mungkin ada konflik di sini, jika orang lain telah membuat perubahan pada file yang sama yang Anda edit dalam pengujian. Jika ada, Anda harus memperbaikinya secara manual, dan berkomitmen. Setelah Anda selesai melakukannya, Anda akan lebih baik untuk beralih ke cabang master dan bergabung testtanpa masalah.


3
2018-03-16 22:27



git checkout master
git pull origin master
# Merge branch test into master
git merge test

Setelah penggabungan, jika file diubah, maka ketika Anda menggabungkannya akan melalui kesalahan "Selesaikan Konflik"

Jadi, Anda harus terlebih dahulu menyelesaikan semua konflik Anda, Anda harus kembali melakukan semua perubahan dan kemudian mendorong

git push origin master

Ini lebih baik dilakukan siapa yang telah melakukan perubahan di cabang tes, karena dia tahu perubahan apa yang telah dilakukannya.


1
2018-04-07 08:55