Pengembang baru tidak dapat mengikuti penggabungan cabang

223

Saya adalah pengembang baru - ini adalah posisi pemrograman pertama saya.

Masalah saya adalah ini: Kami menggunakan git- Saya memotong cabang dari developcabang kami , lalu saya mulai mengerjakan tugas kecil yang telah saya tugaskan. Ini sangat lambat, karena saya tidak berpengalaman. Pada saat saya siap untuk menggabungkan cabang saya kembali ke developyang lain telah membuat begitu banyak perubahan yang menyelesaikan konflik sangat besar (sebenarnya tampaknya lebih mudah untuk membatalkan pekerjaan saya dan memulai kembali pada tugas, yang tentu saja bukan solusi yang berkelanjutan ).

Bagaimana saya mengatasi ini? Apakah ada taktik yang bisa saya gunakan selain 'lebih baik dalam pengkodean'? Saya bermaksud untuk membicarakan hal ini dengan penyelia saya minggu depan.

git  software  branching  merging 
— bunga aster
sumber
165
Anda tidak perlu hanya menggabungkan cabang Anda menjadi pengembangan hanya ketika Anda selesai. Anda dapat menggabungkan pengembangan ke cabang fitur Anda secara bertahap kapan pun Anda mau, untuk membuat penggabungan akhir lebih kecil.
— DavidB
16
Pastikan Anda melakukan proses penggabungan dengan benar. Hanya file Anda yang akan terpengaruh dan hanya perubahan Anda yang harus diterapkan ke cabang dev. Jika Anda mendapatkan konflik acak, kemungkinan Anda melakukan kesalahan gabungan atau orang lain mengacaukan urutan revisi. Ini adalah kesempatan bagus untuk mendidik diri sendiri dan mungkin orang lain dalam menggabungkan hak. Beberapa orang mengalami kesulitan memahami perubahan itu, bukan file yang sedang digabungkan. Jadi revisi pemesanan yang tidak sinkron akan menyebabkan konflik pada file yang tidak pernah Anda sentuh.
16
Pastikan juga editor Anda diatur dengan benar. Kadang-kadang editor "memperbaiki" tab dan spasi sehingga ketika Anda mengedit file, dan mencoba untuk melakukan kembali, itu mengubah seluruh file. Anda harus memastikan sebelum melakukan bahwa hanya perubahan Anda yang dilakukan ke cabang dan perbaiki editor Anda.
32
Ada satu hal aneh di sini "Saya mulai mengerjakan tugas kecil" dan banyak konflik gabungan biasanya tidak cocok. Saya baru saja menggabungkan cabang pembaruan besar 2 minggu ke dalam pengembangan eksperimental dan kami memiliki 10 (!) Konflik yang tidak dapat diselesaikan secara otomatis. Anda tidak mendapatkan banyak konflik kecuali tugas Anda adalah "mengubah nama variabel di semua file". Bukan untuk tugas MINOR.
— TomTom
50
Wajib xkcd: xkcd.com/1597
— ED

Jawaban:

5

Anda mendapatkan gabungan konflik jika perubahan yang Anda lakukan di cabang Anda dekat dengan perubahan yang dilakukan rekan Anda di developcabang sementara itu, yaitu, jika Anda dan rekan Anda mengubah baris kode yang sama atau baris yang berdekatan di file yang sama.

Jadi untuk mengurangi kemungkinan menggabungkan konflik, Anda dapat mencoba menggabungkan lebih awal sehingga kolega Anda mengubah lebih sedikit jalur sementara, atau Anda dapat mencoba mengubah lebih sedikit garis sendiri.

Untuk mengubah lebih sedikit garis sendiri, pastikan untuk hanya membuat perubahan terkait dengan tugas Anda.

Jika Anda perlu bereksperimen dengan berbagai cara untuk mencapai tujuan Anda, mungkin beberapa eksperimen Anda mengubah garis yang tidak perlu diubah? Batalkan perubahan ini sebelum bergabung.

Ada juga beberapa perintah Git yang dapat membantu Anda mengubah sesedikit mungkin baris:

  • git diffdan git diff --stageduntuk melihat baris mana yang Anda ubah.
  • git add -p untuk hanya menambahkan beberapa perubahan Anda dalam file.
  • git commit --amenddan git rebase -iuntuk mengubah komit yang sudah Anda buat di cabang fitur lokal Anda sebelum mendorongnya ke repositori Git lainnya.

(Mengubah sebagai beberapa baris mungkin juga dapat membuat lebih mudah untuk meninjau pekerjaan Anda atau menggunakan alat-alat yang bekerja pada perbedaan antara melakukan seperti git cherry-pick, git rebase, git bisect, dan git blame.)

Tetapi bahkan jika Anda mengurangi kemungkinan menggabungkan konflik, Anda masih akan sering mengalami konflik menggabungkan. Jadi jangan takut pada mereka, tetapi belajar bagaimana menyelesaikan konflik.

— Toxaris
sumber
1
Juga sebelum penggabungan, a git fetchdan git diff origin/developakan menampilkan pratinjau gabungan Anda (semacam). Memberi Anda kesempatan untuk membersihkan perubahan Anda sebelum Anda mendapatkan banyak konflik yang tidak berguna.
— Maks
288

Saya menganggap Anda menggunakan git. Jika demikian, manfaatkan git rebase -i( -isarana interaktif). Jadikan itu tugas harian (bahkan lebih sering, jika perlu) untuk rebase cabang Anda terhadap cabang berkembang. Ini membawa perubahan secara bertahap setiap hari (setidaknya) untuk menjaga agar cabang fitur Anda tetap terbarui. Jika ada konflik selama rebase harian Anda, Anda perlu berbicara dengan tim Anda tentang siapa yang mengerjakan apa.

