"Git pull" atau "git merge" antara cabang master dan development

243

Saya memiliki mastercabang dan developcabang untuk mengerjakan beberapa perubahan. Saya perlu menggabungkan perubahan dari mastermenjadi develop, tetapi pada akhirnya akan menggabungkan semuanya dari developmenjadi master. Saya memiliki dua alur kerja yang berbeda dalam pikiran:

git pull origin mastermenjadi developcabang
git merge mastermenjadi developcabang

Mana cara terbaik untuk melakukan ini, dan mengapa?

git workflow

— Carson
sumber

18

Bacaan yang disarankan: nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Hati-hati dengan rebase. Jika Anda berbagi cabang pengembangan dengan siapa pun, rebase dapat mengacaukan banyak hal. Rebase hanya baik untuk cabang lokal Anda sendiri.

Aturan praktis, jika Anda telah mendorong cabang ke asal, jangan gunakan rebase. Sebagai gantinya, gunakan gabungan.

— Eric Leads
sumber

Namun apakah aman untuk rebase dan menggunakan git push origin rebasedBranch --forcerepo pribadi? Satu-satunya pengguna adalah saya sendiri.

— k0pernikus

Ya, jika Anda satu-satunya pengguna, tentu saja aman. Saya menggunakan push git - memaksa sepanjang waktu ketika saya adalah satu-satunya pengguna. :)

— Tyler Rick

3

Saya mengulangi peringatan Eric. Meskipun, tidak apa-apa untuk rebase cabang jarak jauh Anda sendiri juga. Bermain-main dengan rebase dan gabung dan Anda akan memahami pro dan kontra dari masing-masing dan belajar kapan menggunakannya.

— Ian Lotinsky

Artikel bagus tentang penggunaan rebase, bahkan penggabungan setelah menyelesaikan konflik: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky tautan Anda tidak mengarah ke artikel tentang rebase. Kesimpulan, tetapi apakah Anda masih memiliki tautan yang benar? :)

— Daniel Serodio

347

Alur kerja ini paling cocok untuk saya:

git checkout -b develop

... buat beberapa perubahan ...

... pemberitahuan master telah diperbarui ...

... komit perubahan untuk mengembangkan ...

git checkout master
git pull

... bawa perubahan itu kembali ke pengembangan ...

git checkout develop
git rebase master

... buat beberapa perubahan lagi ...

... berkomitmen untuk mengembangkan ...

... menggabungkan mereka menjadi tuan ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
sumber

2

Ini adalah cara saya bekerja juga, dan saya menemukan itu berfungsi dengan baik. Ada satu hal yang tidak saya lakukan, dan itu git pulltepat sebelum final git merge develop. Apa tujuan dari itu?

— crdx

Setelah ... master pemberitahuan telah diperbarui ... bagian, tidakkah master checkout menghapus perubahan lokal Anda jika Anda tidak melakukan itu?

— a1an

1

@ a1an Tidak, tetapi jika Anda tidak mengkomitnya maka perubahan akan berpindah ke cabang master dan git tidak akan membiarkan Anda menarik sampai mereka berkomitmen.

— elemjay19

5

@crdx Kemungkinannya adalah cabang lain digabungkan ke master jarak jauh sebelum Anda menggabungkan cabang Anda ke master lokal Anda. Anda menarik dan membawa perubahan master jarak jauh ke salinan master lokal Anda. Ini adalah bagaimana saya memahaminya.

— Tarun

12

git pull --rebase origin masterpada cabang pengembangan Anda sedikit lebih cepat.

— Nathan Lilienthal

24

Pendekatan terbaik untuk hal semacam ini mungkin git rebase. Ini memungkinkan Anda untuk menarik perubahan dari master ke cabang pengembangan Anda, tetapi meninggalkan semua pekerjaan pengembangan Anda "di atas" (nanti di log komit) barang-barang dari master. Ketika pekerjaan baru Anda selesai, penggabungan kembali ke master sangat mudah.

— divegeek
sumber

10

Saran yang bagus, dengan asumsi developtidak dibagikan kepada orang lain.

— Karl Bielefeldt

1

@KarlBielefeldt Jika develop dibagikan dengan kontributor lain, bagaimana kami memperbarui developketika beberapa hotfix didorong langsung ke master? Haruskah kita melakukan penggabungan, yaitu git checkout master && git pull --rebase && git checkout develop && git merge master? Saya meninggalkan komentar pada jawaban tertinggi di atas, yang juga merinci kekhawatiran ini.

— modulitos

5

Jika Anda tidak berbagi pengembangan cabang dengan siapa pun, maka saya hanya akan rebase setiap kali master diperbarui, dengan cara itu Anda tidak akan memiliki gabungan melakukan seluruh sejarah Anda begitu Anda akan bergabung mengembangkan kembali menjadi master. Alur kerja dalam hal ini adalah sebagai berikut:

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

Langkah-langkah di atas akan memastikan bahwa cabang pengembangan Anda akan selalu di atas perubahan terbaru dari cabang utama. Setelah selesai dengan mengembangkan cabang dan diubah kembali ke perubahan terbaru pada master, Anda bisa menggabungkannya kembali:

> git checkout -b master
> git merge develop
> git branch -d develop

— KiRPiCH
sumber

1

Aturan praktis saya adalah:

rebaseuntuk cabang dengan nama yang sama , mergejika tidak.

contoh untuk nama yang sama adalah master, origin/masterdan otherRemote/master.

jika develophanya ada di repositori lokal, dan selalu didasarkan pada origin/masterkomit baru-baru ini , Anda harus memanggilnya master, dan bekerja di sana secara langsung. itu menyederhanakan hidup Anda, dan menyajikan hal-hal sebagaimana adanya: Anda langsung berkembang di mastercabang.

jika developdibagikan, itu tidak boleh di rebooting master, hanya digabung kembali dengannya --no-ff. Anda sedang mengembangkan develop. masterdan developmemiliki nama yang berbeda, karena kami ingin mereka menjadi hal yang berbeda, dan tetap terpisah. jangan membuat mereka sama dengan rebase.

— hoijui
sumber