Kantor saya menginginkan penggabungan cabang tanpa batas sebagai kebijakan; pilihan lain apa yang kita miliki?


119

Kantor saya sedang mencoba mencari tahu bagaimana kami menangani perpecahan dan penggabungan cabang, dan kami telah mengalami masalah besar.

Masalah kami adalah dengan sidebranch jangka panjang - jenis di mana Anda memiliki beberapa orang yang bekerja sidebranch yang terpisah dari master, kami berkembang selama beberapa bulan, dan ketika kami mencapai tonggak sejarah kami menyinkronkan keduanya.

Sekarang, IMHO, cara alami untuk menangani ini adalah, remas sidebranch menjadi komit tunggal. masterterus maju; sebagaimana mestinya - kita tidak secara surut membuang bulan pembangunan paralel ke masterdalam sejarah. Dan jika ada yang membutuhkan resolusi yang lebih baik untuk sejarah sidebranch, ya, tentu saja semuanya masih ada - hanya saja tidak ada master, ada di sidebranch.

Inilah masalahnya: Saya bekerja secara eksklusif dengan baris perintah, tetapi anggota tim saya yang lain menggunakan GUIS. Dan saya telah menemukan GUIS tidak memiliki opsi yang masuk akal untuk menampilkan riwayat dari cabang lain. Jadi, jika Anda mencapai labu komit, mengatakan "perkembangan ini tergencet dari cabang XYZ", itu besar rasa sakit untuk pergi melihat apa yang ada di XYZ.

Pada SourceTree, sejauh yang saya bisa temukan, itu adalah sakit kepala yang sangat besar: Jika Anda aktif master, dan Anda ingin melihat riwayat dari master+devFeature, Anda juga perlu memeriksa master+devFeature(menyentuh setiap file tunggal yang berbeda), atau yang lain gulirlah melalui log yang menampilkan SEMUA cabang repositori Anda secara paralel hingga Anda menemukan tempat yang tepat. Dan semoga beruntung mencari tahu di mana Anda berada di sana.

Rekan satu tim saya, dengan benar, tidak ingin memiliki sejarah pengembangan yang begitu sulit diakses. Jadi mereka ingin ini, sidebranch-development-long yang besar bergabung, selalu dengan komit gabungan. Mereka tidak ingin ada riwayat yang tidak dapat langsung diakses dari cabang utama.

Saya benci ide itu; itu berarti kusut yang tak ada habisnya, sejarah pengembangan paralel. Tetapi saya tidak melihat alternatif apa yang kita miliki. Dan saya cukup bingung; ini tampaknya menghalangi hampir semua yang saya tahu tentang manajemen cabang yang baik, dan itu akan membuat saya frustrasi terus-menerus jika saya tidak dapat menemukan solusi.

Apakah kita punya opsi di sini selain terus-menerus menggabungkan sidebranch menjadi master dengan gabungan-komitmen? Atau, adakah alasan bahwa terus menggunakan komit gabungan tidak seburuk yang saya takutkan?


84
Apakah merekam gabungan sebagai gabungan benar-benar buruk? Saya dapat melihat bahwa memasuki sejarah linier memiliki keuntungan, tetapi saya terkejut bahwa tidak melakukannya bertentangan dengan "hampir semua yang Anda ketahui tentang manajemen cabang yang baik". Apa sebenarnya masalah yang Anda takuti?
IMSoP

65
OK, tapi dalam pikiran saya cabang lama berjalan adalah persis di mana Anda melakukan ingin beberapa visibilitas, sehingga menyalahkan dan membagi tidak hanya mendarat di "perubahan diperkenalkan sebagai bagian dari Big Rewrite 2016". Saya tidak cukup percaya diri untuk memposting sebagai jawaban, tetapi naluri saya adalah bahwa tugas - tugas di dalam fitur cabang yang harus ditekan, sehingga Anda memiliki sejarah singkat proyek yang dapat diakses dari sejarah utama, tanpa harus lihat cabang yatim.
IMSoP

5
Yang sedang berkata, sangat mungkin sehingga pertanyaan berkurang menjadi "Saya mencoba menggunakan git pada tingkat yang lebih tinggi daripada rekan tim saya; bagaimana saya menjaga mereka agar tidak mengacaukannya bagi saya." Yang, cukup adil, saya hanya jujur ​​tidak berharap git log master+bugfixDec10thmenjadi titik
puncaknya

