Perbarui cabang Git dari master


676

Saya baru mengenal Git, dan sekarang saya dalam situasi ini:

  • Saya memiliki empat cabang (master, b1, b2, dan b3).
  • Setelah saya bekerja pada b1-b3, saya menyadari bahwa saya memiliki sesuatu untuk diubah pada master cabang yang seharusnya ada di semua cabang lainnya.
  • Saya mengubah apa yang saya butuhkan masterdan ... ini masalah saya:

Bagaimana cara memperbarui semua cabang lainnya dengan masterkode cabang?



59
Namun tugas sederhana lain yang dipersulit oleh Git. Git devs harus menggunakan Stack Overflow sebagai umpan balik dalam loop SDLC mereka. 300.000 orang harus menunjukkan ada sesuatu yang salah dengan alur kerja Git. Mereka perlu menyewa seorang ahli UX karena mereka jelas tidak bisa melakukan git sendiri.
jww

Jawaban:


620

Anda memiliki dua opsi:

Yang pertama adalah penggabungan, tetapi ini menciptakan komit tambahan untuk penggabungan.

Periksa setiap cabang:

git checkout b1

Kemudian gabungkan:

git merge origin/master

Kemudian dorong:

git push origin b1

Atau, Anda dapat melakukan rebase:

git fetch
git rebase origin/master

15
Saya prihatin dengan pendekatan ini. Ketika saya menjalankan git log --graph, grafik menunjukkan master sebenarnya digabung ke cabang topik. Apakah ini akan menyebabkan masalah dalam jangka panjang? Saya pikir praktik terbaik selalu menggabungkan cabang topik kembali ke menguasai. Tolong beri komentar anda.
Patrick

2
Carilah masalah ini jika Anda akan mengikuti alur kerja gabungan: randyfay.com/node/89
Hampus Ahlgren

22
Anda menggabungkan master ke b1. Kenapa kamu got push origin master... tidak masuk akal. Anda tidak mengubah cabang utama. Saya pikir itu adalah kesalahan dengan 119 upvote: /
Yves Lange

22
Jangan menggunakan metode penggabungan, menggunakan git rebase masteradalah jawaban yang benar
Weston Ganger

6
Bagi kita yang membaca nanti - kekhawatiran @Kursion tentang kesalahan ketik ditangani oleh edit penulis. Selain itu, jawaban tervotifikasi tertinggi kedua di bawah ini pada dasarnya mengatakan hal yang sama dengan jawaban ini tetapi dengan diagram struktur cabang dan peringatan mengapa Anda tidak ingin rebase.
luarthealeal

496

Pada dasarnya Anda memiliki dua opsi:

  1. Anda bergabung. Itu sebenarnya cukup sederhana, dan operasi lokal yang sempurna:

    git checkout b1
    git merge master
    # repeat for b2 and b3
    

    Ini meninggalkan sejarah persis seperti yang terjadi: Anda bercabang dari master, Anda membuat perubahan pada semua cabang, dan akhirnya Anda memasukkan perubahan dari master ke ketiga cabang.

    gitdapat menangani situasi ini dengan sangat baik, ini dirancang untuk penggabungan yang terjadi di semua arah, pada saat yang sama. Anda dapat mempercayainya untuk dapat menyatukan semua utas dengan benar. Ini sama sekali tidak peduli apakah b1penggabungan cabang master, atau mastergabungan b1, komit gabungan terlihat sama saja dengan git. Satu-satunya perbedaan adalah, cabang mana yang menunjuk komit gabungan ini.

  2. Anda rebase. Orang-orang dengan SVN, atau latar belakang yang serupa merasa ini lebih intuitif. Perintahnya analog dengan kasus gabungan:

    git checkout b1
    git rebase master
    # repeat for b2 and b3
    

    Orang-orang menyukai pendekatan ini karena mempertahankan sejarah linier di semua cabang. Namun, sejarah linier ini bohong, dan Anda harus sadar bahwa itu benar. Pertimbangkan grafik komit ini:

    A --- B --- C --- D <-- master
     \
      \-- E --- F --- G <-- b1
    

    Penggabungan menghasilkan sejarah sebenarnya:

    A --- B --- C --- D <-- master
     \                 \
      \-- E --- F --- G +-- H <-- b1
    

    Namun, rebase memberi Anda sejarah ini:

    A --- B --- C --- D <-- master
                       \
                        \-- E' --- F' --- G' <-- b1
    

    Intinya adalah, bahwa komit E', F'dan G'tidak pernah benar-benar ada, dan memiliki kemungkinan pernah diuji. Mereka bahkan tidak dapat dikompilasi. Sebenarnya cukup mudah untuk membuat komitmen yang tidak masuk akal melalui rebase, terutama ketika perubahan masterpenting untuk pengembangan di b1.

    Konsekuensi dari ini mungkin, bahwa Anda tidak bisa membedakan yang mana dari tiga komit E, Fdan Gbenar-benar memperkenalkan kemunduran, mengurangi nilai git bisect.

    Saya tidak mengatakan bahwa Anda tidak boleh menggunakannya git rebase. Ini memiliki kegunaannya. Tetapi setiap kali Anda menggunakannya, Anda harus menyadari fakta bahwa Anda berbohong tentang sejarah. Dan Anda setidaknya harus mengkompilasi menguji komitmen baru.


Saya penggabungan cabang lain sumber (tidak master) dan langkah-langkah tambahan untuk menambah jawaban ini bagus adalah untuk memperbarui pada repo lokal saya sebelum penggabungan (memiliki kode terbaru secara lokal): git checkout <source branch> git pull. Kemudian melanjutkan dengan di atas: git checkout b1...
Rod

