svn - 如何理解git的分布式 分支
淡淡烟草味
淡淡烟草味 2017-04-26 09:01:40
0
6
887

看了Git官网的这一段介绍更加迷惑了

用 Git 的话,就算你在飞机或者火车上,都可以非常愉快地频繁提交更新, 等到了有网络的时候再上传到远程仓库。同样,在回家的路上,不用连接VPN 你也可以继续工作。换作其他版本控制系统,这么做几乎不可能,抑或非常麻烦。
链接地址》》》

假如

有一个商城项目正在上线,团队中有A、B、C三个程序员,使用git来进行版本控制。总共开发天数是10天,从第1天到第5天,A、B、C都是一起开发,一起提交,一个版本。但是到了第6天开始,C就不提交到远程了,一直都是在自己修改制作。整个项目很多文件,C会把项目中的文件GlobalFunction.php改动很多次,修改了很多函数,也加入了很多自己的函数。随着开发的继续,C还会不断的陆续修改GlobalFunction.php文件。而一直都提交到远程的A和B,也需要经常修改GlobalFunction.php文件,但是A和B会保持同步到Git远程。

合并

到了最后第10天,C可以联网了,然后C提交到远程。可C电脑里面的GlobalFunction.php 跟 Git远程上的 GlobalFunction.php 已经完全不一样了,而且远程的这个文件还经历过了二十多个版本。而C自己电脑里面的也经历过了几十个不同版本。

极大的疑惑

根据git介绍中的那一段的描述,这样的情况下,Git是可以自动合并?如何自动合并?

C已经在GlobalFunction.php中加入了很多函数且期间也经历过了很多次的版本。


补充

看到很多介绍Git的文章重点都放在了不需要push到远程,不需要联网就可以使用,真的觉得实在是难以理解。我在sf问也有很多人也在说不用push,/q/1010000000605934#c-1020000000606050-1050000000609657,更让人迷惑。不用push,假如1年或者10年了从来都不push到远程,那么还算是协同工作了吗,git会那么神奇10年之后再联网push过去还可以自动合并

淡淡烟草味
淡淡烟草味

membalas semua(6)
刘奇

Menolak senario secara melampau ialah cara yang tidak baik untuk berhujah.

Pertama sekali, apakah tujuan penyerahan? Jika ia hanya untuk menyegerakkan kod kepada orang lain, maka git benar-benar tidak mempunyai sorotan Malah penyerahan luar talian boleh disalah ertikan, yang merupakan kekurangan.

Saya secara peribadi berpendapat bahawa tujuan penyerahan adalah untuk menyimpan sementara kod (pengurusan versi untuk memudahkan pemulangan semula Shenma berikutnya), yang kedua adalah untuk berfungsi sebagai nod peringkat kod (fungsi ini selesai, serahkannya), dan yang ketiga ialah menyerahkannya ke pelayan Sync dan berkongsi dengan orang lain.

Penyerahan luar talian Git boleh mencapai satu atau dua tujuan di atas dengan baik. Dan kerana ia diserahkan di luar talian, anda boleh mengubah suai rekod penyerahan dengan mudah sebelum menyegerakkan dengan pelayan Apakah kegunaan ini? Sebagai contoh, saya menulis kaedah dan ia berfungsi, tetapi saya mahu memfaktorkannya semula, tetapi saya tidak pasti sama ada ia akan berfungsi dengan betul selepas pemfaktoran semula, jadi saya menyerahkan versi terlebih dahulu supaya saya boleh melancarkannya semula jika pemfaktoran semula rosak. Selepas saya selesai memfaktorkan semula, saya akan menyerahkannya semula. Pada ketika ini terdapat dua penyerahan fungsi yang sama, dan anda mungkin hanya mahu orang lain melihat satu penyerahan "fungsi XX selesai", supaya anda boleh menggabungkan kedua-dua penyerahan dengan mudah. Selepas penggabungan terakhir, repositori kod adalah sangat bersih Semua rekod penyerahan diserahkan kerana penyerahan ini boleh ditulis terus ke dalam nota keluaran tanpa "Ujian XXX" atau "Cuba XXX" muncul. Berdasarkan hasil yang sama, anda juga boleh menyerahkan kod yang ditulis sekali dalam beberapa kali Sebagai contoh, jika saya menulis tiga fungsi, saya boleh memilih untuk menyerahkannya tiga kali dan akhirnya menyegerakkannya ke pelayan SVN, anda (tulis bila tiada rangkaian Kod) hanya boleh diserahkan sekali, dan kemudian tulis "Lengkapkan tiga fungsi A, B dan C Ini tidak sesuai untuk orang lain melihat kod anda, dan juga tidak sesuai untuk melancarkan semula A, B,". dan C masing-masing.