26
"sidebranch jangka panjang - jenis di mana Anda punya beberapa orang yang bekerja sidebranch yang terpisah dari master, kami berkembang selama beberapa bulan, dan ketika kami mencapai tonggak sejarah kami menyinkronkan keduanya." Apakah Anda tidak secara berkala menarik dari master ke cabang samping? Melakukan hal itu setiap (sedikit) yang berkomitmen untuk dikuasai cenderung membuat hidup lebih sederhana dalam banyak kasus.
TafT

4
Apa merge --no-ffyang kamu inginkan? Dengan mastersendirinya Anda memiliki satu komit yang menjelaskan apa yang berubah di cabang, tetapi semua komit masih ada dan diasuh menjadi HEAD.
CAD97

Jawaban:


243

Meskipun saya menggunakan Git di baris perintah - saya harus setuju dengan kolega Anda. Tidak masuk akal untuk memeras perubahan besar menjadi satu komit. Anda kehilangan sejarah seperti itu, tidak hanya membuatnya kurang terlihat.

Titik kendali sumber adalah untuk melacak riwayat semua perubahan. Kapan apa yang berubah mengapa? Untuk itu, setiap komit berisi pointer ke induk, komit, dan metadata seperti pesan komit. Setiap komit menggambarkan status kode sumber dan riwayat lengkap semua perubahan yang mengarah ke status itu. Pengumpul sampah dapat menghapus komit yang tidak dapat dijangkau.

Tindakan seperti rebasing, memetik ceri, atau menekan menghapus atau menulis ulang sejarah. Secara khusus, commit yang dihasilkan tidak lagi merujuk pada commit yang asli. Pertimbangkan ini:

  • Anda menekan beberapa komit dan mencatat dalam pesan komit bahwa sejarah tergencet tersedia dalam komit asli abcd123.
  • Anda menghapus [1] semua cabang atau tag yang menyertakan abcd123 karena digabungkan.
  • Anda membiarkan pengumpul sampah berjalan.

[1]: Beberapa server Git memungkinkan cabang dilindungi dari penghapusan tidak disengaja, tapi saya ragu Anda ingin menyimpan semua cabang fitur Anda untuk selamanya.

Sekarang Anda tidak lagi dapat mencari komit - itu tidak ada.

Merujuk nama cabang dalam pesan komit bahkan lebih buruk, karena nama cabang lokal untuk repo. Apa yang ada master+devFeaturedi checkout lokal Anda mungkin ada doodlediduhdi milik saya. Cabang hanya memindahkan label yang menunjuk ke beberapa objek komit.

Dari semua teknik penulisan ulang sejarah, rebasing adalah yang paling jinak karena itu menduplikasi komitmen lengkap dengan semua sejarah mereka, dan hanya menggantikan komit orang tua.

Bahwa mastersejarah mencakup sejarah lengkap dari semua cabang yang digabungkan ke dalamnya adalah hal yang baik, karena itu mewakili kenyataan. [2] Jika ada pengembangan paralel, itu harus terlihat di log.

[2]: Untuk alasan ini, saya juga lebih suka komit gabungan eksplisit atas sejarah yang linier tapi akhirnya palsu akibat rebasing.

Pada baris perintah, git logberusaha keras untuk menyederhanakan riwayat yang ditampilkan dan menjaga semua komit yang ditampilkan tetap relevan. Anda dapat mengubah penyederhanaan riwayat sesuai kebutuhan Anda. Anda mungkin tergoda untuk menulis alat git log Anda sendiri yang berjalan pada grafik commit, tetapi umumnya tidak mungkin untuk menjawab "apakah komit ini awalnya dilakukan pada cabang ini atau itu?". Induk pertama gabungan komit adalah sebelumnya HEAD, yaitu komit di cabang yang Anda gabungkan . Tapi itu mengasumsikan bahwa Anda tidak melakukan penggabungan terbalik dari master ke cabang fitur, maka master yang diteruskan cepat ke gabungan.

Solusi terbaik untuk cabang jangka panjang yang saya temui adalah mencegah cabang yang baru digabung setelah beberapa bulan. Penggabungan paling mudah bila perubahannya baru dan kecil. Idealnya, Anda akan bergabung setidaknya sekali seminggu. Integrasi berkelanjutan (seperti dalam Pemrograman Ekstrim, bukan seperti dalam "mari kita menyiapkan server Jenkins"), bahkan menyarankan beberapa penggabungan per hari, yaitu tidak mempertahankan cabang fitur yang terpisah tetapi berbagi cabang pengembangan sebagai sebuah tim. Penggabungan sebelum fitur QA akan mensyaratkan bahwa fitur disembunyikan di belakang bendera fitur.

