git的示例分析

這篇文章將為大家詳細(xì)講解有關(guān)git的示例分析，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

集中式版本控制工具

而版本控制工具其實(shí)有兩種,一種就是今天談到的Git這種分布式版本控制工具，而另外一種就是SVN這種集中式版本控制工具。SVN的大名可能很多人都聽說過，集中式這個(gè)詞其實(shí)已經(jīng)可以體現(xiàn)這種版本控制工具的缺點(diǎn)，集中式版本控制工具必須聯(lián)網(wǎng)才能使用，而且版本庫都有一個(gè)單一的集中管理的服務(wù)器，用于管理所有文件的所有修改版本，我們工作之前需要先從中央服務(wù)器取得最新的版本，然后進(jìn)行修改，當(dāng)我們修改完成之后，肯定要將我們的更新回傳到SVN進(jìn)行更新版本庫。這時(shí)候如果有其他同事先于你之前更新，可能會報(bào)錯(cuò)：改動基于過時(shí)的版本，先更新再提交。所以說使用SVN這類集中式版本控制工具會導(dǎo)致一個(gè)問題：先完成工作的先更新不會出現(xiàn)問題，后完成工作的還得處理舊版本導(dǎo)致的代碼沖突問題。這些都是SVN的缺點(diǎn)所在，但是SVN這類集中式版本控制工具最致命的缺點(diǎn)在于如果集中管理版本庫的中央服務(wù)器出現(xiàn)問題，而又沒有及時(shí)備份，有可能導(dǎo)致丟失整個(gè)項(xiàng)目的所有歷史更改記錄。

分布式版本控制工具

說完了集中式版本控制工具，接下來我們說說分布式版本控制工具。分布式版本控制工具最為流行的就是Git。分布式版本控制工具可以在每個(gè)人的電腦中創(chuàng)建一個(gè)完整的版本庫，因此分布式版本控制工具集中不需要存在一臺統(tǒng)一管理版本庫的服務(wù)器。那我們針對剛才說過的SVN的缺點(diǎn)來說明為什么我們要采用Git。

Git如何協(xié)同合作

剛才說過集中式版本控制工具必須聯(lián)網(wǎng)才能使用，而且版本庫都有一個(gè)單一的集中管理的服務(wù)器，用于管理所有文件的所有修改版本，但是Git實(shí)際上在本地磁盤就保存著項(xiàng)目的所有歷史更新版本，而且由于Git大部分都是操作本地資源所以完全不需要聯(lián)網(wǎng)操作。Git其實(shí)一般也會存在一臺電腦充當(dāng)中央服務(wù)器的功能，但是實(shí)際上這臺中央服務(wù)器不是用于統(tǒng)一管理版本庫，而是用于同事之間交換修改使用。比如你將你的版本庫提交到中央服務(wù)器，你的同事想要同步你的代碼只需要將中央服務(wù)器的版本庫pull下來與本地代碼進(jìn)行合并就可以，當(dāng)同事工作完成上傳中央服務(wù)器，我們也只需要pull代碼進(jìn)行合并，就可以在同事間很輕松的實(shí)現(xiàn)版本庫的同步。剛才說到SVN有一個(gè)缺點(diǎn)：先完成工作的同事先更新不會出現(xiàn)問題，后完成工作的同事還得處理舊版本導(dǎo)致的代碼沖突問題。但是在Git中不會出現(xiàn)這種提交競賽，不同同事可以依次提交自己更新的部分，就算使用的版本庫已經(jīng)是舊版的一樣可以上傳，會在使用的舊版本的基礎(chǔ)上新開一個(gè)分支，然后每次更新都會更新到這個(gè)分支，到某一天這個(gè)功能完全實(shí)現(xiàn)了，然后將幾個(gè)同事開發(fā)的幾個(gè)分支合并到主分支就可以進(jìn)行合并代碼。我們舉個(gè)例子解釋下：比如有三個(gè)同事同事基于某個(gè)v1.0.0版本開發(fā)，A同事更新代碼后更新成功，B同事更新代碼，由于A已經(jīng)更新了版本，所以這時(shí)候我們可以有兩個(gè)選擇，第一種就是鋼刺啊說的pull代碼與本地代碼合并再提交，或者這時(shí)候由于各自負(fù)責(zé)的功能還在開發(fā)，我們可以在這個(gè)v1.0.0的版本上創(chuàng)建一個(gè)新的分支，進(jìn)行版本的更新迭代。一個(gè)月后整個(gè)功能完成了，這時(shí)候我們就可以合并三個(gè)同事的三個(gè)分支成為一個(gè)分支。

Git如何讓做好備份工作

我們剛才一直在說Git在本地創(chuàng)建版本庫，那版本庫存儲在本地磁盤，本地磁盤出問題我的所有版本庫不就直接全部丟失了。我們可以這樣操作：比如在D盤創(chuàng)建一個(gè)版本庫，然后在F盤創(chuàng)建一個(gè)備份版本庫，每次提交push到備份版本庫，就可以實(shí)現(xiàn)版本庫備份。

Git的優(yōu)勢

Git 和 Svn 的分支實(shí)現(xiàn)機(jī)制完全的不同，這也直接導(dǎo)致了 SVN 在分支合并中困難重重。當(dāng)我們使用SVN中在一個(gè)分支上工作數(shù)周或幾個(gè)月之后，主干的修改也同時(shí)在進(jìn)行著，兩條線的開發(fā)會區(qū)別巨大，當(dāng)你想合并分支回主干，可能因?yàn)樘鄾_突，已經(jīng)無法輕易合并你的分支和主干的修改。而在 git 版本庫中創(chuàng)建分支的成本幾乎為零，所以可以創(chuàng)建一個(gè)屬于自己的個(gè)人工作分支，以避免對主分支 master 造成太多的干擾，也方便與他人交流協(xié)作。當(dāng)最后功能完成最后需要合并分支來合并別人修改的時(shí)候，最好創(chuàng)建一個(gè)臨時(shí)的分支用來合并，合并完成再fatch到自己的分支。

Git的缺點(diǎn)

• 中文完整的Git學(xué)習(xí)資料較少。

• 學(xué)習(xí)周期比較長。

• 代碼一經(jīng)pull，就可以完全公開源碼和版本信息。

關(guān)于“git的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯(cuò)，請把它分享出去讓更多的人看到。