Jika Anda menjalankannya setiap hari, Anda mungkin tidak akan membutuhkan bagian interaktifnya. Biarkan saja melakukan hal itu.

Saya adalah pengembang yang cukup berpengalaman, dan masih butuh sedikit waktu untuk mempercepat proyek baru. Dalam kasus Anda, sepertinya Anda memiliki beberapa orang yang mengerjakan proyek yang sama secara bersamaan, jadi itu adalah proyek yang sangat besar, atau proyek baru yang berkembang dengan cepat. Dalam kedua kasus itu, jangan khawatir jika Anda membutuhkan beberapa bulan untuk masuk ke arus. Jika saya berganti proyek selama 2 atau 3 minggu dan kemudian beralih kembali, saya perlu beberapa jam (atau bahkan satu atau dua hari) untuk sepenuhnya "kembali ke" proyek yang saya tulis 100% sendiri!

Singkatnya, jangan khawatir tentang menjadi lambat saat ini. Cara untuk menjadi lebih baik adalah terus berlatih. Jangan takut untuk bertanya kepada pengembang lain tentang aspek proyek yang tidak Anda mengerti.

SUNTING:

Atau gunakan merge. Itu juga pilihan. Jadi, di atas akan menjadi: "menggunakan git rebase -i( -isarana interaktif) atau git merge". Mengenai yang mana yang akan digunakan, bicarakan dengan anggota tim Anda yang lain. Mereka mungkin (atau mungkin tidak) memiliki preferensi yang kuat. Jelas beberapa orang memang memiliki preferensi yang kuat.

— Jacob Robbins
sumber
22
Saya kira ini adalah jawaban yang benar, tetapi, IMO, hanyalah contoh lain dari desain dan terminologi Git yang buruk. Apa yang Anda "rebasing"? Bukankah ini disebut "pembaruan" atau "checkout" atau "gabung" atau semacamnya ??? (Jawaban di bawah ini menganjurkan "mengambil") Apa gunanya kontrol kode sumber jika setiap hari Anda dipaksa untuk memperbarui ???
— user949300
95
Itu tidak memperbarui atau memeriksa sekalipun. Ini mengambil apa pun yang secara eksklusif ada di cabang Anda, dan menambahkan perubahan Anda seolah-olah Anda baru saja membuatnya di cabang lain. Yakni perubahan Anda sekarang "berdasarkan" cabang lainnya. Selain itu, tidak ada sistem kontrol sumber magis yang mengetahui kode Anda dan bisa tahu cara menggabungkan perubahan ketika banyak orang memodifikasi file yang sama. Anda memperbarui setiap hari untuk menjaga konflik tetap kecil dan dapat dikelola, dan perubahannya segar di benak semua orang sehingga mereka tahu cara menanganinya.
— Vectorjohn
54
@ user949300 rebasing berbeda dari penggabungan, jauh lebih bernuansa dan membutuhkan pemahaman yang lebih baik tentang Git daripada alur kerja penggabungan yang sederhana. Itu sebabnya saya tidak pernah merekomendasikan alur kerja yang melibatkan rebasing ke pemula Git, karena itu mengarah pada asumsi bahwa rebasing adalah satu-satunya / cara default untuk memperbarui cabang dan menyebabkan banyak jebakan dan rasa sakit yang tidak perlu. Dalam kasus ini, penggabungan akan menyelesaikan masalah dengan cara yang sama dan tidak akan menyelesaikan masalah penggabungan konflik di dua cabang fitur paralel yang sudah berjalan lama.
— Semut P
14
@ user949300 git pullyang hanya kombinasi dari git fetchdan git merge(atau Anda dapat menambahkan --rebaseuntuk melakukan rebase bukan penggabungan). Dengan asumsi Anda hanya sekitar satu hari di belakang, maka pada LAN ini kemungkinan akan selesai dalam waktu kurang dari detik, mungkin butuh beberapa detik melalui internet. Bahkan melalui internet dan dengan konflik penggabungan kecil, Anda biasanya dapat terkini dan digabungkan dengan bersih dalam waktu kurang dari satu menit. Menghabiskan penyebaran lima menit sepanjang minggu jauh lebih baik daripada menghabiskan satu jam di akhir minggu untuk menangani konflik gnarly merger.
— Derek Elkins
66
Tidak ada suara positif dari saya karena jawaban ini sepenuhnya terpusat pada rebasing. Rebasing bisa menjadi alat yang bermanfaat, tetapi tidak boleh digunakan tanpa berpikir. Untuk memperbarui hari ke hari, lebih baik bergabung. Mengapa? Karena setiap rebase adalah dusta . Anda menceritakan sejarah dengan cara yang tidak pernah terjadi. Ini benar-benar dapat mengacaukan alat-alat perkasa seperti git bisect: Benda-benda yang dirubah bahkan tidak dapat dikompilasi, jadi git bisecttidak ada gunanya pada komitmen yang dihasilkan rusak. @maaartinus: Saya, lebih suka, sejarah sejati daripada sejarah linier. Jika Anda rebase, Anda benar-benar harus memeriksa setiap komit baru untuk kewarasan untuk menghindari kebohongan berbahaya.
— cmaster
131

Ini mungkin merupakan tanda rekayasa perangkat lunak yang buruk di pihak perusahaan. Terlalu banyak ketergantungan antar, masalah yang berbeda dengan fitur yang tumpang tindih, berusaha untuk mengatasi masalah dalam urutan yang salah, dll. Dapat menyebabkan situasi yang Anda gambarkan. Saya sarankan secara teratur bergabung developke cabang Anda selama pengembangan