Sebagai imbalannya, integrasi yang sering memungkinkan untuk menemukan masalah potensial jauh lebih awal, dan membantu menjaga arsitektur yang konsisten: perubahan yang jauh dimungkinkan karena perubahan ini dengan cepat dimasukkan dalam semua cabang. Jika perubahan memecah beberapa kode, itu hanya akan merusak beberapa hari, bukan beberapa bulan.

Penulisan ulang riwayat bisa masuk akal untuk proyek yang benar-benar besar ketika ada jutaan baris kode dan ratusan atau ribuan pengembang aktif. Dapat dipertanyakan mengapa proyek besar seperti itu harus menjadi repositori git tunggal daripada dibagi ke dalam perpustakaan yang terpisah, tetapi pada skala itu lebih nyaman jika repo pusat hanya berisi "rilis" dari masing-masing komponen. Misalnya kernel Linux menggunakan squashing untuk menjaga agar sejarah utama dapat dikelola. Beberapa proyek sumber terbuka memerlukan tambalan untuk dikirim melalui email, alih-alih penggabungan git-level.


43
@ Standback Saya tidak peduli apa yang dilakukan pengembang secara lokal ... gunakan komit "wip", komit ekstra untuk setiap kesalahan ketik tetap, .... Tidak apa-apa, lebih baik komit terlalu sering. Idealnya, pengembang membersihkan komit sebelum didorong, seperti menggabungkan semua komit yang hanya memperbaiki beberapa kesalahan ketik. Itu masih merupakan ide yang baik untuk menjaga komit terpisah jika mereka melakukan hal-hal yang berbeda, misalnya satu komit untuk fungsi aktual dan tes terkait, satu lagi untuk kesalahan ketik yang tidak terkait. Tapi begitu komitmen didorong, menulis ulang atau menghapus sejarah lebih banyak masalah daripada nilainya, setidaknya dalam pengalaman saya.
Amon

11
"pada umumnya tidak mungkin untuk menjawab" apakah komit ini awalnya dilakukan pada cabang ini atau itu? "" Saya melihat fakta bahwa "cabang" hanyalah petunjuk untuk melakukan tanpa sejarah nyata sendiri sebagai salah satu kelemahan desain terbesar di git Saya benar-benar ingin dapat menanyakan sistem kontrol versi saya "apa yang ada di cabang x pada tanggal y".
Peter Green

80
Tidak ada yang lebih membuat frustrasi ketika mencoba mengidentifikasi penyebab bug dalam kode menggunakan git bisect, hanya untuk mendapatkannya mencapai 10.000 baris uber-commit dari cabang samping.
tpg2114

2
@Standback IMHO, semakin kecil komit, semakin mudah dibaca dan ramah. Komit yang menyentuh lebih dari beberapa poin tidak mungkin untuk dipahami pada tampilan pertama, jadi Anda cukup mengambil deskripsi pada nilai nominal. Itu keterbacaan deskripsi (mis. "Fitur yang diimplementasikan X"), bukan komit (kode) itu sendiri. Saya lebih suka memiliki 1.000 komitmen satu huruf seperti "mengubah http menjadi https"
:)

2
cherry-pick tidak menulis ulang atau menghapus riwayat. itu hanya menciptakan komit baru yang mereplikasi perubahan dari komit yang ada
Sarge Borsch

110

Saya suka jawaban Amon , tetapi saya merasa satu bagian kecil membutuhkan lebih banyak penekanan: Anda dapat dengan mudah menyederhanakan riwayat sambil melihat log untuk memenuhi kebutuhan Anda, tetapi yang lain tidak dapat menambahkan riwayat saat melihat log untuk memenuhi kebutuhan mereka. Inilah sebabnya mengapa menjaga sejarah saat itu terjadi lebih disukai.

Berikut ini contoh dari salah satu repositori kami. Kami menggunakan model tarik-permintaan, sehingga setiap fitur tampak seperti cabang Anda yang sudah berjalan lama dalam sejarah, meskipun biasanya hanya berjalan seminggu atau kurang. Pengembang individu kadang-kadang memilih untuk memeras riwayat mereka sebelum bergabung, tetapi kami sering memasangkan fitur, jadi itu relatif tidak biasa. Inilah beberapa komitmen teratas gitk, gui yang dibundel dengan git:

