Bagaimana dan / atau mengapa menggabungkan di Git lebih baik daripada di SVN?


400

Saya telah mendengar di beberapa tempat bahwa salah satu alasan utama mengapa sistem kontrol versi terdistribusi bersinar, adalah penggabungan yang jauh lebih baik daripada pada alat tradisional seperti SVN. Apakah ini sebenarnya karena perbedaan yang melekat pada bagaimana kedua sistem bekerja, atau melakukan implementasi DVCS spesifik seperti Git / Mercurial hanya memiliki algoritma penggabungan yang lebih pintar daripada SVN?


Saya masih belum mendapatkan jawaban lengkap dari membaca jawaban-jawaban hebat di sini. Diposting ulang - stackoverflow.com/questions/6172037/…
ripper234


itu tergantung pada model Anda. dalam kasus-kasus yang lebih sederhana, svn seringkali lebih baik karena tidak sengaja memanggil penggabungan 2-arah penggabungan 3-cara seperti git dapat dilakukan jika Anda mendorong / menggabungkan / menarik / mendorong pada satu cabang pengembangan. lihat: svnvsgit.com
Erik Aronesty

Jawaban:


556

Klaim mengapa penggabungan lebih baik dalam DVCS daripada di Subversion sebagian besar didasarkan pada bagaimana percabangan dan penggabungan bekerja di Subversion beberapa waktu lalu. Subversi sebelum 1.5.0 tidak menyimpan informasi tentang kapan cabang digabung, jadi ketika Anda ingin menggabungkan Anda harus menentukan rentang revisi mana yang harus digabung.

Jadi mengapa penggabungan Subversion menghisap ?

Renungkan contoh ini:

      1   2   4     6     8
trunk o-->o-->o---->o---->o
       \
        \   3     5     7
b1       +->o---->o---->o

Ketika kami ingin menggabungkan perubahan b1 ke dalam trunk, kami akan mengeluarkan perintah berikut, sambil berdiri di folder yang memiliki trunk check out:

svn merge -r 2:7 {link to branch b1}

... yang akan mencoba untuk menggabungkan perubahan dari b1ke direktori kerja lokal Anda. Dan kemudian Anda melakukan perubahan setelah Anda menyelesaikan konflik dan menguji hasilnya. Saat Anda komit, pohon revisi akan terlihat seperti ini:

      1   2   4     6     8   9
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \
        \   3     5     7
b1       +->o---->o---->o

Namun cara menentukan rentang revisi ini cepat hilang ketika pohon versi tumbuh karena subversi tidak memiliki data meta kapan dan apa revisi yang digabungkan. Renungkan apa yang terjadi kemudian:

           12        14
trunk  …-->o-------->o
                                     "Okay, so when did we merge last time?"
              13        15
b1     …----->o-------->o

Ini sebagian besar merupakan masalah oleh desain repositori yang dimiliki Subversion, untuk membuat cabang Anda perlu membuat direktori virtual baru di repositori yang akan menampung salinan trunk tetapi tidak menyimpan informasi mengenai kapan dan apa hal-hal yang digabungkan kembali. Itu akan menyebabkan konflik gabungan yang buruk di kali. Yang lebih buruk lagi adalah bahwa Subversion menggunakan penggabungan dua arah secara default, yang memiliki beberapa batasan yang melumpuhkan dalam penggabungan otomatis ketika dua kepala cabang tidak dibandingkan dengan leluhur mereka yang sama.

Untuk mengurangi Subversi ini sekarang menyimpan data meta untuk cabang dan bergabung. Itu akan menyelesaikan semua masalah bukan?

Dan oh, omong-omong, Subversi masih menyebalkan ...

Pada sistem terpusat, seperti subversi, direktori virtual menyedot. Mengapa? Karena setiap orang memiliki akses untuk melihatnya ... bahkan yang eksperimental sampah. Percabangan baik jika Anda ingin bereksperimen tetapi Anda tidak ingin melihat eksperimen orang lain dan bibinya . Ini adalah kebisingan kognitif yang serius. Semakin banyak cabang yang Anda tambahkan, semakin banyak omong kosong yang akan Anda lihat.

