您好,登錄后才能下訂單哦!
Source code control 一直是軟件開發過程中重要的環節,從最初的純文件備份,到使用工具進行管理。Source code control 工具的作用也不僅僅只是單純的對同一個版本進行管理了。從目前主流的source code control工具當中不難發現里面的Branch, tag等功能的應用場景越來越多,特別是現在多數企業使用的敏捷編程,結合branch和tag等功能真的能夠很好的做到多版本開發,快速迭代。
思考: 沒有source code control我們如何快速的基于一份代碼同時進行多個功能的并行開發。
回過頭來說下本人在行業當中所用到的幾款source code control工具。
VSS(Visual Source Salf),是一款微軟提供的代碼管理工具,作為Visual Studio的一員,在早期的開發過程當中確實能夠確保代碼不被開發人員錯誤的修改,也解決了異地開發協作的代碼共享管理的難點。但是依舊有一些不足,比如:
文件基本以獨占的形勢進行鎖定。如果A在修改的時候B沒有辦法進行修改。
VSS只支持Windows版本,支持的開發工具僅支持微軟系。
基于文件存儲,服務器必須共享文件夾。安全性值得考慮。以前一般用于內網開發環境。
收費
SVN(Subversion),一個開源的source code control system。除開最基本的如VSS提供的代碼管理功能外,最大的亮點是提供了分支,且提交內容的級別基于代碼行了。也就是說,不用再有獨占文件開發的問題了。比如,一個實現接口的代碼文件可以由多個開發人員同時修改。誰先做完誰可以先進行提交,不會等到必須所有的人做完后再進行合并。對于不能使用VSS的工程師來說,SVN的出現完全是一個福音,直接從CVS跳到了這么強大的工具上。
總結一下,SVN的優劣如下:
優勢:
代碼一致性高。
支持提交事物性操作。
Diff 功能。
Branch,Tag的引用,方便版本管理。
輕松上手。
劣勢
必須是聯網狀態下才可以進行一些數據的讀取。
不是分布式的代碼庫。
SVN服務器崩潰的災難是巨大的。
隨著開源運動的流行(Liunx開發人員的功勞),Git也就這么流行起來的。說是在隨著開源運動的流行而流行起Git的呢?這歸功于Git的分布式這一特性。試想,如果全世界所有的Liunx愛好者都在幾臺機器上進行開發和提交,這酸爽不敢想象。抑或是主服務器崩潰了,那么其他的開發人員也只有淚奔。
Git的牛逼之處在于以下:
每一次Clone就是從服務器上pull到了所有的內容,包括版本信息。
在本地可以根據不同的需要,本地新建自己的分支。
分支之間的任意切換。
單機上就可以進行分支合并。
牛人+插件加持。 Git flow, 按Vincent Driessen 分支模型提供的一個插件.
git-model@2x.png
A successful Git branching model
安裝
$ Brew install git
創建倉庫
$ git init
文件操作
有了倉庫后就可以對文件進行 add , commit, push 和pull等操作了。
Tables | Are |
---|---|
git add | 添加至暫存區 |
git add–interactive | 交互式添加 |
git apply | 應用補丁 |
git am | 應用郵件格式補丁 |
git annotate同義詞,等同于 git blame | |
git archive | 文件歸檔打包 |
git bisect | 二分查找 |
git blame | 文件逐行追溯 |
git branch | 分支管理 |
git cat-file | 版本庫對象研究工具 |
git checkout | 檢出到工作區、切換或創建分支 |
git cherry-pick | 提交揀選 |
git citool | 圖形化提交,相當于 git gui 命令 |
git clean | 清除工作區未跟蹤文件 |
git clone | 克隆版本庫 |
git commit | 提交 |
git config | 查詢和修改配置 |
git describe | 通過里程碑直觀地顯示提交ID |
git diff | 差異比較 |
git difftool | 調用圖形化差異比較工具 |
git fetch | 獲取遠程版本庫的提交 |
git format-patch | 創建郵件格式的補丁文件。參見 git am 命令 |
git grep | 文件內容搜索定位工具 |
git gui | 基于Tcl/Tk的圖形化工具,側重提交等操作 |
git help | 幫助 |
git init | 版本庫初始化 |
git init-db* | 同義詞,等同于 git init |
git log | 顯示提交日志 |
git merge | 分支合并 |
git mergetool | 圖形化沖突解決 |
git mv | 重命名 |
git pull | 拉回遠程版本庫的提交 |
git push | 推送至遠程版本庫 |
git rebase | 分支變基 |
git rebase–interactive | 交互式分支變基 |
git reflog | 分支等引用變更記錄管理 |
git remote | 遠程版本庫管理 |
git repo-config* | 同義詞,等同于 git config |
git reset | 重置改變分支“游標”指向 |
git rev-parse | 將各種引用表示法轉換為哈希值等 |
git revert | 反轉提交 |
git rm | 刪除文件 |
git show | 顯示各種類型的對象 |
git stage* | 同義詞,等同于 git add |
git stash | 保存和恢復進度 |
git status | 顯示工作區文件狀態 |
git tag | 里程碑管理 |
.
.
建議使用github進行上手實驗。使用郵箱注冊一次Git hub后即可在Github上創建自己的Repository.
2.png
創建完成后,我們會得到一個Repository的地址。有了這個地址我們就可以進行Git的練習了。
3.png
使用 git clone 將遠程倉庫clone到本地。
git clone
5.png
添加一些文件
echo "Hello Scott" -> "Hello" //寫了一個文件到Hello git add Hello // 將Hello文件添加到暫存區。(Index) git commit -m "this is my first file" // 提交到本地倉庫 git push //推送本地倉庫到遠程倉庫
6.png
以上,文件就被推送到了遠程倉庫。其他工程師如果執行Pull操作的話即可把變動的文件拉到本地。
7.png
如果有其他工程師修改了文件,需要遠程獲取下。
git pull //拉取遠端文件 git log //可以查看變更歷史
A5B85BFD-764E-468F-81C4-0B727BA70428.png
沖突的解決
沖突往往是因為版本不一致而產生。如工程師A修改了Hello文件并提交到遠端倉庫,而B在本地修改了Hello,也想提交。由于A和B的Hello文件并不一致,所以沖突產生了。
4EB9EB75-2FF9-4363-AD78-9E13D1415EA8.png
只需要git pull一次即可。 (注:git pull 會自動merge,但是通常情況下自動merge效果不會太好。比如A和B 都在修改function A (){} )
沖突長這模樣。
10.png
一般手動解決沖突后,重新添加,提交,push即可。
11.png
如上描述,手動合并沖突比較麻煩。建議使用工具進行git 的操作,現在一般的工具都提供了分支管理,合并等功能。
推薦 SourceTree
在很多時候會遇到同時需要開發多個功能,開發任務將會交給多個工程師進行開發,這個時候在Git上的實踐為-->創建多個分支。 N個工程師從Master或Dev分支進行分支創建。
git checkout -b NewFeature // 分支建好后,會直接切換到該分支。git push --set-upstream origin NewFeature //與遠程分支關聯
完成開發后,需要合并到Master 或Dev 分支。
git merge origin/NewFeature // 將遠程分支NewFeature與當前分支合并。
12.png
寫在最后
以上從source code control擴散到Git的使用,僅僅只是拋磚引玉。歡迎大家多多指教。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。