tampilan standar gitk

Ya, agak kusut, tapi kami juga suka karena kami bisa melihat dengan tepat siapa yang berubah pada jam berapa. Secara akurat mencerminkan sejarah perkembangan kami. Jika kita ingin melihat tampilan tingkat yang lebih tinggi, satu permintaan tarik bergabung sekaligus, kita dapat melihat tampilan berikut, yang setara dengan git log --first-parentperintah:

tampilan gitk dengan --first-parent

git logmemiliki lebih banyak opsi yang dirancang untuk memberi Anda pandangan yang Anda inginkan. gitkdapat mengambil git logargumen sewenang-wenang apa pun untuk membangun tampilan grafis. Saya yakin GUI lain memiliki kemampuan serupa. Baca dokumen dan pelajari cara menggunakannya dengan benar, alih-alih menegakkan git logpandangan pilihan Anda pada semua orang pada waktu penggabungan.


24
Saya tidak terbiasa dengan opsi ini! Ini adalah bantuan besar bagi saya, dan sepertinya belajar lebih banyak opsi log akan membuat saya hidup dengan lebih mudah.
Standback

25
+1 untuk "Anda dapat dengan mudah menyederhanakan riwayat saat melihat log untuk memenuhi kebutuhan Anda, tetapi orang lain tidak dapat menambahkan riwayat saat melihat log untuk memenuhi kebutuhan mereka." Menulis ulang sejarah selalu dipertanyakan. Jika Anda pikir penting untuk mencatat pada saat komitmen maka itu penting. Bahkan jika Anda menemukan itu salah atau melakukannya lagi itu adalah bagian dari sejarah. Beberapa kesalahan hanya masuk akal ketika Anda dapat melihat dalam kesalahan bahwa baris ini adalah sisa dari penulisan ulang nanti. Ketika kesalahan dilipat dengan sisa epik Anda tidak dapat meninjau mengapa semuanya berakhir seperti itu.
TafT

@Standback Terkait, satu hal yang membantu mempertahankan struktur ini bagi saya, adalah menggunakan merge --no-ff- jangan gunakan penggabungan maju cepat, alih-alih selalu buat komit penggabungan sehingga --first-parentmemiliki sesuatu untuk dikerjakan
Izkata

34

Masalah kami adalah dengan sidebranch jangka panjang - jenis di mana Anda memiliki beberapa orang yang bekerja sidebranch yang terpisah dari master, kami berkembang selama beberapa bulan, dan ketika kami mencapai tonggak sejarah kami menyinkronkan keduanya.

Pikiran pertama saya adalah - bahkan tidak melakukan ini kecuali benar-benar diperlukan. Penggabungan Anda terkadang harus menantang. Jaga agar cabang tetap independen dan berumur pendek. Ini pertanda bahwa Anda perlu memecah cerita menjadi potongan implementasi yang lebih kecil.

Jika Anda harus melakukan ini, maka dimungkinkan untuk menggabungkan git dengan opsi --no-ff sehingga sejarah disimpan berbeda di cabang mereka sendiri. Komit masih akan muncul dalam riwayat gabungan tetapi juga dapat dilihat secara terpisah pada cabang fitur sehingga setidaknya mungkin untuk menentukan jalur pengembangan mana yang menjadi bagiannya.

Saya harus mengakui ketika saya pertama kali mulai menggunakan git, saya merasa agak aneh bahwa cabang berkomitmen dalam sejarah yang sama dengan cabang utama setelah penggabungan. Agak membingungkan karena sepertinya komitmen itu tidak termasuk dalam sejarah itu. Tetapi dalam prakteknya, itu bukan sesuatu yang sangat menyakitkan sekali, jika seseorang menganggap bahwa cabang integrasi hanya itu - tujuannya adalah untuk menggabungkan cabang fitur. Di tim kami, kami tidak squash, dan kami sering menggabungkan komitmen. Kami menggunakan --no-ff setiap saat untuk memastikan bahwa mudah untuk melihat riwayat yang tepat dari fitur apa pun yang ingin kami selidiki.


3
Saya setuju sepenuhnya; semua orang lebih suka dekat dengan tuannya. Tapi itu masalah yang berbeda, yang jauh lebih besar dan jauh lebih sedikit di bawah pengaruh saya sendiri yang rendah hati :-P
Standback