Semakin banyak cabang publik yang Anda miliki di repositori, semakin sulit melacak semua cabang yang berbeda. Jadi pertanyaan yang akan Anda miliki adalah apakah cabang masih dalam pengembangan atau jika benar-benar mati yang sulit dikatakan dalam sistem kontrol versi terpusat.

Sebagian besar waktu, dari apa yang saya lihat, organisasi akan default untuk menggunakan satu cabang besar. Yang memalukan karena pada gilirannya akan sulit untuk melacak versi pengujian dan rilis, dan apa pun yang baik berasal dari percabangan.

Jadi mengapa DVCS, seperti Git, Mercurial dan Bazaar, lebih baik daripada Subversion di percabangan dan penggabungan?

Ada alasan yang sangat sederhana mengapa: percabangan adalah konsep kelas satu . Tidak ada direktori virtual oleh desain dan cabang adalah objek keras dalam DVCS yang perlu sedemikian rupa agar dapat bekerja hanya dengan sinkronisasi repositori (yaitu push dan pull ).

Hal pertama yang Anda lakukan ketika Anda bekerja dengan DVCS adalah mengkloning repositori (git's clone, hg's clonedan bzr's branch). Kloning secara konseptual sama dengan membuat cabang dalam kontrol versi. Beberapa menyebutnya forking atau branching (meskipun yang terakhir sering juga digunakan untuk merujuk ke cabang co-located), tetapi itu adalah hal yang sama. Setiap pengguna menjalankan repositori mereka sendiri yang artinya Anda memiliki percabangan per-pengguna .

Struktur versi bukan pohon , melainkan grafik . Lebih khusus grafik asiklik terarah (DAG, artinya grafik yang tidak memiliki siklus). Anda benar-benar tidak perlu memikirkan spesifik DAG selain setiap komit memiliki satu atau lebih referensi induk (yang berdasarkan komit itu). Jadi grafik berikut ini akan menunjukkan panah antara revisi secara terbalik karena ini.

Contoh penggabungan yang sangat sederhana adalah ini; bayangkan repositori sentral dipanggil origindan seorang pengguna, Alice, mengkloning repositori ke mesinnya.

         a…   b…   c…
origin   o<---o<---o
                   ^master
         |
         | clone
         v

         a…   b…   c…
alice    o<---o<---o
                   ^master
                   ^origin/master

Apa yang terjadi selama klon adalah bahwa setiap revisi disalin ke Alice persis seperti mereka (yang divalidasi oleh hash-id yang dapat diidentifikasi secara unik), dan menandai di mana cabang asal berada.

Alice kemudian mengerjakan repo-nya, melakukan dalam repositori miliknya sendiri dan memutuskan untuk mendorong perubahannya:

         a…   b…   c…
origin   o<---o<---o
                   ^ master

              "what'll happen after a push?"


         a…   b…   c…   d…   e…
alice    o<---o<---o<---o<---o
                             ^master
                   ^origin/master

Solusinya agak sederhana, satu-satunya hal yang originperlu dilakukan repositori adalah mengambil semua revisi baru dan memindahkan cabangnya ke revisi terbaru (yang git memanggil "fast-forward"):

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

         a…   b…   c…   d…   e…
alice    o<---o<---o<---o<---o
                             ^master
                             ^origin/master

Kasus penggunaan, yang saya ilustrasikan di atas, bahkan tidak perlu menggabungkan apa pun . Jadi masalahnya sebenarnya bukan dengan algoritma penggabungan karena algoritma penggabungan tiga arah hampir sama antara semua sistem kontrol versi. Masalahnya lebih tentang struktur daripada apa pun .

Jadi, bagaimana kalau Anda menunjukkan contoh yang memiliki penggabungan nyata ?

Memang contoh di atas adalah kasus penggunaan yang sangat sederhana, jadi mari kita lakukan yang lebih memutar meskipun yang lebih umum. Ingat itu origindimulai dengan tiga revisi? Nah, orang yang melakukannya, sebut saja dia Bob , telah mengerjakan sendiri dan membuat komit di repositori sendiri:

         a…   b…   c…   f…
bob      o<---o<---o<---o
                        ^ master
                   ^ origin/master

                   "can Bob push his changes?" 

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

Sekarang Bob tidak bisa mendorong perubahannya langsung ke originrepositori. Bagaimana sistem mendeteksi ini adalah dengan memeriksa apakah revisi Bob langsung diturunkan dari origin, yang dalam kasus ini tidak. Setiap upaya untuk mendorong akan menghasilkan sistem mengatakan sesuatu yang mirip dengan " Eh ... aku takut tidak bisa membiarkanmu melakukan itu Bob ."

Jadi Bob harus menarik dan menggabungkan perubahan (dengan git pull; atau hg pulldan merge; atau bzr merge). Ini adalah proses dua langkah. Bob pertama harus mengambil revisi baru, yang akan menyalinnya dari originrepositori. Kita sekarang dapat melihat bahwa grafik berbeda:

                        v master
         a…   b…   c…   f…
bob      o<---o<---o<---o
                   ^
                   |    d…   e…
                   +----o<---o
                             ^ origin/master

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

Langkah kedua dari proses tarik adalah menggabungkan tip yang berbeda dan membuat komitmen terhadap hasilnya:

                                 v master
         a…   b…   c…   f…       1…
bob      o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+
                             ^ origin/master

Mudah-mudahan penggabungan tidak akan mengalami konflik (jika Anda mengantisipasi mereka, Anda dapat melakukan dua langkah secara manual di git dengan fetchdan merge). Yang nanti perlu dilakukan adalah mendorong perubahan itu lagi origin, yang akan menghasilkan penggabungan cepat karena komit gabungan adalah keturunan langsung dari yang terbaru dalam originrepositori:

                                 v origin/master
                                 v master
         a…   b…   c…   f…       1…
bob      o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+

                                 v master
         a…   b…   c…   f…       1…
origin   o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+

Ada opsi lain untuk menggabungkan git dan hg, yang disebut rebase , yang akan memindahkan perubahan Bob setelah perubahan terbaru. Karena saya tidak ingin jawaban ini menjadi lebih bertele-tele saya akan membiarkan Anda membaca dokumen git , lincah atau bazaar tentang itu.

Sebagai latihan untuk pembaca, coba gambarkan cara kerjanya dengan pengguna lain yang terlibat. Demikian pula halnya dengan contoh di atas dengan Bob. Penggabungan antar repositori lebih mudah daripada yang Anda pikirkan karena semua revisi / komit dapat diidentifikasi secara unik.

Ada juga masalah pengiriman tambalan antara masing-masing pengembang, yang merupakan masalah besar dalam Subversion yang dimitigasi dalam git, hg dan bzr oleh revisi yang dapat diidentifikasi secara unik. Setelah seseorang menggabungkan perubahannya (yaitu membuat komit gabungan) dan mengirimkannya kepada semua orang di tim untuk dikonsumsi dengan mendorong ke repositori pusat atau mengirim tambalan maka mereka tidak perlu khawatir tentang gabungan tersebut, karena itu sudah terjadi . Martin Fowler menyebut cara ini untuk melakukan integrasi bebas pilih - pilih .

Karena strukturnya berbeda dari Subversion, dengan alih-alih menggunakan DAG, itu memungkinkan percabangan dan penggabungan dilakukan dengan cara yang lebih mudah tidak hanya untuk sistem tetapi juga bagi pengguna.


6
Saya tidak setuju dengan argumen branch == noise Anda. Banyak cabang tidak membingungkan orang karena pemimpin dev harus memberi tahu orang-orang cabang mana yang akan digunakan untuk fitur besar ... jadi dua pengembang mungkin bekerja pada cabang X untuk menambahkan "dinosaurus terbang", 3 mungkin bekerja pada Y untuk "membiarkan Anda melempar mobil pada orang "
Mr. Boy

16
John: Ya, untuk sejumlah kecil cabang ada sedikit kebisingan dan dapat dikelola. Tetapi kembalilah setelah Anda menyaksikan 50+ cabang dan tag atau lebih dalam subversi atau kasus yang jelas di mana sebagian besar dari mereka Anda tidak dapat mengetahui apakah mereka aktif atau tidak. Masalah kegunaan dari alat selain; mengapa memiliki semua sampah di repositori Anda? Setidaknya dalam p4 (karena "ruang kerja" pengguna pada dasarnya adalah cabang per-pengguna), git atau hg Anda punya opsi untuk tidak membiarkan semua orang tahu tentang perubahan yang Anda lakukan sampai Anda mendorongnya ke atas, yang merupakan jaga ketika perubahan itu relevan bagi orang lain.
Spoike

24
Saya tidak mendapatkan "terlalu banyak cabang eksperimental Anda argumen kebisingan juga, @Sike. Kami memiliki folder" Pengguna "di mana setiap pengguna memiliki folder sendiri. Di sana ia dapat bercabang sesering yang diinginkan. Cabang murah di Subversion dan jika Anda mengabaikan folder pengguna lain (mengapa Anda harus peduli dengan mereka), maka Anda tidak melihat suara. Tetapi bagi saya bergabung dalam SVN tidak payah (dan saya sering melakukannya, dan tidak, itu tidak kecil proyek). Jadi mungkin saya melakukan sesuatu yang salah;) Namun demikian penggabungan Git dan Mercurial lebih unggul dan Anda menunjukkannya dengan baik
John Smithers

11
Dalam svn mudah untuk membunuh cabang yang tidak aktif, Anda cukup menghapusnya. Fakta bahwa orang tidak menghapus cabang yang tidak digunakan karena itu membuat kekacauan hanyalah masalah kebersihan. Anda bisa dengan mudah berakhir dengan banyak cabang sementara di Git juga. Di tempat kerja saya, kami menggunakan direktori tingkat atas "temp-branch" selain dari yang standar - cabang pribadi dan cabang eksperimental masuk ke sana alih-alih mengacaukan direktori cabang tempat baris kode "resmi" disimpan (kami tidak gunakan cabang fitur).
Ken Liu

10
Apakah ini berarti kemudian, bahwa dari subversi v1.5 setidaknya dapat menggabungkan dan juga git?
Sam

29

Secara historis, Subversion hanya mampu melakukan penggabungan dua arah yang lurus karena tidak menyimpan informasi penggabungan. Ini melibatkan mengambil satu set perubahan dan menerapkannya pada pohon. Bahkan dengan informasi penggabungan, ini masih merupakan strategi penggabungan yang paling umum digunakan.

Git menggunakan algoritma penggabungan 3-arah secara default, yang melibatkan menemukan leluhur yang sama dengan kepala yang digabungkan dan memanfaatkan pengetahuan yang ada di kedua sisi penggabungan. Ini memungkinkan Git menjadi lebih cerdas dalam menghindari konflik.

Git juga memiliki beberapa kode pencarian ganti nama yang canggih, yang juga membantu. Itu tidak menyimpan perubahan atau menyimpan informasi pelacakan - itu hanya menyimpan keadaan file di setiap komit dan menggunakan heuristik untuk mencari nama dan gerakan kode yang diperlukan (penyimpanan pada disk lebih rumit dari ini, tetapi antarmuka itu hadir ke lapisan logika memperlihatkan tidak ada pelacakan).


4
Apakah Anda memiliki contoh bahwa svn memiliki gabungkan konflik tetapi git tidak?
Gqqnbig

17

Sederhananya, implementasi gabungan dilakukan lebih baik di Git daripada di SVN . Sebelum 1.5 SVN tidak merekam tindakan penggabungan, jadi tidak mungkin melakukan penggabungan di masa mendatang tanpa bantuan pengguna yang perlu memberikan informasi yang tidak dicatat oleh SVN. Dengan 1,5 semakin baik, dan memang model penyimpanan SVN sedikit lebih mampu daripada Dag Git. Tetapi SVN menyimpan informasi penggabungan dalam bentuk yang agak berbelit-belit yang memungkinkan penggabungan mengambil waktu lebih banyak daripada di Git - Saya telah mengamati faktor 300 dalam waktu eksekusi.

Juga, SVN mengklaim untuk melacak nama untuk membantu penggabungan file yang dipindahkan. Tapi sebenarnya itu masih menyimpannya sebagai salinan dan tindakan penghapusan terpisah, dan algoritma penggabungan masih tersandung di atasnya dalam memodifikasi / mengubah nama situasi, yaitu, di mana file diubah pada satu cabang dan mengubah nama pada yang lain, dan cabang-cabang itu adalah untuk digabung. Situasi seperti itu masih akan menghasilkan konflik penggabungan palsu, dan dalam kasus direktori berganti nama itu bahkan menyebabkan hilangnya modifikasi diam-diam. (Orang-orang SVN kemudian cenderung menunjukkan bahwa modifikasi masih dalam sejarah, tetapi itu tidak banyak membantu ketika mereka tidak dalam hasil penggabungan di mana mereka akan muncul.

Git, di sisi lain, bahkan tidak melacak nama tetapi mencari mereka setelah fakta (pada saat penggabungan), dan melakukannya dengan cukup ajaib.

Representasi gabungan SVN juga memiliki masalah; di 1.5 / 1.6 Anda bisa menggabungkan dari trunk ke branch sesering yang baru saja disukai, secara otomatis, tetapi penggabungan ke arah lain perlu diumumkan ( --reintegrate), dan meninggalkan cabang dalam keadaan tidak dapat digunakan. Jauh kemudian mereka menemukan bahwa ini sebenarnya bukan masalahnya, dan bahwa a) --reintegrate dapat dipecahkan secara otomatis, dan b) penggabungan berulang di kedua arah dimungkinkan.

