Pertanyaan Mengintegrasikan perubahan indentasi & konten di Git saat penggabungan: Praktik terbaik?


Saya menggunakan Git untuk melacak beberapa kode matlab. Contoh mainan paling menggambarkan masalah. Proyek sejauh ini terlihat seperti ini.

    C
   /
A--
   \
    B

Isi dari A adalah x=5

Kami membuat komit C, di mana garis diubah menjadi x=6

Kami kemudian membuat komit B, di mana konten kami menjadi seperti di bawah ini

if flag==1
    x=5
end

Jika kita mencoba menggabungkan dengan tujuan proyek tampak seperti

    C
   / \
A--   D
   \ /
    B

dengan hasil gabungan di D, kita akan mendapatkan konflik, karena garis utama telah diubah di keduanya (indentasi ditambahkan dalam B, 5 diubah menjadi 6 dalam C).

Apakah ada cara praktik terbaik untuk mengintegrasikan perubahan indentasi dari satu cabang, dan perubahan konten dari cabang lain, untuk mendapatkan hasil penggabungan?

Saya sudah membaca tentang satu strategi di https://stackoverflow.com/a/5262473/288545, dan sementara itu akan menghindari konflik, itu akan membuang inden yang mendukung perubahan konten (yang merupakan perbaikan, tetapi masih membuat lebih sulit untuk membaca kode).

Saya kira saya hanya bisa menghisapnya dan tidak mengubah lekukan saat menulis kode saya. Ini membuatnya lebih mudah dibaca, tetapi bukan masalah besar dalam matlab. Namun, dalam python, lekukan benar-benar penting, jadi bagaimana orang python menghadapinya? Hal ini menjadi jauh lebih buruk jika ada blok kode besar yang kemudian kita ubah menjadi bagian dalam struktur kontrol, sehingga diff menyentuh banyak garis dan membuat konflik gabungan menjadi masalah besar.

Apakah ada strategi gabungan yang akan menangani perubahan jarak dan perubahan konten secara terpisah, dan kemudian mengintegrasikannya? Saya ingin hasil penggabungan menjadi

if flag==1
    x=6
end

10
2017-09-11 19:25


asal


Jawaban:


Kunci untuk memecahkan masalah Anda adalah dengan membersihkan dan membersihkan penulisan ulang fungsi sebagai komit terpisah.

Sebagai seseorang yang melakukan banyak integrasi cabang, saya dapat dengan jujur ​​mengatakan dua hal yang paling menjengkelkan bagi para integrator adalah: 1) pengkode yang suka memformat ulang file yang mereka tidak penulis atau fungsi yang tidak mereka tulis ulang, dan 2) IDE yang memformat ulang seluruh file hanya dengan membuka dan menyimpannya. Yakin file lebih mudah dibaca dalam kedua kasus, tetapi benar-benar mengalahkan titik kontrol versi: Komitmen harus secara cerdas berukuran, dibangun, dan ditinjau. Perintah mereka harus memiliki makna. Kitchen sink commit membuat sejarah yang tidak berguna, dan sejarah seharusnya tidak berguna.

Filosofi ini menyiratkan "Jangan membuang perubahan spasi di komit di mana mereka bukan milik." Jika Anda menulis ulang fungsi yang disentuh, tentu, perbaiki jaraknya. Jika tidak, biarkan ia berkomitmen dan pastikan orang lain yang bekerja pada file itu tahu perubahan spasi akan datang. Itu akan menghemat kerumitan pada waktu integrasi.

Selain itu, Anda dapat menghindari kesalahan spasi putih yang tidak disengaja (spasi di belakang, tab setelah spasi, dan sejenisnya) dengan hook pra-commit stok git. Berikan perintah ini di repositori Anda untuk mengaturnya:

mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

Ini lebih banyak atau lebih sedikit masalah git diff --check, yang juga sangat berguna untuk mendeteksi jenis masalah ini.


3
2017-09-11 23:55



Beberapa alat yang berbeda lebih baik daripada yang lain. saya menggunakan KDiff3, dan sudah diatur untuk dipanggil secara otomatis menggunakan git mergetool. Ini masih belum sempurna, tetapi sering dapat mendeteksi gabungan dari jenis yang Anda gambarkan dan secara otomatis menghasilkan gabungan yang masuk akal.


3
2017-09-12 10:00