— Ivan Anatolievich
sumber
9
Ini mengkodekan 101 hal seperti yang Anda sebutkan. Belum tentu refleksi akurat pada karyawan baru.
— Pak Positif
2
@Ivan Anatolievich OP mengatakan bahwa mereka bercabang dari pengembangan, bukan master, FYI
— Matthew FitzGerald-Chamberlain
6
Jawaban ini menunjukkan mengapa saya tidak suka GIT: ini lagi alat bagi tim untuk menghindari manajemen yang tepat dan perencanaan yang baik. Jawaban untuk semuanya adalah "siapa yang peduli, Anda selalu dapat menggunakan perintah itu nanti", bukannya menghindari masalah sebelum terjadi.
— motoDrizzt
7
Pikiran pertama saya juga merupakan pertanda praktik buruk, para devs seharusnya tidak bekerja pada file yang sama untuk sebagian besar. Jika sebuah proyek kecil mengalami banyak konflik ini, semua orang harus menyelesaikan konflik sepanjang hari tanpa melakukan pekerjaan apa pun!
— Aequitas
14
@motoDrizzt Apa? Saya belum pernah mendengar ada yang membuat argumen itu.
— jpmc26
95

Jawaban yang diterima menurut saya lebih bersifat teknis "bagaimana menggunakan Git lebih baik", saya pikir ini lebih merupakan masalah tim daripada masalah teknik atau perkakas.

Jika Anda menghadapi banyak konflik gabungan, itu berarti Anda dan orang lain dalam tim saling melangkah.
Anda atau mereka harus bertujuan untuk mengembangkan ruang pribadi saat coding dan menghindari bekerja di daerah yang sudah sibuk.

Di tim saya, kami cenderung memiliki tingkat tugas yang tinggi.
Saya biasanya akan mengambil kepemilikan penuh atau lengkap dari dua atau tiga file sekaligus dan mengerjakannya di cabang selama satu atau dua hari paling banyak.
Biasanya jika orang lain menyentuh file-file itu hanya jika benar-benar diperlukan untuk tugas mereka sendiri, kita umumnya tidak bekerja sama di blok tugas yang sama sekali!

Jika Anda menemukan bahwa Anda harus menggabungkan banyak hal, maka semua kode tim Anda ada di satu tempat (yang merupakan sesuatu yang harus dihindari dengan sendirinya) atau semua tugas Anda.

Semua yang dikatakan, sebagai pengembang baru Anda mungkin tidak dalam posisi untuk menegakkan, meminta atau bahkan benar-benar menyarankan segala bentuk restrukturisasi.
Apa yang saya harapkan adalah bahwa tugas Anda telah ditetapkan sebagai hal "belajar-tali" yang seharusnya dapat didekati secara wajar di tingkat keterampilan Anda untuk memudahkan Anda masuk ke dalam tim. Mereka mungkin diambil dari tugas rekan kerja yang masih bekerja di area yang sama, karenanya konflik gabungan Anda.
Solusi untuk hal ini adalah dengan menghentikannya, menyelesaikan masalah, menangani konflik penggabungan sebaik mungkin dan jangan terlalu khawatir, selama Anda melakukan yang terbaik, manajer Anda harus khawatir. kemajuan Anda.
Anda akan menjadi lebih cepat dan lebih percaya diri saat melangkah,

— Rowan
sumber
4
Saya pikir Anda memukul kepala dengan konflik rekan kerja. Menggabungkan konflik adalah hal biasa, tetapi umumnya terbatas pada beberapa file.
— Matthieu M.
10
Ini terdengar seperti akibat wajar dari Hukum Conway , dan prinsip tanggung jawab tunggal - yaitu bahwa jika orang bekerja pada masalah yang berbeda maka idealnya mereka akan mengedit bagian terpisah dari kode sumber.
— ChrisW
7
Meskipun saya setuju bahwa proses yang buruk atau desain yang buruk dapat menyebabkan sejumlah besar konflik, saya cukup yakin bahwa masalahnya hanyalah bahwa OP tidak bergabung dalam arus utama secara teratur. Saya tidak setuju bahwa "mengambil kepemilikan penuh dan lengkap" file adalah hal yang wajar. Saya tidak ingin tim saya memiliki overhead konstan untuk melacak siapa yang "memiliki" apa sekarang, meminta "izin" untuk membuat perubahan, atau menebak file apa yang harus mereka "klaim". Jarang, ketika menulis ulang komponen secara signifikan, saya meminta anggota tim untuk memberi tahu saya apakah mereka akan mengubah file tertentu.
— Derek Elkins
1
ChrisW memiliki ide yang tepat dengan apa yang saya kendarai. Secara umum, Kepemilikan di perusahaan saya berbentuk fungsionalitas aplikasi, saya mengambil kepemilikan penuh atas sistem Filter Pencarian sebagai tugas dan ketika itu terjadi, tidak ada orang lain yang perlu menyentuh file terkait dalam sebagian besar keadaan. Perasaan saya adalah kemungkinan besar OP sebagai starter baru telah diberikan bagian kecil dari tugas yang terkait erat dengan serangkaian tugas yang sedang berlangsung oleh pengembang lain. Berarti dev lain bekerja di bagian yang sama dari basis kode dan mereka saling menghalangi.
— Rowan
1
@Rowan Keren ya saya juga berpikir. Pemisahan fungsionalitas juga dapat membantu pemisahan file (set fungsi dalam file yang berbeda, dll.) Dan IMO ini membantu penggabungan.
— SaltySub2
28

