一： 代碼管理工具，將本地項目同步至新建的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, 平臺或技術自有的社區或論壇
等，歡迎補充。