一: 代碼管理工具,將本地項目同步至新建的git倉庫
對於一個使用過SVN, TFS, GIT等多種常用代碼管理工具的開發者來說,個人還是更鐘情於GIT。
其中基於git的平臺又有很多,gitButket(需翻牆),github(需翻牆),gitlab, 碼雲(支持git和svn)等。
基於當前情況,這裏着重講講gitlab這個平臺,當然除了平臺自己個性化的一些操作,git命令當然是通用於git的各大平臺的。
1.安裝git環境,註冊gitlab賬號
這個就不多說了,git官網下載對應的git安裝包安裝就好了。
gitlab的話在官網註冊賬號,然後創建一個新項目倉庫。
創建項目的時候你可以選擇這個項目是屬於group還是user,團隊項目建議選擇group(group需要提前創建),個人項目建議選擇user。
項目的可見等級(就是權限)也可以選擇:private/internal/public, 當然創建完之後可以修改。
創建完畢,頁面如下。
現在進行第二步 =》
2.將本地項目文件提交到已經創建好的git項目倉庫
對於新的git項目倉庫,有三種情況:
1, 創建新版本庫(沒有本地項目文件夾,也沒有之前創建過的git倉庫);
2,已存在的文件夾(本地已經有了項目文件夾,但沒有同步到git,需要將本地的項目文件夾同步至新創建的git倉庫);
3,已存在的 Git 版本庫(本地已經有之前同步到別的git倉庫的項目文件夾,需要將它同步到新的git倉庫)(或者直接clone新的代碼倉庫到本地,然後對該倉庫的代碼進行修改)
通常,我們都是第二種情況。將本地已經存在的項目文件夾同步到新的git倉庫,所以這裏以第二種來講解:
1,首先要做的,是對git進行git賬號的全局配置“:
git config --global user.name "your userName" // 設置賬號名
git config --global user.name "your password" // 設置密碼
git config --global user.email "your email account" // 設置賬號對應郵箱
git config --global credential.helper store //保存賬號信息到git配置文件
git config --list // 查看git配置信息
2,按順序執行下列命令:
cd existing_folder //切到項目文件夾
git init //初始化git 生成。在項目文件夾中生成.git文件夾
git remote add origin http://192.168.16.58:9000/chengrong.luo/test.git 關聯到遠程倉庫地址
git add . // 將項目文件夾下所有文件添加進git緩存區,準備commit
git commit -m "Initial commit" // 將所有已經state的待commit的文件commit到已經關聯的遠程倉庫, 並添加註釋:Initial commit
git push -u origin master // 將commit 推送到已經關聯的遠程倉庫的master主分支下
同步完成,在gitlab中已經能看到所有推送的記錄了:
至此,本地項目文件夾已經全部同步到了新建的gitlab倉庫。
tips:
(1): 本地項目同步至git倉庫之後,本地會生成一個.gitignore文件,在這個文件裏,你可以將項目文件夾中不需要同步到git遠程倉庫的文件或者文件夾標記出來,這樣如果你修改了這些文件,它也不會出現在你的commit裏面。
(2): 儘量給每個項目添加README.md文件,並且同步到git遠程倉庫。
3. 通過ssh的方式管理git倉庫代碼
git 管理項目代碼通常有兩種方式: ssh協議和http協議,http協議上面已經介紹過,下面簡單再介紹下ssh協議的方式。
一般在gitlab首頁,創建一個新的項目倉庫之後,它都會給你上面的提示,爲你的項目添加一個ssh key。
一般你clone一個倉庫代碼到本地,你可以選擇http協議的克隆地址,也可以選擇ssh的克隆地址。http協議的地址,只要你配置好賬號密碼和郵箱,就能正常工作了。
但是ssh協議的地址,你需要配置ssh key,也就是ssh 公鑰,這是git ssh協議一種比較安全的認證方式。
點擊上面的 add a ssh key 鏈接,進入配置主頁。
點擊生成密鑰,裏面有具體的生成密鑰的方式。
複製到了生成的密鑰字符串之後,把它粘貼到生成密碼的主頁的密鑰輸入框,取個標題,然後點擊增加密鑰,就ok了,現在ssh協議的地址就能使用了。
二,使用gitlab和git 命令進行項目分支和代碼管理
1. git branch(分支) 管理
當你將一個本地項目完全同步至git遠程倉庫之後,你就可以開始放心地coding了。
首先,每個項目都默認會有一個名叫‘master’的主分支,所謂主分支,也就是所有git分支的主幹。
然後,我們可以base 主分支 master 創建任何分支。
創建分支的原則:
(1): 命令規範
儘量在每個分支前加上類別,一般分爲:
feature/ : 功能性分支,當你添加一個功能或者一個功能模塊的時候,創建這類分支;
bugfix/ (hotfix): bug修復性分支,當你需要修復某個或者某幾個分支的時候,創建這類分支;
develop/: 單純的開發分支,比如一些你覺得不算是feature也不算bugfix的分支,就可以在這個分支下;
release/:當項目已經到了release的階段, 可以創建對應的release版本的分支對不同的release版本進行維護
分支名儘量用關鍵詞描述出該分支的主要用途或目的,如:
feature/loginUIApiImplement
bugfix/loginFailedIssueFixing
(2):儘量減少分支之間的依賴
如果是單人開發項目,那麼分支比較好管理,一般只需要保持一個或兩個分支即可,一個feature分支,一個bugfix分支。
如果是團隊開發項目,則儘量避免多人在同一個分支上開發的情況。一個人保持一個或兩個分支。
保持分支獨立的好處就是減少代碼衝突的出現,避免不合適的代碼影響其他分支或者主分支
(3): 永遠儘量避免在master主分支上直接開發,master作爲主分支,要保持最穩定。如果有release的版本,那麼也避免直接在release分支上直接開發,應當base release創建新分支,然後合併分支到release,然後再決定要不要將release上的改動合併到master上。
分支代碼管理
(1)創建新分支:
gitlab: 可以基於master或者其他分支創建新的分支,但一般都是基於master創建分支,或者基於release版本分支
gitlab上創建完分支之後,在本地git terminal終端運行: git fetch, 獲取創建的分支,然後運行: get checkout 分支名,將當前本地工作分支切換到新創建的分支,在分支上進行工作。
git:當然也可以直接在git terminal終端運行: git branch 分支名 直接在本地創建新分支,當然也是需要基於master(先checkout master)
需要注意的是,這種方法創建的分支,最後在你提交修改的代碼之前,你需要發佈該分支,運行命令: git publish
tips:
儘量在每次創建分支之前,pull 最新的master主分支上的代碼到本地,保證你目前創建的分支已經擁有了master上最新的代碼
(2):提交分支代碼
在你覺得已經完成某個分支的代碼修改或者部分代碼修改之後,運行git add . 和 git commit 提交本地修改的代碼,然後再運行git push, 將commit push到git遠程倉庫對應的分支上。
tips:
1,儘量及時提交代碼更新到git倉庫,意外引起修改的代碼丟失或者被回滾
2,儘量在每次commit的時候,填寫本次提交更新的內容描述
(3):合併分支到master主分支
在你已經完成了該分支的所有修改或者階段性的修改之後,且經過初步測試之後,及時合併分支至主分支。
gitlab: 創建pull request, 將子分支以pull請求的方式,merge到master
選擇來源分支,當然就是你想要合併的那個分支,再選擇目標分支,默認就是master了,
點擊比較分支後繼續,進入pull request詳情頁面。
填寫pull request 標題和描述,然後再關注一下下面的幾個可選項:
其中指派這個選項值得一提,如果是團隊開發項目,一般這個指派可以指派給相關的項目同事,讓他們對你即將合併到主分支的代碼進行review和comment,如果對方覺得你提交的代碼有問題,或者代碼會影響到主分支的其他功能,添加原因之後可以拒絕你的pull 請求,你需要重新對有問題的代碼進行優化,然後再次提交你的代碼。你可以刪除之前的pull request,新建一個pull request,再次指派給相關人員,也可以在原來的pull request,讓相關人員第二次審查你改進的代碼,再決定該pull reqeust 能不能合併到master。
當然,你還可以在這個頁面再次修改目標分支。
特別地,如果你在此次pull request 合併完之後,不再需要再這個分支上工作了,建議勾選選項:接收合併請求後刪除來源分支。
這樣,保持分支樹的乾淨和簡潔。
點擊提交合並請求之後,被你指派過的同事,就能在他的gitlab上收到通知,然後開始review你提交的代碼。
這裏,可能會碰到的問題:代碼衝突。
如果有新的代碼在你之前合併到了master主分支,且該代碼修改的地方和你在這次pull request中要合併的代碼有重疊的地方,那就會產生代碼衝突,那麼你需要先解決衝突才進行pull request的合併操作。
你可以按照如下步驟解決衝突,然後將解決完衝突的代碼重新提交:
當然,你還可以在本地使用git圖形化工具(推薦sourceTree)或者IDE自帶git插件進行手動解決代碼衝突。
其實,我們是最不想在合併pull reqeust的時候看到代碼衝突這種情況出現的,那麼如何避免這種情況出現呢?
1:在你推送完本地代碼更新到遠程git倉庫對應的分支之後,在創建pull request 之前,我們先進行 git rebase master 的操作,當然你要保證已經獲取到了最新的master到本地。
也就是說,你把別人已經提交到master的新代碼,也獲取到你的分支上來,或者換一種說法,把你在分支上的修改提交到已經被別人修改過的master上去,但是不會改動master,而是基於你自己的分支。
這個時候,也有可能會存在衝突,但是沒關係,這個時候你在本地解決掉衝突,然後 git add . 再git rebase --continue,這樣解決衝突之後的你的分支,已經可以合併到master了,合併的過程中不可能再產生衝突。
注意:如果你在手動解決衝突的時候由於各種原因沒有解決成功,導致重新提交的代碼不對,沒關係,你隨時可以執行 git rebase --abort 種植本次git rebase, 再重新執行 git rebase。
執行 git rebase的操作還有一個很重要的好處就是, 保證分支的合併歷史不分叉,在一條直線上。
2:如果不可避免地,多個人同時工作在了一個分支上,那麼你需要在每次git commit之後,執行git pull, 有衝突再解決衝突,然後再git push。或者你可以在git commit之後,直接執行 git pull --rebase,這樣能保證分支的提交歷史樹在一個直接上,不會存在分叉。
所以,儘量做完上面的1或者2的步驟之後,再進行分支的合併操作。
git: 當然,純git 命令操作,進行分支的合併也是可以的。
git commit 之後,如果有別人和你工作在同一個分支
再執行 git pull --rebase(有衝突解決衝突,然後 git push);
如果有別人在master上在你之前提交過,執行git rebase master, 有衝突解決衝突, 再git rebase --continue。
最後:
git checkout master
git merge feature
總結:
1,儘量避免多人在同一個分支工作
2,儘量在合併分支之前,獲取到分支和master最新的代碼
3,儘量讓分支樹在一條直線上
tips:
可以使用git cherry pick , 將某個分支上的某個commit 複製到別的也需要應用此次commit的分支上
歷史提交/合併請求查看
gitlab上,你可以查看所有提交歷史,也可以查看所有創建過的pull requst,進行代碼的回滾查看。如果碰到某個bug重複出現或者某些已經有的功能突然缺失,可以通過查看提交歷史或者歷史 pull請求,快速定位到有問題的提交歷史上。
三.使用sourceTree(Git GUI)進行代碼管理
sourceTree是一個非常好的Git GUI工具,而且是免費的。基本上可以操作任何git命令,也可以非常簡便地管理遠程和本地的倉庫分支,清晰的查看分支樹,完成整個git工作流。
官網:https://www.sourcetreeapp.com/
不過,註冊sourceTree,一般都需要綁定對應的bitbucket賬號,但是bitbucket又需要VPN。
所以註冊sourceTree的時候,需要跳過綁定bitbucket的步驟進行註冊。
方法:
關閉註冊窗口,打開sourceTree安裝目錄 \AppData\Local\Atlassian\SourceTree,創建accounts.json文件,並修改accounts.json內容如下:
[
{
"$id": "1",
"$type": "SourceTree.Api.Host.Identity.Model.IdentityAccount, SourceTree.Api.Host.Identity",
"Authenticate": true,
"HostInstance": {
"$id": "2",
"$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountInstance, SourceTree.Host.AtlassianAccount",
"Host": {
"$id": "3",
"$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountHost, SourceTree.Host.AtlassianAccount",
"Id": "atlassian account"
},
"BaseUrl": "https://id.atlassian.com/"
},
"Credentials": {
"$id": "4",
"$type": "SourceTree.Model.BasicAuthCredentials, SourceTree.Api.Account",
"Username": "",
"Email": null
},
"IsDefault": false
}
]
接着 \AppData\Local\Atlassian這個目錄下,
第二個目錄,接着進入"3.1.3.3158"目錄,打開user.config文件,在裏面加入六行代碼:
<setting name="AgreedToEULA" serializeAs="String">
<value>True</value>
</setting>
<setting name="AgreedToEULAVersion" serializeAs="String">
<value>20160201</value>
</setting>
保存,然後重啓sourceTree,打開之後自動就能跳過註冊界面了。
如果再彈出Mercurial詢問窗口,可以根據實際情況做相應的選擇,比如使用默認選項下載Mercurial,或者使用第四個選項“我不想使用Mercurial”。
四:使用Jira, 禪道等協同辦公平臺進行項目管理
曾經用過三個平臺進行bug管理: Woktile, Jira, 禪道,其中最好用的是Jira,但是是國外的平臺,所以也需要VPN。
所以主要還是說說禪道。
1,任務創建
一般一個項目創建之後,項目負責人或者其他相關人員可以進行根據需求或者功能模塊,創建相關的任務。
一個任務可以是一個大的功能模塊,也可以是一個小接口的開發,儘量讓任務之間相對獨立,這樣不同的任務可以分配給不同的人員開發。
創建任務的時候,可以關聯相關功能需求;
可以添加相關附件圖片等,讓接收任何的人清楚該任務要達到 的目的和效果;
也可以創建任務的優先級,這樣開發人員可以根據任務優先級順序選擇任務進行開發。
2, bug處理
一般bug由測試人員創建,然後bug指派給相關開發人員。
開發人員領到bug之後,在我的地盤-我的bug看到bug數量會增加,然後在‘指派我的bug’面板中,看到具體的bug列表。開發人員可以根據bug優先級去激活bug。
如果開發人員對bug沒有疑問,可以點擊確認bug,並在備註框中輸入你針對該bug給出的解決方案。
如果你對bug有疑問,可以對bug進行編輯,添加你的疑問,抄送給提bug的測試人員。
如果你覺得bug不該指派給你,你可以指派回相關測試人員或者你覺得該負責解決該bug的開發人員,並在備註中說明理由。
在你解決完bug之後,你可以點擊已解決,確認你的解決方案,必要時上傳Bug解決完之後的效果圖。
再有必要,你還可以貼出你解決該bug的pulll request的鏈接,這樣如果相關人員對該bug的解決方案有疑問,也可以直接瀏覽你解決該bug時修改的代碼。
3,看板
你可以在項目有的看板頁面,查看所有bug的狀態。
五,使用jenkins對項目工程自動化部署
Jenkins是一個開源的、可擴展的持續集成、交付、部署(軟件/代碼的編譯、打包、部署)的基於web界面的平臺。允許持續集成和持續交付項目,無論用的是什麼平臺,可以處理任何類型的構建或持續集成。
官網:https://jenkins.io/ 官方文檔:https://jenkins.io/doc/
六,接口可視化管理平臺
1,OpenApi
2,Swagger
3,YApi
4,EoLinker
七,開發人員常用社區推薦
1,官網+官方文檔 (這個是最重要的,接觸任何一個新平臺或者新技術,一定要從官方文檔入手,開發過程中很多疑難雜症覺得很難解決,往往就藏在文檔中被你忽略的角落)
2,Github
3,Stack Overflow
4,segmentfault
5,CSDN
6, 平臺或技術自有的社區或論壇
等,歡迎補充。