Hal terpenting dari penggabungan adalah semakin lama Anda menunggu, semakin menyakitkan hal itu. Dan masalahnya tumbuh lebih dari linear. Tiga kali lebih banyak konflik adalah sembilan kali lebih banyak pekerjaan. Ada beberapa strategi:

Gabungkan dengan cabang pengembangan setiap kali ada perubahan, sehingga Anda selalu dekat dengannya, dan tidak pernah memiliki banyak konflik.

Jika Anda membutuhkan waktu lama, mungkin itu karena Anda menghabiskan sebagian besar waktu untuk mencari tahu perubahannya, dan kemudian sedikit waktu untuk mengimplementasikan perubahan tersebut. Jika demikian, gabungkan dengan cabang pengembangan sebelum Anda memulai perubahan kode aktual.

Bicaralah dengan kolega Anda tentang strategi untuk menghindari konflik. Anda mendapat konflik jika dua orang mengedit kode yang sama. Bukan hanya file yang sama, tetapi kode yang sama. Jadi saya memerlukan functionA fungsi baru dan Anda memerlukan functionB fungsi baru, dan kami berdua menambahkannya di akhir file yang sama, kami memiliki konflik. Jika kita menambahkannya di tempat yang berbeda, tidak ada konflik. Jika kami berdua menambahkannya di tempat di file yang secara logis berada, kemungkinan kami tidak akan mengalami konflik.

Jika Anda memiliki konflik, dapatkan alat diff yang baik, sehingga Anda dapat membandingkan cabang pengembangan sebelum penggabungan Anda, kode Anda sebelum penggabungan, kode asli Anda, dan kode gabungan, dan menggabungkan dengan tangan.

Kasus terburuk: Anda tidak membuang pekerjaan Anda, tetapi gunakan alat diff yang bagus untuk mengetahui dengan tepat perubahan apa yang Anda buat, cabang lagi dari pengembangan, dan terapkan semua perubahan yang Anda buat secara manual alih-alih mengetik ulang.

— gnasher729
sumber
Cabang fitur menampilkan dirinya seperti bentuk lain dari utang teknologi, di mana perubahan up-stream dari cabang induk adalah seperti refactoring.
— Dan Lyons
Kecuali Anda harus membayar hutang itu. Sekarang juga.
— gnasher729
15

Pada saat saya siap untuk menggabungkan cabang saya kembali menjadi berkembang (penekanan milikku)

Menangani konflik git mergeseringkali lebih sederhana daripada di git rebase. Di Git gabungan Anda dapat melihat seluruh daftar file yang telah diubah sekaligus. Tidak peduli berapa banyak komitmen yang telah dilakukan oleh rekan kerja lain, Anda harus bergabung satu kali . Dengan alur kerja rebase, Anda mungkin mendapatkan konflik yang sama berulang-ulang dan harus meninjaunya secara manual. Anda bisa memperbaiki komit ke-13 dan merasa seperti Anda tidak bisa melihat cahaya keluar dari terowongan .

Berdasarkan pengalaman saya, ketika saya mencoba untuk menyelesaikan konflik rebase secara naif saya akhirnya kehilangan modifikasi seseorang atau dengan aplikasi yang bahkan tidak dapat dikompilasi. Seringkali saya dan rekan kerja melakukan banyak pekerjaan tetapi menjadi kewalahan oleh kerumitan mengulangi konflik sehingga kami harus membatalkan dan kehilangan pekerjaan kami sebelumnya setelah beberapa rebase dilakukan.

Saya akan menyarankan Anda beberapa teknik tetapi mereka hanya bisa membantu penggabungan menjadi lebih mudah daripada mengotomatiskan tugas.

  • File sumber daya / bahasa . Jika Anda memiliki perubahan aditif ke file sumber daya, pastikan Anda selalu memindahkannya ke akhir file sehingga Anda dapat dengan mudah mengingat perubahan Anda terhadap perubahan orang lain . Anda mungkin dapat menyalin & menempelkan perubahan Anda di bagian bawah, atau hanya menghapus penanda konflik
  • Melakukan. Tidak. BENAR. Format ulang . Baik Anda maupun rekan pengembang Anda tidak akan melakukan "pemformatan ulang kode besar-besaran" selama pekerjaan sehari-hari. Code reformat menambah jumlah positif palsu yang berlebihan dalam manajemen konflik. Reformat kode dapat dilakukan
    • Secara bertahap, mis. Oleh setiap pengembang di setiap komit, segera setelah mereka menggunakan alat otomatis (misalnya Eclipse memiliki opsi untuk memformat ulang pada save, vanilla Visual Studio tidak memilikinya). Benar-benar setiap pengembang harus menggunakan standar format kode yang sama, dikodekan ke dalam format file yang dimakan oleh IDE Anda. Untuk memberi Anda ide, jika 4 spasi atau 2 tab itu tidak masalah, tetapi benar-benar penting jika semua orang menggunakan yang sama.
    • Tepat sebelum rilis, oleh pemimpin tim. Jika komit "reformat kode" terjadi ketika orang tidak bekerja di cabang, yaitu sebelum mereka bercabang, segalanya akan menjadi lebih mudah
  • Tinjau pemisahan pekerjaan di antara rekan kerja. Ini adalah bagian di mana sebagian besar teknik datang. Seperti yang ditunjukkan oleh jawaban lain, itu adalah bau desain jika beberapa pengembang melakukan tugas yang berbeda harus menyentuh sumber daya yang sama. Anda mungkin harus berdiskusi dengan pemimpin tim Anda tentang bagian mana yang harus dimodifikasi oleh setiap pengembang secara bersamaan.