Tetapi setelah semua ini (yang IMHO menunjukkan kurangnya pemahaman tentang apa yang mereka lakukan), saya akan (OK, saya) sangat berhati-hati untuk menggunakan SVN dalam skenario percabangan nontrivial, dan idealnya akan mencoba melihat apa yang Git pikirkan tentang hasil penggabungan.

Poin-poin lain yang dibuat dalam jawaban, karena visibilitas global yang dipaksakan dari cabang-cabang di SVN, tidak relevan untuk menggabungkan kemampuan (tetapi untuk kegunaan). Juga, 'Git store berubah sementara SVN store (sesuatu yang berbeda)' sebagian besar tidak tepat sasaran. Git secara konseptual menyimpan setiap komit sebagai pohon terpisah (seperti file tar ), dan kemudian menggunakan beberapa heuristik untuk menyimpannya secara efisien. Menghitung perubahan antara dua komit terpisah dari implementasi penyimpanan. Yang benar adalah bahwa Git menyimpan DAG sejarah dalam bentuk yang jauh lebih mudah bahwa SVN melakukan mergeinfo. Siapa pun yang mencoba memahami yang terakhir akan tahu apa yang saya maksud.

Singkatnya: Git menggunakan model data yang jauh lebih sederhana untuk menyimpan revisi daripada SVN, dan dengan demikian itu dapat menempatkan banyak energi ke dalam algoritma penggabungan yang sebenarnya daripada mencoba untuk mengatasi representasi => penggabungan yang praktis lebih baik.