3
Sebagai pengguna SVN yang sudah lama, saya lebih suka opsi gabungan daripada rebase: menggunakan kontrol versi apa pun, sangat, sangat penting untuk menyimpan catatan akurat dari perubahan yang Anda buat dan mengapa. Saya dapat melihat daya tarik rebase untuk menyederhanakan sejarah yang tampak, tetapi Anda kemudian harus kembali dan menambahkan komentar komit dari E ', F', G '- dan lebih disukai memiliki rebase secara otomatis ditambahkan ke komentar-komentar itu. Kalau tidak, jika proses build / test / penyebaran-penyebaran rusak pada G 'Anda harus mencari tahu mengapa perubahan itu dilakukan tanpa informasi lengkap.
WillC

13
Sejarah itu bohong
piratemurray

Terima kasih saya menggunakan "git merge any-branch-name" untuk menggabungkan satu kode cabang ke cabang lain. Secara lokal saya dapat menguji kode cabang 1 sementara saya di cabang 2
Priti

1
@blamb Konflik gabungan terjadi dengan keduanya git mergedan git rebase. Tidak ada cara untuk menghindarinya. git rebasememiliki keuntungan untuk memungkinkan Anda menyembunyikan beberapa tahap rebasing (yaitu rebasing cabang yang sama ke beberapa komitmen yang berbeda secara berurutan untuk mengurangi jumlah konflik di setiap tahap). Namun demikian, fakta bahwa rebase berbohong tentang sejarah membuatnya jauh lebih mudah untuk mendapatkan yang baik dalam rebase bertingkat banyak ... Itu sebabnya saya selalu lebih suka penggabungan, bahkan ketika itu berarti saya harus mengacaukan sejarah dengan beberapa komitmen penggabungan. .
cmaster - mengembalikan monica

238

git rebase masteradalah cara yang tepat untuk melakukan ini. Penggabungan akan berarti komit akan dibuat untuk penggabungan, sedangkan rebasing tidak.


52
Bagaimana ketika Anda sudah mendorong ke asal, jika Anda rebase Anda akan menulis ulang sejarah komit dan ini akan bertentangan dengan cabang jauh Anda. Saya pikir rebase hanya boleh digunakan pada tarikan atau ketika Anda belum mendorong ke cabang jauh.
Matt Smith

6
Jika Anda adalah satu-satunya yang bekerja pada cabang jarak jauh, Anda dapat melakukan fitur git push -force asal untuk memperbarui cabang jarak jauh Anda dengan cabang lokal yang telah diubah. stackoverflow.com/questions/8939977/…
stormwild

7
rebase dan gabungkan kedua karya, rebase terbaik untuk cabang pribadi, karena memberikan grafik sejarah yang lebih bersih. jawaban ini adalah yang terbaik
Junchen Liu

5
Perlu lebih jelas tentang pertukaran antara kejelasan (bagus untuk pengguna tunggal atau tim kecil) atau kebenaran berantakan (untuk cabang kode multi-kontributor - diperlukan untuk pemeliharaan (dalam pengalaman saya - YMMV)).
WillC


53

Jika Anda sedang mengerjakan dan mematikan cabang, atau banyak yang telah terjadi di cabang lain saat Anda sedang mengerjakan sesuatu, yang terbaik adalah mengubah cabang Anda menjadi master. Ini membuat sejarah tetap rapi dan membuat banyak hal lebih mudah untuk diikuti.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Catatan:

  • Jangan rebase cabang yang telah Anda kolaborasi dengan orang lain.
  • Anda harus rebase pada cabang yang akan Anda gabungkan yang mungkin tidak selalu menjadi master.

Ada bab tentang rebasing di http://git-scm.com/book/ch3-6.html , dan banyak sumber daya lain di web.


Terima kasih untuk solusi sederhana
Pria jangkung

18

@ cmaster membuat jawaban terinci terbaik. Secara singkat:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Anda seharusnya tidak menulis ulang sejarah cabang alih-alih menyimpannya dalam keadaan aktual untuk referensi di masa mendatang. Sementara bergabung untuk menguasai, itu menciptakan satu komit ekstra tapi itu murah. Komitmen tidak dikenakan biaya.


13

Untuk memperbarui cabang lain seperti (cadangan) dengan salinan cabang utama Anda. Anda dapat mengikuti salah satu cara (rebase atau gabung) ...

  1. Lakukan rebase (tidak akan ada komit tambahan yang dibuat untuk cabang cadangan).
  2. Gabungkan cabang (akan ada komit tambahan secara otomatis ke cabang cadangan).

    Catatan: Rebase tidak lain adalah membuat basis baru (salinan baru)

git checkout backup
git merge master
git push

(Ulangi untuk cabang lain jika ada seperti backup2 & dll ..,)

git checkout backup
git rebase master
git push

(Ulangi untuk cabang lain jika ada seperti backup2 & dll ..,)



1

Ada dua opsi untuk masalah ini.

1) git rebase

2) git bergabung

Hanya berbeda dengan di atas keduanya dalam kasus penggabungan, akan memiliki komit ekstra dalam sejarah

1) cabang checkout git (b1, b2, b3)

2) git rebase asal / master (Dalam kasus konflik diselesaikan secara lokal dengan melakukan git rebase --continue)

3) git push

Atau, opsi git merge juga mirip

1) git checkout "your_branch" (b1, b2, b3)

2) git merge master

3) git push


1

untuk memperbarui cabang Anda dari master:

  git checkout master
  git pull
  git checkout your_branch
  git merge master
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.