2
+1 untukgit merge --no-ff
0xcaff

1
Juga memberi +1 untuk git merge --no-ff. Jika Anda menggunakan gitflow, ini menjadi default.
David Hammen

10

Biarkan saya menjawab poin Anda secara langsung dan jelas:

Masalah kami adalah dengan sidebranch jangka panjang - jenis di mana Anda memiliki beberapa orang yang bekerja sidebranch yang terpisah dari master, kami berkembang selama beberapa bulan, dan ketika kami mencapai tonggak sejarah kami menyinkronkan keduanya.

Anda biasanya tidak ingin membiarkan cabang Anda tidak disinkronkan selama berbulan-bulan.

Cabang fitur Anda telah bercabang dari sesuatu tergantung pada alur kerja Anda; sebut saja itu masterdemi kesederhanaan. Sekarang, kapan pun Anda berkomitmen untuk menguasainya, Anda bisa dan harus melakukannya git checkout long_running_feature ; git rebase master. Ini berarti bahwa cabang Anda, menurut desain, selalu sinkron.

git rebasejuga hal yang benar untuk dilakukan di sini. Ini bukan hack atau sesuatu yang aneh atau berbahaya, tetapi sepenuhnya alami. Anda kehilangan sedikit informasi, yang merupakan "ulang tahun" dari cabang fitur, tetapi hanya itu. Jika beberapa orang menganggap itu penting, itu bisa diberikan dengan menyimpannya di tempat lain (dalam sistem tiket Anda, atau, jika kebutuhannya besar, dalam git tag...).

Sekarang, IMHO, cara alami untuk menangani ini adalah, remas sidebranch menjadi komit tunggal.

Tidak, Anda sama sekali tidak ingin itu, Anda ingin komit gabungan. Komit gabungan juga merupakan "komit tunggal". Entah bagaimana, itu tidak memasukkan semua cabang individu melakukan "ke" master. Ini adalah komitmen tunggal dengan dua orang tua - masterkepala dan kepala cabang pada saat penggabungan.

Pastikan untuk menentukan --no-ffopsi, tentu saja; menggabungkan tanpa --no-ffharus, dalam skenario Anda, dilarang keras. Sayangnya, --no-ffini bukan default; tapi saya yakin ada opsi yang bisa Anda atur yang membuatnya begitu. Lihat git help mergeapa yang --no-ffdilakukannya (singkatnya: itu mengaktifkan perilaku yang saya jelaskan di paragraf sebelumnya), itu sangat penting.

kita tidak secara surut membuang bulan pembangunan paralel ke dalam sejarah master.

Sama sekali tidak - Anda tidak pernah membuang sesuatu "ke dalam sejarah" dari beberapa cabang, terutama dengan komit gabungan.

Dan jika ada yang membutuhkan resolusi yang lebih baik untuk sejarah sidebranch, yah, tentu saja semuanya masih ada - hanya saja tidak di master, itu di sidebranch.

Dengan komit gabungan, itu masih ada. Bukan di master, tapi di sidebranch, jelas terlihat sebagai salah satu orang tua dari gabungan melakukan, dan disimpan untuk selamanya, sebagaimana mestinya.

Lihat apa yang saya lakukan? Semua hal yang Anda jelaskan untuk komit squash Anda ada di sana dengan --no-ffkomit gabungan .

Inilah masalahnya: Saya bekerja secara eksklusif dengan baris perintah, tetapi anggota tim saya yang lain menggunakan GUIS.

(Komentar samping: Saya hampir secara eksklusif bekerja dengan baris perintah juga (well, itu bohong, saya biasanya menggunakan emacs magit, tapi itu cerita lain - jika saya tidak berada di tempat yang nyaman dengan pengaturan emacs pribadi saya, saya lebih suka perintah baris juga). Tapi tolong jangan kebaikan dan mencoba setidaknya git guisekali. Hal ini sangat jauh lebih efisien untuk memilih garis, bakhil dll untuk menambahkan / kehancuran menambahkan.)

Dan saya telah menemukan GUIS tidak memiliki opsi yang masuk akal untuk menampilkan riwayat dari cabang lain.

Itu karena apa yang Anda coba lakukan benar-benar bertentangan dengan semangat git. gitdibangun dari inti pada "grafik asiklik terarah", yang berarti, banyak informasi ada dalam hubungan orangtua-anak-komit. Dan, untuk penggabungan, itu berarti penggabungan yang benar dilakukan dengan dua orang tua dan satu anak. GUI kolega Anda akan baik-baik saja segera setelah Anda menggunakan no-ffkomit gabungan.