11

Satu hal yang belum disebutkan dalam jawaban lain, dan itu benar-benar adalah keuntungan besar dari DVCS, adalah bahwa Anda dapat melakukan secara lokal sebelum Anda mendorong perubahan Anda. Di SVN, ketika saya memiliki beberapa perubahan, saya ingin check-in, dan seseorang telah melakukan komitmen pada cabang yang sama sementara itu, ini berarti bahwa saya harus melakukan svn updatesebelum saya dapat melakukan. Ini berarti bahwa perubahan saya, dan perubahan dari orang lain sekarang digabung menjadi satu, dan tidak ada cara untuk membatalkan penggabungan (seperti dengan git resetatau hg update -C), karena tidak ada komitmen untuk kembali. Jika penggabungan bersifat non-sepele, ini berarti Anda tidak dapat terus bekerja pada fitur Anda sebelum Anda membersihkan hasil penggabungan.

Tapi kemudian, mungkin itu hanya keuntungan bagi orang-orang yang terlalu bodoh untuk menggunakan cabang terpisah (jika saya ingat dengan benar, kami hanya memiliki satu cabang yang digunakan untuk pengembangan kembali di perusahaan tempat saya menggunakan SVN).


10

EDIT: Ini terutama membahas bagian dari pertanyaan ini:
Apakah ini sebenarnya karena perbedaan yang melekat dalam bagaimana kedua sistem bekerja, atau melakukan implementasi DVCS spesifik seperti Git / Mercurial hanya memiliki algoritma penggabungan yang lebih pintar daripada SVN?
TL; DR - Alat khusus itu memiliki algoritma yang lebih baik. Didistribusikan memiliki beberapa manfaat alur kerja, tetapi ortogonal dengan keuntungan penggabungan.
AKHIR EDIT

