Saya telah menggunakan Git sekarang selama beberapa bulan pada proyek dengan satu pengembang lain. Saya memiliki beberapa tahun pengalaman dengan SVN , jadi saya rasa saya membawa banyak bagasi ke hubungan itu.
Saya telah mendengar bahwa Git sangat baik untuk percabangan dan penggabungan, dan sejauh ini, saya hanya tidak melihatnya. Tentu, percabangan itu sederhana, tetapi ketika saya mencoba untuk menggabungkan, semuanya berjalan ke neraka. Sekarang, saya sudah terbiasa dengan itu dari SVN, tetapi bagi saya sepertinya saya baru saja menukar satu sistem versi sub-par dengan yang lain.
Mitra saya memberi tahu saya bahwa masalah saya berasal dari keinginan saya untuk bergabung dengan mau tak mau, dan bahwa saya harus menggunakan rebase daripada bergabung dalam banyak situasi. Sebagai contoh, inilah alur kerja yang dia buat:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
Pada dasarnya, buat cabang fitur, SELALU rebase dari master ke cabang, dan bergabung dari cabang kembali ke master. Penting untuk dicatat adalah bahwa cabang selalu tetap lokal.
Inilah alur kerja yang saya mulai
clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch
Ada dua perbedaan mendasar (saya pikir): Saya selalu menggunakan gabungan alih-alih rebasing, dan saya mendorong cabang fitur saya (dan cabang fitur saya komit) ke repositori jarak jauh.
Alasan saya untuk cabang jarak jauh adalah bahwa saya ingin pekerjaan saya didukung saat saya sedang bekerja. Repositori kami secara otomatis dicadangkan dan dapat dikembalikan jika terjadi kesalahan. Laptop saya tidak, atau tidak menyeluruh. Karena itu, saya benci memiliki kode pada laptop saya yang tidak dicerminkan di tempat lain.
Alasan saya untuk penggabungan bukannya rebase adalah bahwa penggabungan tampaknya menjadi standar dan rebase tampaknya merupakan fitur lanjutan. Perasaan saya adalah bahwa apa yang saya coba lakukan bukanlah pengaturan lanjutan, jadi rebase seharusnya tidak perlu. Saya bahkan membaca dengan seksama buku Pemrograman Pragmatis baru pada Git, dan mereka membahas penggabungan secara luas dan nyaris tidak menyebutkan rebase.
Ngomong-ngomong, saya mengikuti alur kerja saya di cabang baru-baru ini, dan ketika saya mencoba menggabungkannya kembali menjadi master, semuanya pergi ke neraka. Ada banyak konflik dengan hal-hal yang seharusnya tidak penting. Konflik tidak masuk akal bagi saya. Butuh satu hari bagi saya untuk menyelesaikan semuanya, dan akhirnya memuncak dengan paksa ke master jarak jauh, karena master lokal saya memiliki semua konflik diselesaikan, tetapi yang jauh masih tidak bahagia.
Apa alur kerja yang "benar" untuk sesuatu seperti ini? Git seharusnya membuat percabangan dan penggabungan menjadi sangat mudah, dan saya tidak melihatnya.
Perbarui 2011-04-15
Ini sepertinya pertanyaan yang sangat populer, jadi saya pikir saya akan memperbarui dengan pengalaman dua tahun saya sejak saya pertama kali bertanya.
Ternyata alur kerja asli sudah benar, setidaknya dalam kasus kami. Dengan kata lain, inilah yang kami lakukan dan berhasil:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature
Faktanya, alur kerja kami sedikit berbeda, karena kami cenderung melakukan penggabungan squash dan bukan penggabungan mentah. ( Catatan: Ini kontroversial, lihat di bawah. ) Ini memungkinkan kami untuk mengubah seluruh cabang fitur kami menjadi satu komit pada master. Kemudian kami menghapus cabang fitur kami. Ini memungkinkan kami untuk menyusun komit kami secara logis pada master, bahkan jika mereka sedikit berantakan di cabang kami. Jadi, inilah yang kami lakukan:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature
Kontroversi Penggabungan Squash - Seperti yang ditunjukkan beberapa komentator, penggabungan squash akan membuang semua riwayat di cabang fitur Anda. Seperti namanya, itu meremas semua komit menjadi satu. Untuk fitur kecil, ini masuk akal karena mengembunnya menjadi satu paket. Untuk fitur yang lebih besar, itu mungkin bukan ide bagus, terutama jika komitmen individu Anda sudah bersifat atom. Itu benar-benar turun ke preferensi pribadi.
Github dan Bitbucket (lain-lain?) Tarik Permintaan - Jika Anda bertanya-tanya bagaimana merger / rebase berhubungan dengan Tarik Permintaan, saya sarankan mengikuti semua langkah di atas sampai Anda siap untuk bergabung kembali ke master. Alih-alih secara manual bergabung dengan git, Anda hanya menerima PR. Perhatikan bahwa ini tidak akan melakukan penggabungan squash (setidaknya tidak secara default), tetapi non-squash, non-fast-forward adalah konvensi penggabungan yang diterima di komunitas Permintaan Tarik (sejauh yang saya tahu). Secara khusus, ini berfungsi seperti ini:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin
Saya datang untuk mencintai Git dan tidak pernah ingin kembali ke SVN. Jika Anda kesulitan, terus saja dan akhirnya Anda akan melihat cahaya di ujung terowongan.
rebasepengertian
