公司專案的開發流程主要是這樣
**分為
develop分支
master分支
平時我開發的時候，主要在develop分支上改動
一般來講，有以下幾種改動方式
1.直接在develop上修改**
這種一般是當前沒有大需求，沒有其他同事一起開發的情況下為了快速完成乙個任務才選擇直接改develop上的**，實際上這種做法不太符合規範
2.開發新功能，新開乙個feature分支修改
在feature分支上新建以新功能命名的分支，然後在此分支上開發，功能開發完成即可刪除此feature
3.準備新版本發布，在release分支上編譯修改一些細節
當版本發布時，可能有些準備工作和一些小細節改動，此時可以在release分支上完成後再合併
4.修復bug，在hotfix分支上修改
專門用於標記bug修復的乙個分支體系
專案修改好後上線的步驟如下：
首先，確認當前develop分支和master分支都是最新的版本，最好多拉取一下確認一遍
然後，將當前feature分支或者release分支上的東西merge到develop分支，如果沒衝突自然很順利
如果有衝突，就看哪邊改動大，以改動大的那一邊為準來解決衝突，記得事先將改變小的一方的改動**copy到文字編輯器中，然後解決衝突後再手動paste回來
分支merge成功後，將develop上的**推送到master分支
進入jenkins後台，修改編譯路徑字首為master，然後點選編譯，在控制台裡稍等片刻後複製下最後一行的war包的uri，然後將其傳送給運維，請求更新
git flow工作流總結
寫在前面 文章的出處是由於作者本人對於gitlab 以及sourcetree的使用實在是摸不著頭腦，所以決定將各個地方詳細的截圖下來 因為我找的資料裡面對我來說都是不夠用的 由於在學校的時候沒有接觸過git，所以實習有些不適應，就這些天的使用就行相關的總結。現在在實習公司用的gitlab sourc...
Git Flow工作流總結
gitflow 工作流定義了乙個圍繞專案發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於乙個健壯的用於管理大型專案的框架。gitflow 工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配乙個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備 ...
Gitflow 工作流簡介
gitflow工作流通過為功能開發 發布準備和專案維護分配獨立的分支，讓發布迭代過程更流暢。gitflow工作流定義了乙個圍繞專案發布的嚴格分支模型，它會相對複雜一點，但提供了用於乙個健壯的用於管理大型專案的框架，非常適合用來管理大型專案的發布和維護。貫穿整個開發周期，master和develop分...