Saya membaca jawaban yang diterima. Itu salah sekali.

Penggabungan SVN bisa jadi menyebalkan, dan juga bisa merepotkan. Tapi, abaikan cara kerjanya sebenarnya sebentar. Tidak ada informasi yang disimpan atau diperoleh Git bahwa SVN juga tidak disimpan atau dapat diturunkan. Lebih penting lagi, tidak ada alasan mengapa menyimpan salinan terpisah dari sistem kontrol versi akan memberikan Anda informasi yang lebih aktual. Kedua struktur ini sepenuhnya setara.

Asumsikan Anda ingin melakukan "sesuatu yang pintar" Git "lebih baik". Dan Anda diperiksa ke SVN.

Konversikan SVN Anda menjadi bentuk Git yang setara, lakukan di Git, dan kemudian periksa hasilnya, mungkin menggunakan beberapa komit, beberapa cabang tambahan. Jika Anda bisa membayangkan cara otomatis untuk mengubah masalah SVN menjadi masalah Git, maka Git tidak memiliki keunggulan mendasar.

Pada akhirnya, sistem kontrol versi apa pun akan mengizinkan saya

1. Generate a set of objects at a given branch/revision.
2. Provide the difference between a parent child branch/revisions.

Selain itu, untuk menggabungkan itu juga berguna (atau penting) untuk diketahui