Saya juga telah melihat beberapa kebiasaan buruk dalam alur kerja Git di tim saya. Seringkali orang terlalu berkomitmen pada cabang mereka. Saya pribadi menyaksikan pengembang menambahkan 10 hingga 20 komit berlabel "fix", masing-masing komit satu atau dua baris. Kebijakan kami adalah bahwa komit diberi label dengan tiket JIRA untuk memberi Anda ide.

@JacobRobbins menyarankan untuk membuat git rebasetugas harian. Saya ingin mendorong pendekatannya ke depan.

Pertama, gunakan rebase sekali saja untuk mengurangi jumlah komit ke segelintir. Dan rebase hanya ke cabang pengembangan asli , yang merupakan komit dari mana Anda bercabang. Ketika saya mengatakan sedikit, saya bisa berarti 3 atau 4 (misalnya semua ujung depan, semua ujung belakang, semua tambalan basis data) atau angka yang masuk akal secara manusiawi. Setelah Anda mengonsolidasikannya, gunakan fetchdan kerjakan rebase Anda di cabang hulu. Ini tidak akan menyelamatkan Anda dari konflik kecuali tim Anda meninjau pendekatan mereka sendiri, tetapi akan membuat hidup Anda tidak terlalu menyakitkan.

Jika Anda memiliki pertanyaan tambahan tentang tugas tertentu, jangan ragu untuk mencari dan bertanya di Stackoverflow.

[Sunting] tentang aturan no-reformat dan boy scout. Saya memiliki sedikit format ulang RE untuk menyoroti bahwa apa yang saya maksud adalah tugas memformat dari awal seluruh file sumber, termasuk kode yang tidak tersentuh oleh Anda. Bertentangan dengan untuk selalu memformat kode Anda sendiri, yang merupakan boy-scouty, sejumlah pengembang, termasuk saya, digunakan untuk memformat ulang seluruh file dengan kemampuan IDE. Ketika file itu disentuh oleh orang lain, bahkan jika baris yang terpengaruh tidak diubah dalam konten dan semantiknya, Git akan melihatnya sebagai konflik. Hanya editor yang sangat sadar bahasa yang dapat menyarankan bahwa konflik hanya terkait dengan memformat dan menggabungkan secara otomatis fragmen berformat terbaik. Tapi saya tidak punya bukti alat semacam itu.

Lagi pula, aturan pramuka tidak memerintahkan Anda untuk membersihkan kekacauan orang lain. Hanya milikmu.

— usr-local-ΕΨΗΕΛΩΝ
sumber
3
Ini sebagian besar masalah pendapat, tetapi saya tidak setuju bahwa menggabungkan konflik lebih mudah ditangani daripada konflik rebase. Saat Anda rebase, Anda pada dasarnya menerapkan komit satu per satu, menjaga cakupan konflik penggabungan jauh lebih kecil dan lebih mudah diikuti (Anda menerapkan perubahan ANDA yang Anda tahu - bukan perubahan orang lain yang tidak Anda lakukan). Anda mungkin harus menyelesaikan lebih banyak konflik gabungan dengan cara ini (karena menyentuh file yang sama beberapa kali di seluruh komit), tetapi mereka akan lebih kecil dan lebih mudah untuk diatasi.
— user622505
3
Mengenai memformat ulang, sementara VS tidak dapat melakukannya secara otomatis di save, jika Anda mengatur "When I paste" ke "Indent dan format" di "Tools" -> "Options" -> "Text Editor" -> "< Bahasa pilihan Anda> "->" Memformat ", itu artinya format otomatis di tempel. Ini memungkinkan urutan tiga penekanan tombol: ctrl-A, ctrl-C, ctrl-V memiliki hasil yang diinginkan. Yang mengatakan, +1 untuk Do. Tidak. BENAR. Reformat. Kecuali saat Anda menguraikan dalam kondisi yang sangat terkontrol.
— dgnuff
1
Pembaca Bob Martin harus mencatat bahwa Aturan Pramuka harus diterapkan dengan menahan diri jika Anda bekerja dalam tim (jika Anda bekerja sendiri, Anda memiliki lebih banyak fleksibilitas). Jika Anda menafsirkan aturan sebagai "Ini adalah tugas saya sebagai pembuat kode untuk memperbaiki segala sesuatu di setiap file yang tidak sempurna begitu saya mengetahuinya, tidak pernah terpikir apa yang sedang dikerjakan orang lain.", Anda akan berakhir dengan jumlah yang sangat besar untuk menyelesaikan konflik, dan itu akan menjadi kekacauan besar tidak peduli seberapa bagus niat Anda.
— jrh
2
Anda merasa perlu memformat ulang atau sedikit memperbaiki kode, lakukan sebelum atau setelah komit bermakna Anda. Ini tidak hanya akan mengurangi konflik, tetapi juga membantu pembaca komit Anda di masa depan, termasuk pengulas
— max630
1
Dari budaya C # saya, "memformat ulang" berarti tindakan memformat file kode keseluruhan atau bahkan seluruh repositori di mana format hanya terkait dengan keterbacaan . Jika bahasa Anda menggunakan spasi putih secara bermakna, Anda tidak boleh main-main dengan ruang putih di LOC yang bukan milik Anda. Sebaliknya, bahasa pilihan Anda masih memungkinkan spasi putih yang tidak bermakna (misalnya sebelum penjepit) yang dapat "diformat ulang" sesuai dengan standar keterbacaan
— usr-local-ΕΨΗΕΛΩΝ
5

Pertama, jangan berpikir untuk membuang perubahan Anda. Anda akan kehilangan peluang untuk mempelajari proses penggabungan.

