一、開發週期和sprint概述
1。1 sprint週期
按照固定週期（一個sprint，通常是1周或者2周）釋出新版本。
目前規劃：每一到二週一個sprint，最長不超過1個月
全部code提交、合併至release，部署到測試環境並開始整合測試
1。2 每個週期開始（或者上個週期快結束）時，大致確定下來下一srpint週期要完成的任務。通常有一些新feature，也有一些舊bug。
feature的分解：一個大的feature，通常不會在一個sprint裡完成。一個sprint裡，也不會只做一個新feature。為此，需要各feature小組把該feature分解成若干階段，方便在各個sprint分別提交。
各bug均可在自己的分支裡工作，快速修復並提交。不用多個bug擠在一個分支裡。
bug的選取：通常按照優先順序。優先順序同樣的，優先修復新近發現的。（注意，這裡的bug指的是backlog裡已有的、某種程度上不是火燒眉毛的那種bug，可以不太緊張地排期來修。還有一種bug是在線上系統發現的、火燒眉毛的、必須立即修復並上線的，通常叫hotfix。）
1。3 每天早上都要同步（更新）一下code，把本feature小組別人已經提交的code同步下來，及早發現和解決衝突。
1。4 一個sprint裡，每個開發人員都要對該spirnt的deadline心裡有數。在臨近deadline時，注意提交程式碼的質量。
1。5 每個feature小組，每次push到自己的遠端分支，都應該對此次提交的程式碼的質量有足夠信心（也就是說，經過了足夠的自測）。
1。6 臨近sprint deadline時，各組協調一下，把各自遠端分支按一定順序依次合併到release分支。後合併的，要先同步一下code，預防衝突。
1。7 所有feature分支、bug分支都合併到release分支後，部署到SIT環境上，進行一定程度的整合測試，並修復發現的bug。
1。8 若測試量大：測試人員測試若干天，開發人員同時開發下一sprint的任務。
1。9 上線。
1。10 線上發現問題：回滾 vs。 hotfix。
二、具體git操作概述
gitlab上長期保留兩個branch：
master
、
release
。並臨時保留若干
feature-{jira編號}-{date}
，例如：feature-SEH-2-20211231，分支，用於新功能開發。
每次有新功能要開發，要從release拉出新分支（命名為
feature-{jira編號}-{date}
）。該功能開發小組的各成員都在
feature-{jira編號}-{date}
分支上工作，在本地
feature-{jira編號}-{date}
分支上commit上並push到遠端
feature-{jira編號}-{date}
分支上。
注意：
這裡的jira編號為
story
或
feature
編號，當專案上線之後，分支會保留留一段時間（一般一週左右，最長不不超過1個月），直至最終刪除
2。1 新功能開發完成後，從遠端feature-{jira編號}-{date}分支上合併到遠端release分支上。
大致工作流程如下：
gitlab上長期保留兩個分支：master、release。
release分支是定時更新的相對穩定的版本，從各feature、bugfix分支合併而來，生命週期是一個sprint。
master分支是保持永遠穩定的版本，從release分支合併而來，落後release一個版本。
每次有新功能要開發，要從遠端release分支拉出遠端新分支（命名為
feature-{jira編號}-{date}
），由各個feature的負責人或者主力開發人員負責，過程如下：
從遠端倉庫clone到本地：
git clone git@gitlab2。ciics。cn：zyf-service/zyf-service-claim。git
建立本地feature-{jira編號}-{date}分支，跟蹤遠端release分支：
git checkout -b feature-{jira編號}-{date} origin/release
從本地feature-{jira編號}-{date}分支push到遠端，以建立遠端feature-{feature_name}-{date}分支：
git push -u origin feature-{fjira編號}-{date}
注意：
feature的負責人有以下職責：
負責建立feature-{jira編號}-{date}分支
開發完成後合併feature-{jira編號}-{date}分支到release分支，解決衝突
其他每個小組成員也在feature-{jira編號}-{date}分支上工作：
從遠端倉庫clone到本地：
git clone git@gitlab2。ciics。cn：zyf-service/zyf-service-claim。git
checkout 到分支feature-{jira編號}-{date}：
git checkout feature-{feature_name}-{date}
在本地feature-{jira編號}-{date}分支上工作、開發、修改，及時提交到本地：
git add xxx。file
git commit -m “JIRA-CODE commit log”
工作過程中，經常從遠端同步程式碼：
git remote update
git rebase origin/feature-{jira編號}-{date} //發生衝突要及時解決
把本地改動push到遠端同名分支。要經常：
git remote udpate
git rebase origin/feature-{jira編號}-{date} //發生衝突要及時解決
git push origin feature-{jira編號}-{date}
在適當時候，把遠端
feature-{{jira編號}-{date}
分支合併到遠端release分支。
什麼是“適當時候”？如果feature較小，兩三天就做完，則“feature做完時”是合適的。若feature較大，需要跨若干sprint，則“每個sprint結束時”是合適的。每個sprint是多長時間則可視具體情況而定。
這個merge過程，需要在gitlab的web頁面上提交一個“Merge Request”。該請求會發出一個code review請求。
過程如下：
在我們工程頁面下點選New Merge Request
選擇source和target branch，填寫相關內容，並提交
提交merge request，如果想從新選擇分支，可以點選Change branches，請求被接受後，gitlab上自動完成merge過程，不用人工再輸入命令。
release程式碼只有所屬小組的組長有許可權合交，組長在收到merge request的時候做code review，code review規範見第四章經過若干次從
feature-{jira編號}-{date}
分支合併到release分支及相應測試，可認為release分支穩定，可以正式對外發布，此時將release分支合併到master分支，並在master分支上打tag，如 v2。0。0等。可以同時有若干 feature 分支和或
bugfix-{jira編號}
分支進行工作，流程類似。若master分支上上線後發現了bug需要緊急修復，可從master分支拉出
hotfix-{jira編號}
，例如
hotfix-{SEH-100}
，分支工作，經過測試過後合併到master分支上，每次合併到master分支，都要把修改同時提交到release分支，同時通知所有feature分支都同步這次修改：
打TAG版本號管理
在release分支上執行以下命令以把hotfix的修改提交到release分支上：
git remote update
git rebase origin/release
git push
各個feature分支也要合併這次修改：
git remote update
git rebase origin/release
git push
三、關於commit程式碼提交
正確的版本控制系統的使用方法是，一次提交只幹一件事：或是完成了一個新功能，或是修改了一個Bug、或是寫完了一節的內容，或是添加了一幅圖片，就執行一次提交。不要在下班時才想起來要提交，那樣的話版本控制系統就被降格為檔案備份系統了。
如果一件事提交了多次，把多次合交為一個commit,
比如修復了一個hotfix，那麼應該只是針對一個commit。
git關聯jira的ISSUE提交示例，提交方式如下所示：
git commit -m ISSUE_KEY comment _string
例如：
git commit -m ‘SHE-2 修復空指標BUG’
注意：
這裡的ISSUE_KEY是指JIRA的TASK ID 或 BUG ID