3. The set of changes have been merged into a given branch/revision.

Mercurial , Git dan Subversion (sekarang secara native, sebelumnya menggunakan svnmerge.py) semua dapat memberikan ketiga informasi. Untuk menunjukkan sesuatu yang secara fundamental lebih baik dengan DVC, tunjukkan beberapa informasi keempat yang tersedia di Git / Mercurial / DVC tidak tersedia dalam SVN / VC terpusat.

Itu bukan berarti mereka bukan alat yang lebih baik!


1
Ya, saya menjawab pertanyaan secara detail, bukan judul. svn dan git memiliki akses ke informasi yang sama (sebenarnya biasanya svn memiliki lebih banyak), sehingga svn dapat melakukan apa pun yang git lakukan. Tapi, mereka membuat keputusan desain yang berbeda, jadi sebenarnya tidak. Buktinya pada DVC / terpusat adalah Anda dapat menjalankan git sebagai VC terpusat (mungkin dengan beberapa aturan yang diberlakukan) dan Anda dapat menjalankan svn terdistribusi (tetapi benar-benar menyebalkan). Namun, ini terlalu akademis bagi kebanyakan orang - git dan hg melakukan percabangan dan penggabungan lebih baik daripada svn. Itu benar-benar penting ketika memilih alat :-).
Peter

5
Hingga versi 1.5 Subversion tidak menyimpan semua informasi yang diperlukan. Wven dengan post-1.5 SVN informasi yang disimpan berbeda: Git menyimpan semua orangtua dari gabungan komit, sementara Subversion menyimpan revisi apa yang sudah digabung menjadi cabang.
Jakub Narębski