Jadi penyerahan luar talian git membawa fleksibiliti. Ini tidak bermakna bahawa dengan penyerahan luar talian, saya tidak memerlukan pelayan, Air akan secara automatik menyelesaikan kerja kerjasama untuk saya. Inilah yang saya maksudkan apabila saya berkata pada mulanya, "Menolak adegan ke tahap yang melampau adalah kaedah hujah yang buruk." Berbanding dengan svn, git mempunyai lebih banyak kaedah kolaboratif dan lebih fleksibel, tetapi ia tidak dapat mengelakkan masalah kerjasama Anda masih perlu bekerjasama dan menggabungkan kod.

Dalam proses penggabungan kod, sama seperti SVN, konflik juga akan dihadapi, jadi masih merupakan tabiat yang baik untuk menyegerakkan kod dengan pelayan tepat pada masanya jika keadaan membenarkan. Walau bagaimanapun, memandangkan git ialah versi penjejakan berasaskan kandungan dan svn ialah versi penjejakan fail asas, git merge adalah lebih dipercayai daripada svn Iaitu, dalam keadaan yang sama, git kurang berkemungkinan menghadapi konflik berbanding svn.

Akhir sekali, disebabkan oleh ciri penyerahan luar talian git, dan fakta bahawa cawangan git sangat mudah digunakan, anda juga boleh melaksanakan fungsi pengurusan berbilang cawangan tempatan, iaitu, apabila anda mengusahakan fungsi, anda boleh buka cawangan secara tempatan dan kemudian serahkannya secara setempat , dan kemudian gabungkannya dan tolaknya ke pelayan Bagi yang lain, cawangan ini tidak wujud, tetapi untuk anda, anda boleh menukar status kerja pada bila-bila masa (tulis ciri baharu atau tukar semula. untuk membetulkan pepijat). SVN juga boleh memotong cawangan, tetapi cawangannya tidak boleh hanya wujud secara tempatan Jika kerjasama cawangan diterima pakai, akan ada banyak cawangan, yang sesetengahnya tidak perlu diambil berat oleh orang lain. Apa yang lebih menyusahkan ialah jika anda sedang menulis ciri baharu dan perlu kembali dan membetulkan pepijat, anda hanya boleh menyerahkan kod yang belum selesai kepada pelayan svn Pada pendapat peribadi saya (serahkan kod yang belum selesai kepada pelayan repositori). Ini adalah tingkah laku yang sangat buruk, tetapi dengan git, kerana cawangan di luar talian, selepas saya menyerahkannya, saya beralih kembali untuk membetulkan pepijat, kemudian beralih kembali semula, dan selepas fungsi selesai, saya menggabungkan rekod penyerahan dan semuanya sempurna.

巴扎黑

Jika kedua-dua pihak menukar fail yang berbeza, atau bahagian yang berbeza pada fail yang sama, git boleh menggabungkannya secara automatik.

Jika bahagian yang sama pada fail yang sama diubah suai, git tidak boleh bergabung secara automatik Keadaan ini dipanggil "konflik". Ya C), edit secara manual.

Dalam pembangunan sebenar, jika dua orang hanya menambah fungsi pada fail ini, mereka boleh digabungkan secara automatik Konflik berlaku terutamanya apabila baris yang sama diubah suai.

Jawapan untuk tambahan:

Banyak pengenalan menekankan bahawa git boleh dilakukan di luar talian, yang bertujuan untuk dibandingkan dengan svn. Dalam svn, hanya pelayan yang mempunyai repositori lengkap, dan sejarah kod pelanggan tidak lengkap. Setiap pelanggan dalam git ialah repositori lengkap, dan operasi tolak dan tarik sebenarnya penyegerakan antara berbilang repositori lengkap.

