分支管理規範：
總的工作流程圖如下所示：
主要分支
**倉庫中有兩個長期的分支：
master
develop
master 用作生產分支，裡面的**是準備部署到生產環境的。
develop 是可交付的開發**，也可以看成是用於整合分支，每晚構建從develop 獲取**。
當 develop 分支中的**足夠穩定的時候，就將改動合併到 master 分支，同時打上乙個標籤，標籤的名稱為發布的版本號。
輔助分支
通過輔助分支來幫助並行開發，和主要分支不同，這些分支的生命週期是有限的：
特性分支（feature branches）從 develop 分支分出，最終 必須 合併回 develop 。分支名以feature-* 開頭。
特性分支（也叫主題分支）用於開發新特性。每個新特性開乙個新分支，最終會合併回 develop （當特性開發完畢的時候），或者放棄（如果最終決定不開發這個特性）。
發布分支（release branches）從 develop 分出，最終 必須 合併回 develop 和 master 。分支名以release-* 開頭。
發布分支為新的發布版本作準備，包括一些小bug的修正和發布的元資訊（版本號、發布日期等）的新增。
這樣 develop 分支就可以接受針對以後的發布的新特性。在**基本可以發布的時候從 develop 分支分出發布分支。
這時要確保此次發布包括的特性都已經合併到 develop 分支了（同時，為下一版發布準備的特性不能合併到 develop 分支，必須等待發布分支分出後才能合併）。
緊急修復分支（hotfix branches）從 master 分出，最終 必須 合併回 develop 和 master 。
分支名以hotfix-* 開頭。緊急修復分支和發布分支很像，只不過它們是意料之外的。如果生產系統裡有乙個緊急的bug，必須馬上修復的話，我們就從 master 裡分出乙個緊急修復分支。
這樣，某個人修復緊急bug的同時，團隊其他成員可以繼續在 develop 分支上開發。
假設存在發布分支的話，**不應該合併回develop ，而應該合併回發布分支，確保正在準備的發布分支也能收到這個補丁（由於發布分支最終會合併到 develop ，因此這時不用再另外合併到 develop）。
faq：
1. 標準工作流程有哪些角色
對於每乙個分支，都有負責人和開發者這兩類角色，其中開發者負責開發和提交**，並解決持續整合中自己造成的構建失敗問題。
負責人需要在開發者完成開發後拉取並合併**，包含**審查以及衝突的解決，如果分支開發時間較長（比如三天）或者有多個開發者參與，需要在jenkins上建立持續整合job做管控。
2. ****庫一般有哪些分支？是否可以在上面建立個人分支？
****庫長期維護的只有master和develop分支，開發階段會有對應的feature、release、hotfix分支，但在使用完成後會盡快刪除。
個人分支一般存在於開發者本地，開發結束後應盡快合併回對應的分支，這裡建議盡量不要有太大的個人分支，做到開發者每天都要有對應的**提交並經過自動化構建和測試。
3. feature分支是否需要同步develop分支的**？
一般情況下feature分支分出後不需要再同步develop分支**，但為了儘量減少feature分支開發結束合併到develop分支所帶來的**衝突，可以考慮定期（比如每天）同步develop分支**，
這裡我們假定develop分支上的**會進入到下乙個版本中，所以這類同步不會造成太大影響。但如果存在不確定因素，則請feature負責人慎重，此處留有一定的靈活性，可以由feature負責人自己決定是否以及何時進行同步**。
4. feature分支何時可以合併到develop分支？
feature分支開發完成後，代表新功能已經開發完成，等待整合測試（目前採用的在feature分支上做相關功能測試也可以）。
如果該feature需要在下個版本中發布，此時即可合併回develop分支。
如果還不能確定該feature何時發布，建議暫時不要合併回develop分支，避免需要做撤回處理（成本很大），直到確定要在下個版本中發布時再合併回develop分支。
5. 如果develop分支上的某乙個feature需要撤銷該如何操作
首先，我們應該盡量避免這類操作，正常情況下我們假定合併到develop分支上**是會進入到下乙個發布版本中，如果還沒決定某個feature是否要在下個版本中發布，那麼最好不要合併到develop分支。
如果出現以外情況，比如合併後的feature出現重大問題並無法解決需要撤銷，則需要feature負責人將對應**從develop分支移除，並協助解決可能因此帶來的問題（比如有些後續開發依賴於之前feature的部分**）。
如果時間緊迫來不及去除，可以考慮暫時遮蔽掉該feature並在之後的版本中進行移除。
6. feature、release、hotfix等分支開發結束後是否需要刪除？
這類分支屬於臨時分支，建議在開發結束並合併完**後即可刪除，分支的歷史記錄會保留在develop和master分支中。
7. 是否支援類似github的pull request工作流
pull request方式主要用於開發者開發完成後向****庫提交**，由管理員審查並合併對應的**。目前我們的**庫工具還不支援此項功能，所以需要各個分支的管理員自己拉取開發者提交的**進行合併。
但不排除以後可能會支援這種功能。
版本控制工具：
當前公司內使用的是mercurial(hg)工具，最近和幾個移動開發team交流後，目前反饋的主要問題如下：
1. hg版本控制工具，不支援rebase，只支援close，close後的分支也並非完全去掉
2. hg push時不能選擇只push某些change set
3. hg一旦push之後不能撤銷或者回滾
4. hg合併分支的時候不能選擇合併某些提交
結合新的版本控制規範，後期需要大量的建立、刪除、合併臨時分支，hg無法完全刪除分支，關閉後仍然會留存在系統之中，這會對後期的分支管理產生較大影響，
另外目前使用hg工具的開發者相對較少，新同事在加入公司後大多需要學習和熟悉hg的使用方式。
ONVIF客戶端開發
在使用 gsoap 框架生成 之後,得到檔案 soapc.c soapclient.c stdsoap2.c stdsoap2.h duration.c wsdd.h我們利用現有的soapclient,呼叫api構建onvif請求 包括xml,http client 開發前需要了解一下onvif官網...
XFire客戶端開發
引入 xfire相關的類庫 1.使用wsdl生成靜態客戶端 訪問任意語言編寫的web service 2.使用介面生成靜態客戶端 必須拿到服務端的介面class檔案 遠端 工廠 xfireproxyfactory factory new xfireproxyfactory 建立服務模型 servic...
electron windows客戶端開發探索
話不多說，直接開幹。起因 乙個用electron框架開發的windows版瀏覽器需要我負責了。擼 將不知道的點記錄下來，僅供後續檢視。start chcp 65001 electron chcp 65001解釋 設定cmd顯示為utf 8編碼，windows cmd視窗執行此命令後cmd顯示不在亂碼...