Jadi, jika Anda mencapai komit squash, mengatakan "pengembangan ini tergencet dari cabang XYZ", sangat merepotkan untuk melihat apa yang ada di XYZ.

Ya, tapi itu bukan masalah GUI, tetapi dari squash commit. Menggunakan squash berarti Anda membiarkan kepala cabang fitur menjuntai, dan membuat komitmen baru master. Ini memecah struktur pada dua level, menciptakan kekacauan besar.

Jadi mereka ingin ini, sidebranch-development-long yang besar bergabung, selalu dengan komit gabungan.

Dan mereka benar sekali. Tapi mereka tidak "bergabung dalam ", mereka hanya bergabung. Penggabungan adalah hal yang benar-benar seimbang, tidak memiliki sisi yang disukai yang digabungkan "ke" yang lain ( git checkout A ; git merge Bpersis sama git checkout B ; git merge Akecuali kecuali untuk perbedaan visual kecil seperti cabang yang ditukar di git logdll.).

Mereka tidak ingin ada riwayat yang tidak dapat langsung diakses dari cabang utama.

Yang sepenuhnya benar. Pada saat tidak ada fitur yang tidak dihapus, Anda akan memiliki satu cabang masterdengan sejarah kaya yang merangkum semua baris komit fitur yang pernah ada, kembali ke git initkomit sejak awal waktu (perhatikan bahwa saya secara khusus menghindari penggunaan istilah " cabang "di bagian akhir paragraf itu karena sejarah pada waktu itu bukan" cabang "lagi, walaupun grafik komit akan cukup bercabang).

Saya benci ide itu;

Maka Anda sedikit kesakitan, karena Anda bekerja melawan alat yang Anda gunakan. The gitPendekatan ini sangat elegan dan kuat, terutama di percabangan / daerah penggabungan; jika Anda melakukannya dengan benar (seperti yang disinggung di atas, terutama dengan --no-ff) itu adalah dengan lompatan dan lebih unggul untuk pendekatan lain (misalnya, kekacauan subversi memiliki struktur direktori paralel untuk cabang).

itu berarti kusut yang tak ada habisnya, sejarah pengembangan paralel.

Tak berujung, paralel - ya.

Tidak dapat dinavigasi, kusut - tidak.

Tetapi saya tidak melihat alternatif apa yang kita miliki.

Mengapa tidak bekerja seperti yang dilakukan oleh penemu git, kolega Anda dan seluruh dunia, setiap hari?

Apakah kita punya opsi di sini selain terus-menerus menggabungkan sidebranch menjadi master dengan gabungan-komitmen? Atau, adakah alasan bahwa terus menggunakan komit gabungan tidak seburuk yang saya takutkan?

Tidak ada pilihan lain; tidak seburuk itu.


10

Memencet sidebranch jangka panjang akan membuat Anda kehilangan banyak informasi.

Apa yang akan saya lakukan adalah mencoba mengubah master menjadi sidebranch jangka panjang sebelum menggabungkan sidebranch menjadi master . Dengan begitu Anda menjaga setiap komit tetap ada, sambil membuat sejarah komit linier dan lebih mudah dipahami.

Jika saya tidak bisa melakukan itu dengan mudah di setiap komit, saya akan membiarkannya non-linear , agar konteks pengembangan tetap jelas. Menurut pendapat saya, jika saya memiliki penggabungan bermasalah selama rebase master ke sidebranche, itu berarti non-linearitas memiliki signifikansi dunia nyata. Itu berarti akan lebih mudah untuk memahami apa yang terjadi seandainya saya perlu menggali sejarah. Saya juga mendapatkan manfaat langsung karena tidak harus melakukan rebase.


: + untuk menyebutkan rebase. Terlepas dari apakah itu pendekatan terbaik di sini (saya pribadi belum memiliki pengalaman hebat dengannya, meskipun saya belum sering menggunakannya), itu tampaknya merupakan hal terdekat dengan apa yang tampaknya diinginkan OP - khususnya, sebuah kompromi antara dump sejarah out-of-order dan benar-benar menyembunyikan sejarah itu.
Kyle Strand

1