Kedua, cari orang yang mengerjakan file yang menyebabkan konflik. Anda bisa melihat sejarahnya. Bicaralah dengan orang tersebut dan selesaikan konflik dalam file-file itu. Lakukan hal yang sama untuk konflik lainnya.

Jika ada terlalu banyak konflik, tugas Anda mungkin kecil, tetapi berulang. Cobalah untuk menemukan polanya. Ini akan membantu dalam menyelesaikan konflik dengan alat klien Git UI. Saya menggunakan TortoiseGit. Ini membantu dalam penggabungan.

Dan untuk menghindari di masa depan,

  • Ini adalah praktik yang sangat baik untuk menggabungkan cabang pengembangan secara teratur ke cabang fitur Anda.

  • Jika Anda mengaktifkan CI, lihat apakah alat CI menyediakan pembangunan cabang. Ini harus dibangun pada setiap cek di Anda buat di cabang fitur Anda, tetapi setelah gabungan mengembangkan cabang.

— PKV
sumber
1
+1 Saran lain untuk menggunakan Git lebih baik adalah baik, tetapi sebenarnya berbicara dengan pengembang lain tentang menggabungkan konflik adalah aspek kunci lain untuk mengembangkan efektivitas OP.
— Dragonel
1
"Kamu bisa melihat sejarahnya" Mungkin! Tergantung bagaimana remasnya & rebased semuanya: P
— Lightness Races di Orbit
1

Anda harus menjalankan secara teratur (setiap hari) perintah 'git fetch' (bukan git pull) dari cabang pengembangan Anda. Ini akan membuat orang lain melakukan perubahan dan membawanya ke cabang fitur Anda tanpa berusaha mengintegrasikan perubahan ke cabang Anda.

Ini adalah sesuatu yang harus Anda bicarakan dengan pengembang utama (tidak harus manajer Anda), karena perusahaan Anda mungkin memiliki standar sendiri atau cara yang disarankan untuk menangani masalah ini; ini sangat umum. Jangan tunggu sampai minggu depan - cari tahu prosesnya sekarang, dan tanyakan apakah Anda dapat melakukan beberapa pekerjaan sepele (seperti memformat kode atau menambahkan komentar) sehingga Anda dapat menguji prosesnya.

21
Saya tidak yakin ini benar. Git fetch akan mendapatkan remote / origin / master terbaru tetapi Anda kemudian harus menggabungkan remote / origin / master ke dalam cabang fitur Anda (Atau remote / origin / develop jika itu aliran yang mereka gunakan)
— Richard Tingle
Dengan asumsi dia menggunakan git, itu juga ide yang baik untuk belajar bagaimana menekan komit Anda ke bagian yang bermakna. Dengan begitu ketika Anda siap untuk melakukan permintaan tarik, komit Anda ramping dan mudah dan mudah dimengerti.
@RichardTingle Benar, Dia sedang memikirkan opsi rebase. Anda cukup mengambil & rebase cabang Anda dengan cabang dev. Itu akan menyinkronkan semuanya.
6
@ Dan saya pikir itu mungkin masalah pendapat. Secara pribadi saya benci komitmen besar. Coba git membagi dua itu!
— Richard Tingle
2
@PeteCon "dan bawa mereka ke cabang fitur Anda tanpa berusaha mengintegrasikan perubahan ke cabang Anda". Itu sepertinya pernyataan yang kontradiktif. Saya pikir maksud Anda membawa mereka ke dalam repositori lokal Anda tanpa mengintegrasikannya ke dalam cabang fitur Anda, tetapi saya tidak yakin bagaimana itu membantu ...
— Jason Goemaat
1

Jelas hal pertama adalah menghindari banyak orang mengerjakan file yang sama sejak awal, setidaknya dengan cara yang mengarah pada konflik yang sulit. Menambahkan hal-hal ke dalam penghitungan bukanlah masalah asalkan format kode yang baik digunakan. Mengubah aliran kontrol dengan cara yang berbeda dan memindahkan kode adalah jauh lebih rumit. Kadang-kadang ini tidak bisa dihindari. Anda harus mengajukan pertanyaan saat menyelesaikan konflik yang benar-benar rumit.

Yang mengatakan, saya melihat banyak jawaban merekomendasikan untuk bergabung / rebase ke pengembangan secara teratur. Saya akan jauh kurang antusias tentang nasihat semacam itu. Tujuan Anda pada titik ini adalah membuat proses penyelesaian konflik semudah dan seaman mungkin. Satu hal yang akan sangat membantu dengan proses itu adalah untuk memiliki banyak tes regresi segera tersedia, termasuk yang baru yang merupakan bagian dari fitur baru Anda. Jika Anda menyinkronkan cabang Anda secara teratur dengan pengembangan, Anda akhirnya harus menyelesaikan konflik sementara Anda setengah selesai benar-benar mengimplementasikan fitur Anda. Dan itu berarti akan jauh lebih sulit untuk mencari tahu apa yang seharusnya dilakukan oleh kode, karena Anda belum selesai melakukannya. Sebelum mencoba untuk bergabung, pastikan cabang Anda adalah unit perubahan yang koheren. Bahkan lebih baik,

Saya mencoba untuk tidak masuk ke dalam manfaat rebase atas penggabungan yang mungkin untuk pertanyaan lain. Dalam konteks ini alat tidak terlalu penting.

— Kafein
sumber
1

Pada saat saya siap untuk menggabungkan cabang saya kembali ke pengembangan, yang lain telah membuat begitu banyak perubahan yang menyelesaikan konflik sangat besar