4
Alat yang sulit untuk diimplementasikan kembali pada repositori svn adalah git merge-base. Dengan git, Anda dapat mengatakan "cabang a dan b dibagi pada revisi x". Tapi svn menyimpan "file disalin dari foo ke bar", jadi Anda perlu menggunakan heuristik untuk mengetahui bahwa copy ke bar membuat cabang baru alih-alih menyalin file dalam suatu proyek. Kuncinya adalah bahwa revisi di svn didefinisikan oleh angka revisi dan jalur dasar. Meskipun mungkin untuk menganggap "trunk" sebagian besar waktu, itu menggigit jika sebenarnya ada cabang.
Douglas

2
Re: "Tidak ada informasi yang disimpan git atau dapat diperoleh bahwa svn juga tidak disimpan atau dapat diturunkan." - Saya menemukan bahwa SVN tidak ingat kapan semuanya digabung. Jika Anda suka menarik pekerjaan dari bagasi ke cabang Anda dan bolak-balik maka penggabungan bisa menjadi sulit. Dalam Git, setiap node dalam grafik revisi tahu dari mana asalnya. Ini memiliki hingga dua orang tua dan beberapa perubahan lokal. Saya percaya Git dapat menggabungkan lebih dari SVN. Jika Anda menggabungkan SVN dan menghapus cabang maka sejarah cabang hilang. Jika Anda menggabungkan di GIT dan menghapus cabang grafik tetap, dan dengan itu plugin "menyalahkan".
Richard Corfield

1
Bukankah itu kasus bahwa git dan lincah memiliki semua informasi yang diperlukan secara lokal, meskipun, sementara svn perlu melihat data lokal dan pusat untuk mendapatkan informasi?
Warren Dew

8

SVN melacak file sementara Git melacak perubahan konten . Cukup pintar untuk melacak blok kode yang dire-refored dari satu kelas / file ke yang lain. Mereka menggunakan dua pendekatan berbeda lengkap untuk melacak sumber Anda.

Saya masih menggunakan banyak SVN, tetapi saya sangat senang dengan beberapa kali saya menggunakan Git.

Bacaan yang bagus jika Anda punya waktu: Mengapa saya memilih Git


Itulah yang saya baca juga, dan itulah yang saya andalkan, tetapi dalam praktiknya tidak berhasil.
Rolf

Git melacak konten file, itu hanya menampilkan konten sebagai perubahan
Ferrybig

6

Baca saja sebuah artikel di blog Joel (sayangnya yang terakhir). Yang ini tentang Mercurial, tetapi sebenarnya berbicara tentang keuntungan dari sistem VC Terdistribusi seperti Git.

Dengan kontrol versi terdistribusi, bagian yang didistribusikan sebenarnya bukan bagian yang paling menarik. Bagian yang menarik adalah bahwa sistem ini berpikir dalam hal perubahan, bukan dalam hal versi.

Baca artikel di sini .


5
Itu adalah salah satu artikel yang saya pikirkan sebelum memposting di sini. Tetapi "berpikir dalam hal perubahan" adalah istilah yang terdengar tidak jelas pemasarannya (ingat perusahaan Joel menjual DVCS sekarang)
Tn. Boy

2
Saya pikir itu juga tidak jelas ... Saya selalu berpikir perubahan adalah bagian integral dari versi (atau revisi lebih tepatnya), yang mengejutkan saya bahwa beberapa programmer tidak berpikir dalam hal perubahan.
Spoike

Untuk sistem yang benar-benar "berpikir dalam hal perubahan", lihat Darcs
Max

@ Max: tentu saja, tetapi ketika push datang untuk mendorong, Git memberikan dimana Darcs pada dasarnya sama menyakitkannya dengan Subversion ketika datang untuk benar-benar bergabung.
tripleee

Tiga kelemahan dari Git adalah a) itu tidak begitu baik untuk binari seperti manajemen dokumen di mana sangat tidak mungkin orang ingin bercabang dan menggabungkan b) mengasumsikan Anda ingin mengkloning SEGALA SESUATU c) itu menyimpan sejarah segala sesuatu di klon bahkan untuk sering mengubah biner yang menyebabkan clone mengasapi. Saya pikir VCS terpusat jauh lebih baik untuk kasus penggunaan tersebut. Git jauh lebih baik untuk pengembangan reguler terutama untuk penggabungan dan percabangan.
locka
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.