Secara pribadi saya lebih suka melakukan pengembangan saya dalam garpu, kemudian menarik permintaan untuk bergabung ke repositori utama.

Itu berarti bahwa jika saya ingin mengubah perubahan saya di atas master, atau menekan beberapa komitmen WIP, saya benar-benar dapat melakukannya. Atau saya bisa meminta agar seluruh sejarah saya digabungkan juga.

Yang ingin saya lakukan adalah melakukan pengembangan pada cabang tetapi sering rebase terhadap master / dev. Dengan begitu saya mendapatkan perubahan terbaru dari master tanpa harus melakukan banyak merger ke cabang saya , atau harus berurusan dengan banyak konflik merger saat saatnya untuk bergabung menjadi master.

Untuk secara eksplisit menjawab pertanyaan Anda:

Apakah kita punya opsi di sini selain terus-menerus menggabungkan sidebranch menjadi master dengan gabungan-komitmen?

Ya - Anda bisa menggabungkan mereka sekali per cabang (ketika fitur atau perbaikannya "lengkap") atau jika Anda tidak suka memiliki gabungan melakukan dalam sejarah Anda, Anda bisa melakukan penggabungan maju cepat pada master setelah melakukan rebase akhir.


3
Maaf - saya melakukan hal yang sama, tetapi saya tidak melihat bagaimana ini menjawab pertanyaan: - /
Standback

2
Menambahkan jawaban eksplisit untuk pertanyaan Anda.
Wayne Werner

Jadi, itu bagus untuk komitmen saya sendiri, tetapi saya (dan tim saya) akan berurusan dengan pekerjaan semua orang . Membersihkan riwayat saya sendiri itu mudah; bekerja dalam sejarah dev yang berantakan adalah masalah di sini.
Standback

Maksudmu kamu ingin meminta pengembang lain untuk ... apa? Tidak rebase dan hanya squash on merge? Atau apakah Anda hanya memposting pertanyaan ini untuk mengeluh tentang kurangnya rekan kerja Anda?
Wayne Werner

1
rebasing secara teratur tidak berguna jika beberapa pengembang bekerja pada cabang fitur itu.
Paŭlo Ebermann

-1

Kontrol revisi adalah sampah masuk sampah.

Masalahnya adalah pekerjaan dalam proses pada cabang fitur dapat berisi banyak "mari kita coba ini ... tidak ada yang tidak bekerja, mari kita ganti dengan itu" dan semua komitmen kecuali yang terakhir "yang" baru saja berakhir sampai mencemari sejarah sia-sia.

Pada akhirnya, sejarah harus disimpan (sebagian mungkin bermanfaat di masa depan), tetapi hanya "salinan bersih" yang harus digabungkan.

Dengan Git, ini dapat dilakukan dengan melakukan bercabang pada cabang fitur terlebih dahulu (untuk menyimpan semua sejarah), kemudian (secara interaktif) memundurkan cabang dari cabang fitur dari master dan kemudian menggabungkan cabang rebased.


1
Hanya untuk mengklarifikasi: apa yang Anda katakan adalah menulis ulang sejarah pada (salinan) cabang fitur, jadi ada sejarah singkat yang bersih - menghilangkan semua bolak-balik dari pengembangan awal. Dan kemudian, menggabungkan cabang yang ditulis ulang menjadi master lebih sederhana dan lebih bersih. Apakah saya mengerti Anda dengan benar?
Standback

1
Iya. Dan ketika Anda bergabung menjadi master, itu hanya akan menjadi maju cepat (dengan asumsi Anda baru saja rebared sebelum bergabung).
DepressedDaniel

Tetapi bagaimana sejarah ini kemudian disimpan? Apakah Anda membiarkan cabang fitur asli berbaring?
Paŭlo Ebermann

@ PaŭloEbermann Bingo.
DepressedDaniel

Seperti yang dikatakan orang lain dalam komentar: cabang hanyalah penunjuk ke grafik sejarah git, dan mereka lokal. Apa yang dinamai foodalam satu repo mungkin dinamai barberbeda. Dan itu dimaksudkan untuk sementara: Anda tidak ingin mengacaukan repo Anda dengan ribuan cabang fitur yang perlu dijaga agar tetap hidup agar tidak kehilangan riwayat. Dan Anda perlu menyimpan cabang-cabang itu untuk menjaga sejarah referensi, karena gitpada akhirnya akan menghapus komit yang tidak dapat dijangkau oleh cabang lagi.
cmaster
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.