Ini terdengar seperti skenario ideal untuk pemrograman berpasangan !

Info lebih lanjut tentang manfaat dan pendekatan dasar:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Secara alami, Anda akan mempercepat dari waktu ke waktu untuk bekerja sendiri, tetapi hal itu bisa menakutkan sampai saat itu tiba, dan kadang-kadang butuh waktu yang lama. Juga, sementara orang dapat belajar dengan cepat berada dalam lingkungan yang penuh tekanan selalu ditekan untuk mengejar ketinggalan, orang lain yang tidak belajar dengan baik di bawah tekanan terus-menerus akan terhambat.

Alih-alih bekerja pada cabang sendiri dan mencoba untuk mengikuti pengembang lain yang jelas jauh lebih cepat daripada Anda, Anda malah akan bekerja secara langsung (PC yang sama) dengan pengembang lain. Dengan cara ini Anda mendapatkan saran instan dan mungkin akan mengambil tips cara mempercepat dll.

Anda harus mengetahui pendekatan terbaik untuk kode tertentu dalam proyek Anda, karena pemrograman pasangan tidak selalu masuk akal untuk beberapa proyek - meskipun bisa dibilang selalu masuk akal untuk belajar bahkan jika Anda hanya duduk dan menonton seseorang yang lebih berpengalaman daripada Anda (Selama mereka adalah pengembang yang baik, pengalaman tidak selalu berarti mereka menggunakan praktik yang baik).

Duduk dengan dev yang lebih cepat dan lebih berpengalaman berpotensi membantu dengan:

  • Kemungkinan akan mengurangi konflik gabungan karena bekerja dengan seseorang yang lebih berpengalaman akan meningkatkan waktu penyelesaian sebagai lawan dari pekerjaan Anda sendiri
  • Karena mereka akan mengajari Anda, kemungkinan mereka akan lebih lambat daripada mereka akan bekerja sendiri, jadi mungkin masih ada beberapa konflik penggabungan dan dapat bekerja melaluinya dengan seseorang yang berpengalaman dan jadi mungkin mengambil beberapa tips tentang menghemat waktu, dll.
  • Bantu Anda melihat potensi trik dan cara untuk menjadi lebih cepat (meskipun lambat kadang-kadang hanya karena kurangnya pengalaman daripada kurangnya praktik yang baik)
  • Dapat mengajukan pertanyaan segera ketika sesuatu tidak masuk akal atau tidak 100% jelas
  • Bekerja 1: 1 sangat berharga untuk dipelajari karena orang yang Anda minta bantuan sudah memahami kode dan skenario yang tepat saat mereka mengerjakannya, tanpa pemrograman pasangan Anda harus menjelaskan kode dan skenario, yang sering berakhir dengan masalah dan sehingga Anda kehilangan waktu / perhatian mereka untuk benar-benar mendapatkan saran yang sangat dibutuhkan
  • Kenali proses berpikir seseorang yang lebih berpengalaman dan berpengalaman, dan dengan komunikasi yang baik Anda pasti akan belajar hal-hal baru

Apakah ada taktik yang bisa saya gunakan selain 'lebih baik dalam pengkodean'? Saya bermaksud untuk membicarakan hal ini dengan penyelia saya minggu depan.

Saran saya adalah membahas pemrograman berpasangan dengan pengembang lainnya dan kemudian mendekati supervisor Anda. Jika mereka layak, mereka akan menghargai inisiatif Anda yang memiliki lebih banyak kesempatan bagi Anda untuk mengajukan pro pemrograman berpasangan (jika mereka membutuhkannya, kebanyakan orang mengetahuinya dan itu adalah pengetahuan umum mengapa itu membantu).

— James
sumber
Jujur yang downvoted :( ini bukan tebakan liar, ini terjadi di tempat kerja saya dan terbukti bekerja! Kebetulan, saya bekerja keras pada jawaban lain pada pertanyaan lain di situs ini untuk dapat memiliki 10 rep (di atas perwakilan saya yang terkait ) hanya untuk dapat menyarankan "pemrograman pasangan" dalam yang satu ini karena tidak ada yang menyarankannya. Saya bekerja sangat keras untuk menjawab ini.
— James
1

Ada beberapa masalah mendasar di sini. Masalah Anda menggabungkan kemungkinan besar bukan kesalahan Anda dan lebih umum merupakan gejala praktik buruk.

1) Idealnya Anda akan menggabungkan cabang Anda menjadi berkembang setiap hari. Cobalah memiliki kode yang berfungsi setidaknya sekali sehari yang lulus semua tes sehingga Anda dapat bergabung menjadi pengembangan.

2) Jika Anda tidak memiliki kode kerja di titik mana pun selama hari kerja biasa, Anda mungkin memiliki terlalu banyak kode untuk dikerjakan. Anda perlu memecah tugas Anda menjadi tugas-tugas kecil yang dapat diselesaikan (idealnya satu sama lain) lebih cepat sehingga Anda dapat bergabung.

3) File proyek Anda cenderung terlalu besar. Jika ada banyak konflik gabungan untuk file, ada terlalu banyak orang yang mengerjakan satu file. Idealnya sesuatu yang dikerjakan seseorang harus terpisah dari apa yang dikerjakan orang lain.

4) Tim Anda mungkin terlalu besar. Jika Anda merasa lebih mudah untuk membuang seluruh fitur dan memulai kembali, kemungkinan ada terlalu banyak orang yang melakukan kode ke repositori yang sama.

5) Anda mungkin tidak memiliki standar format kode yang konsisten. Jika Anda tidak konsisten menggunakan pemformatan kode yang sama, Anda akan mendapatkan banyak konflik berbeda untuk kode yang sama. Bergantung pada bagaimana git Anda diatur, ini bahkan mungkin mengarah ke konflik spasi putih (ujung baris, lekukan, tab vs spasi).

6) Orang mungkin mendorong perubahan mereka langsung ke cabang pengembangan.

Inilah yang dapat Anda lakukan: 1) Jika Anda tidak dapat bergabung menjadi berkembang setiap hari, gabungkan / rebase berkembang menjadi cabang Anda setiap hari (atau lebih sering).
2) Cobalah memisahkan kode Anda dari kode orang lain.
3) Bicaralah dengan seluruh tim tentang fitur yang lebih kecil, standar pengkodean yang konsisten, dan pengaturan kode yang lebih baik (file yang lebih kecil, fungsi yang lebih kecil).

— xyious
sumber
1

Sebenarnya tampak lebih mudah untuk membatalkan pekerjaan saya dan memulai kembali tugas, yang tentu saja bukan solusi berkelanjutan)

Sebagian besar waktu, inilah yang saya lakukan, pertama kali saya memperbaiki bug atau membuat perubahan pada sistem, saya belajar tentang cara melakukannya. Lain kali saya memperbaiki bug yang sama hanya butuh 1% dari waktu karena saya sekarang mengerti masalahnya.

Saya juga menemukan bahwa ketika saya mengulang sedikit pekerjaan, saya menulis kode yang lebih baik .....

Karenanya tidak ada yang salah dengan membuat cabang baru dari master, mengulang pekerjaan Anda di dalamnya, sambil menggunakan "cabang pribadi" Anda untuk mengingatkan Anda apa yang perlu Anda lakukan.

Mungkin juga Anda telah menemukan cara untuk membagi perubahan Anda menjadi bagian-bagian yang logis dan benar, masing-masing yang digabung ke cabang master setelah selesai. Misalnya, tes unit dan perubahan pada kode backend dapat dilakukan, dan digabungkan. Kemudian dalam operasi terpisah, Anda dapat melakukan perubahan UI yang memanfaatkannya, karenanya memiliki risiko lebih kecil untuk orang lain mengedit file UI yang sama.

— Ian
sumber
1

Jika Anda tidak ingin terlalu sering menggabungkan cabang pengembangan ke cabang Anda, Anda bisa mendapatkan alur kerja yang lebih mirip dengan menggunakan svn git pull --rebase. Ini akan menarik komit baru dan mengulang komit Anda pada mereka. Ini berarti ketika Anda menggabungkan cabang Anda menjadi berkembang, itu akan menjadi penggabungan maju cepat (seolah-olah Anda akan menambahkan semua komitmen masa lalu Anda satu per satu) dan tidak memiliki konflik penggabungan, karena Anda menyelesaikannya semua selama git pull --rebase.

Tetapi semakin banyak komitmen yang Anda buat sebelum menggabungkan salah satu cabang Anda menjadi berkembang atau berkembang menjadi cabang Anda, semakin rumit rebase berikutnya akan didapat dan hal itu sedikit menumbangkan rasa fitur-cabang, karena cabang Anda hanya ada selama tidak di-ungerger .

— allo
sumber
1

Ketika Anda bekerja di file umum, dengan cara apa pun Anda atau rekan satu tim Anda perlu menyelesaikan semua konflik sebelum penggabungan selesai maka dari awalnya, jangan kecewa . Anda masih melakukan pekerjaan proyek dan bangga dengan pekerjaan Anda. Sekarang untuk membuat langkah yang lebih cerdas, Anda dapat mengikuti beberapa saran di bawah ini.

  1. Bagi tugas secara mandiri:

    Sebelum Anda memulai pekerjaan Anda, rencanakan dan bagi seluruh tugas sedemikian rupa sehingga tugas yang ditugaskan untuk setiap anggota tim adalah sebanyak mungkin independen dan modular (untuk menghindari potensi konflik saat berkembang). Anda dapat mendekati pemimpin scrum Anda untuk menetapkan beberapa tugas independen untuk Anda karena Anda masih pemula.

  2. Gabungkan granular yang sering dilakukan:

    Jangan menunggu tugas penuh untuk diselesaikan sebelum final marge. Tentu saja tugas yang lebih besar dapat dipartisi menjadi beberapa subtugas. Jadi pendekatan yang lebih baik adalah dengan menggabungkan komitmen yang lebih kecil untuk subtugas yang lebih kecil pada saat yang sama sering untuk menghindari resolusi konflik yang besar.

  3. Rebase cabang Anda sesering mungkin:

    Lakukan rebase yang sering ke cabang lokal Anda dengan yang jarak jauh. Anda dapat menggunakan perintah di bawah ini untuk sering rebase cabang lokal Anda dengan yang jauh,

    git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch

    Sejauh ini perintah git yang paling berguna bagi saya dalam kehidupan pengembangan saya.

  4. Bekerja sama dengan rekan tim:

    Jika Anda benar-benar perlu bekerja secara paralel dengan rekan setim Anda dalam tugas bersama, silakan bekerja secara kolaboratif. Dia dapat menunggu beberapa saat untuk menghindari penyelesaian konflik yang rumit untuk kenyamanan Anda karena Anda adalah pemula dan dia adalah seorang ahli.

  5. Biasakan dengan opsi git:

    Gunakan kekuatan alat penggabungan git. Ada banyak cara mudah untuk menyelesaikan konflik saat bergabung. Strategi penggabungan kadang - kadang mungkin banyak membantu. Biasakan dan tak kenal takut dengan perintah git.

— Sazzad Hissain Khan
sumber
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.