Kelebihannya ialah anda tidak takut pelayan ditutup atau hilang Semua orang mempunyai perpustakaan versi lengkap Ini juga merupakan titik permulaan untuk Linus membangunkan git (Linux ialah projek sumber terbuka untuk diedarkan berbilang orang. kerjasama).

迷茫

Akhirnya saya ada soalan yang boleh saya jawab dengan baik

Mula-mula mari kita bincangkan tentang hipotesis soalan:

C berhenti berinteraksi dengan alat kawalan jauh dari hari ke-6 dan mula bermain sendiri Apakah ini? Ini tidak diedarkan bermakna apabila rangkaian itu tersedia tidak bermakna ia tidak disegerakkan dengan alat kawalan jauh selepas beberapa hari

Memandangkan fail dipanggil

, maka fail ini jarang diubah suai (atau baris yang sama jarang diubah suai), serupa dengan GlobalFunction.php di bawah Python, kadangkala ia hanyalah yang baharu. Anda hanya akan mengubah suai pembolehubah setup.py apabila versi dikeluarkan version

Pemahaman peribadi saya tentang konsep cawangan GIT ialah pembangunan kolaboratif boleh dijalankan dengan lebih cepat berdasarkan satu atau beberapa cawangan Contohnya, sebuah gudang

mempunyai cawangan yang dipanggil: foo, kemudian A, B. , dan C boleh menjalankan pembangunan kolaboratif Kadangkala cawangan tempatan akan dibuat secara tempatan berdasarkan cawangan biasa ini master Contohnya, cawangan tempatan A dipanggil master, B dipanggil: a-dev dan C dipanggil <.>. Bagaimana ia terhasil? b-dev

git checkout -b xxx origin/master # xxx 代表 `a-dev` 等
c-dev

Kedua, mari kita bincangkan tentang penggabungan yang disebutkan oleh soalan:

Jika C membuat cawangan tempatan

secara tempatan berdasarkan

, maka C sentiasa boleh mengemas kini cawangan induk tempatan tanpa menjejaskan cawangan tempatan master (dan pada masa ini anda sentiasa boleh berada di c-dev cawangan): c-dev

git pull origin master:master
c-devJadi jika tempatan dikemas kini, bagaimanakah ia akan ditunjukkan dalam

? Mudah sahaja, GIT telah memikirkannya untuk anda: master

git rebase master # 此时你在 `c-dev` 分支
c-devSelepas melepasi perkara di atas, hanya terdapat dua situasi yang mungkin berlaku: 1. Konflik gabungan berlaku, gagal; 2. Tiada konflik (mungkin secara automatik

), tempatan rebase status terkini berbeza daripada tempatan merge Gabung master c-devUntuk kejadian 1, GIT tidak akan menyelesaikan konflik secara automatik, tetapi ia boleh cuba bergabung secara automatik (

Jika gagal, ia dipanggil konflik biasanya merujuk kepada penyerahan berbeza yang mengubah suai yang sama). fail fail yang sama (beberapa baris) kandungan memerlukan pembangun untuk menyelesaikan konflik sendiri

mergeRingkasan Peribadi

Cawangan ialah ciri pembunuh GIT yang membezakannya daripada sistem kawalan versi berpusat yang lain (

);
黄舟

Apabila konflik berlaku, SVN membandingkan baris demi baris, manakala Git merekodkan operasi, seperti menambah baris, memadam baris atau mengubah suai baris, supaya proses cantuman lebih mudah

大家讲道理

Masalah yang anda nyatakan hanya boleh diselesaikan melalui cawangan

小葫芦

Ringkasnya, mungkin atau mungkin tidak boleh digabungkan secara automatik.
Setiap komit dalam Git menyimpan perbezaan Anda hanya boleh git tunjukkan komit dan lihat. Perbezaan akan cuba memadankan beberapa baris sebelum dan selepas baris asal yang diubah suai Jika ia boleh sepadan, perbezaan boleh digabungkan secara automatik.
Sebagai contoh, jika tampung C mengubah suai nilai dalam baris kelima, ia tidak komited. A dan B telah menambah fungsi baharu pada GlobalFunction.php Fungsi ini ditambahkan pada penghujung fail Kemudian apabila C bergabung, Git boleh melengkapkan penggabungan melalui cherry-pick.
Jika kedua-dua pihak telah mengubah suai tempat yang sama, konflik itu perlu diselesaikan secara manual.

Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan